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.
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:
The following ports may need to be opened between the Exchange front-end server and all backend Exchange servers:
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:
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.
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.
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.
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.
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.
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.
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.
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.
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 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 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:
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.
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
220.127.116.11, 18.104.22.168, and 22.214.171.124. 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:126.96.36.199 ip4:188.8.131.52 ip4:184.108.40.206 ~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
aol.com text =
"v=spf1 ip4:220.127.116.11/24 ip4:18.104.22.168/24 ip4:22.214.171.124/24 ip4:126.96.36.199/23 ip4:188.8.131.52/24 ip4:184.108.40.206/23 ip4:220.127.116.11/24 ptr:mx.aol.com ?all" aol.com text =
"spf2.0/pra ip4:18.104.22.168/24 ip4:22.214.171.124/24 ip4:126.96.36.199/24 ip4:188.8.131.52
/23 ip4:184.108.40.206/24 ip4:220.127.116.11/23 ip4:18.104.22.168/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
Non-authoritative answer: microsoft.com text =
"v=spf1 mx include:_spf-a.microsoft.com include:_spf-
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: email@example.com
Received: from relay1.somorita.com ([22.214.171.124]) 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 ([126.96.36.199]) 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 <firstname.lastname@example.org>; Mon, 20 Feb 2006 17:04:43 -0800 (PST)
From: Classmates <ClassmatesEmail@classmates.com>
Subject: Lyle, you have 19 visits to your profile
Date: Mon, 20 Feb 2006 17:04:43 -0800 (PST)
X-OriginalArrivalTime: 21 Feb 2006 01:04:48.0214 (UTC)
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:
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.
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 ([188.8.131.52]) 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 ([184.108.40.206]) 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 <email@example.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 220.127.116.11 and that IP address is defined as one of the servers that handles incoming SMTP mail.
Received: from relay1.somorita.com ([18.104.22.168]) 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 ([22.214.171.124]) by relay1.somorita.com with (Mirapoint Messaging Server MOS 3.3.2CR) with ESMTP id AGC33650;
This was received from IP address 126.96.36.199. 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.
Sender ID status result
Validation failed - Malformed domain
The domain name for the PRA is not complete or is in an incorrect format.
Validation failed - Non-existent domain
The domain name for the PRA is not a valid domain name in DNS.
Validation failed - Not permitted result
The DNS data that is retrieved does not contain valid information, is not in a valid format, or contains information that cannot be interpreted by this Sender ID system.
Validation with a neutral result
An SPF record exists, but the published Sender ID data is explicitly inconclusive.
Validation with a none result
No SPF record for the sender's domain was found in DNS.
Validation with a pass result
The sender's IP address for the PRA is found in the SPF record.
Validation with a PermError result
A permanent error has occurred such as a malformed or corrupted DNS SPF record.
Validation with a SoftFail result
A "weaker" failure error where the Sender ID system could not determine conclusively whether the sender's IP address was in the SPF record.
Validation with a TempError result
A transient error has occurred such as unable to contact the DNS server.
Message has no PRA
The PRA cannot be located and thus the sending domain cannot be resolved.
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.
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:
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.
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:
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:
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.
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:
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:
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.
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:
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: