Anonymizing proxies are often used by people who wish privacy, or to circumvent access controls. High profile political cases such as circumventing the Great Firewall of China and the protection of pro-democracy movements are held up as a model of the positive contributions of anonymizing proxies.

But there are also dark sides to anonymizing proxies, such as using them to harass or stalk other people. Many services such as MUDs or web boards want to be semi-anonymous, and have no interest in the user’s actual identity. In this day and age of free throwaway email accounts, establishing a new identity is easy. Banning an account can be rather futile if all what the offender has to do is establish a new email account. So, access control is often done via IP blocking. If the banned offender continues to persist, often the IP blocks are expanded to include the entire range of dynamic addresses allocated for the offender’s ISP.

However, anonymizing proxies are used to circumvent these IP blocks, and raise the bar for those people trying to control access to their services. While there are many valid uses for anonymizing proxies, a few abusers cause there to be a keen desire on the part of administrators to ban them from connecting or utilizing their services outright.

Many of these anonymizing proxies are not helpful enough to identify themselves as such, making banning them tricky. The question then becomes, how can the use of anonymizing proxies be detected? This in part depends on what sort of proxy is used.

There are:

• Protocol specific anonymizers — these are often specific to one protocol at a time, such as an anonymizing web proxy (HTTP) or Internet Relay Chat (IRC). These involve rewriting the messages that are sent between the communicating hosts.

• Protocol independent anonymizers — these create tunnels to carry traffic to the anonymizer. There are two major categories of protocol independent anonymizers:
  • Application-dependent — the application needs to support the tunneling protocol and communicates directly to the anonymizer.  This includes SOCKS.
  • Application-independent — these implement IP-based tunnelling and is the most transparent for the user.  PPTP and OpenVPN are examples of this.

• Multiple relays — while anonymizers such as TOR are really classified as application dependent and protocol independent, it is unique enough to merit a separate look. TOR uses a technique called ‘onion routing’, where communications are relayed through multiple random hosts for each connection that is made.

Analysis of the HTTP headers can reveal anonymous proxies, as these headers are often rewritten in a very characteristic way. User-Agent, From, and Referer headers are usually modified or removed to protect the user’s privacy. By outright rejecting unusual variations on these, it is possible to detect and stop anonymous proxies. There are Snort signatures for detecting this as well.

Along the vein of detecting proxy usage, one approach that works against TOR as well is to exploit the fact that the web browser client is executing client-side code such as Javascript, Java, or Flash. TOR uses Privoxy, and Privoxy often rewrites the content that is sent to the client. By detecting altered content using Javascript, it is possible to determine the use of specific anonymizing proxies and reacting differently. This code can be used as a gatekeeper, that checks before loading extra content. Sending this information back to the server might be viewed as a privacy violation. But this is not perfect, as it could be circumvented by a savvy user using force browsing.

A lower level mechanism is to open a Java socket connection back to the server. Jeremiah Grossman and RSnake at ha.ckers.org presented on this technique at Blackhat 2007. When the connection is successful, the server has the IP address of the origin, circumventing the proxy. By comparing the IP address provided by the connection with the one obtained via the original connection, a decision can be made as to if it is a proxy. There are also various other techniques that rely on client-side exploitation.

For each connection via Tor, the exit node changes. HTTP uses multiple sequential connections. This can be exploited readily by embedding a signature that contains the remote address that previously connected, the user agent, and other headers. This is then MD5’ed into a session hash. If the exit node changes, the remote address will change, consequentially, changing the session hash. When the session hash changes, the application or site can kick the user out to a login page.

Another way to detect anonymizing proxies is to download proxy listings on a daily basis and add them to a list. By comparing the connecting IP address to the list, it can be determined if it was via a proxy. This is imperfect and does not cover all the possible proxies. This also includes downloading a list of Tor exit nodes.

One of the more intriguing papers encountered during the research for this post was Identifying Proxy Nodes in a Tor Anonymization Circuit by Chakravarty, Stavrou, and Keromytis. By measuring the network characteristics of a connection via Tor, it may be possible to determine that the communications came via the anonymous proxy. This is speculation, however, and further research may be coming to investigate this. There may be a technical and detailed blog post on this in the future!

As stated earlier, it is not the most trivial of tasks, but by using a combination of techniques, a website operator should be able to block anonymous proxies. If it is a lower level application such as a MUD that one connects to via telnet, then simpler techniques such as proxy list blocking are necessary. Packet inspection or characteristic measurements may allow such applications to block proxy nodes.