Extreme Exploits: Advanced Defenses Against Hardcore Hacks (Hacking Exposed)

As previously stated, the MTA is responsible for transferring e-mail to other public entities. Some MTAs are built into existing e-mail packages (such as Microsoft Exchange or Lotus Domino) or can be found as stand-alone packages. Built-in MTAs can be convenient to install and maintain; however, these "included" MTAs are often feature-poor and lack the sophistication desired by many organizations. Examples of such missing features include filtering capabilities for anti-virus and anti-spam, and other advantages such as complex e-mail routing functionality for larger, geographically diverse organizations. Implementing a feature-rich, stand-alone e-mail transport agent can give an organization a plethora of new capabilities including the ability to route e-mail in a variety of ways, filter unsolicited messages, and secure e-mail tunnels between trusted organizations, to name a few.

Built-in MTAs

In addition to the various issues listed above, built-in MTAs customarily contain the following limitations:

• The MX border represents the first line of e-mail defense for an organization. During a denial-of-service (DoS) attack on your externally reachable MTA, an attacker may be able to completely disable your internal e-mail system for the duration of the attack. The only way to secure your internal e-mail server from attack is to segregate it from the outside; a stand-alone MTA accomplishes this if properly implemented.

• Most built-in MTA software was designed as an afterthought and, as such, lacks the performance required by some of the filtering and advanced routing functions most organizations require. For example, once virus scanning and anti-spam filtering are added to many built-in MTA packages, the entire e-mail server slows down to accomplish the filtering, which isn't acceptable to the internal user population.

• Numerous security vulnerabilities have been found within the SMTP components of popular e-mail software packages. These vulnerabilities continue to appear publicly and a stand-alone MTA allows the organization to protect the internal e-mail server and expose only the stand-alone MTA, limiting risk/exposure. This is especially important when securing e-mail data stores. If the MTA does not "house" any data stores, the accessibility of the internal server (containing the data) is severely diminished.

Stand-alone MTAs

Stand-alone MTAs are fast becoming a commonplace component of critical infrastructure in large organizations or organizations focused on e-mail security. This is primarily because:

• Stand-alone MTAs customarily operate faster and provide an additional point of redundancy for queuing e-mail.

• Stand-alone MTAs free up your internal e-mail server to perform faster internal operations for its users. Recent studies state as much as 64 percent of an organization's incoming e-mail can be spam, according to statistics gathered by Brightmail, now owned by Symantec. A stand-alone MTA can absorb and filter this traffic without using internal e-mail server resources.

• Stand-alone MTAs provide another layer of security to protect the internal e-mail server and the organization itself. Often, the MTA can be comprised of a different e-mail package and even a different operating system completely, making attack fingerprinting more difficult.

• Many stand-alone MTAs now support the use of Transport Layer Security (TLS) encapsulation of (e)SMTP, which provides a means of opportunistic encryption (or encryption when both systems during a transaction deem it possible) to secure e-mail traversing the Internet.

Stand-alone MTA Implementation

Stand-alone MTAs are often implemented in a simple configuration. For example, many organizations simply use MTAs to accept e-mail from the untrusted network outside an organization, filter the inbound e-mail through several components such as anti-spam and anti-virus subsystems, and then forward the message across the semitrusted (DMZ) network into the organization's internal e-mail server.

Other organizations configure additional features in their stand-alone MTAs, such as opportunistic Transport Layer Encryption (TLS), which allows the e-mail server to automatically build a real-time, temporary, and secure virtual private network to another e-mail server (a trusted partner, perhaps) to authenticate the remote end and to protect the e-mail data with encryption as it traverses the Internet. This feature is ideal if the company is normally transacting sensitive information between several "partner" domains and avoids the need to employ expensive (in both software and technical support (helpdesk) requirements) client-based, end-to-end e-mail security solutions such as PGP or S/MIME.

Likewise, some organizations use the MTA to provide enhanced routing capabilities. For example, if a company has 50 different domains, but only a few user communities, the MTA can be configured to automatically rewrite the envelopes of inbound messages to deliver them to the appropriate domain/system. Enhanced e-mail routing provides incredible flexibility and provides several methods of accomplishing fast and timely integration of disparate domains through organization acquisition, and so on, without the immediate need for complex directory integration.

E-mail is based on IETF (Internet Engineering Task Force) standards such as SMTP. This causes a vast number of commercial and noncommercial software packages and solutions to be available providing enhanced stand-alone MTA features. Additionally, some packages are software-based and require some type of underlying operating system while others are a complete package such as an appliance. The appliance's operating system is highly customized (usually some type of UNIX variant operating system) to perform exceptionally well at transferring e-mail. All other functionality is disabled and/or removed. Features of the appliance vary by manufacturer but will generally contain anti-virus, anti-spam, and even directory integration features.