• Choose a category
• All
• Classic-Fiction

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.

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

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

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

* * *

Tip

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