HTTP-Content-Action am Beispiel OWA – Blocken von /ecp/
Seit der aktuellen Version unterstützt WatchGuard im Content-Filter die Auswahl eines SSL-Zertifikates, sowie mehrere SSL-Zertifikate für TLS/Proxy-Inbound Inspection.
Am Beispiel des Outlook-Webaccess wird die Konfiguration einer HTTP-Content-Action in Verbindung mit eingehender Deep Inspection über HTTPS-Proxy aufgezeigt.
Ziel ist es nun, die Exchange-Admin-Konsole /ecp/ zu blocken, während gleichzeitig alles andere (OWA, Activesync, Autodiscover, Mapi etc.) erlaubt bleibt. Die Fehlermeldung kann etwas aufgehübscht werden.
Zunächst (so man möchte) wird ein offizielles Zertifikat als Proxy-Server-Zertifikat für Incoming TLS/Inspection auf der Firebox installiert. Der Import-Vorgang ist mit Fireware 12.2 etwas angepasst worden, hierzu folgt ein eigener Artikel.
Vorgehensweise:
(Klicken Sie auf die Bilder, um die großen Ansichten zu sehen)
- Zunächst wird die Proxy-Policy gebaut für den eingehenden Traffic über ein SNAT. Hier wird eine HTTPS-Server-Proxy-Action benötigt.
- In der HTTPS-Server-Policy benötigen wir Pattern Matches. Für die Pattern Matches wird die Action auf Inspect gestellt.
- Es werden mehrere Patterns benötigt, für jeden möglichen DNS-Namen eines. Der Filter soll schließlich auch greifen, wenn man mit https://<ipadresse>/owa auf den Server zugreift.
- Als Proxy-Action wird eine HTTP-Content-Action hinterlegt (bei allen Patterns die gleiche Action). HTTP deswegen, weil man sich hier über den Pattern Match auf den Domain Namen und aufgrund Inspect bereits in der Deep Inspection befindet und man sich hier also das im HTTPS-Stream befindliche HTTP-Protokoll ansieht.
- Es muss das richtige Zertifikat ausgewählt werden. Falls man getrennte Zertifikate für unterschiedliche Domain-Namen hat, können hier mehrere stehen. Falls man ein SAN/Multidomain-Zertifikat im Einsatz hat, steht hier überall das gleiche Zertifikat. Falls man nur ein Zertifikat auf der Box als “Default Certificate” installiert hat, steht hier natürlich das Default Certificate.
- Detailansicht der Einstellung eines Patternmatches: Domainnamen
- Detailansicht der Einstellung eines Patternmatches: Action: Inspect
- Detailansicht der Einstellung eines Patternmatches: Auswahl der Proxy-Action (HTTP-Content-Action)
- Detailansicht der Einstellung eines Patternmatches: Auswahl des Zertifikates.
- Detail-Ansicht der HTTP-Content-Action: Hier wird über ein Pattern “*/ecp/*” gematcht,
- und bei Treffer eine HTTP-Server-Proxy-Deny-Action, bzw. für alle anderen URLs eine HTTP-Proxy-Action für Allow aufgerufen. Emfpehlung: Namesgebung der Policies: hier: “HTTP-Server-Deny-Fehlermeldung” bzw. “HTTP-Server-Allow-All-fuer-OWA”
- In der Deny-Policy werden alle Policies verboten (Deny).
- Ebenso kann hier die Deny-Message angepasst werden.
- in der Allow-Action sollte man alles erlauben. Fallstricke sind hier ggf. alte Proxy-Templates.
Sinnvoll sind vor allem:
- General Settings => maximum URL path length anpassen (in alten Templates steht hier ggf. noch 2048, setzen auf 4096 oder 8192).
- General Settings => [x] Allow range requests through unmodified
- Requests Methods => If matched => allow
- Requests Methods => None matched => allow (hier hatten ich bereits einmal den Fall, dass OPTION verboten wurde und damit die Konfiguration einklinken eines iPhones über ActiveSync geblockt wurde).
Da hier möglichst wenig eingegriffen werden soll, werden alle Zugriffe erlaubt. Die anderen Security-Features wurden im Rahmen dieses Setups nicht getestet und in dieser Proxy-Action abgeschaltet.
Das Ziel wurde erreicht: eine HTTPS-Paketfilter-Regel wurde durch einen Proxy ersetzt, der Zugriffe auf /ecp/ blockt.
Hallo!
Danke für die Anleitung. Wenn ich das richtig verstehe, dann wird mit der erzeugten Deny-Regel (*/ecp/*) nur der Zugriff auf https://sub.domain.tdl/ecp/ geblockt. Wenn der letzte Slash weggelassen wird, also https://sub.domain.tdl/ecp aufgerufen wird, greift die Regel nicht. Exchange leitet dann automatisch um auf https://sub.domain.tdl/owa/auth/logon.aspx?replaceCurrent=1&url=https%3a%2f%2fmail.hw-hannover.de%2fecp und der Aufruf kann erfolgen, da das gefilterte Pattern nicht vorkommt.
Hallo Herr Meyer,
Das ist korrekt.
der Vollständigkeit halber sollte daher in Punkt 11 die Regel mit dem Pattern Match einmal kopiert werden und dann
einmal auf “*/ecp/*” und einmal auf “*/ecp” matchen. Alternativ würde vermutlich auch eine einzige Regel mit “*/ecp*” greifen,
das bliebe auszuprobieren.
vielen Dank für den Hinweis
Hallo,
vielen Dank für diese Klasse Anleitung und die damit verbundenen Bemühungen, genau das was ich gesucht habe!
Leider scheitere ich mit der Umsetzung noch an dem verwendeten Zertifikat. Ich verwende die Fireware 12.5.2 und kann dort, im Gegensatz zu der Anleitung oben, nirgends das zu verwendende Zertifikat auswählen. Bis dato verwenden wir für unseren Exchange ein Public Zertifikat von COMODO. Wenn ich die Content Inspection aktiviere, wird beim Aufruf der OWA Seite oder beim Start von Outlook ein Self-Signed Zertifikat von Watchguard verwendet. Gibt es hier eine Lösung wie der Aufruf der OWA Site trotz Conten Inspection mit dem richtigen Zertifikat erfolgen kann?
Vielen Dank und viele Grüße
Hallo Herr Scherer,
die Auswahl des Zertifikates gibt es erst bei aktuelleren Releases. Wenn Sie beispielsweise noch eine Firewall der XTM-Series haben, ist das neueste Release eine 12.1.3 Update 3 – und damit zwar gepatcht (Sicherheitspatches und SSLVPN-Cleints) auf dem neuesten Stand, aber aufgrund der begrenzten Hardware der XTM-Firewalls (die sind ja nun auch schon ein paar Tage alt) auf dem Feature-Stand von etwa Mai 2018. Und gerade bei den SSL-Zertifikaten, dem Handling, den Reverse-Proxies etc. hat sich hier eine Menge getan.
bei den älteren Boxen gibt es die Auswahl des Zertifikates für die Content-Inspection nicht – da gibt es nur ein zentrales Proxy-Zertifikat. Wenn man also ein entsprechendes Wildcard- oder Multi-Domain-Zertifkat – auch SAN-Zertifikat (Subject-Alternative-Name) genannt – als Proxy-Zertifikat installiert, sollte es auch mit einer 12.1.3 funktionieren. Zu welchem Release genau die HTTP-Content-Action eingeführt wurde, kann ich Ihnen allerdings nicht sagen.
Falls Sie Support wünschen, verweise ich auf unser Support-Formular.
viele Grüße,
Werner Maier
Hallo!
vielen Dank für die Anleitung. Mir ist jedoch aufgefallen, dass wenn man die Patterns “*/ecp/*”, “*/ecp” oder auch “*/ecp*” verwendet man trotzdem über die folgende URL auf die Admin Console kommt “https://mail.domain.de/owa/auth/logon.aspx?replaceCurrent=1&url=https%3a%2f%2fmail.domain.de%2fecp”. Das ist die Standart Weiterleitung von Exchange, man muss nur die Domain (in dem Fall mail.domain.de) ersetzten.
Ich habe bei unserer Firewall das folgende Pattern verwendet “*ecp*” da ja am Ende der redirection URL der String “ecp” vorkommt.
wobei die von Ihnen genannte URL aber keine /ecp/ URL ist sondern einfach nur die Login-Seite unter /owa/logon.aspx – was ja erlaubt ist.
sollte sich hier entsprechend jemand für den ECP anmelden, würde ein redirect nach /ecp/… erfolgen, und das wäre dann wieder geblockt.
die Patterns sind sicherlich verbesserungsfähig – es mag auch sinnvoll sein, das ganze mit /ECP/ und /Ecp/ etc. zu untersuchen und zu testen,
was man sicher durch entsprechende Filterung gut abfangen kann.
inzwischen gibt es ja für aktuelle Exchange/OWA zusätzlich die Möglichkeit, das ganze über das Access Portal abzuwickeln (falls von der Firebox Hardware unterstützt und in der Lizenz enthalten).
viele Grüße
— Werner
Hallo, ja mit dem redirect haben Sie natürlich Recht.
Leider haben wir in unserer FireBox nur die Basic Security Suite, deswegen kann ich das Access Portal nicht ausprobieren. Wenn die Lizenz Ende des Jahres ausläuft werden wir wohl auf die Total Security Suite upgraden.
Viele Grüße
Alex
HOWTO - Exchange-Server mittels Reverse-Proxy (Access Portal) und Pre-Authentication absichern - BOC IT-Security GmbH