Locking down your Exchange server with cipher suites

In today’s world, security is the keyword on everyone’s lips. This not only applies to your front door but to your applications that are exposed to the Internet. Hackers — those guys and sometimes gals who thrive on dishing out malware or ransomware — look for every opportunity to gain access to your environment and to wreak havoc. In this article, we will be looking at the newer versions of Exchange and the cipher suites they use and how you can minimize the blast area by securing your environment. Let’s dive straight in.

What is a cipher suite?

Cipher suites are a set of algorithms that you need to secure your environment, either by using SSL and TLS.

  • SSL (Secure Sockets Layer)
  • TLS (Transport Layer Security)

Cipher suites: Algorithms weak and strong

cipher suites

There are several algorithms, some very weak and others strong. The weak ones mean that the Dark Web can attack and gain access to your system if you do not properly secure it. What are these algorithms?

Key Exchange examples

  • ECDH
  • ECDHE
  • DH
  • RSA

Authentication algorithm examples

  • ECDSA
  • DSA

Encryption algorithm examples

  • CAMELLIA
  • 3DES
  • AES

Locking down your Exchange server, firewall, and load balancer

cipher suites

When working with these cipher suites, you need to look at locking down not only your Exchange server but also the firewall or load balancer in front of it. I went through an exercise of testing all the scenarios to get to that A+ or higher status and it involves many things, namely:

  • Using a tool like IIS Crypto to make changes to the operating system.
  • Adding another layer to IIS to give you that extra layer of security.
  • Removing cipher suites on your F5 device or firewall that don’t need to be there. This will lessen the surface attack area.

First of all, how would you know your URL, which you believe is secure, is actually not so secure? Well, you can use a website like SSL Labs that will go and put it through its paces and give you a report of how good or bad your website is and show you what you need to fix. It is a good starting point because it will tell you if you have weak ciphers enabled or are using older protocols that can be attacked because they have been in the past. It also checks your SSL certificate and tells you of any issues such as missing the root certificate or if the chain is not valid.

Every company has its own requirements and with the IIS Crypto Tool, you can experiment on a server (not in production) and a new partition on your F5, for example, to get to that sweet spot. Maybe you have installed a “free” certificate because you want to save costs, but you are just inviting people into your environment as they can now spoof or imitate an SSL certificate.

Let’s take a brief look at the IIS Crypto tool. Version 3 is out now. I have used this tool, which is why I am writing about it, but you can search the web for others if you not comfortable using it.

With the tool, you can perform the following:

  • Changing the SChannel
  • Changing the cipher suites
  • Create templates

You can make use of the best practices or you can toggle between:

  • Server protocols
  • Ciphers
  • Hashes
  • Key exchanges
  • Client protocols

TLS 1.2: The future is now

As you know, many organizations are moving away from TLS 1.0 and TLS 1.1 and now require TLS 1.2 or will be requiring it, not only for email but also for payments. I would advise that you make a backup of your registry before making changes and as mentioned, test it out first before applying it to a production server. The next thing you would need to do is take a backup of your load balancer if it is Kemp or F5 before making changes.

Once you have worked on what you want enabled and removed on your server, you need to apply the same to your load balancer so they match. When you are finished, head over to SSL Labs or any other website that does the checking and see what your site is scoring. If you are happy with the result then leave it and set it as your new “blueprint” for the next server. You can create a template from your current settings and then use the command line to just import it to the next one. As mentioned, if you are not comfortable using a third-party to modify the SChannels, you can head over to Microsoft’s website and use their settings.

What are some of the attacks that are on the Internet that can cause harm to your company? Here are a few, but I will not go into much detail on them:

  • Poodle
  • Freak
  • Beast
  • Drown

Some of them listed above caused havoc and have been around for several years. You can do a Google search on each one to better understand the dangers they pose for you.

Make the right choice — buy an SSL certificate from a reputable company. Spend the time and ensure that you have your company’s interests at heart and secure your environment. Nobody wants to come into work and have to fix an attack from one of the above or deal with other issues like ransomware or hijacking of your SSL certificate.

Featured image: Shutterstock

About The Author

1 thought on “Locking down your Exchange server with cipher suites”

  1. This is an excellent start on what I consider to be a much bigger subject. Anyone deploying a Windows server which is running IIS should be aware of this aspect of security.

    There is a lot of detail to this subject, and unfortunately Windows as well as many other products come pre-configured with all of the oldest and most exploitable protocols and ciphers enabled. This is because it insures that the oldest client devices / software will be able to connect.

    What I learned when I went through this in 2016, is there is no one size fits all solution, there are considerations to everything and as such I found myself doing everything manually via the registry. Once I had a configuration I liked I deployed it to all of the servers using group policy where applicable, and registry updates for the rest to re-configure the servers.

    For an organization that does not already have standards for this I would not recommend starting with a tool like IIS Crypto to make and manage these incredibly granular changes. The reason I say this is that it is not always clear what / where IIS Crypto is making the change for each option.

    The client who I was working on in 2016 was extremely specific about what was and was not allowed, as well as preference for the order the cipher suites should be preferred by the server. What is more because the IIS server was only one layer of the overall security it was important to understand these concepts across multiple platforms, including firewall, application firewall, router, and load balancer.

    IIS Crypto seems like it could be an excellent tool for people that understand what exactly they want configured, and want to deploy that using a 3rd party solution that does not require the user to understand all of the nuances of this subject. The down side to this is that I have seen some clients that use IIS Crypto fail to manage these settings correctly, and fail security audits.
    All because the user that setup the server and ran IIS Crypto did not understand the details, and used a profile whose settings did not actually match the security policy they were being measured against.

    In testing my servers for the items discussed as well as others I found tools such as SSL labs online test only useful with servers that are completely exposed to the open internet, if any part of the server has protection measures between it and the open internet you will not get an accurate report of the potential vulnerabilities at the server level. From a security standpoint it is important to understand what vulnerabilities you have at each level. As such I prefer to use Nmap, via the Zenmap GUI. The tool is free to use and can provide the same level of testing and a lot more and it is done from the platform you are running on, so you are able to test from behind firewalls, etc… and get an accurate view of the individual server security. From there you can then test through the load balancer, and finally through the firewall, even if the site is not exposed to the internet.

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top