MS Exchange 2010 Edge Transport Server STIG

Email system availability depends in part on best practices strategies for setting tuning configurations. Careful tuning reduces the risk that system or network congestion will contribute to availability impacts.

Filters that govern inbound Email evaluation can significantly reduce SPAM, PHISHING, and SPOOFED Emails. Messages from blank senders, known SPAMMERS, or 0-day attack modifications must be enabled to be effective.

Failure to enable the filter will result in no action taken. This setting should always be enabled.

Email system availability depends in part on best practices strategies for setting tuning configurations. Careful tuning reduces the risk that system or network congestion will contribute to availability impacts.

Filters that govern inbound Email evaluation can significantly reduce SPAM, PHISHING, and SPOOFED Emails. Messages from blank senders, known SPAMMERS, or 0-day attack modifications must be enabled to be effective.

Having items identified in the ‘allow’ list causes other SPAM evaluation steps to be bypassed, and therefore should be used only with an abundance of caution. If SPAMMERS were to learn of entries in the ‘allow list’ it could enable them to plan a denial of service attack (or other attack) by spoofing that source.

Email system availability depends in part on best practices strategies for setting tuning configurations. This configuration controls the maximum number of simultaneous inbound connections allowed to the SMTP server.

By default, the number of simultaneous inbound connections is 5000. If a limit is set too low, the connections pool may get filled. If attackers perceive the limit is too low, they could deny service to the Simple Mail Transfer Protocol (SMTP) server by using a connection count that exceeds the limit set. By setting the default configuration to 5000, attackers would need many more connections to cause denial of service.

This control is used to limit the servers that may use this server as a relay. If a Simple Mail Transport Protocol (SMTP) sender does not have a direct connection to the Internet (for example, an application that produces reports to be emailed) then it will need to use an SMTP Receive Connector that does have a path to the Internet (for example, a local email server) as a relay.

SMTP relay functions must be protected so third parties are not able to hijack a relay service for their own purposes. Most commonly, hijacking of relays is done by SPAMMERS to disguise the source of their messages, and may also be used to cover the source of more destructive attacks.

Relays can be restricted in one of three ways; by blocking relays (restrict to a blank list of servers), by restricting use to lists of valid servers, or by restricting use to servers that can authenticate. Because authenticated connections are the most secure for SMTP Receive Connectors, it is recommended that relays allow only servers that can authenticate.

The Simple Mail Transfer Protocol (SMTP) connector is used by Exchange to send and receive messages from server to server. There are several controls that work together to provide security between internal servers. This setting controls the authentication method used for communications between servers. With this feature enabled, messages can be securely passed from a partner domain securely.

The use of secure communication prevents eavesdroppers from reading or modifying communications between mail clients and servers. While sensitive message bodies should be encrypted by the sender at the client, requiring a secure connection from server to server adds protection by encrypting the sender and recipient information that cannot be encrypted by the sender.

Individually, channel security and encryption can be compromised by attackers. Used together, email becomes a more difficult target, and security is heightened. Failure to enable this feature gives eavesdroppers an opportunity to read or modify messages between servers.

Email system availability depends in part on best practices strategies for setting tuning configurations.

This configuration controls the maximum number of recipients who will receive a copy of a message at one time. This tunable value is related to throughput capacity and can enable the ability to optimize message delivery.

Note: There are two types of default Receive Connecters:
Client Servername: This Receive connector accepts SMTP connections from all non-MAPI clients, such as POP and IMAP. As POP and IMAP are not authorized for use in DoD, these should not be present. Their default value for MaxRecipientsPerMessage is 200.
Default Servername: This Receive connector accepts connections from other Hub Transport servers and any Edge Transport servers. Their default value for MaxRecipientsPerMessage is 5000.

For receive connectors, unclear naming as to direction and purpose increases risk that messages may not flow as intended, troubleshooting efforts may be impaired, or incorrect assumptions may be made about the completeness of the configuration.

Collectively, connectors should account for all connections required for the overall email topology design. Simple Mail Transfer Protocol (SMTP) connectors, when listed, must name purpose and direction clearly, and their counterparts on servers to which they connect should be recognizable as their partners.

