{"id":5236,"date":"2018-09-28T13:00:11","date_gmt":"2018-09-28T11:00:11","guid":{"rendered":"https:\/\/www.boc.de\/watchguard-info-portal\/?p=5236"},"modified":"2018-09-28T14:27:59","modified_gmt":"2018-09-28T12:27:59","slug":"http-content-action-am-beispiel-owa-blocken-von-ecp","status":"publish","type":"post","link":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/2018\/09\/http-content-action-am-beispiel-owa-blocken-von-ecp\/","title":{"rendered":"HTTP-Content-Action am Beispiel OWA – Blocken von \/ecp\/"},"content":{"rendered":"

Seit der aktuellen Version unterst\u00fctzt WatchGuard im Content-Filter die Auswahl eines SSL-Zertifikates, sowie mehrere SSL-Zertifikate f\u00fcr TLS\/Proxy-Inbound Inspection.<\/p>\n

Am Beispiel des Outlook-Webaccess wird die Konfiguration einer HTTP-Content-Action in Verbindung mit eingehender Deep Inspection \u00fcber HTTPS-Proxy aufgezeigt.<\/p>\n

<\/p>\n

Ziel ist es nun, die Exchange-Admin-Konsole \/ecp\/ zu blocken, w\u00e4hrend gleichzeitig alles andere (OWA, Activesync, Autodiscover, Mapi etc.) erlaubt bleibt. Die Fehlermeldung kann etwas aufgeh\u00fcbscht werden.<\/p>\n

Zun\u00e4chst (so man m\u00f6chte) wird ein offizielles Zertifikat als Proxy-Server-Zertifikat f\u00fcr Incoming TLS\/Inspection auf der Firebox installiert. Der Import-Vorgang ist mit Fireware 12.2 etwas angepasst worden, hierzu folgt ein eigener Artikel.<\/p>\n

Vorgehensweise:<\/h3>\n

(Klicken Sie auf die Bilder, um die gro\u00dfen Ansichten zu sehen)<\/p>\n

    \n
  1. Zun\u00e4chst wird die Proxy-Policy gebaut f\u00fcr den eingehenden Traffic \u00fcber ein SNAT. Hier wird eine HTTPS-Server-Proxy-Action ben\u00f6tigt.<\/strong>
    \n\"\"<\/a><\/strong><\/li>\n
  2. In der HTTPS-Server-Policy ben\u00f6tigen wir Pattern Matches. F\u00fcr die Pattern Matches wird die Action auf Inspect<\/strong> gestellt.<\/li>\n
  3. Es werden mehrere Patterns ben\u00f6tigt, f\u00fcr jeden m\u00f6glichen DNS-Namen eines. Der Filter soll schlie\u00dflich auch greifen, wenn man mit https:\/\/<ipadresse>\/owa auf den Server zugreift.<\/li>\n
  4. Als Proxy-Action wird eine HTTP-Content-Action<\/strong> hinterlegt (bei allen Patterns die gleiche Action). HTTP<\/strong> deswegen, weil man sich hier \u00fcber den Pattern Match auf den Domain Namen und aufgrund Inspect<\/strong> bereits in der Deep Inspection befindet und man sich hier also das im HTTPS-Stream befindliche HTTP-Protokoll ansieht.<\/li>\n
  5. Es muss das richtige Zertifikat ausgew\u00e4hlt werden. Falls man getrennte Zertifikate f\u00fcr unterschiedliche Domain-Namen hat, k\u00f6nnen hier mehrere stehen. Falls man ein SAN\/Multidomain-Zertifikat im Einsatz hat, steht hier \u00fcberall das gleiche Zertifikat. Falls man nur ein Zertifikat auf der Box als „Default Certificate“ installiert hat, steht hier nat\u00fcrlich das Default Certificate.
    \n    \"\"<\/a><\/li>\n
  6. Detailansicht der Einstellung eines Patternmatches: Domainnamen<\/li>\n
  7. Detailansicht der Einstellung eines Patternmatches: Action: Inspect<\/li>\n
  8. Detailansicht der Einstellung eines Patternmatches: Auswahl der Proxy-Action (HTTP-Content-Action)<\/li>\n
  9. Detailansicht der Einstellung eines Patternmatches: Auswahl des Zertifikates.
    \n    \"\"<\/a><\/li>\n
  10. Detail-Ansicht der HTTP-Content-Action: Hier wird \u00fcber ein Pattern „*\/ecp\/*“ gematcht,<\/li>\n
  11. und bei Treffer eine HTTP-Server-Proxy-Deny-Action, bzw. f\u00fcr alle anderen URLs eine HTTP-Proxy-Action f\u00fcr Allow aufgerufen. Emfpehlung: Namesgebung der Policies: hier: „HTTP-Server-Deny-Fehlermeldung“ bzw. „HTTP-Server-Allow-All-fuer-OWA“
    \n    \"\"<\/a><\/li>\n
  12. In der Deny-Policy werden alle Policies verboten (Deny).<\/li>\n
  13. Ebenso kann hier die Deny-Message angepasst werden.
    \n    \"\"<\/a>\u00a0 \u00a0\"\"<\/a><\/li>\n
  14. in der Allow-Action sollte man alles erlauben. Fallstricke sind hier ggf. alte Proxy-Templates.<\/li>\n<\/ol>\n

    Sinnvoll sind vor allem:<\/p>\n