Configuring the HTTP Proxy on the Server Side

HTTP Proxy Configuration

Once the Squid software has been installed, we need to configure it before we can use the HTTP Proxy. On the server side, this is done by editing the /etc/squid/squid.conf file. Before we start updating it, though, we need to back it up and make sure it doesn't get deleted or overwritten, for example:

$ sudo cp /etc/squid/squid.conf /etc/squid/squid.conf.orig
$ sudo chmod a-w /etc/squid/squid.conf.orig
$ sudo vi /etc/squid/squid.conf

This will ensure that, if something goes wrong in the editing, that you have something to fall back to.

Once the default configuration file has been backed up, we can begin customising it. The following are some of the common changes that you can make to the /etc/squid/squid.conf file (-note that none of these options need to be changed for Squid to work, only if you are not happy with the defaults shown below):

Squid normally listens on port 3128 - if you want to change this, update the following line to cite the desired port:
```
http_port <Port Number>
```
For example:
```
http_port 1234
```
Note: be sure to check the desired port is not in use (-e.g. not already assigned in the /etc/services file)
If you want to restrict access to the proxy (-and you should), then add a line, in the following format, to the end of the ACL section:
```
acl <Unique ACL Name> src <First IP>/<Net Mask>
```
For example, you could define an ACL called "localNetwork" as the group of computers on your local network using:
```
>#Recommended minimum configuration:
acl all src all
acl manager proto cache_object
acl localhost src 127.0.0.1/32
acl to_localhost dst 127.0.0.0/8 0.0.0.0/32
acl localNetwork src 192.168.1.2/24
```
Next - add a rule to "allow" access to to the group of IPs defined in the new ACL - using the following format:
```
http_access allow <Unique ACL Name>
```
For example, to allow all access to all computers on our "localNetwork" ACL, use:
```
http_access allow localNetwork
```
Note: see the Squid manual for more details on the acl and http_access directives

By default, Squid will run under the "proxy" user. If you want it to run as another user, you need to create that user (e.g. using useradd) and to update the following line to state the new user:

cache_effective_user  <Username>

For example:

#  TAG: cache_effective_user
#       If you start Squid as root, it will change its effective/real
#       UID/GID to the user specified below.  The default is to change
#       to UID to proxy.  If you define cache_effective_user, but not
#       cache_effective_group, Squid sets the GID to the effective
#       user's default group ID (taken from the password file) and
#       supplementary group list from the from groups membership of
#       cache_effective_user.
#
#Default:
cache_effective_user proxy

By default, Squid will run under the "proxy" group. If you want it to run as another group, you need to first create that group (e.g. using groupadd) and to update the following line to reference the desired group:

cache_effective_group <Groupname>

For example:

#  TAG: cache_effective_group
#       If you want Squid to run with a specific GID regardless of
#       the group memberships of the effective user then set this
#       to the group (or GID) you want Squid to run as. When set
#       all other group privileges of the effective user is ignored
#       and only this GID is effective. If Squid is not started as
#       root the user starting Squid must be member of the specified
#       group.
#
#Default:
# none
cache_effective_group proxy

By default, Squid will send any alert messages to a local email account called "webmaster": you should change this so this goes to your email account (-as the cache administrator) instead:

cache_mgr <Email Address>

For example:

#  TAG: cache_mgr
#       Email-address of local cache manager who will receive
#       mail if the cache dies. The default is "webmaster".
#
#Default:
cache_mgr fred.bloggs@linuceum.com

Here is an example of an updated /etc/squid/squid.conf file (-changes highlighted):

# Squid normally listens to port 3128
http_port 1234

#Recommended minimum configuration:
acl all src all
acl manager proto cache_object
acl localhost src 127.0.0.1/32
acl to_localhost dst 127.0.0.0/8 0.0.0.0/32
acl localNetwork src 192.168.1.2-192.168.1.3


#Recommended minimum configuration:
#
# Allow only local clients to connect - Fred Bloggs, 1st February 2011
http_access allow localNetwork
# Only allow cachemgr access from localhost
http_access allow manager localhost
http_access deny manager
# Only allow purge requests from localhost
http_access allow purge localhost
http_access deny purge
# Deny requests to unknown ports
http_access deny !Safe_ports
# Deny CONNECT to other than SSL ports
http_access deny CONNECT !SSL_ports

#  TAG: cache_effective_user
#       If you start Squid as root, it will change its effective/real
#       UID/GID to the user specified below.  The default is to change
#       to UID to proxy.  If you define cache_effective_user, but not
#       cache_effective_group, Squid sets the GID to the effective
#       user's default group ID (taken from the password file) and
#       supplementary group list from the from groups membership of
#       cache_effective_user.
#
#Default:
cache_effective_user squid

#  TAG: cache_effective_group
#       If you want Squid to run with a specific GID regardless of
#       the group memberships of the effective user then set this
#       to the group (or GID) you want Squid to run as. When set
#       all other group privileges of the effective user is ignored
#       and only this GID is effective. If Squid is not started as
#       root the user starting Squid must be member of the specified
#       group.
#
#Default:
# none
cache_effective_group squid


#  TAG: cache_dir
#       Usage:
.... etc ......
#Default:
cache_dir ufs /var/spool/squid 100 16 256

Note: it is probably best to make the minimum (-or no) changes to the etc/squid/squid.conf file to begin with. Make a single change, then check Squid is working as expected before moving on to the next change. Always change one thing at a time and test it out, rather than making too many changes in one go.

Finally, restart the Squid daemon, to pick up the configuration changes made:

$ sudo service squid restart

The output should be something like the following:

$ sudo service squid restart
$ ps -ef | grep squid
root      2953     1  0 17:38 ?        00:00:00 /usr/sbin/squid
proxy     2955  2953  0 17:38 ?        00:00:00 (squid)
root      2960  2670  0 17:39 pts/0    00:00:00 grep --color=auto squid

The server side should now be up and running - and you can move on to configure the clients