Exchange 2016 Installation absichern (Hardening)

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:

Nartac IIS Crypto

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:

image

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:

image

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:

IIS Hardening

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:

SNAGHTML94a1c

Hier der Mail Header mit aktivierter Header Firewall, hier stehen deutlich weniger Informationen im Header:

SNAGHTMLa0abd

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

image

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:

image

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:

image

Um SMB1 abzuschalten genügt der folgende Befehl:

Set-SmbServerConfiguration -EnableSMB1Protocol $false

image

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:

image

Im IIS wird nun eine neue Website angelegt, die an die zuvor konfigurierte IP gebunden wird:

image

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

image

Jetzt kann unter der zusätzlich konfigurierten IP auf das EAC zugegriffen werden:

image

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

image

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:

image

Das neue Benutzerkonto wird dann der Gruppe “Administratoren” auf dem Exchange Server hinzugefügt:

image

Jetzt kann das Konto “Administrator” deaktiviert werden:

image

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:

image

15 Replies to “Exchange 2016 Installation absichern (Hardening)”

  1. 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 =)

  2. 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

  3. 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.

  4. 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

  5. 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

  6. 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

  7. Die Deaktivierung von TLS 1.0 ist für den Betrieb von Exchange Server NICHT supported. Davon ist dringend abzuraten.

    Gruß,
    Thomas

  8. 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?

  9. 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.

  10. 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!

  11. 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

  12. 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

  13. 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

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.