How to configuration Squid ?

Squid is governed by a configuration file, normally residing in squid.conf

There is little other documentation shipped with squid in the form of manual or Texinfo (used by the info command) pages.

However, in addition to the well-commented configuration file, FAQ's and documentation also reside in the /usr/share/doc/squid directory. The official web site is not www.squid.org as may be expected, but http://www.squid-cache.org.

squid.conf is a mile long and has many options (129 in all I think). Luckily though, in order to get SQUID going as quickly as possible (although far from optimal), only 2 settings need be changed.

We will look at these two changes in this course but we will also spend some time examining some of the other 127 configuration options.
Setting the port on which SQUID listens

Out the box, SQUID will listen on port 3128 (the default). While it may be convenient to listen on this port, network administrators often configure the proxy to listen on port 8080.

This is a non-well-known port (ports below 1024 are well-known ports and are restricted from being used by ordinary users processes), and is therefore not going to be in conflict with other ports such as 80, 443, 22, 23, etc. SQUID needn't be restricted to one port. It could easily be started in 2 or more ports.

In the example below, I will start SQUID on both ports (8080 and 3128).

http_port 8080 3128


Additionally, if you have multiple network cards in your proxy server, you may wish to restrict the proxy to start on port 8080 on the first network card and port 3128 on the second network card.

http_port 192.168.0.1:8080 172.16.43.1:3128


One point worth noting is that there should be no other services running on these ports prior to starting the proxy server. If there are, SQUID will not start and you will need to consult the log files to determine what has caused SQUID this indigestion.

Finally, if you don't like the ports I've selected here, you are most welcome to choose your own, provided you adhere to the rule in the paragraph above.

If you choose a port below 1024, SQUID will need to be run as the root user, but this is not really a problem, as a new process will be spawned and this new process will run as the squid user.
The SQUID user

SQUID should not be run as root. In it's default mode, if SQUID is started as root, it will run as the effective user 'nobody', and the effective group 'nobody'.

As mentioned earlier, if you wish to run your squid on a port below 1024, you will need to start is as the 'root' user.

There are another two configuration options in the squid.conf file indicating which user and group should be used for the server.

cache_effective_group and cache_effective_user are the configuration files settings that are needed.

