Draußen spielen

von Christian Schulenburg

Lange war das Microsoft Threat Management Gateway der favorisierte Weg, um Exchange abzusichern und im Internet zu veröffentlichen. Mit der Aufgabe dieses Werkzeugs hat Microsoft zunächst eine große Lücke hinterlassen, die zahlreiche Drittanbieter auf den Plan rief. Es zeigt sich jedoch, dass die Zahl der direkt im Internet veröffentlichten Exchange-Server weiterhin sehr hoch ist. Wir schauen uns in diesem Workshop an, wie sich Exchange über einen Apache-Reverse-Proxy veröffentlichen lässt.

Der Hafnium Exploit verursachte im März 2021 viel Aufregung, schließlich erlaubte er es Angreifern, die reguläre Exchange-Authentifizierung zu umgehen und sich als Administrator anzumelden. Darüber hinaus waren die Bösewichte in der Lage, Dateien auf dem Exchange-Server abzulegen und auszuführen. Laut BSI waren allein in Deutschland potenziell etwa 57.000 Server betroffen. Bis die Lücke beim Großteil der Exchange Server schließlich geschlossen wurde, ging einige Zeit ins Land.

Reverse-Proxy als Sicherheitsmaßnahme

Um offene Sicherheitslücken schneller zu schließen, hat Microsoft einen Exchange Emergency Mitigation Service (EEMS) [1] direkt in Exchange integriert. Die neue Funktion prüft stündlich, ob es ein neues Regelwerk für eine Schwachstelle gibt und wendet diese Regel lokal an, um Lücken zu schließen. Der EEMS nimmt Exchange-Administratoren nicht das Einspielen von Updates ab und Fixes müssen diese nach deren Veröffentlichung auch weiterhin händisch einspielen.

Doch Angriffe fängt die Funktion nur verzögert ab und grundsätzlich sollten Sie Exchange nie ohne zusätzliche Sicherheitsvorkehrungen im Internet veröffentlichen. Ein reines Portforwarding an einer Firewall ist dabei nicht ausreichend und IT-Verantwortliche sollten daher den Einsatz einer Web Application Firewall (WAF) oder zumindest eines Reverse-Proxy ins Auge fassen.

Ein Proxy bietet dabei den großen Vorteil, dass er die nachgelagerten Server zunächst Richtung Internet verschleiert. Viele automatisierte Angriffe prüfen über den HTTP-Header, ob sie es mit einem IIS zu tun haben. Ist dies nicht der Fall, sparen sie Zeit und Ressourcen und suchen sich ein nächstes potenzielles Ziel. Durch die Aktivierung der Web Application Firewall lässt sich die Sicherheit des Exchange-Servers deutlich erhöhen. Wir schauen uns in diesem Workshop die Möglichkeiten eines Reverse-Proxy über einen Apache-Webserver an.

Testumgebung einrichten

Für den Workshop installieren wir in einer Exchange-2019-Umgebung zunächst einen Ubuntu-Server. Der Testaufbau befindet sich in Azure und durch die mittlerweile umfangreichen OS-Images ist Ubuntu 20.04 sehr schnell eingerichtet. Nach der Installation erstellen wir zunächst einen DNS-Namen für den Server auf der Azure-VM. Im Bereich der Netzwerkeinstellungen öffnen wir die Ports 80/443 für den externen Zugriff. Den eingerichteten DNS-Namen hinterlegen wir im öffentlichen DNS als cname für unsere Test-Domain "lab.schulenburg.co" und die Subdomains "outlook" und "autodiscover". Im Anschluss melden wir uns über die Azure Cloud Shell mittels ssh am Server an – ssh christian@outlook.lab.schulenburg.co.

Jetzt richten wir die "Uncomplicated Firewall" (UFW) unter Ubuntu ein. Bei UFW handelt es sich um das Standard-Firewall-Konfigurationswerkzeug für Ubuntu. Die Installation erfolgt mit

Standardmäßig ist der eingehende Verkehr an der Firewall unterbunden sowie der externe erlaubt. Um sicherzustellen, dass alles korrekt ist, setzen wir zunächst die Regeln auf die Standardeinstellungen zurück, bevor wir die Ports 22, 80 und 443 wieder explizit öffnen:

Im Anschluss aktivieren wir die Firewall über sudo ufw enables. Der Status der Firewall und das Regelwerk lassen sich einfach mit sudo ufw status anzeigen.

Apache an den Start bringen

Die Reverse-Proxy-Funktion stellt der Apache-Webserver bereit. Anders als unter Windows ist Apache in Unbuntu noch nicht installiert. Dies erledigen Sie mit

Im Anschluss aktivieren beziehungsweise deaktivieren Sie die nötigen Module. Teilweise sind diese mittlerweile ab Werk mitgeliefert, es schadet aber nicht, dies zur prüfen:

