Simple Configuration Tips Put Squid on the Menu
If you've been running a network for any length of time, you know that merely connecting to the Internet, then sitting back and having fun, is simply not in the cards for us hardworking netadmins. No, for all those bits must not be allowed to flow unimpeded, but must be monitored, filtered, diverted, accepted, rejected, sniffed, throttled, chained, and logged. It's a wonder that any of them survive.
The Squid http proxy performs a large number of useful tasks. Today we'll look at http proxying and access controls. Squid's primary duty is to cache http requests. A typical LAN has much fatter internal pipes than external, so the bottleneck is usually your shared Internet connection. Caching Web pages speeds things up considerably, and conserves bandwidth. And you, the godlike admin, can restrict access to specific Web sites, networks, and users, as the whim ... I mean necessity ... dictates.
This article is aimed at Squids that are installed from RPM or .deb. If you build it from sources, be sure to read all the relevant READMEs and INSTALLs, because the steps are different. You'll have to create some files, and pay special attention to file permissions.
Squid runs on any Linux/Unix, and will even run on Windows NT/2000, with a little help from Cygwin. Though it's a mystery to me why anyone would want to do that. A Squid server needs a lot of RAM and a lot of storage. CPU speed is not all that important: A 500mHz processor will do nicely. Fast I/O is where you want to spend your money. Nice fast SCSI drives and lots of RAM will give the fastest performance.
As a very general rule, allow 32 megabytes RAM for each gigabyte of disk space. So a 30-gigabyte disk cache could be paired with 960 megabytes of memory. Calculating how much you really need comes from experience, because it depends on how much traffic your users generate. Most admins store 1-2 weeks of traffic. Keep track of your HTTP bandwidth use, and this will tell you how much you need.
Web caching and Squid logs eat up vast amounts of disk space. So you definitely want /var on its own partition, just in case it goes nuts and fills up uncontrollably and explodes. It's not necessary to use a journaling filesystem for the Web cache, because this is transient data. Plain ol' ext2 works nice and fast, especially when it's mounted with the noatime attribute, which this /etc/fstab entry demonstrates:
/dev/hda3 /var ext2 defaults,noatime
Rather than navigating through squid.conf, which is several thousand lines, rename it squid.conf.bak, and create a new squid.conf from scratch. The original squid.conf is well-commented, and makes a good reference. We'll create a minimal squid.conf that contains only our new directives.
If you elect to edit the original squid.conf, do not uncomment the "default" lines when you want to keep the defaults. This can cause Squid to behave oddly.
For Squid to even start, the server must have a fully qualified domain name. Add this line to squid.conf:
Add the name you want your Squid server to have. It can be different from the hostname, or the same, it doesn't matter.
The Squid User
Squid needs to run as an unprivileged user. By default, it gloms onto nobody. But it's better to create a dedicated Squid user, and not share nobody, which is overused, and a target for crackers. The usual convention is the "squid" user:
# adduser --system --disabled-password --disabled-login --no-create-home --group squid
Now add the squid user to squid.conf:
cache_effective_user squid squid
You really don't want your nice Squid proxy to be abused by spammers and other loathesome subhumans. Even when it's tucked away on your LAN behind a firewall, it doesn't hurt anything to use these rules:
acl all src 0.0.0.0/0.0.0.0
acl localnet src 192.168.1.0/255.255.255.0
http_access deny all
http_access allow localnet
The default is port 3128:
If Squid is used on a firewall/gateway, with an internal-facing NIC, and an external NIC, be sure to tell Squid to listen only on the internal interface:
Logging options range from minimal output to torrential output, numbered from 1-9. Trust me, it is better to start with minimal logging, then increase the verbosity only if it's needed:
You probably want users to have a contact email, to report problems. This address appears in error messages:
You can now save your changes, and run Squid's built-in configuration checker:
# squid -k parse
If it exits silently, you're in good shape. If it finds errors, it helpfully tells you where:
2004/05/31 13:07:13| parseConfigFile: line 12 unrecognized: 'squidserver'
Make a habit of running squid -k parse every time you make a change, because it will prevent many headaches.
And now, the moment we've all been waiting for -- making Squid go:
# /etc/init.d/squid start
Starting proxy server: squid.
Squid tries hard to be helpful. It checks for errors at startup, and tells where they are.
A useful way to test Squid is to start it from the command line. Shut Squid down:
# squid -k shutdown
Restart it in a terminal with this command, and mounds of interesting output shall pour forth:
# squid -N -d1
2004/05/31 15:26:01| Starting Squid Cache version 2.5.STABLE5 for i386-debian-linux-gnu...
2004/05/31 15:26:01| Process ID 3807
2004/05/31 15:26:01| With 1024 file descriptors available
2004/05/31 15:26:01| Performing DNS Tests...
2004/05/31 15:26:01| Successful DNS name lookup tests...
2004/05/31 15:26:01| DNS Socket created at 0.0.0.0, port 32871, FD 4
2004/05/31 15:26:01| Adding nameserver 220.127.116.11 from /etc/resolv.conf
2004/05/31 15:26:01| Adding nameserver 18.104.22.168 from /etc/resolv.conf
The line we're most interested in seeing is
2004/05/31 15:26:02| Ready to serve requests.
Let's give it a test drive. Configure a Web browser on the Squid server. Tell it "localhost" and "port 3128." Start Web surfing. You should be able to cruise the Web without a care. To make sure it's going through Squid, shut Squid down by hitting ctrl+c. Now when you click a link, it should give an error message like "The connection was refused when attempting to contact the proxy server."
Other clients on the LAN can connect either by the Squid server's IP or hostname, and port. You now have a functioning http caching server. Come back next week for more details on access control lists, and additional Squid management tips and tricks.