Locking Down SMTP

SMTP is the de facto messaging standardnot only for Exchange Server 2003 but also for the industry. This service is not built into Exchange Server 2003 but rather is a service provided by Windows Server 2003. Nonetheless, SMTP security and other parameters can be easily configured through the Exchange System Manager (ESM).

General SMTP Security Best Practices

Some general security best practices for SMTP include, but are not limited to, the following:

• Limit Message Size Limiting the size of incoming and outgoing emails not only helps save disk space on the Exchange Server 2003 server, it also minimizes Denial of Service (DoS) vulnerabilities.

• Disable Auto-replies The classic out-of-office or on-vacation message that users may configure are essentially messages informing a hacker that "I'm not at home." Users are notorious for also giving information, such as contact information, in these auto-reply receipts that should not necessarily be shared with anyone that sends them an email.

• Restrict User Access Allowing only authenticated users to send email prevents unauthorized users from using the system for spam or other nonapproved messaging.

• Control SMTP Connections Controlling which IP addresses or domains that can send emails will greatly reduce spam, spam-relaying, and DoS attacks.

• Hide the SMTP Greeting Hide the SMTP greeting so that hackers must work even harder to discover which messaging system they are trying to attack.

Configuring Message Delivery Limits

Message delivery limits prevent users from sending large messages through Exchange. Large messages tie up Exchange resources (processing time, queue availability, disk storage, and more) and if misused can be just as bad as experiencing a DoS attack. It also molds users into using better, alternative delivery methods , such as file shares, compression of attachments, and even document management portals. Exchange Server 2003 uses a 10,240KB (10MB) message size limit by default, and this can be easily set to smaller sizes.

Another important message delivery limit that can be used to secure Exchange Server 2003 involves the number of recipients that a message can be sent to at any one time. Limiting the maximum number of recipients limits internal users' ability to essentially spam the enterprise with large numbers of emails. Exchange Server 2003 limits the number of recipients per message to 5,000 recipients. Using public folders in addition to a limitation on the maximum number of recipients can also mold users into working more efficiently with Exchange Server 2003.

To configure Exchange Server 2003 message delivery limits, do the following:

1. Open the ESM by choosing System Manager from the Start, All Programs, Microsoft Exchange menu.

2. Expand Global Settings and then right-click Message Delivery and select Properties.

3. On the Defaults tab, adjust the limits for Sending message size or Receiving message size.

4. To control the number of recipients per message, adjust the Recipients limits setting.

TIP

Distribution Groups are expanded when evaluating the maximum recipients limit. It might be necessary to override some users (for example, the Human Resources (HR) department) with No Limit in Active Directory Users and Computers to allow them to use an All Employees distribution group .

Securing SMTP Virtual Servers

Security configuration parameters can be found within the SMTP virtual server's Property pages. To view the Property pages for a server's SMTP virtual server, do the following:

1. Open the ESM by choosing System Manager from the Start, All Programs, Microsoft Exchange menu.

2. Expand the Exchange Organization, the Administrative Group where the server resides, the Exchange Server 2003 server, the Protocols folder, and finally the SMTP folder.

3. Right-click the Default SMTP Virtual Server and select Properties.

Using Authentication Controls

All three of the supported authentication methods supported by the SMTP virtual server (that is, anonymous, Basic, and Integrated Windows Authentication) are enabled as illustrated in Figure 13.8. Although this configuration might appear to be completely insecure , it depends on the organization's security policy and whether the SMTP virtual server is accessible by a host on the Internet. Many SMTP hosts do not require usernames and passwords and instead rely on other methods to secure access. If the organization has only a small number of SMTP hosts accessing the SMTP virtual server, use either Basic with TLS or Integrated Windows Authentication.

Figure 13.8. Authentication methods supported by SMTP virtual servers.

CAUTION

Checking the option to resolve anonymous email might leave the messaging environment susceptible to spoofing. Spoofing is essentially the ability for an unauthorized user to masquerade as a valid or authorized user. It can give users and hackers the ability to forge messages as if they were being sent from a legitimate user.

These options are accessible by clicking the Authentication button on the Access tab within the SMTP virtual server's Property pages.

Securing Communications

Communications with the SMTP virtual server can be secured using digital certificates and encryption. More specifically , using encryption can be made a requirement through the use of TLS. To secure communications using TLS, do the following:

1. Within the SMTP virtual server's Property pages, select the Access tab.

2. Click on the Certificate button within the Secure communications section to start the Web Server Certificate Wizard. Click Next to bypass the welcome screen.

3. As illustrated in Figure 13.9, there are several options for obtaining a digital certificate, including creating a new one, assigning an existing certificate, importing, or copying a certificate from another site.

   Figure 13.9. Requesting a digital certificate for the SMTP virtual server.

   

4. Click Next and then select the certificate to use. The options vary depending on the option chosen in the previous step.

5. Click Next and then review the certificate summary window.

6. Click Next and then Finish when done.

At this point, the certificate is installed but the secure communications is not enabled. To require encrypted communications, do the following:

1. Click on the now visible Communications button.

2. In the Security window check the check box to require encrypted communications.

3. Optionally, check the check box to require 128-bit encryption. This option is recommended when using TLS.

Restricting Access to the SMTP Virtual Server

Access to the SMTP virtual server can be restricted based on the IP address, subnet, or domain. These options are found by clicking the Connection button on the Access tab.

Controlling SMTP Relaying

SMTP relay servers deliver messages without regarding the recipient or sender. This functionality is very useful to many organizations, but if the relay is wide open, spammers can and will prey on it whenever possible so that thousands upon thousands of messages can be easily broadcast without ever disclosing their true point of origin. For instance, an organization might need to relay alerts and notifications from internal systems to users. A monitoring solution, such as Microsoft Operations Manager (MOM), can be configured to send email alerts to the administrator via a relay server if the Exchange server goes down. Another example would be to enable UNIX servers to relay backup reports and logs to administrators.

NOTE

Relaying can also be enabled on an SMTP connector if the Allow Messages to Be Relayed to These Domains option is checked on the Address Space tab of the SMTP connector's Property pages.

The good news is that Exchange Server 2003 must be manually configured to enable any SMTP relaying. However, more often than not many organizations still are unknowingly SMTP relays because of misconfigurations or carelessness.

As spam enters an organization, administrators can view the SMTP header to reveal the SMTP relay server from which the message originated. The spammed organization can then either complain to the organization that was used as a relayor worse , add the SMTP relay server to a relay blacklist. These blacklists , which Exchange Server 2003 supports, help reduce spam but can wreak havoc for organizations that are unknowingly relaying because messages can be blocked so that spam is not further propagated using your SMTP relay.

If your organization must use relaying, there are security measures that can be taken to prevent SMTP relay abuse. Connection control methods, similar to what was described in the earlier section "Restricting Access to the SMTP Virtual Server," can restrict access to the SMTP relay based on IP addresses, subnets, and domains. Domain restrictions require reverse lookups, however, which can severely affect server performance. In addition to connection control, relaying can be controlled through the use of authentication methods.

Using Authentication to Secure a Relay Server

In Exchange 2003, the administrator can grant or deny relay permissions to specific users and groups. Relay permissions give the user the right to use the SMTP virtual server to send mail to a destination outside the organization. More specifically, relaying can be restricted using Discretionary Access Control Lists (DACLs), which enables more granularities with restrictions. Restricting relaying on SMTP virtual servers is useful to allow a group of users to relay mail to the Internet, but deny relay privileges for others

For outbound connections, authentication can be configured to control connections from the SMTP relay server to other messaging servers. These options can be located by doing the following:

1. Click the Delivery tab within the SMTP virtual server's Property pages.

2. Click Outbound Security to view the authentication options.

The authentication options for outbound security allow you to choose only one type of authentication to use, which is not the case for the inbound security settings. When either Basic or Integrated Windows Authentication is used, additional information must be supplied and the other servers must support authentication. If Basic is chosen, a username and password must be supplied by the SMTP relay server. On the other hand, if Integrated Windows Authentication is to be used, a valid account and password must be supplied. In either case, TLS can be used and is recommended.