Tarpitting is the practice of artificially delaying server responses for specific SMTP communication patterns that indicate high volumes of SPAM or other unwelcome messages. The intent of tarpitting is to slow down the communication process for SPAM batches so that the cost effectiveness of sending SPAM is reduced and directory harvest attacks may be thwarted.

A directory harvest attack is an attempt to collect valid email addresses from a particular organization so that the email addresses can be added to a spam database. A program can be written to collect email addresses that return a 'Recipient OK' SMTP response and discards all email addresses that return a 'User unknown' SMTP response.

Tarpitting makes directory harvest attacks too costly to automate efficiently.

Email system availability depends in part on best practices strategies for setting tuning configurations. Careful tuning reduces the risk that system or network congestion will contribute to availability impacts.

Filters that govern inbound Email evaluation can significantly reduce SPAM, PHISHING, and SPOOFED Emails. Messages from blank senders, known SPAMMERS, or 0-day attack modifications must be enabled to be effective.

This setting controls the rate at which delivery attempts from the home domain are retried, user notifications are issued, and notes the expiration time when the message will be discarded.

If delivery retry attempts are too frequent, servers will generate network congestion. If too far apart, then messages may remain queued longer than necessary, potentially raising disk resource requirements.

The default values of these fields should be adequate for most environments. Administrators may wish to modify the values as a result, but changes should be documented in the System Security Plan.

NOTE: Transport configuration settings apply to the organization/global level of the Exchange SMTP path. By checking and setting them at the Hub server the setting will apply to both Hub and Edge roles.

This setting controls the maximum number of simultaneous outbound connections allowed for a given SMTP Connector, and can be used to throttle the SMTP service if resource constraints warrant it. If the limit is too low, connections may be dropped. If too high, some domains may use a disproportionate resource share, denying access to other domains. Appropriate tuning reduces risk of data delay or loss.

The Simple Mail Transfer Protocol (SMTP) connector is used by Exchange to send and receive messages from server to server. There are several controls that work together to provide security between internal servers. This setting controls the encryption method used for communications between servers. With this feature enabled, only servers capable of supporting Transport Layer Security (TLS) will be able to send and receive mail within the domain.

The use of secure communication prevents eavesdroppers from reading or modifying communications between mail clients and servers. While sensitive message bodies should be encrypted by the sender at the client, requiring a secure connection from server to server adds protection by encrypting the sender and recipient information that cannot be encrypted by the sender.

Individually, channel security and encryption can be compromised by attackers. Used together, email becomes a more difficult target, and security is heightened. Failure to enable this feature gives eavesdroppers an opportunity to read or modify messages between servers.

A connectivity log is a record of the SMTP connection activity of the outbound message delivery queues to the destination Mailbox server, smart host, or domain. Connectivity logging is available on Hub Transport servers and Edge Transport servers. By default, connectivity logging is disabled. If events are not recorded it may be difficult or impossible to determine the root cause of system problems or the unauthorized activities of malicious users.

NOTE: Transport configuration settings apply to the organization/global level of the Exchange SMTP path. By checking and setting them at the Hub server the setting will apply to both Hub and Edge roles.

Attackers can use automated messages to determine whether a user account is active, in the office, traveling, and so on. An attacker might use this information to conduct future attacks. Ensure that non-delivery reports to remote domains are disabled. Before enabling this setting first configure a remote domain using the EMC or the New-RemoteDomain cmdlet.

Attackers can use automated messages to determine whether a user account is active, in the office, traveling, and so on. An attacker might use this information to conduct future attacks. Remote users will not receive automated 'Out Of Office' delivery reports. This setting can be used to determine if all the servers in the Organization can send 'Out of Office' messages.

Log files help establish a history of activities, and can be useful in detecting attack attempts or determining tuning adjustments to improve availability. This setting enables an automated log entry to be sent to Microsoft giving general details about the nature and location of the error. Microsoft, in turn, uses this information to improve the robustness of their product.

