6.3 Common Scenarios

Because access controls can be complicated, this section contains a few examples. They demonstrate some of the common uses for access controls. You should be able to adapt them to your particular needs.

6.3.1 Allowing Local Clients Only

Almost every Squid installation should restrict access based on client IP addresses. This is one of the best ways to protect your system from abuses . The easiest way to do this is write an ACL that contains your IP address space and then allow HTTP requests for that ACL and deny all others:

 acl All src 0/0 acl MyNetwork src 172.16.5.0/24 172.16.6.0/24 http_access allow MyNetwork http_access deny All 

Most likely, this access control configuration will be too simple, so you'll need to add more lines. Remember that the order of the http_access lines is important. Don't add anything after deny All . Instead, add the new rules before or after allow MyNetwork as necessary.

6.3.2 Blocking a Few Misbehaving Clients

For one reason or another, you may find it necessary to deny access for a particular client IP address. This can happen, for example, if an employee or student launches an aggressive web crawling agent that consumes too much bandwidth or other resources. Until you can stop the problem at the source, you can block the requests coming to Squid with this configuration:

 acl All src 0/0 acl MyNetwork src 172.16.5.0/24 172.16.6.0/24 acl ProblemHost src 172.16.5.9 http_access deny ProblemHost http_access allow MyNetwork http_access deny All 

6.3.3 Denying Pornography

Blocking access to certain content is a touchy subject. Often, the hardest part about using Squid to deny pornography is coming up with the list of sites that should be blocked. You may want to maintain such a list yourself, or get one from somewhere else. The "Access Controls" section of the Squid FAQ has links to freely available lists.

The ACL syntax for using such a list depends on its contents. If the list contains regular expressions, you probably want something like this:

 acl PornSites url_regex "/usr/local/squid/etc/pornlist" http_access deny PornSites 

On the other hand, if the list contains origin server hostnames, simply change url_regex to dstdomain in this example.

6.3.4 Restricting Usage During Working Hours

Some corporations like to restrict web usage during working hours, either to save bandwidth, or because policy forbids employees from doing certain things while working. The hardest part about this is differentiating between appropriate and inappropriate use of the Internet during these times. Unfortunately, I can't help you with that. For this example, I'm assuming that you've somehow collected or acquired a list of web site domain names that are known to be inappropriate. The easy part is configuring Squid:

 acl NotWorkRelated dstdomain "/usr/local/squid/etc/not-work-related-sites" acl WorkingHours time D 08:00-17:30 http_access deny !WorkingHours NotWorkRelated 

Notice that I've placed the !WorkingHours ACL first in the rule. The dstdomain ACL is expensive (comparing strings and traversing lists), but the time ACL is a simple inequality check.

Let's take this a step further and understand how to combine something like this with the source address controls described previously. Here's one way to do it:

 acl All src 0/0 acl MyNetwork src 172.16.5.0/24 172.16.6.0/24 acl NotWorkRelated dstdomain "/usr/local/squid/etc/not-work-related-sites" acl WorkingHours time D 08:00-17:30 http_access deny !WorkingHours NotWorkRelated http_access allow MyNetwork http_access deny All 

This scheme works because it accomplishes our goal of denying certain requests during working hours and allowing requests only from your own network. However, it might be somewhat inefficient. Note that the NotWorkRelated ACL is searched for all requests, regardless of the source IP address. If that list is long, you'll waste CPU resources by searching it for requests from outside your network. Thus, you may want to change the rules around somewhat:

 http_access deny !MyNetwork http_access deny !WorkingHours NotWorkRelated http_access Allow All 

Here we've delayed the most expensive check until the very end. Outsiders that may be trying to abuse Squid will not be wasting your CPU cycles.

6.3.5 Preventing Squid from Talking to Non-HTTP Servers

You need to minimize the chance that Squid can communicate with certain types of TCP/IP servers. For example, people should never be able to use your Squid cache to relay SMTP (email) traffic. I covered this previously when introducing the port ACL. However, it is such an important part of your access controls that I'm presenting it here as well.

First of all, you have to worry about the CONNECT request method. User agents use this method to tunnel TCP connections through an HTTP proxy. It was invented for HTTP/TLS (a.k.a SSL) requests, and this remains the primary use for the CONNECT method. Some user-agents may also tunnel NNTP/TLS traffic through firewall proxies. All other uses should be rejected. Thus, you'll need an access list that allows CONNECT requests to HTTP/TLS and NNTP/TLS ports only.

Secondly, you should prevent Squid from connecting to certain services such as SMTP. You can either allow safe ports or deny dangerous ports. I'll give examples for both techniques.

Let's start with the rules present in the default squid.conf file:

 acl Safe_ports port 80          # http acl Safe_ports port 21          # ftp acl Safe_ports port 443 563     # https, snews acl Safe_ports port 70          # gopher acl Safe_ports port 210         # wais acl Safe_ports port 280         # http-mgmt acl Safe_ports port 488         # gss-http acl Safe_ports port 591         # filemaker acl Safe_ports port 777         # multiling http acl Safe_ports port 1025-65535  # unregistered ports acl SSL_ports port 443 563 acl CONNECT method CONNECT http_access deny !Safe_ports http_access deny CONNECT !SSL_ports <additional http_access lines as necessary...> 

Our Safe_ports ACL lists all privileged ports (less than 1024) to which Squid may have valid reasons for connecting. It also lists the entire nonprivileged port range. Notice that the Safe_ports ACL includes the secure HTTP and NNTP ports (443 and 563) even though they also appear in the SSL_ports ACL. This is because the Safe_ports ACL is checked first in the rules. If you swap the order of the first two http_access lines, you could probably remove 443 and 563 from the Safe_ports list, but it's hardly worth the trouble.

