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!

The backup SMTP server for my public domains are running on a FreeBSD platform (it is a Sendmail daemon). Since its unique function is to relay messages to authoritative Exchange servers, it has no connection with the directory service maintaining information about active mailboxes, therefore it cannot understand if a recipient address of a message is to be managed as a valid address, even if it is sent to one of my public e-mail domains.
Obviously this behavior has always been causing the generation of many NDRs (Non-Delivery Receipts), because of the large amount of messages sent by spammers to invalid SMTP addresses. Furthermore, several NDRs cannot be delivered because also the sender SMTP address is often crafted, so generating a painful message flow and queue growth.

Since I have no time to spend in administering my Unix servers, after I tried to make Sendmail able to lookup the Active Directory at each “rcpt to” submission I took off, because it was a solution too expensive to fit my needs until some days ago, when I found a great message posted by someone who was experiencing the same concerns about the NDR message flow.

The solution is essentially build onto some perl scripts which compose the active recipient list by querying the Active Directory. Then they compile the “access” file needed by sendmail to build the relay control database “access.db”, by reading also the information contained in the “relay-domains” file under the /etc/mail directory.
I had only to write a shell script to unify all the operations (query the LDAP server, build the access and the access.db files, reload Sendmail daemon) and my Sendmail is fnally able to know if the “Rcpt to” field is a fake or valid SMTP address, without any complex MTA code change!

On the last week-end I decommissioned the Development local area network by migrating the sole machine still working in it to the Phoibos DMZ network, which is now reacheable from the Internet with an high available topology (as explained in the post “Behind an ISA 2006 Array“).

The same BSD installation is still publishing the free Phoibos weblogs collection, empowered by FreeBSD 6.1, Apache 2.2, PHP 5.6, MySQL 5.0 and WordPress 2.0… you are welcome to request your free blog activation!

The new free blogging service, published in the context of the Phoibos project, is based on a FreeBSD system, running in my corporate production network enviroment. Here is a screenshot of the console of this virtual guest machine, showing you the firsts databases containing the posts submitted by hosted users.

The experimental use of WordPress in this free hosting service will allow us to better understand the value of the services which can be empowered by this open source platform.

After I implemented the blogging engine empowering this weblog in my development area, today I wanted to challenge me with the setup of the so-called “unstable” version of the same engine, targeted to blog hosting customers.

At the first I tried to make working the package of WordPress MU fetched from the FreeBSD.org packge collection (which claimed to be the 1.5.1.3 version), but after  lot of troubles, I realized it probably was not the “right” version for me! 😛
So, after a couple of hours spent in the WPMU support forum I decided to try to download the source files straightly from the WordPress website… et voila’: after a few clicks, (and have the DB dropped and re-created)  I am finally able to host as many WordPress blogs as I want! Simply go to the http://weblogs.valsania.it/ to see the result, and… happy blogging! ;)