Republished with permission from WatchGuard Technologies, Inc . Originally published 21 Sep 2001.

Introduction to WatchGuard’s SMTP Proxy by Fred Avolio , Avolio Consulting, Inc . 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. Premises 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: Open the Firebox Policy Manager and click Setup . Click Authentication . Click the Aliases tab, then click Add . For the Host Alias Name , type whatever you want to name your group of mail servers. In this example, I’ll type mailhubs .  Click Add , then click Add Other . From the Choose Type drop-down menu, select the appropriate type. For example, if you have only one mail server, choose Host IP Address . If you have a bunch of mail servers with consecutive IP addresses, choose Host Range . Then, in the Value box, type the IP address of your mail server(s). When done entering IP addresses of mail servers, click OK in each dialog box until you return to the Aliases tab. You should see the new group at the bottom of the list of aliases. Click OK . You have now defined a group of mail servers. To direct all e-mail to your mail servers: From the Policy Manager, click Edit , then Add Service . Click the plus sign next to Proxies , and pick SMTP . Click Add , then OK . From the Incoming tab, use the drop-down menu to select Enabled and Allowed . Under the box labeled To: , click Add .  Scroll down the list of Members until you find mailhubs (or whatever you named your mail servers group in the procedure above). Select it, then click Add . Click OK , which returns you to the SMTP Proxy Incoming box. Your policies are now configured to allow e-mail to come From: Any and go To: mailhubs .  Technically, you don’t need to bother logging allowed packets. Your e-mail servers probably already logs everything. But initially (for your edification), click Logging and enable Enter it in the log for all categories. Then click OK to return to the SMTP Proxy box. 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. Properties (Incoming) 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: Idle Timeout . Remember that our proxy is playing the part of an SMTP server. The real servers are in the mailhubs group. If the proxy thinks it is reading incoming e-mail, and 600 seconds (the default) has gone by with no action, it is allowed to just drop the connection. Maximum Recipients. This setting allows you to specify how many addresses can receive one e-mail message. This is intended for spam control, since spammers often send e-mail with many, many recipients in one message. But so might senders of “legitimate” e-mail, so tune this number to what is normal at your site. If you don’t know what is normal, an analysis of your mail hub’s logs should give you a clue. Maximum Size is a way to control the size of messages you’ll allow through your gateway. If a message is larger than this number (in kilobytes), it will be rejected, so be careful when changing it and, again, know what is normal .  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. Properties (Outgoing) 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 user1@host1.example.com or user2@host2.example.com, would appear on the outside to come from user1@example.com and user2@example.com. 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. [Attachment denied by WatchGuard SMTP proxy (type "application/octet-stream", filename "foo.ppt")] 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: [Attachment denied by WatchGuard SMTP proxy  (type "text/plain", filename "junk.bat")] 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: Return-Path: <fred@avolio.com> … Received: from [168.191.22.140] (helo=hub.avolio.com)       by dfw-mmp1.email.verio.net with esmtp       id 15a5m1-0003z3-00       for fma@al.org; 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 <fma@al.org>; Thu, 23 Aug 2001 21:28:39 -0400 Errors-to: <error@avolio.com> Message-Id:<4.3.2.7.2.20212648.00b3850@hub1.avolio.com> X-Sender: avolio@mail.veriomail.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 23 Aug 2001 21:27:04 -0400 To: avolio@clark.net From: Frederick M Avolio <fred@avolio.com> Subject: test 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: Return-Path: <fred@avolio.com> … Received: from [168.191.22.140] (helo=avolio.com)        by dfw-mmp3.email.verio.net with esmtp        id 15a5nQ-0004wF-00        for fma@al.org; Fri, 24 Aug 2001 01:30:05 +0000 Errors-to: <error@avolio.com> Message-Id: <4.3.2.7.2.20212648.00b3850@hub1.avolio.com> Date: Thu, 23 Aug 2001 21:28:28 -0400 To: avolio@clark.net From: Frederick M Avolio <fred@avolio.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. ## Further Reading Simple Mail Transfer Protocol, RFC821 , RFC2821   Standard for the format of ARPA Internet text messages, RFC822 , RFC2822 Anti-Spam Recommendations for SMTP MTAs, RFC2505 Rose, Marshall and Strom, David, Internet Messaging: From the Desktop to the Enterprise , Prentice Hall, 1998. [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.