Exploring Proxy Detection Methodology

Exploring Proxy Detection Methodology Mandeep Pannu Department of Computer Science and Information Technology KPU Surrey, Canada [email protected]

Bob Gill

Robert Bird

Department of Electrical Faculty of Engineering and and Computer Engineering Computing BCIT Coventry University Burnaby, Canada Coventry, UK [email protected] [email protected]

Abstract—Under most circumstances, cyber criminals will commit fraudulent transactions using proxy services which hide their real IP address and physical location. This is done in an effort to avoid being tracked and prosecuted by law enforcement agencies. This paper presents the investigation of a proxy detection methodology and efforts to implement such technology into a business solution with the sole purpose of eliminating the majority of fraudulent transaction attempts. The approach, described in identifies multiple proxy connectivity methods, and implements a multi-tiered detection technique. The result of the experiments demonstrates that the proxy methodology improves business security by identifying users who are utilizing proxies and to collect data that prevents potentially fraudulent activities. Keywords—fraud prevention; proxy detection; security

I. INTRODUCTION The detection and protection against fraud have become of utmost importance in modern society. With the rise of online financial and e-commerce services, a new class of criminal has surfaced. When we use any Internet-related application or service, we become potential targets for cyber criminals. Cyber criminals utilize techniques such as social engineering, phishing, and scamming to exploit system vulnerabilities for personal gain. They could act on our behalf to take our valuable assets, or use our privileges or rights without our knowledge. Concealing a person’s true identity and location on the Internet can be done by the usage of proxy or anonymity services. Cyber criminals commit fraudulent transactions by using proxy services to hide their real internet protocol (IP) address and physical location, in order to avoid being tracked and prosecuted by law enforcement agencies. Thus, having the ability to detect proxy connections and prevent fraudulent transactions becomes paramount. We are proposing to devise and present a proxy detection methodology to protect businesses, as well as their end users, against electronic commerce (e-commerce) fraud. Knowledge gained from currently available detection methods, underlying technology, and methods of experimentation were all thoroughly considered and utilized. This proposed proxy detection methodology checks for cyber criminals who access the website and/or web application for the possibility of proxy usage and perform necessary action before cyber criminals carry out fraudulent activities.

Kai Yang

Ben Farrel

Department of Computer Science and Information Technology KPU Surrey, Canada [email protected]

Department of Computer Science and Information Technology KPU Surrey, Canada [email protected]

This paper identifies different proxy connectivity methods, in order to develop a multi-tiered proxy detection module, and evaluate the implementation of the module in terms of cost and effectiveness. Tests are completed using different types of devices and platforms, such as desktops, laptops (Windows), and mobile devices (Android). We also test the module using computers connected through home networks, work networks, and mobile networks. The results of the experiments indicate that the proxy detection module improves business security by successfully identifying proxy users. II. BACKGROUND In the literature about information technology, the term “proxy” is also referred to as a “Stepping Stone” [1]. A proxy is software that resides on a server or node, and has the purpose of mediating access between the client’s machine and the destination server. When an application generates a request for a particular resource, the request is relayed via the demarcated proxy server. Once the proxy server receives the request, it analyzes the said request in order to determine the desired resource accompanied by its designated server or machine, as well as any additional information that it needs to relay, after which it connects and forwards the request to the target server and waits for a response. Upon receipt, it forwards the reply back to its end client [2]. Fig. 1. Example of a Typical Proxy

A. Proxy Types According to David Gourley and Brian Totty [3], proxy servers can be classified based on their functionality. 1) Child filter: Proxies can be utilized in order to block certain types of content such as adult material. 2) Document access controller: Access to certain resources can be restricted and/or granted to certain users based on authentication and authorization mechanisms.

