A private BSD laboratory

On the last week-end I’ve decided to migrate both my SMTP front-end and public DNS servers to the new BSD platform. This implementation lets me able to run the latest version of BIND and Sendmail, thus enabling an higher level of security. In addition, the latest version of ClamAV-milter is now checking all incoming messages at the SMTP connection layer, this is important for me to get rid of a large amount of malware which has been filtered out at the next levels (usually by the heuristic spam filter), until now.

I found that ClamAV can be a good solution to fit the needs for securing the SMTP traffic and for reducing the administrative overhead brought by the daily checking of the UCE folders on my back-end Exchange systems: the mind-free quarantine management (if the scanner finds any malware, it can immediately break down the current SMTP session, even without taking care of NDR generation) and the auto update process make it a plug-and-forget solution… at least, until there will be any trouble to resolve! 😉

Yesterday night I spent more than five hours on a FreeBSD 6.1 system in testing the clamav-milter service. Do you remember my last post, in which I wrote about the need to migrate all my SMTP front-end systems to the FreeBSD platform in order to achieve a better security check on incoming e-mail traffic? Now I’m able to run a Sendmail daemon tailored to my corporate needs which works together with a good (and free) virus scanning engine, dropping infected e-mails at the SMTP connection stage without generating any NDR (Non-Delivery Report) to the sender address. Also the reporting feature (an e-mail to the postmaster mailbox) in case of virus detection fits well in my environment, where there is no scheduled notification sent to the postmaster address.

I had to work a lot to find the best installation method for my production environment: after I built all the packages needed by ClamAV (by inserting the right flags during the make process) I was able to setup the latest version of the product on the production systems without installing the ports collection. Now I want to observe it running for some days before migrating the primary SMTP front-end system too.

I must admit that I’m going to be convinced to rebuild all my front-end SMTP servers with FreeBSD systems running Sendmail, because of some important features still missing even in the ‘SMTP Transport’ role of the new Exchange Server 2007… 🙁  I already have such a system running in my corporate production environment, running as my secondary mail exchanger system, but before completing the migration to the BSD platform I would like to accomplish some additional steps.

One of the most relevant requirements is the ability to check the RCPT TO data and verify that the recipient is actually existing and active in every back-end Exchange organization, so I have spent some time to rebuild the RcptFilter solution, as I explained in the post before. Since then, I realized that to have the access file rebuild process running on each mail server is not just the best way to sync the GAL with Sendmail, since I should allow each mail server (both internal and Internet systems) to access all the Domain Controllers via LDAP, in order to let them obtain the global address list from the Exchange organization which rely on Active Directory Services to store its data.

Thus I decided to centralize the access file rebuild process, by scheduling the perl scripts execution onto the Windows Server 2003 R2 system built to be used by our IT Services group for their administrative, monitoring and management tasks. After the access file is rebuilt (everyday at the 12:00 AM), it is compressed and published on a web server to be accessible to all my FreeBSD systems, which simply have to fetch and unpack it, then to rebuild the access.db file and restart the Sendmail daemon.

So my centralized RcptFilter system is ready to run, now I only wish to bind a virus scanning engine to Sendamil before making it my first and unique SMTP Internet relay system!