While this type of debugging information would not ordinarily contain sensitive information, it may alert eavesdroppers to the existence of problems in your Exchange organization. At the very least, it could alert them to (possibly) advantageous timing to mount an attack. At worst, it may provide them with information as to which aspects of Exchange are causing problems and might be vulnerable (or at least sensitive) to attack.

All system errors in Exchange will result in outbound traffic that may be identified by an eavesdropper. For this reason, the 'Report Fatal Errors to Microsoft' feature must be disabled.

Default product installations may provide more generous access permissions than are necessary to run the application. By examining and tailoring access permissions to more closely provide the least amount of privilege possible, attack vectors that align with user permissions are less likely to access more highly secured areas.

Log files help establish a history of activities, and can be useful in detecting attack attempts or determining tuning adjustments to improve availability. Audit log content must always be considered sensitive, and in need of protection.

Successful exploit of an application server vulnerability may well be logged by monitoring or audit processes when it occurs. By writing log and audit data to a separate partition where separate security contexts protect them, it may offer the ability to protect this information from being modified or removed by the exploit mechanism.

The INFOCON system provides a framework within which the Commander USSTRATCOM regional commanders, service chiefs, base/post/camp/station/vessel commanders, or agency directors can increase the measurable readiness of their networks to match operational priorities. The readiness strategy provides the ability to continuously maintain and sustain one’s own information systems and networks throughout their schedule of deployments, exercises, and operational readiness life cycle independent of network attacks or threats. The system provides a framework of prescribed actions and cycles necessary for reestablishing the confidence level and security of information systems for the commander and thereby supporting the entire Global Information Grid (GIG) (SD 527-1 Purpose).

The Exchange software files and directories are vulnerable to unauthorized changes if not adequately protected. An unauthorized change could affect the integrity or availability of email services overall. For this reason, all application software installations must monitor for change against a software baseline that is preserved when installed, and updated periodically as patches or upgrades are installed. Automated and manual schedules for software change monitoring must be compliant with SD527-1 frequencies.

Note: Policy Auditor 5.2 or later, File Integrity Monitor (FIM) module will meet the requirement for file integrity checking. The Asset module within HBSS does not meet this requirement.

Exchange may be configured to accept email for multiple domain names. This setting identifies the domains for which the server will accept mail. This check verifies the email server is not accepting email for unauthorized domains.

In the same way that added security layers can provide a cumulative positive effect on security posture, multiple applications can provide a cumulative negative effect. A vulnerability and subsequent exploit to one application can lead to an exploit of other applications sharing the same security context. For example, an exploit to a web server process that leads to unauthorized administrative access to the host system can most likely lead to a compromise of all applications hosted by the same system.

Email services should be installed on a partition that does not host other applications. Email services should never be installed on a Domain Controller / Directory Services server.

Email system availability depends in part on best practices strategies for setting tuning configurations. Message size limits should be set to 10 megabytes at most, but often are smaller, depending on the organization. The key point in message size is that it should be set globally, and it should not be set to ‘unlimited’. Selecting ‘unlimited’ on either field is likely to result in abuse and can contribute to excessive server disk space consumption.

Message size limits may also be applied on send and receive connectors, Public Folders, and on the user account under AD. Changes at these lower levels are discouraged, as the single global setting is usually sufficient. This practice prevents conflicts that could impact availability and it simplifies server administration.

Sender Identification (SID) is an email anti-spam sanitization process. Sender ID uses DNS MX record lookups to verify the SMTP sending server is authorized to send email for the originating domain.

Failure to implement Sender ID risks that SPAM could be admitted into the email domain that originates from rogue servers. Most SPAM content originates from domains where the IP address has been spoofed prior to sending, thereby avoiding detection. For example, messages with malformed or incorrect 'purported responsible sender' data in the message header could be (best case) created by using RFI non-compliant software, but is more likely to be SPAM.

Block List filtering is a sanitization process performed on email messages prior to their arrival at the destination mailbox. By performing this process at the email perimeter, threats can be eliminated outside the enclave, where there is less risk they can do harm.

