Position Aware Firewall

Transcription

1 Position Aware Firewall ELEC Progress Report #2 University of Victoria March 3, 2008 Students Adam Verigin - averigin@uvic.ca Sean Boyd - seanboyd@uvic.ca Steve Gillan - swgillan@gmail.com Tyler Price - taprice@engr.uvic.ca Group Number 10 Supervisors Stephen W. Neville Michael McGuire

2 Table of Contents Table of Contents i List of Figures ii 1 Project Summary 1 2 Equipment Acquisition 2 3 Gathering Signal Strength Information 3 4 Positioning Testing Link Verification Orientation Variance Graphical Interface Design Goal Application Design Progress Made Remaining Work Future Unplanned Work Firewalling Possible Solutions Website And Other Documentation 10

3 List of Figures 7.1 Inspired Solutions Company Logo Postition Aware Firewall System Diagram

4 1. Project Summary The goal of this project is to design a Position Aware Firewall system that will be able to track the position of an indoor wireless user and grant, limit or deny access depending on the logical restrictions associated with the user s location within the physical domain. Restricting access based on a physical location allows a number of cyber-security issues to be reduced to ones of physical security, which is more easily enforced and regulated. Such an approach is obviously limited by the ability to accurately resolve user positions, so the project will focus on two core areas: 1. Developing the basic function of the overall system 2. Investigating the density of wireless access points (WAP) required to resolve a user s position down to reasonable levels (i.e., within a given room) This project has many applications in real-world systems. A typical application is that this system would deny users in a parking lot outside of a business from using the business wireless connection. Another application would be to restrict students sitting in a lecture to only view content from that course s webpage. One last example would be that a company hosting guests in a conference room would be able to grant them internet privileges, but deny them access to any proprietary information. All these situations occur on a frequent basis in many locations, thus evidencing the marketability of this product.

5 2. Equipment Acquisition In order to achieve accurate position aware firewalling, a number of wireless access points (WAP s) were needed. These WAP s needed to be able to run some form of Linux, perform basic routing, and allow for simple customization. After considering several routers, the Linksys WRT54GL was chosen as the best option due to its ability to run a number of firmware distributions designed including OpenWrt, DD-WRT, and others. Because accuracy is a critical aspect of the project, it was desirable to acquire approximately 10 routers in order ascertain how densely the routers need to be distributed in order to gain usable position resolution. The routers were purchased at Netlink Computers in Vancouver for $63.98 each and picked up to avoid shipping charges. Other necessary equipment included a network switch, CAT5 cabling, and a Linux-based PC to act as a server. All of this equipment has been loaned to the team by the InSPiRe Lab, project supervisors, or the team members themselves.

6 3. Gathering Signal Strength Information The process of gathering signal strength information proved to be much more challenging than anticipated. Firstly, several different firmwares were considered and tested. The list included OpenWrt WhiteRussian, OpenWrt Kamikaze (newer than WhiteRussian) and DD-WRT, which is based upon the OpenWrt package. The main advantage WhiteRussian and DD-WRT held over Kamikaze was that they had a web interface for configuring the router. This issue, while not critical, drastically facilitated the configuration of routers. However, DD-WRT is not, by default, able to store changes outside of the router s configuration into static memory, and enabling such a functionality is quite difficult. This was an issue for this project because the routers needed to run custom software files, which, with DD-WRT, it would be possible to load and run, but if the router were to be rebooted, then the software would be lost since it would be stored in volatile memory. Thus, weighing the options, OpenWrt WhiteRussian was selected as the best operating firmware on which to develop this system, although if time permits, it would be desirable to use DD-WRT and automate the process of committing files to static memory since it has the nicest web interface of all the firmwares tested. In order to make use of these routers for position-aware firewalling, they needed to be able to gather signal strength information. Upon initial observation, it appeared that the WL package, available for all 3 firmwares, would provide the functions needed. The most appealing of these was a scan function that claimed to return Received Signal Strength Information (RSSI) measurements. However, this function was realized to be of no use for gathering client signal strength information as if would only return information for other WAP s; not for clients. Upon this discovery, an alternative method was conceived. This new method would be to use wl assoclist, which would return a list of MAC addresses associated with the measuring WAP, and then use wl rssi macaddress for each associated client to gather an RSSI reading for each. This was possible and resulted in the first measured client signal strengths. However, this method fell short because, in order to gather RSSI measurements for a client, it had to be associated with the measuring WAP, meaning RSSI measurements could only

