Paranoid Penguin - Adding Clam Antivirus to Your Postfix Server
Our ClamAV and Amavisd-new dæmons are configured and running. Only a couple more tasks remain, configuring Postfix for content filtering and updating ClamAV's virus databases.
Important note: the following assumes that Postfix already is configured for and successfully performing its normal receiving/forwarding duties.
First, open /etc/postfix/master.cf with your text editor of choice, and add the lines in Listing 3 to the bottom of the file, if they aren't there already.
Listing 3. Lines to Add to /etc/postfix/master.cf
smtp-amavis unix - - y - 2 smtp -o smtp_data_done_timeout=1200 -o disable_dns_lookups=yes 127.0.0.1:10025 inet n - n - - smtpd -o content_filter= -o local_recipient_maps= -o smtpd_client_restrictions= -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks, ↪reject_unauth_destination -o mynetworks=127.0.0.0/8 -o strict_rfc821_envelopes=yes -o smtpd_error_sleep_time=0 -o smtpd_soft_error_limit=1001 -o smtpd_hard_error_limit=1000
The smtp-amavis section defines Postfix's outbound communications, using the SMTP protocol, with amavisd. It corresponds to the following line you should add or edit in /etc/postfix/main.cf:
content_filter = smtp-amavis:[127.0.0.1]:10024
This line tells Postfix to send all incoming e-mail to 127.0.0.1, the local system, on TCP port 10024, amavisd's default SMTP listening port, by using the smtp-amavis interface we defined in master.cf. You can change amavisd's listening port by editing the $inet_socket_port parameter in /etc/amavisd.conf.
The second section in Listing 3 defines the inbound interface on which Postfix should accept messages returned by amavisd. In other words, Postfix listens on the local loopback IP 127.0.0.1 on TCP port 10025, which are the address and port to which amavisd sends notifications and forwarded messages by default. You can change amavisd's notification and forwarding address and ports by editing the parameters $notify_method and $forward_method parameters, respectively, in /etc/amavisd.conf. After editing master.cf and main.cf, you need to restart or reload Postfix.
Before we go any further, let's test the system. The simplest way to test is to send yourself an e-mail message containing the following string, which is not a real virus but a test string called the Eicar Test Signature:
If everything is working, amavisd sent an e-mail to the account you specified in amavisd.conf's $virus_admin parameter, and the message should be quarantined in the directory specified in amavisd.conf's $QUARANTINEDIR parameter.
I highly recommend tailing your mail log while performing this test. Type tail -f /var/log/mail, and Postfix and amavisd will log their actions there. In my own experience, this is the fastest way to identify problems, especially if you increased amavisd's log-verbosity as described earlier.
Also, be sure to do at least one test with clean e-mail to ensure you haven't impaired Postfix's ability to receive and deliver unfiltered mail.
There's only one thing left to do, but it's important: update ClamAV's virus-signature databases and create a cron job to do so automatically every day. ClamAV includes a utility called freshclam for this purpose.
Because using freshclam is the simplest task in this entire undertaking, and because I'm basically out of space for now, I leave it to you to explore the freshclam(1) and freshclam.conf(5) man pages. Suffice it to say that in normal practice you use the command form freshclam -l /path/to/logfile, where /path/to/logfile specifies the file to which you want freshclam to write its logs.
It's recommended that you run freshclam every couple of hours. The easiest way to do this is by running freshclam in dæmon mode via the -d and -c startup options. See the freshclam(1) man page for more information.
With that, you now should have a ClamAV-enabled SMTP gateway or at least be started down the road towards one. If you're having problems, the on-line Resources includes additional Postfix plus Amavisd-new tutorials. Good luck!
Resources for this article: www.linuxjournal.com/article/7811.
Mick Bauer, CISSP, is Linux Journal's security editor and an IS security consultant in Minneapolis, Minnesota. He's the author of Building Secure Servers With Linux (O'Reilly & Associates, 2002).
|Secure Server Deployments in Hostile Territory, Part II||Jul 29, 2015|
|Hacking a Safe with Bash||Jul 28, 2015|
|KDE Reveals Plasma Mobile||Jul 28, 2015|
|Huge Package Overhaul for Debian and Ubuntu||Jul 23, 2015|
|diff -u: What's New in Kernel Development||Jul 22, 2015|
|Shashlik - a Tasty New Android Simulator||Jul 21, 2015|
- Secure Server Deployments in Hostile Territory, Part II
- Hacking a Safe with Bash
- KDE Reveals Plasma Mobile
- Huge Package Overhaul for Debian and Ubuntu
- Home Automation with Raspberry Pi
- Shashlik - a Tasty New Android Simulator
- The Controversy Behind Canonical's Intellectual Property Policy
- Embed Linux in Monitoring and Control Systems
- diff -u: What's New in Kernel Development
- General Relativity in Python