Squid Access Rights
This is the sorest subject for any administrator. Yes, access rights to various squid functions are controlled in squid, and they are defined in the /etc/squid/squid.conf configuration file. But because the main emphasis of this book is on the security aspects of Linux, I devoted this subject to a separate section.
Access Control List
The first thing to consider is the ACL, which is a powerful tool for configuring site access rights. Using a list of names, actions or users can be grouped. The tag is issued in the following format:
acl name type string
The functions of the tag's three parameters are the following:
name — This can be any name, preferably descriptive of the actions performed.
decision_string — This is a template whose function depends on the type of operation specified in the second argument.
type — This parameter can take on the following values: src, dst, srcdomain, dstdomain, url_pattern, urlpath_pattern, time, port, proto, proxy_auth, method, browser, or user. The functions of the main types, specifying how to interpret the preceding parameter (decision_string), are as follows:
src — Access is controlled by source IP addresses.
dst — Access is controlled by destination IP addresses.
port — Access is controlled by the destination port number.
proto — A list of protocols is given delimited by a space.
method — This specifies the type of the method of the request; for example, POST or GET.
proxy_auth — This requires an external authentication program to check user name and password combinations. With REQUIRED put as a user name (i.e., acl password proxy_auth REQUIRED) allows any valid user name to be accepted.
url_regex — This instructs the function to search the entire URL for the regular expression you specify.
time — This indicates the time in the format day h1:m1 - h2:m2. This string can be used to restrict access to only specified days of the week and times of day. The abbreviations for the days of week are the following: s for Sunday, M for Monday, T for Tuesday, w for Wednesday, H for Thursday, F for Friday, A for Saturday.
The configuration file already contains several lists that are ready to use and usually do not have to be edited. These are shown in Listing 9.1.
Listing 9.1: Default ACL rules in the /etc/squid/squid.conf configuration file
acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl SSL_ports port 443 563
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 1025-65535 # unregistered ports
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 CONNECT method CONNECTs
The preceding list is the minimum recommended ACL configuration.
The first entry specifies an acl named all. The src type of decision string means this list covers all users whose IP address matches 0.0.0.0/0.0.0.0, that is, all users.
The next entry creates an ACL class named manager. It defines access to the cache_object protocol, as specified by the proto type and the cache_object decision string. And so on.
Now, try to create your own ACL class. Suppose you have to allow access to the Internet for ten computers in your network with addresses from 192.168.8.1 to 192.168.8.10 (the subnet mask is 255.255.255.0). Access should be denied to all other computers in the network
When creating the list, you should start by denying access to all and then allowing it only to those who require it. A class for all users already exists in the default list: acl all src 0.0.0.0/0.0.0.0. A list for ten computers is named, for example, AllowUsers; its decision string is of the src type, the decision string itself being the range of addresses in question. Here is how it looks:
acl AllowUsers src 192.168.8.1-192.168.8.10/255.255.255.0
This ACL class, named AllowUsers, includes all computers in the specified address range.
Assigning Rights
After access lists have been created, access rights for each of them can be assigned using the following commands:
http_access allow|deny ACL_name — Specifies access rights to HTTP. In the following example, all users, except those specified in the AllowUsers ACL, are prohibited access to HTTP:
http_access deny all
http_access allow AllowUsers
By specifying access rights for the AllowUsers ACL, all it takes is one line to allow access for all computers included in this ACL. This eliminates the need to specify rights for each computer and makes the lives of administrators of big networks much easier.
In the previous example, only computers in the 192.168.8.1 to 192.168.8.10 address range were allowed access to the Internet. Access will be denied to any computer trying to access the Internet from any other address.
icp_access allow|deny ACL_name — Specifies access rights to the proxy server over ICP. By default, access is denied to all:
icp_access deny all
miss_access allow|deny ACL_name — Specifies rights to receive the MISSES reply. In the following example, only local users have the rights to receive the MISSES reply; all other users can only receive the HITS reply:
act localclients src 172.16.0.0/16
miss_access allow localclients
miss_access deny !localclients
Authentication
Using an IP address to limit access rights does not guarantee that the IP address cannot be faked. Moreover, there always exists a possibility that the wrong people can obtain the physical access to the computer allowed access to the Internet. Once they do, what they do with it is up their good, or ill, will.
I used to work for a company, in which each employee was allotted a certain monthly download limit, with the excess paid for by the employee. The authentication procedure was based on the IP address.
Note Authentication does not work if squid is configured to work in the transparent mode.
Once, several employees were noticed to have gone over their traffic limit significantly. This would have been no big deal, except these guys were away on vacation. Someone was faking their IP addresses and using their share of the Internet traffic.
To prevent something similar from happening to you, you should employ supplementary protection by checking the user name and password. This is done using the following directive:
authenticate_program path_to_program path_to_pswdfile
The directive specifies the path to the external authentication program and the path to the password file. By default, the authenticator program is not used. The traditional proxy-authentication program can be specified by the following directive:
authenticate_program /usr/lib/squid/ncsa_auth /usr/etc/passwd
The path to the ncsa_auth program may be different for your system.
You must have at least one ACL of the proxy_auth type to be able to use the authentication feature of the proxy server.
Consider the following directives:
authenticate_children n — Specifies the number of concurrent authentication processes to spawn. One process cannot perform authentication of several clients at once; consequently, while one user is being authenticated, no other users will be able to access the Internet using the proxy server.
authenticate_ttl n hour — Indicates the time in hours that the authenticated user name-password pair remains cached. During this time, the user can work without having to undergo the authentication process again. The default value is 1 hour; however, if a wrong password is entered, the pair is removed from the cache.
authenticate_ip_ttl 0 second — Specifies how long a proxy authentication will be bound to a specific IP address. The purpose of this directive is to prevent password sharing. Setting it to 0 will prevent users logging in with the same password from different IP addresses. For dial-up users, this value can be increased to 60 seconds, so that the user can redial in case of a connection break. However, dynamic IP addresses are normally used for dial-up connections, with a new address given for each connection; consequently, it is not guaranteed that the original address will be given for the repeated call.
authenticate_ip_ttl_is_strict on|off — If set to on, access from other IP addresses is disallowed until the time specified in authenticate_ip_ttl expires.