Web proxies allow employees to browse the Net quickly and safely. Web proxies cache content and allow subsequent requests for the same pages to be served by local cache, which is faster than returning to the sites multiple times. Proxies can also scan incoming web traffic for malicious content and protect end users from viruses, and they allow control over what web content is accessed by what users. To take advantage of all these features, let's walk through the process of installing and configuring a simple web proxy with virus filtering.
A perfect secure web proxy consists of the following components:
We'll run our proxy server on a basic CentOS 6 platform with no package groups preinstalled. For a really bare-minimum installation you can use the minimal image from the official mirrors page. Once we have the operating system installed we can install the proxy server's components.
Squid is available from the official CentOS 6 repository. You can install it by executing yum install squid. Ensure that Squid is automatically started and shut down with the system by adding it to the default system startup and shutdown levels with the command chkconfig squid on.
yum install squid
chkconfig squid on
By default, Squid's main configuration file /etc/squid/squid.conf allows requests from local networks on common ports. Uncomment the line cache_dir ufs /var/spool/squid 100 16 256 so that the proxy caches files on disk. The parameters of this directive instruct the proxy to use the default ufs storage format. The caching directory is /var/spool/squid, and it should store up to 100MB of content with 16 first-level subdirectories and 256 second-level subdirectories. Consider increasing the cache from 100MB to 1000MB, because 100MB is too low to meet today's browsing needs.
cache_dir ufs /var/spool/squid 100 16 256
In the same file, after the default configuration information, add the following directives:
icap_enable onicap_send_client_ip onicap_send_client_username onicap_client_username_encode officap_client_username_header X-Authenticated-Usericap_preview_enable onicap_preview_size 2048icap_service service_req reqmod_precache bypass=1 icap://127.0.0.1:1344/squidclamavadaptation_access service_req allow allicap_service service_resp respmod_precache bypass=1 icap://127.0.0.1:1344/squidclamavadaptation_access service_resp allow all
This basic configuration instructs Squid to use the SquidClamav ICAP service running on localhost on TCP port 1344. This use is required for non-cached content. You can find more information about all the configuration directives from the official Squid documentation.
ClamAV is not available in the default CentOS 6 repositories, so you have to choose between installing from source or using a third-party repository. I suggest using the EPEL repository, because it allows easy installation and maintenance.
To install the EPEL repository on CentOS 6, run the command rpm -ivh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-5.noarch.rpm. After that, to install ClamAV, execute yum install clamav clamav-db clamd. Since this is the first installation from the EPEL repo, you are warned about its key, and you have to confirm that it's OK to continue.
rpm -ivh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-5.noarch.rpm
yum install clamav clamav-db clamd
Ensure that the ClamAV daemon, clamd, is started and stopped automatically by executing chkconfig clamd on.
chkconfig clamd on
You can configure a bare minimum ClamAV configuration by editing the file /etc/clamd.conf. You have to remove at least the line that says Example so that the service can start. You might also consider changing some directives from their default values. For example, you can define which file extensions are to be scanned with ScanPE, ScanELF, ScanPDF. For performance reasons you might change the default maximum size of the files to be scanned (MaxFileSize) from 25MB, or how much data of every file is to be scanned (MaxScanSize) – 100MB is the default. The bigger the values, the more resources are required and the slower the proxy will be.
ScanPE, ScanELF, ScanPDF
The ClamAV virus signatures datatabase is updated by a separate program called freshclam. Its configuration file is /etc/freshclam.conf. Again, in order to use it, you have to remove at least the line that says Example in the beginning of the file. Most settings can be left to their default values.
If you execute freshclam without arguments, the signatures are updated once and the program exits. You can configure freshclam as a cron job to check periodically for ClamAV updates, or you can start it in daemon mode by running freshclam -d -c 2, where -d specifies daemon mode and -c 2 specifies how often to update daily – twice in our case. Add that command to your /etc/rc.local file to ensure that it is started next time the server reboots.
freshclam -d -c 2
One interesting setting that you may consider changing in /etc/freshclam.conf is SafeBrowsing, which by default is set to off. This setting specifies whether you want to use the Google Safe Browsing database, which contains an updated list of known malicious sites. You should enable it, taking a small performance hit, unless your organization's end users are using browsers that already have it implemented, such as Mozilla Firefox and Google Chrome. You can turn it on by specifying SafeBrowsing yes.
C-icap is not available in the default repositories nor in EPEL, so you have to install it from source from its site, extract it, and go through the standard ./configure && make && make install routine.
./configure && make && make install
Because C-icap is a custom installation from source, it is not supported by chkconfig. Thus, to have the C-icap server started automatically at boot time, add its binary executable /usr/local/bin/c-icap to /etc/rc.local at the bottom on a new line.
You can find the configuration file for C-icap by default at /usr/local/etc/c-icap.conf. You can leave most of the default options as they are. Specify ServerLog /var/log/icapserver.log to log server activity in the file /var/log/icapserver.log; we'll use the server's log later to ensure that everything is working properly.
While you're examining the configuration, note the directives ModulesDir and ServicesDir. By default both point to /usr/local/lib/c_icap. This directory is where you must install your ICAP services and modules, such as SquidClamav.
You have to install SquidClamav from source for the same reasons as for C-icap. Once you download it from its SourceForge page, extract it and go through the standard ./configure && make && make install procedure.
To ensure SquidClamav is installed properly, check the directory /usr/local/lib/c_icap. You should see two files: squidclamav.la, the libtool library file, and squidclamav.so, the module itself.
SquidClamav does not run as a separate service, so you don't have to add it to the default runlevel for automatic startup. Instead, it will be accessed through the C-icap server.
SquidClamav's configuration file is located at /etc/squidclamav.conf. Here too you can rely on the default configuration for the most part. One of the options you should change is redirect. When end users attempt to download viruses, they can be redirected to a URL you specify here. Create a page with a good explanation, or you as an admin may be deluged with complaints that downloads are mysteriously non-functional.
To create the redirect page, you can use the script cgi-bin/clwarn.cgi, which you can find in SqidClamav's source code archive. Simply upload it to a site and specify redirect example.org/cgi-bin/clwarn.cgi.
At this point your proxy should be fully installed and properly configured. To ensure all services start automatically, reboot your server, then start testing.
When you start to test, make sure that you can connect to the server's IP address at TCP port 3128, the default proxy port. You must allow connections to this port in the default CentOS 6 firewall, unless you have disabled the firewall as advised in the base CentOS 6 installation.
Once you ensure you can connect to this port, configure a browser with the same details – for HTTP proxy address, use the server's IP address, and for port, use 3128. Then begin browsing the web and see how the proxy performs in comparison to non-proxied browsing. Try simulating the work of as many users as would normally be browsing. You may find that your server's resources have to be increased as more users begin using the proxy.
On the server side, monitor the following logs:
The most important test for your proxy is to try downloading a virus and seeing the result. You can find various resources online on how to create a test file with a known virus signature. Once you create such a file, upload it somewhere and try to download it with a browser using your new proxy. If everything is working properly, you should see in C-icap server's log entries like:
Wed Feb 22 01:03:57 2012, general, DEBUG squidclamav_end_of_data_handler: received from Clamd: stream: Eicar-Test-Signature FOUNDWed Feb 22 01:03:57 2012, general, DEBUG squidclamav_end_of_data_handler: Virus redirection: http://example.org/cgi-bin/clwarn.cgi?url=http://the_url_of_your_test_virus_file: Eicar-Test-Signature FOUND.
If you've implemented everything we've talked about so far, you should have a basic proxy with virus protection. On this base you can continue to make improvements and add more features. Here are a couple of ideas for additional components you can add to improve your users' security:
If for any reason this open source proxy solution doesn't quite do what you want, you can investigate what leading commercial products such as SmoothWall offer in order to best address your organization's needs.
Allowed tags: <a> link, <b> bold, <i> italics