Open Source Anti-Virus for the Whole Network: ClamAV

James Mikusi

Until recently, there was not a strong open source presence in the anti-virus realm. Now, however, there is more than one project in this arena, and the ClamAV project in particular is proving its ability to provide software scanning in a way that's adaptable and effective.

In the spirit of the Unix philosophy, Doug McIlroy said, "Write programs that do one thing and do it well. Write programs to work together." ClamAV demonstrates just how effective this model continues to be. The ClamAV engine simply filters any input given and outputs a basic summary stating whether a virus was detected. This simplicity makes it appropriate for scanning content on a local file system, network file system, Web proxy, mail gateway, or whatever. Simply send it input and get a yes/no result.

ClamAV Features

When weighing the effectiveness of anti-virus software, two features must be considered. The first aspect is the frequency and timeliness of virus database updates. This is an area of strength for open source collaboration because virus database updates are made continuously by the project's maintainers with help from the Internet community in general. The ClamAV project hosts a Web form where new virus discoveries can be posted and inspected by the virus database maintainers and added to daily.cvd publications if appropriate. On occasion, the ClamAV project has even been the first to identify new viruses and thus bestowed the right to name the virus. In my opinion, this global contribution to the virus database makes ClamAV a force to be reckoned with.

The second consideration is the performance of the scanning engine. How long do scans take? Are viruses detected pre-infection? Are suspicious files with virus-like actions, but not in the definition database, treated like viruses for protection? In this aspect, the ClamAV "suite" performs excellently, too. It's a simple, straightforward scanning engine.

When setting up ClamAV, be sure you use the most recent code (1). As the project has advanced, there have been changes to the virus database definition formats that require using the most up-to-date software distributions to make sure the most recent virus definitions are effective. The ClamAV FAQ says:

You'll get [a ClamAV installation is OUTDATED] message whenever a new version of ClamAV is released. To detect all the latest viruses, it's not enough to keep your database up to date. You also need to run the latest version of the scanner. You can find the latest release at http://www.clamav.net under the stable link. Running the latest stable release also improves stability.

The Dissection

The ClamAV home page is http://www.clamav.net. The project is hosted on SourceForge where official releases or snapshots may be obtained. Check the "3rd Party Software" link on the home page to find an RPM binary that can even be obtained via yum install clamav with the appropriate entries in /etc/yum.conf (2).

As of this writing, the current version of ClamAV is 0.80-1. This article will concentrate on RPM distributions where available for their ease of installation and updates. If not using yum (or similar), obtain both clamav-0.80-1.i386.rpm and clamav-devel-0.80-1.i386.rpm -- the latter being necessary only for compilation of mod_clamav.so and vscan-clamav.so (discussed later). Install both RPMs with rpm -ivh.

Two parts make up the engine of ClamAV: clamd, the scanning daemon, and freshclam, the virus database update retrieval tool. By default, ClamAV keeps its virus definitions in /var/lib/clamav with two definition files: main.cvd and daily.cvd. The file /etc/freshclam.conf controls the basics of the freshclam process, which downloads the two abovementioned definition files and alerts the clamd engine to reload the virus definitions. Later in this article, I will describe how to create a local virus definition server.

The frequency of the freshclam daemon should be directly related to how much traffic flows in and out of any given network. In small office environments, I find two updates during the workday ease my mind. High-traffic sites or paranoid admins may want to consider hourly updates. The only other out-of-the-box edit to make for virus database updates is to point a regionally local update server:

DatabaseMirror db.XY.clamav.net    # XY = country code. ie: US for us.

The second part of the work is done by the clamd daemon. It can operate in either of two modes: unix socket or tcp socket. Either of the following configuration directives from /etc/clamd.conf controls this behavior. Choose one! ClamAV can't listen to both Unix and network sockets concurrently. Unless using a central virus scanner server, the first option is preferred:

LocalSocket /var/run/clamav/clamd.sock  # UNIX socket owned by clamav

TCPAddr 127.0.0.1
TCPSocket 3310                        # default port

The default working directory is /tmp, but it can be changed with the following directive:

TemporaryDirectory /tmp/clamav   # setting used for this article

VirusEvent sendemail pip@foo.bar "Found %v."
# my custom script "sendemail"

In Action

The most basic virus scan can be made with the clamscan executable included in the distribution. When run on a Unix client where the clamd daemon is running (in either Unix socket or network mode), it takes filenames, directories, or standard input as arguments and scans them for viruses. While a simple summary with findings is dumped to standard output, the clamscan process simply returns 0 for no detection, 1 for a detected virus, and any other positive number identifying an error in processing.

