Front End

Exchange 2007 Edge Transport Agents

 In my last post you would have noticed that Exchange 2007 comes with additional protection in the form of agents. Maybe someone at Microsoft is a big fan of the Matrix I dont know. But i briefly wanted to cover agent roles on the Edge Server…

Additional layers of message protection and security are provided by a series of agents that run on the Edge Transport server and act on messages as they are processed by the message transport components. These agents support the features that provide protection against viruses and spam and apply transport rules to control message flow.
Edge Transport Rules

Edge Transport rules are used to control the flow of messages that are sent to or received from the Internet. The Edge Transport rules help protect corporate network resources and data by applying an action to messages that meet specified conditions. These rules are configured for each server. Edge Transport rule conditions are based on data, such as specific words or text patterns in the message subject, body, header, or From address, the spam confidence level (SCL), or attachment type. Actions determine how the message is processed when a specified condition is true. Possible actions include quarantine of a message, dropping or rejecting a message, appending additional recipients, or logging an event. Optional exceptions exempt particular messages from having an action applied.

Address Rewriting

You use address rewriting to present a consistent appearance to external recipients of messages from your Exchange 2007 organization. You configure the Address Rewriting agent on the Edge Transport server role to enable the modification of the SMTP addresses on inbound and outbound messages. Address rewriting is especially useful when a newly merged organization that has several domains wants to present a consistent appearance of e-mail addresses to external recipients.

Edge Rules Agent

The Edge Rules agent, which runs on the Edge Transport server, helps you control the number of unwanted messages that enter your organization. If your internal network is compromised, the Edge Transport rule agent can also apply the same or different rules to outgoing messages. In this manner, the Edge Rules agent helps you prevent infected or unwanted messages that are generated by infected computers in your internal network from leaving your organization. The following list provides some examples of when the Edge Rules agent can help you protect your organization:

Virus outbreaks   Thousands of new viruses are created each year. Most antivirus software providers are reactive when they update their software. To update their software, antivirus software providers have to identify the virus, create an update for their software, and then send the update to their customers. This causes a gap in protection where an infected message can enter an organization unexpectedly.

Denial of service attacks   Malicious individuals who want to do harm to organizations may use denial of service (DoS) attacks to draw attention to themselves or to cause damage. These attacks are typically unannounced and can be difficult or impossible to predict.

The Edge Rules agent is designed to help you reduce the impact of each of these risks. The Edge Rules agent lets you configure conditions and exceptions to identify both unwanted and wanted messages and to act on those messages by using configured actions.

Anti-Spam and Antivirus Scanning

In Exchange 2007, the anti-spam and antivirus features provide services to block viruses and spam, or unsolicited commercial e-mail, at the network perimeter. Most viruses use spam-like tactics to gain access to your organization and to entice users to open an e-mail message. If you can filter out most of your spam, you are also more likely to capture viruses before they enter your organization.

Spammers use a variety of techniques to send spam into your organization. Servers that run the Edge Transport server role help prevent users in your organization from receiving spam by providing a collection of agents that work together to provide different layers of spam filtering and protection. Establishing tarpitting intervals on connectors makes e-mail harvesting attempts ineffective.

The Sender ID agent

The Sender ID agent relies on the RECEIVED Simple Mail Transfer Protocol (SMTP) header and a query to the sending system’s domain name system (DNS) service to determine what action, if any, to take on an inbound message.

When you configure anti-spam agents on an Edge Transport server, the agents act on messages cumulatively to reduce the number of unsolicited e-mail messages that enter the organization.

Sender ID is intended to combat the impersonation of a sender and a domain, a practice that is frequently called spoofing. A spoofed mail is an e-mail message that has a sending address that was modified to appear as if it originates from a sender other than the actual sender of the message.

Spoofed mails typically contain a From: address that purports to be from a certain organization. In the past, it was relatively easy to spoof the From: address, in both the SMTP session, such as the MAIL FROM: header, and in the RFC 822 message data, such as From: “Michael Smith” Michael@mydomain.com, because the headers were not validated.

Microsoft Exchange Edge Transport Server Role

 Note: In pre-release versions of Microsoft Exchange Server 2007, the Edge Transport server role was referred to as the Gateway server role.

