E-mail is almost as important as electricity for some organizations, but practically no area of the typical network is as vulnerable as an e-mail server. By their very nature, e-mail servers allow data to enter the network, and thus they are usually the chief portals by which viruses and other malicious attachments infiltrate your network. Likewise, e-mail servers also tend to be targets for denial of service (DoS) and other types of attacks. Because of their complexity, e-mail servers tend to be difficult to secure. In this Daily Drill Down, I’ll provide you with some pointers for locking down your Exchange 2000 Server.

Lock down the core operating system
As you’re no doubt aware, Exchange 2000 rides on top of Windows. Because of this, the only way to secure Exchange is to secure Windows. Begin securing Windows by disabling all unnecessary services on your Exchange servers. Remember that the more processes that are running, the greater the chance that one of the processes contains a bug that can be exploited. Disabling unnecessary services will not only increase security but also boost performance.

Many Windows 2000 services are disabled by default, but others are set to be started either automatically or manually. I recommend disabling the services shown in Listing A. Of course, this list may vary slightly depending on your own needs.

Once you’ve disabled all unnecessary services, I recommend checking to make sure that your Exchange Server is not a domain controller. Remember that your Exchange Servers are often accessible via the Internet, and the last thing that you want to do is to make a domain controller Internet-accessible.

Run the Microsoft Baseline Security Analyzer
Now that you’ve covered some of the basics, the next step in the process is to install and run the Microsoft Baseline Security Analyzer (MBSA). Although the MBSA isn’t really meant to be used in conjunction with Exchange, I still recommend using it to lock down Windows. The basic idea behind the MBSA is that it scans your servers for common security problems. The MBSA is designed to look for problems with Windows NT 4.0 SP4 and above, Windows 2000, Windows XP, IIS 4.0 and above, Internet Explorer 5.01 and above, SQL 7.0, SQL 2000, Office 2000, and Office XP.

The MBSA looks for a wide variety of security problems. The utility checks everything from password lengths to missing hot fixes. Although the MBSA is designed for servers, I recommend also running it against your workstations as well. Workstations are a bigger source of security breaches than most people realize, especially in an Exchange environment. You’ll be amazed at what the MBSA finds.

Run the IIS Lockdown Tool
When you finish running the MBSA, I recommend running the IIS Lockdown tool. The IIS Lockdown tool is a utility designed to help you to secure IIS. Keep in mind, though, that whether or not you use OWA, Exchange Server is dependent upon at least some of the IIS components. Therefore, it makes sense to go ahead and make sure that IIS is secure.

Microsoft Baseline Security Analyzer and IIS Lockdown Tool

If you’re interested in knowing more about the MBSA and the IIS Lockdown Tool, see the Daily Drill Down “Make sure your network is secure with the Microsoft Baseline Security Analyzer” and the Daily Feature “Lock down security on your IIS server.”

Install patches and fixes
Once you’ve finished running the MBSA and IIS Lockdown utilities, it’s time to make sure that all of your service packs and hot fixes are up to date. If you’ve been following all of the steps that I’ve outlined so far, then there’s a chance that your patches and hot fixes might already be in pretty good shape. As you’ll recall, the MBSA tool reports on which hot fixes and patches are installed onto your server and which ones are missing. However, keep in mind that the MBSA wasn’t designed for Exchange and therefore has no knowledge of which Exchange-related patches you should apply to your server.

A more comprehensive tool for spotting which patches need to be applied is HFNetChk. HFNetChk is a command line tool that enables an administrator to check to see what patches have been applied to every machine on the network, and all from a central location. Unfortunately, HFNETCHK wasn’t initially designed to work with Exchange either. However, a source from within Microsoft tells me that HFNetChk will soon support Exchange.

What makes HFNetChk such a great tool is that it’s Web-based. HFNetChk downloads patch information in XML format directly from Microsoft. Therefore, you can be sure that the tool always has the most current version of information. If you’d like a copy of the HFNetChk utility, you can download it from Microsoft’s TechNet Web site.

Service Packs

Make sure you’ve downloaded and installed the latest Service Pack for Exchange as well as the latest Service Pack for Windows. As of the time of this Daily Drill Down, the most current Service Pack for Exchange 2000 is Service Pack 3. You can find out more about Exchange 2000 Service Pack 3 in the Daily Drill Down “Patch Exchange 2000 Server with Service Pack 3.”

Know who has administrative access
It may sound a little goofy for me to tell you that you should know who has administrative access to your Exchange Server. After all, you should already know who your Exchange Administrators are. However, because of the way that Exchange was designed, it’s not always blatantly obvious who has administrative permissions to which servers.

There are a couple of good examples of this. For starters, one might assume that those with administrative privileges at the domain level automatically have administrative permissions to Exchange Server. However, this isn’t necessarily the case. To have administrative permissions to Exchange, a user must be a member of the Exchange Admins group.