7 3. Gathering Signal Strength Information 4 be gathered for a client by one WAP. This was useless for position aware firewalling because each WAP needed to be able to gather readings for a given client so their position could be triangulated. Because of this, only two further options remained: create a protocol by which multiple WAP s would switch on and off in sequence so as to gather the readings, of somehow passively intercept packets using wireless routers in monitor mode on top of an existing network. Since implementing a protocol that would synchronize multiple routers in a manner that could disrupt client connections would be difficult and could have detestable side-effects, passive measurement options were sought out. Kismet, an layer 2 wireless network detector, sniffer, and intrusion detection system, emerged as the best possible means by which to gain such measurements. This system used a drone application installed upon one or more WAPs which would intercept packets, and a server application installed on a Linux machine which would localize the intercepted packets and compile the information they contain. Further, a client program could be run on the same machine as the server to take the information and display it in a basic graphical interface, making it easy to observe lists of APs and clients. Thus, as an initial test, the drone application was loaded onto a WAP running OpenWrt Kamikaze, and the server application was installed on an HP Pavillion dv6700 laptop running Ubuntu Upon a successful configuration of both applications, the server was able to connect to the drone and gather data and upon loading the client, a list of observable WAPs and clients was compiled. However, shortly after this achievement, it was observed that no signal strength information was displayed. Upon further investigation, it turned out that Kismet was not able to gather per-packet RSSI from the Broadcom chipset used in the test WAP. Further research, however, lead to the discovery of the IEEE article, Positioning in the Home, written by James Salter, et. al. In this article, he explained that he had edited the Kismet source code so that he could collect per-packet signal strength information. Thus, the next step for progress was to contact him and inquire about what changes he had made. Thankfully, he was willing to send a customized OpenWrt build file with a set of patch files which summarized his changes to the Kismet source code. Further investigation of his changes yielded that he had changed one line of code to extract the signal strength information properly, and had created a protocol named NOMAD that allowed for a TCP client to connect to the Kismet server and receive

8 3. Gathering Signal Strength Information 5 signal strength information for every packet intercepted by the WAP. As a test, a Kismet server was established on one WRT54GL, and telnet was used to log in an initialize the NOMAD protocol. This returned a list including time stamps, source and destination MAC addresses, and signal levels. Next, the Kismet source code for the version running on the laptop was manually edited to apply the necessary changes for NOMAD, and this was also successfully tested. Finally, since the NOMAD protocol did not include an entry for the data s source, modifications were made to the NOMAD code so that this field was also reported, and a script was written to telnet into the Kismet server and log the retrieved data. Using this system, initial testing of the system was conducted. The most recent development regarding RSSI collection has been the writing of a C++ program to connect to the Kismet server and log it with the enhanced functionality of parsing the data and exporting it to a CSV file which can easily be imported into MATLAB. The main goal of this program is to automate the data collection process, and drastically shorten the analysis of the data as well. In the future, position calculation and MySQL logging will be added to this program, which will form the heart of the position aware firewall.

9 4. Positioning Testing 4.1 Link Verification Once the signal strength information has been collected, questions arose regarding the validity of these results. The main issue was whether the value being returned by the Kismet drones was the link between the client and the localized drone (which is desired) or if it just the signal strength value between the client and the broadcast AP. To help determine which scenario was occurring, a broadcast access point and a Kismet drone were placed in opposite corners of a room. The client, connected at the broadcast router, moved toward the Kismet router at an interval of 0.25 m. The expected result was to have a plot where the signal strength reported by the Kismet drone became stronger as a the distance from the client decreased, which will validate that the signal returned by the Kismet drone is a the link between it and the client. If the output would have been a constant line, or the signal was weaker as the distance between the drone and client became closer, it would appear that the RSSI values were being extracted from the packet between the broadcast router and client. From these tests, it was determined that the signal strength increased as the distance decreased, which validated the collected data. 4.2 Orientation Variance Initial results of the positioning measurement tests revealed that the RSSI values are highly affected by the orientation of the wireless user. This can be shown in the results taken at the same location, when rotated by 90 degrees. The non-similarity in the signal will provide a challenge in ensuring that the position calculation is able to negotiate between varying user orientation.

