Secure Messaging Architecture and Deployment Considerations

What is the best placement of Exchange servers, front-end servers, and domain controllers on a network?

Since the release of Exchange 2000 and the concept of front-end and back-end servers was introduced, there has been much discussion about the placement of these servers such that remote users can access their email services. After all, the front-end server is essentially nothing more than a Simple Mail Transfer Protocol (SMTP) and Hyper Text Transfer Protocol (HTTP) "pass through" server, and the obvious place to put this server is a screened subnet (aka the perimeter network or a demilitarized zone—DMZ). Even some organizations' written security policies state that all Web services accessed by external resources must be in the DMZ.

The intent of the DMZ network is to provide a place where resources (such as a Web server or a mail relay server) can be accessed by users outside of your network. Servers sitting in a DMZ should have no critical or sensitive data on them; thus, if they are compromised, the loss of data or service is minimized. However, this can give network security people a false sense of security.

The Old Way

When Exchange 2000 was first released, many Exchange gurus as well as Microsoft recommended placing the Exchange front-end servers in the DMZ and then place the Exchange back-end servers and the domain controllers on the internal network. This architecture is illustrated in Figure 3.1. In Figure 3.1, the front-end server sits in the DMZ and specifically allows Outlook Web Access (OWA) clients using Secure Socket Layer (SSL) to connect to the front-end server; the front-end server then passes the OWA clients' requests to the back-end servers on the internal network. If only it were that simple, though; a number of additional ports must be opened.

Figure 3.1: Traditional way of thinking about front-end and back-end server placement on the network.

Over the years, a number of weaknesses have been found in the architecture that Figure 3.1 shows. Front-end servers must be domain members and have the ability to communicate with all back-end Exchange servers as domain controllers and DNS servers. The following ports will need to be opened between the Exchange front-end servers and the domain controllers that the Exchange server will be configured to use:

• User Datagram Protocol (UDP) and Transmission Control Protocol (TCP) port 53 (DNS, if DNS is on the domain controller)
• UDP and TCP port 88 (Kerberos)
• TCP port 135 (Remote Procedure Calls—RPCs)
• TCP port 389 (Lightweight Directory Access Protocol—LDAP)
• TCP port 3268 (LDAP for Global Catalog—GC)
• TCP port above 1024 for RPC communication

The following ports may need to be opened between the Exchange front-end server and all backend Exchange servers:

• TCP port 25 if front-end server is used for SMTP
• TCP port 80 if front-end server is used for OWA/ActiveSync
• TCP port 110 if front-end server is used for Post Office Protocol 3 (POP3)
• TCP port 143 if front-end server is used for Internet Messaging Access Protocol 4 (IMAP4)
• TCP port 691 for link state

Exchange can be configured to use specific domain controllers on the internal network by configuring the domain controllers to be used on the properties of each Exchange server's directory access property page (see Figure 3.2).

Figure 3.2: Configuring an Exchange server to use specific domain controllers.

Thus, TCP and UDP ports must be opened between the front-end servers and domain controllers for Kerberos, LDAP, and RPCs. The port that must be opened above 1024 to the domain controllers/GC servers is a dynamic port that may be different each time a domain controller is rebooted. You can avoid opening the ports above 1024 by statically mapping the RPC port for domain controller services to a specific port on the domain controller/GC servers. To do so, create a registry value called TCP/IP Port in the

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters registry key.

Set this registry value to some value up to 5000; I usually pick a standard value for all my domain controllers that is just below 5000. Microsoft recommends the port be below 5000 in Microsoft article 298369 "How to Configure a Global Catalog Server to Use a Specific Port When Servicing MAPI Clients." You can find out more about static port mappings that are used with Exchange and domain controllers in Microsoft article 270836 "Exchange Server Static Port Mappings."

As many network administrators have found, this approach is often difficult to configure. In addition, this approach does not necessarily provide any better security than if the front-end server resided directly on the internal network. The reason is that a large number of ports to critical services must be opened between the front-end servers in the DMZ and domain controllers and Exchange servers on the internal network. If a front-end server is compromised, the compromised front-end server has almost unfettered access to the domain controllers and Exchange servers.

Using Internet Protocol Security (IPSec) can reduce the number of ports that have to be opened between the front-end server in the DMZ and the servers in the internal network. The following UDP and IP protocols must be opened in the firewall to allow IPSec to function through the firewall:

• UDP port 500 for Internet Key Exchange (IKE)
• IP protocol ID 50 for Encapsulating Security Protocol (ESP)
• IP protocol ID 51 for Authentication Header (AH)

However, the IPSec policy must be tightly and precisely configured so that only necessary hosts and services are accessible by the hosts in the DMZ; otherwise, you will have a bigger security problem than you did with the additional ports opened. Thus, Microsoft and most Exchange system designers recommend against putting Exchange servers into the DMZ network.

Improving Security for Front-End Servers

The approach that is recommended by Microsoft for placement of front-end servers and improving Exchange security for servers that must be accessed via Internet clients calls for all Exchange servers to be placed on the internal network. Figure 3.3 shows an example of a network that has implemented this approach.

Figure 3.3: Moving the front-end servers to the internal network.

The approach illustrated in Figure 3.3 works well for any Web publishing solution, not just for Exchange servers. By using a solution that is capable of Web server publishing (or reverse proxy), the actual servers can be safely located on the internal network. The only host to which the client must have access is the server that handles the reverse proxy functions.