It is advised that you create a user squid (if it's not already there) as well as a group 'squid' and change the configuration file accordingly.

Once the user and group that you are going to use has been established we need to set up access to our proxy.
Access control to the proxy server

Access control is determined using two sets of configuration parameters. The first is the access control list (acl), and the second is the http_access list (http_access). The 'acl' really defines a synonym that we can use within the http_access list.

The general form of these acl lists is:

acl aclname acltype string1 ... | "file"


'acltype's can be any of (this is not the whole list!):
src the source address of the packet (e.g. Your IP address)
dst the destination address of the packet (e.g. The IP address/domain to which this packet was destined)
srcdomain the source domain of the packet (for this, SQUID must do a reverse name lookup to determine the source domain, adding to the latency)
dstdomain as in the source domain, only the domain for which the packet is destined
srcdom_regex a regular expression describing the source domain (e.g. QEDux.*)
dstdom_regex as in srcdom_regex A regular expression using the source or the destination domain. Be aware that this can cause delays as a result of lookups.
Time specify the time at which hosts can connect e.g. acl allowed_clients src 192.168.0.0/255.255.255.0 acl regular_days time MTWHF 10:00-16:00 http_access allow allowed_clients regular_days

Once we've defined the acl, we can use that to define the http_access files. We showed an example in the time acltype above, but let's look at others.

The general format of the http_access directive is:

http_access allow|deny [!]aclname ...


Thus, if we have an acl as follows:

acl allowed_clients src 192.168.1.0/255.255.255.0


The http_access line could read:

http_access allow allowed_clients


A couple of points to note regarding http_access lines are:

Each line is 'OR'ed with the next. Thus, having two lines as follows:

http_access allow allowed_clients


OR

http_access deny !allowed_clients


and this would allow the allowed_clients, but deny the clients that don't conform to the allowed_clients source address. The first match will cause squid to accept the request and no further lines will be matched. In typical OR style, "TRUE or anything" will always yield a TRUE result.

So order is important in the http_access lines.

If you consult your squid.conf file, you will notice in the acl there is an entry as follows:

acl all src 0.0.0.0/0.0.0.0


with an associated line, at the end of all http_access lines, as follows:

http_access deny all


The result is to deny all clients that have not matched a previous http_access rule. A 'catch-all' as it were.

Furthermore, each entry on the http_access line is 'AND'ed with the next entry.

In the 'time' example mentioned above:

http_access allow allowed_clients regular_days


this would be interpreted as:

http_access allow allowed_clients AND regular_days


This would be stating that if the client is on the 192.168.0.x network AND the time is between 10am and 4pm, allow access through the proxy.

Obviously we would also need to add a deny line somewhere below this, otherwise even though this line might not match, the client would still be allowed through the proxy.

let's look at some examples of acl's (comments above the lines indicate what I'm trying to achieve using them):

# Set the source address for the 'alias' QEDux.net.work
# (clients on this network in range 10.0.1.x)
acl QEDux.net.work src 10.0.1.0/255.255.255.0

# Set the source address for the 'alias' QEDux.net.home
# (clients on this network in range 192.168.43.x)
acl QEDux.net.home src 192.168.43.0/255.255.255.0

# Although defender is on the network 10.0.1.x,
# I am specifically specifying it based on it's MAC address
acl defender_arp arp 00:01:03:8C:FB:01

# Disallow access to any url containing the word \
sex or porn or adult.
# Note too the use of the -i option, which will \
match the RE in a
# case insensitive manner
acl blacklist_sites url_regex -i sex porn adult


Now for the http_access lines:

# Ensure that this is not defender that is trying \
to use the proxy
http_access deny defender_arp

# Ensure that anybody trying to use the proxy is \
not going to an
# adult/porn/sex site
http_access deny blacklist_sites

# Otherwise allow users on the domains \
QEDux.net.{home,work} to
# use the proxy (and thus use the Internet)
http_access allow QEDux.net.work \
QEDux.net.home

# Otherwise deny all clients that don't fit these patterns
http_access deny all


By default, SQUID as shipped in it's shrink wrapping, only allows access to the localhost using the http_access directives. Thus, in it's simplest form, you will be required to add an acl line for your network, as well as an entry in the squid.conf file to allow access from hosts on your network.

A comment in the squid.conf file as follows shows where you should add your own rules:

.....
#
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS \
FROM YOUR CLIENTS
#
.....


Some final notes regarding blacklisting sites are:

Instead of having a regex that will match sites, you could include all the blacklist sites in an external file, and change your acl to read as follows:

acl blacklist_sites url_regex "/etc/blacklisted_sites.txt"


Now all you would need to do is to add the sites you which to blacklist in this text file and bingo, you've solved a problem.

It is worth noting that denying access to certain sites will probably require that you, or your company, has a policy laid down in advance that employees are aware of. Post contractually laying down the law is not legal and you (or your company) could find yourselves in hot water. It is a warning, and with users becoming more aware of their rights, it is worthwhile consulting a lawyer prior to undertaking such a policy on the proxy.

My personal means of dealing with 'abuse' of the Internet it to automate a process of publishing the users of the Internet in order of sites they've recently visited. That way, if Joe's name appears at the top of the list for www.playboy.com, it could become an embarrassment at tea time when people begin to quiz him about it!
Exercises:

1.

Configure a acl/http_access directives that will allow times of usage of the Internet to lunchtime and after 5pm.
2.

Configure an acl/http_access directive to allow users on the 172.16.43 network, but deny particular hosts 172.16.43.149 and 153.
3.

Configure an acl/http_access directive to disallow users with the MAC addresses 00:10:11:96:A1:C3, C5 and 96:EF:15
4.

Given the following http_access directives, what is the outcome: The acl is given as follows:

acl Safe_ports port 80 21 443 563 70 210 1025-65535
acl CONNECT method CONNECT

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

acl ip_acl src 192.168.2.0/24
acl time_acl time M T W H F 9:00-17:00
http_access allow ip_acl time_acl

acl hosts1 src192.168.0.10
acl hosts2 src 192.168.0.20
acl hosts3 src 192.168.0.30
acl morning time 10:00-13:00
acl lunch time 13:30-14:30
acl evening time 15:00-18:00

http_access allow host1 morning
http_access allow host1 evening
http_access allow host2 lunch
http_access allow host3 evening
http_access deny all


Setting the cache_dir

At this point you may be itching to start your proxy, but wait. There's more!

Out the box, SQUID ships with a default cache size of 100Mb and this may need to be changed depending on how large a site you proxy is handling.

If you are just testing at this stage, leave the defaults. However, you should be aware of what the figures mean after the path to the cache directory.

The general format of the cache_dir directive is:

cache_dir Type Maxobjsize Directory-Name Mbytes \
Level-1 Level2 [..]


where :

*

Type is generally ufs (although it can be other things too - consult the squid.conf file)
*

Maxobjsize is the maximum object size the storage directory supports. This can be omitted
*

Directory-Name is the name of the top-level directory. You may well wish to store your cache in /var/cache or /var/spool/cache or /var/spool/squid. You would specify this here.
*

Mbytes, by default out the shrink-wrapping, this is 100Mb. However this is a really small cache and it will most likely be exhausted quite soon when using the cache - even for a small organization. Remember that exhausting the cache will not affect your access to the Internet, but will certainly increase latency to the sites you are visiting.
*

The last two entries, Level-1 and Level-2 are the number of first-tier directories that will be created under the Directory-Name, and Level-2, the number of 2nd tier directories under the first-tier

Figure 3.1. Squid Directory Levels
Squid Directory Levels

Note that Squid does not automatically create the hierarchy of directories required to cache your pages. You can do this using:

/usr/sbin/squid -z


The best means of starting squid first time is to start it by hand. Assuming you know where your squid binary lives, you could do something like:

/usr/sbin/squid -N -d 1 -D


This will not put squid into the background, but will spew all the output to the console.

*

The -d 1 option is the amount of debugging information it will show. Increasing the number after the -d will show more debug information.
*

The -N option will not put squid into the background, but it will continue to run in the foreground, while the -D option will disable initial DNS tests.

If, on the output, you see:

Ready to serve requests


your proxy server is ready to be used. If not, read the log carefully to determine what the problem is. Once you have tested the proxy, you can CTRL-C this squid process and start it as the init scripts would do (in Debian that would be /etc/init.d/squid start).

Original article here