Recent discussions in newsgroups, the press, and other forums show a heightened concern about Microsoft Windows 2000 and Exchange 2000 Server security. Typical Exchange security discussions focus on protecting Exchange servers from outside threats, but I want to offer a twist and look at protecting our Exchange servers from internal threats—in other words, protecting ourselves from ourselves.
The most obvious protective measure we need to take is Exchange server lockdown, which includes protecting the server's physical security as well as configuring parameters and removing unnecessary services. For example, because Exchange 2000 depends so heavily on Microsoft IIS, you need to apply the latest IIS security tools such as URLScan and IISLockD.Are you introducing unnecessary security risks by running services such as FTP, Telnet, or Win2K Server Terminal Services on the Exchange server? A related problem is vulnerable Local Administrator accounts. During installation, many installers set the Local Administrator password to something easy to remember, such as "password." A weak password on a Local Administrator account on a domain member server or workstation opens up numerous vulnerabilities and exploit possibilities. Administrators must make sure these accounts are strong and must apply policies to Exchange servers so that only certain accounts can log on locally. Exchange administrators need to enforce strong local lockdown measures to ensure that the servers aren't easy targets for attackers.
Another security concern is Exchange 2000 rights delegation. Managing Exchange Server 5.5 was easier than managing Exchange 2000 because you didn't need to worry about Active Directory (AD). By default, Exchange 5.5 administrators can't extend their power beyond the site boundary unless specifically granted this power. Managing Exchange 2000 and its AD integration is more challenging. An often-overlooked fact is that the administrative powers of Exchange 2000 administrators (those delegated this right, whether at the Organization level or Administrator group level) aren't limited to their own Administrator group. The Exchange 2000 concept of an Administrator group isn't a security boundary as it was with an Exchange 5.5 site—it's an administrative boundary. You must consider this fact when designing your Exchange 2000 topology and administrative model. You also must carefully consider how freely you delegate Exchange Administrator privileges when deploying Exchange 2000. A misunderstanding of Exchange 2000 administrative roles can be a fatal flaw in your plans to protect your Exchange servers from attack.
The topic of Exchange 2000 topology relates closely to a matter of trust: You absolutely must trust your Exchange 2000 administrators. You also must trust your Win2K domain administrators. Domain administrators have some powerful privileges within an AD forest—privileges that can affect Exchange security. If you don't trust these individuals, you must consider AD and Exchange organizational designs that provide the degree of isolation your business requires.
The bottom line? You must trust your administrators, and you must understand the implications of your Exchange and AD deployment design and delegation decisions. If you want more information about protecting your Exchange deployment, the following list of white papers is a good place to start.
Planning Your Implementation of Microsoft Exchange Server
Active Directory and Exchange Dependencies and Requirements
Exchange 2000 and Active Directory Deployment Considerations
Exchange 2000 Internals: Permissions Guide
Exchange Server 5.5 Security
Tips for Securely Connecting Your Microsoft Exchange 5.5 Site to the Internet