3) Security firewall: Proxies are an effective technique of improving an enterprise’s security when deployed at the entry point of a given network segment, for the reason that they can be configured to filter certain types of application-layer protocols. 4) Web cache: Due to their caching ability, proxies can store frequently accessed content and when a request is received, instead of the given resource being retrieved from the server and sent to the end client, it is served directly to the end client from the local cache, thereby reducing congestion and bandwidth consumption. 5) Surrogate: This type of proxy is also termed as “reverse-proxy” or “server-accelerator”. It is generally utilized in order to reduce server-load caused by the generation of dynamic content. Henceforth, similar to the “web cache” type, it caches the content generated for a particular request, and if any client initiates the same request, it returns the content without re-soliciting the end server. 6) Content router: Based on the content-type and network conditions such as traffic flow/congestion, proxies can be employed to request specific content from servers which deal with the type of content requested and alleviate traffic from servers which are over-loaded. Moreover, as reflected by Michael Ligh et al. [4], proxies can also be categorized by the level of anonymity provided to the end user. 1) Transparent: It does not conceal the source IP address of the end user when requesting a particular resource. This is accomplished by adding a hypertext transfer protocol (HTTP) header to the request containing the IP address of the user’s machine. 2) Anonymous: This type of proxy does conceal the end user’s IP address, by omitting it from any request headers. On the other hand it still displays a header indicates that the end user is utilizing a proxy therefore this type of proxy is not very effective in providing complete anonymity. 3) Highly anonymous: This provides the highest level of anonymity due to the fact that it does not relay any information that might potentially identify a user or the datum that the aforementioned is utilizing a proxy service. B. Proxy Protocols Proxies utilize a diversity of protocols to support end client to proxy-server communication. As emphasized by the author Blake Adair [4], the most common protocols encompass: 1) HTTP: It is not explicitly designed for proxy communications. Nevertheless, when utilized by proxy based applications, it tolerates encrypted or unencrypted HTTPbased communications and also has the ability of allowing non-HTTP traffic to pass-through the proxy-server when the CONNECT functionality is employed. 2) Socket secure (SOCKS): There are currently 3 major SOCKS protocol version. SOCKS4 is especially designed for proxy-based applications. It will allow any transmission

control protocol (TCP) based traffic and can also resolve domain name system (DNS) addresses if the SOCKS4a extension is utilized. SOCKS5 is the extension of SOCKS4 protocol, and besides all functionality delivered by the previous version, it provides support for the user datagram protocol (UDP), IPv6, and additional client-based authentication. Additionally, there are proxies that implement virtual private network (VPN) techniques by creating a point-to-point or site-to-site connection that is secure with different type of protocol. Below are some examples. 1) Layer 2 tunneling protocol (L2TP): A standard protocol for tunneling L2 traffic over an IP network [5]. Its ability to carry almost any L2 data format over IP or other L3 networks makes it particularly useful. 2) OpenVPN: An open-source software application that implements VPN techniques for creating secure point-to-point or site-to-site connections in routed or bridged configurations and remote access facilities [6]. It uses a custom security protocol that utilizes secure sockets layer (SSL) and transport layer security (TLS) for key exchange. 3) Point-to-point tunneling protocol (PPTP): A method for implementing virtual private networks [7]. PPTP uses a control channel over TCP and a GRE tunnel operating to encapsulate point-to-point protocol (PPP) packets. 4) Secure socket tunneling protocol (SSTP): A form of VPN tunnel that provides a mechanism to transport PPP or L2TP traffic through an SSL 3.0 channel [8]. 5) Stealth: TorGuard has engineered special “stealth” connections that are guaranteed to bypass deep packet inspection (DPI) firewalls and provide “invisible” VPN access anywhere in the world [9]. C. HTTP Headers As aforementioned, transparent proxies do not conceal the end user’s IP address due to the fact that they embed a particular HTTP header in the request, which identifies the end user’s machine IP address. The HTTP header analysis technique relies on detecting the HTTP headers and determining the end user’s IP address based on their typical proxy header. This solution is quite common and has been deployed to prevent IP spoofing even in specialized security devices such as the CISCO IronPort Web Security Appliance [10]. The most frequently utilized headers that indicate the IP address of a proxy’s end client are: 1. VIA: As defined by RFC 2616 [11], this is a generalpurpose header which informs the destination server of the end-client’s IP address as well as the end-client of the origin server’s IP address. 2. X-FORWARDED-FOR: Standardized in 2014 and as defined by RFC 7239 [12]. This HTTP header field is a common method for identifying the originating IP address of a client connecting to a web server through a load balancer or HTTP proxy. The originating IP address can be obfuscated at

