Tip

Built-in security tools help defend Exchange Server 2010

Securing Exchange Server 2010 is a process that involves making key decisions that can negatively affect access to features and ease of use. Exchange administrators are often seen as the bad guy for doing the right things -- security-wise -- for the organization.

There's good news for administrators; Exchange Server 2010 is more secure and feature-rich out-of-the-box than its predecessors. This tip introduces some major security vulnerabilities of Exchange 2010 and how the server can protect itself against them.

Transport security in Exchange 2010

The SMTP protocol is the first challenge to Exchange 2010 security. SMTP is vulnerable to snooping since SMTP is an extremely open protocol that sends information in clear text.

Self-signed certificates are used in Exchange 2010 to enhance SMTP security. By default, the hub transport role leverages self-signed certificates to encrypt communications between transport servers within the organization, with no additional administrative intervention (Figure 1).

    Requires Free Membership to View


Figure 1. An example of a self-signed certificate in Exchange Server 2010.

External-facing transport servers use opportunistic transport layer security (TLS) when connecting to remote SMTP hosts. This allows them to send encrypted communications outbound if the remote server has a trusted certificate. Administrators can also enable domain security for partner SMTP domains for mutual TLS encryption (Figure 2).

Organizations that require encryption for regulatory compliance purposes like HIPAA can benefit from this feature. When an edge transport server role is introduced, an additional layer of security becomes available to the organization when external connectivity is limited to the perimeter network.


Figure 2. The mutual TLS setting has been checked on the Send connector in Exchange 2010.

Protecting Exchange 2010 users from spoofing

Another potential vulnerability is the fact that messages sent with SMTP can be easily manipulated. One way that a message can be manipulated that could have disastrous consequences is spoofing.

Spoofing is the process of pretending to be someone you are not in an email message. In many cases, the recipient of a spoofed message does not identify that the message didn't originate from the actual sender. A great example of this is when you receive an email from yourself advertising the latest get-rich-quick scheme.


Figure 3. Here's an example of telnet spoofing analysis in Exchange 2010.

Secure Multipurpose Internet Mail Extension (S/MIME) certificates can protect Exchange organizations from email address spoofing. S/MIME certificates let users digitally sign a message that they are sending. If the recipient trusts the certificate authority that issued the certificate, he can verify that the person in the From: field is, in fact, the same person who sent the message. Outlook 2010 and Outlook Web App (OWA) clients both support S/MIME

You can also use S/MIME certificates to encrypt the actual messages that users send to one another. S/MIME requires an organization to invest in a public key infrastructure (PKI) solution. Leveraging Active Directory Group Policy and Exchange Server 2010 can facilitate S/MIME deployment.


Figure 4. Group policy object for distributing certificates in Exchange 2010.

Exchange Server 2010 and Active Directory integration

The latest addition to the message security feature set is the tight integration between Exchange Server 2010 and Active Directory Rights Management Services (AD RMS). If an organization introduces AD RMS, administrators can use it to enforce compliance for security policies.

An example of this might include encrypting email messages as they're sent between certain individuals in an organization. AD RMS is better than S/MIME because it enables Exchange 2010 transport servers to decrypt messages, scan for viruses that may be attached and then securely deliver the messages to the target recipients (Figure 5).


Figure 5. Active Directory Rights Management Services have been applied to this message.

Role Based Access Control (RBAC) in Exchange 2010

Microsoft creates 11 native universal security role groups when Exchange Server 2010 is deployed; these groups are granted explicit management roles. You can customize the management roles -- there are just over 60 built-in roles to choose from -- for these role groups. You can also create your own custom role groups and management roles to match your specific security model.

Microsoft removed the ability to delegate within the Exchange Management Console (EMC). Delegation now occurs using membership changes made to built-in role groups as well as any custom management roles groups that you create from Active Directory Users and Computer (Figure 6) or from the Exchange Management Shell (EMS).


Figure 6. Here are some built-in role groups in Exchange Server 2010.

Client access server vulnerabilities

Much like transport servers, Client access server (CAS) roles are often Internet-facing. There are a variety of Internet protocols that can be used to access users' mailboxes, which makes the CAS role vulnerable. Protocols such as HTTP (OWA/ActiveSync/Outlook Anywhere), IMAP4 and POP3 each have potential vulnerabilities. However, similar to SMTP, they can be protected with certificates.

The CAS role cannot use self-signed certificates without making users aware that they're not from a trusted certificate authority . Additional certificates from trusted CAs must be obtained for the CAS servers.

Exchange Server 2010 includes a new Certificate Wizard (Figure 7) in the EMC that simplifies the request-and-import process. With an increasing dependence on certificates for security, it's nice to have assistance to ensure that all potential vulnerabilities are being accounted for as new certificate requests are generated. It's also helpful that you don't need to use the Exchange Management Shell.


Figure 7. The Exchange Server 2010 Certificate Wizard.

Protecting Exchange Server 2010 with ForeFront

Just as an edge transport server creates an additional layer of protection for SMTP communication, there needs to be an equivalent protection for HTTP, IMAP4 and POP3 connections. To provide protection, an application layer firewall becomes a reverse proxy for the applications that use these protocols.</ p>

Microsoft strongly recommends using an application firewall and provides two related products, both of which are next-generation ISA servers that can protect the CAS roles in the perimeter network.

Forefront Protection for Exchange 2010 (FPE) is the latest Microsoft technology you can use to protect your organization from spam, viruses, phishing and other security issues. You can deploy FPE on the edge, hub and mailbox server roles on-premise; you can also use Forefront Online Protection for Exchange 2010 (FOPE) in the cloud, in addition to on-premise protection.

Richard Luckett is the President of SYSTMS of NY Inc. Richard is a Microsoft Certified Trainer with more than ten years Exchange Server instructional experience. He is a three-time Exchange MVP. Richard is an accomplished author and speaker who authored "Administering Exchange 2000 Server" and "The Complete Reference: Microsoft Exchange 2007 SP1" both by McGraw-Hill. He is also the course director of seven best-selling Exchange courses for Global Knowledge, Inc.

This was first published in July 2010

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.