In the solution that Figure 3.3 shows, a Microsoft ISA server is placed in the DMZ. The only port necessary to be opened from the outside is port 443 (HTTPS). The ISA server accepts the inbound HTTPS requests, decrypts the request, examines the URL, determines the correct server to pass the HTTP data on to and the validity of the data, optionally re-encrypts the data, and passes it on to the internal front-end server. This solution can be put into place even if the solution you use as a reverse proxy server is not your primary firewall solution.

What is the best protection method for Internet clients?

It is a popular misconception that email or Web traffic can be easily intercepted when traveling from mail server to mail server or from a browser client to a Web server. For someone interested in compromising your messaging data during data transmission, they have to be sitting in the path of the IP datagrams. Although this does occur, the intruder must have network monitoring equipment either on the client's network, the server's network, your corporate network infrastructure, or at an ISP that provides the Internet connectivity. Consequently, this does not happen very frequently, and people that want to intercept sensitive data such as credit card data or other information have to resort to schemes such as phishing or social engineering.

Encrypting the data stream between a client and a server does not mean that the data is also encrypted when it is stored on the server or at the client.

Protecting your messaging data during transmission is still important in order to provide an additional layer of security. This is certainly true if your corporate information crosses public networks or networks to which you do not have control of the physical access to the network media. For some organizations, such as those affected by regulations such as the Health Insurance Portability and Accountability Act (HIPAA), an organization may be bound by law to encrypt some types of data.

Data encryption on your network may be required if you must meet certain regulatory requirements.

As an experienced network or messaging administrator can tell you, if someone manages to access the network infrastructure through which your messaging data passes, it is a very simple matter to intercept clear-text data that is transmitted by protocols such as HTTP, POP3, IMAP4, and SMTP. Even intercepting user names and passwords can be deceptively simple. On first glance, the Outlook Web Access (OWA) logon session that Figure 3.4 shows appears to be secure.

Figure 3.4: Capturing basic authentication credentials

The HTTP header authorization identifies the authentication method as basic authentication. The authorization string is dm9sY2Fub3N1cmZiXGNrYW1peWE6JHVwZXIkZWNyZXQxMjM=.

This is not an encrypted authentication string, but simply encoded using Base64 encoding. Decoding this string shows the string: volcanosurfb\ckamiya:$uper$ecret123. The user's domain name is volcanosurfb, the account is ckamiya, and the password is $uper$ecret123. A good password compromised by basic authentication.

Outlook Clients and Remote Procedure Calls

Connecting directly to an Exchange Server system using an Outlook client over the Internet is not the most common configuration. Remote Outlook clients usually use either a VPN connection or Remote Procedure Calls (RPCs) over HTTP; however, many organizations still use a standard RPC connection to connect to an Exchange Server remotely. Although RPCs are not easily readable using network or protocol monitoring tools, the data can still be captured and decoded by a skilled person.

Outlook and Exchange Server can take advantage of the built-in encryption capabilities provided by the Windows RPC functions. For client-server communication, this functionality is not enabled by default, but it can easily be turned on via the Outlook profile. On the Security property page (see Figure 3.5) of the Microsoft Exchange Server connection properties, simply select the Encrypt data between Microsoft Office Outlook and Microsoft Exchange Server check box. When Outlook is restarted, all RPC traffic between Outlook and the Exchange Server will be encrypted using 128-bit streaming encryption.

Figure 3.5: Enabling Outlook-to-Exchange encryption.

Enabling Outlook RPC encryption is a good idea if you are concerned about messaging data being captured and viewed within your organization's network.

SSL Clients

For POP3, IMAP4, OWA, ActiveSync, and RPC over HTTP clients, using Secure Sockets Layer (SSL) is the best approach to protecting the messaging data being transmitted over the network. SSL is an application-layer technology that provides encryption for client-server applications that do not handle encryption themselves. SSL was originally developed by Netscape, but it has become a de facto standard for client-to-server security for Web applications.

The most common application of SSL is found with Web browsers communicating with a Web server and can be identified when the URL is preceded by an HTTPS rather than just HTTP. However, this technology can be extended to other TCP/IP applications including POP3 or IMAP4 clients.

Enabling SSL requires a certificate be installed on the server. For HTTP-based applications, this certificate is installed using the Internet Information Services administrator program. Installing the certificate through IIS Admin allows OWA, ActiveSync, and RPC over HTTP client traffic to use SSL because all three of these functions use the Web server. To protect POP3 or IMAP4 clients, the same certificate can be used; simply export a copy of the certificate using IIS Admin, then import it for the POP3 or IMAP4 virtual server using Exchange System Manager. As long as the fully qualified domain name (FQDN) being used for the HTTP certificate does not change for POP3 or IMAP4 clients, the certificate will remain valid.

Certificates and a Trusted Issuing Authority

Generating a certificate is deceptively easy. For an experienced Windows administrator, this task is as simple as installing the Microsoft Certificate Server and then requesting and issuing as many certificates as you please. Most small and midsized organizations have neither the resources nor the time to plan and correctly implement a certificate authority (CA) infrastructure; thus, at least for limited certificate issuance, they should consider using a trusted authority.

Browser clients will not "trust" certificates issued by an unknown CA because the browser does not have the issuing server's certificate. A Web browser client will receive a pop-up similar to the one in Figure 3.6 indicating that the certificate was issued by a company you have chosen not to trust.

Figure 3.6: When a certificate is issued by an unknown certificate authority, an alert pops up.

If you simply click Yes in the Security Alert dialog box, the SSL connection will be established anyway. At least this works for Web applications; for Outlook using RPC over HTTP, the connection will not be established and there will be no warning.

See Microsoft Knowledge Base article 555261 "To use Outlook 2003 RPC over HTTPS your client PCs must trust the root certificate" for more information.

