6.4 Testing Access Controls

As your access control configuration becomes longer, it also becomes more complicated. I strongly encourage you to test your access controls before turning them loose on a production server. Of course, the first thing you should do is make sure that Squid can correctly parse your configuration file. Use the -k parse feature for this:

 % squid -k parse 

To further test your access controls, you may need to set up a fake Squid installation. One easy way to do that is compile another copy of the Squid source code with a different $prefix location. For example:

 % tar xzvf squid-2.5.STABLE4.tar.gz % cd squid-2.5.STABLE4 % ./configure --prefix=/tmp/squid ... % make && make install 

After installing, you need to edit the new squid.conf file and change a few directives. Change http_port if Squid is already running on the default port. For simple testing, create a single, small cache directory like this:

 cache_dir ufs /tmp/squid/cache 100 4 4 

If you don't want to recompile Squid again, you can also just create a new configuration file. The drawback to this approach is that you'll need to set all the log-file pathnames to the temporary location so that you don't overwrite the real files.

You can easily test some access controls with the squidclient program. For example, if you have a rule that depends on the origin server hostname ( dstdomain ACL), or some part of the URL ( url_regex or urlpath_regex ), simply enter a URI that you would expect to be allowed or denied :

 % squidclient -p 4128 http://blocked.host.name/blah/blah 

or:

 % squidclient -p 4128 http://some.host.name/blocked.ext 

Certain aspects of the request are harder to control. If you have src ACLs that block requests from outside your network, you may need to actually test them from an external host. Testing time ACLs may be difficult unless you can change the clock on your system or stay awake long enough.

You can use squidclient 's -H option to set arbitrary request headers. For example, use the following if you need to test a browser ACL.

 % squidclient -p 4128 http://www.host.name/blah \       -H 'User-Agent: Mozilla/5.0 (compatible; Konqueror/3)\r\n' 

For more complicated request, with many headers, you may want to use the technique described in Section 16.4.

You might also consider developing a routine cron job that checks your ACLs for expected behavior and reports any anomalies. Here is a sample shell script to get you started:

 #!/bin/sh set -e TESTHOST="www.squid-cache.org" # make sure Squid is not proxying dangerous ports # ST=`squidclient 'http://$TESTHOST:25/'  head -1  awk '{print }'` if test "$ST" != 403 ; then         echo "Squid did not block HTTP request to port 25" fi # make sure Squid requires user authentication # ST=`squidclient 'http://$TESTHOST/'  head -1  awk '{print }'` if test "$ST" != 407 ; then         echo "Squid allowed request without proxy authentication" fi # make sure Squid denies requests from foreign IP addresses # elsewhere we already created an alias 192.168.1.1 on one of # the system interfaces # EXT_ADDR=192.168.1.1 ST=`squidclient -l $EXT_ADDR 'http://$TESTHOST/'  head -1  awk '{print }'` if test "$ST" != 403 ; then         echo "Squid allowed request from external address $EXT_ADDR" fi exit 0