6.4. SMTP

 < Day Day Up > 

The Simple Mail Transfer Protocol, which governs mail flow, was not designed with security in mind. By default, SMTP servers will accept connections from anywhere and allow anyone to interact with the daemons providing service. What's worse, the daemons believe everything you tell them, as shown in Example 6-4. This conversation can be easily carried out by connecting to port 25 on a mail server via telnet. Lines starting with a number are mail server responses, highlighted lines are commands sent to the mail server.

Example 6-4. SMTP conversation
 220 woot.home.korff.org ESMTP Sendmail 8.12.9/8.12.9; Sat, 11 Sep 2004 11:52:26  -0400 (EDT) HELO im.your.father.luke 250 woot.home.korff.org Hello [172.16.0.2], pleased to meet you MAIL FROM: <darth@vader.net> 250 2.1.0 <darth@vader.net>... Sender ok RCPT TO: <yanek> 250 2.1.5 <yanek>... Recipient ok DATA 354 Enter mail, end with "." on a line by itself From: "Darth Vader" <darth@vader> To: Nobody! Date: Yesterday Subject: Tomorrow I'd give my right hand for an open relay. . 250 2.0.0 i8BFqQwu008586 Message accepted for delivery QUIT 221 2.0.0 woot.home.korff.org closing connection Connection closed by foreign host.

It's important to know what's happening during this SMTP transaction, so let's take these lines one by one.


HELO

The HELO request allows the client to identify itself to the server. The server will attempt to do a reverse lookup on the IP address of the incoming connection. In this example, the reverse lookup failed, so the IP address of the client appears in the response. After the HELO, there is a new "envelope" ready for the coming mail message. These days, most mail clients use the extended hello command, EHLO, which is a way of simultaneously identifying yourself and asking the server, "What are your capabilities?"

HELO requires a client to claim an identity. It's then possible for the server to reject the claim under certain situations:

  • When the IP address does not reverse resolve into the hostname provided as an argument to the HELO (DNS PTR record incorrect or missing)

  • When the hostname provided as an argument to HELO does not resolve at all. (DNS A record missing)

  • When the server has been configured to block the host, the domain in which the host resides, or the netblock in which the host resides

Unfortunately if you choose to configure your mail server in this way, you'll have throngs of unhappy users beating down your door because you're blocking a lot of legitimate mail. Too many administrators of mail servers know too little about DNS.


Envelope information

The subsequent MAIL FROM: and RCPT TO: commands are very much like writing your target and return address on the outside of a regular envelope. This SMTP envelope information governs where the mail is routed. Note that recipients do not always have access to this information after the message is delivered.


DATA

The DATA command tells the mail server that all subsequent input is going to be the mail message. The server will expect a series of lines to be considered the mail "header" followed by a blank line, followed by the message body. A period (.) on a line by itself marks the end of the message.


QUIT

As the name implies, this is used after the message has been sent to the mail server and the client wishes to terminate the connection.

6.4.1. Envelope Versus Header

Most ordinary users don't really understand that SMTP is very much like regular mail. There is an envelope that contains address information and determines how the message contained "within" is to be routed. One important difference is that with SMTP, the raw envelope information is often discarded after message delivery. You may look at a message and see that it was addressed to myaccount@home.com, but in fact you received it at myaccount@work.com.

The key here is that when you look at a message in your MUA, you are examining the partial contents of the message header and the message body, not the envelope. Worse, the partial header information typically shown by most MUAs is never verified and thus cannot be trusted. In order to fully understand where the message came from and how it was sent, you must look at the contents of the entire message (all headers and body), as seen in Example 6-5.

Example 6-5. Message from Darth Vader
From darth@vader.net Sat Sep 11 11:56:11 2004 Received: from im.your.father.luke ([172.16.0.2])         by woot.home.korff.org (8.12.9/8.12.9) with SMTP id i8BFqQwu008586         for <yanek>; Sat, 11 Sep 2004 11:54:00 -0400 (EDT) Message-Id: <200409111554.i8BFqQwu008586@woot.home.korff.org> From: "Darth Vader" <darth@vader> To: Nobody! Date: Yesterday Subject: Tomorrow Status: RO I'd give my right hand for an open relay.

You'll notice three headers have been added: a From line, Received lines, and Message-Id. Carefully examining the Received message headers will help you trace how messages reached the target systems and what systems (not people!) were responsible for sending the message.

6.4.2. Security Implications