This problem can be remedied by installing the issuing certificate server's certificate as a trusted issuing authority on any client that may establish an SSL session using a certificate issued by that server. This is not difficult to do internally because trusted certificates can be deployed to all computers through a Group Policy Object (GPO) or other automated means. However, if the certificate is used by external clients, they must install the certificate on the computer on which they are currently working.

Of course, Web browser clients can be told simply to ignore the Security Alert, click Yes, and continue. This practice is not a good idea—asking your users to get into the habit of ignoring security warnings will sooner or later lead them to ignore a valid warning.

There are several CAs on the Internet that are trusted by most browser clients. In Internet Explorer (IE), you can view a list of the Trusted Root Certification Authorities and the Intermediate Certification Authorities by selecting Tools, Internet Options, Content, Certificates.

In the Certificates dialog box, which Figure 3.7 shows, you can see a list of the Trusted Root Certification Authorities and the Intermediate Certification Authorities. For Windows power users, you can see the same list using the Certificates management console.

Figure 3.7: Trusted Root Certification Authorities in IE.

Getting a certificate that is issued by a trusted authority is pretty simple. Simply generate a certificate signing request (CSR) using IIS Admin and send it to the CA of your choice. For certificates that are widely trusted and provide better liability protection (such as for e-commerce sites), authorities such as VeriSign and Thawte are a good choice. If you simply need to provide SSL for data protection, though, there are a number of lower-cost alternatives including InstantSSL/Comodo and GoDaddy.

Messaging Data Protection Moving Forward

As mentioned earlier, just because the data stream of an email message is encrypted on the network using technologies such as SSL/TLS, IPSec, or RPC encryption, it does not mean that the data is completely secure or that the person that currently has possession of the data cannot forward it to unauthorized users. Regulatory requirements for data protection are often vague on exactly what is required to protect information. HIPAA, for example, states that "reasonable and appropriate" measures be taken to address privacy, security and business policies, and requirements of protected health information (PHI).

However, HIPAA does not provide technical guidance on what those "reasonable and appropriate" measures are. In order to take "reasonable and appropriate" measures, some organizations simply filter any outbound messages containing PHI that might leave their organization. Others are implementing SSL/TLS connections between SMTP servers. Ultimately, though, to ensure that PHI is completely protected and to do due diligence, technologies such as S/MIME (PKI) and Enterprise Rights Management (ERM) should be investigated.

Is there a way to guarantee a sender's identity?

The Simple Mail Transfer Protocol (SMTP) was designed to be open and very simple. The original standard for the protocol provided for no security or authenticity mechanisms. Even as the SMTP standard has evolved to meet modern messaging needs, mechanisms for ensuring the identity of senders have remained elusive.

Businesses increasingly rely on email to share business-critical information, yet that very information is easily spoofed and falsified. Figure 3.8 shows a message that was easily spoofed using a POP3 mail client. There are few clues in this message that a typical end user can use to determine whether the message is authentic and came from the purported sender.

Figure 3.8: A spoofed message.

Phishing schemes, easily spoofed messages, and massive amounts of spam that arrive in users' mailboxes have only contributed to the erosion of faith in the authenticity of the source of many of the messages. For example, to reduce the likelihood that any customers succumb to a phishing scheme, many banks have announced on their Web sites that they will never send announcements or news email messages to customers and thus customers should not respond to any message that might appear to be from them. By doing so, the banks have denied themselves a very efficient mechanism for communicating with their customers.

All SMTP email between two Exchange Server systems in the same Exchange organization is automatically authenticated.

There are a couple of mechanisms that can be used to provide varying levels of authentication for messages that arrive within your organization. These include requiring SMTP authentication, employing whitelisting systems, using Sender ID, and implementing S/MIME digital signatures.

SMTP Authentication

The most modern of SMTP systems include an authentication mechanism—the enhanced SMTP (ESMTP) verb AUTH. The AUTH verb allows an SMTP client system (the sender) to authenticate to the SMTP server. However, this setup requires that credentials be created for each organization that is going to send you mail, and their servers would have to be configured to use these credentials. Although configuring SMTP authentication is simple to do, it is not practical except in situations in which you are communicating with the same SMTP servers all the time (such as business partners or other SMTP systems within your organization).

SMTP authentication is not practical for large numbers of domains to which you must send authenticated mail, as it require a lot of administrative attention to configure and maintain (such as changing passwords that must be reset).

Configuring SMTP authentication is simple using a mail system such as Exchange 2000 or Exchange 2003. To illustrate, let's review a simple example of how this would work. Suppose an organization needs to send mail to a remote organization, and the connection is authenticated. The sending organization is Volcano Surfboards (volcanosurfboards.com) and the receiving organization's domain is Somorita Surfboards (somorita.com); the administrators at somorita.com have created a username and password for the Volcano Surfboards mail server.

The mail administrator at Volcano Surfboards needs to create an SMTP Connector that will be used by the mail destined for somorita.com. Most administrators are used to creating an SMTP Connector whose scope is *, which means that it will deliver outbound mail to all domains. To limit the scope of this connector so that it delivers mail only for somorita.com, a custom SMTP address space is defined on the SMTP Connector. This is shown in Figure 3.9.

Figure 3.9: Configuring a specific address space.

Once the scope of the SMTP Connector is limited to send mail only to the somorita.com domain, the authentication options can be configured. On the Advanced property page of the SMTP Connector, the Outbound Security button lets you configure the authentication mechanism. The Outbound Security property page is shown in Figure 3.10. The default setting for outbound security is anonymous access. Basic authentication will be the most common option because this setting will work with most any SMTP server that supports authentication including other Exchange Servers.

