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 as a keyword is an exaggeration at this point, it's more my "basic security guideline": simple and always to be implemented.
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-AUTHORITY\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:
Hallo Frank.
Wie sieht das aktuell mit Exchange 2016 und CU22 aus? Funktioniert es hier mit abgeschaltetem TLS 1.0 ohne Problem?
Reichen beim IIS Deine Vorschläge aus, oder bedarf der IIS weiterer Härtungsmaßnahmen? Dazu gibt es ja einiges an Anleitungen.
Vielen Dank im Voraus für Deine Antwort.
Viele Grüße
Dirk
Ich hab den Befehlt szum deaktivieren der ECP Seite abgesetzt und trotz neustart ist die seite von Außen noch zu erreichen
Get-EcpVirtualDirectory „ecp (Default Web Site)“ | Set-EcpVirtualDirectory -AdminEnabled:$false
Was hab ich falsch gemacht?
Die nue Website geht aber bereits
Hallo,
möchte man das Ändern des Kennworts über OWA erlauben, dann muss man auch
Get-EcpVirtualDirectory „ecp (Default Web Site)“ | Set-EcpVirtualDirectory -owaoptionenabled:$true
setzen.
Viele Grüße
Hallo,
danke für das How-To. Anbei ein Hinweis für „Exchange Administrative Center (EAC) deaktivieren“.
Bei mir in Outlook erscheint der Hinweis „Zurzeit können keine Email-Infos angezeigt werden.“, wenn man eine E-Mail schreiben möchte.
Nach einigem Herumprobieren, bin ich darauf gestoßen, dass im DNS-Server für den exchange-server zwei DNS Einträge erzeugt werden, wenn man, wie oben beschrieben, dass EAC deaktiviert und dem exchange server eine zweite IP-Adresse zuweist, d.h. 192.16.100.26 und 192.16.100.99.
Wenn man nun im DNS den zweiten Eintrag für das EAC (192.168.100.99) löscht, der für das EAC vorgesehen ist, funktioniert Outlook wunderbar und ohne Hinweise wie oben beschrieben. Deshalb würde ich empfehlen, in den IP-Einstellungen unter „Erweiterte TCP/IP-Einstellungen“ im Reiter „DNS“ den Haken bei „Adressen dieser Verbindung im DNS registrieren“ zu deaktivieren. Man achte jedoch darauf, dass die Hauptadresse (192.16.100.26) im DNS weiter aufgelistet wird.
Hallo,
bitte obigen Kommentar ignorieren; Das Deaktiveren von „Adressen dieser Verbindung im DNS registrieren“ führt doch zu einigen Problemen.
Hallo,
bei uns ist das so, das wenn wir die 2te IP Adresse eintragen, der Exchange Server nach einer Weile gar keine Mails mehr versendet. Alle Mails bleiben in der Queue hängen. Erst wenn man die 2te IP Adresse wieder löscht und den Transport Dienst neu startet laufen auch die Mails wieder.
Deshalb können wir das so nicht umsetzten.
Oder hat noch jemand eine andere Idee dazu?
Hi Frank, im Zuge des aktuellen Exploits/der aktuellen Ausnutzung der 3 Schwachstellen: Gibt es Probleme wenn man dem IIS bei der Windows Integrated Authentifizierung die Extended Protection vorgibt (required)?
Hi Frank,
gilt das ganze auch noch für Exchange 2019?
Sollte sich ja nicht viel geändert haben oder?
Danke dir.
VG
Thomas
Hallo Thomas,
bei Exchange 2019 verhält sich einiges anders (TLS 1.2, Client Accessrules…). Daher bezieht sich dieser Artikel nur auf Exchange 2016.
Gruß,
Frnak
Hallo zusammen,
ich habe auch das Hardening durchgeführt mit dem IISCrypto (Win2016+Ex2016). Als ich dann aber mit dem CertificateAssistant ein neues Zertifikat bereitstellen wollte, erhielt ich immer Fehler: „Die zugrundeliegende Verbindung wurde getrennt…“.
Nach ein wenig Debugging stellt sich heraus, dass „New-ACMERegistration“ den Fehler ausgibt, weil keine Verbindung zustande kommt.
Auf die Lösung bin ich dann hier gestoßen: https://github.com/ebekker/ACMESharp/issues/124#issuecomment-379525513
Sollte vielleicht auch beim Certificate Assistant mit berücksichtigt werden
Schöne Grüße
Klaus
Hallo zusammen,
ich möchte diesen Thread neu aufgreifen. Wir haben das Hardening bereits letztes Jahr durchgeführt und TLS 1.0 deaktiviert ohne Probleme (durchgehend Outlook 2016 Clients).
Jetzt haben wir inzwischen zwei Exchange 2016 CU9 und eine DAG eingerichtet. Seitdem kam das Problem auf, dass man auf die Frei/Gebucht Zeiten von Benutzer nicht zugreifen konnte die sich auf dem anderen Server befanden. Wenn man die Datenbank auf den gleichen Server aktiviert hat konnte man den Kalender aktualisieren. Bei Usern wo man Editor Rechte am Kalender hat ging es in beiden Fällen.
Die Meldung im Eventlog lautete:
Protokollname: Application
Quelle: MSExchange Availability
Ereignis-ID: 4002
Aufgabenkategorie:Availability Service
Ebene: Fehler
Schlüsselwörter:Klassisch
Benutzer: Nicht zutreffend
Computer: EX2.domain.local
Beschreibung:
Process xxxx: ProxyWebRequest CrossSite from S-1-5-21-xxxxxxxxxxxxxxxxxxx to https://ex1.domain.local:444/EWS/Exchange.asmx failed. Caller SIDs: NetworkCredentials. The exception returned is Microsoft.Exchange.InfoWorker.Common.Availability.ProxyWebRequestProcessingException: Fehler bei Proxywebanforderung. —> System.Net.WebException: Die zugrunde liegende Verbindung wurde geschlossen: Unbekannter Fehler beim Empfangen.. —> System.ComponentModel.Win32Exception: Der Client und der Server können keine Daten austauschen, da sie nicht über einen gemeinsamen Algorithmus verfügen
Name of the server where exception originated: EX2. LID: 43532. Make sure that the Active Directory site/forest that contain the user’s mailbox has at least one local Exchange 2010 server running the Availability service. Turn up logging for the Availability service and test basic network connectivity.
Nach TAGELANGER Suche war das Problem tatsächlich das deaktivierte TLS 1.0. Ist jemand von euch ebenfalls über diesen Fehler gestolpert? Kann man dem Exchange das TLS 1.0 irgendwie untersagen (bug – feature ;-)? Übrigens auch ein Upgrade auf CU10 hatte nicht geholfen.
Danke und VG
Hallo Franky,
ich habe die EAC Seite eingerichtet. Der Link funktioniert auch mit der neuen IP. Bei der Anmeldung auf der Seite erhalte ich folgenden Fehler:
:-(
Da hat etwas nicht geklappt.
Es ist ein Problem beim Verwenden Ihres Postfachs aufgetreten.
X-ClientId: F77230ADA3ED4262AFACBC2D68B7C166
request-id 25d44201-982f-497b-9430-08c978877e09
X-OWA-Error Microsoft.Exchange.Data.Storage.ObjectNotFoundException
X-OWA-Version 15.1.1466.8
X-FEServer EXCHANGE
X-BEServer EXCHANGE
Date:30.05.2018 06:17:51
Hast Du da eine Idee?
Gruß Andreas
Die Leute die hier im Kommentar schreiben „Deaktivierung von TLS 1.0 ist für den Betrieb von Exchange Server NICHT supported“ ist totaler Blödsinn!
Microsoft selbst empfiehlt die Abschaltung von TLS 1.0 seit 2015! Seit 2015 befinden wir uns im SHA2 Zeitalter und dies sollte jeder wissen der einen Exchange oder Web Server aufsetzt. Selbst die Azure Office Systeme von Microsoft benutzen kein TLS 1.0!
Wer solche Kommentare wie oben schreibt der sollte sich zuvor mit seiner Exchange Umgebung auskennen. Und welche Clienten zum Einsatz kommen. Und keine Generelle falsche Empfehlung aussprechen die in Behauptung und Begründung falsch ist!
TLS 1.0 NICHT DEAKTIVIEREN!! Hatte gestern noch CU17 eingespielt und heute den Test mit dem deaktivieren von TLS 1.0 gemacht und es gab riesen Probleme mit den Outlook Clients. Auch mit Outlook 2016. Also besser die „Best Practise“ von dem Tool so übernehmen, dann passt alles.
Hallo Frank,
trotz der Altivierung habe ich die Info bekommen, dass der NDR ohne Ende interne Informationen preis gibt. Gibt es hierzu auch eine Lösung?
Die Deaktivierung von TLS 1.0 ist für den Betrieb von Exchange Server NICHT supported. Davon ist dringend abzuraten.
Gruß,
Thomas
Hallo,
habe IIS Crypto mit den Best Practices angewandt. Anschließend sind sämtliche Mails in der Queue hängen geblieben. Ich konnte das Problem dann wie folgt lösen:
Local Security Policy -> Security Settings -> Local Policies -> Security Options
Hier dann die Policy „System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing“ auf Enabled setzen.
Beste Grüße
Hey Frank,
danke für diesen Artikel. Wenn ich jedoch wie beschrieben das TLS 1.0 deaktiviere ist mein Eventlog voll Fehler und Outlook kann das OAB nicht mehr vom Exchange abrufen.
Ich hab ne Frage:
Wie deaktiviere ich den Firewall Header wieder?
Hi Christoph,
mit dem folgenden Befehl kannst du die Header Firewall wieder aktivieren:
Get-SendConnector | Add-ADPermission -User „NT-AUTORITÄT\ANONYMOUS-ANMELDUNG“ -ExtendedRights ms-Exch-Send-Headers-Routing
Gruß, Frank
Danke für das gute HowTo.
Macht es in der Ein-Server Konfiguration und beim Einsatz einer Web Application Firewall (Sophos-UTM) nicht Sinn, die URLs, welche nicht extern benötigt werden zum Beispiel EWS, ECP, usw. zu deaktivieren?
Schönen Gruß
Andreas
Hi Andreas,
zumindest ECP wird extern benötigt. Hier wird nicht nur das ECA veröffentlicht, sondern euch die Einstellungsseite für die Benutzer.
Gruß, Frank
Besten Dank für das nette HowTo.
Für das aktivieren der Header-Firewall musste ich auf einem englischen System einen anderen User angeben:
Get-SendConnector | Remove-ADPermission -User „NT AUTHORITY\ANONYMOUS LOGON“ -ExtendedRights ms-Exch-Send-Headers-Routing
Bei der EMC verwende ich einen haproxy der den Zugang nur von der internen Domain zulässt. das funktioniert auch ganz gut =)