WatchPoint Security Blog

Hardening Exchange Server

Written by Nathan Studebaker | January 20, 2015

There have been several attacks on various SSL configurations over the last few years, so it is important to keep your systems up to date with patches and best practice configurations. Microsoft Exchange is one of those services that uses SSL for secure communication. This article will focus on hardening a Microsoft Exchange server by disabling old cipher suites and old versions of SSL.

What are cipher suites and what is SSL/TLS? A cipher suite is simply a collection of authentication and encryption algorithms used for secure network communication. SSL/TLS is a protocol that governs how the communication is done. Together, SSL/TLS provide the framework for the secure communication and the cipher suites perform the function of actually securing the connection.

Again, the reason that this is relevant is because there have been several attacks on SSL and because Microsoft Exchange uses SSL, we want our system to be as secure as possible. We will harden our system, disabling old cipher suites and protocols that have known exploits. A good place to read more about this is through the SSL Labs website (www.ssllabs.com). This website provides a great deal of information about the vulnerabilities found in these outdated cipher suites and protocols, and it also includes a free tool that will grade your server on how secure it really is.

The first step is to know what is supported and enabled by default on your current Exchange server version. Below is a summary of the important differences between Windows Server versions:

 

  • Window Server 2003 has SSL 2.0/3.0 and TLS 1.0 enabled by default. The default installation did not support AES ciphers – but support could be added through a hotfix.
  • Window Server 2008 also has SSL 2.0/3.0 and TLS 1.0 enabled by default, but this time they supported the AES cipher suites out of the box.
  • Window Server 2008 R2 introduced TLS 1.1 and TLS 1.2, but they were disabled by default. TLS is a newer replacement for SSL and is more secure.
  • Window Server 2012 takes us a step further with TLS 1.2 enabled by default.

 

As you can see, many items are supported but not enabled by default, so its our job as the technician is to enable these secure features. The good news is that these features can be easily disabled/enabled through registry changes and powershell scripts. Here is a link http://axisbu.com/steps-needed-to-harden-a-microsoft-exchange-server/ to another article which outlines the registry keys and powershell commands you'll need to harden your server. Please make sure to make a backup copy of your registry before making any changes. Below is summary of current recommendations and what the text files will disable/enable. For a more detailed explanation please visit www.ssllabs.com.

 

Current TLS recommendations

The SSL Labs TLS configuration guidance was updated recently (v1.3), introducing new recommendations. Here’s the change log:

  • Recommend replacing 1024-bit certificates straight away.
  • Recommend against supporting SSL v3.
  • Remove the recommendation to use RC4 to mitigate the BEAST attack server-side.
  • Recommend that RC4 is disabled.
  • Recommend that 3DES is disabled in the near future.
  • Recommend supporting Forward Secrecy.

 

Replacing 1024-bit Certificates:

The new recommendation is to replace 1024 bit certificates with 2048 bit certificates. This involves re-keying your SSL certificate with a newer/more secure certificate.

 

Disabling SSL v3

Even though SSLv3 is not susceptible to the POODLE exploit like SSLv2 was, it is now recommended to disable SSL entirely in favor of TLS. Older browsers like IE verison 6 and other browsers used on Windows XP are about the only clients who wouldn’t support TLS, so the impact of this is on your end users should be minimal.

 

Disable RC4 ciphers

The RC4 cipher is now considered insecure and it is recommended that you disable it.

 

Disable 3des

This one needs to be considered before deploying. Windows XP does not support the AES cipher suites for TLS 1.0 and after disabling RC4, XP clients would be then using 3des. Find out if any of your users still use XP before disabling this one. We know that XP is end of life, but that doesn't mean users aren't still running it.

 

Forward Secrecy

This has to do with the sessions keys that are used during the TLS session. Essentially it forces new keys to be generated for each session. This prevents attackers from using an old session key to eaves drop on the communication.

 

As was mentioned earlier, SSL Labs has a great free utility that you can use to test the strength of your cipher suites. We recommend running the test before and after to make sure everything worked as planned. If you followed these instructions you should have a rating of B or better.