Understanding Exchange Server Security Basics

When you are planning the procedures, technology, and precautions that you will implement to ensure better security for your Exchange server infrastructure, you should aim for a goal that we refer to as being "reasonably secure." This means you are taking precautions and implementing technology that is "at least" as good as the other companies in your own industry, and it will mean something entirely different to a small business that has no confidential or proprietary data in their mail system than it will to, for example, a health care provider.

Starting with the Obvious

Anyone experienced in fighting unauthorized intruders will tell you that malicious hackers usually attempt an attack by looking for the "low-hanging fruit." They look for known vulnerabilities and a weak defensive perimeter. So let's start with the more obvious security precautions and procedures. Many readers will look at this list and think it is painfully simple, but we find many organizations still miss the most basic points when securing their Exchange systems and even their networks.

• Your internal network should always be protected by a firewall. More on this later in this chapter.

• Physical server security is almost as important as firewall security. Ensure that servers are physically secured and in an environmentally controlled place. Backup media should be physically secured.

• No unnecessary Windows services, third-party software, or beta software should be installed on any Exchange server.

• Keep all operating systems and application software (Exchange included) up-to-date. You should plan to apply server-side critical security patches and updates within 4 to 6 weeks of release. In most situations, service packs should be applied within 8 to 12 weeks of release; this is dependent on verifying that no incompatibilities exist with current software or hardware.

• Administrator accounts (both local and domain) should be renamed and should have complex passwords assigned. The guest account should be disabled.

• Limit the membership the Administrators and Power Users groups to only absolutely necessary users. Limit the membership in Domain Admins, Enterprise Admins, and the domain's Administrators groups.

• Auditing and logging should be enabled on all Exchange servers. More information can be found on security logging and protocol logs in Chapter 21, "Logging, Auditing, and Monitoring."

• Administrative and operator accounts should not have mailboxes. Practice separation of administrative responsibilities from day-to-day tasks such as using e-mail, word processing applications, and so on.

• Do not install e-mail client software on your servers and do not use your servers to surf the Internet.

Thinking about Intruders

Almost all discussions of security, malicious hackers, and protecting your information infrastructure focus on protecting resources from being compromised from outside. While that will yield useful precautions and information for consideration, security violations do not always come from outside of your firewall. Employees and users from business partners may also be a source of data theft, data compromise, information leaks, and other security events. With that in mind, here are a few tips to consider:

• Enable mailbox logon diagnostic logging so that if necessary you can review who has accessed each mailbox.

• Network connections between business partners must be properly firewalled and audit. This not only protects your own information, it ensures accountability on the part of your own employees. Business partners should be provided with access to only the specific resources they require and nothing more. This is also true of resources that your own employees may need from your partner.

• Practice the principal of least permissions not only for administrators but also for users. Security group membership must be audited regularly to ensure that users do not have excessive rights and permissions.

Understanding Message Security Types

Messaging security can actually mean a lot of different things to different people. So let's quickly review the different types of security involved:

• Operating system and Exchange Server software security Securing and protecting the operating system and the Exchange Server applications (services) is probably what most people think about when they think about Exchange Server security. And that is what much of this chapter discusses. This encompasses ensuring that the attack surface of the operating system and Exchange services has been minimized. We do this by employing firewalls, operating system/application updates, good physical security, and solid administrative procedures.

• The security of e-mail data in transit Protecting e-mail data while the data is in transit usually involves some type of network encryption. This could be Secure Sockets Layer (SSL)/Transport Layer Security (TLS) or IP security (IPSec). We protect data in transit if we are concerned about the physical layer of our network (or the networks on which e-mail traffic crosses) being compromised and allowing someone to perform protocol analysis. The Outlook client can implement built-in encryption and encrypt message traffic between the client and a Mailbox server. Implementing HTTPS on Client Access servers ensures that web clients (such as Outlook Web Access, Windows Mobile ActiveSync, or Outlook Anywhere) transmit data securely.

• The security of e-mail data at rest Most of the time, e-mail data is at rest. E-mail is in the sender's Sent Items box, in a message queue, or in the recipient's Inbox. The message data may be moved in to an archival system or copied out to a personal store (PST) file. Protecting e-mail data at rest involves encrypting the data so that only authorized recipients can open a message. Technologies that can provide message encryption include Secure Multipurpose Internet Mail Extensions (S/MIME) and enterprise rights management (ERM) or digital rights management (DRM) technologies.

Protecting Your Firewall

The Internet can be a dangerous place: worms, 'bots, malicious hackers, script kiddies, and reality TV streaming video. Organizations that own public IP addresses often see dozens of attacks or probes against those IP addresses every day; these probes are often just someone (well an automated program) looking for a known vulnerability that they can exploit. Some organizations see attacks directed against their resources from a malicious hacker who is intentionally trying to do the organization or its data harm.

Something has to provide a layer of protection against these types of attacks. The firewall is a device that sits between an external network (an untrusted network) and a private or trusted network. In medium and larger organizations, actual management of the organization's firewall is outside of the e-mail administrator's area of responsibility. Oftentimes even in small organizations the firewall is managed by someone else. However, as an e-mail administrator, your servers are responsible for receiving SMTP mail from the Internet, sending SMTP mail to the Internet, and possibly receiving inbound traffic from HTTP/HTTPS clients. So you need to be able to converse effectively with the people who will provide the necessary access. If this is all "old hat" to you, then please skip on to the next section.

Figure 20.1 shows a simple Exchange 2007 deployment that is protected by a firewall. This organization is protected by an external firewall and an internal firewall. The network that sits between them is the perimeter network or the demilitarized zone (DMZ) network. The perimeter network is intended for servers that you must protect to some degree, but you do not want the traffic intended for those servers to be coming directly into your internal network. In this diagram, we are showing two separate firewalls, but this is a conceptual diagram. Some organizations will have both an internal firewall and an external firewall, while others will have a single firewall that provides internal, external, and perimeter network ports.

Figure 20.1: Typical firewall deployment protecting Exchange Server 2007

In this deployment, inbound SMTP (TCP port 25) mail from the Internet hits the firewall. The external firewall sees that TCP port 25 is permitted, but only for certain internal IP addresses. The inbound SMTP traffic is then directed to the internal firewall, where possibly a second set of restrictions or access lists (often called rules or an access control list) is consulted. The internal firewall allows inbound SMTP, but only to the Exchange 2007 Hub Transport server.

The same would happen for inbound HTTPS traffic (TCP port 443) that comes from Outlook Web Access, Windows Mobile ActiveSync clients, and Outlook Anywhere clients. The external and internal firewalls determine that TCP port 443 is permitted, but only to the internal Exchange 2007 Client Access server.

Tip 

A very common question is whether or not the Exchange Client Access and Hub Transport server roles should be placed in the perimeter network. No, the Hub Transport and Client Access server roles should not be placed in the perimeter network. Neither Microsoft nor any reputable Exchange expert will advise you to do this. If you are advised to do this, get a second opinion.

Any other types of traffic that hits the firewall would not be allowed even to the perimeter network. Figure 20.1 showed a very simple example; most organizations' firewall configurations are far more complex. You may also be publishing more than one or two applications. Table 20.1 shows some of the typical ports that may be required on different Exchange server roles.

Table 20.1: Typical Ports Required by Exchange Applications
Open table as spreadsheet

Application	Port	Exchange Server role
SMTP	25	Hub Transport server
SMTP w/TLS	25	Hub Transport server
HTTP	80	Client Access server
POP	110	Client Access server
IMAP4	143	Client Access server
HTTPS (HTTP with SSL)	443	Client Access server
POP3 with SSL	995	Client Access server
IMAP4 with SSL	993	Client Access server

While Table 20.1 does list some ports that are not encrypted (such as HTTP, POP3, and IMAP4), we do not recommend that these ports be opened. We recommend all Internet applications use SSL ports to protect logon credentials and data. We have intentionally left out LDAP ports since this would require that LDAP be opened to Active Directory domain controllers or global catalog servers; we do not recommend exposing any Active Directory services directly to the Internet.

Provided your Windows and Exchange servers are up-to-date on patches and you have taken reasonable measures to lock down your server configuration, the configuration shown in Figure 20.1 should provide reasonably good security. However, we will discuss the use of SMTP relay hosts (and the use of the Edge Transport server role) as well as reverse proxy servers to provide even better security for Exchange servers that are exposed to the Internet.