Detecting Anonymous Proxy Usage Final Report

7.6 Further System Tests

The first run resulted in an error showing up, and as the system was not monitored, the exact time of the error was not discovered; the error can be seen in Figure .

Figure - Pcap error

After researching the error and debugging through the code it was found that if the program was not getting network packets it would cause the error. This meant if the network dropped for a certain period of time the program would crash. This unfortunately was not ideal and a solution for this was sought. To fix this error a ‘try’ and ‘continue’, was added into the code surrounding the ‘(header, packet) = cap.next() line. If the network was not receiving any packets it would continue to look for them without crashing the program. Once this had been implemented it could then be tested to make sure it was working correctly. A test was carried out, once the system was running, the network connection was stopped. Previously the system would crash, however now the system continues to search for the network packets, this meant the previous test could now be carried out again.

The test was resumed and the program was left running for 24 hours. The system was still running after the 24 hours, with no results printed on the console. This validated it was running correctly and that there were no false positive results noted within the time allocated.

Another error noted when testing the system was when the system was being closed while it was still running. Unfortunately due to the console closing down at the exact time, a preview of the error could not be captured. This error did not affect the log file or the system; however a more reliable way to close the program would be ideal. One solution would be to give the network administrator an option to press ‘esc’ if they want to close the system, this should close down the system properly without any errors showing. Another option was to control the error when the system was closed, as the user can just press ‘x’ to close the system this was a more feasible plan. Therefore a ‘keyboardInterrupt’ exception was used in the main function.

The final test that was performed on the system was to determine if the system could perform as it should when there are many different proxies being used at once on the system. To do this test, firstly all 3 of the proxies were opened up along with the Tor Browser. The program then was started, to monitor the network packets. In each of the proxies, the website ‘www.guardian.co.uk’ was opened up and used for five minutes. Figure shows a snippet of the data that was printed to the console, as can be seen each of the different proxies and the onion routing application’s usage was detected correctly without any problems occurring in the system.

Figure - Testing every proxy at once with continuous usage

When taking a closer look at the log created by the system, each of the packets was printed out successfully and in order. A snippet of each of the packets can be seen in Figure , Figure , Figure and Figure .

Figure - CGI Proxy continuous use

Figure - PHPProxy continuous use

Figure - Glype continuous use

Figure - Onion routing continuous use

As can be seen in the snippets, the date and time is beside the proxy name, this shows the exact time the proxy is found and printed to the file. Between the different proxies, there are only milliseconds of a difference; this is the same throughout the log file. Appendix B contains a more thorough sample of the log file created when all the proxies were being run, due to the logs size, only a quarter of the file was included. The most notable part of the log file is the time difference between each of the proxies, this information is very useful to a network administrator as they know exactly when the proxy was being used and which proxy it was. They can also see each of the IP’s within the packet, and therefore can make the decision if it is a threat to the networks security or allow its usage.

8. Evaluation & Reflection

One of the main aims of the project was to firstly examine the packets in the network to see how each of the different packets looked and what was contained therein. Once a good grasp of the data in the packets was obtained, the proxies would then be used to compare the difference. Any noticeable difference contained therein could then be used to determine if a proxy was being used and what type of proxy it was. This was successfully done in four out of the five tests, with the SSL CGI proxy being the only downfall. Again the program didn’t have a 100% success rate in determining the Tor Browser, however the differences in the network packets was noticeable in most of them. This criterion in the packets was put into regex strings to be compared with each inbound and outbound packet, in turn successfully determining the different proxies.

When the project was first started there was a need for a system that would be able to detect the use of anonymous proxies, security is a major field in Information Technology and the sector is increasing at a fast rate. This system fills that need, it can successfully detect Glype, PHPProxy, Unsecure CGI proxy and the Tor Browser which in turn provides a more stable and secure environment for the company/organisation to perform its everyday tasks. Overall the project would be very useful to a network administrator in terms of monitoring the network packets to determine if there is a proxy in use or if the Tor browser is in use. This system, although it doesn’t pick up every single proxy, would be an important system to any company that has high security measures.

The system was hoped to have 100% accuracy in detecting anonymous proxies. This however could not be achieved as the data travelling through a SSL proxy or pages that use ‘https’ on Tor generally use port 443, and thus the data in the network packets was encrypted. The system however did achieve 100% accuracy when detecting the Glype, PHPProxy and the unsecure CGI proxy. Also in testing it had 66.67% accuracy in finding the Tor browser.