By Kurt Seifried Rev 0.1
Securing specific services - Sendmail (S07.C04)
Sendmail is another one of those services most of us have have a love/hate relationship with. We hate to admin it and we'd love to replace it. This is however not 100% possible, as sendmail has many features and stability, with the downside being it runs as root. Newer mailer packages such as qmail, vmailer address these problems however they also suffer problems, qmail lacks certain features (anti spam/UBE) that sendmail has, as well as a no binary distribution clause, vmailer OTOH addresses all these things and more, but hasn't yet been released. So what are we to do? Get qmail, compile it, move it to the mail server, trouble shoot it, etc, or rpm -ivh the latest sendmail and get it running in <2 minutes? If you want to try qmail click here, if not keep reading.
Sendmail has earned itself a very bad reputation for security, however I find it hard to blame software when I find systems running versions of sendmail like 8.6.X, we are now up to 8.9.1, common folks. The root of the problem is that almost everyone used to run sendmail, as soon as a big was found, finding a system to exploit wasn't all that hard =). The last few releases of sendmail have been quite good, no root hacks, etc, and with the new anti spam features sendmail is finally starting to show that it is quite a good MTA. A re-write of sendmail ("son of sendmail" yikes) is planned, between this, a more advanced qmail, and vmailer, unix admins will have it made.
Chrooting sendmail is definately a good option, but a lot of work, and since it runs as root, rather debatable as to the effectiveness of this. I find that by keeping sendmail up to date, you can pretty much avoid any crack attempts, of course if a new exploit comes out and the patch takes 24 hours we're up poop creek, the same applies to any piece of software though. Also by using sendmail's advanced anti spam features you can effectively block 99% of all spam coming to you, and easily lock down any relaying your site will do (of course trusted internal hosts could still use you as a relay, but at least you have some control over these hosts, you can either remove their accounts, firewall them, etc).
Keeping sendmail up to date is relatively simple, I would recomend minimally version 8.8.8, preferably 8.9.0 or 8.9.1 (the 8.9 series has more anti-spam features, however RedHat's 8.8.7 rpm has most of these features as well). RedHat currently ships 8.8.7, and 8.8.8 and 8.9.X series are available in their contrib directory for hurricane/etc. You can also get the source from ftp.sendmail.org, but compiling sendmail is not for the faint of heart or those that do not have a chunk of time to devote to it (personally I avoid source code nowadays like the plague ;).
Sendmail only needs to be accesible from the outside world if you are actually using it to receive mail from othr machines and deliver the mail locally. If you only want to run sendmail so that local mail delivery works (ie a stand alone workstation, test server or other) and so mail can easily be sent to other machines simply firewall off sendmail, or better, do not run it in daemon mode. Sendmail can be run in a qeueue flushing node, where it simply 'wakes' up once in a while and processes local mail, either delivering it locally, or sending it off on it's way across the 'net. To set Sendmail to run in queue mode:
edit /etc/rc.d/init.d/sendmail and change the line: daemon /usr/sbin/sendmail -bd -q1h to: daemon /usr/sbin/sendmail -q1h note if you use your system to send lots of email you may wish to set the queue flush time lower, perhaps -q15m (15 minutes) now outbound and system internal mail will behave just fine, which unless you run a mail server, is perfect.
Now for all those wonderful anti-spam features in sendmail. Sendmail's configuration files consist of:
/etc/sendmail.cf - Primary config file, also tells where other config files are ---- 8.9.X /etc/mail/ - 8.9.X holds _all_ the other sendmail config files instead of them being scattered around, whitin this dir we have: Makefile - allows easy create of the deny database access - Access list database (for spam stomping) aliases - aliases file domaintable - Domain table (adding domains) mailertable - Mailer table (overriding domains) majordomo - the other alias file relay-domains - Hosts that will permit relaying sendmail.ct - this is equivalent to setting class "t" sendmail.cw - file containing names of hosts for which we receive email sendmail.hf - location of help file virtusertable - Virtual user table (maps incoming users) ---- 8.8.X /etc/sendmail.cw - file containing names of hosts for which we receive email /etc/aliases - holds all mail aliases /etc/mail/ - holds most of the security related, and address remapping files Makefile - allows easy create of the deny database deny - plain text file for anti spam listing deny.db - db file made from deny ip_allow - list of ip addresses that can use our relay (internal, trsuted hosts) name_allow - hostnames that can use our relay, clients/etc relay_allow - names of domains we relay to (in association with MX records for holding mail while you use the server for doom/etc)
The aliases and majordomo file are pretty straightforwad, they simply contain aliases in the form 'name: name2' where all mail going to name, gets redirected to name2, which can be an email address, program or whatever.
Please note this section is not yet complete, but I wanted to put up at least a minimal amount of info for securitn Sednmail
Securing DNS | Back to Section 7
Contact Kurt Seifried, All rights reserved Kurt Seifried 1998, content and information may not be reposted physically or electronically without the express permission of the author, this includes but is not limited to www mirror sites, email, usenet news, etc.