Securing Exchange Server

Scott Collins's famous security axiom states, "You should be exactly as paranoid as it is cost-effective to be." In other words, you need to expend an appropriate amount of effort to protect valuable network and data assets, just as you protect material assets such as your house. And your security efforts need to consider the whole picture—if you make your house of balsa wood, an expensive lock on the front door won't help.

In terms of the data they hold, your Exchange Server systems are probably among your company's most precious possessions. To effectively protect these servers, begin by understanding potential threats: who might decide to attack your mail system, where an attack might originate, what form it might take, and how it might penetrate your defenses. Then, familiarize yourself with the security tools at your disposal and decide which tools can best defend your systems.

Take the Lead
The following strategies require that you take active responsibility for measuring your network's security posture and fixing its shortcomings, both of which can have a big effect on Exchange Server security. (For example, several Denial of Service—DoS—attacks against Windows NT depend on open remote procedure call—RPC—ports. If your Exchange Server system is accessible from the Internet, you need to know whether the RPC ports are open on the firewall and your Exchange Server box. You need to have a firewall between your Exchange Server machine and the outside world, and you need to properly configure the firewall to pass only the ports you need.) If you aren't directly involved with security, go to your company's security folks and explain that because email is a crucial service, you want to secure your systems as much as possible.

Know the Enemy
One of the phrases insurance agents most frequently hear is, "That won't happen to me." The number-one myth of computer security is disturbingly similar: Most people assume that attackers are external entities that focus their efforts only on high-profile targets such as Microsoft or NASA.

In fact, the biggest source of attempts to penetrate corporate networks is corporate employees. Another common source of attacks is script kiddies or anklebiters—relatively unskilled but malicious attackers who pick sites at random, scan blocks of IP address ranges, then probe specific machines to see what vulnerabilities they can find. As opposed to efforts to steal data, most of these assaults are DoS attacks that range from flooding your Internet connection with bogus packets to actively attempting to destroy data on your servers. (The commonly reported attacks that involve defacement of an organization's Web pages are a DoS subspecies, most often the results of flaws in file-sharing security.) Exchange Server systems are most vulnerable to DoS attacks that target the underlying OS; however, a savvy attacker who can capture authentication credentials can use them to read messages for the mailboxes belonging to those credentials.

Of course, if your organization has a high profile, your risk of becoming a target does multiply. Malicious entities are more likely to single out your company for the publicity value of cracking your network or for access to your network's valuable data. Take a few minutes to think about whether your organization has information that someone might want to steal or compromise or whether a malicious attacker might be particularly interested in your servers. This line of thought will give you an idea of the types of threats—internal, random, or targeted—you might face.

Think Like a Thief
Preventing an attack is better than reacting to one. In 1994, Dan Farmer (a computer-security legend) wrote a highly controversial and influential paper titled "Improving the Security of Your Site by Breaking Into it." Farmer's theory stated that to secure your network, you should use the same software and methods as an attacker—along the lines of acting like a safecracker to measure the strength of a bank safe. Predictably, this approach wasn't too popular in corporate America, but since then the security community has accepted Farmer's essential idea as a valid way to test system security—provided you have permission. Randal Schwartz, a noted Perl expert and UNIX administrator, lost his job and was arrested for performing this type of security analysis on a customer without permission. (See http://www.lightlink.com/spacenka/fors for details about this cautionary tale.)

The best way to find vulnerabilities in your network is to use the tools and thought processes that an attacker would use and fix security weaknesses as you go. Look for vulnerabilities on a test system first. If you configure the test servers identically to your production machines, such a test is a great way to find problems without involving your production resources. The bad guys will find whatever openings you don't find, so you need to thoroughly search for and fix holes.

To help you in your task, you can use network monitoring and scanning tools such as Internet Security Systems' RealSecure product lines. Go to http://www .WindowsITsecurity.com for a good place to start learning about these tools. I also recommend that you subscribe to the Microsoft security notification service at http://www.microsoft.com/technet/security/notify.asp.

Stop Trouble Before It Starts
After you've analyzed potential threats and holes in your network, you should assess whether you're adequately using the security tools you already have. Of course, if an attack comes from within your network, fancy tools to protect your external perimeter will go only so far. You should always put your Exchange Server machine in a restricted-access location and lock the server's console when you're away from it. And you might consider the built-in security features of Exchange Server and your OS. Windows 2000, NT, Exchange 2000 Server, and Exchange Server 5.5 all have some level of security protection that you can put into place, often with minimal overhead.

By default, anyone on your network can read SMTP traffic that crosses the network because SMTP sends messages and authentication in clear text. Both Exchange 2000 and Exchange Server 5.5 let you use Secure Sockets Layer (SSL) technology to encrypt SMTP traffic as it passes between mail servers, although a few limitations exist. (You can use SSL only when both servers support SSL, and it doesn't provide authentication between servers.) Using SSL on your internal network might seem like overkill, but many companies combine SSL with internal firewalls to limit the risk of information leaks. Enabling SSL in Exchange Server 5.5 is easy.

1. Open Exchange Administrator, right-click the Internet Mail Service (IMS), and choose Properties.
2. Go to the Security tab. This tab lists each Fully Qualified Domain Name (FQDN) for which you've defined a security policy; your list most likely will contain a single entry named <Default>.
3. Select the domain for which you want to modify the security policy, then click Edit. The Edit E-Mail Domain security information dialog box appears.
4. Select SASL/SSL security. Make sure to select the SSL encryption check box.
5. Click OK.