Because Microsoft Exchange Server email security threats, such as spam and viruses, are constant, it is more important than ever to make sure Exchange Server is securely deployed. Even so, Exchange Server complexity -- and the fact that the Internet is chock-full of contradictory advice -- can make securing Exchange a challenge. To better protect your email environment, here are some Exchange Server security dos and don'ts that you should put into practice.
Do choose your certificates carefully
Digital certificates are a requirement for secure Internet communications. Even so, deciding which types of digital certificates to use can be tricky. The primary reason is cost, since digital certificates from commercial certificate authorities can be expensive.
Investing in a single certificate wouldn't be too costly, but, unfortunately, you typically need one certificate for every hostname that you use. This means separate certificates for Outlook Web Access (OWA,) your edge transport server, the Autodiscover service and who knows what else. When you consider that these certificates periodically expire, you can see how this costs add up.
I have seen many creative techniques for reducing certificate costs, including one organization that threw caution to the wind and decided to go without certificates. Obviously, that technique falls squarely into the Security Don't (ever) category.
A common low-budget solution is to use self-signed certificates. Exchange Server 2007 can generate self-signed certificates to use in place of expensive commercial certificates. While this might sound appealing, users will likely receive certificate warning messages when they try to connect to Exchange remotely, and Windows Mobile users won't be able to connect at all. If you decide to use self-signed certificates, use them internally; use commercial certificates for external network connections.
To get around this, use a special type of X.509 certificate known as a Subject Alternate Name (SAN) certificate. A SAN certificate allows you to associate multiple hostnames with a single certificate. These certificates typically cost more than a normal X.509 certificate, but the extra cost may be justified if you would otherwise have to purchase multiple certificates.
Keep in mind that SAN certificates can be more difficult to deploy than normal X.509 certificates and that some legacy firewalls do not support the use of SAN certificates. For example, ISA Server did not support SAN certificates until Microsoft released ISA Server 2006.
In some cases, using a wildcard certificate is a better option. A wildcard certificate lets you use a single certificate for your entire domain. The downside to wildcard certificates is that they are not compatible with Windows Mobile 5.0 devices.
Don't place a client access server at the network perimeter
Microsoft recommends that you do not place your client access server at the network perimeter. In fact, the only Exchange 2007 server role that Microsoft even supports at the network perimeter is the Edge Transport Server.
Even though the prospect of allowing Internet traffic into your private network is scary, Microsoft has a good reason for recommending that client access servers reside in the private network. The perimeter network is designed to protect your private network. A client access server requires access to Active Directory and mailbox servers. This means that if you place a client access server at the network perimeter, you must open several firewall ports to allow it to communicate with your private network. These open ports pose a serious security risk.
Does this mean that you should allow unfiltered Internet traffic to reach your private network? Hardly. Microsoft recommends placing an ISA Server at the network perimeter and allowing it to act as a proxy to your client access server. This solution lets you keep your client access server away from the network perimeter without allowing unfiltered Internet traffic to reach your private network.
Do use an edge transport server
The Edge Transport Server role is new to Exchange Server 2007. Its job is to sit at the network perimeter and filter out viruses and spam before they have a chance to reach your hub transport or mailbox server. Because Exchange 2007 doesn't require using an edge transport server, why deploy it?
Although deploying an edge transport server isn't required with Exchange 2007, it is a good idea. There are a number of third-party products and hosted filtering services that can eliminate spam and viruses. However, an edge transport server has a distinct advantage over other spam and virus filtering methods. An edge transport server is technically an Exchange server.
This means that, unlike most third-party filtering products and services, an edge transport server is aware of the recipients who have mailboxes on your mailbox servers. That's not only important for performance reasons, but also to help prevent denial of service (DoS) attacks.
For example, although my Exchange Server organization only has five mailboxes, I receive thousands of spam messages daily. While most of these messages are directed to me specifically, there are always some in which spammers have attached common user names to my domain name in hopes of reaching a valid mailbox.
Unless a filtering solution knows what the valid email addresses are for your organization, there's a good chance that invalid messages will make it to your hub transport server. The hub transport server then must spend valuable server resources processing the messages and sending non-delivery reports.
The best way to keep spam and viruses out of your organization is to use both a hosted filtering service and an edge transport server. The hosted filtering service will get rid of viruses and the majority of spam. That way, less spam will consume Internet bandwidth and email viruses will be kept off of the network. Once the majority of spam is gone, the edge transport server can examine the remaining messages in greater detail.
Do consider using Forefront Security for Exchange Server
I'm often asked which antivirus solution is best to protect an Exchange Server organization. That's not an easy recommendation to make.
Most antivirus products on the market protect against the same viruses. Any time a new antivirus product is released, all of the reputable vendors release a virus definition update to include the new viruses.
If you are shopping for an antivirus product for Exchange, these are the questions you should ask:
- How fast does the antivirus vendor publish virus definition updates?
- How well does the product work with Exchange Server?
When it comes to protecting other types of servers, I definitely have some antivirus product preferences. Some antivirus products just quarantine infected files, while others repair them. This isn't an issue with Exchange Server, however. There is no need to perform any repair work at the Exchange Server level; you only need to get rid of infected attachments before they make it to a user's mailbox.
My advice is to find a good Exchange-aware antivirus product to run on your Exchange servers, and then use a different antivirus product on workstations. If a new virus comes out and the product protecting Exchange hasn't received a virus signature yet, the workstation-level software may be able to detect and remove the virus at the client level.
This technique works well if your clients are running Microsoft Outlook, but it doesn't always work for Outlook Web Access (OWA) or Windows Mobile clients. That being the case, I recommend using Forefront Security for Exchange Server.
Forefront Security is a Microsoft product that licenses scanning engines from third-party antivirus companies. Since you never know which antivirus company is going to be the first to offer a signature for a new virus, using multiple scanning engines from multiple antivirus vendors greatly improves your chances of detecting and removing new types of viruses.
|ABOUT THE AUTHOR:|
Brien M. Posey, MCSE, is a five-time recipient of Microsoft's Most Valuable Professional award for his work with Exchange Server, Windows Server, Internet Information Services (IIS) and File Systems and Storage. He has served as CIO for a nationwide chain of hospitals and was once responsible for the Department of Information Management at Fort Knox. As a freelance technical writer, Brien has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal website at www.brienposey.com.
Do you have comments on this tip? Let us know.
Please let others know how useful this tip was via the rating scale below. Do you know a helpful Exchange Server, Microsoft Outlook or SharePoint tip, timesaver or workaround? Email the editors to talk about writing for SearchExchange.com.