There is no native security here. As the acronym indicates, SMTP is simple. It provides a means for messages to get from point A to point B, and that's it. Senders are not verified in any way. There are no provisions to ensure that only the recipient is able to read the message. Messages are transported from the sender to the recipient across any number of mail servers in clear text. Fortunately, as security has become a greater concern in recent years, several add-on systems provide some of this functionality.

6.4.2.1 SMTP AUTH via SASL

The Simple Authentication and Security Layer (SASL) provides "authentication support to connection-based protocols" like SMTP. It's been built in accordance with RFC 2554 that defines how clients can authenticate themselves to an SMTP server. You'll often see the term "SMTP AUTH" used almost interchangeably with SASL. The former is the service extension to SMTP defined in the RFC to allow for authentication. The latter is the library that actually does the authentication.

SMTP AUTH lets administrators deploy mail servers that allow anyone to send mail, as long as they can authenticate. It doesn't help a recipient verify that a message sent from a particular address actually came from the person listed on the To: line. Nor does it guarantee that the message has not been modified in transit. Its most common use is to allow legitimate senders to use the organization's mail server even when they are coming from unknown and untrusted networks, like WiFi hotspots and hotels.

You might be thinking that you could configure your mail server to only send messages if the sender is from your domain, regardless of the IP from which the connection was made thus alleviating the need for SMTP AUTH. Think again. SMTP headers are trivially faked as we will discuss later, and this style of configuration makes your mail server an open relay.


6.4.2.2 TLS

Transport Layer Security (TLS), which supercedes Secure Sockets Layer (SSL), is a communications protocol that provides private and reliable communications by cryptographic means. TLS is often coupled with SASL to provide authentication over an encrypted connection so that usernames and passwords are not transmitted in clear text.

While SASL combined with TLS does provide a flexible and secure way for roaming users to send mail through your mail server, it is not the only option. Other approaches include "POP before SMTP," which uses the authentication in a POP session to create a window of time during which an SMTP session originating from the same client IP address will be permitted to relay through the system. Another alternative is client-based certificates that allow users who have certificates installed on their computer (wherever they are) to authenticate. While these options are both viable and used by various organizations, SASL combined with TLS is easy to implement, secure, and flexible. Thus it is this option that we cover in this chapter.

6.4.2.3 SPF

The neverending war against SPAM has given rise to the Sender Policy Framework (SPF). While SASL and TLS together allow responsible administrators to restrict who uses their servers to send mail, a plethora of uninformed administrators are still running open relays. SPF provides a mechanism for MTAs to verify that the server sending a message from a given domain is authorized to do so. In Example 6-4, if SPF guidelines were followed, the mail server woot.home.korff.org that received mail from 172.16.0.2 would look for a specially formulated TXT record for vader.net in order to determine whether 172.16.0.2 is allowed to send mail from that domain. If everyone created these specially formulated TXT records for their domains, mail servers could verify senders and reject mail if the server was not authorized to send mail from that domain. Of course if everyone ensured their servers weren't open relays, that would help, too. The trouble is, it's difficult to make everyone do anything in particular.

SPF continues to be a controversial "solution" to SPAM for a variety of reasons. For more information about this framework, see the SPF resources at the end of this chapter. One final piece of good news: SPF support, for those who want it, is available as a plug-in to SpamAssassin Version 3.0.0.

6.4.2.4 Message integrity, privacy, and non-repudiation

Another category of problems associated with sending and receiving email might be summarized as "message validation." First of all, without additional software, there's no way to guarantee that the message a recipient receives is the same message that the sender sent. In other words, there is no guaranteed message integrity. Second, because messages are not encrypted during transmission, a rogue intervening mail server could easily redirect unencrypted messages to another host. Thus there's no expected privacy. Finally, the recipient has no way to know for sure who sent the message; she can only see who's listed on the From: line. In other words, there is no ability to provide non-repudiation.

These problems are grouped together because they can be solved through cryptographic means. Products like Pretty Good Privacy (PGP), the GNU Privacy Guard (GPG), and the Secure MIME (S/MIME) standard are all capable of providing message integrity, privacy, and non-repudiation. Unfortunately, an appropriate treatment of these methodologies and the underlying concepts in cryptography are well beyond the scope of this chapter. It's important to be aware that these problems exist so that if you need to address them at some point, you'll know you have reading to do.

     < Day Day Up > 


    Mastering FreeBSD and OpenBSD Security
    Practical Guide to Software Quality Management (Artech House Computing Library)
    ISBN: 596006268
    EAN: 2147483647
    Year: 2003
    Pages: 142
    Authors: John W. Horch

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net