Paranoid Penguin - Adding Clam Antivirus to Your Postfix Server

Keep vulnerable systems out of trouble with a layer of high-performance protection on your Linux mail server.
Configuring ClamAV

Once you've installed ClamAV and Amavisd-new, you can configure them. We start with ClamAV, the simpler of the two. ClamAV's configuration file is /etc/clamav.conf. To configure ClamAV, open this file with the text editor of your choice. Listing 1 shows the parameters most people need to change from the defaults.

The first line seems innocent enough, but it's important that you comment it out. If it isn't, clamd cannot run.

The two LogFile... settings are commented out by default. Uncomment them to enable logging to the file of your choice and to overwrite the file when it reaches the size specified in LogFileMaxSize.

DatabaseDirectory is crucial. This is where ClamAV keeps its virus-signature databases—its brains, as it were. In the ClamAV RPM I installed, the clamd dæmon was compiled to use /usr/share/clamav for this setting, but the included sample clamav.conf file showed a commented-out value of /var/lib/clamav, so I uncommented this setting and changed it to /usr/share/clamav in order to minimize confusion.

LocalSocket determines which socket file clamd uses to communicate with the outside world, namely, Amavisd-new. If you use this setting, which I recommend, be sure to leave the lines for TCPSocket and TCPAddr commented out. On my Genco package, the default value for this path for LocalSocket is /tmp/clamd, but /tmp is world-readable/writable. I recommend you instead set this path to /usr/share/clamav/clamd.sock and set the permissions on /usr/share/clamav to rwxrwx. In other words, remove the read/write/execute bits for other.

The last setting in Listing 1, User, specifies the name of the non-privileged user account clamd should run as after initialization. clamd must be started as root, but if this parameter is uncommented and set, clamd demotes itself after it's done initializing.

This is all most of us need to set in /etc/clamav.conf. Before you start clamd, however, make sure your system has an account for clamav and the permissions on any path you set in /etc/clamav.conf are set accordingly. It's also a good idea to use a group, clamav, for this account. As we see in the next section, this makes it easier to share certain resources between clamd and amavisd.

The /etc/passwd entry for clamav user account is:

clamav:x:52:52:ClamAV Daemon:/:/bin/false

And, the /etc/group entry for clamav group account is:

clamav:x:52:

Once clamd is configured, you can start it simply by entering the command clamd. If you installed ClamAV from a binary package, your system may have an init script for clamd in /etc/init.d. If so, be sure to enable it so clamd starts at boot time. Otherwise, you need to create and enable your own startup script.

Configuring Amavisd-new

As with clamd, we need to edit only a single file, /etc/amavisd.conf, in order to configure amavisd. However, we've got a little more work to do here. Listing 2 shows the most important settings in my /etc/amavisd.conf file.

The first two settings in Listing 2, $daemon_user and $daemon_group, specify the user and group amavisd should run as, amavis and clamav, respectively. As I mentioned previously, I like to use a common group for all of amavisd's and clamd's files, so it makes sense to have amavisd run as that group too. The /etc/passwd entry for my amavis account looks like this:

amavis:x:53:52:Amavisd-new Daemon:/var/amavis:/bin/false

$mydomain specifies your organization's name domain. $MYHOME, which should be set to the same path as your amavis account's home directory, specifies the root path to Amavisd-new's files, customarily /var/amavis. This directory should be owned and writable only by root. $QUARANTINEDIR is the path to the directory in which you want amavisd to dump quarantined e-mail messages. This directory should be owned by your amavis user account and writable only by it.

$db_home, which you may need to uncomment, specifies where amavisd should keep its databases, such as include cached scan results, among other things. $helpers_home specifies the directory in which you want amavisd to keep its SpamAssassin settings and other miscellaneous things. $helpers_home may be commented out by default. The directories specified by $db_home and $helpers_home should be owned and writeable only by your amavis user account.

$pid_file and $lock_file, also possibly commented out, can be used to specify where amavisd writes its pidfile and lockfile, respectively.

$log_level specifies how verbose amavisd's log messages should be, expressed as a number between 0 and 5, with 5 being the most verbose. The default is 0, but I find 2 to be a much more useful setting that nonetheless doesn't clutter my logfile. By default, amavisd sends its log messages to the local syslog system under the mail facility. In other words, your amavisd log messages should turn up in the same place as where your Postfix messages are written.

The next four settings concern e-mail originated by amavisd when a virus or spam message is detected. $virus_admin is the e-mail address to which you'd like virus notifications sent. This must be a valid e-mail address; update your local aliases file if the value you set here isn't yet. In practice, this probably should be the e-mail address of you, the system administrator.

It's also possible to configure amavisd to send notifications to each message's intended recipient or to its sender, but most people find this annoying, especially because the from addresses of spam and virus e-mails nearly always are forged. Don't do that.

$mailfrom_notify_admin and $mailfrom_notify_spamadmin specify the from address to use when amavisd sends virus or spam notifications, respectively.

Finally, we come to amavisd.conf's real magic: the antivirus scanner definition for ClamAV. In my default /etc/amavisd.conf file, this entire section was commented out, so I first had to delete the initial # on each line. You may or may not need to do this yourself.

You do, however, need to check the clamd socket path in this section. In Listing 2, I've changed mine from the default of /var/run/clamav/clamd to /usr/share/clamav/clamd.sock, the same path I defined in /etc/clamav.conf.

Once you've edited /etc/amavisd.conf and set the permissions on amavisd's directories accordingly, you can start the dæmon by entering the command amavisd without arguments. As with clamd, you need to enable and maybe even first create a startup script for amavisd so it starts at boot time. I advise setting this up so that clamd starts first. That way, by the time amavisd starts, clamd's socket already is in place.

Also, as with clamd, you should start amavisd as root. It demotes itself to the user and group you specified in amavisd.conf.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

postfix is not allowing the communication with the port 10025

kiran's picture

dear sir,

i have done the basic setup of postfix and have enabledthe virus scannindg using clamav with amavisd.......
the configuration is fine while testing through telnet..
can u help me out sir why postfix is not allowing the connection through the port 10025

missing files and unmet depends

dannyr's picture

I updated my repos to clamAV for Ubuntu and ran;
apt-get install clamav clamav-base clamav-freshclam clamtk libclamav1
-clamav is already the newest version.
-clamav-base is already the newest version.
-libclamav1 is already the newest version.
-Some packages could not be installed.
- unmet dependencies:
clamav-freshclam: Depends: clamav-base (= 0.88.2-1ubuntu1) but 0.88.4-0volatile1 is to be installed

I did not get any conf files or any daemons eg clamd

Any suggestions

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState