I am wondering how reverse proxies can be used to bypass company acceptable use policies?

What can be done to prevent it?

  • An example of a specific situation may help. Jun 16, 2012 at 9:03

3 Answers 3


Reverse proxies can't really be used to circumvent the rules, I believe you are referring to forward proxies. Check this post to learn the difference. (If I'm wrong please post a comment)

You can restrict access by forcing them to use your own forward proxy server internally. Do mind that this is not 100% proof, a more skilled user will get through this with ease by using SOCKS over ssh.

What can you do? What you do whenever someone breaks the rules:

  • you warn them
  • you punish them

Just make sure when you warn and punish them they are aware what the AUP states and also why some things were banned. Make them aware that there might be security threats for the internal network or to the working environment and that their behavior is not acceptable.

  • It could be either. However the question is not 100% clear on that part. For example http://proxy.com/http/www.google.com/ I would consider a reverse proxy because it abstracts/hides the destination as opposed to abstracting/hiding the client. Jun 16, 2012 at 9:00
  • 6
    @BernieWhite, hm, i am not sure about that. I think the common terms are (at least in the area of web application development): A (forward) proxy accepts connections from known clients to any server. A reverse proxy accepts connections from any client to known servers (e. g. for load balancing). For proxies that accept connections from any client to any server, the term "open proxy" or "anonymizer" seems to be the best fit. Jun 16, 2012 at 9:32
  • @Hendrik I'll pay that. Jun 16, 2012 at 10:02

Detect It

Regardless of either a forward or reverse proxy analysis of the network traffic with something like Wireshark will allow you to detect it, which is the first step to preventing it.

Proxies designed to bypass filtering or access control will exhibit these types of behaviours as to bots and generally anything trying to hide it’s true purpose:

  • Long URLs with web site names in them either in the front http://www.google.com.proxy.com/ or trailing like http://proxy.com/http/www.google.com/
  • SSL/TLS tunnelling
  • Connections to IP addresses instead of DNS host names
  • Connections to where the HTTP request Host: header does not match the host name
  • Non-HTTP connections out on HTTP ports
  • Connections to TCP/UDP port over 1023

This obviously could include a lot of legitimate traffic however knowing what type of traffic currently goes in and out your network will allow you to detect any anomalies.

Prevent It

Assuming you are starting from no control on your network I would look to build up the following in to enforce strict compliance:

  • Develop a corporate Managed Operating Environment (MOE) – know what software is installed on your clients/servers, enforce removal of software that is unknown or not permitted.
  • Use a firewall with good logging and filtering capability on edge network and try to put choke points in so to minimize where you have to look.
    • Tune firewall rules and logging.
    • Only log what you need to prevent overload of data that you can’t possibly review.
    • Use a whitelisting approach. i.e. Block everything coming in and going out by default and allow only known approved traffic.
  • Use proxy servers for granular HTTP/HTTPS control.
    • Choose one that supports category based filtering (which is a dictionary and sometimes other smarts to categorise URLs, they often have a category just to block know anonymising proxies).
    • Proxy servers can implement SSL interception for blocking tunnelling applications (some legitimate application use this).
    • Block non-HTTP traffic over HTTP ports.
    • Block HTTP/HTTPS traffic directed to IP addresses instead of DNS host names.
    • Regularly review reports on the web traffic, look for suspect host names and uncategorised websites.
  • Implement an intrusion prevention system

While you might find you are unable to do all of these, any will definitely help.

Hope that helps.


(Answering for a forward proxy as I agree with Lucas).

Depending on how open the environment, there's not much you can do. If you have to allow ssh out of the network for legitimate purposes, you can't figure out if the traffic is normal ssh (e.g., transferring files for legitimate purposes) or a SOCKS proxy over an ssh tunnel; if the user implemented it correctly (sometimes stuff like DNS requests won't use the proxy and you can tell where people are going). If you have the ability to be more restrictive, you can just block everything but port 80 (maybe allowing port 443 for a few known entities like gmail).

A better solution is clear well-known Acceptable Use Policies with clear consequences for violations. E.g., if employee is caught looking at porn/watching netflix movies/using facebook on company computers on company time in clear violation of rules, have harsh penalties (ranging from severely docking pay to firing). Another alternative is installing remote monitoring application on all company computers and letting an admin remotely look in on any desktop. (Though that seems fairly draconian and probably would create a hostile working environment).

Additionally, if what you are worried about is sharing limited bandwidth and people are say streaming lots of video, it may be worth thinking about implement some sort of network quota; possibly more stringent for encrypted traffic versus port 80 HTTP or HTTPS traffic to known servers (e.g., gmail).

If you are worried about people transferring out confidential data that's another issue. Once an employee has access to data on their computer, you basically need to rely on trusting the employee to not misuse the data (as well as restricting and monitoring who is initially accessing the sensitive data). If they can set up a proxy; they can do other things to take the data off-site. Encrypt the files and email them out or put them on removable storage (USB drive/burned cd/dvd/laptop), etc.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .