SMTP Security

By default, an SMTP server attempts to make a TCP port 25 connection to your Exchange server via an anonymous connection. Anonymous does not mean that a user account set up in your Active Directory proxies the connection request, as is the case with the IIS Anonymous user account, IUSR_<machinename>. In the SMTP world, anonymous means that no user name or password is required for the remote SMTP service to make a port 25 connection. Hence, any SMTP Server on the Internet can make, by default, a port 25 connection to your Exchange Server.

To make SMTP more secure, you could require either Basic or Integrated Windows Authentication (IWA) before the SMTP Virtual Server (VS) could accept an inbound connection. But this configuration is unworkable on the Internet because you can’t predict who will be connecting to your Exchange server in the future and thus can’t assume that the user has an appropriate user name and password to make a connection. Moreover, not many messaging administrators are interested in implementing such a security measure at their end. So even though an anonymous connection to port 25 on your Exchange server represents a vulnerability, it is one that must be managed using a different approach than removing anonymous connections.

How do we protect against these kinds of attacks? By starting with the use of two firewalls. A dual firewall topology allows you to protect your internal Exchange servers while also filtering incoming e-mail against potential attacks. The area between the two firewalls is called the perimeter network (also known as DMZ or demilitarized zone). The philosophy is to put up a line of defense against potential attacks. Hence, we’re willing to sacrifice our Exchange servers in the perimeter network, but not willing to sacrifice our Exchange servers on the internal network. Because the Exchange servers in the perimeter network do not host any important information—no mailboxes or public folders—they can be both sacrificed during an attack and easily rebuilt. And because they act only as relay servers, we can use them to sanitize incoming e-mail over port 25.

Take a look at Figure 24-8. You see that in the perimeter network are three servers. The external firewall has port 25 open. Mail is first routed to the Content Scanning (CS) server before moving on the Anti-Virus scanning server (AV). You should take note of two points. First, all your external MX records will point to the CS server. Hence, any inbound SMTP traffic will necessarily be routed to your CS server. Second, we conduct content scanning first because of the rate at which new viruses can spread vs. the rate at which our AV definitions are updated. Think back to some of the major viruses in the last few years, which were able to spread worldwide very quickly, usually in a matter of hours. It is almost impossible for any AV company to get the virus, study it, write a definition for it, and then push out the new definition for that virus before it spreads worldwide. You can tell a CS server, however, to quarantine or delete any message that contains certain types of attachments and, in effect, block most viruses based on their type of content rather than on a comparison to a virus definition file.

Figure 24-8: Three Exchange servers in the perimeter network.

Even though the CS server will block a number of e-mails, it is still best to run the e-mail through an AV scanning server. Once scanned, the e-mail is sent to the Certificates and Encryption (CE) server.

Note

You should be aware of two issues regarding the AV server. First, many products offered by the major AV servers perform content scanning at the same time as the virus scanning, on the same VS, using the same software. We have no problem with this method of scanning e-mail. But we wanted to distinguish between content scanning and antivirus scanning to highlight the need to perform both types of scanning in the perimeter network. Second, we understand that not everyone can afford to purchase three individual servers and Exchange licenses for their perimeter network. Again, these ideas are presented to highlight the concepts we’re discussing. All three of these functions (content scanning, AV scanning, and message encryption) can be performed using three different virtual servers on a single Exchange box or even using another SMTP platform that is less expensive on less expensive hardware.

The third server through which e-mail is transferred is an Exchange relay server. This server re-sends the encrypted and signed e-mail to the internal Exchange 2003 Server. The internal Exchange 2003 Server should be configured to accept inbound e-mail only from the third Exchange 2003 Server in the perimeter network. Because port 25 is not open on the internal firewall, the two Exchange servers communicate using a different port number. The internal Exchange server should also be running its own AV/CS software, preferably from a vendor that is different from the one the servers are using in the perimeter network. The whole point of implementing this model is to ensure that port 25 traffic is as well protected as possible.

Between the third Exchange 2003 server in the perimeter network and the internal Exchange server, you need to set up certificates and encryption as well as modify the ways that the virtual servers communicate. On the Exchange perimeter network server, you modify the SMTP VS as follows:

• On the Outbound Security tab, select Integrated Windows Authentication, enter a user account created in Active Directory specifically for this purpose, and select TLS Encryption (Figure 24-9). (TLS stands for Transport Layer Security.)

  
  Figure 24-9: Configuring outbound security for the VS on the CE Exchange Server in the perimeter network.

• On the Outbound Connections tab, configure an outbound TCP port number that is difficult to guess (Figure 24-10). You need to open this port on your internal firewall for inbound traffic.

  
  Figure 24-10: Configuring a unique port number for outbound SMTP traffic on the CE Exchange Server in the perimeter network.

• On the Advanced Delivery tab, configure the Internet Protocol (IP) address for the internal Exchange Server so that it is the smart host for this VS. When you do this, all e-mail will be forwarded to the internal server (Figure 24-11).

  
  Figure 24-11: Configuring the internal Exchange server to be the smart host for the CE Exchange Server in the perimeter network.

On the VS of the internal Exchange Server, you need to create a second VS for inbound traffic and modify the inbound VS as follows:

• On the Authentication page, configure both Basic and IWA, and require TLS. On the Users tab, specify that only the user account configured on the outbound VS of the CE Exchange server in the perimeter network is able to submit e-mail to this inbound VS (Figure 24-12).

  
  Figure 24-12: Configuring inbound authentication on the inbound VS of the internal Exchange server.

• On the Connection page, specify the IP address of the CE Exchange server in the perimeter network as the only server that is allowed to access the inbound VS (Figure 24-13).

  
  Figure 24-13: Configuring inbound IP address acceptance on the inbound VS of the internal Exchange server.

• Use an internal certification authority (CA) to create certificates for both Exchange servers to use for the TLS portion of the message transmission.

No system is foolproof, but this dual firewall topology has several advantages. First, by passing incoming e-mail through a good content scanning tool, you filter for code types that virus scanners don’t.

Second, by passing your e-mail through a virus scanner, you’re doing your best to ensure that all known viruses are cleaned out. Not passing your e-mail through an updated antivirus scanner after running it through a content scanner is unwise because older viruses might not be caught by the content scanner.

Third, by passing your e-mail through another Exchange 2003 server that will encrypt it and digitally sign it before sending it to the internal Exchange 2000 Server, you receive several types of protection. The IP address of the internal Exchange 2003 server does not need to be published in the public DNS records. This means that an attacker attempting to Telnet into your server will never be able to reach it directly. Also, if you configure the internal Exchange 2003 server to accept e-mail only from the encrypting Exchange server over a port number above 1024, any attempts to make port 25 connections to the internal Exchange server from any other IP address will fail. Finally, to impersonate the third Exchange server in your perimeter network, the attacker must spoof the IP address, grab the certificate, and crack the password of the user account configured between the two servers.

You could spoof the IP address easily enough, except that the internal Ex- change 2000 Server is also looking for a digital certificate (whose trusted certification authority is an internal Windows 2000 Certificate Server) before it will accept the connection. Consequently, you not only need to spoof the IP address—you also need a valid certificate from the internal certificate server to make such a connection. Obtaining such a certificate is difficult when the personnel are well trained in network security. Social engineering is the route to take here if you want to get a certificate from the internal certification authority. But even if the hacker could obtain a certificate and spoof the IP address, the hacker would need to find out the user name of the shared account and then crack the password. Although not impossible, these hurtles might create enough headaches to deter the hacker.

If a hacker decides to bring down your perimeter Exchange servers, you’ve really lost nothing of value other than your time in getting the servers functioning again. Your company might lose some money due to the inability to communicate via e-mail, but it hasn’t lost any current data. This is an important point. The server that hosts your data is the one most protected. And the ones most exposed do not host important data. If those servers are lost, at least all the business-critical data is saved on the internal Exchange 2000 Server. For many companies, this is an acceptable level of risk to assume.

As we’ve explained throughout this chapter, no answer is perfect, and this security scenario does have a few major holes, such as doing nothing to protect against messages sent to the Exchange server via Outlook Web Access. Port 25 is well protected but port 80 access to your Exchange server is wide open. If you want to learn how to secure OWA, refer to Chapter 19, “Supporting Outlook Web Access.”

The second major hole in this model is one that cannot be plugged: messages are continuing to flow through all three servers to your internal Exchange server. As long as I can get a packet to your internal Exchange server, I can potentially do harm to it. So remember that 80 percent rule we discussed in the introduction to the chapter: you can make your data only about 80 percent secure. But don’t let that discourage you from implementing our strategies.