Showing posts with label proxy. Show all posts
Showing posts with label proxy. Show all posts

Monday, April 21, 2008

Web filter evasion part 4: Public HTTP Proxies

A lot of times, you kind of want access to your favorite content, even if it's just to read it, while at work or school. Some places with more draconian Internet access policies block pretty much everything "cool" and paint their restrictions with a very wide brush. In this series, we'll uncover a few ways around these restrictions.

With each article, I will delve into techniques that are progressively more advanced and difficult to implement. Keep in mind that this is a thought exercise in evasion. Implementing this stuff could get you expelled from school, fired from your job, or banned from public-access computers in a library or coffee shop. With a little bit of wisdom, you can often get around the restrictions set in place without getting yourself into hot water.

Today, we will cover using "wide open" proxies to bounce our connections through. Since proxies are transient and often configured poorly, they pass the ire of most web filters. The rub? You usually have to find one that operates on a well-known port such as 80 (http) or 443 (https/ssl). Finding a working proxy can be a pain, and using it involves tweaking your browser settings and/or installing special software. Group policies could leave you in the cold on this one. The increased difficulty of this particular evasion technique brings this trick in at #4 in our series.

Public Proxies
Public proxies are (often SOCKS v5) proxy servers that have either been intentionally or accidentally configured to allow anyone on the Internet to access proxied content without proper access controls. I could go on and on about the various security implications of these proxies but that's not what this series is about. Simply put, HTTP proxies differ from Web Proxies in that the browser directly handles communication with the proxy behind the scenes. Regardless of what protocols the proxies are capable of handling, we're only concerned about Web traffic (http/https) for the time being.

Browser Configuration:
Yesterday, I linked to various proxy configuration instructions for different browsers. Today, you can use the same instructions to add the proxies you discover on your own. If you find that there is already a proxy server configured, you might be out of luck for this trick (and maybe for the fifth and final one, as well). If your employer is already forcing your web traffic through their own proxy, there's a good chance that they're blocking all outgoing traffic from your workstation to the Internet, making HTTP Proxies AND Tunneling difficult, if not impossible.

Security Risks:
The same risks apply here as apply to web proxies. Your data is going through a third party and you're subject to data manipulation, sniffing, or other bad things. Essentially, you're trusting a potentially unknown and untrusted third party with your traffic. By now, it should be obvious that these more aggressive evasion techniques can't be easily justified. You have been warned.

Finding public HTTP Proxies:
Public proxies play a huge role in the so-called underground. I'm talking mostly about illegal or frowned-upon activities such as phishing, spamming, and illegal file sharing. As such, there are groups that go out of their way to sniff out and enumerate poorly-configured proxy servers that are easily hijacked for whatever purpose others desire. I don't advocate using services without permission. In a moment, I'll discuss how to set up your own public HTTP Proxy.

One source that provides a list of proxies that can be sorted on several criteria: http://www.xroxy.com/proxy-port.htm

Assuming your employer or school has you locked down to using only port 80 or 443, use the above tool to find proxies that operate on those ports. Then, update your proxy settings to match one of the servers in the list. If it's too slow or fails to work, try again. Soon enough, you should be able to access all of the content your heart desires.

Squid at home (or on another server outside of work/school)
You can also configure Squid to act as your own proxy. Making it a public proxy is a bad idea, so lock it down to your remote computer's IP Address. First, find your public-facing IP address from the computer you normally use, and write it down. The easiest way is to visit WhatIsMyIP.com. Then, using the Squid configuration guide from yesterday, add the following lines:

At the top of the block of "acl" lines (replace with your actual ip address in place of 65.43.2.1):
acl myremote src 65.43.2.1 255.255.255.255

Above the other http_access lines:
http_access allow myremote all

Finally, you will need Squid to listen on a port you can use. For this example, we will use Port 80. Keep in mind this will interfere with any web server running on this host. Below the existing http_port line(s), add:
http_port 80

Restart Squid, then point your browser's proxy to the IP address of your squid server, port 80.

The IP Address restriction of "myremote" will keep others from hijacking your proxy. Add as many rules as you need to for other remote IP addresses.

On Wednesday, the final aricle in this series will cover encrypted and tunneled proxy traffic.

Sunday, April 20, 2008

Sysadmin Sunday: Squid Cache

What is Squid?
Aside from something Bruce Schneier writes about every Friday, "Squid is a caching proxy for the Web supporting HTTP, HTTPS, FTP, and more. It reduces bandwidth and improves response times by caching and reusing frequently-requested web pages. Squid has extensive access controls and makes a great server accelerator. It runs on Unix and Windows and is licensed under the GNU GPL." -- taken from Squid-Cache.org, as I couldn't explain it any better myself.

