Big Bubbles (no troubles)

What sucks, who sucks and you suck

Root Yourself to the Ground

The pace of change in the Unix world has sure picked up since Linux took off. Whereas previously a sysadmin could coast for years on knowledge of a few key packages like sendmail V8.6 and BIND v8, secure that little was likely to change and the skills were transferrable to every site (ahem), suddenly the Unix infrastructure can change overnight (or at least between Solaris releases) and you find yourself having to relearn basic configurations on the fly.

Case in point: Sendmail in Solaris 8 & 9.

Here’s a typical secure Sendmail configuration for a client (i.e. outgoing mail only, to a central hub or relay): * Config file built using the nullclient feature. * sendmail daemon disabled. * sendmail run in queue-processing mode at regular intervals via cron (i.e. not listening on the SMTP port). In previous Solaris releases, this involved disabling the sendmail startup script and adding an entry to the root crontab to run sendmail -q.

In Solaris 8, Sun made things easier by allowing you to change the normal mode of the program via the /etc/default/sendmail file; sendmail would run as a daemon, but only in queue-processing mode.

In Solaris 9, Sun have updated Sendmail to V8.12. This supports a new feature called message submission, defined in RFC 2476 (wha’? did I miss a meeting?). Mail submission requires a second sendmail process using a different config file called (which Sun warns you not to edit) and running under the smmsp UID (huh??). It also assumes that it can submit mail to a sendmail daemon running on the local host in listen mode - if you configured sendmail for queue-only as above then bad luck, you lose (and you won’t receive any email to let you know either).

To their credit, Sun actually discuss this issue in the Solaris 9 documentation (Resource Management and Network Services guide) and provide an alternative secure configuration, which involves editing the sendmail config to bind the daemon only to localhost with the line: DAEMON_OPTIONS(`NAME=NoMTA4, Family=inet, Addr=’)dnl (This is the way that Sendmail on Red Hat/Fedora is configured out of the box.) This advice seems to have been taken from the Sendmail FAQ, Q3.44. But who reads the FM, right?

**Update, 2004-03-09: ** Just as well, because the advice isn’t complete. You also need to lock down the MSA port (587), which is used by the mail submitter. Insert the following two lines after the one above: FEATURE(`no_default_msa’)dnl DAEMON_OPTIONS(`Name=MSA, Port=587, Addr=, M=E’)dnl (And remember not to use any of these macros in comments unless they’re `quoted’, otherwise they will be expanded and insert spurious lines in your config. He said from painful experience.) Thanks to Scott Burch on the SAGE members list for the extra advice. (Scott also suggests disabling the MTA and using your central mailhost as the MSP in instead, but Sun warn you not to touch that file.)

All these configurations are discussed in the Sun BluePrints paper, Solaris Operating Environment Security (Dec 2002). Learning what the goshdarnheck RFC 2476 is and what it means is left as an exercise for the reader (but please post a summary back to me when you’ve done it ;-).