10 5. Graphical Interface 5.1 Design Goal A front-end application is being designed to allow a system administrator to set the physical locations of the drone WAPs and the areas that the access zones cover. Additionally the system administrator, or other system user, should be able to use the application to view the locations of each of the users connected to the wireless network that the drone WAPs are monitoring. 5.2 Application Design The application is currently being developed in Java in order to run on any one of the platforms we are using as part of the system. A simple graphical user interface is being constructed based on the Swing Application Framework, and Hibernate has been implemented for a robust database persistence layer. Interaction with the rest of the system is performed by the server making position calculations and writing the results to a MySQL database server. Time-stamped positions of users (relative to the floor plan coordinates) are written to the database by the position calculator, which are in turn read by the application. 5.3 Progress Made Currently the application is a basic framework for performing the initial setup of the system (not including initial training of the drones). This includes the following functionality: 1. Importing an image of the building s floor plan. 2. Placing the drone access points. 3. Drawing the physical access zones.

11 5.4 Remaining Work 8 4. Saving the setup to the database. The data model for storing the setup to the database has also been created, but work still remains on setting up the position calculator to access the database as well. 5.4 Remaining Work There are several tasks which are remaining before this application will be fully functional: 1. Fixing bugs: there is an error with database transactions in the persistence layer, and the floor plan image is not correctly saved. 2. User locations need to be displayed in real time. A thread needs to be created that constantly grabs the user data from the database and draws the locations on the floor plan. 3. Additional options need to be added for system setup so that the different access zones that are being drawn can be matched to specific rules in the firewall application. 5.5 Future Unplanned Work Unfortunately some of the functionality that would be ideal for this system cannot be completed due to time constraints. For this application to be fully deliverable with the entire system the following should be implemented: 1. Integration with training done for position measurements 2. Integration with firewall application for modifying and creating access rules. 3. Improving precision of drawing the access zones and drone WAPs.

12 6. Firewalling 6.1 Possible Solutions The firewall is being considered to reside on a separate machine that will be connected to the system over an Ethernet link, which will also be connected to the database. The reason for this is to simulate an existing firewall that will tie into the Positioning system. Possible challenges in tying in a firewall application is related to how the firewall will handle the position value calculated by the system. Two options are available for implementing a firewall application that will restrict access via a user s IP address or MAC address: 1. Alter an existing open source firewall application to query the database used by the position calculator and floor plan UI application to associate an IP address with a physical access zone. The difficulty with this option is learning the existing code well enough to make the necessary changes - many open source projects are fairly immature and lack documentation and organization or have matured to a state where the code is large and difficult to maintain. 2. Program a thin layer on top of Iptables to match up IP addresses with rules based on the users location stored in the database. The request would then either be blocked or redirected to a default access denied page.

13 7. Website And Other Documentation The documentation for this project is well under way. Since the inception of this project, a online Wiki was created so that all team members could post any and all information related to the project. The framework for the final report has been created using the document preparation system, L A TEX. Information will be transfered from the Wiki to the final report document. The framework for the website is now under development. A simple, modern, and clean design is desired. The website will contain information regarding the project and team members will be included. All documents related to the project will be available for download. A number of diagrams have been created to include in both the website and final report. Examples of these graphics include a company logo, Figure 7.1, and a system diagram, Figure 7.2. Figure 7.1: Inspired Solutions Company Logo

14 7. Website And Other Documentation 11 Figure 7.2: Postition Aware Firewall System Diagram