Figure 3.10: Defining SMTP authentication.

If you are using basic authentication, you should select the TLS Encryption check box because basic authentication sends the user name and password in clear text. Using TLS Encryption will require that the remote SMTP server have a certificate installed and configured for its SMTP server. The Integrated Windows Authentication option will only work when selecting user accounts that are located in your Active Directory (AD) forest or with an AD forest to which you have a trust relationship. Unfortunately, users have no simple way to verify that messages were received from an SMTP connection that is authenticated.

Whitelisting

Whitelisting is a technology that is normally used to fight spam but allows you to create a list of authorized recipients and thus can also help ensure that the threat from bulk phishing schemes is reduced. Figure 3.11 shows how a whitelisting system might function either when provided by a managed provider or by some type of SMTP-based system in the organization's DMZ.

Figure 3.11: Using a whitelisting service.

In the example in Figure 3.11, a sender on the Internet sends a message to a recipient that is protected by a whitelisting service. The whitelisting service could either be in the form of a managed provider such as FrontBridge or Spam Arrest or it could be an appliance or SMTP system in the organization's DMZ such as a Sendio appliance. The whitelisting service has a database of authorized senders; this database can be pre-populated by the users or IT department of the organization being protected.

If the sender is not on the whitelist, the service sends back a challenge to the sender. The sender must do something to confirm their identity such as connect to a Web page, reply to the message, or enter an authentication code. Once the sender has authenticated, some services and software packages will still require the recipient to validate the sender as authentic. When the user is authenticated, the whitelisting service adds that sender's email address to its database of authenticated users, then passes messages through to the recipient's mailbox server. If you place a whitelisting service in front of your mailbox servers, you decrease the likelihood that bulk spamming or phishing attacks will affect your user community, but a practical joke or an intentional deception such as the one shown earlier is still possible.

Sender ID

Sender ID is one of the email industry's attempts at reducing spam and validating that a message has indeed been received by its intended recipient. Specifically, Sender ID is part of the Coordinated Spam Reduction Initiative, which is intended to reduce spam and to make spoofing a message more difficult. An SMTP server that has Sender ID enabled essentially evaluates the sender of the message, the SMTP server from which the message was received, and a list of SMTP servers that are authorized to send messages for the sender's domain. The message is evaluated and ranked into one of three categories:

• The sending SMTP server is on the authorized list of SMTP servers
• The sending SMTP server is not on the list of authorized SMTP servers
• The SMTP domain from which the message originated does not have a list of authorized servers

Based on these categories, the receiving SMTP system can reject the message or pass the category on to the end user or an anti-spam system for further processing. Although this process might sound simple, there is quite a bit more to it than you would first think. And even if you don't implement Sender ID on your own SMTP servers, you should still identify your authorized SMTP servers so that other organizations implementing Sender ID won't incorrectly reject or quarantine mail from your servers.

DNS and SPF Records

To identify a list of authorized servers for a specific domain, a receiving SMTP server must check somewhere for a list of authorized SMTP servers for that domain. The list of authorized servers is published for that domain using DNS in the form of Sender Policy Framework (SPF) resource records. The SPF record contains a list of the IP addresses from which your organization will transmit email to the Internet.

Creating SPF records requires knowledge of exactly which servers send mail on behalf of your domain. This includes smart hosts and managed provider SMTP servers.

Microsoft has created a Web-based wizard that will verify the existence of an SPF resource record, lookup your organization's MX records and A records for your domain, and take you through the necessary steps to create an SPF record for any domain and any type of mail system.

You can find this wizard on the Internet at http://www.anti-spamtools.org.

The following scenario outlines a very simple example of how to do so for a domain called somorita.com. In this example, somorita.com has only a single outbound SMTP server. This SMTP server is the same server that is used for inbound and outbound mail. In the third step of the Sender ID Framework SPF Record Wizard, you simply need to select the Domain's inbound servers may send mail check box and verify that the host name that was read from the MX record is correct (see Figure 3.12).

Figure 3.12: Creating a simple SPF resource record.

On the fourth page of the wizard, it creates a simple text string shown here:

v=spf1 mx mx:serenity.dnsalias.com ~all

The DNS administrator for this domain must then create a DNS TXT record for the somorita.com domain. In this example, the same SMTP server is used for sending mail as is used for receiving mail.

In a more complex example, an organization called volcanosurfboards.com needs to create an SMTP record. Figure 3.13 shows this slightly more complex environment; this organization has two servers internally that can originate SMTP mail to the Internet, and they use a managed provider through which outbound mail is normally delivered. Their SMTP servers are configured to send mail directly to the recipient if the managed provider is down.

Figure 3.13: Creating SPF records for a slightly more complex organization.

The two servers on the inside of the network that are allowed to send internal mail have IP addresses of 192.168.254.10 and 192.168.254.12. These are different than the IP addresses that are in the organization's MX records.

The managed provider provides the IP addresses of their outbound mail servers; those are

131.107.2.201, 131.107.2.202, and 131.107.2.203. Using the Sender ID Framework SPF Record Wizard, the IP addresses of the individual outbound mail servers are defined in step 3 of the wizard. This is shown in Figure 3.14.

Figure 3.14: Assigning specific IP addresses for outbound SMTP mail servers.

The Sender ID Framework SPF Record Wizard creates a slightly more complex SPF record for volcanosurfboards.com. This record looks like this:

v=spf1 ip4:192.168.254.10 ip4:192.168.254.12 ip4:131.107.2.201 ip4:131.107.2.202 ip4:131.107.2.203 ~all

Defining the SPF records, even if the organization is not using Sender ID, will help other organizations to properly identify and authenticate the email coming from the organization's SMTP servers.

You can also check another organization's SPF records by simply using NSLOOKUP.EXE. The previous examples are still fairly simple and reflect what a smaller organization might have. For example, if I want to check the SPF records for aol.com, I would type

C:\>nslookup -q=txt aol.com

Server: kilauea1.volcanosurfboards.com

Address: 192.168.254.15

Non-authoritative answer:

aol.com text =

"v=spf1 ip4:152.163.225.0/24 ip4:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0/23 ip4:205.188.159.0/24 ip4:64.12.136.0/23 ip4:64.12.138.0/24 ptr:mx.aol.com ?all" aol.com text =

"spf2.0/pra ip4:152.163.225.0/24 ip4:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0

/23 ip4:205.188.159.0/24 ip4:64.12.136.0/23 ip4:64.12.138.0/24 ptr:mx.aol.com ?all"

In this example, you can see many IP addresses that have been entered in the form of IP subnets. An organization can also consolidate these records by using include statements such as the case of microsoft.com.

C:\>nslookup -q=txt microsoft.com

Server: kilauea1.volcanosurfboards.com

Address: 192.168.254.15

Non-authoritative answer: microsoft.com text =

"v=spf1 mx include:_spf-a.microsoft.com include:_spf-

b.microsoft.com ~all"

Determining the Purported Responsible Address

If you are implementing Sender ID on your SMTP servers, the first thing that your SMTP server that receives a message from the outside world has to do is to determine the responsible sender. The originating email address is known as the Purported Responsible Address (PRA); a more precise definition of the PRA is the email address that is most recently responsible for injecting the email message into the messaging system. The PRA must be determined before you can evaluate whether the message was sent from an SMTP server that is responsible for that domain.

If you already know something about SMTP, your first guess might be that the receiving SMTP server simply examines the inbound SMTP data stream and evaluates the RFC 2821 SMTP conversation. In this portion of the SMTP conversation, the sending SMTP system sends the MAIL FROM and RCPT TO verbs. A simple assumption is that the MAIL FROM verb would contain the valid identity of the sender and, in most cases, that assumption would be correct. However, for organizations that use smart hosts, mail forwarders, mailing lists, or alternate delivery addresses, this assumption does not hold true. Thus, the entire message must be first accepted so that the RFC 2822 portion of the message can be examined. Listing 3.1 shows an example of an SMTP header for a piece that ended up in the spam quarantine.

x-sender: bounce+OM_1641909368@mail.classmates.com x-receiver: lbullock@somorita.com

Received: from relay1.somorita.com ([131.107.2.200]) by mailserver.somorita.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Feb 2006 15:04:53 -1000

Received: from 65-243-133-26.classmates.com ([65.243.133.26]) by relay1.somorita.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Feb 2006 15:04:47 -1000

Received: from uurain01.sea2.cmates.com (unknown [10.10.142.201]) by 65-243-133-26.classmates.com (Postfix) with SMTP id 8ABFE30424 for <lbullock@somorita.com>; Mon, 20 Feb 2006 17:04:43 -0800 (PST)

From: Classmates <ClassmatesEmail@classmates.com>

To: lbullock@somorita.com

Subject: Lyle, you have 19 visits to your profile

Mime-Version: 1.0

Content-Type: multipart/alternative;

boundary=100839671140483883572.CmatesMail.classmates.com

Envelope-Sender: MAIL

Message-Id: <20060221010443.8ABFE30424@65-243-133-26.classmates.com>

Date: Mon, 20 Feb 2006 17:04:43 -0800 (PST)

Return-Path: bounce+OM_1641909368@mail.classmates.com

X-OriginalArrivalTime: 21 Feb 2006 01:04:48.0214 (UTC)

FILETIME=[CF88DF60:01C63682]

X-SCL: 7 89.02%

Listing 3.1: An example of an SMTP header for a piece that ended up in the spam quarantine.

The receiving SMTP system must examine the header of the RFC 2822 message and evaluate the different fields that may indicate the sender's email address. The following RFC 2822 headers are used in this order to determine the PRA:

• Resent-Sender
• Resent-From
• Sender
• From

If these fields are not found in the RFC 2822 portion of the message, the Sender ID system will revert back to the original RFC 2822 MAIL FROM verb that was found in the original message transmission. In the RFC 2822 header that Listing 3.1 shows, the PRA of the message is ClassmatesEmail@classmates.com as determined by the From field in the header.

Validating the Sender's SMTP Server

Now that the purported recipient address of the message is determined, the Sender ID system can determine the SMTP server that was responsible for sending the message to your messaging system. The SMTP header contains all the SMTP hosts that have processed or relayed the message through the sender's organization, the Internet, and your internal network. From the previous example, the SMTP hops looks like this:

Received: from relay1.somorita.com ([131.107.2.200]) by mailserver.somorita.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Feb 2006 15:04:53 -1000

Received: from 65-243-133-26.classmates.com ([65.243.133.26]) by relay1.somorita.com with (Mirapoint Messaging Server MOS 3.3.2CR) with ESMTP id AGC33650; Mon, 20 Feb 2006 15:04:47 -1000

Received: from uurain01.sea2.cmates.com (unknown [10.10.142.201]) by 65-243-133-26.classmates.com (Postfix) with SMTP id 8ABFE30424 for <lbullock@somorita.com>; Mon, 20 Feb 2006 17:04:43 -0800

For this organization's Sender ID setup, they must configure all the IP addresses of their mail servers. This would include the IP addresses of any server that handles mail on their behalf, such as a mail relay host, SMTP bridgeheads, or managed providers. For Exchange 2003 SP2, this is configured on the General property page of the Message Delivery properties. Figure 3.15 shows the Sender ID and Connection Filter Configuration Settings for somorita.com.

Figure 3.15: Defining IP addresses that may relay SMTP mail internally.

Any SMTP header that contains one of the SMTP addresses shown as a source host will be considered internal and thus not an authorized sender for the message that is being analyzed. Thus, in this case, the first line SMTP header shown in the following example is considered internal because it was received by IP address 131.107.2.200 and that IP address is defined as one of the servers that handles incoming SMTP mail.

Received: from relay1.somorita.com ([131.107.2.200]) by mailserver.somorita.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Feb 2006 15:04:53 -1000

The next piece of host information is the following header:

Received: from 65-243-133-26.classmates.com ([65.243.133.26]) by relay1.somorita.com with (Mirapoint Messaging Server MOS 3.3.2CR) with ESMTP id AGC33650;

This was received from IP address 65.243.133.26. This IP address is not part of the internal mail delivery infrastructure and thus is considered the source address for this message. A quick NSLOOKUP of the sender's domain (classmates.com) shows that they do indeed have SPF records for their hosts. Thus, the Sender ID system will rank this message as being from a validated sender. Ironically, the message was spam, but many organizations that consider themselves "reputable Internet marketers" do have SPF records.

There are several Sender ID status results that might come of the examination of the sending SMTP server and the PRA. Table 3.1 shows the possible results and what this may mean.

Table 3.1: Sender ID status results.

Successful validation of the PRA's Sender ID information will result in the message being ranked as less likely to be spam and failures will contribute to the ranking of the message as being a higher likelihood of being spam. Differing SMTP systems will let you analyze this information differently. Exchange Server does not add any information about the PRA or the Sender ID validation to the SMTP header, but that information is passed on to the Exchange Server and can be viewed with a custom view in Outlook. See http://tinyurl.com/ga6o8 for more information. Similarly, the SCL of messages can be viewed in the same way; see http://tinyurl.com/b2p5n for more information.

On an Exchange Server 2003 SP2 system, you can monitor the summary statistics in the Performance console by looking at the counters found in the MSExchange Sender ID object.

Figure 3.16 provides a sampling of these statistics.

Figure 3.16: Monitoring Sender ID validations.

Take note of the most common counter—Total Messages Validated with a None Result. This counter indicates that an SPF record was not found. This is due, in part, to the slow adoption of Sender ID and the fact that many mail systems administrators are simply not creating the necessary SPF records in DNS. In Figure 3.16 almost 80 percent of all the SPF record looks resulted in a record not being found. Clearly, rejecting or deleting inbound mail based on the lack of an SPF record would be a bad idea. However, even if you do not plan to implement Sender ID lookups on inbound mail, you should get your SPF DNS records published.

Digital Signatures

The most reliable and simplest way for a user to verify that a message sender is valid is to request that anyone sending your users' email that requires a higher degree of authenticity use S/MIME digital signatures. Implementing an S/MIME infrastructure for an organization allows users to encrypt sensitive message content and let the recipients of their messages know that the message content has not been altered and comes from the stated sender. The secure messaging system that allows sender verification should have the following characteristics:

• Message origin must be verifiable.
• Message integrity must be verifiable. If the message body or attachments were altered in transit, the user must be notified.
• Message sender must not be able to repudiate the message. A sender cannot later claim that they did not send the message.

Additionally, messages may be required to be private, meaning that only the intended recipient and the sender can view the message content. However, a secure messaging system based on S/MIME does not allow control of the content once an authorized recipient has the content in their possession. To keep the scope of this discussion focused, I will only be discussing the use of S/MIME for digital signatures.

S/MIME digital signatures provide the most reliable and simplest way for end users to verify the authenticity of SMTP mail. Most mail clients intended for business use support S/MIME. This does not, however, extend to Web mail services, which may simply strip out the digital signature.

For a small organization (less than a few hundred mailboxes), deploying an S/MIME solution is fairly simple because you can go to an organization such as Thawte to request a free Thawte Personal Mail certificate. For larger organizations, this will require deploying a public key infrastructure (PKI) that will be sufficient to meet your needs and at the same time be trusted by all your business partners that need to authenticate certificates that you have issued to your users, such as in the case of S/MIME signed email messages.

The Mechanics of Message Signing

On first impression, S/MIME digital signatures are almost indistinguishable from magic. The sender of the message merely clicks an icon or chooses a message option that creates a digitally signed message. The recipient opens a digitally signed message and has some indication on the message form that the message has not been altered and did indeed come from the sender. Figure 3.17 shows an example of a digitally signed message.

Figure 3.17: A digitally signed message.

The digitally signed message (when viewed from Outlook 2003) shows the SMTP address of the signer on the left side of the message above the message body, and on the right side shows a small red and yellow certificate icon. If the user clicks on the red and yellow certificate icon, the user can verify the digital signature.

If there is a problem with the digital signature (such as untrusted certification authority or an altered message), the red and white certificate icon is replaced with a warning that looks like a red exclamation mark on a yellow background. If the user clicks the warning icon, the user can view the Message Security properties (shown in Figure 3.18).

Figure 3.18: Displaying a broken message signature.

Notice in the description field of the Message Security properties in Figure 3.18, the signature indicates the message was signed by the correct SMTP address, but the error indicates that the message may have been altered in transit. The message alteration could be due to someone maliciously changing the message body or attachments after the sender clicked Send or might be due to an SMTP gateway or server process doing something such as appending a text disclaimer to the message after the message was signed.

So that you can appreciate the digital signature process, let's review how a digital signature is calculated and appended to a message. The sender must have an S/MIME certificate that contains a public key and must have a private key associated with the public key. In order for the certificate to be trusted by recipients outside of your organization, the certificate should be signed by a trusted certificate authority.

When the sender prepares a new message, if they have an S/MIME certificate installed on the machine and associated with their mail client, they should see a toolbar button or a message option that creates a digital signature, as Figure 3.19 shows.

Figure 2.19: Message toolbar that includes message signing and encrypting options.

The user merely clicks the Sign button or icon to assign a digital signature to the message. Depending on the configuration of the machine, the user may be asked to confirm that they are accessing the cryptography API or they may even be required to provide the password that is used to protect their private keys. After that is complete, the message is signed. So what happened when the button was clicked? The following list outlines the process:

• The mail client verifies that the sender has a digital certificate that allows message signing
• The mail client examines the message body and the attachments and calculates either a 160-bit SHA-1 (secure hashing algorithm) hash or a 128-bit MD5 (message digest) hash. The hash of the message cannot be reversed and if even a single bit of the original message is changed, the hash will be different.
• The mail client accesses the sender's private key and encrypts the message hash with the private key.
• The mail client attaches to the message the digital signature, which consists of the encrypted hash and the user's signing certificate (containing the public key).
• The message leaves the client computer and is sent through the message transport system.

This entire process (except for clicking Sign) is entirely transparent to the user. Once the hash is calculated for the message and is encrypted with the sender's public key, the hash cannot be recalculated because the only person that would be able to re-encrypt the hash is the owner of the private key.

Digital signatures are difficult to fake, but if the sender's private key (or the entire computer) is compromised, this is possible. When the recipient receives the signed message and opens it, the mail client automatically verifies the signature. If the message signature is not valid or the sender's certificate is not trusted, the recipient will receive some type of warning either in the message or via a pop-up warning. The following list offers a high-level view of what happens when the recipient opens a signed message:

• The mail client examines the message and determines that the message has been digitally signed. Based on the signing algorithm that was used when the message was signed (either SHA-1 or MD5), the message body and attachments are examined and the message hash is calculated.
• The mail client opens the sender's certificate and decrypts the public key with the hash that was calculated when the message was transmitted. Because the hash was encrypted with the sender's private key, the only key that can decrypt it is the public key.
• The mail client examines the sender's certificate to ensure that the sender of the message is the same as the certificate owner's SMTP address and that the certificate was signed by a trusted certificate authority.
• The mail client compares the hash of the message that it received with the hash of the message that was calculated when the message was transmitted.
• If the message hash is invalid, the sender's SMTP address is not correct, or if the certificate was issued by an untrusted authority, the user is warned.

Digital signatures apply to more than just email. There are some excellent tutorials on S/MIME and digital signatures. See http://tinyurl.com/zo5sl, http://tinyurl.com/fvwsm and http://tinyurl.com/h2fff for more information.

What are best practices to follow when deploying servers?

Good email security should start the day you take your hardware and software out of the box and start installing. Security should not be an afterthought once a server is in production. Good security and good operational practices go hand-in-hand, and the steps that you take during deployment will contribute to not only better security but also a more stable email server environment.

First and foremost, start with a server build checklist that includes steps that will help make the server more stable and more secure. Once the server operating system (OS) and the email server software is installed, have a checklist of procedures and best practices that you follow to ensure the software is installed properly and securely.

I have a four-layer model that I use for representing the path to stable, secure, and available server platforms. Each of the higher layers depends on the lower layers being built properly. If the lower layers are not built properly, you cannot expect the upper layers to provide reliable or secure services. The four layers are:

• Operational policies and procedures
• Application
• Operating system
• Server platform

Building a Solid Server Platform

The hardware and the OS are the base for solid operations and good security. Although each server's role may be different and the application software may be different, a consistent installation checklist provides the important first steps. The following checklist should be followed for all server builds. Although there are exceptions to many of these checkpoints, this is a good starting point:

• The server should be placed in a physically secured area with appropriate access and environmental controls (air conditioning and redundant power).
• Server hardware should be updated to have newer versions of the firmware/FlashBIOS, including updates for the system BIOS, disk controllers, host bus adapters (HBAs), tape drives, backplane firmware, and embedded systems management hardware. Newer versions does not always mean the most recent version, so consult with your hardware vendor to confirm the best versions of firmware for your particular environment and application. For Windows Server 2003 (WS2K3), take the default settings for the OS.
• Add only the necessary additional services or Windows components to support the application that will run on the server. Do not install unnecessary components.
• Obtain newer versions of the vendor's server installation CD-ROMs or disks. Confer with the vendor to ensure you are getting the best version for your environment and the application that the server will be supporting.
• Install the OS using the hardware vendor's installation procedures and disks.
• Apply the most recent OS service packs and critical updates for your server platform.
• Consult an automatic update service, such as Microsoft Update, to download the latest critical updates and notify the administrator that they are ready to apply.
• Install the WS2K3 Support Tools.
• Tune the virtual memory settings so that initial page file size is 1.5*RAM and the maximum file size is 2.0*RAM.
• Enable disk performance monitor counters (diskperf -y).
• Optimize the WS2K3 memory settings based on your intended application. For Exchange Server 2003, see Microsoft Knowledge Base article 815372 "How to optimize memory usage in Exchange Server 2003."
• Apply the appropriate baseline security template to the server based on your environment. Once the template is applied, test the server and its functions thoroughly before proceeding to ensure that the template has not broken a critical function that you require.
• Configure the Windows event log sizes, such as the following:
  • System log = 49,152KB
  • Security log = 49,152KB
  • Application = 196,608KB
