9.4. 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.

9.4.1. 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.

9.4.2. Assigning Rights

After access lists have been created, access rights for each of them can be assigned using the following commands:

http_access allowdeny 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 allowdeny ACL_name Specifies access rights to the proxy server over ICP. By default, access is denied to all:
```
 icp_access deny all 
```
miss_access allowdeny 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 
```

9.4.3. 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 onoff If set to on, access from other IP addresses is disallowed until the time specified in authenticate_ip_ttl expires .