Block List Services (sometimes called Reputation Data Services) are fee based data providers that collect the IP addresses of known SPAMmers and other malware purveyors. Block List Service Subscribers benefit from more effective SPAM elimination, which has been estimated as comprising up to 90% of inbound mail volume. Failure to specify a Block List provider risks that manual email administration effort would be needed to maintain and update larger block lists than a single email site administrator could conveniently or accurately maintain.

The 'Block List' Services vendor provides a value for this field, usually the DNS suffix for their domain.

Email system availability depends in part on best practices strategies for setting tuning configurations. This configuration controls the maximum number of simultaneous outbound connections from a domain, and works in conjunction with the Maximum Outbound Connections Count setting as a delivery tuning mechanism. If the limit is too low, connections may be dropped. If too high, some domains may use a disproportionate resource share, denying access to other domains. Appropriate tuning reduces risk of data delay or loss.

By default, a limit of 20 simultaneous outbound connections from a domain should be sufficient. The value may be adjusted if justified by local site conditions.

By performing filtering at the perimeter, up to 90 percent of spam, malware, and other undesirable messages are eliminated from the message stream rather than admitting them into the mail server environment. Attachments are being used more frequently for different forms of attacks. By filtering undesirable attachments a large percent of malicious code can be prevented from entering the system. Attachments must be controlled at the entry point into the email environment to prevent successful attachment-based attacks. The following is a basic list of known attachments that should be filtered from Internet mail attachments.

*.ade *.crt *.jse *.msi *.scr *.wsh *.dir *.adp *.csh *.ksh *.msp *.sct *.htm *.dcr *.app *.exe *.lnk *.mst *.shb *.html *.plg *.asx *.fxp *.mda *.ops *.shs *.htc *.spl *.bas *.hlp *.mdb *.pcd *.url *.mht *.swf
*.bat *.hta *.mde *.pif *.vb *.mhtml *.chm *.inf *.mdt *.prf *.vbe *.shtm *.cmd *.ins *.mdw *.prg *.vbs *.shtml
*.com *.isp *.mdz *.reg *.wsc *.stm
*.cpl *.js *.msc *.scf *.wsf

By performing filtering at the perimeter, up to 90% of SPAM, malware, and other undesirable messages are eliminated from the message stream rather than admitting them into the Mail server environment. Sender reputation is anti-SPAM functionality that blocks messages according to many characteristics of the sender. Sender reputation relies on persisted data about the sender to determine what action, if any, to take on an inbound message. This setting enables the sender reputation function.

SPAM origination sites and other sources of suspected Email-borne malware have the ability to corrupt, compromise, or otherwise limit availability of Email servers. Limiting exposure to unfiltered inbound messages can reduce the risk of SPAM and malware impacts.

The Global Deny list block messages originating from specific sources. Most Black List filtering is done using a commercial 'Block List' service, because eliminating threats from known SPAMMERS prevents the messages being evaluated inside the enclave where there is more risk they can do harm.

Additional sources should also be blocked to supplement the contents of the commercial 'Block List Service'. For example, during a 0-Day threat action, entries can be added, and then removed when the threat is mitigated. An additional best practice is to enter the enterprise’s home domains in the Deny List, because inbound Email with a ‘from’ address of the home domain is very likely to be SPOOFED SPAM.

By performing filtering at the perimeter, up to 90% of SPAM, malware, and other undesirable messages are eliminated from the message stream rather than admitting them into the mail server environment. Anonymous email (messages with blank sender fields) cannot be replied to. Messages formatted in this way may be attempting to hide their true origin to avoid responses, or to SPAM any receiver with impunity while hiding their source of origination.

Rather than spend resource and risk infection while evaluating them, it is recommended that these messages be filtered immediately upon receipt and not forwarded to end users.

Email system availability depends in part on best practices strategies for setting tuning configurations. This configuration controls the number of idle minutes before the connection is dropped. It works in conjunction with the Maximum Outbound Connections Count setting.

Connections, once established, may incur delays in message transfer. The default of 10 minutes is a reasonable window in which to resume activities without maintaining idle connections for excessive intervals. If the timeout period is too long, idle connections may be maintained for unnecessarily long time periods, preventing new connections from being established. Sluggish connectivity increases the risk of lost data. A value of 10 or less is optimal.