Lokale MS Exchange-Server mit Reverse-Proxy oder WAF vor Webshell-Attacken schützen
Microsoft Exchange Server sind «gefährliche» Server. Sie beherbergen relativ wertvolle Daten (Mails, Kalender, Kontakte usw.), sind nahe am Domänencontroller, oft zuwenig geschützt und sind nur durch eine NAT von den Weiten des Internets getrennt. Also 24/7 frei von überall her für jeden erreichbar.
Ein Einfallstor für ungebetene Gäste, wie die ProxyLogon-Lücke vom Frühjahr 2021 oder die kürzlich bekannt gewordene ProxyNotLogon-Lücke eindrücklich zeigen. Die extreme Geschwindigkeit die von Angreifern an den Tag gelegt wird, um WebShells in betroffenen Servern zu verstecken, ist irgendwie beeindruckend aber auch beängstigend.
Meine Erfahrung mit der ProxyLogon-Lücke hat gezeigt, dass man fast Lucky Luke sein muss um eine solche Lücke zu schliessen bevor sich der Server etwas einfängt. Auch mit sehr viel Automatisierung und zentralem Management dauert ein solcher Patchvorgang seine 24-48 Stunden. Zeit welche von Angreifern schamlos ausgenutzt wird.
Problematik
Exchange-Setups vieler KMUs sind sehr einfach gestrikt: Der Exchange-Server läuft auf einem einzigen Host. HTTPS-Traffic wird durch eine NAT direkt und ungefiltert an den Exchange-Server weitergeleitet. Da dieser Traffic verschlüsselt ist, bringen Filter auf der Firewall nichts. Die Firewall «sieht» nur verschlüsselten Traffic und kann diesen nicht analysieren, geschweige denn auf SQL-Injections und Co. reagieren.
In dieser Konfiguration landet jeder Request uneingeschränkt und ungefiltert auf dem Server. Gerade dies ermöglicht den Betrieb von WebShells, Phishing-Sites durch Angreifer. Single-Host-Exchange-Server enthalten mit IIS einen vollwertigen Webserver.
WebShells werden von Angreifern für sog. Lateral Movement verwendet, dabei wird das Netzwerk weiter Ausgekundschaftet um lohnende Ziele zu identifizieren und z.B. mittels Ransomware gezielt zu verschlüsseln. Nicht selten vergehen zwischen der Infektion mit einer WebShell und der eigentlichen CryptoTrojander-Attacke auf wichtige Datenziele Wochen oder gar Monate.
Lösungsansatz
In erster Linie versucht man den Echange-Server aus der «Schusslinie» zu nehmen. Man stellt den Server hinter einen Reverse-Proxy der nur legitime Anfragen an den Server weiterleitet. Fehlerhafte und illegitime Anfragen werden vom Reverse Proxy Server direkt abgelehnt und landen so nie auf dem Exchange-Server. Dies schliesst zwar direkt keine Sicherheitslücken, erschwehrt oder verunmöglicht aber die Verwendung von WebShells durch Angreifer.
Reverse Proxies sind so nicht neu:
- Microsoft hat die Funktion in IIS integriert
- NGINX, die wohl bekannteste Reverse-Proxy-Lösung aus der Linux-Welt
Der Reverse Proxy befindet sich idealerweise in einer sog. DMZ, kommuniziert also sowohl mit dem mit dem Internet als auch mit dem Exchange-Server (oder anderen Web-Servern) nur über eine Firewall welche den Zugriff auf die Notwendigen Ports beschränkt.
Reverse Proxy als Firewall-Dienst
Umgebungen bei welchen Reverse Proxies in DMZ-Zonen betrieben werden, generieren durch den dafür zusätzlich erforderlichen Server (resp. VM) zusätzliche Betriebs- und Wartungskosten. Zudem bieten sie nur einen einfachen aber trotzdem effektiven Basis-Schutz.
Moderne Firewall-Appliances bieten die Möglichkeit zusätzliche Relay-Services aus zu führen. Am Bekanntesten sind wohl Mail-Relays oder -Filter, VPN-Server, Web-Proxies aber auch Reverse Proxies (wie z.B. Squid auf pfSense).
Da der Reverse Proxy die Möglichkeit hat, die erhaltenen Anfragen, vor der Weiterleitung an interne Netze, zu entschlüsseln und zu prüfen ist hier der Ideale Punkt um eine Filter-Lösung zu Platzieren welche «böse» Anfragen identifizieren und entfernen kann. Genau hier setzen sog. Web Application Firewalls (WAF) an: Durch Patterns welche vom Hersteller der Firewall selbst oder von einem Antivirus-Anbieter bereitgestellt werden, werden schädliche Anfragen erkannt und gezielt von der WAF geblockt. Zudem ermöglichen die meisten WAF-Lösungen auch Load-Balancing sowie quellen- oder request-basiertes Routing.
Reverse Proxy Konfiguration: Eine Kunst für sich
Die Konfiguration von Reverse Proxies oder WAFs setzt Erfahrung voraus und sind häufig sehr komplex. Dies ist besonders am Beispiel der Sophos XG WAF gut zu sehen: Die Anleitung von Sophos für die Konfiguration von WAF für MS Exchange 2016 ist sehr lang. Die Erstellung eines funktionalen Patterns erfordert eine sehr fundierte Kenntniss der zu schützenden Web-Applikation. Bei Web Application Firewalls kommt zudem noch dazu, dass selbst die gängigsten Web-Applikationen false positives generieren und entsprechend gewhitelistet werden müssen.
Es wäre wünschenswert wenn dieser entscheidende Bestandteil eines WAF-Schutzes bei den Herstellern mehr Gewicht hätte. Seitens der WAF-Hersteller stehen nur begrenzt funktionierende vorgefertigte Konfigurationen vor. Aber auch Seitens der Hersteller von WebApps wie Microsoft Exchange usw. sind die Informationen oft dürftig. Das Nichtvorhandensein solcher Informationen zwingt den Admin dazu die passenden Einstellungen zeitintensiv über ein Testsystem oder gar im Monitor-Betrieb eines Live-Systems zu ermitteln.
Passende Ressourcen:
Vorlagen für Sophos XG WAF-Regeln sind in meinem GitHub-Repo für Sophos XG Templates zu finden:
Quellen:
- Titelbild: «Weiße Betonstruktur» von Arantxa Treva
