Edge Transport Server Security - Firewall Configuration
According to all of Microsoft‘s marketing hype, one of the goals of the secure computing initiative is to make server secure by default. I would have to agree that the newer Microsoft products tend to be more secure while running a default set up than the product from even a few years ago were. Even so, I have to disagree with the notion of servers being secure by default. There is always something that can be done to make a deployment more secure. Of course this is more of an issue with some types of servers than others.
One type of server that you should really focus a lot of attention on securing is an edge transport server. The reason why I say this is that an edge transport server is designed to sit in a DMZ, and filter out potentially malicious messages coming in from the Internet. Because of the server‘s position within the DMZ, it is more vulnerable to attack than a server on the backend network would be.
Fortunately, Microsoft realizes that edge transport servers reside in a dangerous area, and has designed them accordingly. Unlike other types of Exchange servers, which transport servers do not rely on the Active Directory, and are not even domain members. In fact, when you deploy the Edge Transport Server role, you are actually deploying a hardened version of Exchange that is well-suited to the task at hand.
So What‘s the Problem?
If Exchange Server is deployed in a secure manner on edge transport servers, then you may be wondering where the problem lies. In my opinion, the biggest inherent security weakness with edge transport servers is that Exchange Server must reside on top of the Windows operating system. This means that if Windows has not been configured securely, then theoretically Exchange may not be security either. The ways in which the firewalls protecting the edge transport server are configured is also a major issue.
Some Security Techniques
When it comes to securing an edge transport server, it is important to remember that the server‘s job is to accept e-mail from the Internet, filter out any undesirable messages, and forward the remaining messages to the backend Exchange servers. Because the edge transport server is essentially acting as a proxy, it is configured to use two separate NICs. One of these NICs is connected to the Internet, and the other is connected to the backend network. Both of these NICs should be protected by a firewall. You can see an example of this type of configuration, shown in Figure A.
Figure A Both of the edge transport server’s NICs should be protected by a firewall.
Generally speaking, the firewall facing the Internet should be configured so that the only type of traffic that is allowed to reach the edge transport server is SMTP traffic over port 25. This port must be open for both inbound and outbound traffic.
Although the edge transport server only uses the SMTP protocol to communicate with the outside world, there are some additional protocols that are needed for communication with the backend Exchange organization. Therefore, the firewall that separates the edge transport server from the backend Exchange Server organization should be configured to allow:
- SMTP traffic over port 25
- LDAP traffic over TCP port 50389
- LDAP traffic over UDP port 50636
- RDP traffic over TCP port 3389
Although it is necessary to use these ports, they can be configured in a way that makes their usage more secure. Obviously, port 25 is going to have to be open for both inbound and outbound traffic. Otherwise, mail flow just won‘t work. You have a little bit more flexibility with the other three ports though.
Port 50389 is actually to facilitate the server‘s ability to use LDAP to communicate with ADAM. As such, this port only needs to be enabled on the local server, and does not necessarily have to be open on the firewall.
Port number 50636 must be opened because it is used for secure LDAP communication between the backend Exchange network and the edge transport server. Even so, the edge synchronization process is a one-way process, so you only have to configure this port to accept inbound traffic.
Enabling Port number 3389 is optional. Microsoft recommends opening it because doing so allows you to remotely manage your edge transport server. If you do choose to open this port then it only needs to accept inbound traffic.
In this article, I have talked about the ways in which firewalls must be configured in order to facilitate a secure edge transport server deployment. In Part Two of this series, I will talk about some things that you can do to harden the Windows operating system.