On your network, you can set up Squid on a reasonably well-endowed server for the purposes of manipulating certain Internet traffic - specifically HTTP, usually for the purpose of increasing load times on frequently-visited content. There are other things you can do with Squid, such as blocking advertisements or turning all of the images upside down (or is that umop ap!sdn). For now, though, we'll set up a Squid server in our lab on our AMP (Apache/MySQL/PHP) fun box, running Gutsy server.

Getting and Installing Squid

Many operating systems' package installers have Squid available for installation. Squid has a list of binary packages for popular operating systems, but building Squid from source code is trivial at best (with a ./configure && make && sudo make install ) but for the sake of cleanliness, I'll just do a sudo apt-get install squid on Ubuntu.

Making Squid Work
Squid must have a cache directory that it can store the data in. If the package installation did not create this, then you must run (as root), squid -z, which will create the cache directory. You should also make sure that squid will start by default. If you reboot and squid isn't running, adding "squid" to your rc.local file is the easiest way, but there could be a start-up script somewhere that would do a more elegant job.


Proxy settings on your workstation(s)
Squid, by default, runs on port 3128. To enable proxy for your workstation, you will need to know the IP Address of your Squid server, and when asked for what port the proxy runs on, enter 3128. Here are some links for setting up Proxy in various browsers. Just remember to use your Squid IP and Port in place of any example proxy configuration used.


Now what?
At this point, you likely have a Squid server up and running with the basic default configuration enabled, and for the most part, it's completely useless. Shown below, I've pointed Safari's proxy settings to the Squid server then attempted to access HiR Information Report to no avail.