the server connect stage, and as such, this method is only reliable for trusted servers. The HTTP header analysis technique is effective as long as the type of proxy is transparent, and the proxy service adds the specific headers. However, if the proxy service omits the headers, or sends a header with a client IP address that does not match the actual client address, this detection method will fail. D. RBL Databases According to the author, John Brozycki, a real-time blacklist (RBL) identification check can be employed to detect whether a person is using a proxy or not [13]. RBLs were created in order to detect and prevent, in real-time, spamming activities such as the sending of unsolicited emails. Large volumes of email spam are often sent through proxy and VPN anonymity services, which end up getting blacklisted. However, RBLs are not limited to spam detection only, as they can also provide listings of hosts compromised via illegal third party exploits, worms, Trojans or any other form of malware. The providers of such services are: Spam and Open Relay Blocking System (SORBS), Spamhaus Project, Abuse Hosts Blocking List (ATLBL), and many more. The principle of determining if an IP address has been listed in a specific RBL, as described in Brozycki’s paper, is that the RBL needs to be queried, and if the reply contains a valid DNS record, this implies that the aforementioned IP address has been listed in the RBL’s database, therefore might represent a proxy. If the reply did not return a DNS record, then it has not been listed in the particular RBL, and it might not be a proxy. E. Limitations of Current Proxy Detection Techniques To the best of our knowledge, all proxy detection techniques have a plethora of advantages and disadvantages [13]. Currently, there is no single method that is capable of identifying all of the possible configurations for proxy connections. However, by using several detection schemes, we are able to greatly increase the effective detection rate. Several disadvantages exist that are outside of the control of the methodology tested in this report.  These testing methods cannot prevent an end user from performing modifications to their computer or network traffic with the intention of bypassing a configured detection method.  Not all businesses will have the resources to manage and maintain secure access to all of their systems. This is especially the case when portions of the company are outsourced.  Any tests that are heavily dependent on RBL databases might be prone to higher amounts of false positive results.  People are becoming highly protective of their data and privacy. Some users like to surf the internet in stealth so they can keep their browsing details private. Therefore,

not every user is willing to go online with their original IP address that can reveal their true identity and location. III. METHODOLOGY In order to analyze the incoming connections, we aim to build a detection methodology that functions similarly to the proxy detection demonstrated on WhatIsMyIPAddress [14]. This website uses a collection of six tests to determine if a user is behind a proxy or not. One of these tests is performed using a vast collection of internal testing data that has been formatted into an identification database. As this approach is out of the scope for this project, we will focus on the identification methods that can be completed without the need of database storage and access. The remaining five tests utilize packet header analysis, various scripting techniques, and routing analysis. We will analyze these tests, along with other known methods, to accomplish our goal. A. Research Method The primary ideology of this paper is hoping to introduce the readers into the world of e-commerce fraud and its related proxy-based operations. Hence, various references were chosen to deliver an adequate amount of knowledge to help readers to better understand the relevance of fraud prevention via proxy detection. Since our target audiences are mostly small to medium sized enterprises, their needs and capabilities are also taken into consideration. In order to provide complete anonymity to our test subjects, we have sanitized all the IP addresses and personal information before publication. B. Data Gathering Method For the purpose of data gathering, we have purchased a proxy service license through TorGuard [9]. The services provided by TorGuard allow us to test five different proxy connectivity types from hundreds of servers across the globe. We also utilized configurations that are available through free proxy lists, and alternative connectivity types such as mobile data connections and VPN tunnels. Once the proxy configurations were completed, connection attempts were made to our pre-configured server, which contains a packet logging application that documents each instance of connection and identifies specific proxy connections. For the best result, we gathered test data from different browsers. For Windows devices, the following browsers were used: Firefox 44, Chrome 47, Internet Explorer 11, and Opera 34. For Android devices, the following browsers were used: Chrome 47 and the default browser with Flash player installed. C. Design Detection and Prevention Method To identify a large number of configurable proxy connection types, several steps can be used. 1) Identify the public IP address of the target machine. 2) Implement a Flash element that runs client-side and quickly reports the true public IP. 3) If the target machine’s IP and the retrieved public IP match, then this test will return a value representing that no