There are some quirks to the Exchange Admins group as well. Any administrator who’s a member of the Exchange Admins group has administrative access to all of the Exchange servers in the entire domain. In organizations with multiple Exchange sites, it’s likely that someone different manages each site. However, if each site administrator is a member of the Exchange Admins group, then each Administrator can manage all of the Exchange servers within the domain, regardless of which site the server is in. In a large organization, this is almost never a desirable situation.

Because there’s little you can do about it, at a minimum you should be aware of the users who have Exchange Admin group privileges. To find out which users have Exchange Admin group privileges, check the Exchange Admin group membership in Active Directory Users And Computers.

Use dedicated organizational units
One way to eliminate the problem of Exchange administrators in disparate locations with universal power is to divide your Exchange organization into multiple organizational units (OUs), which lets you apply a different security policy to each OU. As a result, the security policy that you apply to an OU then trickles down to the servers within that OU.

As you create organizational units, you should not only consider administrative tasks, but also server roles. For example, if the Finance department managed their own Exchange Servers, you’d obviously create an OU for the Finance department. You could then take things a step further and create an OU for OWA servers if OWA were being used.

If your main Finance Exchange Server is being used as a back-end server to an OWA front end, you might consider placing that server or servers in a dedicated OU as well. There’s really no right or wrong way to create your Exchange server-related OUs, as long as the OU structure that you create reflects the various administrative roles and server roles within your organization.

Antivirus strategies
Another huge threat to Exchange Server is viruses. In fact, my personal Exchange organization consists solely of mailboxes for my wife and myself and a few test accounts with unpublished addresses. The point is that I am not involved in some large organization that’s constantly being bombarded by viruses. Even so, this morning when I checked my e-mail, I counted fourteen inbound messages that were infected with viruses. Sure, I get a lot of e-mail from many different people, but I’m just one person. If I get fourteen infected e-mails in one morning, imagine how many infected e-mails trickle into a large corporation every day.

The big question is how you prevent these viruses from infecting your organization. Because of the distributed nature of Exchange Server, not just any antivirus software will get the job done. Instead, you must protect the servers at both the operating system level and at the Exchange store level. Likewise, you must also protect your clients’ machines.

Client antivirus protection
Let’s talk about the clients first. I recommend running Symantec’s Norton Antivirus on client computers. There are a couple of reasons why I recommend this software. First, like any other antivirus software, Norton Antivirus protects all of your machines’ various files. Second, the virus definitions are constantly updated. Most importantly, the latest version of Norton Antivirus integrates itself with Outlook. Previous versions of Norton Antivirus offered Outlook protection, but this is the first version that I’ve seen that has really worked well with Outlook.

Any time that you send or receive a message, that message is automatically scanned for viruses. If a virus is detected in an inbound message, you are given the chance to either repair or quarantine the virus before the message ever appears in your inbox.

Server antivirus protection
Once all of the clients have been protected, you must protect the server. As I noted earlier, you must implement a two-tier approach in order to protect Exchange Server. Although Norton Antivirus does an excellent job protecting servers from viruses, I recommend using another vendor’s product on the server.

The reason why you shouldn’t use Norton Antivirus on the servers is that you’ve already used it on the desktops. For truly effective antivirus protection, you need to use two different antivirus products. For example, if you use Norton Antivirus on the desktops, you might use McAfee or Panda at the server level (be sure to use the Windows version and the Exchange version or else the Exchange stores won’t be protected.).

If you don’t see the logic behind using multiple antivirus products, consider this: Symantec, McAfee, and Panda are all excellent products and all feature automatically-updated virus definitions. Now, suppose for a moment that a new virus were to come out today. If Symantec doesn’t come out with a virus definition update until noon, and the Norton Antivirus is your antivirus solution across the board, then you’ll be completely unprotected against the new virus until noon. In the meantime, Panda might have a virus definition update by 9:00 AM.

The problem is that virus protection isn’t an exact science. One day, Panda might be the first to come out with a virus definition update. The next time, Symantec might be first. You just never know. That’s why you should use two different antivirus programs. To see how this is effective, let’s return to my earlier example in which you’re running Norton Antivirus at the desktop and Panda on the server. It’s 10:00 AM and Panda came out with a definition for a new virus an hour ago, but Symantec won’t have a definition for a few more hours.

If someone were to e-mail a copy of the virus to one of your Exchange users, the copy of Panda that’s running on the server should intercept the virus before it’s ever placed in the user’s mailbox. If on the other hand, Symantec had been first with the virus definition update, then the virus would slip right through the server-level virus protection, but Norton Antivirus would catch it when the mail is downloaded into Outlook.

Recheck your security often
If you remember nothing else from this Daily Drill Down, remember this: The key to good security is to evaluate your security system often. Security is not a “set it and forget it” feature. New patches and hot fixes are constantly coming out, so it’s important to run the MBSA and the HFNetChk tools often. Likewise, it’s just as important to continuously monitor your system’s security logs and to perform frequent security audits so that you can spot anything that might have changed in your security policy. Even if nothing in your security policy ever changes, remember that what’s considered secure today may not be considered secure tomorrow, or even later on this afternoon. That’s why it’s so important to reevaluate your system’s security often.