• Install the application, such as Exchange Server 2003, and apply the most recent service pack and critical updates.
• Install antivirus software that supports the antivirus APIs provided by your mail server software, such as the Exchange antivirus application programming interface (AVAPI). Configure the antivirus software to update signatures between 4 and 12 times per day; doing so ensures that you check for updated virus signatures at least once every 6 hours and possibly as frequently as once every other hour.
• Disable any Windows services that you have determined are unnecessary for your organization.
• If your Exchange OWA is not protected by a reverse proxy server that can filter URLs and allow only specific virtual directories to access the Exchange Server, consider implementing the Urlscan utility. See Microsoft Knowledge Base article 823175 "Finetuning and known issues when you use the Urlscan utility in an Exchange 2003 environment" for more information. Keep in mind that Urlscan may disable a user's ability to open messages with special characters in the subject line.

Checking Your Work

After you have your server initially installed and configured, you can proceed to check your work and make sure you have not missed anything obvious or potentially harmful. For Windows and Exchange, Microsoft provides two simple-to-use tools for just this purpose—the Microsoft Baseline Security Analyzer 2.0 (MSBA) and the Exchange Server Best Practices Analyzer Tool (ExBPA).

The MSBA is a more generic tool that scans to determine whether critical updates are available for programs such as Windows, Internet Explorer (IE), Exchange, and Office as well as scans for vulnerabilities to well-known problems. When you run the MSBA, it connects to Microsoft and downloads the latest XML file it will used to scan for vulnerabilities and patch versions. The scan report includes information about what was scanned and how to correct potential problems. Figure 3.20 shows an MSBA report that was run against a WS2K3 member server supporting Exchange Server 2003.

Figure 3.20: Baseline Security Analyzer report.

The second tool that is helpful in isolating a poorly configured server is ExBPA. This tool is more targeted towards analyzing Exchange Servers but will look at some configuration items related to domain controller/Global Catalog (GC) configuration as it pertains to Exchange Server. The ExBPA uses WMI to collect information about one or more of your Exchange Servers and analyzes this against a database of best practices and configurations that is a result of the experience of the Exchange team as well as many consultants and Exchange experts. Regardless of how well you think your Exchange organization is configured, the ExBPA will probably find something you have not thought of.

When you first launch the ExBPA, it will want to download any updates to its XML database of best practices and will then need to connect to Active Directory (AD) to read your Exchange organizational structure. Figure 3.21 shows the initial screen of the ExBPA in which you are asked which Exchange Servers are to be analyzed and the type of scan to perform.

Figure 3.21: Starting an ExBPA scan.

Once you click the Start Scanning option on the main page, ExBPA will start scanning AD and the selected servers. This scan may take anywhere from a few minutes to a few hours depending on the number of Exchange Servers you have selected to scan and the network bandwidth between the scanning machine and the selected servers.

When the report is completed, you can sort the report based on a number of criteria. The default is the critical issues list, but I usually switch to the Full Issues List report so that I can list everything that the ExBPA found. The Full Issues List is shown in Figure 3.22. Each issue can be expanded to see information about what the recommended setting is and if you would like the ExBPA to skip that particular setting the next time it scans that server.

ExBPA reports might contain a considerable amount of information about your organization's internal infrastructure. Treat these reports as confidential and protect them accordingly.

A word of caution about these reports: the best practices recommendations are generic and don't take into consideration your organization's message flow rules or your business practices. For example, the report in Figure 3.22 recommends "Consider setting 'TarpitTime.'" However, in this organization, all inbound mail is routed through a managed provider and the organization's firewall only accepts inbound SMTP from the managed provider's SMTP servers. Thus, configuring an SMTP tarpit will not have any effect on the organization's messaging services.

Figure 3.22: An example ExBPA Full Issues List report.

An overzealous administrator may also implement these recommendations without fully considering the ramifications. A common recommendation is to disable anonymous authentication SMTP on Exchange back-end servers. If you don't read the recommendation carefully, you might disable SMTP authentication on your front-end servers and begin rejecting mail from the Internet. Exercise caution, read the recommendations carefully, and consider how they will affect your organization.

Infrastructure Protection

For servers that are connected to an outside network (such as the Internet or to a business partner), there are additional steps you can perform to provide another layer of protection for your servers:

• Use a managed provider on the Internet or SMTP message hygiene system in the DMZ to provide initial inspection of message content.
• Protect published Web resources such as Outlook Web Access (OWA) or mobile device access (ActiveSync) by placing a reverse proxy server between the internal servers and the Internet. Ensure that the reverse proxy server can provide URL inspection.
• On Internet-facing servers, use SSL certificates that have been issued by a trusted certifying authority.
• Configure OWA to use Forms Based Authentication (FBA) so that logon sessions are timed out after some period of client inactivity.
• Implement IPSec between domain controllers/GC servers and Exchange Servers.

Bad Practices

To the best practices list, there is a corresponding list of things that you should not do or that may affect the stability or security of your messaging system:

• Installing a mail client on the console of the mail server
• Surfing the Web, checking email, or using desktop applications from the server console
• Installing unnecessary Windows components or additional applications on dedicated mail servers
• Installing evaluation software on production servers
• Combining server roles such as domain controller, Exchange Server, and SQL on the same physical machine
• Applying service packs and critical fixes immediately after they are released and without testing them

---