proxy was detected. However, if the IP addresses do not match, we are able to confirm that a proxy is certainly in use. Utilizing this test, we are able to positively identify any simple proxy that has been configured through a browser, or users requesting access through a web-based proxy portal. Fig. 2. Detection Architecture

Additional tests can also be made to identify stealth connections such as universal VPN services, though only to a certain degree. In order to target VPN services that our first test would not identify, we can implement further checks. 1) Reverse DNS test: Attempt to confirm the IP of a target machine through an Internet Control Message Protocol (ICMP) request, then using the resulting DNS name, verify that the connection path resolves to the same target machine and not to a local IP or a different system entirely. 2) TOR network discovery test: Identifying the majority of TOR (an anonymity network) users can be accomplished by parsing the list of publicly available TOR exit nodes, then comparing the target machine's public IP against the list. 3) RBL database test: Compare the target machine's public IP against RBL database. However, this test might not be as reliable, due to possible false positive results. In addition, all connection IP addresses are required to send to a third party service in order to use RBL databases, which can present a potential security concern and higher service cost. IV. IMPLEMENTATION A. Proxy Connection Configuration Proxy connections can be configured in a multitude of fashions. These include configuring a simple redirection within a given browser that will send any web based traffic through the provided proxy service. Alternatively, a proxy connection can be configured as a new network device, and bridged to the existing network adapter to send packets through a designated server. A client side application can be used, such as TorGuard, to automate the creation and connection type through a designated secure proxy service. Finally, there are websites, such as kproxy.com and hide.me, that act as an anonymous proxy browser by creating a separate frame that connects to the requested sites through a designated server location. Manually configuring a proxy connection requires a fair amount of configuration information including the IP or DNS address, the port being used, the security option utilized for authentication, encryption type, valid user credentials, and the knowledge needed to bridge a network adapter to the configured proxy connection.

B. Method Development Given the accuracy of the aforementioned methods, we have opted to focus on developing a client-side Flash object that runs from the target machine, and reports the local connection IP for determining whether a proxy or VPN is in use. This implementation method has the benefit of quickly identifying any locally configured proxy connections, or webbased proxy portals. The IP detection of our module is accomplished by reporting the locally detected public IP, and comparing it against the IP address that initiated the connection to our test server. In order to ensure that the test will carry out, it is designed to verify that the user attempting to access the site is able to run the Flash object in their browser. The following steps were required to provision and install the aforementioned proxy detection module method: 1) Set up a web server capable of running Perl and PHP. 2) Adjust the parameters of the proxy detection module according to the environment variable of the server. 3) Copy the configured module over to the web server. 4) Create the necessary file and log that runs the module on the web server. 5) Integrate the Adobe Flash in small web format (SWF) file format on the webpage as an embedded object, so it will initiate the analysis process locally and remotely. Once the flash object runs on the client-side, it will return the local IP of the client to help identify whether a proxy had been used or not. Additional methodology checks can be implemented by altering the PHP code segments to include a reverse DNS test, TOR network discovery test, and RBL database test. In order to identify the effectiveness of our detection algorithm, we need to configure our test platform computers with various known proxy configurations, and then connect to our target server for validation. A debug logging function was added to the module, so we can validate correct identification of proxies and to further troubleshoot false positives if the situation requires it. Furthermore, a Wireshark packet capture was set up on the client-side, to monitor the connection and record the TCP/IP packet information to avoid data collection error and possible human error throughout the test. C. Provisioning We provisioned Windows and Android since these operating systems make up approximately 77.58% of Internet connected devices worldwide [16]. Due to the fact that iOS does not support flash, the module will not work on iOS devices. The module is configured to run on a website hosted on a dedicated server with Intel E3-1230v2 processor using Apache, MySQL, PHP, and CentOS - one of the best community-based Linux server distributions available today [17]. Since the test devices are configured to specifically use proxy connections, additional tests are conducted on our personal devices (desktop, laptop, and mobile) to better represent real-life situations of normal proxy users.

