1 / 34

Wireless Network Security Virtual Lab

Wireless Network Security Virtual Lab. Team sdDec11-10 Shishir Gupta, Anthony Lobono, Mike Steffen Client Dr. George Amariucai Advisor Dr. Doug Jacobson

emmahiggins
Download Presentation

Wireless Network Security Virtual Lab

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Wireless NetworkSecurity Virtual Lab Team sdDec11-10 Shishir Gupta, Anthony Lobono, Mike Steffen Client Dr. George Amariucai Advisor Dr. Doug Jacobson Dept. of Electrical & Computer Engineering Iowa State University

  2. Project Details Concept: CprE 537: Wireless Network Security has no lab element • Potential for enhanced learning by way of hands-on experimentation with live Wi-Fi, Bluetooth, RFID and/or GSM networks Problem: Course is popular among distance education students • Distance ed. students unable to use physical labs • Curriculum best suited to physical equipment Goal: Create a remote access wireless security sandbox environment and develop engaging course-relevant experiments to be run within it.

  3. CONCEPT SKETCH

  4. Functional Requirements • Remote access for both on and off campus students • Support for up to four concurrent users • Support for Bluetooth and Wi-Fi communication • Basic labs to demonstrate the lab environment • Comprehensive documentation for both administrating the lab and using the lab

  5. Functional Requirements • Users should have full control over their machines • Lab machines must communicate over the correct channels • Users should be able to see what resources are available

  6. Functional Requirements • Each user should be able to use the system without interference from other users. • Requires non-overlapping channels

  7. Functional Requirements • A way to attack the carrier sense multiple access with collision avoidance (CSMA/CA) • Requires packet injections at the Data Link layer.

  8. Non-Functional Requirements • Sufficient network bandwidth • Sufficient system resources • Each user will be allowed a single backup of their machines • Lab machines should be configured to simulate real world situations • User friendly

  9. Constraints • 802.11b/g channel bandwidth • Space in Nuclear Engineering • Hardware support for custom drivers

  10. Hardware Constraints • Limited USB ports • Limited PCI slots • 4 PCI/USB cards for malicious users • 4 USB Wi-FI dongles for clients • At least 2 Bluetooth dongles

  11. Market Survey • Similar wireless environments: Arizona State, Northeastern University, St. Mary’s University, others • No other remote labs specific to wireless communication. • Academic pursuit; marketability largely irrelevant

  12. Potential Risks & Mitigations • Risk: The virtualization plan requires specialized and sparsely documented hardware features which may be vulnerable to instability under extreme conditions- • Mitigation: We have set up a test environment and testing will remain an important part of the implementation process; preliminary testing results have been encouraging and potential scale-back or alternate architecture may be implemented as backup if needed. • Risk: Feasibility of executing jamming exploits at the installation location without disrupting near-by networks- • Mitigation: Extensive testing will also be undertaken after installation of the hardware at the final location. If necessary, interface power may need to be reduced or special antennas may need to be employed.

  13. Risk: Feasibility and/or legality of GSM-based and RFID –based security experiments- • Mitigation: These technologies will be re-evaluated for feasibility and remain an optional part of the functional requirements for this project till then. • Risk: A major aim of the project is to ensure that students have access to a safe platform where they can run many different types of experiments without limitation of low level hardware access. This means that there is always a risk that advanced experiments will go wrong sometimes and break a machine or mess up with the configuration. • Mitigation: We will keep back-up images for the entire setup of the lab environment and provide documentation such that an administrator can handle such a situation and quickly reboot the environment setup.

  14. Cost Estimate VM Host Servers $950 (approx) Wireless Cards $200 ($20 x 10) Routers / Switch $100 Extra Hardware $250 - $500 Total $1500 - $1750 Jamming / Sniffing Spectrum Analysis GSM RFID

  15. Schedule • Preliminary hardware setup by the end of February • Preliminary lab design by the end of March • Wi-Fi demo lab setup by the end of the first semester • Bluetooth • GSM second semester • RFID • Final lab setup and testing by the end of the second semester

  16. Task Responsibility As a small team of three members, each member will be involved with each and every aspect of project. However, here is a very basic work breakdown- • Michael Steffen – Hardware Specialist Michael will lead the design and setup of the entire hardware architecture for the lab • Anthony Lobono - System Specialist Anthony will lead the design and setup of the entire system architecture for the lab • Shishir Gupta - Security Specialist Shishir will lead the design and implementation of the wireless security experiments for the lab

  17. Functional Decomposition • Hardware/Software/Net Architecture • Administrative Setup • Wireless Experiments • Laboratory Documentation

  18. Design: Hardware Architecture • Commodity x86 server hardware • Two machines for I/O requirements • USB wireless dongles (Ralink) • Consumer-grade routers • Wireless camera • Custom RF analysis tools • USB Bluetooth/RFID/etc tools

  19. Design: Software Architecture • Multilevel • Hypervisor • OS • Software tools • Scripts • Mostly invisible to end user

  20. Design: Software Architecture • Hypervisor • VmwarevSphere Hypervisor 4.1 • Free license • Robust platform • Team familiarity • Ease of configuration • Custom scripted via console SSH • Virtual machines • Four transmit client nodes • One receive client node • Four attack nodes • Two host config nodes (one per host) • One administration node • Each transmit/attack node assigned a physical network adapter

  21. Design: Software Architecture • Operating system • Client machines: Arch Linux • Lightweight, configurable • Attack machines: BackTrack • Preinstalled and preconfigured exploit tools • Administrative machines: Arch Linux • Resource-friendly background machines • Operating systems tuned for efficiency and scripted for environment compatibility

  22. Design: Software Architecture • Dilemma: How to ensure environment is equally available to all? • Solution: Each user has own VM • Remains off until requested • Radio config patched before boot and stripped after logoff • Result: greater uptime for all users

  23. Design: Software Architecture • Drivers • Experiments based on nonconforming packet transmission • Direct buffer writing • Firmware • Embedded implementation of full and/or baseband spectrum analysis

  24. Design: Software Architecture • Scripts • Backend: Hypervisor scripted to allow statistics gathering, power state mods, file operations • Frontend: Transmitters scripted to generate traffic, all machines scripted to behave properly when user logs out • Scripts for environment user management, administration • User interface • Web portal • Access to system status, user file operations, documentation • Terminal or X server access to user’s attack and transmit nodes • X access via Nomachine NX

  25. Design: Network Architecture • Intent: user environments separate from each other • Users MAC-locked to router • Can be bypassed • Transmit nodes blocked from communicating via firewall • Routing of HTTP versus SSH traffic achieved via firewall, routing tables • Radio separation achieved by manual channel configuration

  26. Wireless Security Experiments • Wi – Fi (3 - 4 Experiments) • Bluetooth (1 - 2 Experiments) • GSM (1 - 2 Experiments) (optional) • RFID (1 - 2 Experiments) (optional) Jamming Attacks Sniffing Attacks Spoofing Attacks Header Based Protocol Based Traffic Based Authentication

  27. Test Plan • Each component of the sandbox environment will be tested to ensure it is functional • Administrative scripts must be tested • Administrative virtual machines must be secured and tested • System benchmarks will be preformed on all virtual machines • Preliminary test case

  28. Problems • How to route network traffic correctly over two different wireless interfaces • No support for VMware Snapshots while using hardware I/O redirection • No command line interface support for the free version of ESXi hypervisor. • Lack of documentation

  29. Current Status • Preliminary test case is open to the current Computer Engineering 537 class • Wireless hardware has been ordered • System architecture is in final stages of planning • Starting the documentation process

  30. Second Semester Plan • Evaluate and implement security plan • Finish administrative scripts • Plan and/or implement Bluetooth, other network protocols • Expand documentation wiki • Write laboratory experiments and administrative docs • Determine feasibility of / implement dongle buffer writing • Assemble and configure final hardware

  31. Questions

More Related