Squid_ The Definitive Guide - Duane Wessels [52]
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.
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
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 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. 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