V. EXPERIMENT RESULTS AND EVALUATION In the first part of this particular investigation, we have determined that when proxy connections are created, specific characteristics that are unique to the proxy become identifiable during transmission of information, or during connection attempts. The information needed to identify a proxy can sometimes be as simple as reading the packet header containing connection type details, or checking for a matching forward and reverse DNS records, or comparing the client’s IP to a RBL database. Many methods exist to identify these traits and we intend to devise a detection logic that utilizes these tests with efficiency and accuracy.

1) Connection one is using a simple proxy configuration, as the initial IP address differs from the one identified through the proxy detection module. It also failed the reverse DNS test. 2) Connection two passes the test as both the public and detected IP are the same. There were no detections on the remaining two tests. 3) Connection three is a partial match. It fails the reverse DNS check, which can mean that they are using a misconfigured stealth VPN service, but it can also indicate that they were connecting through a mobile data service, or have disabled any ICMP requests on their firewall. 4) Connection four indicates that a TOR network connection was detected.

B. Proxy Detection Test

D. Result Evaluation

Proxy detection tests were performed in each development phase. Each test signified advancement in our detection algorithm. During testing, it was determined that the easiest method of integration is via PHP. Further testing was performed in an attempt to utilize HTML5; however, we were unable to create a non-PHP module that is capable of operating without requiring the user to install a plug-in or add-on extension. Through the utilization of both paid proxy services and manual configuration on several system platforms, we were able to positively identify proxy users of any manually configured proxy options, or web based portals. As previously described, VPN services were more difficult to identify in a meaningful way. These VPN services can potentially be detected using one of the following methods.  Personal computer fingerprinting and analysis of data stored in a database.

The proxy detection module performed its function with efficiency and effectiveness. The detection process time per client is approximately one millisecond (1 ms) plus the latency between the client and the server. The detection rate for SOCKS proxy connections is 100%. On the other hand, the detection rate for HTTP proxy connections is 94%, due to some devices disabled flash and scripts. The module is relatively straightforward to integrate into existing systems. As long as we are able to enforce the use of the Flash object on the browser, the detection of any locally configured proxy will be positively identified. Unfortunately we were unable to create a database-free methodology of identifying users utilizing advanced VPN services. Since VPN services bind to a locally created network device, the proxy detection module will find both the public IP and the discovered IP to be the same, which renders the proxy detection module ineffective. 78 out of 80 of the VPN services that we tested through TorGuard were positively identified with a reverse DNS test. However, the reverse DNS test is vulnerable to false positives. In order to filter out the false positives, we would need to create a complex mechanism to analyze the client machines' details. A detailed fingerprint can be created from any incoming connection containing information about the computer and location [18]. The fingerprint is used to identify information about the target machine, such as local machine's country codes, language options, and regional settings. This information can then be compared against the public IP address' country of origin.

