Introduction
In the first part of this article series, we looked a common set of Unix tools to act as an effective spam and virus front-end for Microsoft groupware products, such as Exchange, Notes and Groupwise. The concept of layered security was discussed, and in the case of filtering for spam emails, various alternatives such as deleting the message, forwarding the message with a modified subject line (which facilitates additional post-processing by the Exchange server or Outlook client), and setting thresholds for acceptable types of email.
The second and final article in this series will take a similar approach to the above, using a different set of tools to accomplish essentially the same thing. In particular, we'll look at the use of Qmail, Qmail-Scanner, Clam Anti-Virus, and once again, SpamAssassin as alternate tools in the war against viruses and spam. Once again, all these tools are open-source, free alternatives that provide an effective additional layer of security to a Microsoft-centric email and groupware system.
An alternate strategy
Sendmail is only one possible MTA to use when defending the inbox. Another popular choice is qmail [ref 13] as it is considered by some to be faster and easier to configure than sendmail. A good set of tools to have when using qmail would be:
ref 14
Qmail-scanner enhances the capabilities of qmail by providing an extensible means of scanning, filtering and reacting to e-mail coming into or through (if you're an valid relay) your gateway. It works with virtually any virus scanner, so you are not limited to the suggestions in this article.
Clam AntiVirus [ref 15] ClamAV is a powerful anti-virus toolkit that integrates well with qmail. It provides for automatic virus signature database updates over the Internet and even works on compressed attachments.
SpamAssassin is still the tool of choice for filtering out the rest of the unwanted mail.
If you're not already running qmail, you should first read Life with qmail [ref 16]. It is the de-facto setup guide for qmail and will have you up and running with a functional MTA in very short order. Also note that there is a patch [ref 17] required to enable use of different scanners.
As with sendmail, there are a few basic housekeeping steps to take to run a well-behaved MTA. Relaying by default is disabled, but it can be enabled if you require this functionality. You need to edit the /etc/tcp.smtp file and add entries for client relay access in the form of:
ip.address.of.client:allow,RELAYCLIENT=""
This sets the RELAYCLIENT environment variable on an IP-by-IP basis. Once you've finished editing the file, you need to rebuild the database:
At a minimum, you'll need to include the address of your Exchange server to enable it to send mail via the gateway. Also, you'll need to edit the /var/qmail/control/smtproutes file and add an entry to enable forwarding of incoming mail to your Exchange server:
You'll need to rebuild the database again.
The SpamAssassin configuration is slightly different for this setup. You still need to do the same prep work for installing and configuring SpamAssassin, but this time it will be running as its own daemon - spamd. This will require the creation of an init script to ensure it works at reboot.
ClamAV generally installs out-of-the-box (again, even easier when using BSD or Linux distributions with good centralized package management) and binary packages are available [ref 18] if you are the trusting type and pressed for time. The full instructions are available at the ClamAV [ref 19] site, however there are some fundamental configuration steps and qmail integration pieces you will need to consider.
First, create a clamav user and group, setting the shell to something like /bin/false (or nologin since it doesn't need an interactive login. Next, if you want to enable auto-updating of the virus signature definitions, you'll need to setup the necessary file/permissions:
# touch /var/log/clam-update.log
# chmod 600 /var/log/clam-update.log
# chown clamav:clamav /var/log/clam-update.log
and ensure freshclam has a way to update the definitions, either by running it as a daemon with the appropriate parameters (the following has freshclam update once-per-day):
/usr/local/bin/freshclam -d -c 1 -l /var/log/clam-udpate.log
or via a cron job (change the download time to your liking, this executes at 0313 daily):
13 3 * * * /usr/local/bin/freshclam -quiet
If your server is behind an http proxy, you'll need to edit the configuration file and make the appropriate changes to enable freshclam access to download site.
Making Qmail battle ready
With the fundamental components installed, you now need to focus on the glue that makes all the pieces work together: qmail-scanner. The qmail-scanner site lists everything you'll need for a successful install, but you'll need to make sure the components in the Requirements section are installed for a successful build, especially the Perl modules.
Unless you've already gone through a qmail-scanner customization, you will also need to do some manual configuration of the options to get exactly what you need and it may even be necessary to run the configure script by hand to get things just right. With that in mind, the following table provides values for the most common options to the qmail-scanner configure script:
| Configure option |
Value |
Explanation |
--spooldir |
/var/spool/qmailscan |
Mail spool directory |
--qmaildir |
/var/qmail |
Top level of qmail directory |
--bindir |
/var/qmail/bin |
Where to install the scanner |
--qmail-queue-binary |
/var/qmail/bin/qmail-queue |
Full path of the qmail qmail-queue binary |
--admin |
maildude |
User to e-mail alerts to |
--domain |
example.org |
Domain of --admin |
--local-domains |
example.org |
Defaults to --domain value, but can be a comma-separated list of all domains that are considered to be local |
--silent-viruses |
klez, bugbear, nimda, swen |
Any virus found in this list will be quarantined and the user will not be notified |
--unzip |
1 |
Unzip all compressed files |
--log-details |
yes |
Keeps a log of activity in mailstats.csv |
--fix-mime |
1 |
Fixes broken MIME messages |
--scanners |
"fast_spamassassin clamscan" |
If specified, this lists the scanners active with this configuration |
--install |
1 |
Create install dirs and install the program |
A list of all options can be found at the qmail-scanner site [ref 20]. Once installed, create a qscand user and group as you did for the ClamAV install.
You will need to install qmail-scanner-queue for things to work properly. It can be found in the qmail-scanner source contrib. directory. Do a simple make and then copy the qmail-scanner-queue file to the qmail executable directory. Make sure the permissions are correct by running:
# chmod 6755 qmail-scanner-queue
# chmod 0755 qmail-scanner-queue.pl
# chown qscand:qscand qmail-scanner-queue*
The last qmail-scanner action is to copy the quarantine-attachments.txt file from the source distribution to the qmailscan directory and ensure all files are owned by qscand. Note that will all the additional processing, you will need to modify the softlimit parameter for qmail in order for it to process mail.
The only step left is to tell qmail to use qmail-scanner. One of the most common ways to doing this is to add parameters to the lines in the tcp.smtp file:
QS_SPAMASSASSIN="yes",QMAILQUEUE="/var/qmail/bin/qmail-scanner-queue"
Once you have made the modification, rebuild the database.
Make sure you try this on a test environment first since there will no doubt be differences in your environment that will require modifications to the above steps. You may find the setup quides -- covering installation on FreeBSD, RedHat, Fedora and Debian -- at qmailrocks.org [ref 21] to be helpful as a reference or as an alternate way of installing all of the pieces (they take a different approach at the integration of all the components).
The never-ending battle
As your inbox no doubt proves, spammers get smarter every day, virus writers get more clever by the second and users never stop complaining about spam. As a result, you'll need to do regular checks for software updates to MIMEDefang, qmail-scanner, ClamAV and (especially) SpamAssassin. You may also want to provide a way for users to forward mail to a central spam account which will have its contents added to the site-wide database.
Another point to consider is do you deliver or delete. If you go the route of deleting all suspected virus/malware/spam messages there is a chance (albeit a small one, once you've tuned the system) that you'll classify good mail as bad. Because of this, many sites choose to clean, tag and deliver. They remove viruses and virus-ridden attachments, tag bad mail as virus, malware, policy-rejected or spam and then deliver at least some message to the user. Users can be instructed how to setup client filters (Outlook can even define filters that get processed on the Exchange server, removing some burden from the user's PC) and the mail servers can be instructed to wipe the spam folders clean at regular intervals. However, this takes additional time and computing resources (storage and processor), so you will need to find the best balance for your organization.
You may also need to look at process optimization. The MIMEDefang/SpamAssassin filtering process consumes memory, CPU and disk space for each message processed. If you discover that mail processing is slowing to a crawl you don't have to necessarily run out and buy a bigger box. MIMEDefang can be optimized by running it as a server pool, thus eliminating the need to start a Perl process for each message. SpamAssassin checks can be very time consuming on large messages. You can modify the rules to not check large (100KB+) messages since they are generally not spam (yet) and have all other MIMEDefang filter checks performed before the SpamAssassin test runs (since you don't need SpamAssassin to process already rejected or tagged messages). In the qmail setup, the individual components work well together, but are even more efficient apart - i.e. have one server do virus scanning and another do spam detection.
Privacy is one more area where you will need to devote some research time to, especially if you want to run a centralized spam/malware gateway in some European countries. Different laws exist which dictate when/where/how/why and what you can do with e-mail directed to your users. In some places you may be able to redirect/quarantine mail and save it for an extended period of time. In others, you may only be allowed to collect a small bit of data for reporting purposes and then immediately either have to remove or forward the messages to their destinations.
The allied alliance
Even if you've had a successful deployment of MIMEDefrag/SpamAssassin or qmail-scanner/ClamAV/SpamAssassin, you may find that keeping up the fight is more than you can handle. That doesn't mean giving into spam/malware, but it may mean bringing in the Allies to shore up your defenses. A virtually painless (except for the pocketbook) alternative is to partner with companies such as Sprint or Postini . For a fee (usually per-mailbox) and a simple DNS record change, these services will do all of the filtering, tuning and reporting for you. You can even work with them to allow your users the ability to review the spam via a web site and tag messages they wish to keep (either once or on a continuing basis). Using these services can free up time and resources that your company can put to other use, which may wind up paying for the costs of the service in the long run.
Either in-house or via a partner service, the tools are there to help you fight the good fight against spam/malware.
|