Linux Server Security (2nd Edition( [Electronic resources] نسخه متنی

9.1. Background: MTA and SMTP Security

MTAs move email from one host or network to another. This task
contrasts with that of Mail Delivery Agents (MDAs), which move
mail within a system (i.e., from an MTA to a local
user's mailbox, or from a mailbox to a file or
directory). In other words, MTAs are like the mail trucks (and
airplanes, trains, etc.) that move mail between post offices; MDAs
are like the letter carriers who distribute the mail to their
destination mailboxes.
Procmail is one
popular MDA on Linux systems.

In addition to MTAs and MDAs, there are various kinds of
email
readers, including
POP3 and
IMAP clients, for retrieving email
from remote mailboxes. These clients are also known as
Mail User Agents (MUAs), of which Mutt,
MS-Outlook, Pine, and Evolution are popular examples. There is no
real-world analogue of these, unless your letters are handed to you
each day by a servant whose sole duty is to check your mailbox now
and then. But we're not concerned with MUAs or MDAs,
except to mention how they relate to MTAs.

Most MTAs support multiple mail-transfer protocols, either via
embedded code or separate executables. Nearly all MTAs, for example,
support at least UUCP
and SMTP. Nevertheless, for the remainder of this chapter,
I'll assume you're interested in
using your MTA for SMTP transactions, since SMTP has been the
dominant mail-transfer protocol of the Internet for some time.

9.1.1. Email Architecture: SMTP Gateways and DMZ Networks

No matter what other email
protocols you support internally, such as the proprietary protocols
in
Microsoft
Exchange or Lotus Notes, you need at least one SMTP
host on your network if you want to exchange mail over the Internet.
Such a host, which exchanges mail between the Internet and an
internal network, is called an SMTP gateway. An SMTP gateway acts as
a liaison between SMTP hosts on the outside and either SMTP or
non-SMTP email servers on the inside.

This liaison functionality isn't as important as it
once was: the current versions of MS Exchange, Lotus Notes, and many
other email-server products that used to lack SMTP support can now
communicate via SMTP directly. But there are still reasons to have
all inbound (and even outbound) email arrive at a single point, chief
among them security.

First, it's much easier to secure a single SMTP
gateway from external threats than it is to secure multiple internal
email servers. Second, "breaking
off" Internet mail from internal mail lets you move
Internet mail transactions off the internal network and into a DMZ
network. Now your gateway can be isolated from both the Internet and
the internal network by a firewall (see Chapter 2).

Therefore, I recommend, even to organizations with only one email
server, the addition of an SMTP gateway, even if their server already
has SMTP functionality.

But what if your firewall is your FTP server,
email server, etc.? Although the use
of firewalls for any service hosting is scowled upon by the truly
paranoid, this is common practice for very small networks (e.g., home
users with broadband Internet connections). In this particular
paranoiac's opinion, DNS and SMTP can, if properly
configured, offer less exposure for a firewall than services such as
HTTP.

For starters, DNS and SMTP potentially involve only indirect contact
between untrusted users and the server's filesystem.
(I say "potentially" because
it's certainly possible, with badly written or
poorly configured software, to run extremely insecure DNS and SMTP
services.) In addition, many DNS and SMTP servers (e.g., BIND and
Postfix) have chroot options and run as unprivileged users. These two
features reduce the risk of either service being used to gain
root access to the rest of the system if
they're compromised in some way.

9.1.2. SMTP Security

There are several categories of
attacks on SMTP email. The scenario we tend to worry about most is
exploitation of bugs in the SMTP server application itself, which may
result in a disruption of service or even in the hostile takeover of
the underlying operating system.
Buffer-overflow attacks are a typical
example, such as the one described in CERT® Advisory
CA-1997-05 (MIME Conversion Buffer Overflow in Sendmail
Versions 8.8.3 and 8.8.4; see
http://www.cert.org/advisories/CA-1997-05l).

Another danger is abuse of the SMTP server's
configurationthat is, using the server in ways not anticipated
or desired by its owners. The most widespread form of SMTP abuse is
relaying. Spammers
and system crackers alike rejoice when they find an SMTP server that
blindly accepts mail from external entities for delivery to other
external entities.

Such "open
relays" can be used to obfuscate the true origin of
a message and to forward large quantities of
Unsolicited
Commercial Email (UCE) and other undesirable email. For example, open
SMTP relays were an important attack vector for the
Hybris worm as
described in CERT® Incident Note IN-2001-02
(Open mail relays used to deliver "Hybris
Worm," http://www.cert.org/incident_notes/IN-2001-02l).

Still another security risk in SMTP is that one's
MTA will leak user and system information to prospective intruders.
Like SMTP abuse, SMTP "intelligence
gathering" usually capitalizes on sloppy or
incorrect software configuration rather than bugs per se.

The main difference between abuse and probing is intent: those who
relay UCE through your server probably don't care
about the server itself or the networks to which
it's connected; they care only about whether they
can use them for their own purposes. But somebody who probes an SMTP
server for usernames, group memberships, or debugging information is
almost certainly interested in compromising that SMTP server and the
network on which it resides.

Historically, two SMTP commands specified by RFC 2821
(Simple Mail Transfer Protocol, available at
ftp://ftp.isi.edu/in-notes/rfc2821.txt) have
been prolific leakers of such information: VRFY, which
verifies whether a given username is valid on the system and, if so,
what the user's full name is; and
EXPN, which
expands the specified mailing-list name into a list of individual
account names.

A third SMTP command, VERB, can be
used to put some MTAs into
"verbose" mode.
VERB is an Extended SMTP command and was
introduced in RFC 1700 (Assigned Numbers). Since
one of the guiding principles in IS security is
"never reveal anything to strangers
unnecessarily," you should not
allow any publicly accessible MTA server to run in verbose mode.

EXPN, VRFY, and
VERB are throwbacks to a simpler time when
legitimate users wanting such information were far more numerous than
mischievous strangers up to no good. Your MTA should be configured
either to ignore VRFY and EXPN
requests or to falsify its responses to them, and to
disregard VERB requests.

9.1.3. Unsolicited Commercial Email

Unsolicited Commercial Email (UCE)
isn't a security threat in the conventional sense:
sending UCE generally isn't illegal (unless it
involves fraud of some kind), nor is it a direct threat to the
integrity or confidentiality of anyone's data.
However, if somebody uses your bandwidth and
your computing resources (both of which can be
costly) to send you something you don't want,
isn't this actually a kind of theft? I think it is,
and many people agree. Rather than being a mere annoyance, UCE is
actually a serious threat to network availability, server
performance, and bandwidth optimization.

Unfortunately, UCE is difficult to control. Restricting which hosts
or networks may use your SMTP
gateway as a relay helps prevent that particular abuse, but it
doesn't prevent anyone from delivering UCE
to your network. Blacklists, such as the
Realtime Blackhole List (http://mail-abuse.org/rbl/),
that identify and reject email from known sources of UCE can help a
great deal but also tend to result in a certain amount of legitimate
mail being rejected, which for some organizations is unacceptable.
Anyhow, blacklists are a somewhat crude way to address UCE.

A much better approach is to use scripts such as
SpamAssassin
(available at http://www.spamassassin.org) to evaluate each
incoming email message against a database of known UCE
characteristics. With some fine-tuning, such scripts can radically
reduce one's UCE load. Depending on the volume of
email arriving at your site, however, they can also increase CPU
loads on your SMTP gateway.

9.1.4. SMTP AUTH

SMTP exploits, relaying, and abuse, including UCE, are all SMTP
problems; they're risks endemic to the SMTP protocol
and thus to many SMTP Mail Transfer Agents. But surely
there's some proactive security
feature in SMTP?

Until 1999, there wasn't: SMTP was designed with no
security features at all, not even the most rudimentary
authentication mechanism. But that changed in 1999 with the
introduction of RFC 2554, SMTP Service Extension for
Authentication (known more simply as SMTP
AUTH), which provided the SMTP protocol with a modular
authentication framework based on the generic
Simple Authentication and Security Layer
(SASL) described in RFC 2222.

SMTP AUTH allows your MTA to authenticate prospective clients via one
of several authentication schemes. In this way, you can more
effectively control such activities as SMTP relaying and you can also
provide SMTP services to remote users, even if their IP address is
unpredictable.

It's far from a panacea, and it
isn't even supported by all MTAs, but SMTP AUTH is a
badly needed improvement to the venerable SMTP protocol. Both MTAs we
discuss in this chapter support SMTP AUTH.