Few days ago, on Microsoft TechNet's web site published a very good article "Top 5 Exchange Server 2007 Security Best Practices". This article so clear and simple to implement that I decided to republish it here...

Number 5: Use the Client Submission Port

When they designed the Exchange Server 2007 transport servers (the Hub Transport and Edge Transport roles), the members of the Exchange Server product team made a great decision that makes it easier than ever to quickly and securely configure Simple Mail Transfer Protocol (SMTP) connections: they separated the receive functionality (the SMTP server role) from the send functionality (the SMTP client role). As a result, you now have Receive Connectors and Send Connectors, allowing you to more easily break down SMTP traffic between the server role and the client role as shown in Figure 1.

This split permits Exchange Server 2007 to offer out-of-the-box support for the Client Submission Port de facto Internet standard. Many ISPs and networks block outgoing TCP 25 connections to reduce the amount of spam coming from their networks and force outgoing messages through their filtering. This can be a real bother for users who connect to different networks; they may have to reset their application configuration depending on the network they’re currently connected to.

The Client Submission Port standard proposes a solution for this problem by using two separate SMTP server ports: the default TCP port 25 and an additional TCP port 587. In Exchange Server 2007, these are implemented as two receive connectors on Hub Transport servers:

Legacy Exchange servers and Exchange Server 2007 transport servers in your organization use port 25 for SMTP communications with each other. If a Hub Transport server is intended to receive incoming messages from the Internet, its Default Receive Connector should allow anonymous connections. By default, this connector requires authentication; Exchange Server assumes you are using an Edge Transport server as your external gateway.

The Client Receive Connector gives you an alternative to requiring authenticated SMTP on your main external mail gateway, especially if that gateway is a third-party appliance. Using this port gives your users the ability to submit messages to your servers even when they’re on the road, without needing to change their configurations.

I should point out that if your users are using Outlook Anywhere with Office Outlook 2007, RPC over HTTPS with Outlook 2003, or WebDAV connection with Microsoft Entourage 2004 or 2008, they don’t have to worry about this problem (and neither do you). Likewise, mobile devices that use the Exchange ActiveSync (EAS) protocol won’t be affected by this.

If you’re curious about the Client Submission Port, you can find out more details (and benefits) from a blog post I wrote, “TCP Port 25 Considered Harmful?”

Number 4: Disable HTTP connections

Obviously, I’m not telling you to disable all HTTP-based protocols. Basic HTTP is a security risk, though, because it transmits all data in cleartext; anyone who is snooping the connection can listen to every bit of data and reconstruct your users’ messages. As a result, anytime you’re deploying HTTP-based protocols, you should always enable encryption through SSL (or its successor protocol TLS). This helps protect you and your users when they connect, especially when using Basic authentication (as is common for many mobile devices).

It is surprising how many people know that they need to use SSL and enable it, then proceed to merrily publish both the secure and insecure versions of the protocol to the outside world. One common reason for doing it is troubleshooting: it can be much easier to troubleshoot unencrypted connections. However, once you’ve performed your initial testing and verified your publishing configuration, you should disable plain HTTP.

Number 3: Don’t use default certificates on Internet-facing server roles

One of the biggest sources of objections to using SSL and TLS is the requirement for X.509 digital certificates. Some common objections I’ve heard include:

The Exchange Server product team has heard these objections (and more) over the years and finally addressed it in Exchange Server 2007. When you set up each Exchange Server 2007 server, the installer will generate a self-signed certificate that the server uses to secure communications with other Exchange Server 2007 servers and Office Outlook 2007 clients. If you have a pre-existing certificate on the machine (maybe you already have a PKI deployed, such as Windows Certificate Services), you can specify this certificate during Setup. Exchange Server 2007 will happily use that certificate instead.

These self-signed certificates are a great security step forward for organizations that don’t have anything deployed; just by upgrading, they now get the benefit of secure transport communications without performing any extra work. They’ll even work as you publish services out to the Internet, after a fashion; Office Outlook clients will give certificate warnings, which will be worrisome and annoying to your users, while other clients (including Windows Mobile devices) won’t be able to use these self-signed certificates.

As a result, you should, at a minimum, hedge your bets. By that I mean even if you make use of the self-signed certificates inside of your organization, purchase commercial certificates from a reputable certificate authority for use with your SMTP and HTTP servers – that is, any host (whether a client or server) that will be initiating or receiving connections from the Internet. Here are some issues you should watch out for:

For additional information on deploying commercial certificates, you should read the Exchange 2007 Autodiscover Service whitepaper and the Managing SSL for a Client Access Server documentation topic.

Number 2: Use the Security Configuration Wizard

By now, we’ve all heard the security mantra “defense in depth” often enough that it’s actually sinking in. We all know that a strong defense strategy means not only using secure features and technologies, but also using firewalls to limit access between your servers and hosts on other networks. As a final layer of defense, you also need to harden your Exchange servers; this means shutting down unnecessary services and reducing the potential vectors for attackers to successfully exploit, even if they get through the other defenses. As an example, Exchange servers don’t need to act as file servers in most circumstances, so you don’t need to keep the Windows File and Print Services bindings active on your network interfaces.

Over the years, a number of people and companies, including Microsoft, have developed hardening checklists and procedures for each version of Exchange Server. With Exchange Server 2007, though, Microsoft makes it a lot easier to harden your servers by using the Security Configuration Wizard (SCW). The SCW, an optional component first introduced in Windows Server 2003 Service Pack 1, uses a library of XML files to help determine which services, settings, and ports can be safely shut down without affecting the applications the server is running.

Once you have the SCW component installed, you need to tell it about Exchange Server 2007; by default, it only knows about Exchange Server 2003. To do this, you need to register the Exchange 2007 SCW extensions, which are two XML files that provide the information the SCW needs to successfully harden Exchange Server 2007 servers. These files are included with Exchange Server 2007; which ones you use are determined by the server roles installed on the server, as shown in Table 1.

Once you’ve gotten the extensions installed, you can use the SCW to harden your Exchange Server 2007 servers as shown in Figure 2.

Number 1: Place your Exchange Servers correctly

With Exchange Server 2003 and previous versions, you had a lot of network design issues that you had to consider when you were securing your Exchange deployment. The question that generated some of the most discussion, though, is where to place front-end servers and external bridgehead servers. The two main options -- the interior protected network or a perimeter network -- were both supported by Microsoft, but they offered different tradeoffs:

With Exchange Server 2007 multiple role architecture, this question becomes simple to answer as shown in Figure 3. The only Exchange Server 2007 role that is supported in a perimeter network is Edge Transport; all four other roles are only supported in your interior protected network.

---