Wireless Network Security 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 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. CONCEPT SKETCH Remote Access User 1 INTERNET User 2 Firewall User 3 IASTATE User 4 LAB ENVIRONMENT VM Server Virtual Router Virtual Router VM Server Attack VM’s Transceiver VM’s Wireless Devices 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 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 Functional Requirements • Each user should be able to use the system without interference from other users. • Requires non-overlapping channels Functional Requirements • A way to attack the carrier sense multiple access with collision avoidance (CSMA/CA) • Requires packet injections at the Data Link layer. 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 Constraints • 802.11b/g channel bandwidth • Space in Nuclear Engineering • Hardware support for custom drivers 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 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 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. • 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. Cost Estimate VM Host Servers $950 (approx) Wireless Cards $200 ($20 x 10) Routers / Switch $100 Extra Hardware $250 - $500 Jamming / Sniffing Spectrum Analysis GSM RFID Total $1500 - $1750 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 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 Functional Decomposition Hardware/Software/Net Architecture Administrative Setup Wireless Experiments Laboratory Documentation 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 Design: Software Architecture • Multilevel – – – – Hypervisor OS Software tools Scripts • Mostly invisible to end user Design: Software Architecture • Hypervisor – Vmware vSphere 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 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 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 Design: Software Architecture • Drivers – Experiments based on nonconforming packet transmission – Direct buffer writing • Firmware – Embedded implementation of full and/or baseband spectrum analysis 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 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 Wireless Security Experiments Wi – Fi Bluetooth GSM RFID (3 - 4 Experiments) (1 - 2 Experiments) (1 - 2 Experiments) (optional) (1 - 2 Experiments) (optional) Jamming Attacks Header Based Sniffing Attacks Protocol Based Spoofing Attacks Traffic Based Authentication 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 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 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 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 QUESTIONS