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.

Reference:

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

 

 

 

 

 

 

 

 

 

 

 

 

Chances are, you are one of the millions who suffer from Spam-i-tous.

Spam-i-tous n. – def. ailment where the sufferer spends time each day sorting through and deleting senseless unsolicited emails designed to provoke him/her into spending money. Fortunately, Microsoft has unveiled a new set of tools that will allow Exchange administrators to perform a spam-a-dectomy in order to help remove spam from the messaging environment.

For those of you who remember the tools that shipped with Exchange 2000 and Outlook 2000, skip on a bit. For those of you who didn’t know anti-spam tools existed in Microsoft’s messaging suite, you are not alone. Outlook 2000 (and even Outlook 98) included a little-known feature known as Junk E-Mail filters. Based on mailbox rules, the junk e-mail filters would filter messages based on criteria identified by the end- user. If a message came through that was of pornographic nature, (and the user decided they did not want to receive similar messages) he or she could “tag” the message as junk mail or adult content, and the sender would be identified in the rule. In addition, the junk mail filter could scan the messages using preset key words and phrases. For example, “Subject contains ‘adults only’ ” would capture all messages using the phrase in the subject field. The message would then be moved or deleted based on the rule settings the user had configured.

Even Exchange 5.5 had some basic Spam-fighting tools that were slightly improved with Exchange 2000. Both versions came with the ability to block sending servers by IP address. Reverse DNS lookup was another option that helped block messages from servers who were spoofing other domains or were not valid. If an administrator could watch incoming messages, train users on junk e-mail filters, and block sending servers, then there was a good chance that Spam could be contained. I say that in the past tense because the techniques that spam’mers used has changed, and the tools that Microsoft provided with Outlook 98/2000 and Exchange 2000 are sorely outdated. For example, a junk mail filter that filtered the word “refinance” for example, was thwarted if the sender spelled the word differently or used spaces between the characters. Better technology was definitely needed.

Outlook 2003 Anti-spam tools

If you are debating whether to upgrade your Outlook client to Outlook 2003, let me help sway your decision. To begin with, Outlook 2003 implements a privacy feature that blocks html-embedded messages from automatically retrieving pictures from the Internet that are identified in the message.

 

This is a huge bonus since most pornographic material that comes through is HTML links and not embedded into the message. Spam senders also pay ISP costs and really don’t want to send out millions of large messages because it limits the number of people they can reach in a short amount of time. So even if Spam messages get through, they probably won’t contain graphics, even though the bold flashing text may be offensive. This new feature should help alleviate the fear-factor in opening mail at work.

The biggest improvement to the new Outlook client is the enhanced anti-spam controls and features.

However, before we dive into this  we need to understand how and where these filters are applied. If your backend server is Exchange 2003, then all (spam) filtering for that mailbox is done at the server. Those of you who have imported the rather large blacklist files that are available on the Internet will love this news because Outlook 2000 and 2003 slows significantly when the filter lists are large. From a client perspective, this is a very good thing because the server will move or delete the email before the Outlook client ever sees it. This being a new feature, many administrators will be hesitant to recommend each user import huge blacklists when a server filtering solution may be better suited. Having a large server-based list will save server processing time and reduce the amount of administration each user must perform to control their own spam.

There is a catch-22 when it comes to fighting spam. On one side, only the users can truly decide if a message sent to them is spam or not. On the other side, allowing each user to make that determination is time-consuming, frustrating and not dissimilar from non- filtering as the mailbox users must still sift through their messages to determine if they are getting false-positives. Having said that, the one thing server-based solutions do not do well is providing granular settings for each individual mailbox. This is where the new Outlook 2003 tools really shine. If you already know whom in your organization gets spammed the most, these folks will thank you as if you had shortened their work-day (which is not too far from the truth).

There are four settings that each individual user can set within their own Outlook profile.  As previously mentioned, the lowest-risk feature is set by default. With No Protection, Outlook will not scan messages for content, but will “block” messages based on specific domains or senders your have identified within the junk senders options. The second level; Low scans messages against the lists you have provided, as well as other basic filters such as those described in the filters.txt file. Microsoft continues to install this file with Outlook, but it is very outdated and includes a very small sampling of definitions and keywords. While you cannot directly modify the content rules, Outlook offers the ability to change the aggression level of filtering as indicated by four options. For example, if you still have a great deal of incoming spam and notice no false-positives in your Junk E-Mail folder, then you may want to increase your scanning level to High. After you choose this setting, watch your Junk E-Mail folder very closely as you will likely need to add exceptions to your Trusted Senders lists in order to allow questionable messages to come through unscathed.

The highest scanning option for Outlook is one that is increasing in popularity. It is as simplistic as the No Protection option, but has the opposite affect. When you choose the Trusted Lists Only option, a message will not make it to the inbox unless the user is in your address book or in your Trusted Senders or Trusted Recipients list. The beauty of this setting is the ease at which it can be implemented. With one click, you will only receive mail from people you know. If you do business with company.com, you can easily add that entire domain to your “Trusted Senders” list. Also, if you want to receive mail from someone at aol.com, you could add aol.com or the individual email address to the “Trusted Senders” list.

As you can see, Outlook junk mail filtering has improved. Since the filtering occurs at the server level, the server can do the work instead of the client. Although this puts an additional (and unpredictable) load on a server, it is important to remember that the impact we felt on the client side was a direct result of launching Outlook and processing all the messages in the inbox. Now, because the filtering will occur on the server, it is processed as the message arrives so the load is spread out more evenly. This is not the only load we are adding to the server as Exchange 2003 now supports some of its own new updates and features to fight spam.

