Windows 2000 and Exchange 2000 offer new routes to email security, but have you done all you can with Exchange 5.5?

8 Ways to Secure Exchange

Windows 2000 and Exchange 2000 offer new routes to email security, but have you done all you can with Exchange 5.5?

• By Roberta Bragg
• June 01, 2000

I love Spam. Yeah, I know. Most of you think that fatty ham-ish product in the squarish can is a worse treat than reassembling keyboards from spare parts. But I like it. As far as I’m concerned, it rates right up there with fried bologna.

What I don’t like is that noxious spam that screws up my other source of pleasure, email. Like most of you, I don’t appreciate unsolicited offers for pornographic pictures, vacations in Hawaii that don’t really exist, stock market scams, and real estate swindles. Mostly I just delete without reading them.

But there’s something that you as the Exchange administrator can do about spam. It’s not often we technophiles get to do something that benefits society as a whole while just performing our jobs. But spam control is one of them. If you or your counterparts are responsible for the email servers in your company, you can take steps to reduce spam for the rest of us.

Controlling spam is just one step you need to take to secure Microsoft Exchange Server. Here’s a list of eight must-do’s. Plus, since you’ll eventually want to maximize the security benefits existent in Windows 2000, I’ll touch on that—as well as security in Exchange Server 2000.

1. Think big—attackers do. Don’t just think about someone knocking out your Exchange server or reading your email. If your Exchange Server is on the Internet, email can be a source of forgery, Trojan horses, and viruses, as well as unwanted advertising.

In a forgery situation, messages appear to be coming from someone other than the real source. These messages spread false information, false alarms, and false hope. Worse, they may trick users into providing information such as passwords or other compromising data.

In the case of Trojan horses, recent security advisories from Microsoft, third-party security lists, and the trade press have pointed to vulnerabilities within email. Messages can carry executable code that may damage your system or send back data from your machine.

We all know the problems that viruses can create. Just when we think we have them licked by running scans on all systems, they creep in along with our email.

To guard against the annoyances, destruction, and downtime these things can cause, you have two choices. I’d suggest you do both.

First, control mail that enters your system. Investigate the purchase of software that screens each and every mail message and attachment that enters your network. This software does for email what the lowly virus scanner does for your local OS. Ask your ISP if it’s using such software, since it’s something many ISPs are now considering. ISPs, beware: If you don’t offer this service soon, you may not have any services to offer later.

Second, everyone in your organization needs a great big dose of security awareness. Make sure they get it while you tighten control over their activities. You know never to read unsolicited attachments and never to run “free software” someone sends you. And, of course, you certainly send virus and security warnings you receive to the security officer—not to all 5,000 mailbox addresses in the corporate address list.

But do your users know this? As techno-gurus, we often look down upon the digitally unwashed. Give them a bar of soap and help them clean up their act. Meanwhile, distribute hot fixes and patches for client vulnerabilities (and there have been a lot lately) and use System Policy for NT 4.0 and Group Policy for Win2K to implement and maintain security tweaks.

Meanwhile, log off as administrator and log on with your user account (with Win2K, use “run as”). That’s right—you should never read email using your privileged account. Some Trojans and other security nightmares require administrative privilege to infect your systems. Don’t give away the corporate jewels unwittingly.

2. Use advanced security features to provide encrypted email messages. Exchange comes with the ability to encrypt email. You must install the Key Manager (KM) server and provide email clients with certificates and keys. It’s not hard, but it is extra work. You must also train your users to use this service; it won’t encrypt email by default. Investigate combining Exchange and Microsoft Certificate Services. Microsoft Support Services has an excellent white paper on doing just that; see “Leveraging Security Features in Windows 2000 for Exchange” at www.microsoft.com/ exchange/55/whpprs/Security2000.htm. (It’s a 9M download.)

3. Protect your Internet Mail services (the service that provides the connection to the Internet, and thus Exchange). You can configure this service to connect to specific SMTP hosts only, or to block efforts by others. While you’re at it, configure Internet Mail not to relay SMTP mail—that will help reduce spamming. See “Spam I Am.”

4. Control message size. A simple denial-of-service attack could tie up your mail server by sending large messages to existing—or non-existent—mail users. By limiting the message size, larger messages are discarded.

5. Prevent delivery of automatically generated replies. It’s easy for users to configure mail clients to announce to the world that they’re on vacation in Europe for six weeks or simply out of the office for a personal day. Handy as that may be, this information is not a good thing to tell outsiders. (“Oh, goody. The systems admin is gone. Now’s a good time to hack his account…”).

6. Place your Exchange server behind the corporate firewall, preferably in a screened subnet. The firewall can block unwanted and unneeded traffic while allowing specific mail server traffic to come only to the mail server. In a screened subnet design, servers that must be connected to the Internet are kept in a separate subnet. Knowledge of the inner corporate addresses and computers can more easily be kept hidden.

If you use multiple mail servers or require extreme security messages, consider placing a server with no mail boxes in the subnet or use an SMTP proxy (a program configured to accept and pass on SMTP mail). The proxy can receive all email and forward it to internal servers configured to receive mail only from it. This scenario also has the advantage of allowing only the proxy’s address to be a part of external DNS servers. What attackers don’t know about, they can’t attack.

