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.
- Open Exchange Administrator, right-click the Internet Mail Service (IMS), and choose Properties.
- 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>.
- 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.
- Select SASL/SSL security. Make sure to select the SSL encryption check box.
- Click OK.
Exchange 2000 uses the Transport Layer Security (TLS) protocol, which is based on and interoperable with SSL. Enabling TLS for Exchange 2000 is similar to enabling SSL for Exchange Server 5.5.
- Open the Microsoft Management Console (MMC) Exchange System Manager snap-in and navigate to the SMTP virtual server for which you want to turn on TLS.
- Right-click the virtual server and choose Properties to open the Properties dialog box.
- Go to the Access tab.
- Click Authentication. Make sure to select the Enable SSL client authentication check box.
- Go to the Delivery tab and click Outbound Security.
- Select the TLS encryption check box.
- Click OK.
Turning on SSL (or TLS) protects outbound messages (i.e., messages leaving the server through SMTP) but doesn't protect traffic traveling from clients—Microsoft Outlook Web Access (OWA), POP3, and IMAP4 in particular—to the server. To fix this problem, you can enable the use of SSL with OWA, and you can suggest that POP3 or IMAP4 users use a client (e.g., Microsoft Outlook Express) that supports the use of SSL with POP3 and IMAP4.
If you want to protect network traffic between clients and servers and you're using Win2K, you can use the IP Security (IPSec) protocol to shield all TCP/IP traffic. Unlike SSL, IPSec is transparent to applications, so you don't need to change any Exchange Server settings to use it. And if the client supports IPSec, you get end-to-end traffic encryption. Of course, you first need to enable IPSec, and your network (including routers and firewalls) must permit it to pass. (For details about using IPSec, see Paula Sharick, "Use IPSec to Protect Your LAN Resources," October 2000.)
For Your Eyes Only
Your messaging system faces a slightly more insidious danger than outright attacks: people who read other people's messages. By and large, this is a personnel problem rather than a technical problem, and it isn't always malicious. (Messages that end up bouncing to the postmaster mailbox are a rich source of amusement for administrators at many sites.) However, you can apply technology to limit the chances of this type of snooping.
You often have legitimate reasons to grant a user access to another user's mailbox. For example, when you use Outlook for calendaring, you open other users' calendars. This action causes the system to generate event ID 1016 in the Application log. Any tool that opens a user's mailbox (e.g., Messaging API—MAPI—virus scanners, brick-level backup tools) will generate the same event. Your company's legal or human resources (HR) department might also have reason to monitor specific mailboxes.
In Exchange Server 5.5, the site service account permits unfettered access to all mailboxes on a server. Whoever has access to the site service account name and password can log on and read the contents of any mailbox—without leaving any sign that he or she did so. You probably don't want to permit this broad behavior on your network. Because the site service account is so powerful, choose a strong password and limit access to the account. I also recommend that you monitor the Security log to ensure that the account is being used properly.
Although you could use the account to provide access to a specific mailbox's contents, doing so increases the likelihood that the account will be compromised. A better solution is to grant someone else permissions to the mailbox in question (bearing in mind that this action might cause the alternate recipient to generate return receipts, potentially telling the world that someone other than the recipient is reading the mail). Or you can use message journaling to copy all mail traffic for that mailbox to another mailbox or public folder, from which a designated user can then inspect the messages. (I'll discuss journaling in the next column.)
Exchange 2000 tightens the site service account loophole considerably; the site service account no longer exists, and the Administrator account and the Domain Admins and Enterprise Admins groups are explicitly denied access to individual mailboxes. (See the Microsoft article "XADM: How to Get Service Account Access to All Mailboxes in Exchange 2000" at http://support.microsoft.com/support/kb/articles/q262/0/54.asp for instructions about how to give snooping power to a designated account.) You can also use message journaling in Exchange 2000.
Run, Don't Walk
Next time, I'll discuss related security topics, including the best way to protect your Exchange Server machines and clients against viruses. In the meantime, I suggest that you immediately go to Microsoft's security site (http://www .microsoft.com/technet/security), read the NT security checklists, and evaluate how your current preparations stack up. Also, consider reading a good security book, such as Stefan Norberg's Securing Windows NT/2000 Servers for the Internet (O'Reilly, 2000) or Michael Howard's Designing Secure Web-Based Applications for Microsoft Windows 2000 (Microsoft Press, 2000). For a great general introduction to network security, check out Bruce Schneier's Secrets and Lies: Digital Security in a Networked World (John Wiley & Sons, 2000). The time you spend researching security now might save you from major problems later.
