The Goals of Protection
It's probably stating the obvious that the whole point of firewalls and proxy servers is to protect resources like Exchange from attack. But what exactly does that mean? Obviously, you're going to allow some traffic in: Port 25 for SMTP is a good bet, and if you're using OWA than either 80 or 443, for HTTP or HTTPS, is another easy guess. So why bother with the firewall?

Because Windows and Exchange open up a zillion ports on top of those three: RPC, LDAP, IMAP4, POP3, RDP, the list goes on and on. Rather than spending the rest of your life figuring out which ports can be locked down and which services can be disabled, it's a lot easier to just throw a firewall in front of everything and lock down the ports that are allowed in from the Internet. Figure A, below, shows a pretty common-sense Exchange deployment, with the back-end (or mailbox) server on the internal network, and with an OWA server in the perimeter network (sometimes called a demilitarized zone, or DMZ). The outer firewall is set to allow incoming OWA (HTTP or HTTPS) traffic to the OWA server, and to allow SMTP traffic to the back-end server. The internal firewall is set to allow SMTP traffic.

The problem arises when you try to get the OWA server actually functioning out there in the perimeter network. Unfortunately, OWA servers have to run Exchange, and they have to be domain members. Getting domain logon traffic through a firewall can be a study in frustration: Kerberos, Kerberos password, LDAP, secure LDAP, global catalog (GC), GC queries, RPC endpoint mappers, and the zillion or so ports that RPCs like to use dynamically. In fact, while it's possible to configure a firewall to allow the right traffic, it's a real pain. That's why a more common, more realistic, and in fact Microsoft-recommended scenario is to place all of the Exchange servers-including OWA front-end servers-on the internal network. Figure B shows the change:

Now, both firewalls wind up with a similar configuration, allowing SMTP and OWA traffic to reach the appropriate servers. Both Exchange servers can readily contact the domain and each other, and all's well.

But What About Protection?
Unfortunately, protecting Exchange requires a bit more than just port filtering. If that were the case, you could just configure port filters in the TCP/IP settings, or in Routing and Remote Access, and slap the Exchange servers directly on the Internet. If you're just using your firewalls to filter ports, what's the difference?

That's why my favorite configuration is the one shown below in Figure C.

Note that variations on this theme are just fine: I've placed a Microsoft Internet Security and Acceleration (ISA) server on the perimeter network; you could also use it in place of one of the firewalls, if that's what you prefer. You can also use another proxy server product, if ISA isn't your favorite flavor. What's important to realize is that the ISA server isn't acting as a firewall, it's acting as a proxy server. Or, to be more accurate, as a reverse proxy server.

Normally, a proxy server accepts Web requests from internal clients, and then runs out to the Web to fetch the requested content. The content is then delivered to the requestor and cached on the proxy. The next request for the same content can be served from the cache. One of the key features of this proxying is that the proxy server never passes requests directly from the internal network to the Internet, or vice-versa. The proxy receives a request form an internal client, and then generates an entirely new request that goes out to the Internet.

Now, turn that process around: Web requests are received from the Internet. They're sent to ISA (or whatever proxy you use, so long as it supports reverse proxying) as if ISA were the OWA server. ISA then generates an entirely new request and forward it off to the OWA server. If you trust Microsoft (or whoever made your proxy) even a little bit, you can assume that they're not going to generate malformed, IIS-crashing HTTP packets from scratch. In other words, ISA is accepting untrusted requests from the Internet and then creating trustworthy versions of those requests. If a request is received that's likely to crash IIS, it may crash the ISA server, but not your Exchange server. You've sort of turned the proxy server into a fuse, a potential point of failure that you accept because it helps keep failure away from more mission-critical components.

ISA in particular can also help "fuse" SMTP traffic. ISA includes an SMTP filter: ISA can then sit and accept incoming SMTP traffic as if it were your mail server, and then pass validated, safe SMTP packets to Exchange. Some other firewalls and proxies offer similar features; it's more than just opening port 25 in the firewall, it's actual inspection and validation of the incoming packets. Some firewalls (including ISA) can also be configured to virus-scan the incoming traffic to stop many kinds of e-mail viruses.

Proxies can play another fuse-like role in preventing the impact of difficult-to-defend-against attacks like Denial of Service (DoS) and Distributed Denial of Service (DDoS) attacks. Remember, in DoS/DDoS attacks, one or more remote computers attempt to flood a particular server (or servers) with traffic. The idea is to send so much traffic that the servers back up and become unable to provide services to legitimate users. However, if the external attackers believe that ISA server (or your firewall, other proxy, or whatever) really is your e-mail server, they'll attack it. Firewall software is often equipped to detect and deal with DoS/DDoS attacks more effectively than an e-mail product like Exchange, reducing the likelihood that the target of the attack will actually crash. More importantly, ISA takes the brunt of the attack, ensuring that the Exchange server can continue to serve internal clients, send outgoing SMTP traffic, and perform other services for legitimate users.

Get Serious About Protection
Multiple layers of protection -- firewalls, proxies, and so forth -- offer the best defense against today's sophisticated attacks. Multiple layers are desirable everywhere. For example, don't install antivirus software on your firewall, your proxy or your Exchange servers; install antivirus software in all of these places: One may catch something the others miss. Many companies creating setups like the one in Figure C will use a different brand of software for the proxy server and for each of the firewalls, with the theory that an attacker who knows how to compromise one brand might not be so smart about the next layer.

As a mission-critical service, e-mail servers like Exchange are favorite targets of attackers. Spending some time to understand how attackers try to hit Exchange, and to understand how those attacks can be mitigated, can allow you to create a more stable environment that can survive even determined outside attacks.

Questions? Comments? Tips of your own to share? Post 'em below!