One thing to keep in mind while working with ClamAV is permissions. The ClamAV installation defaults to creating the user clamav. This is the user name assumed by clamd and freshclam, the owner of virus database files, and quarantine directories. Not getting scan results? Make sure the requesting process can read/write the domain socket. Verify /var/run/clamav/clamd.sock has permissions 777 and /tmp/clamav permissions of at least 770 and that both files are owned by uid clamav, gid clamav.

Perimeter Scanning

If using a Samba file server, then ClamAV can use vscan-clamav (from the samba-vscan project) via the VFS interface of Samba. Although this is said to work with Samba v2.2, the procedures here were achieved with Samba v3. This utility is not yet available as an RPM, so the source code needs to be downloaded. The first thing necessary to compile the vscan-clamav module is the Samba source code. We'll get everything we need here from samba-3.0.7-1.src.rpm (3). Run the following to make the RPMs and extract the source (this step is necessary even if you already have a Samba binary installed since compilation of samba-vscan requires the Samba source and make proto run within):

rpmbuild --rebuild samba-3.0.7-1.src.rpm

rpm -Uvh /usr/src/redhat/RPMS/i386/samba-3.0.7-1.i386.rpm

rpm2cpio samba-3.0.7-1.src.rpm | cpio -i samba-3.0.7.tar.bz2
tar xjf samba-3.0.7.tar.bz2
cd <samba-source-root>/source
 ./configure; make proto

tar xjf samba-vscan.0.3.5.tar.bz2; cd samba-vscan-0.3.5
<editor-of-choice> clamav/vscan-clamav.h  # if customizations are desired
./configure --with-samba-source=<samba-source-root>/source
make clamav
cp vscan-clamav.so /usr/lib/samba/vfs/ # or the lib/samba/vfs \
  location for your installation

cp clamav/vscan-clamav.conf /etc/samba/

vscan-clamav: config-file = /etc/samba/vscan-clamav.conf
vfs object = vscan-clamav

clamd socket name = /var/run/clamav/clamd.sock  # tell it where clamd listens.
scan on open= yes
scan on close = yes
deny access on error = yes
deny access on minor error = yes # iron fist.
send warning message = yes # use windows messaging to notify the 
                           # user when viruses are found.

# only necessary if keeping viruses for later inspection.
#make sure this directory is NOT public or shared via samba!
quarantine directory = /tmp/clamav
quarantine prefix = VIRUS_INFECTED-

The beauty of the samba-vscan implementation is that files are scanned and detected even before users can open them. Using ClamAV as part of a full anti-virus network solution helps prevent viruses from ever reaching the desktop -- ignoring removable media. With proper IT policy, it would be very difficult for infections to spread in your network.

mod_clamav Apache Module

I covered protecting file servers, but now I'll concentrate on scanning in-bound and out-bound data -- the first being Web content. The first thing needed is the ever popular Apache Web server with module support (DSO, mod_proxy, and the source distribution file mod_clamav-0.21.tar.gz (4). The creation of the module mod_clamav is a simple matter of ./configure; make; make install; this will require the availability of the Apache apxs utility. If it's not auto-detected, then its location can be specified with the -with-apxs command-line option when running ./configure:

tar xzf mod_clamav-0.21.tar.gz
cd mod_clamav-0.21
./configure [--with-axps=/usr/sbin/apxs]
make

Now it's time to modify httpd.conf. mod_clamav will chain its actions onto mod_proxy in the <Proxy> specification. While proxy support can be added to a content serving server, the following configuration file is intended to be used as a minimal standalone proxy/virus-scanning server. I prefer this method because it conforms to Unix philosophy referenced at the beginning of this article. Copy it and run it via /usr/sbin/httpd -f /etc/httpd/conf/httpd-clamav-proxy.conf (Listing 1).

Note also the sethandler clamav mapped to the virtual directory /clamav, which permits retrieving a status page from mod_clamav and is useful for finding out whether it's up and running.

Local Virus Database Server

If you read the Apache config file closely, you'll have noticed a VirtualHost section. This simply adds the ability to serve the content in /var/lib/clamav where the virus database definition files live. Via this method, and by adding "virusdb" to point to this host in your DNS configuration, it can serve the files main.cvd and daily.cvd to other internal clients. Just point client installs of ClamAV to "your-virtualhost.yourdomain.com" as well as coordinate this with your DNS zone. I liked setting up a DNS record for "virusdb.mydomain.com".

