Well, here we go again! It’s been awhile since I posted anything, but that’s sort of how things go. I felt like it was time to share and document the right away to secure an email proxy. I know there is plenty of documentation out there on this, but I thought it would be helpful to put my own spin on it and help you understand why it actually matters.

We will cover SSL security hardening and then go into some simple tweaks you can do on IIS to protect yourself from potential DDoS or silly little things that create load on your server.

SSL Hardening

So, there are a few key tenets to truly hardening your SSL posture on your server:

1. Disable Weak Ciphers
2. Disable Weak Protocols
3. Protect against attacks that downgrade your Protocols
4. Protect long-term keys
5. Use SHA-2 SSL certificates with SANs
6. Implement several best practice HTTP Response Headers
7. Setting the cipher preference
8. Always use SSL bridging on your load balancer. Offloading is just terrible for performance and not the right thing to do for email.

If you do these things, you can create a secure and tight security posture in your environment. Let me help you with that! I promise it isn’t TOO painful.

First…let’s start with my super little script for disabling ciphers, protocols, and setting the proper cipher preference.

You can access the script here. This script is very useful and does a few things for you:

• Enables TLS 1.1+1.2 and disables all the other icky protocols.
• Disables insecure ciphers
• Enables secure ciphers
• Sets cipher strength order (aka Perfect Forward Secrecy)
• Sets hashes and key exchange algorithm

I can’t take all the credit as I found an existing script and enhanced it to take care of a bunch of things all at once. So you see this script does almost everything that you need to do to fully secure your environment.

Now we can move onto some IIS tweaks…

You will want to go into IIS on your server, expand default website and then click on HTTP Response Headers. Once you have done that, you should add these keys:

Obviously the ASP.net one is already there, but these are very useful and one of them “Strict-Transport-Security” will protect you against attackers trying to bounce you from HTTPs down to HTTP. That’s bad in case you didn’t know! These items will get you an A in SSL Labs. Unfortunately you can’t pull off a A+ when you do SSL bridging because IIS does not support HSTS (simply, protocol downgrade attacks). The way that I address HSTS is by disabling every protocol that I can. You can also modify my Powershell script to disable TLS 1.1 as a poor man’s HSTS.

Additional IIS Hardening

If you are following this so far, you already have a strong SSL posture, but let’s focus on really locking things down and protecting yourself. Many enterprises have port scanning tools or engines that test your environment’s stability. It’s a good opportunity to address this so you can protect yourself from things terrorizing your web server and impacting performance.

Let’s start by installing two things: (1) Domain IP Restrictions and (2) URL Re-writing:

You want to run this command in Powershell first to install Domain IP Restrictions:

Install-WindowsFeature Web-IP-Security

Second, you want to install this MSI on your server to get URL re-writing installing in IIS

Configure URL Re-Writing Rules

The first thing you want to do is look at your IIS Logs and figure out what “Good Actors” are hitting your web server. You absolutely must make sure that you aren’t sacrificing or breaking key aspects of your environment because you are trying to make things solid. One example of this that I would hope most of you use is something like Site24x7 for your external monitoring. It’s vital to know when external endpoints go KABOOM! So in this example, you would create a policy like this below at the Default Website:

You click “Add Rule” and “Request Blocking” then create a policy that looks like this:

This policy basically states, that anything that isn’t using the Site24x7 User Agent hitting your root website will have its request aborted. This is a key principal to controlling/securing your traffic.

Next, you want to go down to Microsoft-Server-ActiveSync and create another rule for request blocking. This rule will basically say anything that isn’t one of these user agents (i.e. iPhone, iPad, or Boxer) will be blocked when trying to hit the EAS site:

Hardening your Servlet and other non-ActiveSync subsites

The other subsites can be a little bit challenging to lockdown. The best way that I have been able to ensure they are secured effectively is with Domain IP Restrictions.  First we configure the “Feature Settings” for the Domain IP Restrictions for a specific subsite.

Once you have done that, you just configure a rule to only allow your localhost IP address:

In Closing

This is my shortest blog, but I don’t see any point rambling on all over the place. I struggled through many of these items for quite some time, but I’m glad that I finally have it working perfectly. Hopefully this will help you continue to build a stronger and more fluid environment. Feel free to reach out to me with any questions or thoughts.