The other way to approach this is to list the privileged ports that are known to be unsafe:

 acl Dangerous_ports 7 9 19 22 23 25 53 109 110 119 acl SSL_ports port 443 563 acl CONNECT method CONNECT http_access deny Dangerous_ports http_access deny CONNECT !SSL_ports <additional http_access lines as necessary...> 

Don't worry if you're not familiar with all these strange port numbers . You can find out what each one is for by reading the /etc/services file on a Unix system or by reading IANA's list of registered TCP/UDP port numbers at http://www.iana.org/assignments/port-numbers.

6.3.6 Giving Certain Users Special Access

Organizations that employ username-based access controls often need to give certain users special privileges. In this simple example, there are three elements: all authenticated users, the usernames of the administrators, and a list of pornographic web sites. Normal users aren't allowed to view pornography, but the admins have the dubious job of maintaining the list. They need to connect to all servers to verify whether or not a particular site should be placed in the pornography list. Here's how to accomplish the task:

 auth_param basic program /usr/local/squid/libexec/ncsa_auth     /usr/local/squid/etc/passwd acl Authenticated proxy_auth REQUIRED acl Admins proxy_auth Pat Jean Chris acl Porn dstdomain "/usr/local/squid/etc/porn.domains" acl All src 0/0 http_access allow Admins http_access deny Porn http_access allow Authenticated http_access deny All 

Let's examine how this all works. First, there are three ACL definitions. The Authenticated ACL matches any valid proxy authentication credentials. The Admins ACL matches valid credentials from users Pat, Jean, and Chris. The Porn ACL matches certain origin server hostnames found in the porn.domains file.

This example has four access control rules. The first checks only the Admins ACL and allows all requests from Pat, Jean, and Chris. For other users, Squid moves on to the next rule. According to the second rule, a request is denied if its origin server hostname is in the porn.domains file. For requests that don't match the Porn ACL, Squid moves on to the third rule. Here, the request is allowed if it contains valid authentication credentials. The external authenticator ( ncsa_auth in this case) is responsible for deciding whether or not the credentials are valid. If they aren't, the final rule applies, and the request is denied.

Note that the ncsa_auth authenticator isn't a requirement. You can use any of the numerous authentication helpers described in Chapter 12.

6.3.7 Preventing Abuse from Siblings

If you open up your cache to peer with other caches, you need to take additional precautions . Caches often use ICP to discover which objects are stored in their neighbors. You should accept ICP queries only from known and approved neighbors.

Furthermore, you can configure Squid to enforce a sibling relationship by using the miss_access rule list. Squid checks these rules only when forwarding cache misses, never cache hits. Thus, all requests must first pass the http_access rules before the miss_access list comes into play.

In this example, there are three separate ACLs. One is for the local users that connect directly to this cache. Another is for a child cache, which is allowed to forward requests that are cache misses. The third is a sibling cache, which must never forward a request that results in a cache miss . Here's how it all works:

 alc All src 0/0 acl OurUsers src 172.16.5.0/24 acl ChildCache src 192.168.1.1 acl SiblingCache src 192.168.3.3 http_access allow OurUsers http_access allow ChildCache http_access allow SiblingCache http_access deny All miss_access deny SiblingCache icp_access allow ChildCache icp_access allow SiblingCache icp_access deny All 

6.3.8 Denying Requests with IP Addresses

As I mentioned in Section 6.1.2.4, the dstdomain type is good for blocking access to specific origin servers. However, clever users might be able to get around the rule by replacing URL hostnames with their IP addresses. If you are desperate to stop such requests, you may want to block all requests that contain an IP address. You can do so with a redirector (see Chapter 11) or with a semicomplicated dstdom_regex ACL like this:

 acl IPForHostname dstdom_regex ^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+$ http_access deny IPForHostname 

6.3.9 An http_reply_access Example

Recall that the response's content type is the only new information available when Squid checks the http_reply_access rules. Thus, you can keep the http_reply_access rules very simple. You need only check the rep_mime_type ACLs. For example, here's how you can deny responses with certain content types:

 acl All src 0/0 acl Movies rep_mime_type video/mpeg acl MP3s rep_mime_type audio/mpeg http_reply_access deny Movies http_reply_access deny MP3s http_reply_access allow All 

You don't need to repeat your http_access rules in the http_reply_access list. The allow All rule shown here doesn't mean that all requests to Squid are allowed. Any request that is denied by http_access never makes it to the stage where Squid checks the http_reply_access rules.

6.3.10 Preventing Cache Hits for Local Sites

If you have a number of origin servers on your network, you may want to configure Squid so that their responses are never cached. Because the servers are nearby, they don't benefit too much from cache hits. Additionally, it frees up storage space for other (far away) origin servers.

The first step is to define an ACL for the local servers. You might want to use an address-based ACL, such as dst :

 acl LocalServers dst 172.17.1.0/24 

If the servers don't live on a single subnet, you might find it easier to create a dstdomain ACL:

 acl LocalServers dstdomain .example.com 

Next, you simply deny caching of those servers with a no_cache access rule:

 no_cache deny LocalServers 

The no_cache rules don't prevent your clients from sending these requests to Squid. There is nothing you can configure in Squid to stop such requests from coming. Instead, you must configure the user-agent s themselves .

If you add a no_cache rule after Squid has been running for a while, the cache may contain some objects that match the new rule. Prior to Squid Version 2.5, these previously cached objects might be returned as cache hits. Now, however, Squid purges any cached response for a request that matches a no_cache rule.