Einleitung
Dieser Artikel beinhaltet meine Favoriten für die generellen Anpassungen der Exchange Umgebung nach bzw. während der Installation. Die im folgenden beschriebenen Maßnahmen für das Hardening sind sehr allgemein, sodass sie auf bestehende und neue Umgebungen angewendet werden können.
Die Maßnahmen beziehen sich auf den Exchange Server und das Betriebssystem selbst, ob die Maßnahmen in der eigenen Umgebung nötig oder überflüssig sind, muss jeder selbst entscheiden / bewerten.
Hardening als Keyword ist an dieser Stelle übertrieben, es handelt sich eher um meine „Basis Sicherheitsrichtlinie“: Einfach und immer umzusetzen.
Alte SSL/TLS Protokolle deaktivieren
Die veralteten Protokolle SSL2, SSL3 und TLS1 sollten nicht mehr eingesetzt werden, denn es gibt bekannte Schwachstellen die für Angriffe ausgenutzt werden können. Die alten Protokolle sind aber aus Kompatibilitätsgründen immer noch aktiviert. Daher sollten die alten Protokolle deaktiviert werden, auch wenn dies bedeutet, dass veraltete Software als Client nicht mehr genutzt werden kann.
Alte Protokolle und Cipher lassen sich am Einfachsten mit dem Tool IIS Crypto deaktivieren. IIS Crypto kann hier runtergeladen werden:
Nachdem das Tool auf dem Exchange Server gestartet wurde, reicht ein Klick auf “Best Practises” um die alten SSL Protokolle zu deaktivieren. Damit auch TLS1 abgeschaltet wird, muss dieses noch separat abgewählt werden:
Die Einstellungen werden nach einem Neustart des Servers angewendet. Hier gibt es weitere Informationen:
Chrome und Windows Server 2016: ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY
X-AspNet-Version deaktivieren
In der Standardeinstellung übermittelt der IIS die eingesetzte ASP Version. Zwar erhöht das Abschalten der Versionsübermittlung nicht direkt die Sicherheit, aber wenn schon jemand nach Schwachstellen sucht, dann muss man ja nicht unbedingt noch Fährten legen.
Im “Konfigurations-Editor” des IIS Servers lässt sich die Übermittlung der eingesetzten ASP Version abschalten:
Im Feld Abschnitt muss dazu der Eintrag “system.web/httpRuntime” ausgewählt werden, dann kann der Wert für “enableVersionHeader” auf den Wert “False” gesetzt werden:
Dies deaktiviert die Versionsübermittlung im HTTP-Header des IIS.
Header Firewall
In der Standardkonfiguration schreibt Exchange einige interne Informationen in den Mail Header. Ohne aktivierte Header Firewall sind zum Beispiel interne IPs und Hostnamen sichtbar:
Hier der Mail Header mit aktivierter Header Firewall, hier stehen deutlich weniger Informationen im Header:
Weniger Informationen erschweren die automatische Schwachstellensuche. Die Header Firewall kann einfach per Exchange Management Shell aktiviert werden:
Get-SendConnector | Remove-ADPermission -User "NT-AUTORITÄT\ANONYMOUS-ANMELDUNG" -ExtendedRights ms-Exch-Send-Headers-Routing
Mehr ist nicht nötig um die Header Firewall einzuschalten.
NetBIOS über TCP/IP deaktivieren
NetBIOS über TCP/IP wird von vielen Schwachstellenscannern als problematisch angesehen, für Exchange wird es nicht benötigt und kann daher deaktiviert werden.
In den Eigenschaften der Netzwerkverbindung kann NetBIOS über TCP/IP deaktiviert werden:
SMB1 deaktivieren
SMB in der Version1 ist schon einige Jahre alt und weißt ein paar bekannte Schwachstellen auf, in der Standardeinstellung ist es allerdings aktiviert:
Um SMB1 abzuschalten genügt der folgende Befehl:
Set-SmbServerConfiguration -EnableSMB1Protocol $false
Der Befehl deaktiviert nur SMB1. SMB2 und SMB3 bleiben davon unangetastet. SMB2 und SMB3 sollten nicht deaktiviert werden.
Exchange Administrative Center (EAC) deaktivieren
Das Exchange Admin Center (EAC) ist in der Standardkonfiguration auf allen Exchange Servern aktiviert. Werden der oder die Exchange Server per NAT oder Web Application Firewall im Internet veröffentlicht, hängt auch das EAC im Internet. Die EAC lässt sich je Server abschalten, allerdings wird sie dann auch für das interne Netzwerk abgeschaltet. In größeren Umgebungen mit mehreren Exchange Servern ist dies normalerweise kein Problem, hier können beispielsweise 2 Exchange Server im Internet per Web Application Firewall veröffentlicht werden und ein dritter Exchange Server wird für die Administration benutzt und nur im Fehlerfall aktiviert.
Wenn nur ein Exchange Server im Unternehmen vorhanden ist, kann man sich mit einem kleinen Workaround behelfen. Dem Exchange Server wird eine zusätzliche IP Adresse vergeben:
Im IIS wird nun eine neue Website angelegt, die an die zuvor konfigurierte IP gebunden wird:
Für die neue Website werden ein neues ECP und OWA Verzeichnis angelegt:
New-EcpVirtualDirectory -Server ETEX1 -WebSiteName EAC New-OwaVirtualDirectory -Server ETEX1 -WebSiteName EAC
Jetzt kann unter der zusätzlich konfigurierten IP auf das EAC zugegriffen werden:
Für das EAC welches im Internet veröffentlicht wird, in diesem Fall die IP 172.16.100.26, kann der Zugriff nun abgeschaltet werden:
Get-EcpVirtualDirectory "ecp (Default Web Site)" | Set-EcpVirtualDirectory -AdminEnabled:$false
Nachdem die Änderungen übernommen wurden, ist der Zugriff auf das EAC nur noch über die zusätzliche IP 172.16.100.99 möglich. Sofern der Router oder Web Application Firewall Verbindungen nur an die 172.16.100.26 leitet, ist der Zugriff aus dem Internet auf EAC nicht mehr möglich.
Lokalen Administrator deaktivieren
Das Deaktivieren des lokalen Kontos “Administrator” ist schon beinahe so alt wie Windows selbst und gehört damit zum Standard. BruteForce Attacken werden deutlich schwieriger, wenn der Benutzername nicht im Vorfeld bekannt ist.
Das lokale Konto “Administrator” sollte nicht nur umbenannt werden, sondern ein neuer lokaler Benutzer erstellt werden, der die Rolle “Administratoren” bekommt. Dazu muss zunächst ein neues lokales Benutzerkonto erstellt werden:
Das neue Benutzerkonto wird dann der Gruppe “Administratoren” auf dem Exchange Server hinzugefügt:
Jetzt kann das Konto “Administrator” deaktiviert werden:
Natürlich sollte nicht nur der lokale Administrator deaktiviert werden, sondern auch das Konto “Administrator” im Active Directory.
Software auf dem aktuellen Stand halten / Unnötige Software deinstallieren
Das regelmäßiges Aktualisieren der eingesetzten Software wichtig ist, brauch nicht erwähnt werden, denn es ist eh jedem klar. Aber es reicht nicht nur regelmäßig und möglichst zeitnah die Windows Updates zu installieren, auch alle anderen Komponenten müssen auf dem aktuellen Stand gehalten werden:
- Firmwares
- Treiber
- BIOS oder VMware Tools / Hyper-V Tools
- zusätzliche Software auf dem Exchange Server (Backup Agent, Virenscanner, etc)
- Exchange Server (aktuelle CUs)
- Windows Updates
Wenn man schon dabei ist die Komponenten zu aktualisieren, lohnt es sich auch über die installierten Programme und Tools zu schauen. Adobe Flash / Reader, Firefox, Chrome, Java, Classic Shell und so weiter und so weiter, haben NICHTS auf einem Exchange Server verloren. Zusätzliche Windows Features die nicht von Exchange vorausgesetzt werden, haben ebenfalls nichts auf dem Exchange Server zu suchen.
Windows Firewall
An der Windows Firewall muss im Grunde nichts verändert werden. Exchange erstellt während der Installation alle nötigen Regeln. In manchen Umgebungen wird die Windows Firewall allerdings per GPO oder manuell deaktiviert. Es gibt keinen Grund die Windows Firewall abzuschalten, vielleicht sind zusätzliche Regeln für bestimmte Tools nötig (Backup, Virenscanner), die Firewall sollte aber in jedem Fall aktiviert bleiben:
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 =)