Your first defense against viruses, trojans, and email worms is the software that you run on your mail servers. Your users and file servers should all have their own antivirus filtration systems, but you can eliminate over 99% of incoming malicious code by a well implemented antivirus system on your mail servers.
Note that this guide is outdated, and VAMS is no longer available. I’m leaving it up as a reference!
Vexira AntiVirus for Mail Servers Amavisd-new Licence fees ranging from $299 to $3900
(as of May 2005)
Free software + costs for antivirus licenses
(ranging from free to $500 per license)
Single daemon handles all functions. Single daemon calls other daemons and programs for analysis. One company’s antivirus definitions. Include as many definitions as you want. Note that Vexira also has a standalone product for servers that can be used by Amavisd. Very fast. Speed dependent on the number and type of external programs called for filtration. Integrated antispam using custom and bayesian filtration. Advanced ruleset management is being developed and will be released in a later version. Antispam provided by a number of mechanisms including SpamAssassin, dspam, dcc, razor2, and others. Cconfigurations per user, per group, or per domain can be held in an SQL database. Commercial support – we had a few questions while testing the software and updating this guide, and found their support personnel to be very knowlegable. Support provided by mailing lists. Summary: A great antivirus solution, not too expensive, good support. Antispam technology is average, with additional features coming in the future. For standalone antivirus in a mail environment, this is the best solution we’ve seen to date, and it can be combined with an Amavis implementation to take advantage of even more features. Summary: The most comprehensive overall mail security solution available, but does require a lot of skill on the part of the person installing and maintaining. The capabliity to use any other software (even VAMS) as part of the solution makes it the choice for experienced system administrators. The decision regarding whether to use a free (open source) solution or a commercially supported solution will be for each individual or organization to decide.
Installing VAMS is not difficult. Download the tarball and extract it to /usr/local/src. In the vams-install directory, run the vams-install.pl installer file. You will be asked for installation locations, and it is safe to leave them at their defaults.
You will be asked for the list of domain names that you server handles. Enter however many are appropriate for your license and server separated by spaces. You will then be asked for the IP and port number of the SMTP server that will be used to forward scanned mail. This is a reinjection listener as per the Master.cf Guide. For the moment, set this to 127.0.0.1:10025, and we can change it later if need be. You will also need to enter your registration information here. You can get a trial license to see how well the software works for you before you buy.
The VAMS update system has a dependency on the which command. If you do not have it available, the update system will fail – as it uses which to confirm that the software is present. This will be addressed in a later version, but for now, if you are running a Fedora or RedHat Linux variant, use up2date which to install, or whatever package management system you use otherwise.
To keep the antivirus definitions up to date, you’ll need to add a cron job to run the update script:
We would recommend that you have the cron job run every 2 to 4 hours as per your organization’s policy.
Now that VAMS is installed, there are a few options that you might want to change in the /etc/vams/vams.conf file.
default-input = 127.0.0.1:10021 This is the IP and port that the software will use to listen for incoming mail. Depending on your implementation, you might want postfix to accept email, proxy it to VAMS and/or Amavis, and then have it forwarded back to postfix for delivery. This is what we will use for our example. [target]
default = 127.0.0.1:10025
This is the IP and port that the software will use to forward clean scanned mail. Cleaned scanned mail will usually be forwarded to a reinjection listener. tempdir = /var/ramdrive VAMS stores emails on the hard disk while it scans them. The speed of ram is much faster than that of a hard disk, so if you have enough ram, then allocating 64MB to a ram disk can speed up your antivirus processing enormously. Add the following to your /etc/rc.local file, replacing antivirususer and antivirusgroup with their appropriate entries. If you are going to use Amavis, then this directory would be /var/amavis/tmp and the user and group will both be amavis.
mount -t tmpfs none /var/ramdrive/ -o size=64M
chown antivirususer:antivirusgroup /var/ramdrive
helo-name = av.domain.com You will usually want your mail headers to include all processes that handled email, so defining the helo-name will make sure that you get more detailed information in your mail headers. statistic-mail = firstname.lastname@example.org By default, this is set to email@example.com so that the people working on making the software better can learn from your implementation if you enable statistics to be sent. Your policies on releasing information out might not permit you to do this, so please make sure of what you are allowed to do before enabling this. max-smtp-size = 16M The maximum size of emails to permit through your server needs to be set as per your organization’s policy. 8 or 16M is a good number. quarantine-copy = no You can keep a copy of all emails that contained viruses. Most organizations get so many of these, that it’s not worth filling up disk space. You should set this as per your organization’s policies. block-encrypted-archive = yes By default, encrypted archives (password protected zip and rar files) will be passed through the system. Many viruses have come out recently that include an encrypted payload with the password to the file in the email text. This depends on users who blindly follow instructions, but there are a lot of them. Set this as per your organization’s policies. archive-max-decomp-depth = 5
block-archive-decomp-depth-exceeded = no
Sometimes archives can be archived, and archived, and archived, and so on. The unzip/untar/unrar/etc process can take a lot of CPU power, so a limit is set on how deep you want your mail server to decompress and unarchive files. You can also block any archive that contains too many levels of additional archives. [template default] spamfilter
enable = no
To dissable the integrated spam filtration system in VAMS, you need to change the enable= entry to no. The antispam capabilities of VAMS are beyond the scope of this guide, although we do plan on adding more information later this summer once it has been running in our lab and we’ve been able to test it in more detail. One interesting feature is the ability of the software to enable spam filtration on a per user capacity based on LDAP settings.
You now have to make a decision on how you want your email to be filtered. Following are two options:
Postfix -> VAMS – > Postfix
This example would have Postfix accept email, perform some checking such as ensuring that the email is not malformed and comes from a valid address (such as reject_unverified_sender), pass the message to VAMS for antivirus filtration, and then back to Postfix for delivery. In the case where you’ve enabled spam filtration in VAMS, you would also have that capability.
In main.cf, you will need to specify how email will be forwarded to VAMS. This will be done with:
You will also need to set up a reinjection listener on 127.0.0.1:10025 as per the Master.cf Guide.
Postfix -> Amavis -> VAMS -> Postfix
This example would have Postfix accept email, perform some checking such as ensuring that the email is not malformed and comes from a valid address (such as reject_unverified_sender), proxy the message to Amavis where it would be analyzed for spam content by SpamAssassin, have executable attachments removed, and be scanned for viruses by the clamd daemon. The email would then be passed to VAMS to be scanned for viruses, and then back to Postfix for delivery.
You would first configure Postfix and Amavis as per the Amavis Guide.
Then, set up VAMS as described above in this guide.
You will also need to set up a reinjection listener on 127.0.0.1:10025 as per the Master.cf Guide.
Finally, in /etc/amavisd.conf, you will need to specify how email wil be forwarded to VAMS. This will be done with:
$forward_method = ‘smtp:[127.0.0.1]:10021’;
Clam AntiVirus is a free (GPL license) anti-virus toolkit for UNIX. The main purpose of this software is the integration with mail servers (attachment scanning). The package provides a flexible and scalable multi-threaded daemon, a command line scanner, and a tool for automatic updating. The programs are based on a shared library distributed with the Clam AntiVirus package, which you can use with your own software. Please see the ClamAV Web Site for installation instructions.
Once you have downloaded the software, untar it into /usr/local/src. Running ./configure –help will give you the list of options for configuring. Note the –with-user= and –with-group= options that you should use to specify a user to be used for this process (never run anything as root if you can help it). If you are using amavisd as per ourAmavis Guide, then you will probably want to specify the amavis user and group that you created for amavisd.
Follow the normal ./configure; make; make install procedure that you would for any software. The next thing you’ll need to do is comment out the Example line in the freshclam.conf and clamav.conf files. These will be located in either /etc or /usr/local/etc depending on how you configured your software. In the clamav.conf file, you will also need to note the following:
LocalSocket /var/run/clamd/clamd.sock – this is the location of the socket file for the clamav daemon. You will need to know this location if you will be using it with amavisd.
User amavis – this is the user under which the clamav daemon will run. This should be the same as what you used on the –with-user= option when you ./configure.
Now that your configuration files are set up, you will need to run freshclam in order to update the virus definitions. Running freshclam -d will lauch the freshclam process as a daemon, that you can leave to automatically update the virus definitions regularly. Alternatively, you can run freshclam in a cron job to update as often as you want. Last, run clamd, confirm the presence of the socket file, and you’re ready start filtering for viruses.
On a desktop computer, multiple antivirus programs can cause problems. On a mail server, multiple antivirus programs / definitions can save you a lot of potential trouble. No product is perfect, and when a new virus makes its way into the wild, being as the different antivirus vendors are located in different time zones, have different people working for them, and have different quality assurance and change control procedures, one vendor could have new definitions available minutes or hours ahead of another. Historically, there has been up to a 48 hour delay for some vendors to release definitions! More controls and protections in your solution can only make it more difficult for a virus to get in.
If you are an antivirus vendor and would like to include a product in this list, or are an administrator with experience in another product that you think would be beneficial to other people, we would be happy to list any product that will work either with Postfix or Amavis.