How to clear out anonymous Web proxy servers in the workplace

Enterprises may use Web filtering software to limit Internet use, but some employees may respond right back with easily available anonymizing proxies. John Strand explains how to keep your users from bypassing content filters.

In an effort to control browser use within an organization, enterprises often use Web filters as part of their security gateway technology strategy. Some employees, however, eager to bypass the devices and continue their Web use without restriction, respond by using anonymous proxies, tools that can trick Web filters into incorrectly allowing access to an inappropriate site. In this tip, after reviewing how Web anonymizers can lead to compromised systems, we'll look at ways companies can shore up their content-filtering processes.

Why anonymous Web proxies are bad
First, I want to establish the dangers of allowing users to use anonymous proxy software to surf the Web. Let's be clear: If employees are using them on your network, you can guarantee that at least some portion of your user population is doing something that they should not be doing, perhaps going to porn sites, gambling sites or other non-approved places like personal blogs, MySpace.com or YouTube. Keep in mind that these websites often host malware, including Trojan backdoors in the form of ads and/or "special programs."

For more on proxy servers

A SearchSecurity.com reader asks Mike Chapple, "Can you explain the difference between a proxy server and proxy firewall? How do they work together?"
Also, remember that many enterprise Web content-filtering devices are not merely preventing attack and infection from malicious sites and domains of ill-repute. The products also protect an enterprise from content on legitimate sites that are unknowingly hosting malware via third-party ads by trying to block malware that may be dispersed via the adds. The Internet and the browsers that access it are your single greatest vulnerability. Without the protection of a Web content-filtering device, your only layer of defense against malicious code from the Web is antivirus, a defense which can be bypassed when a hacker has the right tools.

So how do users bypass Web-filtering devices? Quite easily; there are many freely available tools to do so. Employees, for example, can make connections and request objects through "go-between" anonymous proxy software like Privoxy, instead of having to connect directly to an enterprise server and be subject to content filtering.

To boot, keeping up with emerging Web proxy tools and techniques is no easy task. The blacklist approach that some antivirus vendors take to unauthorized proxies is to continually search through forums, IRC channels and discussion boards where users set up and share proxies. The vendor then adds the proxies to their blacklist. While the approach is interesting, it is flawed in that it does not help when a user sets up a proxy at home and tunnels out of an enterprise environment via SSH or SSL as we discussed above. In this case, the proxy of choice may not have reached the critical mass to attract the blacklist vendor's attention.

How to defend against anonymous proxy software
The first action an organization should take is to review its Web surfing policies. Acceptable use policies should state that user activity to and from the Internet will be monitored, and that no methods of bypassing corporate Web filters will be tolerated. Users should have no reasonable expectation of privacy. This may be a tough sell due to political issues, but it will go a long way toward securing and monitoring an environment.

To gain visibility into the network, which is an important aspect of anti-proxy defenses, any outgoing traffic that is not associated with a business driver should be blocked. Exceptions may be necessary for some external sites. For example, your users may need to access other sites for research or data entry. Try to identify which sites are essential in order for the business to function and make restrictions accordingly.

Don't miss need-to-know info!

Security pros can't afford to be the last to know. Sign up for email updates from SearchSecurity.com and you'll never be behind the curve!
While we as a community of security professionals have become quite good at only allowing certain protocols into our network (ingress filtering), many of our networks are still lacking when it comes to the traffic we allow out of our environment (egress filtering). It's critical to apply the same mindset to both inbound and outbound traffic. If enterprises redirect outgoing traffic destined to common Web ports like port 80 or 443, but neglect to monitor or restrict traffic to any other port, an internal user can circumvent outbound Web filtering by using the browser to manually input the server address and the port (i.e. wwx.homeproxy.com:8888). Attackers may also be able to create an SSH tunnel out of the enterprise environment to an external proxy. Ideally, you should have a default drop rule that any traffic not explicitly allowed is implicitly denied.

After getting a handle on the traffic leaving the environment, monitor the sites that internal users are accessing. Because there will inevitably be proxy sites that Web content-filtering software misses, make sure to review Web content-filtering logs on a weekly basis, at least.

Following all of the above steps helps in a number of ways. These best practices will cut back on the amount of unauthorized Web surfing, help with an audit and limit the effectiveness of client-side attacks against an enterprise environment. Many malware infections delivered via a Web browser utilize the Web as a command and control mechanism. Others utilize non-standard ports and protocols like port 6667 or ICMP as a tunneling mechanism. With outbound ports shut down, aside from those being redirected through a Web content filtering device, a major command and control vector for external attackers can be taken down. Considering this, any traffic that is about to leave the network -- and that has not been explicitly allowed and monitored -- should be treated as a possible compromise and should be investigated.

About the author:
John Strand currently is a Senior Security Researcher with his company Black Hills Information Security, and a consultant with Argotek, Inc for TS/SCI programs. He teaches the SANS 504 "Hacker Techniques, Exploits and Incident Handling," 517, "Cutting Edge Hacking Techniques," and 560 "Network Penetration Testing" classes as a Certified SANS Instructor. Strand also answers your questions on information security threats.

This was last published in March 2009

Dig Deeper on Web Server Threats and Countermeasures