To fix this, find the ACL lines in squid.conf (on Gutsy, it's /etc/squid/squid.conf) and simply add a line define your local network. Obviously, you would want to replace this with your own IP subnetting information.

acl localnet src 192.168.0.0/255.255.255.0

Then, find the http_access lines and add a line (preferably above all of the other http_access lines) allowing machines on the local network to get out to the rest of the Internet:

http_access allow localnet all


After re-starting squid (killall squid, pkill squid, /etc/init.d/squid restart, etc...) I can access anything through squid, and the pages will now be cached. This will reduce the bandwidth used for day-to-day web browsing and make pages seem to load faster. For a small business running on typical consumer broadband connections, this is a quick and easy way to increase browsing performance. Also, operating system patches will only be downloaded once and then cached. When the time comes to do the updates on all of the workstations, this trick will make life a little easier for you.

If you wish to force all HTTP traffic through Squid (for instance, if you yourself are planning on implementing a Web filter with Squid) and you have a somewhat flexible router or firewall, you can block all outgoing traffic destined for port 80 and 443 except for traffic coming from the Squid server. That, however, is beyond the scope of this article.

Tomorrow, you'll learn how to tweak a few options for Squid so that you can use it to evade web filters in the fourth article in my ongoing web filter evasion series.

Saturday, April 19, 2008

Web filter evasion part 3: Anonymous Web Proxy

A lot of times, you kind of want access to your favorite content, even if it's just to read it, while at work or school. Some places with more draconian Internet access policies block pretty much everything "cool" and paint their restrictions with a very wide brush. In this series, we'll uncover a few ways around these restrictions.

With each article, I will delve into techniques that are progressively more advanced and difficult to implement. Keep in mind that this is a thought exercise in evasion. Implementing this stuff could get you expelled from school, fired from your job, or banned from public-access computers in a library or coffee shop. With a little bit of wisdom, you can often get around the restrictions set in place without getting yourself into hot water.

In Part 3, I am going to discuss using web "privacy" or "anonymizer" proxies. It's number three on the list because it is simple to use and often free -- risks be damned. These often free (but occasionally subscription-based) web sites provide you with a special URL that you visit, whereupon you enter the URL you wish to visit. These sites often claim to keep rogue websites from storing cookies or executing scripts on your computer, while others focus on evading web filters or blocking ads.

Risk of getting punished if caught
Regardless, you will have a difficult time weaseling your way out of this stunt if you're caught. The only reason you'd want to use proxies such as these one while in a web-restricted environment is to evade the restrictions. There's no innocent sweet-talking that will save you here. Also, many web filtering companies specifically play cat-and-mouse with these kinds of services, often blocking them shortly after they appear. Users who trigger this rule on a web filter are almost certainly going to get a visit from a higher-up.

Security risk of using proxies
Any time you use a proxy, you are routing traffic through someone else's network. While it's true that all Internet traffic hits various networks, the operators of proxies KNOW that people are using their services either for privacy or filter evasion. As such, not all proxy providers are guaranteed to be trustworthy, including those listed below.

Managed Web Proxies
Megaproxy offers a free trial. It was one of the first web-based anonymous proxies, with the intended purpose of keeping cookies and ads at bay, making it more difficult for site owners to gather data about you. The (perhaps unintentional) side effect was that people who could access the it from behind a web filter service could often use it to access blocked content. The paid version has a much more obscure and innocuous URL that isn't likely to make netadmins question it, but its URLs are most likely blocked on commercial filtering software because they go to great lengths to find most of the high-profile ways to evade. I actually did subscribe to this service many years ago, but I've since let it lapse. I was generally happy with it while I used it.

Privax offers an extensive list of (what appear to be free) Anonymous Web Proxies. The catch being here that there are many different URLs you can visit, with the hopes one or more won't be filtered. Some addresses blatantly announce that it's a proxy service while others are less obvious. Like other web proxies, Privax places a secondary navigation bar at the top of every page, making it easy to tell if the stuff you're looking at is, in fact, being proxied. I haven't extensively used Privax before, but it looks like a decent solution as I sit here now and try some sites through it.


Set up your own
For a while, I ran my own CGI Proxy on a hosted server that I could access from anywhere. If you have web space, this is a way to set up your own proxy under the radar, especially if you access it via SSL. The down-side is that many web-based anonymizers that you can host yourself (there are others, written in PHP, Perl, etc) lack some of the more advanced functionality of the commercial "anonymizer" providers. If setting one up yourself, be sure to use a method of password protecting your proxy so that it can't be abused by others who stumble across it.

Tomorrow on Sysadmin Sunday, I'll discuss setting up Squid, a caching HTTP proxy. This is different than a Web or CGI proxy, but it can be used to evade web filters as well. On Monday, I'll pick up the series again and discuss how to bypass web filters with your new Squid server.

Read the whole series: Web Filter Evasion

Tuesday, April 15, 2008

Web filter evasion part 1: RSS and You

A lot of times, you kind of want access to your favorite content, even if it's just to read it, while at work or school. Some places with more draconian Internet access policies block pretty much everything "cool" and paint their restrictions with a very wide brush. In this series, we'll uncover a few ways around these restrictions.

In Part 1, I am going to cover one way of evading these restrictions that is not only one of the most straightforward and easy methods, but also the least likely to get you in trouble with your boss or your IT department: Online RSS readers.

About RSS
RSS was invented around the turn of the century, but started to gain widespread popularity in the wake of so-called "Web 2.0", when syndication, mash-ups, cross-platform publication and content management all coalesced together. While not every web site has an RSS feed, almost every blog, news site and social network has some kind of RSS integration going on. In this article, I'll focus on gaining access to content via RSS despite web filtering software's strangle-hold.

Local RSS Clients
Local RSS clients such as FeedReader or Mozilla Firefox Live Bookmarks usually contact the site directly, pulling a data feed down (RSS, Atom, XML, etc) to display the information in a lightweight, easy-to-read format. The problem with this is that the RSS feed usually has the blocked URL in it. For example, Digg's rss feeds are all on digg.com. If access to Digg is blocked, you can't get to the feeds, either.

Online Readers
Online RSS readers pull the feed from a central server, then just display the information to you directly over the web. For this example, I'll use Google Reader. That said, My Yahoo and MSN Live (among dozens of others) also offer the ability to integrate feeds on your page but it's not quite as robust as Google Reader. Using the example above, if you add Digg's RSS feeds to Google Reader, your web filter only sees you trying to access http://www.google.com/reader/ which is passing the contents of the RSS feeds to you - and most web filters let you get to Google. Again, if that doesn't work, there are dozens of ways to access RSS feeds with online readers.

Things to note
One flaw here is that embedded content from banned sites won't load and may be logged in your web filtering software. If your employer blocks Flickr, you can load someone's Flickr RSS feed into your reader and see their feed, but all of their images will fail to load. Same goes for blog posts with embedded YouTube videos if YouTube is blocked. You get the idea. Basically, this works best for RSS feeds where most of the content is text-based. News sites like CNN or Engadget. Social bookmarking sites like Digg, delicious and reddit. Blogspot, wordpress or livejournal blogs. Even twitter.

Justification
If you get busted (which is not likely if you play your cards right), you can always say that you use something like Google Reader to track updates to your favorite websites at home. If you can get to it from work, it must be okay, right? Make sure you're managing your time wisely, and keep the content you view at work "work safe" and non-offensive. Chances are that your boss won't mind. In fact, he might just think you're checking your personal email really quick, as RSS readers often look somewhat similar to web mail clients. Plausible deniability only works once, though. If you're asked to stop it, you should stop. If your written policy specifically bans all personal Internet browsing, you may also get the book thrown at you. HiR won't be held responsible for legal or employment problems.

How to do it:
First, sign up for a free Google account if you don't have one already.

Next, go to Google Reader and log in.

Add a subscription RSS feed. I'll add HiR Information Report to my Google Reader:





In part 2, I'll cover using out-of-band communication.