Spam Gateway
From Superk
|
|---|
These are my notes on how to go about configuring a spam gateway that will accept mail, process it then pass it on to another mailserver for local delivery. This gateway does not store any mail itself nor does it act as a mere proxy service for SMTP (see reasons below). These notes are not complete nor are they intended to be. They are an extension of some lecture notes presented by a friend of mine, Sam Hart, for his local LUG, CINLUG.
SMTP Proxy vs. SMTP Gateway
There is a big difference between a SMTP proxy & gateway as I recently found out. A proxy server will simply filter traffic in a somewhat transparent manner while letting the actual server it services do all the work. In the case of a SMTP proxy, the proxy server hands all requests & responses to & from the actual SMTP server it's trying to protect. So when another mail server requests to make a connection through the proxy server, it's the SMTP server behind the proxy that is responding and not the proxy itself. This can lead to some significant issues as will be discussed below. In this type of environment, the mail server itself acts as both the MDA as well as the MTA for all mail.
A SMTP gateway is fundamentally different in that it is an actual mail server accepting and sending mail on behalf of the network mail server. When another mail server requests to send a mail to a user on the LAN, it talks to the gateway, not the server that passes the mail to the user. The gateway server receives the mail, processes it and then initiates a completely new conversation to the LAN mail server to send the message on. In this scenerio, the LAN mail server becomes the MDA while the gateway acts as the MTA in relay mode.
Why a Gateway is Better
While a proxy server can be very effective at filtering & handling spam & virus emails, it has a major downfall; it does not seperate the LAN mail server entirely from the Internet. This problem becomes apparent in two major areas:
Security
By having the LAN mail server continue to handle the SMTP conversation, it exposes the LAN server's capabilities to the world. This can give malicious outsiders information that is probably best kept hidden. While it is entirely possible (and encouraged) to secure the outward side of a normal mail server so that it remains fairly inpenatrable, if it is not necessary, why provide that information?
Compatibility
If you are running a LAN mail server that uses non-compliant SMTP protocols (ie, Microsoft Exchange), those protocols are very likely to be advertised and possibly used by other mail servers who have the same capability. Exchange will get picked on quite a bit in this regard during the course of this article. Despite the fact that this is a bad practice for a variety of security reasons, it also provides an issue of compatibility with the mail filtering services that may not understand these special protocols and thus not be able to handle the mail being sent through them (or worse, handling it incorrectly allowing malicious mail & virii to get through). A gateway server can be configured to be entirely compliant and very stripped down since it's only job is to receive, process and pass on mail, nothing more. This puts a fully compliant face on the network even if the internal server is not compliant - a type of abstraction layer for the network.
| As noted, Microsoft Exchange has a real problem if not properly configured with SMTP compliance. Most notably (at least to me) is the SMTP extension used in Exchange called XEXCH50. This extension is designed to handle communication between Exchange servers only. It provides a mechanism in which the Exchange servers can authenticate to one another and transmit the message in binary format between them. This likely provides an increase in speed and security between Exchange servers and is designed only to be used between servers within the same organization. Where this fails is when an Exchange server is configured to offer that protocol extension to the public as one of it's available SMTP extensions. Other similarily mis-configured Exchange servers can pick up that extension and prefer it's use. This normally does not cause a problem when the Exchange server is exposed publically on both sides, but many complaint mail filters will not know how to handle this type of communication and will fail. This behavior has been noted most prominately with communications to Exchange 2003 servers that have this enabled (it is enabled by default). While there are ways to disable this extension in Exchange 2000/2003, there is no known way to disable it in Exchange 5.5 or older. See the section, See Also below for more information. |
Configuration Scenerios
There are several ways that a spam gateway can be configured and positioned on a network. Ultimately, however, the most important decision is going to be whether to place the gateway inside or outside the LAN's firewall. There are, of course, advantages to both scenerios.
Inside the LAN Firewall
By placing the spam gateway on the inside of the LAN firewall, it is offered instant protection from a great many threats. All traffic sent from the internet can be exclusively filtered and passed to the spam gateway in a relatively clean fashion which reduces the need to lock down the spam gateway itself. This reduces some of the administration needs associated to implementing a gateway.
However, there are drawbacks to this scenerio. Malevolent traffic can still infiltrate the spam gateway through unforseen loopholes in the firewall and from infected machines on the LAN side as well. Another danger is in the spam gateway itself becoming infected and then posing as a point of further infection to the rest of the network. It is definately good practice to lock down the gateway itself from any unnecessary traffic whether it lies within or without the LAN firewall protection.
Outside the LAN Firewall
By placing the gateway outside the LAN firewall, the LAN itself remains more protected from the malevolent traffic that the spam gateway itself filters. Only the "cleaned" traffic from the gateway enters the LAN itself. This is definately a security benefit. Another benefit gained from placing the gateway outside the firewall is a reduction in the amount of unnecessary traffic hitting the firewall in general. This frees up the firewall to more effectively filter other internet traffic.
It is critical that the gateway be thoroughly locked down from accepting unnecessary internet traffic in this scenerio, however, as it will be completely vulnerable outside the protection from the LAN firewall. It is recommended that all unused services be turned off and that a protective firewall be installed on the gateway machine itself to block all traffic but SMTP (and perhaps SSH and/or HTTP for administration and monitoring). Remember to allow DNS access out of the gateway so that domain resolution tests can be performed.
WAY Outside the LAN Firewall
Another useful variation on the "Outside the LAN Firewall" scenerio is to place the gateway completely off-site in a hosted or colocation environment. This removes the unnecessary traffic from the LAN's Internet pipe completely by filtering all spam/virus from a remote location before sending useful mail over the Internet pipe to the LAN site. This solution will, of course, cost extra for the actual hosting required. All the same precautions listed in the "Outside the LAN Firewall" scenerio should be observed for this variation.
See Also
- Building an SMTP Gateway with Debian & Postfix - Sam Hart's lecture notes
- Integrating Postfix & Spamassassin - Quick & dirty outline of how to integrate Spamassasin with Postfix.
- Copfilter Forum Thread - Discussing the problem of the XEXCH50 Exchange SMTP extension with ProxSMTP mail proxy.
- Postfix Documentation - Documentation from Postfix on setting up this type of spam gateway.
