Using Squid

Squid is a web proxy -- it handles http requests for clients. It will cache recent lookups which will improve performance/reduce internet traffic, and it also gives you stronger options for restricting online activity.

Access Control

A lot of people find this fiddly. First, you create an acl (access control list), then you grant/deny access. The first match wins:

 acl all src 0.0.0.0/0.0.0.0
 acl mycompany src 192.168.0.0/24
 http_access allow mycompany
 http_access deny all</pre> 

This will allow everyone in the 192.168.0.0/24 ip range access to your proxy, and deny it for anyone else. It's usually easier to put your matches into separate files rather than squid.conf like this:

 acl banned_users src "/etc/squid/banned_users"
 http_access deny banned_users

where banned_users is just a line-separated list:

 192.168.0.13/32
 192.168.0.19/32
 192.168.0.54/32

Multiple acls are logically ANDed so the match is only made if all conditions are met:

 http_access deny !all_access_group banned_domains

If a user isn't in the all_access_group and the site is in the banned_domains acl, the request will be denied.

Blocking executable downloads with Squid

This was something I was asked to do where I work, and it proved a little problematic due to the complexity of http itself. For instance, we used to do this to stop the download of executables:

 acl banned_file_types url_regex -i \.exe$

The problem is that parameters can be added to an URL in the form of: http://www.dodgyspyware.com/evil.exe?9383410ac2c332c This also means that clever people can download any .exe simply by postfixing a question mark to the URL. To protect against that, you need to incorporate this:

 acl banned_file_types url_regex -i \.exe\?+

Which works great, except now cgi executables don't work on web pages: http://www.legitsite.com/cgi-bin/search.exe?loc=london because the http GET command covers both downloading a file and requesting a page (which executes a script). Also, if the request is http POST instead you won't see them in the URL, and anyway this doesn't stop people downloading .vbs, .com, .scr files, etc. The only way around this is to abandon filtering on common file extensions, and instead block on the server's replied mime type for the file. Unfortunately there are a fair few of these, but the main biggie for file downloading is application/octet-stream. Here's what we currently do:

 acl banned_mime_types rep_mime_type -i ^application/octet-stream$
 http_reply_access deny banned_mime_types

Sometimes servers have misconfigured mime types, so they respond with the wrong type for a file -- seems to happen reasonably often with .swf (flash) files. Other than that, this should work well. Users get a specific error message telling them they can't download, but you can't see this from the access.log file because this only records user requests -- the requested mime type is often different from the replied mime type, and it's the latter that tells the browser how to handle the file (display in the browser, open up Acrobat, save to disk, etc). You can tie it up with /var/log/squid/store.log if you need to see exactly which mime type was used, or turn on debug logging. The squid wiki is a good resource: http://wiki.squid-cache.org/