In die Konfiguration des Apache fügen Sie am Ende eine Zeile hinzu und starten den Server neu:

Im Anschluss richten Sie die Weiterleitung ein und deaktivieren die Standardkonfiguration. Für unsere neue Konfiguration legen wir eine leere Datei mittel "touch" an und aktivieren diese:

Der Apache-Webserver kann für unterschiedliche Aufrufe verschiedene Inhalte liefern (Virtual Hosting). Er entscheidet anhand des HTTP-Headers, welche Seite er ausliefert. Dabei legt das System pro virtuellem Host eine eigene Konfigurationsdatei an. In unserem Beispiel leiten wir alle Aufrufe an den Exchange-Server weiter, weshalb wir in der Konfiguration im Bereich "VirtualHost" mit einer Wildcard arbeiten. Daneben werden die einzelnen Exchange-Verzeichnisse über "ProxyPass" gesondert weitergeleitet. Auf die Weiterleitung des ECP-Verzeichnisses für das Exchange Administration Center (EAC) verzichten wir, sodass ein Zugriff von außen nicht möglich ist. Diese lässt sich auch über "Client Access Rules" am Exchange selber bewerkstelligen. Sofern das Verzeichnis erst gar nicht übergeben wird, brauchen wir uns am Exchange-Server darüber keine Gedanken machen.

Den sehr umfangreichen Inhalt der Datei finden Sie unter [2]. Den Inhalt fügen wir über den soduedit-Befehl in die zuvor erstellte Konfigurationsdatei "001-exchange.conf" ein. Sie müssen dabei die Servernamen und die IP-Adresse des Exchange-Servers in den Zeilen 6 bis 8 und 12 anpassen. Die Konfiguration lässt sich über sudo apache2ctl -t prüfen. Hier sollten Sie ein "Syntax Ok" zurückerhalten. Sofern es keine Fehler gibt, starten Sie Apache neu und prüfen den Status:

Let’s Encrypt für die Zertifikate nutzen

Zum Abschluss geht es um die Konfiguration des Zertifikats. Let’s Encrypt ist eine Zertifizierungsstelle, die das Abrufen und Installieren von kostenlosen TLS-/SSL-Zertifikaten auf einfache Art und Weise ermöglicht. Der Softwareclient "Certbot" unterstützt und automatisiert diesen Prozess.

Zunächst müssen Sie zwei Pakete installieren, wobei eines den Client selbst und das andere ein Plug-in zur Integration für Apache bereitstellt. Die Installation erfolgt über:

Der Certbot-Client liest beim Ausführen "ServerName" und "ServerAlias" aus dem VirtualHost-Konfigurationsblock unserer Konfigurationsdatei aus, sodass Sie die URLs nicht explizit angeben müssen. Der Befehl zum Erstellen des Zertifikats lautet sudo certbot --apache. Bei der ersten Ausführung sind einige Abfragen zu beantworten. Dazu zählen unter anderem die Terms of Services von Let’s Encrypt, aber auch die Anmeldung zu einem Newsletter. Am Ende des Prozesses wird das Zertifikat erstellt und eine Zusammenfassung angezeigt (Bild 2).

Das Zertifikat hat eine Gültigkeit von nur drei Monaten. Das Gute ist aber, dass sich Certbot automatisch um die Erneuerung kümmert. Hierfür läuft im Hintergrund der certbot.timer-Dienst, der zweimal am Tag ein Skript ausführt und automatisch alle Zertifikate erneuert, die in den nächsten 30 Tage auslaufen. Der Status des Timers prüfen Sie mit

Die Erneuerung des Zertifikats lässt sich mit dem Befehl

anstoßen. Sollte es bei der Erneuerung zu Fehlern kommen, sendet Let’s Encrypt automatisch eine Nachricht an die angegebene E-Mail-Adresse.

Damit ist die Einrichtung des Reverse-Proxy und des Zertifikats abgeschlossen. Zum Schluss prüfen Sie noch einmal die Konfiguration und starten den Apache neu:

Den Zugriff prüfen Sie relativ einfach mit "Outlook on the Web". Im Browser geben Sie die öffentliche Exchange-Adresse mit der Erweiterung "OWA" an. Der Aufruf sollte ohne Fehlermeldung erfolgen und als Zertifikat kommt unser selbsterstelltes zum Einsatz. Ob Outlook und Autodiscover korrekt laufen, lässt sich zunächst sehr einfach mit dem Microsoft Remote Analyzer prüfen. Hierfür besuchen Sie einfach die Seite Microsoft Remote Connectivity Analyzer [3] und führen die Verbindungstests für Exchange aus. Das Einrichten von Outlook oder anderen Clients sollte im Anschluss ebenfalls funktionieren. Sofern es zu Problemen kommt, stehen die in der Konfiguration definierten Apache-Logfiles unter "/var/log/apache2" zur Verfügung. Die Einrichtung des Reverse-Proxys ist damit abgeschlossen.