Since the Edge Transport Server Role is a transport role for messages you can’t benefit from it to provide your colleagues with Outlook Web Access, Outlook Mobile Access, Outlook Voice Access, Outlook Everywhere or one of the other nifty “road warrior” features Exchange 2007 provides to more easily work together. In this scenario you need a Microsoft Exchange Server 2007 box with the Client Access Server Role applied to it. Although enhancements were made to Client Access Servers security the face-off between security and functionality remains.

Exchange 2007 introduces a new concept to Exchange organizations, the concept of server roles. Similar to how a Windows server can host one or more roles, this type of configuration has been implemented in Exchange Server 2007.

In Exchange 2007, the Edge Transport server role is deployed in your organization’s perimeter network as a stand-alone server or as a member server of a perimeter-based Active Directory domain. Designed to minimize the attack surface, the Edge Transport server handles all Internet-facing mail flow, which provides Simple Mail Transfer Protocol (SMTP) relay and smart host services for the Exchange organization. Additional layers of message protection and security are provided by a series of agents that run on the Edge Transport server and act on messages as they are processed by the message transport components. These agents support the features that provide protection against viruses and spam and apply transport rules to control message flow.

The computer that has the Edge Transport server role installed doesn’t have access to the Active Directory directory service. All configuration and recipient information is stored in the Active Directory Application Mode (ADAM) directory service. To perform recipient lookup tasks, the Edge Transport server requires data that resides in Active Directory. EdgeSync is a collection of processes that are run on a computer that has the Hub Transport server role installed to establish one-way replication of recipient and configuration information from Active Directory to the ADAM instance on an Edge Transport server. The Microsoft Exchange EdgeSync service copies only the information that is required for the Edge Transport server to perform anti-spam configuration tasks and the information about the connector configuration that is required to enable end-to-end mail flow. The Microsoft Exchange EdgeSync service performs scheduled updates so that the information in ADAM remains current.

You can install more than one Edge Transport server in the perimeter network. Deploying more than one Edge Transport server provides redundancy if a server fails. You can load-balance SMTP traffic to your organization between Edge Transport servers by defining more than one mail exchange (MX) resource record with the same priority in the Domain Name System (DNS) database for your mail domain. You can achieve consistency in configuration between multiple Edge Transport servers by using cloned configuration scripts. Additionally, an Edge Transport server template is provided for use with the Windows Server 2003 Service Pack 1 Security Configuration Wizard to help configure Windows Server 2003 at the appropriate role-based security level.

Exchange Server Front and Back-ends.

I currently running a Front –end / Back-end scenario in a DMZ and have been for two years. It’s worked well… but has been compromised so it’s not full proof, although that was down to other circumstances. The Front-end / Back-end configuration is available in both Microsoft Exchange 2000 Server and Microsoft Exchange Server 2003 and the basic principal is to divide server roles. The distinction is made between a front-end server that accepts requests from clients and then proxies them to an appropriate server for processing, making this effectively a Back-end server.

Scenarios

• According to the Microsoft documentation a Front-end / Back-end scenario comes to play when you experience or foresee experiencing performance, scalability or security issues with Microsoft Exchange:

Performance

• From a performance point of view you can deploy Front-end servers to lift the burden of SSL securing your Outlook Web Access (OWA) and Outlook Mobile Access (OMA), POP3 and IMAP from your Back-end server. Blocking Unsolicited Bulk E-mail (UBE or Spam) at the Front-End might speed up your Back-end to Outlook clients connected to the Back-end server.

Scalability

• From a scalability point of view you can use the configuration to make a neat Network Load Balanced (NLB) cluster of Front-end servers. Don’t use Clustering Services though to scale your Front-end servers, it won’t work.

Security

• Despite the performance and scalability improvements you can gain from implementing a Front-end / Back-end configuration you cannot use it by itself in any security scenario. Encrypting traffic with IPSec, Using the Security Configuration Wizard in Windows Server 2003 SP1 and even pinning down RPC ports will get you far, but in my opinion not far enough.

  In my opinion the security design flaw in the current Front-end / Back-end configuration is you actually install a fully fledged Exchange Server, which you afterwards strip of its databases and configure to relay everything to the back-end Exchange Server. It stays an Exchange Server however, which needs access to the Active Directory, DNS and other Exchange Servers. If you implement your Front-end server inside a DMZ you’ll be required to open up a whole lot of UDP and TCP ports, eventually rendering your DMZ pretty useless if the box gets compromised.

Yes I’m knocking it and Yes it works. In my next post I’ll look at the new flavours from Exchange Server2007