28.7. Configure of the /etc/squid/squid.conf file -/proxy-caching mode

With some minor modification to the squid.conf file we have defined above to run in httpd-accelerator mode, we can run Squid as a proxy-caching server. With a proxy cache server, all users in your corporate network use Squid to access the Internet. With this configuration, you can have complete control, and apply special policies on what can be viewed, accessed, and downloaded. You can also control bandwidth usage, connection time, and so on. A proxy cache server can be configured to run as stand-alone server for your corporation, or to use and share caches hierarchically with other proxy servers around the Internet.

With the first example below we show you how to configure Squid as a stand-alone server, and then speak a little bit about a cache hierarchy configuration, where two or more proxy-cache servers cooperate by serving documents to each other. Edit the squid.conf file, vi /etc/squid/squid.conf and add/change the following options for proxy cache that run as a stand-alone server:

http_port 8080 icp_port 0 acl QUERY urlpath_regex cgi-bin \? no_cache deny QUERY cache_mem 16 MB cache_dir ufs /cache 200 16 256 redirect_rewrites_host_header off replacement_policy GDSF acl localnet src 192.168.1.0/255.255.255.0 acl localhost src 127.0.0.1/255.255.255.255 acl Safe_ports port 80 443 210 119 70 21 1025-65535 acl CONNECT method CONNECT acl all src 0.0.0.0/0.0.0.0 http_access allow localnet http_access allow localhost http_access deny !Safe_ports http_access deny CONNECT http_access deny all cache_mgr [email protected] cache_effective_user squid cache_effective_group squid log_icp_queries off cachemgr_passwd my-secret-pass all buffered_logs on

The big difference with the httpd-accellerator mode configuration is the use of access control lists (ACL). This feature allows you to restrict access based on source IP address (src), destination IP address (dst), source domain, destination domain, time, and so on. Many types exist with this feature, and you should consult the Squid.conf file for a complete list. The four most used types are as follows:

                   acl  name   type    data
                   |     |    |    |
                   acl some-name src a.b.c.d/e.f.g.h  # ACL restrict access based on source IP address 
                   acl some-name dst a.b.c.d/e.f.g.h  # ACL restrict access based on destination IP address 
                   acl some-name srcdomain foo.com  # ACL restrict access based on source domain 
                   acl some-name dstdomain foo.com  # ACL restrict access based on destination domain
                 

As an example, to restrict access to your Squid proxy server to only your internal clients, and to a specific range of designated ports, something like the following will make the job:

acl localnet src 192.168.1.0/255.255.255.0 acl localhost src 127.0.0.1/255.255.255.255 acl Safe_ports port 80 443 210 119 70 21 1025-65535 acl CONNECT method CONNECT acl all src 0.0.0.0/0.0.0.0 http_access allow localnet http_access allow localhost http_access deny !Safe_ports http_access deny CONNECT http_access deny all

This acl configuration will allow all internal clients from the private class C 192.168.1.0 to access the proxy server; it's also recommended that you allow the localhost IP (a special IP address used by your own server) to access the proxy. After we choose a range of ports (80=http, 443=https, 210=wais, 119=nntp, 70=gopher, and 21=ftp) which our internal clients can use to access the Internet, we deny the CONNECT method to prevent outside people from trying to connect to the proxy server, and finally, we deny all source IP address and ports on the proxy server.

Multi-level Web Caching The second method of proxy cache is the so-called Multi-level Web Caching where you choose to share and cooperate with more proxy-cache servers on the Internet. With this method, your organization uses the cache of many others proxy cache servers, and to compensate, the other cache server can use yours. It's important to note that in this situation, the proxy cache can play two different roles in the hierarchy. It can be configured to be a sibling cache, and be able to only serve documents it already has, or it can be configured as a parent cache, and be able to get documents from another cache or from the source directly.