In this article, we will explore the many security challenges that today’s messaging administrators face. Specifically, we will focus on the risks to an Exchange environment and the tools available to help protect your messaging environment from virus outbreaks, hacker attempts, unsolicited mail and even attacks from an unknown origin. We will explore Exchange 2000 features, the new tools and features in Exchange 2003 as well as Outlook security tools, ISA Server and some third-party applications. Just as with any solution, security is not likely to be obtained by using a single product or technique. More likely, a combination of tools, products and techniques are the best solution to protecting your systems. Please keep in mind that this is a 2500-3000 word magazine article and not a replacement for a complete security program. Microsoft and other vendors have produced formal security books, programs and articles that explain what is needed to provide a security program to your environment. See www.microsoft.com/security for more information. In addition, you should refer to the Certified Information Security Systems Professional (CISSP) curriculum to get a better idea of how to build security processes and systems.
You are likely not hearing the cry for security for the first time. Microsoft has been on the security bandwagon for a couple of years now as it tries to shake its reputation for being insecure. To Microsoft’s defense, it’s operating systems and office tools have been under fire for several years as gifted students of technology and security specialists try to “topple the giant” and expose weaknesses in it’s systems. Even small security problems are often blown out of proportion and cause Microsoft to pull it’s developers from other projects in order to create a patch or fix for a security problem that could potentially affect no one. Where in the past Microsoft has been reactive to these security alerts, it now has embraced the idea that patches will be required and has built elaborate systems to automate the alert and update process. Windows update services have been available for over a year and reflect Microsoft’s understanding that security is an ongoing issue that will require diligence on it’s part as well as the administrators.
So what are the largest security issues facing Exchange administrators? At the Microsoft Exchange Conference in 2002, several surveys were sent out. The leading security concern as reported in Aladdin’s security survey was New Viruses, followed closely by Unauthorized External Access then Unauthorized Internal Access. In addition, 48% of the companies identified that Spam had a moderate impact while 28% indicated it was a severe impact. Should spam be considered a security threat? Industry analysts often classify spam in the security department and I think I agree with them. First, spam often includes HTML objects that load graphics and can launch code. Second, a great deal of spam is of the pornographic nature and can affect someone’s job; even yours. Right now, a case is pending with Cisco where an employee is suing Cisco because they feel the company should have done more to prevent offensive materials from entering the email system.
So now that we have identified the four security areas, let’s break them down a little more. We will start with the number one concern which is a virus outbreak. The war against viruses has several fronts. In the Microsoft Press book, Secure Messaging with Microsoft Exchange Server 2000, the idea of Defense in Depth is discussed in great detail. The idea is that the defense from virus outbreak/attack is not a single layer or even a single program. In fact, to defend yourself from a virus outbreak you will likely be using several products installed on different machines. Here is where you need to focus your energies:
Perimeter Protection. For most people, this means SMTP. At every SMTP entry point in your infrastructure, you need to have a virus scanning engine. Moreover, this virus scanning engine needs to have it’s signature files updated regularly. Those of you who remember the nimda virus will remember that the signature files were available at different times depending on your AV vendor. Because of this, many administrators like to use different vendors or in some cases vendors that provide more than one scan engine in their scanning product. The brand and operating system of this scanning engine makes no real difference as SMTP is a open protocol. I know some administrators who have written their own sendmail scanning engine that sits in the DMZ. As long as the virus signatures are updated regularly and a trusted scanning engine is used, this configuration should work fine.
The next anti-virus front is the store itself. Just because we have filtered a virus from entering the system from SMTP, does not mean your store is clean. We need to make sure that any virus that somehow gets into the store can be identified and removed. It is very important that you also allocate scanning software that has the capability of scanning the Exchange store. This scanning engine may be the same as vendor or program as your SMTP scanning engine. The most important thing is that the scanning engine be Exchange-aware and knows how to scan the databases, not the database files. If you configure a scanning product to scan the database, stm or log files then you will likely crash your Exchange system.
The third area of importance in respect to virus scanning is the file system and memory systems both on the clients and on the servers. If you can stop a virus from getting into the memory or hard disk of your client machines, then you will probably avoid an outbreak. In addition to file system and memory scanning, there are some additional items you should look for. On the server, try to allocate AV software that can watch for IIS virus attacks. On the client side, be sure to use an Outlook client no older than Outlook 2000 SR-1 (with the security patch) and do not change the registry to that the security features are disabled. Client protection is probably the most important way to stop an outbreak. The security features of Outlook (2000 SR-1 or better) will not allow a program to access the address book or access Outlook programmatically without user-intervention. What this means is that a virus that proliferates itself by automatically mailing others will be stopped or at least slowed down with the newer versions of Outlook.
OK, so now we move on to access security which is the second and third largest concern for Exchange administrators. Unauthorized external access and unauthorized internal access are simplistic thoughts with complex implications. Before you accept the default settings in Exchange or open ports for people, you need to decide what kinds of access you will allow. There are many companies I work with who still do not allow access from the Internet. Other companies require a VPN session in order to allow external access. (Which more or less changes the access type to internal.) The less access you allow into your environment the more secure it will be. Allowing HTTP, POP, IMAP, LDAP, client SMTP and MAPI access from outside your firewall requires you to configure additional components in order to better secure your environment. For each external access method you provide, you need to allocate technology to lock it down. For the most part, we are talking about the use of SSL in order to secure the message as well as the authentication. In addition to securing the communication, you need to be concerned about strengthening the password and changing the password lockout, duration and history. Anyone can hit your secured OWA site and break passwords by using simple programs that use random words or password building routines. If you are going to allow external access to your systems, you will most certainly need to take a strong look at your password strength and policies.
Smartcards and VPN access offer superior security to just SSL alone. A VPN server that requires smartcard access means no connection can be made into your network unless the end user has a smartcard, knows the pin number and has a valid account. On the client end all that is required is an Internet access, an IPSEC or PPTP connection to the VPN server, a $30 smartcard reader, his or her smartcard and pin number. Incidentally, the only VPN software necessary comes with Windows 2000 and 2003 Server. The only client software required comes with Windows 2000 and Windows XP. Aside from SMTP access (through a relay or directly) your Exchange servers would never need an Internet connection for this configuration. Access, of course would be provided only if the client can connect over IPSEC or PPTP and has a smartcard reader so there is a limitation in respect to connectivity at customer locations or kiosks. Allowing OWA access through a reverse-proxy with SSL could then provide your emergency access if VPN connectivity is not possible.
So what is possible with OWA? I mentioned in passing the idea of a reverse proxy, but we should discuss this more as it has some very interesting possibilities. As you already know, Exchange 2000 Enterprise (and Exchange 2003 Standard edition) can act as a Front-End server. An Exchange 200x FE server can accept an SSL connection from a client and “proxy” the get and post requests to the appropriate backend (mailbox) server. The client never actually talks to the mailbox server, instead it’s commands are echoed to the mailbox server by the FE server after the authentication process. ISA server can also serve as a FE server and it has several distinct advantages. For one, it can bridge SSL whereas an Exchange FE server cannot. In other words, the HTTP traffic can be encrypted between the client and the FE server and between the FE server and the mailbox server as long as ISA server is used. Pretty cool huh? In addition, ISA server is tuned to cache so all those graphics and icons used by OWA will only have to be loaded on the ISA server once and it is then stored in a cache which can speed up performance of OWA somewhat.
Unauthorized internal access is a topic that surprised me a little as I rarely hear an administrator mention it or discuss it as a problem. It could potentially be a huge problem depending on who’s email was accessed and what data was collected. Payroll would not be a nice thing to have posted on the wall. So how can be reduce our exposure to a breach in internal security? The answer is as multi-layered as virus protection. You will likely use a combination of processes and technology to ensure internal security. Walking away from your machine while Outlook is running will circumvent any technical security you may have put into place. (Unless you are using Bluetooth or a Smartcard attached to your person.) Many of the precautions we used in protecting against external access should be replicated internally. Unless you really need it, POP and IMAP should be turned off where possible. In addition, OWA should require SSL in order to keep internal passwords secret. Smartcards are again my favorite in respect to unauthorized access as there is a setting in the User object within the AD to require smartcard access for the account. In other words, you could require that certain HR people, the administrator account or key people use smartcards. If they do not have their cards, their accounts cannot be accessed. Pretty simply huh?
IPSEC of course also plays an important role in protecting the network from packet inspection and during the authentication process. If you have a network that requires the utmost of protocol security (perhaps you have a research team that excels at packet inspection) you can implement a more strict IPSEC policy that requires certificates for communication. There is much more on this subject online, but the capabilities are built-in to Windows 2000, XP and Windows Server 2000 and 2003. Message encryption is also handy for ensuring that messages can only be read by certain people. The use of certificates is required for message encryption and is also a perfect fit for smartcards as the certificate can be placed on the card itself instead of residing on the user’s hard drive. The idea of message encryption is pretty simple really. You have a certificate authority in the network or you use an external CA. I encrypt a message to you using your public key so that only your private key can decrypt the message. The AD can be used to publish the public keys so all I do is pick your name from the address book. On your end, you have your private key (which is password protected) on a floppy, on the hard drive, in a smartcard, etc. and use it and your key password to read the message.
Next, let’s spend a moment on spam. USA Today estimates that over 7 billion spam messages will be sent this year alone. Unsolicited mail is choking our message systems, duping people into give away their account names and passwords and sending pornography throughout your system. Whether or not this is considered a security problem is debatable, but it is certainly a problem being faced by messaging administrators. Fortunately, Microsoft is on the bandwagon to help stop spam and has released some new tools in Outlook 2003 and Exchange 2003 in order to help stop it. Most of you will likely still seek third-party Exchange addins like Spam Smacker or iHateSpam to help stop spam, the new tools will help you at least slow it down a little. The most exciting feature is Outlook 2003’s new support for blocking HTML messages. <figure1.bmp> . This feature is enabled by default and blocks external content in HTML messages. So if a message comes in and tries to load external graphics, the graphics are blocked. While any offensive text is still there and the message itself is not blocked, external graphics are not loaded or displayed. This is highly effective in reducing the number of pornographic images your users are exposed to.
Outlook 2003 also comes with more advanced search filters for recognizing junk mail and adult content. Unfortunately, the search filters cannot be edited so you are stuck with just the well-known word variants. Exchange 2003 is not without its new advanced features as well. Blacklist server support is now available which allows the Exchange server to check the sender’s address against known spam lists on blacklist servers. While the new features are much improved, there are still some holes in this area in that body and subject searches are not available from the server level and monitoring and resending filtered messages are not a simple task. Fortunately, Microsoft has updated the new Anti-Virus API to 2.5 so ISVs can create better snap-ins for Exchange Server 2003 to handle and control spam better than before.
Lastly, there is the matter of updates and the implementation of security patches. Windows 2000 with SP3 and better supports the Windows Update Services (as long as your server has outbound HTTP connectivity). While automatic update, installation and reboot is generally not recommended, the automatic downloading of updates is a great idea. Your server connects peridocally to the Windows Update site and downloads any security updates that are updated. The administrator must then log on to the server (terminal services is fine) and choose to install the downloaded updates. If the administrator never looks at the servers, the security patches will never get installed so it is important that the admin team connect to the servers periodically and install the updates. A weekly change control process is always a good idea and it allows the administrators to not only install the updates, but reboot the server is necessary. If you are just now putting a change control process in place, let me help you decide on your first update. If you have not done it already, you need to download and run the Microsoft Baseline Security Analyzer tool on every Windows Server. Secondly, you should download and run URLScan on each IIS server. These two steps will help protect you from IIS attacks.
In conclusion, today’s Exchange administrators are faced with securing against the unknown. Fortunately, Microsoft and other vendors have provided the necessary tools to make protecting and updating the system a science. Moreover, Microsoft has documented some excellent security guides, books and procedures for securing your environment. Securing your systems does not have to be a daunting task, but diligence is key. Unless you regularly check, monitor and update your systems you will not be able to maintain a level of security. The less access you provide, the easier it will be to secure your environment.
Microsoft Press – Secure Messaging with Microsoft Exchange Server 2000
Microsoft Security Website – http://www.microsoft.com/security
Exchange Server Security Resources – http://www.microsoft.com/exchange/techinfo/security/default.asp
Technet – Exchange Server Security Center – http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/prodtech/mailexch/default.asp
Microsoft Baseline Security Analyzer – http://www.microsoft.com/technet/treeview/default.asp?url=/technet/Security/tools/tools/MBSAHome.asp