Exchange weiter absichern

Bis hierhin haben wir lediglich den Reverse-Proxy eingerichtet und der Mehrgewinn in Sachen Sicherheit ist überschaubar. Der reine Reverse-Proxy spielt seine Stärke vor allem aus, wenn unterschiedliche URLs zu unterschiedlichen Backend-Servern weitergeleitet werden. So wäre es beispielsweise möglich, "sharepoint.lab.schulenburg.co" über die gleiche öffentliche IP-Adresse mit Port 443 über eine Apache-Konfigurationsdatei an einen anderen internen Server weiterzuleiten.

Den externen Zugriff auf das EAC haben wir bereits unterbunden und nicht benötigte Exchange-Zugriffspunkte lassen sich einfach deaktivieren. Um die Sicherheit des Exchange-Servers aber merklich zu erhöhen, lässt sich in Ubuntu sehr schnell eine Web Application Firewall nachrüsten – zum Einsatz kommt dabei "ModSecurity". Mit frei definierbaren Filteregeln prüft die Anwendung den ein- und ausgehenden HTTP-Verkehr auf ungewöhnliche oder schädliche Daten und blockiert die weitere Verarbeitung bei Bedarf. Dadurch wird der Webserver nicht weiter belastet und auch Denial-of-Service-Attacken (DoS) lassen sich wirksam unterbinden.

Zunächst installieren Sie das Modul "ModSecurity", aktivieren es und starten Apache neu:

ModSecurity ist damit bereits einsatzbereit. In der Standardkonfiguration überprüft und loggt es aber nur verdächtige Aktivitäten. Um dies zu ändern, kopieren Sie zunächst die Standardkonfiguration und passen sie wie folgt an. Zunächst ändern Sie den Eintrag "SecRuleEngine" von "DetectionOnly" auf "On":

Im nächsten Schritt laden Sie den Standardregelsatz "OWASP ModSecurity Core Rule Set (CRS)" von Github herunter und binden ihn ein:

Bei CRS [4] handelt es sich um das Regelwerk für "ModSecurity" des "Open Web Application Security Projects", das zum Ziel hat, die Sicherheit von Anwendungen und Diensten im Web zu erhöhen. Ist der Vorgang abgeschlossen, müssen Sie sicherstellen, dass in der Datei "/etc/apache2/mods-enabled/security2.conf" die folgenden Einträge hinterlegt sind:

Weiterhin müssen Sie die Zeile "IncludeOptional /usr/share/modsecurity-crs/*.load" auskommentieren. Im Anschluss starten Sie Apache ein weiteres Mal neu.

Die Einrichtung der WAF mit einem umfangreichen Regelwerk ist damit bereits abgeschlossen. Bevor Sie die Endbenutzer auf die neue Umgebung loslassen, sollten Sie ausführlich testen und die genutzten Exchange-Funktionen prüfen. Es gilt dabei, False Positives in der Konfiguration zu vermeiden. Hier kommt wieder das Apache-Log unter "/var/log/apache2/" zum Einsatz. Um Problemen schnell auf die Spur zu kommen, lässt sich das Protokoll mit folgendem Befehl live verfolgen:

Das Log selbst lässt sich mit dem folgenden Befehl etwas schneller auswerten:

Die gefundenen Regeln müssen Sie in die Konfigurationsdatei im Bereich der Weiterleitungen ausnehmen. Um zum Beispiel die Regeln 920100, 910440 und 921130 zu deaktivieren, tragen Sie diese im OWA-Abschnitt ein:

Die Prüfung des Regelwerks nimmt etwas Zeit in Anspruch, doch am Ende sollten die Nutzer auch von extern fehlerfrei in einer gesicherten Umgebung arbeiten können.

Fazit

Ubuntu ist mit Apache als Reverse-Proxy schnell eingerichtet und mit ModSecurity abgesichert. Viel Erfahrung brauchen Sie für die Inbetriebnahme nicht. Es stellt sich nur die Frage, wer am Ende hilft, wenn etwas nicht läuft, denn einen etablierten Support gibt es in dem Fall nicht – hier könnte der Web Application Proxy aus Windows eine Alternative sein.

Exchange 2019 über Apache veröffentlichen

Draußen spielen

Reverse-Proxy als Sicherheitsmaßnahme

Reverse-Proxy als Sicherheitsmaßnahme

Testumgebung einrichten

Apache an den Start bringen

Let’s Encrypt für die Zertifikate nutzen

Exchange weiter absichern

Fazit