Sun Jan 23 00:00:00 PST 2005
Installing Clam Anti-Virus
Okay, so we still live in a Windows
world. More accurately, we live in a Microsoft Office world. I try
hard to educate people about the evils of software lock-in, as well
as the perils of non-portable file formats, but the Luddites of the
world still insist on a Redmond monoculture.
So, even though I refuse to expose my systems to a certain eponymous windowing OS, I am occasionally forced to fire up Word or Excel to handle a document which makes heavy use of proprietary extensions. While most documents open fine in OpenOffice.org, occasionally there's just no substitute for editing a data file with its native application.
I've had excellent success with MS Office 2000 running under CrossOver Office, but am worried about exposing my Linux box to the onslaught of virii which the office suite brings with it. While it is unlikely that a MS Windows or MS Office virus could damage my Linux system as a whole, it could potentially wreak havoc with my home directory or the CrossOver-supported Windows binaries. Obviously, this is not acceptable.
My solution was to implement ClamAV, an open-source anti-virus scanner. While it doesn't support on-access scans when a file is opened, it is more than capable of handling on-demand scans of email attachments and stored files.
Scanning a file manually (using clamscan) before opening it with MS Office is a pretty trivial process, and doesn't really bear mentioning. However, since most of my suspect files come in via email, I wanted to automate the process of scanning attachments.
There are many ways to implement ClamAV. For efficiency reasons, I decided to install ClamAV system-wide, but handle attachment scanning on a per-user basis through procmail to maximize flexibility and reduce the overhead of scanning every email that comes into the system.
As a side note, installation on Debian is very straightforward, but installing the clamav package doesn't install the clamdscan binary by default. For that, you'll also need the clamav-daemon package if you want to daemonize ClamAV and avoid some of the overhead of repeatedly spawning clamscan from multiple procmail instances. If you opt not to install the daemon, just substitute "clamscan" for "clamdscan" wherever appropriate.
If you search the ClamAV web site, you can find plugins and wrappers for using ClamAV from a procmail recipe. The problem is that most of them, for one reason or another, insist on writing each email out to disk before processing. Now, while ClamAV may need to use temporary files when scanning inside compressed archives, writing all messages to disk is both unnecessary and slow. In fact, using the plugins, each email will get written to disk at least twice, whether or not it contains a file attachment.
So, I wanted a solution that didn't have any external dependencies (e.g. some third-party plugin), and which could take emails from standard input so that emails were only written to disk once. I couldn't find a simple procmail recipe to do this on the ClamAV site, so I rolled my own.
While purists may note that this recipe doesn't handle any exotic error conditions, it's fairly straightforward and will handle the majority of cases smoothly. I may try to bullet-proof it at some later point in time, but at the moment it works well enough for me.
So, even though I refuse to expose my systems to a certain eponymous windowing OS, I am occasionally forced to fire up Word or Excel to handle a document which makes heavy use of proprietary extensions. While most documents open fine in OpenOffice.org, occasionally there's just no substitute for editing a data file with its native application.
I've had excellent success with MS Office 2000 running under CrossOver Office, but am worried about exposing my Linux box to the onslaught of virii which the office suite brings with it. While it is unlikely that a MS Windows or MS Office virus could damage my Linux system as a whole, it could potentially wreak havoc with my home directory or the CrossOver-supported Windows binaries. Obviously, this is not acceptable.
My solution was to implement ClamAV, an open-source anti-virus scanner. While it doesn't support on-access scans when a file is opened, it is more than capable of handling on-demand scans of email attachments and stored files.
Scanning a file manually (using clamscan) before opening it with MS Office is a pretty trivial process, and doesn't really bear mentioning. However, since most of my suspect files come in via email, I wanted to automate the process of scanning attachments.
There are many ways to implement ClamAV. For efficiency reasons, I decided to install ClamAV system-wide, but handle attachment scanning on a per-user basis through procmail to maximize flexibility and reduce the overhead of scanning every email that comes into the system.
As a side note, installation on Debian is very straightforward, but installing the clamav package doesn't install the clamdscan binary by default. For that, you'll also need the clamav-daemon package if you want to daemonize ClamAV and avoid some of the overhead of repeatedly spawning clamscan from multiple procmail instances. If you opt not to install the daemon, just substitute "clamscan" for "clamdscan" wherever appropriate.
If you search the ClamAV web site, you can find plugins and wrappers for using ClamAV from a procmail recipe. The problem is that most of them, for one reason or another, insist on writing each email out to disk before processing. Now, while ClamAV may need to use temporary files when scanning inside compressed archives, writing all messages to disk is both unnecessary and slow. In fact, using the plugins, each email will get written to disk at least twice, whether or not it contains a file attachment.
So, I wanted a solution that didn't have any external dependencies (e.g. some third-party plugin), and which could take emails from standard input so that emails were only written to disk once. I couldn't find a simple procmail recipe to do this on the ClamAV site, so I rolled my own.
# Scan only messages with application or multi-part MIME attachments.
:0
* ^Content-Type:.*(application|multipart)
{
# Feed the email to ClamAV, and store the output into a variable.
:0w
CLAMSCAN=|clamdscan --mbox --disable-summary --stdout -
# Place the name of any suspected virus into a custom email header.
:0fhw
* CLAMSCAN ?? : \/.*FOUND
| formail -A "X-Local-Clamscan: ${MATCH}"
# Otherwise, if no virus was detected, mark the email as clean.
:0Efhw
| formail -A 'X-Local-Clamscan: clean'
}
While purists may note that this recipe doesn't handle any exotic error conditions, it's fairly straightforward and will handle the majority of cases smoothly. I may try to bullet-proof it at some later point in time, but at the moment it works well enough for me.