Exchange 2000 offered some very basic features that can be used to filter messages. More specifically, Exchange 2000 offered the ability to block messages from certain domains and IP addresses. An Exchange 2000 administrator can inspect incoming messages and track the sending server’s IP and domain by inspecting the SMTP message header. This information can then be used to build a block list in Exchange 2000.

Using the Exchange System Manager, the administrator can globally block a specific sender or domain. By using the connection control settings of the SMTP Virtual Server, the administrator could block the sending server’s IP address or network. It was with this setting that many of us began to learn how the spammers operate. These marketing companies often operate out of a small or home office and in countries with fast network links. Those of you who have allocated new ISP links, whether it be a leased line, DSL or ISDN, can appreciate the amount of time it takes to provision and install a digital line. The most prolific spamming companies must constantly change server IP addresses in order to confuse spam filters. The IP address you blocked last week will probably never be used again. Understanding this, and the difficulty in allocating new lines, the spammer will acquire a DSL or network link with a bank of IP addresses. In theory, 32 IP addresses should provide a month’s worth of spam if the IP address, server name, sending domain, and messages are changed every day. By identifying this early, the administrator can head off other spam messages by filtering a block of IP addresses instead of just the one used to send the last message.

Unfortunately, the built-in tools that are bundled with Exchange 2000 and Exchange 2003 do not recognize sending networks, although they do allow you to block networks. Third-party spam tools will be required in order to recognize and block spam-sending networks. Having said that, Exchange 2003 does include many more anti-spam tools than its predecessor.

Not only does Exchange 2003 include the ability to block domains and IP addresses, but it supports the basic anti-spam tools such as the use of blacklist servers as well as whitelist and blacklist support. In addition, you can also create an Exception list to identify the mailboxes that should never be filtered. Perhaps you have an executive who wishes to handle spam filtering on their own using the Outlook 2003 filters.  By adding his/her SMTP address on this screen, you can be sure that no server-based rule will ever filter their messages.

It is also important to understand the difference in respect to the terminology used for fighting spam. Exchange 2000 and 2003 both support blacklists¾meaning the administrator can manually add entries for domains or senders they wish to block. Exchange 2003 now supports the use of blacklist servers.  Exchange Server 2003 can compare the sender’s domain against a list of known spam domains located on third-party servers on the Internet. RELAYS.VISI.COM, for example, is a free blacklist server you can use.

IP and IP network blocking can now be controlled from the same Message Delivery configuration screen, so we now have “one-stop shopping” in respect to server-based filtering rules. Sender Filtering rules is still available, as is the new Recipient Rules filtering. On the Connection Filtering screen, the administrator can add the IP Address(es) of the sending domain to create a Whitelist of acceptable sending domains. From this same screen, the Deny list can be built to block sending SMTP servers or networks. While these tools are very important in blocking and allowing SMTP messages based on IP addresses, it is important to note that messages being forwarded to your domain by a third-party, another domain, or even a server in your DMZ may not be subject to allow, disallow, or blacklist rules since the sending server is one you trust. It does not appear that the Exchange 2003 filtering and IP rules can recognize a trusted SMTP server and inspect the information from the server that sent the message to it. In other words, if you have a send mail or content filtering server between your Exchange 2003 server and the Internet, the IP blocking/allow and blacklist server support will probably not function correctly as all of these review and consider the IP of the (last) sending server and not the original sending server. If this is your configuration, a third-party spam tool may be a better fit for you.

I have learned over the years that the correct defense for fighting virus outbreaks requires more than one solution. The client and server must have logic installed to detect virus patterns, and the same is true for a comprehensive battle with spam and unsolicited mail. With Outlook 2003, we are provided with much more sophisticated anti-spam tools that allow the end users to define their own tolerances and manage the deletion of messages and processing of false-positives. While this does save the administrator from certain management of spam messages, the load on Exchange Servers will increase while the same amount of messages are received, and end-users are still required to filter and sort junk mail, albeit with better management tools.

On the Server front, Microsoft has indeed made headway in providing support for blacklist servers and override support for internal SMTP addresses. One of the most powerful features of the server-based filtering is the ability to archive or delete messages. Should you choose to delete messages that are filtered due to server-rules, you can stop the messages from entering the Exchange stores and limit the number of junk messages the users must sort through. Another awesome feature is the ability to drop sessions from known spam senders.

With a fairly simple script, I can find the valid SMTP addresses in your network by using random or known words within an SMTP session. Your SMTP server will indicate “recipient OK” when I hit a match and I can add it to my spam list. To thwart this, we can tell Exchange to drop the connection if a match is made against the Senders list. As cool as this feature is, it does require that the sender continue to use the name we identified and will not work for spoofed domains.

In summary, Microsoft has greatly improved the spam fighting tools in both Outlook and Exchange Server. The 2003 versions of both programs should provide the administrator with a base set of tools to help get spam under control. While these filters and tools will work better in some environments, they will not work optimally in all networks. Microsoft has extended the new Anti-Virus API in Exchange 2003 to allow third-party vendors to develop their own Exchange Server snap-ins to embrace and extend the base-set of components provided with Exchange Server 2003. Specific features that can be provided by third-party vendors include management tools for archived messages, support for forwarding servers, detection of spoofed domains, a comprehensive list of subject and body text filters, the ability to dynamically update the filter engine and filters list, web-management tools with statistics, and much more