Securing the Mail: Lock Spam and Viruses Out of Sendmail


Repeat after me: “Spam and viruses bad. Locked down mail servers good.
Leaving relaying open bad. Locked down mail servers good. Leaving
virus avoidance for the end user to deal with bad. Locked down mail
servers good.” Okay, now that we’ve got that over with, let’s take a
look at some methods for locking down a popular mail server in the
Linux and UNIX realm: Sendmail.

Securing Sendmail 8.9 Against becoming A Tool for Spammers

Sendmail 8.9, the latest version, comes locked down against
relaying right out of the box: you can find out more about previous
versions by going to the Sendmail web site (Resources). So rather than focusing on initial
configuration, let’s look at a more insidious problem: taking over
someone else’s Sendmail setup and making sure they haven’t
punched any holes in it spammers might use.


Don’t roll your eyes. There are a lot of administrators who just kind
of fell into their jobs, and rather than learning the proper way to do
things will punch security holes to get their workarounds to function.
Maybe you were even one of them once, but now you know better, but
you’ve forgotten to go back and clean up all of your old messes.


The key files for your Sendmail relaying setup are /etc/mail/access,
and /etc/mail/relay-domains. /etc/mail/access is built in a series of
single-line entries, and each of these entries consists of two
components. The first half of an /etc/mail/access line contains
information on whom the rule applies to; for example, 192.168.25.3
means this rule is meant for the machine with this IP address.
The second half expresses what the rule is setting: for example, using
RELAY here tells Sendmail to allow 192.168.25.3 to relay email through
this server.


For more details on /etc/mail/access, be sure to have the Sendmail
documentation installed, and then take a look in the file
/usr/share/doc/sendmail/README.cf. This is a long document. A great
shortcut is to search through it for the term access_db, which will
take you faster to the correct spot for data on what terms are
available for this file. If you don’t know how to search through a
file, here’s the general sequence of events. Type less
/usr/share/doc/sendmail/README.cf
to view the file’s contents a screen
at a time, then type /access_db and press Enter to begin your search.
If the first time doesn’t bring you to what you’re looking for, press
N to repeat the search with the same term as before.


/etc/mail/relay-domains is a slightly different beast but only just
barely. Where /etc/mail/access is used for allowing external users to
relay mail through the server, /etc/mail/relay-domains is used for
local relaying. This file utilizes the same format as
/etc/mail/access.


For additional information, see

http://www.sendmail.org/~ca/email/relayingdenied.html.


Blocking Spam from Reaching Your Users

So you’re sure you’re not part of the spammer problem, but your
users are buried in the stuff. Fortunately there are tools out there
that can help on the server side of things. They have to be utilized
carefully, however. Whenever you try to filter out all of the bad,
whether we’re talking about web pages, email, tuna, or books, you
always tend to catch unintended items in the net.


There are outside services you can pay to filter your mail for spam,
viruses, and more, but this article focuses on self-help so let’s look
at what you can do with your own server. The key for many people is
something called a real time black hole list, which consists of a web
site whose maintainers keep track of servers that are not properly
locked down — and therefore used by spammers to annoy us all — and then
allows other sites access to this information.


There is only so much room to cover so many important things in this
article, so I’ll leave the details to the Sendmail.org documentation
(see Resources, below).


Setting Sendmail 8.9 and Up to Snag Viruses

On the virus front, Sendmail does not natively support virus scanning.
That doesn’t mean you can’t scan email for viruses in conjunction with
the Sendmail server. There are a number of tools available out there,
and typically you’ll need both a gateway (an intermediary program
between Sendmail and the antivirus program) and a virus scanner.

You can write your own gateway or make use of one of those already
out there. Two gateways known to work well with Sendmail are
Tamiz and AMaViS. (See Resources)


There are a larger number of antivirus programs out there that work
under Linux and Unix than you might have guessed. These software
packages include Sophos Sweep , Trend Micro
FileScanner, CAI’s eTrust InoculateIt, and McAffee. (See Resources)


Note that AMaViS works with a number of popular Linux and UNIX email
servers. Even if you’re not using Sendmail on your Linux or UNIX
system, there’s no excuse to leave virus issues for the end users to
deal with. Clean them up at the server end. But don’t trust them
blindly, make sure they send you notices about what’s been blocked,
and double-check on occasion to make sure nothing innocent was caught.


Wrapping Up

If you pay for bandwidth, then it’s imperative you get spam and
viruses under control. A spammer making use of your server can cost
you heavy traffic costs. The spam your users have to download
from the server costs a bundle in both bandwidth and productivity. And
last but not least, when even one of your users activates a virus,
that program then sends a surge of activity both internally and out to
the Internet.


Unfortunately, it’s not usually just one user who falls for a virus.
Look at it this way. I have a virus scanner on my Windows box and we
run a virus scanner and spam blocker on the Linux Sendmail server. I
never even knew the Klez virus existed until I started hearing people
complain about it. Even as Klez attacked repeatedly over the weeks, it
wasn’t something I personally had to deal with: in twenty-five days,
our setup stopped 187 viruses from reaching me, 178 of them being from
Klez, six of them being the new Yaha one, and some others.


That’s enough viruses to count as spam as far as lost productivity
time! And 187 times I was not at risk of activating a virus
through sloppiness. If I were a non-technical end user, what do you
think the chance might be that I might have opened at least one of
those?



Resources:

Latest Articles

Follow Us On Social Media

Explore More