Keeping Exchange 2000 secure

Security is one of your major concerns. But where do you begin to secure a complex application like Exchange 2000? Brien Posey gives you some ideas on where to start.

When you think of Exchange 2000 security, it’s easy to feel overwhelmed. After all, Exchange 2000 is a complicated product, to say the least. While Exchange 2000 contains many of its own security settings, it’s important to realize that Exchange resides on top of Windows 2000 and borrows heavily from the various Windows 2000 security mechanisms. Therefore, the easiest way to make sure that Exchange is secure is to make sure that Windows 2000 is secure. In this article, I’ll explain some of the various steps that you can take to help to make Exchange 2000 Server more secure.

What is security?
Before you get started, it’s a good idea to define your goals. Simply put, making Exchange Server secure means that Exchange 2000 and the underlying Windows components are configured in such a way that only the intended person (or group of people) can access a particular resource. While this statement may sound simple at first, it carries a lot of weight.

That’s because there are a lot of different ways an unauthorized individual could gain access to your resources. He or she could exploit a misassigned security permission or any of the known Windows 2000 or Exchange security holes. Such an individual could also intercept messages as they flow across the wire. It’s because there are so many different ways that someone could gain such access that you really have your work cut out for you when it comes to implementing Exchange 2000 security.

One of the first steps that you should take toward better Exchange 2000 security is to implement a good audit policy. As you may know, auditing is the process of monitoring system events and making a log entry when certain types of events occur. You can perform a success audit or a failure audit, or both, on any given system event.

Auditing is important because it can sometimes help you to spot a potential security breach before it happens. For example, suppose you set up a failure audit on the login. You’d receive an entry in the audit log every time someone entered a password incorrectly. Normally, this is no big deal, but if by reading the logs you found that late at night, invalid logins were being produced in large numbers, you might have a problem on your hands. Someone is probably trying to break into your network by guessing passwords.

There are all sorts of things that you can audit beyond just logins. For example, I recommend auditing policy changes. That’s because if the person attempting to gain illegal access is successful, you’ll need to know if he or she is trying to change the system’s administrative policies.

So what does all of this have to do with Exchange 2000? Quite a bit, actually. Since Exchange resides on top of Windows 2000, it depends on Windows 2000 to authenticate users. If a user account’s security is compromised by a hacker guessing a password, an administrative policy change that boosts a user’s priorities, or through any other method, then the user’s Exchange resources can be affected. Therefore, the first step to establishing good Exchange 2000 security is to use auditing to see what’s going on in your system.

Exchange and encryption
Another method that you can use to protect Exchange Server is through encryption. While encrypting the actual databases or transaction logs could potentially cause problems, you can encrypt the actual messages and other Exchange-related traffic as it flows across the wire.

It’s important to point out, though, that there are several different types of encryption that you can implement. To keep the discussion simple, for now, I’ll just assume that you are strictly using Exchange Server for e-mail and are not using any of its other capabilities. From an e-mail standpoint, you’ll have traffic between Exchange users within the organization and between local Exchange users and Internet users.

The key to encrypting messages is that the recipient must be able to decrypt the message when they get it. This is typically done by sharing a key. The idea is that only the sender and the recipient have the key to decrypt the encrypted message. Of course, the actual process depends heavily on which encryption protocol is used.

So how do you go about encrypting your e-mail traffic? First, let’s discuss communications between Exchange 2000 users within a common organization. It may seem odd at first, but I do recommend encrypting this type of e-mail communication because there tends to be a lot of sensitive information e-mail sent within a company. Unless these sensitive messages are encrypted, it would be possible for a disgruntled or mischievous employee to intercept a copy of each message, thus destroying any hope for e-mail privacy.

For securing local communications, I recommend implementing the IPSec protocol. IPSec allows you to encrypt enterprise-wide communications by using either Kerberos version 5 or a certificate generated by your certificate server. You can implement the usage of the IPSec protocol by mandating it from within a group policy.

There are actually a few different ways that you can implement IPSec. Obviously, some of these methods are more secure than others. The Client implementation is the least secure of the available IPSec policies. It tells a machine that it’s okay to respond by using IPSec if another machine requests it, but it will never initiate secure communications. The Server IPSec policy is designed to try to make all outbound communications secure but will accept inbound communications even if they aren’t secure. The final predefined IPSec policy is Secure Server. This policy requires encrypted communications in both directions.

