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.

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 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"
                

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!

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 :

Figure 3.1. 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.

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