To allow appropriate packet filtering, you may need to configure a Remote Procedure Call (RPC) to use a fixed port. (RPC data is used for communications between Exchange clients and the server). Firewalls need to know the ports you wish to allow open so that traffic can flow through them. I’ve included a helpful table with this column. One caveat: Since Exchange uses random addresses to talk RPC to the clients, your firewall admin will go nutso. To keep that person from experiencing meltdown, configure a static value for the port by making the following registry entry. Add the value TCP/IP Port to the keys:

HKEY_LOCAL_MACHINE\SYSTEM\
   CurrentControlSet\services\MSExchangeDS\
   parameters
HKEY_LOCAL_MACHINE\SYSTEM\
   CurrentControlSet\services\MSExchangeIS\
   parameters

Then, as its value, enter the port number you want the RPC to use. Make sure this port isn’t used elsewhere—and that it can be configured in the packet filtering program. Maybe it’s a good idea to get together with the firewall person, no?

7. Protect the base operating system. It’s easy to forget that security starts in the home. So don’t forget to secure NT or Win2K first, before installing Exchange. All the special security considerations outlined here and elsewhere will make little difference if you don’t follow those steps first. Use NTFS; require users to have complex passwords; apply service pack and hot fixes; protect files with Access Control Lists (ACLs); run only the services that you need and unbind unneeded services from network cards; check permissions on any shares… You know the drill.

8. Configure RPC encryption on the client to encrypt RPC communication between the client and server. This is different from encrypting email messages. When you encrypt an email message, it’s encrypted throughout its voyage, from your client to the recipient. You have to ask for this to be so. When you encrypt RPC, the data gets encrypted on its journey from your computer to the Exchange server as it crosses the network. While it’s in your mailbox or at some final destination, there’s no encryption. Even in a pure Exchange Server/Outlook environment, it’s protected only while on the wire. But maybe that’s all you need.

To use this service, you must open the Exchange services properties on the Outlook client (find this from the Tools menu under Services); on the Advanced property page, check both boxes for encrypting all client/server communication. The nice part here is that once done, it’ll happen automatically. (Exchange 2000 uses SMTP, not RPC for client/server communications, but it’s capable of using RPC with your MAPI clients.)

Leveraging the Security Features of Win2K

How can you use the security features of Win2K to protect Exchange? Several new features will have immediate usability; others may need to wait for the directory integration and architectural changes of Exchange 2000. You can implement the following list of services and features as you move to Win2K:

• Authentication between Exchange Server and Win2K can be implemented with challenge and response or Secure Sockets Layer-encrypted channel (used to update the Win2K directory with the Exchange directory and contacts).
• Certificate Services. A public key infrastructure (PKI) is built into Win2K. This allows you to issue X.509v3 certificates for authentication (I am who I say I am), confidentiality (no one else can read my stuff), and data integrity (the message hasn’t changed). These services are used by Exchange 2000 Key Manager services. You can integrate Win2K Certificate Services with Exchange Server 5.5 advanced security. Learn more by reading the white paper, “Leveraging Security Features in Windows 2000 for Exchange,” which I referenced earlier.
• IPSec provides security for IP at the transport layer. This means that it can be implemented to protect all communications traveling across your IP network without any changes to the applications you use. While SSL (the security used to protect e-commerce transactions) can be used with applications that know how to use a Web browser, IPSec can be used without rewriting any applications. Properly configured, it works by encrypting every packet that leaves the protected computer. To protect your email, your Exchange servers and clients must have IPSec implemented.
• Encrypting File System or EFS can be used to encrypt files and folders on any Win2K computer. Remember: It doesn’t protect data while it crosses the network, and it’s a personal encryption system. You and I can’t use it to share encrypted data. Since my mailbox resides on the Exchange Server, how can EFS be used? Remember that attachment that represents your budget for the next quarter? If you’re using Win2K Professional, set up a special folder on an NTFS partition to store these documents. Encrypt the folder, and anything you place in it will automatically be encrypted. For your users, establish this folder via Group Policy. Then, as I reminded you earlier in my speech, make sure users are trained in its uses and abuses. Files moved to 3.5-inch disks, for example, don’t remain encrypted.

Exchange 2000 Goodies

It’s too soon for me to comment on Exchange 2000. However, here are a few tidbits to share. Win2K uses Kerberos. Exchange 2000 will be a service. In the Kerberos world, that means a service ticket will be required for access. Simply put, a higher level of security will be provided as the result of using a more secure authentication system.

Win2K provides authentication through delegation, which is leveraged by Exchange Server and Outlook Web access. Authentica-tion through delegation means your credentials can be forwarded from IIS to the Exchange server when it resides on another computer. NT can’t provide authentication through delegation; this means that when IIS and Exchange are on different servers, clear-text passwords cross the Internet when users are allowed to access the Exchange Server using their browser.

Access control in Win2K is much more granular everywhere, because access is evaluated at the item level. In Exchange 2000, this means, for example, if you’re allowed to access only five of 10 items in a public folder, only those five items will be visible to you.

Last, using the Active Directory Users and Computers snap-in, administrators can grant permissions to non-administrative users for some chores. This is called delegation of administration. It allows you to spread the wealth, so to speak, and get others to do some of the more mundane administrative chores, (like resetting passwords for the masses) without elevating users to administrators and granting them all kinds of other privileges as well. Exchange 2000 administrators will be able to use the Exchange System Management snap-in to delegate administrative control as well. They might use this to allow users to manage public folders, for example, or to give limited privileges to new Exchange administrators until they learn the ropes.