ACLs and Delay Pools Under Squid

Squid has many ways of restricting access to, and limiting what the users can do. We will cover basic access control lists, and how these can be used from forcing requests to go through a parent proxy to restricting access to the proxy. Additionally, we will cover how to password protect the proxy, and how to implement delay pools (restricting bandwidth use).

ACLs have many options to restrict access based on source ip address, destination ip address, source domain, and destination domain. This is done by: 

	acl src w.x.y.z/a.b.c.d   # ACL based on source ip address
	acl dst w.x.y.z/a.b.c.d	  # ACL based on destination ip address
	acl srcdomain foo.com	  # ACL based on source domain
	acl dstdomain foo.com	  # ACL based on destination domain
To use this to restrict access to your Squid proxy to only those hosts you wish - ie, local hosts, use the following directive format: 
	acl localnet src 192.168.1.0/255.255.255.0
	http_access allow localnet
	http_access deny all
In this example, we are restricting access to the private class C 192.168.1.0. You can have as many acl lines as you wish, specifying as many different source ip addresses as you want. Add another http_access allow line for each acl, and remember the lines are OR'ed together. If you wish to have multiple restrictions, put them on the same http_access line and they are AND'ed together.

To restrict access to the Squid proxy via the time, use the format: 

       acl aclname time     [day-abbrevs]  [h1:m1-h2:m2]
           day-abbrevs:
               S - Sunday
               M - Monday
               T - Tuesday
               W - Wednesday
               H - Thursday
               F - Friday
               A - Saturday
This can be used, for instance, to restrict access to work hours (9am - 5pm, Monday to Friday). 
	acl workdays time M T W H F 9:00-17:00
	http_access allow workdays
There are many other formats for access control lists, ranging from regular expressions based on the URL, source and destination domain name, the browser User-Agent string (string which identifies to the server what browser you are using), and more. See the default squid.conf distributed with Squid for more information.

It is also possible to force requests to either go directly to the source, or to go through any parent or sibling proxies. Forcing all traffic through neighbourhood proxies is useful in a situation where traffic to the parent proxy is a lower cost than direct traffic. Forcing traffic to go directly to the server is usually used to force local requests (for example, hosts in an intranet). The standard way of configuring this is: 

	acl local-intranet dstdomain host.domain.com
	always_direct allow local-intranet
	never_direct deny local-intranet
	never_direct allow all
Squid also has support for proxy authentication. This is a simple idea that reads in a username and password, runs the specified authentication program, and either returns OK, if the username / password combination is correct, or ERR if it is not, in an endless loop. This can be used in many ways - simple system password lookups, database lookups or even a LDAP query.

By default, Squid comes with traditional proxy authentication in the SQUID_SRC_ROOT/auth_modules/NCSA directory. To compile it, cd into this directory and type: 

	$ make
	# make install
Then add a line similar to the following to actually enable it: 
	authenticate_program /usr/bin/ncsa_auth /usr/etc/passwd
Then add an ACL line similar to the following: 
	acl authacl proxy_auth username .. # Use REQUIRED as a username for any
This can then be used in a http_access line, as follows: 
	http_access allow authacl
Any requests to the proxy then have to be authenticated. You can also specify the text string which is given to the user when they are asked for a username / password by: 
	proxy_auth_realm Squid proxy-caching web server
One issue with proxy authentication is, by default, it doesn't force authentication of FTP connections. This can be fixed by modifying the previous example to: 
	acl ftp proto FTP
	...
	http_access deny FTP
	http_access allow authacl

Another issue is that you can't use proxy authentication with transparent proxing. A better approach would be to set up a auto proxy.

Another useful squid feature is delay pools. Conceptually, delay pools are bandwidth limitations - ``pools'' of bandwidth that drain out as people browse the Web, and fill up at a rate you specify - this can be thought of as a leaky bucket that is continually being filled. This is useful when bandwidth charges are in place, as in Australia where volume charges are typical, or if you want to reduce bandwidth usage for web traffic.

To enable this, configure squid with the --enable-delay-pools option. There are 3 classes of delay pools - class 1 is a single aggregate bucket, class 2 is an aggregate bucket with an individual bucket for each host in the class C, and class 3 is an aggregate bucket, with a network bucket (for each class B) and an individual bucket for each host.

To configure the amount of delay pools, and specify which pool is which class, use the following format. 

	delay_pools 2      # 2 delay pools
	delay_class 1 2    # pool 1 is a class 2 pool
	delay_class 2 3    # pool 2 is a class 3 pool
To specify which pool a client falls into, create ACLs which specifies the ip ranges for each pool, and use the following: 
	delay_access 1 allow pool_1_acl
	delay_access 1 deny all
	delay_access 2 allow pool_2_acl
	delay_access 2 deny all
Setting the parameters for each pool is done by: 
	delay_parameters pool aggregate network individual
where ``aggregate'' is the parameter for the aggregate bucket, ``network'' for the network bucket, and ``individual'' for the individual bucket. Aggregate is only useful for classes 1, 2 and 3, network for classes 2 and 3, and individual for class 3.

Each of these parameters is specified as restore / maximum - restore being the bytes per second restored to the bucket, and maximum being the amount of bytes that can be in the bucket at any time. It is important to remember that they are in bytes per second, not bits. To specify that a parameter is unlimited, use a -1.

If you wish to limit any parameter in bits per second, divide this amount by 8, and use the value for both the restore and the maximum. For example, to restrict the entire proxy to 64kbps, use: 

	delay_parameters 1 8000/8000
It is also possible to specify how full the bucket starts: 
	delay_initial_bucket_level 50
where the value is the percentage full.

For further explanation and examples, please see the default squid.conf file comments.

As you can see, Squid provides many way of limiting access to it, both by restricting who can use it, and how much they can use it. There are many more options to Squid than covered here, but the defaults are reasonable for most cases.

Brad Marshall is a Systems Administrator for Plugged In Software, a software development company based in Brisbane, Australia. He has been using Linux for more than 5 years, and has a BSc majoring in Computer Science.