Defenses Against Mail Service Attacks

There is no way to protect against every type of attack all of the time; however, as a messaging administrator you can take steps that will help to secure your network environment. When approaching defense, it is always wise to assume a layered approach in order to ensure that your environment is protected from different perspectives. By securing multiple facets of your environment, you help to reduce the chances of an infrastructure breach by effectively reducing your surface exposure.

As we discuss the layered approach to defense against mail service attacks, we will be examining the environment beginning with the Internet facing components first, from which we will work our way inwards toward the internal network. By employing defensive tactics at each layer within your messaging services, you reduce the risk associated with mail service attacks by arming your systems to respond to attacks appropriately. This is easier to do with certain attacks and more difficult with others.

Also, something to be aware of and keep in mind is that there is administrative overhead associated with deploying a layer approach. Since you will typically introduce additional products that are deployed at different points throughout the infrastructure, the associated maintenance and upkeep must be considered. Without proper maintenance, your defensive systems may not be able to protect your environment. This is especially true with antispam and antivirus products. Without the most recent definitions, the product may very well miss a Trojan or virus as it attempts to make its way into your network. To ensure this is less likely to occur, it is a good idea to create a product maintenance schedule and take the time to validate that maintenance is being completed as expected.

Defense in the Perimeter Network

A perimeter network can be created in a variety of ways in a network environment. Perimeters may be as simple as a single bastion host creating the barrier between the internal network and the internet to a more complex deployment of screened subnets with multiple firewall layers for protection. Regardless of how your perimeter network is deployed, in order to stage a proper defense against mail service attacks, there must be an SMTP presence existing in the company's perimeter network, which is maintained separately from the mail servers that are housing user data and performing internal routing.

Mail traffic should not be allowed to flow from the Internet directly into your internal network, and your internal Exchange servers should not be transmitting data to the Internet. In order to reduce exposure whenever possible, Exchange servers should be placed on the internal network. The one exception to this is the Exchange 2007/Exchange 2010 Edge servers.

Edge servers are a server role that exists in both Exchange 2007 and Exchange 2010, which are intended to be deployed in a perimeter network. By deploying Exchange Edge servers into a screened subnet in your perimeter network, they can be used as smart hosts for forwarding Internet-bound e-mail traffic by the Exchange servers on the internal network. Utilizing Exchange Edge servers allows for minimal surface exposure to the Internet, and since Edge servers are designed to be Internet facing, they are an SMTP deployment which is secured by default.

Exchange Server 2003 does not contain a server role that was intended for deployment into the perimeter network. So the question becomes, in the case of an Exchange 2003 architecture, do we still need to deploy perimeter components? The short answer is Yes. Assuming Internet traffic is part of the infrastructure requirements, you should still take steps to screen your internal network from direct Internet mail connectivity.

In order to accomplish this screening, many administrators choose to deploy SMTP appliances, such as Cisco's Ironport (www.ironport.com), CipherTrust's Ironmail (www.ciphertrust.com/products/ironmail), or Symantec's Brightmail Traffic Shaper appliance (www.symantec.com/business/brightmail-traffic-shaper). These devices are built to handle SMTP traffic to/from the Internet and will typically have many built-in defense mechanisms that allow the system to cope with a wide range of attacks, as well as manage spam influx efficiently. Even in situations where Exchange 2007 is the e-mail product of choice, often times the administrator will make the decision not to use the Exchange Edge role as their Internet facing SMTP server and instead choose to deploy an SMTP appliance.

Regardless of which messaging product is selected, it is critical to implement this first line of defense. Whichever device is deployed as the Internet facing SMTP service for the environment, it is important to deploy it as securely as possible, including protection against viruses, Trojans, worms, and spam. SMTP Auth attacks can be defended against by ensuring not to utilize authenticated connections into the SMTP server, while mail relay attempts can be deterred by properly configuring the system not to allow it. If mail relay is a requirement, then IP address–based filtering is an additional protective measure that can be deployed. IP address filtering adds administrative overhead, but allows the administrator to narrow the scope of which machines are able to submit an e-mail message for routing.

alt1 Note

In recent years, a group of partners, including Microsoft, have been focusing on making it possible to attempt to predict the legitimacy of a mail message based on its originating source. They have come together to create a resource referred to as the Sender ID Framework. This Sender ID Framework is used to validate if the source messaging server is an authorized transmitter for the domain namespace by checking DNS for valid SPF records.

Spoofing is one of the most difficult attacks to identify and combat; however, the source IP address in a mail message is one of few items that attackers cannot manipulate. In order to obtain connectivity to the Internet, they must play by the rules of transfer control protocol (TCP)/IP, which does not allow them to manipulate the source IP address. This allows the usage of the source address as a means to verify authenticity. Some vendors have chosen to use the predictable source IP in order to track trends over time. By analyzing the sending habits of different public IP addresses and storing the data in a centrally accessible database, the vendor's customers are able to configure their devices to make a determination as to whether a source IP address should be trusted, or if it is a prime candidate to expect spam from.