Mail Filtering

There are a number of SMTP projects using ClamAV, but I chose clamstmp for this article because it's available as an RPM (or just a .spec to build your own RPM) and because its design lends itself for usage in most any mail server software. Essentially, it runs as a standalone (mail) server accepting mails on a listening socket, scans them for viruses via clamd, and then sends them back to the delivering mail server on some other socket. The project's homepage states that it was designed with Postfix in mind, which will be covered here. On the other hand, check the references at the end of the article because there may already be a project to suit your mail server specifics (5). For example, there is a clamav milter project for use with sendmail.

Get the clamsmtp RPM (clamsmtp-1.0-1.src.rpm at the time of writing) and build it with:

rpmbuild -rebuild clamsmtp-1.0.1.src.rpm
rpm -Uvh clamsmtp-1.0-1.i386.rpm

This configuration assumes that Postfix, clamsmtp, and clamd all run on the same server. It uses the loopback address for communication:

OutAddress: 10026     # "ip:port" or just "port"
                      # must coordinate with postfix master.cf
Listen: 0.0.0.0:10025
ClamAddress: /var/run/clamav/clamd.sock # make sure its not just "clamd"
User: clamav
VirusAction command # your heart's desire. Email, page, SMS, fax, ...

Configuring Postfix is a simple matter of some edits to main.cf and master.cf. This is taken directly from the project's Web site. This configuration (Listing 2) can be cut and pasted into a Red Hat 9 default Postfix distribution in about two minutes for a working solution.

Just make sure Postfix listens on the loopback address (main.cf: inet_interfaces = $myhostname, localhost) where clamsmtp defaults to sending its results if based on this configuration. Clamsmtp will receive its requests on 127.0.0.1:10025 from Postfix running on the same machine; ergo, it will send the filtered mail back on 127.0.0.1:10026. This default behavior comes from the OutAddress: 10026 config directive, which says send mail back to the IP address it came from on port 10026. An IP:Port specification can be used here if needed.

Also, clamsmtp defaults to dropping mail with positive virus scans. I find this a little discomforting in that I like the fact that email is reliable and never vanishes into the ether. Even when there are problems, I'm confident it will bounce back. The maintainers have a strong argument in that virus-infected emails usually have false reply-to addresses anyway, so bouncing the mail is wasted effort and bandwidth. You decide. Change the default behavior of dropping virus infected mails by setting Bounce: on in clamsmtp.conf.

It's also possible to add a header to the email after scanning and let local delivery agents, like procmail, do their own thing. This is accomplished with the clamsmtpd.conf directive:

ScanHeader: X-AV-Checked: ClamAV using ClamSMTP.

To make this project complete, there needs to be client-based scanner, which is fulfilled by the ClamWin port. The core ClamAV project does distribute a Windows installer but without any GUI front-end. Maybe this is acceptable in the world of Unix administration, but it's not very friendly for the standard end user. Find the installer on the ClamWin homepage (6).

One drawback of the current ClamWin installation should be noted -- it doesn't support on-access scanning, which might make it better classified as a virus infection notifier rather than "anti"-virus prevention. As far as anti-virus software goes, this is very undesirable but is likely to change in future releases of this project. On a better note, it uses the same virus database files as the previously described projects as well as scheduled scans, email notification, Outlook plug-in, a tray icon, and a Windows explorer plug-in.

The ClamWin project distributes an installer that auto-detects the presence of Outlook and prompts for the option to install the Outlook plug-in during setup. When starting Outlook, there will then be a splash screen showing the ClamAV logo but no other noticeable difference. From installation forward, all Outlook in-bound and out-bound email will be scanned for viruses locally. This might be considered redundant if all the mail is going to a filtered gateway anyway, but it's probably a good idea nonetheless. If you have users that fiddle with POP3/IMAP or SMTP settings to check other accounts, then using the local filter is a good idea. Most desktop stations these days are plenty over-powered for the typical office desktop user, so a few extra cycles spent scanning mail is harmless.

Once installed, there are two noticeable differences. First is an icon in the system tray, which brings up the main configuration interface when double-clicked. There are nine tabs that include configuration of the virus database server (use the local VirtualHost replicator described in the proxy section), email notification, and scheduling of scans. The second change occurs in Explorer, which adds an option to the right-click context menu for scanning a single file or folder. This is great for scanning recent downloads before executing them.

