With all the news about information leaks, hackers, and encryption, it’s natural for security administrators to ask how to make an ultra-secure Microsoft Exchange Server deployment that’s good enough for any purpose outside of sending top secret information. I’ll show you how to build out an Exchange Server 2016 deployment in a Hyper-V virtual machine that is as secure as I can possibly make it while still allowing it to be usable. We're talking locked down, encryption both at rest and in transit, securely accessible from remote locations, and hardened against interlopers.
Specifically, I’ll explain how to build:
- An Exchange Server. I am sure a lot of people will roll their eyes and say Microsoft Exchange cannot ever be secured properly and that true security can only come from Sendmail or Postfix custom compiled. I take issue with that. Those solutions might work if you are hosting a server for yourself and perhaps a couple of other people, but Exchange has valuable groupware features.
Secondly, information lives both in e-mail and in calendars and contacts. Neither Sendmail nor Postfix address that in an integrated way. If you secure Exchange, you secure calendars, contacts, inboxes, journal entries, instant message conversation history, and more. Finally, most people prefer Outlook and Outlook simply works best with Exchange.
- A solution that works in the office and on the road. I want to focus on securing mobile access to Exchange as much as possible. Secure mobility is critically important. If there is a compromise to be made in this design, it will be in the name of security and not convenience. Anyone with any experience in this industry will tell you security and convenience are at odds with each other. I want to make intelligent and reasoned choices with this build that allow some convenience without compromising the overall integrity of the system.
- A simple one-box solution. I am not going to deploy multiple Exchange servers as part of an availability group. I am not going to cluster the Windows Server machines. I am not going to have attached storage or try to manage a SAN connection. Rather, I am going to keep it simple: The storage, server, and Exchange will all live on one box to the point where you can set this up on a single virtual machine and either run it in house or deploy it up in an infrastructure as a service environment like Amazon Web Services or Microsoft Azure.
This is a three-part operation. First, deploy Exchange. Second, secure the foundation both from a Windows Server and Exchange perspective. Finally, secure the network and implement the very latest in encryption and auditing technologies so that you have the best secure single Exchange Server implementation available. In fact, I am putting this system into production for my own business, so this is not a theoretical exercise. My organization will depend on this deployment.
Installing Exchange Server 2016 on your server
To install Exchange, I recommend using Michel de Rooij’s excellent PowerShell script that takes care of laying the Exchange Server 2016 bits down on your system. Although many other scripts are out there, this one takes the cake as far as laying down all the prerequisites including filter packs. Depending on which operating system you are going to install (I will use Windows Server 2016 as it is the latest baked release and is well supported, but the script provides support from Windows Server 2008 R2 Service Pack 1 on up through the current release), it prepares the Active Directory installation via the required schema updates, and it handles errors and exceptions nicely. The script is updated often—the last update as of this writing was on June 28, 2017.
The script requires you to have the Exchange ISO or source files nearby. One nice feature of Exchange 2013 and later versions, including 2016, is that all of the cumulative updates are actually full copies of Exchange. This means you can extract the cumulative update file to a directory and launch a greenfield Exchange installation from there that will be fresh and up to date from the start. This means that it always pays to have a local copy of the latest cumulative update extracted and ready to go. It can save you hours of updating efforts as patching existing servers can take extended amounts of time. Save that work for your servers that are already deployed. As of this writing, the latest version of Exchange 2016 was cumulative update 7, released on September 19, 2017.
Here is the command to launch the PowerShell script:
Install-Exchange15.ps1 -InstallBoth -SourcePath c:\exchange2016cu7 -Organization EightyTwoVentures -AutoPilot -Credentials
Once you run that command, a box pops up for you to enter administrator credentials. These credentials will be saved until the script run is complete—even if there is a reboot, the script preserves the credentials—and then deleted. You will want to allow for five or six reboots and about an hour or so to actually put the physical Exchange bits within your virtual machine, but by the end you should be ready to roll and have a functioning, if not configured, Exchange deployment ready.
Set up Bitlocker encryption
Part of security is encryption, and that means encrypting data both at rest (while it is stored on disk) as well as in transit (while it is being transmitted over the wire). Since we are dealing with Exchange, that means we have Windows Server, and that means we have Bitlocker, an industrial strength drive encryption mechanism that will suit our deployment just fine.
In fact, Bitlocker is part of the guidance for the Exchange Preferred Architecture, the “ideal world” scenario Microsoft lays out if you want a bulletproof Exchange deployment that exploits all the strengths and mitigates all the weaknesses of the product. Set up Bitlocker in Windows Server to encrypt the whole drive and be done with it — it is a two-step process. (Don’t lose your backup encryption keys, though.)
Create transport rules with Transport Layer Security (TLS)
The secure Exchange deployment mandates the use of TLS for security during transmissions. TLS is the equivalent of HTTPS and SSL for mail transmissions, resulting in the encryption of the entire data transmission portion of an SMTP conversation between mail servers. When an e-mail is sent, both the mail servers involved in the transaction exchange certificates and then agree to talk on an encrypted channel, and the message headers, body, and any attachments travel across that secure channel.
Most SMTP servers these days support opportunistic TLS, meaning that they will try to use TLS by default when contacting remote mail servers and also when accepting inbound mail to users homed in their organization sent from outside, but they will fall back to traditional clear text insecure SMTP if the other party does not support TLS.
You have to create a transport rule that requires TLS. This is different in Exchange 2016 (and 2013) than it used to be in earlier versions like 2007 and 2010 (the certificates don't matter here anymore if you are using this rule, so no fussing with certificates is necessary), so read through this carefully even if you are an old hat at Exchange.
- Create a transport rule within the Exchange Control Panel. Log in. Then on the left side click “mail flow,” and then in the top, select “rules” and then click the “+” icon and choose “Create a new rule...”
- You want this rule to apply to all messages, so give the rule a friendly name. Then under “*Apply this rule if...,” select the bottom option, “[Apply to all messages].” Then, under “*Do the following,” hover your mouse over “Modify the message security...” and click on “Require TLS encryption.”
- Make sure the “Enforce” radio button is selected under “Choose a mode for this rule” and then enter any change tracking or notes to yourself you would like to refer to under the comments section.
- Finally, click the save button at the bottom of the window. A warning will pop up: “Do you want this rule to apply to all future messages?” Click “Yes.”
Set up remote access via SSL VPN
A key part of this secure Exchange Server deployment is ensuring that anybody who talks to the Exchange Server is either a known quantity or comes from a known place (more on the latter later). An SSL VPN is generally considered the most secure of the practical ways of remotely accessing any service. It doesn't require special ports opened on your firewall, it wraps a session in a good layer of encryption, and it supports evaluating the current state of a supplicant attempting to connect to a service to make sure it has not been compromised.
An SSL VPN also has the advantage of making your remote client part of your local secure network, so you can manage and touch it as necessary to keep it safe and secure. For this ultra-secure Exchange deployment, I am making SSL VPN the only way of accessing the system, except from my local network where I will allow standard ActiveSync connectivity from Outlook clients. Fantastic SSL VPN appliances are available from a variety of vendors. You probably already have one. Just deploy that.
Set up the firewall
Securing Exchange means you also need a secure network. On your Hyper-V host you will want to remove network bindings from the physical host adapters to eliminate one way your host operating system could be compromised and prevent other workloads from running on the host.
On the edge, having this secure of a mail server basically means opening two ports: port 25, which you need to carry out SMTP transaction, and typically port 443 for HTTPS connections that are used to establish your SSL VPN session. For slightly more security mainly through obscurity, you may wish to change your SSL VPN port number to something random, but the procedure for doing so depends on your SSL VPN manufacturer. You will generally need to pick an alternate port number higher than 1024. If you do this, you will need to train users to use this port to connect to the SSL VPN to get their mail.
Is there any way to make port 25 more secure? There are two schools of thought on that:
- Belt-and-suspenders types appreciate the risk that malware, viruses, and spam in general present to uneducated users as well as the load that accepting all mail locally presents on a server. They will consequently choose to use a third-party messaging hygiene service. I am partial to Mailprotector, although Microsoft’s Exchange Online Protection is very useful as well.
If you choose to use a third-party hygiene service to block spam and viruses, then you can further lock down port 25 on your edge firewall to only the IP ranges that your message hygiene service uses. This way, your firewall will silently discard packets from any other sources and ensure that the only mail that gets to you has been through your hygiene service's servers. In addition, make sure your service provider supports requiring TLS so that the transmission encryption remains in place, and perhaps consider using their service as a smarthost (again with TLS required) so that you get outbound security as well. - The ultra-paranoid may be unwilling to trust that mail destined for you would traverse through cloud services at any point, and so you want all mail be delivered direct to you. That is certainly a requirement in some instances. In this case, you would almost certainly want TLS encryption to be forced on a connection. It is not a totally foolproof encryption mechanism because most mail servers, Exchange included, do not do any sort of verification on the certificates exchanged at the beginning of a transmission to prevent accepting and transmitting in clear text. Be forewarned: You will get a ton of spam over time with this scenario.
Last thoughts
Building a secure standalone Exchange deployment is a journey, not a checklist. While I’ve given you a mail server built on a solid foundation that encrypts data at rest and in transit and has just about as minimal an attack surface as possible, threats continue to evolve. Managing a mail server can be a full-time enterprise. This is a good start, but look after your server well.