See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/304158964

Exploring Proxy Detection Methodology

Conference Paper · June 2016

DOI: 10.1109/ICCCF.2016.7740438

CITATIONS READS
2 1,952

5 authors, including:

Mandeep Pannu Bob Gill

Kwantlen Polytechnic University British Columbia Institute of Technology
18 PUBLICATIONS   84 CITATIONS    12 PUBLICATIONS   342 CITATIONS   

SEE PROFILE SEE PROFILE

Robert Bird
Coventry University
14 PUBLICATIONS   20 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Internet of Things: Analyzing the Impact on Businesses and Customers View project

Volatile Memory Recovery and analysis; Evidential logging: professionalising digital forensic evidential recovery; gender differences in student cohorts in digital forensics
View project

All content following this page was uploaded by Mandeep Pannu on 15 February 2018.

The user has requested enhancement of the downloaded file.

 Exploring Proxy Detection Methodology
Mandeep Pannu Bob Gill Robert Bird Kai Yang Ben Farrel
Department of Computer Department of Electrical Faculty of Engineering and Department of Computer Department of Computer
Science and Information and Computer Engineering Computing Science and Information Science and Information
Technology BCIT Coventry University Technology Technology
KPU Burnaby, Canada Coventry, UK KPU KPU
Surrey, Canada Bob_Gill@bcit.ca robert.bird@coventry.ac.uk Surrey, Canada Surrey, Canada
mandeep.pannu@kpu.ca kaixin.yang@kwantlen.net Ben.farrel@kpu.ca

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.
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

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.
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 HTTP-
based 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 general-
purpose 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 web-
based 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
A. Proxy Operations Analysis
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 The proxy detection module performed its function with
phase. Each test signified advancement in our detection efficiency and effectiveness. The detection process time per
algorithm. During testing, it was determined that the easiest client is approximately one millisecond (1 ms) plus the latency
method of integration is via PHP. Further testing was between the client and the server. The detection rate for
performed in an attempt to utilize HTML5; however, we were SOCKS proxy connections is 100%. On the other hand, the
unable to create a non-PHP module that is capable of operating detection rate for HTTP proxy connections is 94%, due to
without requiring the user to install a plug-in or add-on some devices disabled flash and scripts. The module is
extension. Through the utilization of both paid proxy services relatively straightforward to integrate into existing systems. As
and manual configuration on several system platforms, we long as we are able to enforce the use of the Flash object on
were able to positively identify proxy users of any manually the browser, the detection of any locally configured proxy will
configured proxy options, or web based portals. As previously be positively identified.
described, VPN services were more difficult to identify in a Unfortunately we were unable to create a database-free
meaningful way. These VPN services can potentially be methodology of identifying users utilizing advanced VPN
detected using one of the following methods. services. Since VPN services bind to a locally created network
 Personal computer fingerprinting and analysis of data device, the proxy detection module will find both the public IP
stored in a database. and the discovered IP to be the same, which renders the proxy
detection module ineffective.
 A client-side invasive application that monitors all web 78 out of 80 of the VPN services that we tested through
traffic and ensures a secure connection to the target site TorGuard were positively identified with a reverse DNS test.
(this is used by a number of banks). However, the reverse DNS test is vulnerable to false positives.
 Advanced hardware technology that performs detailed In order to filter out the false positives, we would need to
packet inspection used in combination with tracking create a complex mechanism to analyze the client machines'
packets. details. A detailed fingerprint can be created from any
incoming connection containing information about the
C. Experiment Results computer and location [18]. The fingerprint is used to identify
Below are some of the proxy users logged by the proxy information about the target machine, such as local machine's
detection module, which demonstrates the result of our country codes, language options, and regional settings. This
experiment. information can then be compared against the public IP
address' country of origin.
TABLE 1. SELECTEDA EXPERIMENT RESULTS
VI. E-COMMERCE MODULE DESIGN AND
Time Connection Discovered Proxy RDNS Tor
Stamp IP IP Detected Failure Check IMPLEMENTATION
1/31/2016 10.190.147.23 10.190.22.1
Yes Yes No
7:11 4 76 As modern society becomes more and more dependent on
1/31/2016 10.107.147.23 10.107.147.
7:12 4 234
No No No electronic transactions, data has become the most valuable
1/31/2016
10.150.208.18
10.150.208.
No Yes No asset for any businesses. Due to the inherently insecure nature
15:41 18
1/31/2016 10.164.234.13 10.164.234.
of the Internet, businesses need to take into account that
No No Yes
22:34 8 138
A
vulnerable web-based applications can be exploited by cyber-
Out of 811 connection attempts from 50 devices.
criminals. Thus, it is crucial that businesses adopt e-commerce
fraud prevention methods to safeguard their data.
Based on table 1, below are the interpretations of the 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 non-
VPN 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_Point-
to-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-based-
vpn-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/reading-
room/whitepapers/detection/detecting-preventing-anonymous-proxy-
usage-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-ww-
monthly-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/878620-
the-best-linux-distros-of-2016.
[18] R. Broenink, "Using Browser Properties for Fingerprinting Purposes," in
16th Twente Student Conference on IT, Enschede, 2012.

View publication stats