written by: Finn Orfano•edited by: Bill Bunter•updated: 5/22/2011
No software can ever be completely secure just be installing it then forgetting about it. It is same with Exchange Server 2007, however these best practices mentioned below can give you best security value out of Exchange Server 2007.
slide 1 of 5
Using SSL And Disabling HTTP
For users to get their Exchange Server mailbox data from anywhere relies on the HTTP. Many applications such as Outlook Anywhere for Outlook 2007 and even Mac computers and Windows Mobile devices also depend on HTTP. Because basic HTTP transmits all data in cleartext, any hacker spying the connection can listen to every data bit and reconstruct your users’ messages. Therefore, it is necessary to enable encryption through SSL or TLS. This will provide full security to you and your users when they connect from a computer or a mobile device. It is true that not many people are aware of importance of using SSL. When you decide to use SSL, enable it and performed all the testing, you should then disable plain HTTP
slide 2 of 5
Using The Client Submission Port
The exchange Server 2007 has been designed to allow us quickly and securely configure Small Mail Transfer Protocol (SMTP). Its developers have separated the receive and the send functionality, as a result we now have Receive Connectors and Send Connectors. They allow you to more easily partition SMTP traffic between the server role and the client role.
A solution to this problem is proposed by Client Submission Port, by using two separate SMTP server ports – the default TCP port and an extra port 587. In Exchange 2007, the Default Receive Connector on TCP port 25 is implemented, meant to receive data from other SMTP servers and the Client Receive Connector on TCP port 587 is implemented to support the use of SMTP mail clients such as Outlook Express, Vista Mail, etc.
Using The Client Receive Connector port, your users get the ability to submit their messages to your servers, without needing to change their settings, even when they are remote.
slide 3 of 5
Placing Exchange Servers Correctly
With Exchange Server 2003 and prior versions, there has been lot of questions put forward. Most of those questions were about placing front-end servers and bridgehead servers. The recommended option was to placing the servers in the interior network but many people objected to it because they thought it to be a risk of letting connections from the Internet through their defensive layers without filtering. They found a way of filtering the connections by using proxy servers such as Microsoft’s ISA Server.
On the other hand, placing the servers in a perimeter network weakens the value of the perimeter network. Placing Servers in a perimeter network means opening many ports and connections to vital infrastructure servers. However, this practice was recommended before the invention of ISA server.
Since the release of Exchange Server 2007, its multiple role architecture has made it simple to answer those questions. The 2007 version of the Exchange Server now only supports Edge Transport in a perimeter network; the four other roles are solely supported in the interior network.
slide 4 of 5
Using the Security Configuration Wizard (SCW)
Many companies have deployed hardening checklists and procedures for each version of Exchange Server. Microsoft has made it a lot easier to harden the servers by using Security Configuration Wizard (SCW). It is an optional feature that uses a library of XML files to help determine which services, ports and settings can be safely shut down without affecting the applications the server is currently running. When you install the SCW component, you will also need to configure it for Exchange Server 2007 – by default, it only understands Exchange Server 2003. To do this, register the Exchange 2007 SCW extensions. These extensions are two XML files (Exchange2007.xml and Exchange2007Edge.xml) that supply the information the SCW needs to harden Exchange Server 2007 Servers. Once you have installed the extensions, use SCW to harden your Exchange Server 2007.
slide 5 of 5
Not Using Default Certificates
Although it is clear that SSL and TSL provides the security we all need, some people still object to using them because of its requirement for X.509 digital certificates. They think purchasing commercial certificates is too expensive and their deployment and troubleshooting is also complicated.
When we install Exchange Server 2007, a self-assigned certificate that the server uses is automatically generated. The self-signed certificates are a great security for businesses that do not have anything deployed. These certificates will even work as you publish services out to the Internet but the Office Outlook clients and Windows Mobile devices will either give certificate warnings or you won’t be able to use the self-signed certificates.
Therefore, even if you use the self-signed certificate inside of your organization, it is important to purchase commercial certificates from a trusted certificate authority for use with SMTP and HTTP servers. You might want to use wildcard certificates to cut down cost but be aware that mobile devices running Windows Mobile 5.0 and prior versions do not support wildcards. You have another option of specifying multiple hostnames on one certificate. Such a certificate uses the Subject Alternate Name (SAN) X.509 field. These certificates are harder to deploy and costs more, they may also cause complications if you are using ISA Server to publish your services. Moreover, ISA Server 2004 does not support the use of SAN certificates.