(e)Mail Insecurity

TCP port 25 considered harmful?

Mailing lists are a great resource, even in this Latter-Day Dispensation of Search Engines and Web Forums. While web forums have their place, there's nothing like being able to carry on an extended conversation in the comfort of your own Inbox. While reading a drive-by comment on a recent thread I participated in, I was inspired to dust off the carcass of an aborted post I'd written up a while ago, take a step back, and examine the practice of port-blocking TCP 25 -- the port used by the Simple Mail Transfer Protocol (SMTP).

Free To Be SMTP

In order to discuss this more clearly, I need to drop down to a 100-200 level discussion for a second. Please bear with me as I make sure everyone's on the same page.

First, we have two ISP networks, connected by the Internet, as shown in Figure 1:

Figure 1: A tale of two networks

Note: although I've labelled both networks here as ISPs, they could be universities, corporations, whatever -- they're a single network adminsitrative entity with a connection to the Internet.

Second, at the start of our discussion each network has its firewall and mail server configured in the following fashion:

1. All traffic on port 25 from any internal host to any external host is allowed.
2. All traffic on port 25 from any external host to the internal mail server is allowed.
3. Any messages addressed to internal recipients do not require authentication.
4. Any messages addressed to external recipient, sent from any internal host, do not require authentication.
5. Any messages addressed to external recipient require authentication.

Note: we're only focusing on email protocols here, so I'm ignoring any other protocols or blocking rules that may be defined.

This represents a traditional mail/firewall architecture. If I'm a user of My ISP, when I send a message to some other user, my mail client is configured to contact mail.my.isp over port 25. That server then forwards it on toward the recipient. If I'm out and about -- maybe I'm over at a your house sharing your wireless connection, and you're on Your ISP -- my mail client will still contact mail.my.isp over port 25. Likewise, your setup is going to work in the same fashion. Your mail client will contact mail.your.isp over port 25 whether your on Your ISP's network or some other network. Clear so far?

Also traditionally, many networks allow SMTP relaying from any IP address in their address space, usually without requiring any SMTP authentication. This means that when I'm over at your house, my connection is coming from a Your ISP IP address, so if I connected to mail.your.isp over port 25, I'd be able to submit a message to any e-mail recipient without having to provide credentials. If I connected to mail.your.isp from outside the Your ISP network, the mail server would only accept email addressed to recipient at Your ISP (thus preventing the open relay problem).

Crackdown!

In the past several years, I've seen a rising number of ISPs and corporate networks block outbound TCP 25 connections (from their network to other networks) at their firewall. So now when I'm at your house, Your ISP is blocking outbound TCP 25 and I can no longer reach mail.my.isp. I now have to temporarily change my configuration to point to mail.your.isp so I can send outgoing email. What a pain!

But it gets worse. Your ISP has now turned off all unauthenticated relay, which means that even though I'm coming from a Your ISP IP address (I'm still at your house, snarfing your wireless bandwidth), the mail.your.isp server won't accept email messages for external recipients unless I've provided authentication credentials. Since I'm a user of My ISP, I don't have them. Denied!

Our firewall and server configuration rules now look like this:

1. All traffic on port 25 from the internal mail server to any external host is allowed.
2. All traffic on port 25 from any external host to the internal mail server is allowed.
3. All other traffic on port 25 is denied.
4. Any messages addressed to internal recipients do not require authentication.
5. Any messages addressed to external recipient require authentication.

This leaves a problem, though -- what do I do when my machine is on someone else's network? More often than not, I don't have credentials to their mail server, and there's no widely available way to allow some sort of roaming credentials.

You might think that requiring 100% SMTP authentication would be the answer, and yes, it would definitely help. The problem, though, is that the use of inter-system SMTP authentication still isn't very common. My ISP can't block unauthenticated SMTP submissions to mail.my.isp because that's how the vast majority of its users' incoming SMTP message traffic will be sent; mail.your.isp doesn't have a valid set of credentials. Even if their admins did swap credentials, this doesn't scale at all; the whole point of SMTP is to accept messages from likely unknown sources.

The solution is the message submission port, which was first introduced by (IIRC) Sendmail. This port, TCP 587, is essentially a second SMTP port. However, the difference is that this port should always be configured to require authentication in order to submit any message, whether the recipient is a member of the mail server's internal domains or not. This separates our "internal" message submission traffic (regardless of which network it's originating from) away from the same port used to accept unauthenticated traffic and allows us to apply different controls appropriately.

What Do We Get?

Other than a bigger headache for users, what do mail administrators get by implementing this configuration?

• Better control over malware. By forcing all hosts on their network to contact only the approved outbound mail servers, admins can help ensure hosts under their control aren't sending messages under the control of malware, such as participating in zombie spam nets. Many spyware, worm, and zombie variants don't do anything fancy; they attempt to connect to the recipient's mail server directly. By blocking outbound TCP 25, these variants are thwarted.
• Predictable mail chokepoints. If the malware is smart enough to check the user's mail software profile and clone the settings, the messages are going to get out. Aha! But now admins can subject that outbound message traffic to spam and virus scanning. In turn, they can quickly find out if they've got a problem inside their network.
• Simpler configuration of firewall and message server. You might think that requiring two inbound ports would make things harder, but really it makes it much simpler to secure your system. On port 25, I don't allow open relay, and I don't allow authentication (which, if I'm running Exchange, makes me really happy, because that's one fewer directory harvesting attack vector). On port 587, I require authentication for all submissions. At the firewall, I allow inbound port 25 and 587 to my bridghead servers. I block all outbound 25 and let 587 through. Simple and easy, with very low chance of unintended interactions or consequences.
• Audit trails. By requiring all message submissions to be authenticated, I know which user has gotten attacked by malware when weird things start showing up in my message hygiene scanning.
• Bandwidth control. Malware running on modern hardware can easily generate enough outbound traffic to completely saturate an organization's available bandwidth. By separating the port that allows incoming unauthenticated SMTP traffic from the port that allows your users to submit outgoing/internal messages, you can now easily configure traffic shaping so that an infected machine can't dominate your connection to the world.

Some people don't like this configuration, or agree that it's a useful one. On the one hand, I sympathize; I remember running a mail server in the good old days before spam and firewalls. On the other hand, times change, and our network protocols and best practices need to adapt to keep up.

Updated: Added the bullet item for "bandwidth control," thanks to Michael's feedback.

Print | posted on Monday, August 07, 2006 11:20 AM