You can actually use any of these predefined IPSec policies on clients, servers, or both. However, I recommend using the Secure Server policy on all of your Exchange servers. Doing so will guarantee secure communications between Exchange servers and between the clients that use them. Of course, before the clients can participate in secured communications, they need to be assigned one of the IPSec policies. You can assign any of the policies to them, but I recommend assigning them either the Client or the Server policy, depending on the security needs of your organization.

When assigning IPSec policies, it’s easy to encrypt every bit of traffic flowing across your network. However, doing so takes a toll on performance. Additional processing power is needed on each machine to encrypt and decrypt the network traffic. Likewise, encrypted packets are larger than nonencrypted packets, so encrypted communications require more network bandwidth than nonencrypted communications. Before you go and encrypt every single packet of information, consider the impact that doing so will have on your system.

I mentioned that you will also have to deal with the issue of e-mail that’s flowing between Exchange users and Internet users. Unfortunately, there’s no easy way to provide encryption for standard e-mail messages at the server level. The reason for this is that the encryption keys that are normally used are associated with Active Directory. Because the typical Internet user doesn’t use Active Directory, they won’t have access to the encryption keys. You can encrypt individual messages, though. In such a case, the keys are sent along with the message so that the recipient can decrypt it.

Right now, you may be wondering about e-mail traffic encryption for employees who work at satellite offices. Whether or not these employees will be able to use encryption will depend on the method that they use to access your Exchange servers. If the offices are linked together by a typical WAN link, then encryption won’t be a problem. Active Directory is probably already aware of the remote office, and communicating with the remote office would work the same (from an encryption standpoint) as communications within the local office.

However, if the remote office is connected to the local office by a virtual private network (VPN), then things will be even easier for you. Remember that the whole idea of a VPN is to provide secure communications through an insecure medium, such as the Internet. So, any traffic that flows across the VPN link has already been encrypted. All you need to worry about is encrypting local traffic on both ends. The VPN traffic flows between two designated servers. Each of these servers then routes traffic between the Internet and their respective local networks.

So, if a user on network A needed to send an e-mail message to a user on network B, the traffic would be encrypted for its journey to the VPN server on the local network. That server would then encrypt the traffic a different way in order to send it to network B. The VPN server on network B would receive the message and then translate it into an encryption format suitable for passing the message along to its final destination.

Digital signatures
Another way to increase security is to use digital signatures at the client end. Adding a digital signature to a message does a couple of different things. First, it provides undeniable proof of the source of a message. For example, about six years ago, someone sent me a message that appeared to be from my boss, but wasn’t. I responded to the message, and the results were a little embarrassing, to say the least. If digital signatures had existed at the time, that whole ugly situation could have been avoided because I would have been able to identify that the message was faked.

Another thing that you can do with digital signatures is encrypt individual messages. This layer of encryption goes beyond any encryption that may currently exist on your network. Therefore, if you’re using the IPSec protocol to encrypt transmissions already, your message could be double encrypted if you chose to use a digital certificate.

To use a digital certificate, you must first be able to acquire a certificate from either a certificate server on your network or from a third-party provider such as VeriSign. Once you have access to a digital certificate, the trick is to make Outlook 2000 use it. To do so, open Outlook 2000 and select the Options command from the Tools menu. When you do, you’ll see the Options properties sheet. Select the Security tab and click the Get A Digital ID button. Outlook will then take you to a Web site that walks you through the process of acquiring a digital ID.

Once you’ve installed the digital ID, select the Options command from Outlook 2000’s Tools menu again. This will take you to the Options properties sheet. Go back to the Security tab and click the Setup Secure E-mail button. When you do, Outlook will display the Change Security Settings dialog box. This dialog box will allow you to control what you do with the digital signature. For example, you can tell it to automatically sign all of your messages. Likewise, you can also encrypt your outbound messages. I should mention however, that there’s an option to send signed messages as clear text. You’ll have to use this option if you’ll be sending e-mail messages to people whose e-mail programs can’t decode encrypted messages.

Security is one of the prime concerns for most network administrators today. When you implement software as complicated as Exchange 2000, it can be a daunting task to figure out where to begin to properly apply security. However, once you know where to begin and what your options are, you’ll quickly discover that securing Exchange 2000 isn’t that difficult at all.

Editor's Picks

Free Newsletters, In your Inbox