Unfortunately, the installer at current (v0.35-2) doesn't support network deployment or easy replication of settings. The installer asks whether to install for the current user or All Users, but config files are per user in their "HOME\Application Defaults\.clamwin" folder (Win2K/XP) or "C:\Windows\Profiles\username\.clamwin" (Win98).

For small office installations, I've found it easy enough to configure one client, create the desired configuration, then copy the files ClamWin.conf and ScheduledScans from C:\Documents and Settings\username\Application Data\.clamwin to new client installations, but I put them in C:\Program Files\ClamWin\bin (as opposed to a single user's configuration directory) where they will be copied as defaults for new users on first logins. Large installations might want these files maintained via policy files or as read-only files in their home directories. This is a trivial task if you're already using Samba for network logins.

Reference should also be made to the need for the COM_SPEC environment variable in ClamWin. This variable references the command.exe (Win98) or cmd.exe (Win2K, WinXP) command prompt (or DOS shell). This variable is usually set on Win98 and WinXP clients, but I found some Win2000 machines where it was not set. If not, it can easily be added to your system variables. (In WinXP, it's been renamed "ComSpec.")

Testing: Is It Working?

It's installed, but is it doing its job? It's not practical to pass known viruses around the network just to see if tools are doing their jobs, thus the European Institute for Computer Anti-Virus Research (EICAR) provides a good solution. They've come up with the idea of a text file whose signature is generally accepted by most anti-virus packages to trigger a positive virus finding. It's distributed in several forms, including within doubly zipped archives at http://www.eicar.com/anti_virus_test_file.htm. This link itself will trigger mod_clamav/mod_proxy and block the page from loading.

This is not proof of full virus protection but rather a trigger to ClamAV to see whether the software is installed and functioning. Full proof of concept would be provided by "unbiased" third parties such as http://www.virusbulletin.com/ (7). Since having software evaluated by such an institution requires subscription fees, and most open source projects don't have such a budget, it's not likely this will happen for ClamAV in the immediate future. It might happen when ClamAV becomes more widely used and a full test against commercial packages is commissioned. I hope articles such as this one will advance ClamAV down this path. (Check out the "who's using it" link on the homepage for more information.)

What Next?

Open source software has come a long way in the past decade from being a midnight hacker's favorite toy to a financial institution's budget saver and performance enhancer. While Linux, Apache, sendmail, BIND, Perl, and the like have filled the spectrum of open source software benchmarks, there has been a void in virus protection until the emergence of ClamAV and similar projects.

ClamAV's model follows the Unix philosophy -- it scans for viruses, nothing more and nothing less (8). Its sole intent is to do this well and let projects like mod_proxy and clamstmp provide support for connecting to other services. Likewise, I find my favorite software packages to be those with wide support networks, such as Perl-CPAN and Apache-modules. If these are any signs of what gives software longevity, then ClamAV is well on its way to wide acceptance.

The curious might want to look at the sigtool application distributed with ClamAV, which is used to manage the virus database files. It's trivial to open a cvd file and grep the text definition files for a virus name and signature. You might even find occasion to add your own signatures to have certain files treated like viruses. For instance some admins don't want file sharing apps making it to the desktops. Also worth noting is the libclamav library, which provides a completely different option for linking programs with ClamAV (samba-vscan can use this option).

Lastly, you can help out! This project has become so successful because of its large contribution base. Make it even better by adding yourself to that list (9). If you find a new virus, submit it to the database via the link on the home page. This spirit and mentality could potentially halt viruses for good!

Resources

1. ClamAV home page -- http://www.clamav.net/

2. Third-party software information -- http://www.clamav.net/3rdparty.html

3. Samba source -- http://www.openantivirus.org/projects.php#samba-vscan

4. Mod_clamav source -- http://software.othello.ch/mod_clamav/

5. Clamsmtp -- http://memberwebs.com/nielsen/software/clamsmtp/

6. ClamWin -- http://www.clamwin.com/

7. Virus Bulletin -- http://www.virusbulletin.com/

8. Unix Philosophy -- http://www.faqs.org/docs/artu/ch01s06.html

9. ClamAV FAQ and mailing lists -- http://www.clamav.net/faq.html#pagestart

10. Author Notes -- http://www.i-kong.com/clamav

Jimi lives in and runs his consulting business from Jersey City, NJ. He currently spends way too much time trying to turn his PC into the ultimate PVR Multimedia machine, but when he does tear himself away from his computer, he enjoys the dancing nightlife in NYC. He can be reached at: jimbox@i-kong.com.