Republished with permission from WatchGuard Technologies, Inc . Originally published 21 Sep 2001.
Introduction to WatchGuard's SMTP Proxy
Simple Mail Transfer Protocol is the standard for transmitting e-mail over the Internet. The Firebox comes with an SMTP proxy which, when properly configured, can protect your network from many e-mail worms, Trojans, and viruses. This article walks you through some of the SMTP Proxy features and options, explains why you'd want them on or off, and shows sample logs of the results. In this limited space, I can't be exhaustive-but that means this won't be exhausting , either. So here's the SMTP Proxy short course.
To know what to do with any proxy, you first need an overall security approach. That's what the proxy supports. Here are security premises I recommend for the SMTP Proxy.
1. That which is not expressly permitted, is denied. If you've been around firewalls for any length of time, you've heard this. The only services, connections, protocols, or anything allowed are those specifically allowed. If you haven't enabled it, it should be-by default-disabled.
2. A firewall cannot sanitize traffic it doesn't see. You need to make sure that e-mail can flow through only one logical path: through the Firebox. In this way, the Firebox will be able to filter out possible harmful content in all your e-mail.
3. A firewall should defend . It should reduce or eliminate vulnerabilities and risk. To do this, the Firebox limits services (in support of premise #1), and controls those services that are allowed (for more on this philosophy, see my column, " One Size Never Fits All "). Another way to defend is to hide potentially useful information from would-be attackers. So, the SMTP proxy, for example, might hide internal addresses and remove overly helpful headers. (Why would you want someone to know that you are using "Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)"?)
Basic Proxy Setup: Incoming and Outgoing
With those premises established, we're ready to set up proxied SMTP. As we begin, the whole idea is that incoming e-mail should be able to come from anywhere on the Internet but only go to your mail hubs (your designated mail processing systems). You may have one e-mail server, you may have a hundred, but you want to specify them.
Specifying these requires two steps in the Firebox's Policy Manager: 1) naming and defining your mail servers as one group; and 2) telling the SMTP Proxy to direct mail to that group. Here's how you accomplish those two tasks.
To define your mail servers as a group:
You have now defined a group of mail servers.
To direct all e-mail to your mail servers:
The process for configuring outgoing mail (e-mail from your organization to the world) is similar to what you've just done for incoming mail, but reversed. SMTP should be Enabled and Allowed From: mailhubs To: Any . So, e-mail can only come in from the outside to the mail hubs, and can only go out from them.
Now it gets more interesting.
If you followed the procedures above, you have used the Incoming and Outgoing tabs in the SMTP Proxy window. There's one tab left: Properties. Properties can be applied to both Incoming and Outgoing e-mail. To continue our walk-through, click Properties , then Incoming .
Under the General tab, we find some basic SMTP set-ups:
We move now to the Content Types tab. Here, you permit or deny messages based on MIME header types and attachment type. Considering the recent rash of SirCam Trojan Horses and the birth of the Nimda worm, content type screening may be the most important feature of the SMTP Proxy.
The MIME content types (listed under Allow only safe content types ) is a bit tough to figure. Remember Premise #1? You have to list all the MIME types you wish to permit. By default, "application/octet-stream" is not permitted. That means no receiving binary files, such as a Microsoft PowerPoint(tm) presentation. Will this work with your organization's business requirements? You need to do some planning, and understand any error messages that appear in your logs. (We'll take a look at those in a moment.)
The next field, a list of attachment types, is a list of what to deny . A filename can have any extension (e.g., "report.foozbain"), but only certain extensions are automatically treated as executable by your e-mail client just because of their extensions. To this list, add file name and extension patterns that are associated with virus or worm attacks (for example, "love-letter*" blocks the well-known I Love You virus).
The next tab is Address Patterns . This is used for anti-relaying. Every e-mail relay (an e-mail post office) has a notion of what e-mail addresses it handles. Like the local post office in a town, addresses in that town are handled by local delivery, and addresses outside of the town go someplace else. "Spammers" use open relays-mail relays that will take mail from anywhere and send it to anywhere-- to bulk mail a single message to thousands of e-mail addresses in a single action. Your e-mail gateway should only handle mail that is from your domain (or domains), or to your domain. Address Patterns is where you specify this. If your mail hub handles relaying correctly, you can ignore this setting (some firewalls do not correctly relinquish this control to the mail hub, but the Firebox does). If you are uncertain about whether your mail hub is up to the task, configure the Firebox to accept e-mail from anywhere ( Allowed from: *), but only allow recipients in your domain (enter your domain, or domains, under Allowed to: )
The Headers tab lets you specify what headers are allowed. (Standard RFC822 and proposed standard RFC2822 lists all the recognized headers.) You could allow any in-coming header, but why would you? Some headers have been exploited to an attacker's advantage, such as an old exploit against a bug in Sendmail that used the Errors-to: header. And most sites don't ever see more than a few header types. So, here you specify the kinds of headers you accept, so the proxy can discard the rest.
Features enabled on the Logging tab are straightforward. I'd log removal of headers and extensions, and go ahead and log auditing and accounting information. Your e-mail server probably does a fine job of that, but you may find it convenient to have these logged in with other Firebox activity.
If you've been following along so far, clicking OK returns you to the SMTP Proxy's Properties tab and saves your work. Clicking Outgoing applies similar controls for outbound e-mail. You'll find a now-familiar Idle timer for outbound connections, and a list of allowed header patterns. Masquerading is something your e-mail hub probably does fine, but most mail servers could be more thorough. Masquerading makes outgoing e-mail seem to have uniform addresses. So, for example, mail from email@example.com or firstname.lastname@example.org, would appear on the outside to come from email@example.com and firstname.lastname@example.org.
Masquerading also plays a role on the Logging tab features. We want to enable Log-Message ID masquerading to hide the names of inside computers. Though "security through obscurity" is unwise as a sole defense, there is absolutely nothing wrong with making it harder for an attacker to attack. Again, just for grins and education, I'd log everything. You can always ratchet it down later.
Now for the logs
Let's look at a few examples of what a configured SMTP Proxy contributes to your logs. I've shortened the log entries for readability here. The 10.* addresses are IP addresses on my test network. 10.0.0.0 is External and 10.1.0.0 is Trusted.
allow in eth0 48 tcp 20 128 10.0.0.3 10.1.0.20 1047 25 syn (SMTP)
[10.0.0.3:1047 10.1.0.20:25] removing ESMTP keyword "ENHANCEDSTATUSCODES"
[10.0.0.3:1047 10.1.0.20:25] removing ESMTP keyword "DSN"
[10.0.0.3:1047 10.1.0.20:25] removing ESMTP keyword "ONEX"
[10.0.0.3:1047 10.1.0.20:25] removing ESMTP keyword "ETRN"
[10.0.0.3:1047 10.1.0.20:25] removing ESMTP keyword "XUSR"
[10.0.0.3:1047 10.1.0.20:25] removing ESMTP keyword "AUTH"
The entries above indicate a normal inbound message. The SMTP proxy threw away the Extended SMTP (ESMTP) commands it either didn't understand or decided were dangerous. (I'll write about these and headers next month.) The e-mail itself was delivered successfully.
allow in eth0 48 tcp 20 128 10.0.0.3 10.1.0.20 1045 25 syn (SMTP)
[10.0.0.3:1045 10.1.0.20:25] removing ESMTP keyword "ENHANCEDSTATUSCODES"
[10.0.0.3:1045 10.1.0.20:25] removing ESMTP keyword "DSN"
[10.0.0.3:1045 10.1.0.20:25] removing ESMTP keyword "ONEX"
[10.0.0.3:1045 10.1.0.20:25] removing ESMTP keyword "ETRN"
[10.0.0.3:1045 10.1.0.20:25] removing ESMTP keyword "XUSR"
[10.0.0.3:1045 10.1.0.20:25] removing ESMTP keyword "AUTH"
[10.0.0.3:1045 10.1.0.20:25] denied Content-Type: "application/octet-stream"
The above e-mail contained a Microsoft PowerPoint(tm) document. The proxy denied entry to the binary file (MIME type "application/octet-stream"). When it was delivered the message contained this line in place of the PPT file.
denied by WatchGuard SMTP proxy \
When a file with an executable attachment was sent, the log showed:
[10.0.3:1046 10.1.0.20:25] pattern "*.bat" found in Content-Disposition \ parameter "filename": "junk.bat"
and in my e-mail client I received:
denied by WatchGuard SMTP proxy
You can customize this warning message.
Finally, let's look at a few outbound messages.
First, here's how some headers looked, without the SMTP Proxy's masquerade facility:
Received: from [126.96.36.199] (helo=hub.avolio.com)
by dfw-mmp1.email.verio.net with esmtp
for email@example.com; Fri, 24 Aug 2001 01:28:38 +0000
Received: from system1.avolio.com (system1.avolio.com [10.1.0.2])
by hub.avolio.com with ESMTP id f7O1Sci13128
for <firstname.lastname@example.org>; Thu, 23 Aug 2001 21:28:39 -0400
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 23 Aug 2001 21:27:04 -0400
From: Frederick M Avolio <email@example.com>
Note the information leakage: 1) the workstation name (system1) is revealed, with IP address; 2) the inside mail hub name is exposed (the address is really that of the Firebox); 3) the X-sender line contains my account name and the ISP; and 4) the X-mailer line shows what mail client I use.
The proxy hides that information. The same message through the proxy:
Received: from [188.8.131.52] (helo=avolio.com)
by dfw-mmp3.email.verio.net with esmtp
for firstname.lastname@example.org; Fri, 24 Aug 2001 01:30:05 +0000
Date: Thu, 23 Aug 2001 21:28:28 -0400
From: Frederick M Avolio <email@example.com>
Note, the information leak is stopped. No internal hostnames appear in the message as delivered.
To proxy or not
One of the greatest threats on the Internet today is infection by viruses and Trojan Horse programs. And most of those are borne to our networks in e-mail messages. With security, the more granular you can make your decision making for protection and defense, the better. The SMTP Proxy provides the kind of nuanced control that should make a network administrator sleep more easily. Now that you've gotten acquainted with it, I hope you'll make a point of using it. ##
[Editor's Note: Fred is too modest to mention that he is co-author of Sendmail: Theory and Practice , published by Butterworth-Heinemann, ISBN: 1555581277. Edition 2 is scheduled to come out in December, 2001.]
Copyright(c) 2001, WatchGuard Technologies, Inc. All rights reserved. WatchGuard, LiveSecurity, Firebox and ServerLock are trademarks or registered trademarks of WatchGuard Technologies, Inc. in the United States and other countries.