Squid Puts the Squeeze on Net Wrongdoers
Last week, in part 1, we got Squid up and running as a simple local http caching proxy. This week, we shall exercise our godlike admin powers and use Squid to control Web access for our users. We shall control the time of day they are allowed to surf, make sure their Web surfing goes through Squid, force them to authenticate to Squid, and create blacklists of their favorite Web sites.
Last week, we got as far as testing Squid on the server. Connecting clients is simple. For example, this is how Mozilla does it:
Edit -> Preferences -> Advanced -> Proxies. Click "manual proxy configuration." Enter the name of your Squid server, and the port number. For example:
You may also use the IP address of the Squid server.
Diving Back Into squid.conf
squid.conf contains something like 125 separate options. You can run Squid with an empty squid.conf, and just let it coast on the defaults. (Though on my Debian system, it would not start until I gave it a visible_hostname directive.) The following examples can be used either in a blank, brand-new squid.conf, or added to the original. Remember to not uncomment the defaults. Be sure to run Squid's syntax checker, and restart Squid after making changes:
# squid -k parse # /etc/init.d/squid restart
Blocking Bad Users
Some folks just never learn. They show up for work, and immediately start crawling all manner of not-work related Web sites, or fire up their personal mp3 servers, or log in to Deathmatch Quake, and slow traffic to a crawl. Squid makes it easy to stop them in their tracks. Remember our ACLs (access control lists) from last week?
acl all src 0.0.0.0/0.0.0.0 acl localnet src 192.168.1.0/255.255.255.0 http_access allow localnet http_access deny all
Let's create a deny rule for our problem user:
acl all src 0.0.0.0/0.0.0.0 acl localnet src 192.168.1.0/255.255.255.0 acl BadUser src 192.168.1.100 http_access deny BadUser http_access allow localnet http_access deny all
The order is important, always put your "deny all" rule last. Now you can leave your problem user blocked until you implement a remedy.
Here we are with this nice big Internet to play in, and suddenly bosses everywhere are screaming at us to put up fences. It's quite the fashionable trend these days to implement Web blacklists, to prevent users from accessing certain Web sites. You and I both know this is largely a futile exercise. But here is how to do it anyway. All you need is a list of forbidden domain names, and these two rules:
acl ForbiddenDomains url_dstdomain "/etc/squid/forbiddendomains" http_access deny ForbiddenDomains
The list format is simple, just a single column list of domains:
dixiecupps.com dixiepeephole.com onlinegambling.net quakedeathmatch.com
You may assemble your own list, or use one of the many publicly-available lists. A Google search for "squid blacklist" will find many. If your blacklist needs are serious, try SquidGuard.
Squid supports a number of authentication schemes and protocols. The simplest is the NCSA authentication helper. You'll need a separate password file for Squid, and NCSA support compiled into Squid, which would be most unusual if it were not. The password file is created with htpasswd, which comes with Apache, or you can download it from http://www.squid-cache.org/htpasswd/. While you're there, grab chpasswd, which allows users to change their own passwords. (Or not, depending how much control you wish to claim over the innocent lives of your users.)
You definitely do not want to use system logins. Leave them alone! Do not touch. etc. This is how to create a new password file with htpasswd:
# htpasswd -c /etc/squid/passfile alice New password: Re-type new password: Adding password for user alice
The -c flag creates a new file. To add more users, don't use the -c:
# htpasswd /etc/squid/passfile ted New password: Re-type new password: Adding password for user ted
Take a look and make sure:
# cat /etc/squid/passfile alice:mU7OltQzHySmY ted:8K.EZVQwHM/Ok
The default encryption for htpasswd is crypt, which serious security geeks laugh at. Let them laugh; for use on your LAN, it's just fine. Make sure that the password file is mode 644. Now tell Squid about it:
auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/passfile acl Passfile proxy_auth REQUIRED http_access allow Passfile http_access deny All
You can really tighten the screws on your users, and restrict the hours that Internet access is available:
acl Internet_hours time M T W H F 12:00-13:00 http_access allow Passfile Internet_hours
Squid and Iptables
None of this does any good if your users can simply disable the proxy in their Web browsers. Yes, these same users who stare at you blankly when you use big technical words like "Web browser" will find ways to mess with their browser configurations. To foil such cunning, make nice iptables rules:
lan="eth0" internet="eth1" iptables="/sbin/iptables" # Set default policies $iptables --policy INPUT DROP $iptables --policy OUTPUT DROP $iptables --policy FORWARD DROP #allow LAN users to use Squid $iptables -A INPUT -i $lan -p tcp --destination-port 3128 -m state \ --state NEW -j ACCEPT # allow Squid to proxy http & https traffic $iptables -A OUTPUT -o $internet -p tcp --destination-port 80 -m state \ --state NEW -j ACCEPT $iptables -A OUTPUT -o $internet -p tcp --destination-port 443 -m state \ --state NEW -j ACCEPT
This is not a complete firewall, just the Squid-pertinent bits. Now your users can futz with their browser configurations all they want to- too bad, so sad, Squid runs the show.