A. Proxy Operations Analysis

 A client-side invasive application that monitors all web traffic and ensures a secure connection to the target site (this is used by a number of banks).  Advanced hardware technology that performs detailed packet inspection used in combination with tracking packets. C. Experiment Results Below are some of the proxy users logged by the proxy detection module, which demonstrates the result of our experiment. TABLE 1. SELECTEDA EXPERIMENT RESULTS Time Stamp 1/31/2016 7:11 1/31/2016 7:12 1/31/2016 15:41 1/31/2016 22:34

Connection IP 10.190.147.23 4 10.107.147.23 4 10.150.208.18 10.164.234.13 8

Discovered IP 10.190.22.1 76 10.107.147. 234 10.150.208. 18 10.164.234. 138 A

Proxy Detected

RDNS Failure

Tor Check

Yes

Yes

No

No

No

No

No

Yes

No

No

No

Yes

Out of 811 connection attempts from 50 devices.

Based on table 1, below are the interpretations of the data.

VI.

E-COMMERCE MODULE DESIGN AND IMPLEMENTATION

As modern society becomes more and more dependent on electronic transactions, data has become the most valuable asset for any businesses. Due to the inherently insecure nature of the Internet, businesses need to take into account that vulnerable web-based applications can be exploited by cybercriminals. Thus, it is crucial that businesses adopt e-commerce fraud prevention methods to safeguard their data.

A. Legal Implications Several legal implications need to be considered when designing the proxy detection module for e-commerce use. 1) Data protection: All processed data need to be secured by employing cryptographic technology, and stored in a secure environment where the information is not disclosed unless legally permitted. All parts of the module should provide boundary-checking and input validation. The module should also be capable of preventing attacks such as SQL injection, remote command execution, remote file inclusion, and information disclosure. 2) Customer privacy: An enterprise must adhere to the laws of the country they operate in. If the enterprise is based in the United Kingdom, it must provide an adequate layer of obscurity and control for its customers' identities, and only share such information with other parties in accordance with the laws and regulations. 3) Trademark laws: Violating any existing patents or trademarks could do serious damage to an enterprise's financial status or image. Therefore, it is advised that enterprises be aware of trademark laws. 4) Terms and conditions for the provided service: Customers must acknowledge a specific set of terms and conditions before using an enterprise' product or service. Due to the fact that the module utilizes resources on the end user's machine, it is important to obtain permission from the end user to avoid potential legal action from the end user. B. Module Integration All business operations that are conducted through existing solutions need to be modularized in such a way that the ordering process is clearly visible and can be altered to include the proxy detection module. During the user authentication stage, the module will check the validity of user's login or transaction attempts, and relay the detection results to the web server to determine the access permission. If needed, further analysis such as statistical analysis, data correlation, or intelligent agent approach can be performed since all detection results are logged. Given its construction, the module can be easily integrated with the majority of the web platforms and appended to a user authentication prompt. The cost to add the module to systems is low due to its simplicity. Once the module is integrated with the website, the module can actively monitor all transactions. The added security offered by the module benefits any website that stores confidential customer data. VII. CONCLUSION AND FURTHER RESEARCH A. Conclusion Proxy connections have many types and protocols, and with different software and technique configurations, it can be difficult to uncover a proxy connection. Although there are many existing methods to detect a proxy connection, all methods have their limitations. It is our goal to create a module that is capable of identifying as many proxy types as

possible. In this paper, we have investigated and tested different detection techniques, used the knowledge attained to design a multi-tiered proxy detection module, and explained how to implement the module in a business environment. With the overall detection rate of 97% and low integration cost, our proxy detection module is an effective and efficient solution for businesses to prevent fraudulent transactions from nonVPN proxy connections. B. Further Research This paper serves as an example and starting point for the study of proxy detection, and stands as a reference point for any interested researchers and organizations to explore this particular area. In the future, we would like the opportunity to improve the current detection technique. One of the features we would like to develop in future is the ability to encompass various data analysis techniques, which should improve the existing proxy detection methods. Another feature to be developed is seamless integration to any existing systems, where the module can be attached or removed from the system without impacting the overall quality and functionality of business operations. REFERENCES [1]

