Introduction
This article contains my favorites for general adjustments to the Exchange environment after or during installation. The hardening measures described below are very general, so they can be applied to existing and new environments.
The measures relate to the Exchange Server and the operating system itself; whether the measures are necessary or superfluous in your own environment is a matter for you to decide / evaluate.
Hardening als Keyword ist an dieser Stelle übertrieben, es handelt sich eher um meine „Basis Sicherheitsrichtlinie“: Einfach und immer umzusetzen.
Deactivate old SSL/TLS protocols
The outdated SSL2, SSL3 and TLS1 protocols should no longer be used, as there are known vulnerabilities that can be exploited for attacks. However, the old protocols are still activated for compatibility reasons. The old protocols should therefore be deactivated, even if this means that outdated software can no longer be used as a client.
The easiest way to deactivate old protocols and ciphers is to use the IIS Crypto tool. IIS Crypto can be downloaded here:
Once the tool has been started on the Exchange server, simply click on "Best Practices" to deactivate the old SSL protocols. TLS1 must be deselected separately so that it is also deactivated:
The settings are applied after restarting the server. Further information can be found here:
Chrome and Windows Server 2016: ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY
Deactivate X-AspNet version
By default, the IIS transmits the ASP version used. Switching off the version transfer does not directly increase security, but if someone is already looking for vulnerabilities, then you don't necessarily have to lay trails.
The transmission of the ASP version used can be switched off in the "Configuration Editor" of the IIS server:
In the Section field, the entry "system.web/httpRuntime" must be selected, then the value for "enableVersionHeader" can be set to "False":
This deactivates the version transfer in the HTTP header of the IIS.
Header Firewall
In the standard configuration, Exchange writes some internal information to the mail header. If the header firewall is not activated, internal IPs and host names are visible, for example:
Here is the mail header with the header firewall activated, with significantly less information in the header:
Less information makes the automatic vulnerability search more difficult. The header firewall can be easily activated via the Exchange Management Shell:
Get-SendConnector | Remove-ADPermission -User "NT-AUTORITÄT\ANONYMOUS-ANMELDUNG" -ExtendedRights ms-Exch-Send-Headers-Routing
Nothing more is required to activate the header firewall.
Deactivate NetBIOS via TCP/IP
NetBIOS over TCP/IP is considered problematic by many vulnerability scanners; it is not required for Exchange and can therefore be deactivated.
NetBIOS can be deactivated via TCP/IP in the properties of the network connection:
Deactivate SMB1
SMB in version 1 is already several years old and has a few known vulnerabilities, but it is activated by default:
The following command is sufficient to switch off SMB1:
Set-SmbServerConfiguration -EnableSMB1Protocol $false
The command only deactivates SMB1. SMB2 and SMB3 remain untouched. SMB2 and SMB3 should not be deactivated.
Deactivate Exchange Administrative Center (EAC)
The Exchange Admin Center (EAC) is activated on all Exchange servers in the standard configuration. If the Exchange server(s) are published on the Internet via NAT or Web Application Firewall, the EAC is also connected to the Internet. The EAC can be switched off for each server, but it is then also switched off for the internal network. In larger environments with several Exchange servers, this is not normally a problem. For example, two Exchange servers can be published on the Internet via a web application firewall and a third Exchange server is used for administration and is only activated in the event of an error.
If there is only one Exchange Server in the company, you can use a small workaround. An additional IP address is assigned to the Exchange server:
A new website is now created in the IIS, which is bound to the previously configured IP:
A new ECP and OWA directory are created for the new website:
New-EcpVirtualDirectory -Server ETEX1 -WebSiteName EAC New-OwaVirtualDirectory -Server ETEX1 -WebSiteName EAC
The EAC can now be accessed under the additionally configured IP:
Access can now be switched off for the EAC that is published on the Internet, in this case the IP 172.16.100.26:
Get-EcpVirtualDirectory "ecp (Default Web Site)" | Set-EcpVirtualDirectory -AdminEnabled:$false
Once the changes have been applied, access to the EAC is only possible via the additional IP 172.16.100.99. If the router or web application firewall only routes connections to 172.16.100.26, access to EAC from the Internet is no longer possible.
Deactivate local administrator
Deactivating the local "Administrator" account is almost as old as Windows itself and is therefore standard. Brute force attacks are much more difficult if the user name is not known in advance.
The local account "Administrator" should not only be renamed, but a new local user should be created that is assigned the role "Administrators". To do this, a new local user account must first be created:
The new user account is then added to the "Administrators" group on the Exchange Server:
The "Administrator" account can now be deactivated:
Of course, not only the local administrator should be deactivated, but also the "Administrator" account in the Active Directory.
Keeping software up to date / uninstalling unnecessary software
There is no need to mention the importance of regularly updating the software used, because it is clear to everyone anyway. But it is not enough just to install Windows updates regularly and as soon as possible; all other components must also be kept up to date:
- Firmwares
- Drivers
- BIOS or VMware Tools / Hyper-V Tools
- Additional software on the Exchange server (backup agent, virus scanner, etc.)
- Exchange Server (current CUs)
- Windows Updates
If you are already updating the components, it is also worth looking at the installed programs and tools. Adobe Flash / Reader, Firefox, Chrome, Java, Classic Shell and so on and so forth have NOTHING to do on an Exchange Server. Additional Windows features that are not required by Exchange also have no place on the Exchange Server.
Windows Firewall
Basically, nothing needs to be changed in the Windows firewall. Exchange creates all the necessary rules during installation. In some environments, however, the Windows Firewall is deactivated via GPO or manually. There is no reason to deactivate the Windows Firewall, additional rules may be necessary for certain tools (backup, virus scanner), but the firewall should remain activated in any case:
