Uploaded on

 

More in: Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
252
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
2
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. SHARK: A Wireless Internet Security Test Bed May07-09 Final Report Senior Design Project Department of Electrical and Computer Engineering Iowa State University Clients Department of Electrical and Computer Engineering Iowa State University Team Advisors Dr. Steve Russell Team Members Steven Eilers Computer Engineering Jon Murphy Computer Engineering Alex Pease Computer Engineering Team Leader Jessica Ross Computer Engineering Communications Coord. REPORT DISCLAIMER NOTICE DISCLAIMER: This document was developed as a part of the requirements of an electrical and computer engineering course at Iowa State University, Ames, Iowa. This document does not constitute a professional engineering design or a professional land surveying document. Although the information is intended to be accurate, the associated students, faculty, and Iowa State University make no claims, promises, or guaran- tees about the accuracy, completeness, quality, or adequacy of the information. The user of this document shall ensure that any such use does not violate any laws with regard to professional licensing and certifica- tion requirements. This use includes any work resulting from this student-prepared document that is re- quired to be under the responsible charge of a licensed engineer or surveyor. This document is copyrighted by the students who produced this document and the associated faculty advisors. No part may be repro- duced without the written permission of the senior design course coordinator. Submitted: 6/16/2010
  • 2. TABLE OF CONTENTS 1 LIST OF DEFINITIONS............................................................................................................................6 2 INTRODUCTORY MATERIALS...........................................................................................................11 EXECUTIVE SUMMARY...................................................................................................................................11 PROBLEM STATEMENT....................................................................................................................................12 GENERAL PROBLEM.......................................................................................................................................12 OPERATING ENVIRONMENT.............................................................................................................................12 INTENDED USERS AND INTENDED USES.............................................................................................................13 2.1.1 Intended Users.............................................................................................................................13 2.1.2 Intended Uses...............................................................................................................................13 ASSUMPTIONS AND LIMITATIONS......................................................................................................................14 2.1.3 Assumptions.................................................................................................................................14 2.1.4 Limitations...................................................................................................................................16 EXPECTED END PRODUCT...............................................................................................................................17 3 APPROACH AND RESULTS..................................................................................................................17 FUNCTIONAL REQUIREMENTS .........................................................................................................................17 DESIGN CONSTRAINTS....................................................................................................................................19 APPROACHES CONSIDERED AND SELECTED........................................................................................................20 3.1.1 SHARK Box..................................................................................................................................20 3.1.2 Wireless Network.........................................................................................................................22 3.1.3 Traffic Generation.......................................................................................................................23 3.1.4 Transfer data to Analysis Machines............................................................................................24 3.1.5 Analysis........................................................................................................................................24 3.1.6 Virtual Machines.........................................................................................................................25 3.1.7 7of9..............................................................................................................................................25 DETAILED DESIGN.........................................................................................................................................26 3.1.8 Hardware.....................................................................................................................................27 3.1.9 Computers....................................................................................................................................27 3.1.10 Wireless cards and Access Point...............................................................................................27 3.1.11 Wireless access points, and other hardware.............................................................................28 3.1.12 Physical Network layout............................................................................................................28 3.1.13 Logical Network layout..............................................................................................................31 3.1.14 Large Area Network layout.......................................................................................................32 SOFTWARE....................................................................................................................................................33 3.1.15 Operating systems......................................................................................................................33 3.1.16 Linux..........................................................................................................................................33 3.1.17 UNIX..........................................................................................................................................33 MACHINE BREAKDOWN..................................................................................................................................34 3.1.18 SHARKweb................................................................................................................................34 3.1.19 SHARK (access point)................................................................................................................35 3.1.20 SmallBox ...................................................................................................................................35 3.1.21 Virtualnet (virtual network host)...............................................................................................36 OTHER DESIGN OPTIONS...............................................................................................................................37 3.1.22 7of9 as a computer..................................................................................................................37 3.1.23 No NAT on the analysis network...............................................................................................37 IMPLEMENTATION PROCESS DESCRIPTION..........................................................................................................38 3.1.24 SHARK.......................................................................................................................................38 3.1.25 Virtual Net.................................................................................................................................39 3.1.26 Analysis......................................................................................................................................39 TESTING APPROACH ......................................................................................................................................40 3.1.27 Lab Test.....................................................................................................................................40 3.1.28 Field Test...................................................................................................................................42 2
  • 3. END PRODUCT RESULTS.................................................................................................................................44 THE FOLLOWING SECTION CONTAINS DETAILS ABOUT THE END PRODUCT RESULTS.....................................................44 3.1.29 Lab Testing................................................................................................................................44 3.1.30 Field Testing..............................................................................................................................45 PROJECT END RESULTS..................................................................................................................................46 3.1.31 SHARK ......................................................................................................................................46 3.1.32 7of9............................................................................................................................................46 3.1.33 Analysis......................................................................................................................................46 3.1.34 Virtual Machines.......................................................................................................................46 4 RESOURCES.............................................................................................................................................47 ESTIMATED RESOURCES..................................................................................................................................47 PERSONAL EFFORT REQUIREMENTS....................................................................................................................47 OTHER RESOURCE REQUIREMENTS.....................................................................................................................50 FINANCIAL REQUIREMENT................................................................................................................................53 5 SCHEDULE...............................................................................................................................................57 6 CLOSURE MATERIALS.........................................................................................................................59 PROJECT EVALUATION....................................................................................................................................59 COMMERCIALIZATION.....................................................................................................................................60 ADDITIONAL WORK.......................................................................................................................................61 LESSONS LEARNED........................................................................................................................................61 6.1.1 What went well.............................................................................................................................61 6.1.2 What did not go well....................................................................................................................61 6.1.3 What technical knowledge was gained........................................................................................61 6.1.4 What non-technical knowledge was gained.................................................................................62 6.1.5 What would you do differently if you could do it over again.......................................................62 RISK AND MANAGEMENT.................................................................................................................................62 ANTICIPATED POTENTIAL RISKS AND PLANNED MANAGEMENT................................................................................62 ANTICIPATED RISKS ENCOUNTERED AND SUCCESS IN MANAGEMENT........................................................................63 6.1.6 Unanticipated risks encountered, attempts to manage and success............................................63 PROJECT TEAM INFORMATION.........................................................................................................................63 6.1.7 Client Information.......................................................................................................................63 6.1.8 Faculty Advisor and Graduate Assistant.....................................................................................64 6.1.9 Student Team Information...........................................................................................................64 CLOSING SUMMARY........................................................................................................................................66 3
  • 4. LIST OF FIGURES FIGURE 1: THE ABOVE IMAGE REPRESENTS THE PHYSICAL NETWORK LAYOUT..........30 FIGURE 2: THIS FIGURE REPRESENTS THE LOGICAL NETWORK LAYOUT. ....................31 FIGURE 3: THIS IS THE LARGE AREA NETWORK LAYOUT FOR THE SHARK PROJECT..32 FIGURE 4: THIS FIGURE SHOWS THE MACHINE SOFTWARE BREAKDOWN.......................34 4
  • 5. LIST OF TABLES TABLE A: OLD ESTIMATE OF PERSONAL EFFORT.......................................................................48 TABLE B: DESIGN PHASE ESTIMATE OF PERSONAL EFFORT..................................................49 TABLE C: FINAL PERSONAL EFFORT................................................................................................50 TABLE D: OLD OTHER RESOURCES...................................................................................................51 TABLE E: REVISED OTHER RESOURCES..........................................................................................52 TABLE F: FINAL OTHER RESOURCES................................................................................................53 TABLE G: OLD FINANCIAL REQUIREMENTS..................................................................................54 TABLE H: REVISED FINANCIAL REQUIREMENTS.........................................................................55 TABLE I: FINAL FINANCIAL REQUIREMENTS................................................................................56 TABLE J: DELIVERABLES EVALUATION..........................................................................................59 5
  • 6. 1 List of Definitions This section contains some definitions that may be useful to the reader. 7of9 – the SHARK system’s open access point ARP – Address resolution protocol Bandwidth – The amount of data that can be passed over a communications medium in a given period of time. Captive portal – When a user first connects to a network, a captive portal is sometimes used to route them to a default page where they must login before using the Internet normally. ChilliSpot – one of many open source captive portal solutions Compromise – A system is said to be compromised when an attacker gains access to all of its administrative functions. DMZ – Demilitarized zone – A network area set up between one’s private network and a public network, like the Internet. 6
  • 7. FreeBSD – A free UNIX-like operating system that is somewhat lesser known than Linux. GNU General Public License – (GPL) A license that allows software to be used and modified freely for no cost as long as these changes are marked and the resulting work is also released under the GPL. For more information, visit www.gnu.org/licenses/gpl.html Hacking sandbox – A research based playground for hackers and upcoming hackers to test their ability to hack into the wireless security networks. Honeyd – an open source software system that creates virtual hosts on a network Linux – A UNIX-like operating system widely used by students in computer related fields available for use and modification under the GPL. Microsoft Windows – A popular operating system in the university and world environment. mySQL- An Open Source multithreaded SQL database management system 7
  • 8. Open source software – Any software whose source code is available under some license that permits users to study, modify, and distribute the code in modified or unmodified form. Software in this category is also known as “free”. The GNU General Public License is one of the licenses used for this type of software. OS X – Apple Computer’s UNIX-like operating system. Packet – A unit of data sent over a network. Proxy – A computer used to allow a client to make indirect connections to other machines. RADIUS – (Remote Authentication Dial-In User Service) - An authentication and accounting system used by many Internet Service Providers. Enter a username and password into the system, if valid, grants access to the wireless network. SHARK – a wireless security network to be used to study wireless security issues as well as serve as a hacking sandbox for students. Ssh – a set of standards and an associated network protocol that allows a user to create a secure connection between two computers 8
  • 9. SUSE Linux – a distribution of Linux Traffic – The flow of data over the internet. Traffic analyzer – A program which analyzes internet traffic and send the information back to a centralized location. Traffic generator – A program which generates authentic-looking internet traffic Ubuntu – A distribution of Linux based on Debian, an older Linux distribution. UNIX – A command line based operating system developed for digital computers in 1969. It is still in use today in various incarnations. VPN – Virtual private network – A private communications network established over a public network used to send data from point to point securely. WAP – Wireless access point – a radio networking device used to connect one or more computers together and possibly to the Internet WEP – Wired Equivalent Privacy – A WiFi encryption protocol on wireless security networks. It uses a stream cipher and single fixed size key to encrypt the data stream. This method of encryption can be defeated if the 9
  • 10. attacker can intercept packets. Rotating-key WEP attempts to patch this vulnerability by changing the WEP key every so often. WiFi – Wireless fidelity – Term meant to be used generally to refer to any type of wireless communications network or protocol standard. Wiki – A website that allows users to add, remove, and edit content according to the whims of the administrator of the site. Wireless network – A network connection between two or more computers in which data is transmitted via low powered radio waves. Wireless security – Methods and means of securing wireless networks from abuse by unauthorized users WPA – WiFi protected access – A WiFi standard intended to improve the security features of WEP. X11 – A client-server based protocol used to implement graphical user interfaces. It features network transparency; the client and server may or may not run on the same machine. Also known as the X Window System. Xen – an open source virtual machine monitor 10
  • 11. 2 Introductory Materials This section contains information about how SHARK was conceptualized and for whom it is intended. Executive Summary The SHARK system is a wireless security network that will be used to study security related issues on wireless networks. When deployed, SHARK will provide a cheap and efficient research system intended to be implemented at various educational institutions. The SHARK system itself is a modular system and well documented so that it is easily installable at any reasonable location for research purposes. Since the system is being deployed to research computer hacking and related security issues, it must be as well protected as possible from being exploited itself. In addition since the system is under a limited budget, the software and equipment was chosen to keep the system as cheap and small as possible while still within design constraints. As we are currently proceeding, the project is on schedule and within budget. The following sections define in detail the limitations, assumptions, approaches, and resources that the SHARK system has and will operate under. 11
  • 12. Problem Statement This section describes the problem to be solved in detail and includes a detailed problem statement and an approach to a solution. General Problem SHARK was conceptualized to provide a means by which students can learn about wireless security. The Departments of Electrical and Computer Engineering and Computer Science at ISU are severely lacking in courses on information technology in general, especially on the undergraduate level. The number of faculty with expertise in this field is limited, so creation of courses in this field is restricted to their available time. Thus, the idea of offering a system to students to study on their own time was proposed. This project is a continuation of the Fall 2005/Spring 2006 SHARK senior design problem. Operating Environment SHARK consists of a group of computers intended to be housed inside of campus buildings. These are kept at temperatures comfortable to computer users and administrators (typically around 70 Fahrenheit). In the 12
  • 13. case of heating/air conditioning failure, the various components of SHARK shall be able to withstand an ambient temperature range of 45 to 100 Fahrenheit. Intended Users and Intended Uses This section provides details about the anticipated users and usages for the final product. 2.1.1 Intended Users The intended users of SHARK are ISU college students interested in information security. Typically, they are between the ages of 18 and 22 and male, but there will be exceptions to this rule. They will probably be computer engineering or computer science majors in different parts of their college education, so the best assumption is that they have a basic high school education and know the basics of how wireless internet works (e.g. how to switch wireless access points). Most people prefer to use UNIX-based operating systems such as Linux, OS X, and FreeBSD due to their flexibility with respect to low level tools, but some may be using Microsoft Windows-based operating systems. 2.1.2 Intended Uses 13
  • 14. SHARK is intended to be used as a tool by which to learn about wireless security. The user is supposed to access one of SHARK's wireless access points (WAPs) via their operating system's wireless internet tool and use any means available to use the WAP to send data and/or read other data off of it. SHARK is intended to be used as a legitimate hacking tool so that curious students do not have to illegally access someone else's private WAP. Care must also be taken to make sure that students do not break into ISU's network from SHARK. Assumptions and Limitations This section details the assumptions and limitations that the SHARK team used while developing SHARK. 2.1.3 Assumptions The following are the assumptions used to develop SHARK.  The software involved in building SHARK shall be freeware available under the GPL or similar license.  The traffic analyzer shall be able to monitor connections to the wireless access points, packet traffic (including the fake 14
  • 15. traffic from the traffic generator), and activity inside of the machines hosting the wireless access points.  The traffic generator shall be able to generate traffic in a non-monotonous way such that prospective hackers cannot tell that it is not a real network they are hacking.  The web server component shall be secure enough to not be at risk for defacement by prospective hackers.  The web server shall have the capability to log the email address and name of prospective hackers desiring more information about SHARK and wireless security.  There will be 5 levels of difficulty involved in breaking into SHARK. The difficulty levels will be increased periodically and those registered as interested in SHARK shall be notified via email when security is upgraded. • Level 1 (GUPPY): No security. • Level 2 (CLOWNFISH): Hackers shall crack WEP. • Level 3 (SWORDFISH): Hackers shall crack rotating key WEP before being ranked SWORDFISH. 15
  • 16. • Level 4 (BARRACUDA): Hackers shall crack WPA before being ranked BARRACUDA. • Level 5 (SHARK): Hackers shall defeat RADIUS server.  A reasonable number of prospective hackers shall attack the system at one time according to the limits of the WAPs and software associated with SHARK. 2.1.4 Limitations  Wireless access points must be portable.  There are only three computers available for use in the initial build of SHARK, including the web server.  SHARK must be built within a $150 budget. There are extremely limited funds available for use in this project, including documentation.  SHARK has to be isolated enough from the rest of ISU's network to remove or reduce the possibility of ISU's network being compromised. 16
  • 17. Expected End Product The SHARK team will create a system of wireless access points that seems like an actual real life network to be used as an educational hacking sandbox as well as a research data source. In addition to deploying this system, the SHARK team shall provide enough documentation about the project to allow other researchers or future senior design teams to expand upon this project. 3 Approach and Results This section contains details about the approach used by the SHARK team and results of that choice. Functional Requirements The following are requirements to be fulfilled by an assembled end product. • All participants can operate the system The project is designed for educational purposes, so anyone should be able to attempt to use the system. • Well documented users The users shall be well-documented, so abusers of the system 17
  • 18. can be identified. It should also record users and their access. • Traffic generation A wireless card on the SHARK node will be dedicated to traffic generation, so that the students can use that traffic to help them break into the machine. • Control traffic leaving the SHARK node The system shall be able to control all traffic leaving the SHARK node. Web traffic should be allowed to access the web, but all other traffic should be forwarded to the virtual network. • System will provide a wireless network The project will provide a wireless network for the purpose of users attacking the network and providing a safe and legal environment for hacking exploration. • System will be secure. The system will be made as secure as possible to reasonably prevent malicious attacking on the system from causing extensive damage to the system or connected networks. • Traffic monitoring All traffic entering the SHARK node will be captured and used for determining packets detected, users using the system, etc. • Various levels of Security 18
  • 19. The system should provide various levels of security for users to attempt to break through and examine. • Analysis The system will capture the traffic on the SHARK node and provide statistical data on what type of packets were detected and the time it took for users to enter the system. Design Constraints This section discusses conditions that the final product must be able to withstand and limiting factors. • Minimal Size SHARK node needs to be as small as possible so that way it can be placed in a closet and not be in the way of university personnel. • Contact with hackers The entire unit, including the SHARK node, will be accessible to well-educated security personnel, and must be able to withstand their abuse. • Minimal cost The SHARK node needs to be cheap enough for other universities to buy it, and place it on their campus. Universities 19
  • 20. in general have tight budgets. • Wireless Cards Wireless cards can either listen to or transmit traffic; they cannot do both at one time. • Outputs The system will be expected to be able record all traffic sent by intruders that have penetrated the network, and all traffic sent across the 7of9 access point. • Security The system will be expected to be reasonably secure from malicious attacks. • Reliability The system will be expected to be reasonably fixed if broken, and updateable. Approaches Considered and Selected The following section contains details about the SHARK team’s approach considerations. 3.1.1 SHARK Box For the SHARK box itself, the team had two design issues to accomplish. The 20
  • 21. first issue was what operating system to use on the system and second was what piece of software to provide a captive portal. A captive portal redirects any user who connects to a computer to a specified location, our login page for example. 3.1.1.1 Operating System The team looked at two approaches for implementing and operating system on the SHARK box. The first approach was to use Ubuntu, a distribution of the Linux operating system based on the Debian distribution of Linux. The advantages to this approach are that the operating system is well documented; well supported with software; fairly easy to make secure; most of the SHARK team had experience with Ubuntu; and it is Open Source software. The disadvantages to this approach were that it is an Open Source solution with no official support. The second approach we considered was using FreeBSD, a Berkeley Unix-based operating system. The advantages to this choice were that it can be made more secure than Linux, and that it’s also an Open Source solution. The disadvantages to this approach are that it is not as well documented as Ubuntu, there is no official support, none of the team members had much experience with it, and it can be difficult to locate programs for. The team chose to go with Ubuntu because team members are familiar with the system and it is a well documented operating system. 3.1.1.2 Captive Portal The team considered two options for creating a captive portal. The first was a software solution called ChiliSpot. The advantage of this application was that 21
  • 22. there were tutorials available to assist in installation, and that it is an open source solution. The disadvantage of this approach was that because it is an open source solution, it has no support. The second option that we looked into was purchasing a captive portal software solution. The advantages to this solution were that it would be supported and guaranteed to work. The disadvantages to this solution were that it would exceed our budget to purchase. We chose to go with the ChiliSpot solution because it was an open source solution and we found a tutorial to install and configure the software. 3.1.2 Wireless Network The team considered two options for the wireless network. The first option the team considered was to have two separate wireless cards connected to a computer. The first wireless card would create the wireless network for using software included in the local computers operating system. The advantages to this approach would be that the wireless card would be a part of the host computer; no external components would be required. Disadvantages to this approach are that extra configuration is required in the operating system to make the wireless network; wireless cards required are difficult to locate; and expenses would be higher. The second option the team considered was to purchase a proprietary wireless access point instead of a wireless card. The access point would then be connected to the computer. The advantages to this approach are that the wireless access point is capable of handling all security levels required; no extra configuration or software is required on the local computer; cheaper than the necessary wireless cards; traffic can be directly transferred to other 22
  • 23. machines. The disadvantage of this approach was that SHARK would no longer be self-contained. The team chose to go with the wireless access point for multiple reasons, most notably time constraints for testing the system and ease of instillation. 3.1.3 Traffic Generation For generating traffic on the SHARK wireless network, the team needed to create ARP packets. Two approaches were considered. The first approach is to write a program to directly connect to the access point through a wireless card. The connecting process creates the ARP packet that is needed for attacking an access point. Then the program will disconnect from the access point. Once the program disconnects, it reconnects to the access point to create another ARP packet and continues this pattern. The advantage to this approach is that it more accurately simulates a real network. The disadvantages to this approach are that it doesn’t generate ARP packets as quickly as preferred; and requires a second program to automatically restart the program to reconnect to the network. The second approach was to write a program that simply generates ARP packets and sends them out on the wireless network. The advantages of this approach is that it generates more ARP packets faster for users to use, doesn’t need to continually connect to the access point, and doesn’t need any additional components to operate. The disadvantage to this approach is that it doesn’t simulate ARP packets as accurately as the first approach. The team decided to use the second approach for our project. The reason for this is that for users to successfully break our system, they need a large number of ARP packets. This 23
  • 24. approach generates them faster and possibly makes it easier for users to successfully enter the network. 3.1.4 Transfer data to Analysis Machines The team considered one option for this. We would connect the SHARK machine to the analysis machines through an Ethernet hub. The advantages of this approach are that all data received on the hub gets sent to all other machines connected to the hub. The disadvantage to using the hub is that it isn’t a completely secure device. We chose to implement this approach because we need the traffic at multiple locations and this accomplishes this by default; the hub is transferring data to secure machines so hub security is a negligible issue; and installing the hub is simple, requiring only being plugged in. 3.1.5 Analysis The team considered one option for SHARK’s traffic analysis. This option was to monitor and capture the traffic on the SHARK network. Using the program Ethereal SHARK would capture the traffic on the network, ignoring ARP packets sent by the traffic generator because these are too numerous to monitor and we know what they are. Once the traffic is captured it will be sent to the provided analysis machines over an internet connection. The resulting data will be analyzed to find what types of packets were detected on the system and approximately how long it took for users to break through the encryption. The advantages to this approach are that it provides data on packets used to hack a network; how long the average successful attacker might take. The disadvantage to this system is that the files will be extremely large and possibly 24
  • 25. larger than the system with its limited space will be able to deal with. The team chose this approach because it would give us some information on the attackers and provide additional results. 3.1.6 Virtual Machines The team considered mainly one approach for implementing the virtual machines. This approach was to use the software package Xen. Using Xen the will create three virtual machines. The first virtual machine created would be a virtual mail server, which provides a target and for any attackers that wish to attack it. The second virtual machine to be created by Xen will be a tar pit, which acts as a magnet to draw in any packets not sent to any machines on the virtual network. The third and final virtual machine created will be an instance of Honeyd, which mimics a number of computers to confuse attackers. The advantages to using Xen; it’s a free open source software; its documented; access to people with experience in Xen. The disadvantages would be it is not greatly supported; to make a change one needs to change multiple files. The reason the team went forward with this option is because it helped simulate a real network environment; it was a free solution; and makes it a little harder for attackers to reach the real systems. 3.1.7 7of9 The team considered two different approaches to completing the 7of9 module. The first approach was to use two additional wireless cards and connect them directly to the SHARK box. One card would create the wireless network, and the other card would monitor the network and send the traffic to SHARK’s other 25
  • 26. machines. The advantages to this are that the network would be self-contained on the SHARK box. The disadvantages are that the SHARK box is unable to handle that many wireless cards in addition to the current wireless card and cost of purchasing cards would exceed SHARK’s budget. The second approach considered by the team was purchasing a non-secure access point, and connect it to the hub. The advantages of this system are that it would send all traffic to the hub by default, lower the cost of equipment (enabling us to stay under budget), and simplify the design. The disadvantage of this approach is that it is an external device to the system. Since 7of9 does not need to be a component of SHARK the disadvantage is negated. The team chose the access point because it lowered the overall cost and accomplished the goals for the 7of9 entity. Detailed Design The SHARK Project consists of hardware and software. The hardware consists of four computers, multiple wireless cards, two hubs, one router, and a wireless access point and Ethernet cards and cables. The software consists of the operating systems on every machine, and the software and services every machine is running. 26
  • 27. 3.1.8 Hardware The following describes in detail the hardware that is to be used by the system. 3.1.9 Computers There are four computers; each computer serves a purpose. The first computer (SHARKweb) is a dedicated web server that hosts the project website and contest information, the machine is a dedicated web server. The second computer (SHARK) hosts a single SHARK node and contains one wireless card and is connected to a proprietary access point. A SHARK node is a computer functioning as a wireless access point that the students will be penetration testing. A SHARK node is easy to set up and able to be set up anywhere on a network. The third machine (Virtualnet) functions as a virtual network. It hosts at least 3 virtual machines. The 4th machine (smallbox) is an analysis machine, running packet capturing software (ethereal) to analyze the techniques used by the intruder to compromise. 3.1.10 Wireless cards and Access Point The team is using an proprietary access point that will provide the wireless network for users. The access point, connected to the SHARK node, will function as the access point granting the intruder access to the virtual network. The 27
  • 28. access point will have 5 levels of security, during registration it will be open without any security. During the challenge there will be 4 levels of security: WEP, what the basic home user uses; WPA, what the advanced home user uses; rotating WEP, this is like WEP, just every so often the WEP key changes; and, finally the corporate solution RADIUS, which requires a user logon to use the network. The wireless card is to function as a traffic generator to help the intruders break into the network by generating packets with the correct encryption. 3.1.11 Wireless access points, and other hardware There will be one proprietary access point (7of9) left open so that internet users can connect to it and everyday traffic in the area can be analyzed. The network will need two hubs so that the traffic coming into the 7of9 access point and the traffic forwarded to the virtual network can be analyzed. The web server, virtual network, and analysis machine will all be located behind a router, running a NAT for security. The purpose for this is that it allows for one register IP address, a DMZ for the web server, and tighter security for user restrictions. 3.1.12 Physical Network layout Please refer to Figure 1 for the physical network layout. The SHARKweb machine is not directly connected to any of the other machines-it is functioning as 28
  • 29. a web server, and is thus on a separate branch of the router. The 7of9 access point is connected to the internet via a hub that is shared by a SHARK node. SHARK has two wireless cards, one to host the SHARK node, and the other to generate traffic. Connected to the SHARK node are the intruders’ and the traffic generator’s wireless card. The Ethernet connection to the internet allows for remote login to box for maintenance. The connection also hosts a tunnel to the virtual network. The tunnel should be secure and transparent to others on the internet. It is implemented using a VPN or X11 protocol. The tunnel goes to a router that has two branches a DMZ hosting SHARKweb, and a private network. The private network directly connects to a hub so that the analyzer smallbox can record packets for analysis. The virtualnet machine also receives all of these packets. 29
  • 30. Virtual Network analyzer hub VirtualNet SmallBox webserver router Sharkweb Physical View Internet attackers Access point generator hub Access point 7of9 Shark Figure 1: The above image represents the physical network layout. Once a user hacks into the virtual network, they will have web access via the captive portal. It will allow for port 80 to have internet access, but all other traffic will be forwarded to the virtual network. 30
  • 31. Virtual Network analyzer VirtualNet SmallBox webserver Sharkweb Logical View Internet All other traffic from shark attackers Port 80 traffic from shark and all of 7of9 traffic Access point generator Access point 7of9 Shark Figure 2: This figure represents the logical network layout. 3.1.13 Logical Network layout Depicted above in Figure 2 is how the machines actually interact. SHARKweb appears connected directly to the Internet along with the 7of9 access point. Traffic from Port 80 from an intruder will be allowed to make http requests while all other traffic will be forwarded through a tunnel to the private analysis network. Also, all communications for SHARK node maintenance must come through the 31
  • 32. secure tunnel. Attackers will see the SHARK access point and traffic from the traffic generator going across the SHARK wireless network. 3.1.14 Large Area Network layout The layout for the SHARK network is show in Figure 3 below. There is a private analysis network with a virtual network attached. This private network then connects to Iowa State University’s (ISU) Public Network. There will be one SHARK node on ISU public network and then other SHARK nodes located on other public networks anywhere in the world. Virtual Network Research Private ISU Network shark Remote Private Public Internet Remote Private shark Figure 3: This is the large area network layout for the SHARK project. 32
  • 33. Software The following describes in detail the software solutions that is be used to execute the project. 3.1.15 Operating systems The operating systems are the technician’s interface to the machine for maintenance. 3.1.16 Linux All machines except for the web server are a flavor of Linux. The virtual network machine and the SHARK node are Ubuntu, because it is the latest distribution in the Debian family and is quickly being recognized as the easy to use. It has good documentation and is well supported. Using this distribution insures a longer life time of distribution support and upgrading. The analysis software will run on a SUSE Linux machine. The current project team is stronger in Linux than UNIX, so there is less of a learning curve. 3.1.17 UNIX The web server is running Free BSD, a highly documented and well-supported UNIX distribution. It is easier to secure and lockdown a web server in UNIX the in Linux. 33
  • 34. Machine Breakdown This section will look at every individual computer and list the important service running on each machine. A graphic representation is shown in Figure 4. Anayisis VirtualNet SUSE Ubuntu Snort Xen WireShark PXI loder Mysql Apache Shark Ubuntu Sharkweb Chillispot FreeBSD Void11 Apache Apache Mysql Mysql php WireShark Figure 4: This figure shows the machine software breakdown. 3.1.18 SHARKweb The SHARK web server is running on Apache with php installed, to handle the wiki page that is for the developers’ weblog. In addition, mySQL is installed to 34
  • 35. handle the user login for the wiki page. The server is running Free BSD, since it is highly securable. 3.1.19 SHARK (access point) The operating system running on the machine is Ubuntu. mySQL and Apache are also installed and running on the machine. When a user connects to the access point he or she will be redirected to a locally hosted web server for login/registration. In order to have web access the intruder must be registered on the machine. Squid, a proxy software will be running and functioning as a transparent proxy, allowing port 80 traffic to go to the web, while all other traffic will be sent to the virtual network. Chili Spot, a captive portal creating software is also running on the SHARK node. The captive portal redirects all traffic that is successfully on the access point to the registration page until the attacker registers, validating their success at breaking into the network. The generator will consist of a program that generates a lot of ARP packets. This allows attackers to use the ARP packets to break into the wireless network. 3.1.20 SmallBox This machine is set as an intrusion detection system, it is designed to record and recognize penetration techniques. It is between the access point and the virtual network. The box will have ethereal, and snort running on SUSE Linux. 35
  • 36. 3.1.21 Virtualnet (virtual network host) The machine is running Ubuntu Linux with Xen. Xen is an open source virtual machine solution. 3.1.21.1Virtual Machines There will be at least 3 virtual machines running concurrently to provide simulation reality to the system. 3.1.21.1.1Virtual Machines 1 This virtual machine will be running a mail server, website (for defacing and trophy), Ssh, and a programming environment. It is a target for attackers to obtain and provides them with a pseudo goal or item which signifies success. 3.1.21.1.2Virtual Machines 2 This virtual machine will have a tar pit running, in order to grab packets sent to machines not on the network virtual. This increases difficulty of obtaining access to the real network behind the virtual network, and decreases security risks from more novice level attackers. 3.1.21.1.3Virtual Machines 3 This virtual machine will be running honeyD, which is honeypot software. It is designed to act as more than one computer, and can run scripts that mimic 36
  • 37. machines. It is used to confuse attackers from realizing they are on a virtual network. Other Design Options The following describes other designs the team decided against implementing. 3.1.22 7of9 as a computer The original goal was to have 7of9 function as a wireless access card generating a wireless network from a computer. However, due to machine constraints and the nature of the requirement that 7of9 an open access point, the team decided a cheaper and easier solution would be using a proprietary solution (an off the shelf wireless access point). The team could have added the 7of9 access point to the SHARK unit, but this would have required the addition of 2 more wireless cards to the machine, resulting in interference due to four wireless cards. 3.1.23 No NAT on the analysis network The original goal was to have every machine on the analysis network connect directly to the internet; but, due to security, this was frowned upon. Also, a network address translation (NAT) system allows for easy implementation of a firewall. 37
  • 38. Implementation Process Description The process for implementing SHARK involved multiple steps. Each component of the SHARK system involved multiple aspects and pieces that needed to be considered. The hardware for the most part were already set up, there was one network card added to the Shark machine, all other hardware was set up. The main implementation involved the software configurations. 3.1.24 SHARK Once the software packages were decided upon for SHARK, the team began installation of those packages onto the SHARK computer. Once a package was installed, we updated that piece of software until it was the most recent version of the software available. After the software packages are installed, the next step is to begin to configure the software properly for use on the system. During configuration, the team realized that it is not possible to use two separate wireless cards on the SHARK box because the software was not able to handle them both. This caused the team to use a wireless access point instead of a wireless card to create the wireless network. Once the team received the wireless access point, the team was able to connect it into the system. After this, the team created the wireless network and the ability to maintain the 5 levels of security. The next component implemented was the traffic generator. The team wrote a program that would generate continuous ARP packets onto the wireless network. Once the traffic generator was set up, SHARK was able capture traffic on the system. The team then implemented the traffic analysis and ran it on captured packets to verify the correctness of generated traffic. Once these 38
  • 39. pieces are verified, we installed SHARK module in a closet in Coover Hall and begin student testing. Once the student testing is complete and results returned, project is considered success or failure based on those results. 3.1.25 Virtual Net The software was decided on due to ease of access to support, and documentation. The team first created the base machine that manages all other virtual machines. This machine then had to be configured before virtual machine images were generated. Images were made for each virtual machine by setting up a dedicated area on the hard disk containing its OS, its directories and a separate kernel. These images were added to Xen’s boot sequence. The machines share the same Ethernet card with each machine having its own virtual card that mapped to the real card. Then by internal routing the traffic is routed between the machines. A virtual machine manager that manages system calls is loaded when the base machine boots. Finally, the interface to the base machine needed to be configured as a router to forward the appropriate traffic to every virtual machine. 3.1.26 Analysis Once the software packages were decided upon for the analysis machine, we began installation. Once the installation was complete, we updated the software to their most recent versions. After configuring the software to work with the local computer’s configuration, the computer is now ready to be connected to the SHARK network. The next step was to write a program in C/C++ to analyze the 39
  • 40. traffic captured on SHARK to determine statistics in the traffic. The software parses a text file that has the traffic written to it from SHARK looking for key words such as “ARP” to identify the types of packets received. It then makes note of the address of the computer that sent the packet, received the packet, and the time the packet was sent. This information is used to compile results saying what types of packets were detected, the computer that generated those packets, how long it took for an attacker to break the network from the first packet detected to their success, and the identity of the attacker by comparing his computer address to the information logged when the attacker registered on the box. After the analysis program is finished, it was installed on the analysis machine and run on each file of capture traffic to provide analysis results to test the machines, analyze the attackers, and provide additional end product results. Testing Approach Two testing methods were used on this product. The first was a lab test of the system; the second will be a field test of the system through a competition. 3.1.27 Lab Test In the lab test, team members varied the levels of security and tested the ability to penetrate the wireless access point, access the virtual network, and the web. This test is mainly confirming that the software networks work together as 40
  • 41. expected. The testing occurred in the lab where the system was developed. The team members were be given a checklist of conditions to check and report whether the system gave the correct output. Team member check list: • Verified that each security level was active − Team members attempt to connect to the access point with security measures running − Team members attempted to connect without authentication. − If blocked from accessing the machine, then testing successful. • Verify that laptops can connect to the machine with the correct authentication − Team members attempted to connect to access point with security measures running − Team members attempt to connect with authentication − If allowed access to the machine, than testing successful. • Verify that traffic generator is connecting to the access point and generating an ARP packet − Team members connect to the SHARK machine − Team members captures traffic on the SHARK network − If ARP packets are detected, then testing successful. • Verify that 7of9 connects allows a connection to the internet. − Team members connect to 7of9 access point. 41
  • 42. − If team members are allowed to access the internet, testing successful. • Verify that login/registration page stores the user. − Team members connect to SHARK machine with open security − Team members register/log on to machine − If allowed access to machine, testing part 1 successful − If machine recorded user information, part 2 sucessful. • Verify analysis software − Once software is complete run on traffic sample − Compare results of software to actual file − Verify that results match/make sense • Verify that Xen is operating − Net scan to see if virtual machines are detected − Send traffic on the virtual network to check if they are absorbed by tar pit − Attempt some known security exploits − If machines detected and traffic absorbed, successful 3.1.28 Field Test The field test (contest) will take place while the access points are located in the closet of Coover Hall. Students would be able to register and then participate; all that would be required would be that they be in range of the access point. All packets will be captured and web access will be restricted for this test, so that the security is increased, and the virtual network is tested. The data will verify the 42
  • 43. functionality of the server, while the recorded packets will serve as a record and means of analysis for the results. Students attempting to break in will use any method that they know to try and gain access to the wireless network. Students are expected to complete the open access point and possibly break the WEP encryption security. Project will be considered success if students are able to complete these steps successfully. Due to lack of time and computing power of student resources, it is unlikely for students to get any farther than WEP encryption. • Test that students can register − Students access SHARK − Students are able to register, than successful. • Test if students can break WEP encryption − Students are able to break WEP encryption − Students registers at WEP, then successful. • Test if students can break WPA encryption − Students are able to break WPA encryption − Students registers at WPA, then successful. • Test if students can break rotating WEP encryption − Students are able to break WEP encryption − Students registers at rotating WEP, then successful. • Test if students can break RADIUS encryption − Students are able to break RADIUS encryption − Students registers at RADIUS, then successful. 43
  • 44. End Product Results The following section contains details about the end product results. 3.1.29 Lab Testing Lab testing results when according to plan. • Open Access − Able to log on to system − Log file showed user information such as user name, password, IP address. − Successful • WEP Encryption − Effectively blocked un-authenticated users. − Unable to gain access to the system without key − Using authentication key, able to gain access to the system and register − Successful • WPA Encryption − Effectively blocked un-authenticated users. − Unable to gain access to the system without the key − Using authentication key, able to gain access to the system and register − Successful • Rotating WEP − Effectively blocked un-authenticated users. 44
  • 45. − Unable to gain access to the system without the key − Using authentication key, able to gain access to the system and register − Successful • Radius − Effectively blocked un-authenticated users. − Unable to gain access to the system without the key − Using authentication key, able to gain access to the system and register − Successful • Verify Traffic Generator − Traffic Generator complete. • Verify 7of9 − Access point installed. • Verify Analysis Software − Software completed. • Verify Xen Software − Software configured. 3.1.30 Field Testing • Open Access − Accessable, works correctly. • WEP Encryption − Works correctly 45
  • 46. • WPA Encryption − Works correctly. • Rotating WEP − Works correctly. • Radius − Works correctly, required for operation of captive portal. Project End Results At the current time the project is completely implemented. 3.1.31 SHARK Currently, the SHARK node has the wireless access point and cards installed and all software is configured. It generates a wireless network with all levels of security. The traffic generator and analysis program have been installed. The SHARK node is housed in Coover Hall. 3.1.32 7of9 Currently, the 7of9 access point is plugged into the system and works. 3.1.33 Analysis Currently, our analysis machines have all of the software packages installed and configured properly. 3.1.34 Virtual Machines Currently our virtual machine has Xen installed and configured properly. 46
  • 47. 4 Resources This section contains tables and discussion about the resources used in the SHARK project. Estimated Resources In this section, the detail out the updated plans for time management and cost performance. The final time commitments for project and time schedules accurately reflect the amount of effort and financial resources that are needed to complete this SHARK project. This section will cover resources and the schedule the team will follow. Personal effort requirements Below are the tables that outline individual team member effort placed on a single task, the overall amount of time they spent and the total time spent. There are three tables A-C; they are ordered from earliest estimates to the accurate time commitments of each team member. 47
  • 48. Table A contains the old estimates of required personal effort broken down by team member. Table A: Old Estimate of Personal Effort Table A: Old Estimate of Personal Effort (in hours) Personnel Task Task Task Task Task Task Task Task Names 1 2 3 4 5 6 7 8 Total Ross, Jessica 20 25 25 50 15 30 10 30 205 Eilers, Stephen 20 30 20 60 15 30 10 30 215 Murphy, Jon 20 25 25 55 15 30 10 30 210 Pease, Alex 15 35 20 65 15 30 10 30 220 Total 75 115 90 230 60 120 40 120 850 48
  • 49. Table B contains the design phase estimates of team member hours. Table B: Design Phase Estimate of Personal Effort Table B: Design Phase Estimate of Personal Effort (in hours) Personnel Task Task Task Task Task Task Task Task Names 1 2 3 4 5 6 7 8 Total Ross, Jessica 20 25 25 55 15 30 10 30 210 Eilers, Stephen 20 30 20 65 15 30 10 30 220 Murphy, Jon 20 25 25 65 15 30 10 30 220 Pease, Alex 15 35 20 75 15 30 10 30 230 Total 75 115 90 260 60 120 40 120 880 49
  • 50. Table C contains the final number of team member hours. Table C: Final Personal Effort Table C: Final Personal Effort (in hours) Personnel Task Task Task Task Task Task Task Task Names 1 2 3 4 5 6 7 8 Total Ross, Jessica 14 20 12 44 18 14 12 18 152 Eilers, Stephen 16 21 16 60 16 12 8 12 161 Murphy, Jon 12 18 25 51 12 18 10 11 157 Pease, Alex 18 23 24 75 10 6 9 17 182 Total 60 82 77 230 56 50 39 58 652 Other resource requirements Below are some tables that outline the other resources used by the team members, the overall cost, or whether it was donated. The three tables D through F are ordered from earliest estimates to the accurate resources used. 50
  • 51. Table D contains a list of the old other resource requirements for this project. Table D: Old Other Resources Table D: Old Other Resources Item Other Team Hours Hours Cost Parts and Materials: a. Computers setup 25 0 $75.00 1. 2 Wireless Cards $75.00 2. 4 Computers Donated b. Poster printing 20 0 $20.00 Total 45 0 $95.00 51
  • 52. Table E contains a list of the revised other resource requirements for this project. Table E: Revised Other Resources Table E: Revised Other Resources Item Cost Parts and Materials: Wireless AP $30.00 Switch (2) $50.00 Router $25.00 Computers Donated b. Poster $15.00 Total $120.00 52
  • 53. Table F contains a list of the final other resource requirements for this project. The additional server space refers to the physical location of the servers (Marston 406). The bandwidth row refers to the bandwidth used by the web server, and the developer Wiki page. The server uses Iowa State University’s bandwidth. Table F: Final Other Resources Table F: Final Other Resources Item Cost Parts and Materials: Wireless AP $62.99 hubs (2) Donated Router $39.99 Wireless Card(2) 49.99/Donated Computers (4) Donated Server Space Donated Bandwidth Donated Software Open Source Poster $24.52 Total $177.59 Financial requirement This section covers the financial cost the team incurred while implementing and designing the project. The three tables G through I appear oldest to newest. The final costs with labor of this project are less then the original estimate of this project. The costs without accounting for labor are higher then the original estimates. Please refer to tables G and I to compare. 53
  • 54. Table G contains an old estimate of the financial requirements for the project. Table G: Old Financial Requirements Table G: Old Financial Requirements Item Without Labor With Labor Parts and Materials: a. Computer $75.00 $75.00 c. Poster printing $20.00 $20.00 Subtotal $95.00 $95.00 Labor at $10.50 a. Ross, Jessica $2152.50 b. Eilers, Stephen $2257.50 c. Murphy, Jon $2205.00 d. Pease, Alex $2310.00 Subtotal $8925.00 Total 95.00 $9020.00 54
  • 55. Table H contains the new estimates of the financial requirements for the project. Table H: Revised Financial Requirements Table H: Revised Financial Requirements Item Without Labor With Labor Parts and Materials: $105.00 $105.00 Poster printing $15.00 $15.00 Subtotal $120.00 $120.00 Labor at $10.50 a. Ross, Jessica $2205.00 b. Eilers, Stephen $2310.00 c. Murphy, Jon $2310.00 d. Pease, Alex $2415.00 Subtotal $9240.00 Total $120.00 $9375.00 55
  • 56. Table I contains the final financial requirements for this project. Table I: Final Financial Requirements Table I: Final Financial Requirements Item Without Labor With Labor Parts and Materials: 152.97 152.97 a. Computer Donated Donated c. Poster Expenses $24.52 $24.52 Subtotal $177.59 $177.59 Labor at $10.50 a. Ross, Jessica 152 hours $1560.00 b. Eilers, Stephen 161 hours $1690.50 c. Murphy, Jon 157 hours $1648.50 d. Pease, Alex 182 hours $1911.00 Subtotal $6810.00 Total $177.59 $6987.59 56
  • 57. 5 Schedule This section contains a visual of the SHARK team’s final revised schedule for Spring 2007 (see Figure 5). The schedule has changed because implementation of SHARK took longer than originally estimated. This has put the team behind in testing. 57
  • 58. 58 Figure 5: This figure shows a graphical representation of the schedule.
  • 59. 6 Closure materials In this section we will discuss the closure materials for this final report document, including the future of the project and lessons learned during the course of the project. Project Evaluation Below is a table of our deliverable milestones and their respective successes. Table J: Deliverables Evaluation Deliverable Degree of Explanation Success Project Plan Fully Met When designing the project plan and creating the scope, the team concluded on a design that fit the customer’s requests as well as the design constraints that we had to overcome. Project Poster Partially The poster went well together in its design and Met completion. The team was able to convey the required information to those who chose to read it carefully. Design Report Fully Met The report met the expectations of the group members. Final Report Partially Our team was successful in compiling the final Met report. Product Fully Met The team was able to test our system in a closed Demonstration space, which allowed the team to confirm theproject’s success. Weekly Reports Partially Most of the weekly reports were completed, but 59
  • 60. Met the detail and accuracy of the reports were latent. SHARK Testing Partially The team was unable to fully test the SHARK Met system, due to the time constraints of the testing. The testing requires 8 weeks; there was not sufficient time left to fully run the test during the semester. It will be completed during Fall 2007 SHARK Exceeded The SHARK implementation met and exceeded Implementation the client’s expectations of how SHARK should be designed. The team would classify the project as Fully Met as a whole. There were some areas in which we were unable to meet the client’s full goals, but in the end the client was satisfied with the project’s successes. Commercialization The SHARK project is solely as a research project and has little commercialization. There is nothing “marketable” about SHARK except the statistical data results that are received. It could be perceived that a security company might use SHARK to evaluate how their particular wireless system is compromised. If this product were able to be commercialized, its production cost would be around $500 dollars. The street price would have to be upwards of $1,500 due to research costs and technology integration. Another problem with this is that the statistical data is subject to interpretation to what the researchers perceive. 60
  • 61. Additional Work A few features that would help enhance the effectiveness of the SHARK project would include customization of the statistical data that is given to the researchers. This would help categorize the information into the format that the researchers would like to see and would make it more automated. Another feature that would help would be the added generation of traffic for users to get a better simulated environment of what a real access point would be. Lessons Learned In this section various lessons that were learned and the knowledge gained during the SHARK project will be discussed. 6.1.1 What went well The group’s cohesion was good through the duration of the project. The team was also able to meet most of the guidelines that were set in place by the client. 6.1.2 What did not go well There were issues with some of the software not being configured properly, which caused interruptions to the development laboratory’s internet connection as well as to the project itself. It took quite a while to find and fix the problem. Additionally, a lot of work had to be redone due to the previous SHARK team’s poor documentation. 6.1.3 What technical knowledge was gained The team learned quite a bit about wireless security and Unix-like operating systems. There was much knowledge gained in the realm of wireless security, 61
  • 62. including how WEP and WPA are easily compromised by some of the more industrious students at Iowa State. 6.1.4 What non-technical knowledge was gained The team learned some interpersonal skills about communication and functioning as a group. There were times where information that should have been conveyed wasn’t, but overall we were successful in being able to communicate with one another. The team also gained valuable insight into the type of people who are attempting to use our project. 6.1.5 What would you do differently if you could do it over again The team would redesign parts of the project to make it more cost effective and easier to manage. This would make the developer rely purely on the analysis instead of the initial setup of the machines. Risk and management This section will be dedicated to the risks that were uncovered during our project and how the team overcame them or found a workaround. Anticipated potential risks and planned management The biggest risk that we foresaw was the potential for a user to hack into the SHARK system. It is understood that attackers are attempting malicious attacks on parts of the system, since that is the point of SHARK. However, it is important to make sure that the user doesn’t actually compromise the system in order to maintain the integrity of the research data. 62
  • 63. . Anticipated risks encountered and success in management The team knew that allowing the students to attempt to hack into the SHARK wireless network would be a risk, but the team decided that our software system was robust enough to handle most of the techniques that a user might attempt. The software used in this system is open source and therefore actively improved upon by developers concerned about this issue. 6.1.6 Unanticipated risks encountered, attempts to manage and success One risk encountered was creating a DHCP server on Iowa State University’s main network. The team accidentally created a DHCP broadcasting server that interfered with Iowa State’s DHCP server. In other words, SHARK’s DHCP server told other computers on campus that it was the main server rather than Iowa State University’s DHCP server. This confused the computers and subsequently took them off the Internet. This was unexpected but fixed quickly. Project Team Information This section contains project team contact information. 6.1.7 Client Information Steve F. Russell, Ph.D., P.E. Department of Electrical and Computer Engineering 207 Nuclear Engineering Iowa State University Ames, Iowa 50011 63
  • 64. 515-294-1273 sfr@iastate.edu 6.1.8 Faculty Advisor and Graduate Assistant Steve F. Russell, Ph.D., P.E. Department of Electrical and Computer Engineering 207 Nuclear Engineering Iowa State University Ames, Iowa 50011 515-294-1273 sfr@iastate.edu Adrienne Huffman Electrical and Computer Engineering 4611 Mortensen Rd Ames, IA 50011 adnihuff@iastate.edu 6.1.9 Student Team Information Alex Pease Computer Engineering 320 S 4TH ST #2 64
  • 65. Ames, IA 50010 apease@iastate.edu Jon Murphy Computer Engineering 2519 Chamberlain St #415 Ames, IA 50014 jwmurph@iastate.edu Steve Eilers Computer Engineering 125 N Hyland Ames, IA 50014 seilers@iastate.edu Jessica Ross Computer Engineering/Mathematics 302 Hickory Dr Apt #7 Ames, IA 50014 65
  • 66. rossjr@iastate.edu Closing summary The SHARK team created a system of wireless access points that seems like an actual real life network to be used as a hacking sandbox for educational purposes. In addition to deploying this system, the SHARK team provided enough documentation about the project to allow other researchers or future senior design teams to expand upon this project. To test the SHARK system, there will be a contest held in Fall 2007. It will consist of participants attempting to break through various levels of security. This contest will provide data on students’ ability to engage in hacking as well as data for breaking through various levels of security. 66
  • 67. 67