R.-M. Lin, Y.-C. Chou and K.-T. Chen, "Stepping Stone Detection at The Server Side," in 2011 IEEE Conference, Shangai, 2011, pp. 964-969. [2] D. Stuttard and M. Pinto, "The Web Application Hacker's Handbook: Finding and Exploiting Security Flaws," John Wiley & Sons, 2011, pp. 50. [3] D. Gourley and B. Totty, "Http: The Definitive Guide," O'Reilly Media, 2002, pp. 131-137. [4] M. Ligh, S. Adair, B. Hartstein and M. Richard, "Malware Analyst's Cookbook and DVD : Tools and Techniques for Fighting Malicious Code," John Wiley & Sons, 2010, pp. 11-15. [5] V. Rawat, R. Tio, S. Nanji and R. Verma, "Layer Two Tunneling Protocol (L2TP) over Frame Relay," February 2001, pp. 1-3. [Online]. Available: https://www.researchgate.net/publication/277825842_Layer_Two_Tunne ling_Protocol_L2TP_over_Frame_Relay. [6] Z. Hou, M. Xu, L. Zhu, L. Peng and B. Hu, "The Design and Realization of the Test Scheme OpenVPN, Based on Message Simulation," November 2013. [Online]. Available: https://www.researchgate.net/publication/266643218_The_Design_and_ Realization_of_the_Test_Scheme_OpenVPN_Based_on_Message_Simu lation. [7] K. Hamzeh, G. Pall, W. Verthein, J. Taarud, W. Little and G. Zorn, "Point-to-point tunneling protocol (PPTP)," December 1998. [Online]. Available: https://www.researchgate.net/publication/234818729_Pointto-point_tunneling_protocol_PPTP. [8] G. Trinder, "How SSTP based VPN connection works," Microsoft, January 2007. [Online]. Available: https://blogs.technet.microsoft.com/rrasblog/2007/01/10/how-sstp-basedvpn-connection-works. [9] TorGuard.net, "Anonymous VPN, Proxy & Anonymous Proxy Services," 2016. [Online]. Available: https://torguard.net. [10] P. Ružicka, "Deployment of Cisco IronPort Web Security Appliance," Cisco Expo, 2009, pp. 27-31. [11] R. Fielding, J. Gett S, J. Mogul, H. F. Nielsen, L. Masinter, P. J. Leach and T. Berners-lee, "RFC 2616: Hypertext Transfer Protocol HTTP/1.1," December 1998, pp. 145-169. [Online]. Available: https://www.researchgate.net/publication/242418693_RFC_2616_Hypert ext_Transfer_Protocol_-_HTTP11. [12] A. Petersson and M. Nilsson, "Forwarded HTTP Extension," June 2014, pp. 2-4. [Online]. Available: https://www.rfc-editor.org/rfc/rfc7239.txt.

[13] J. Brozycki, "Detecting and Preventing Anonymous Proxy Usage," September 2008. [Online]. Available: https://www.sans.org/readingroom/whitepapers/detection/detecting-preventing-anonymous-proxyusage-32943. [14] What Is My IP Address, "Advanced Proxy Check," [Online]. Available: http://whatismyipaddress.com/proxy-check. [Accessed 15 12 2015]. [15] P. C. Kolin, "Successful Writing at Work," Cengage Learning, 2012, pp. 331-353. [16] Stat Counter Global Stats, "Top 8 Operating Systems from Aug 2012 to Mar 2015" [Online]. Available: http://gs.statcounter.com/#all-os-wwmonthly-201208-201503-bar. [Accessed 16 December 2015]. [17] S. Bhartiya, "The Best Linux Distros of 2016," January 2016. [Online]. Available: https://www.linux.com/news/software/applications/878620the-best-linux-distros-of-2016. [18] R. Broenink, "Using Browser Properties for Fingerprinting Purposes," in 16th Twente Student Conference on IT, Enschede, 2012.