Schritt 1 – Zertifikat aus der Windows PKI exportieren
Das interne oder public Zertifikat des Exchange Servers muss samt private Key als PKS12 exportiert und in die UTM importiert werden um es in der WAF verwenden zu können.
Das öffentliche Zertifikat sollte alle nötigen DNS-Namen enthalten. Ist das Zertifikat zeitgleich auch das interne Zertifikat (da z.B. selbstausgestellt über internen Windows PKI) sicherstellen dass auch die
internen DNS-Namen vorhanden sind. Das ist zwar nicht für die WAF wichtig, aber interne Clients haben sonst ein Problem.
Hier ein paar Beispiele:
- mailserver.kunde.de
- autodiscover.kunde.de
- owa.kunde.de
- outlook.kunde.at
Export des Zertifikats (Annahme interne Windows PKI)
- Auf dem Server der das Zertifikat als Computerzertifikat erhalten hat (Exchange Server)
- WIN + R -> MMC
- Datei -> Snap In hinzufügen
- Zertifikate auswählen -> Hinzufügen
- Computerkonto auswählen -> Weiter
- Lokalen Computer … –> Fertig stellen
- MMC mit OK bestätigen
- Zertifikate (Lokaler Computer) -> Eigene Zertifikate -> Zertifikate
- Das Exchange Zertifikat auswählen -> Doppelklick
- Register Details -> In Datei kopieren… -> Weiter
- Ja, privaten Schlüssel exportieren auswählen
- Nur folgendes markieren: Privater Informationsaustausch – PKCS #12 (.PFX) -> Weiter
- Option Kennwort aktivieren und Passwort eingeben
- Speicherort wählen und z.B. wie folgt benennen: 20xx-20xx-hostname.domain.at-withPrivateKey-PKCS12.pfx
Schritt 2 – Zertifikat in die Sophos SG UTM Firewall importieren
Die WAF in kurzen Worten
- Die Funktionsweise der WAF in einer Sophos SG Firewall funktioniert nach folgenden Prinzip:
- Die „externe Weiterleitung“ was ohne WAF ein D-NAT machen würde, wird unter Echte Webserver
- Der virtuelle Webserver „simuliert“ den eigentlichen Server (Exchange) und stellt dabei auch die Zertifikate bereit.
- Der virtuelle Webserver erhält wiederum ein Firewall–Profil an dessen er weiß was er filtern soll.
- Unter Site-Path-Routing werden Eintrittspfade wie z.B. https:/url.tld/owa an den echten Webserver Wenn kein /irgendwas angegeben wird, dann wird der Root, also „/“ verwendet und jede URL geht zum echten Webserver. Site-Path-Routing ermöglicht als einziger die Zugriffskontrolle der URLs per IP/Netzwerk Einschränkung. Site-Path-Routing steuert auch die Umkehrauthentifizierung, spricheine „Reverse Authentifizierung“ wenn z.B. 2-Faktor Authentifizierung verwendet werden soll für wiederum z.b. die OWA Anmeldung (eigene Anleitung).
- Alles was mit dem Filtern, zulassen oder blockieren von Schadcode zu tun hat, wird im Firewall-Profil geregelt.
Zertifikat in Sophos SG UTM importieren (Stand Firmware 9.509-3) Deutsche WebAdmin GUI
- In WebAdmin einloggen
- Webserver Protection -> Zertifikatverwaltung -> Register Zertifikate
- Neues Zertifikat -> Methode: Hochladen -> Name z.B. 20xx-20xx-hostname.domain.at-von-PKI-Servername
- Als Dateityp PKCS#12 (Zert.+CA) wählen -> Kennwort eingeben
- Den Ordner-Button klicken -> die Zertifikatdatei z.B. 20xx-20xx-hostname.domain.at-withPrivateKey-PKCS12.pfx auswählen und hochladen
Schritt 3 – Sophos Firewall – Web Server Anlegen
Echten WebServer anlegen
Namen sind natürlich frei wählbar. Ich habe Beispielsnamen aus meiner Demoumgebung gewählt.
- Webserver Protection -> Web Application Firewall -> Register Echte Webserver
- Name: SERVEREX01-HTTPS
Host: Das Hostobjekt des Exchange Servers (Hostobjekt sollte übrigens Schnittstelle, DNS und Reverse DNS eingetragen haben)
Typ: Verschlüsselt (HTTPS)
Port: 443 - Unter Erweitert
Option HTTP-Keep-Alive aktivieren mit 300
Schritt 4 – Sophos Firewall Profile Konfigurieren
Exchange, in diesem Fall 2016, verwendet im Wesentlichen 4 Dienste nach außen/von außen.
- Autodiscover zur Server Ermittlung
- ActiveSync für Mobiles und Push Mail
- Outlook Anywhere zur Client-Kommunikation
- Outlook Wep App als Webmail
Drei Dienste können in einem Profil zusammengefasst werden (ActiveSync, Anywhere, OWA). Autodiscover braucht andere Einstellungen und hat daher ein eigenes Profil. Dies bedeutet jedoch auch dass 2 externe IPs benötigt werden. Wer das nicht möchte, muss sich ein Profil machen, und entsprechende funktionen „minmieren“ sprich die Sicherheit des einzelnen Profiles drosseln damit alle Features von Exchange laufen. Das spart Sicherheit, aber auch dafür eine IP Adresse. In meinem Beispiel verwende ich jedoch 2 Profile.
Firewall-Profil 1 – Autodiscover
Profil
- Name: Exchange2016-2019-AutoDiscover
- Modus: Ablehnen
Hardening & Signierung
- Statisches URL Hardening: Aktiv und Manuell festgelegt
- Einstiegs URLs:
/AutoDiscover
/Autodiscover
/autodiscover - Form Hardening: Aktiv
Filterung
- Clients mit schlechten Ruf blockieren: Aktiv
- Keine Fern-Abfragen für Clients mit schlechten Ruf: Nicht aktiv
- Filter Allgemeine Bedrohungen
- Filterregeln übergehen:
960015
960911
Filterkategorien allgemeine Bedrohungen
- Alles aktiv außer SQL-Injection-Angriffe
Antiviren-Scans
- Aktiv mit Zweifachscan und Up/Downloads
- Unscannbaren Inhalt blockieren
Firewall-Profil 2 – OWA,ActiveSync,Anywhere
Profil
- Name: Exchange2016-2019-OWA-ActiveSync-Anywhere
- Modus: Ablehnen
Hardening & Signierung
- Statisches URL Hardening: Aktiv und Manuell festgelegt
- Einstiegs URLs:
/ECP
/ecp
/EWS
/ews
/Microsoft-Server-ActiveSync
/OAB
/oab
/OWA
/owa
/RPC
/rpc
/MAPI
/mapi
Filterung
- Clients mit schlechten Ruf blockieren: Aktiv
- Keine Fern-Abfrage für Clients mit schlechten Ruf: Nicht aktiv
- Filter allgemeine Bedrohungen
- Filterregeln übergehen:
960010
960015
960018
960032
981176
981203
981204
Filterkategorien allgemeine Bedrohungen
- Alles aktiv außer
– SQL-Injection-Angriffe
– XSS-Angriffe
– Ausgehend
Antiviren-Scans
- Aktiv mit Zweifachscan und Up/Downloads
- Unscannbaren Inhalt blockieren
Hinweis:
Outlook Anywhere passieren lassen war ab Exchange 2016/2019 bei keinen meiner Tests nötig sofern mindestens Outlook 2016 Versionen eingesetzt wurde.
Bei Verwendung von Outlook 2013 musste die Option aktiviert werden! Am besten nach Abarbeitung aller Punkte die Verbindungen einmal testen und nur wenn nötig zusätzlich aktivieren. Bedenken Sie auch, dass mittlerweile MAPI over HTTP anstelle RPC over HTTP verfügbar ist.
Schritt 5 – Sophos Firewall – Virtuelle Webserver
Wir benötigen 2 virtuelle Webserver da wir 2 verschiedene Profile verwenden.
Virtueller Webserver 1
Virtueller Webserver
- Name: Exchange2016-2019-Autodiscover
- Schnittstelle: Die externe WAN-IP für Autodiscover
- Typ: Verschlüsselt (HTTPS
- Port: 443
- Zertifikat: das Hochgeladene des Exchange Servers
Domänen
- Alle externen DNS Namen markieren
Echte Webserver
- Unseren Zuvor angelegten SERVEREX01
Firewall Profil
- Exchange2016-2019-AutoDiscover
Erweitert
- Host-Header durchreichen: Aktiv
Virtueller Webserver 2
Virtueller Webserver
- Name: Exchange2016-2019-OWA-ActiveSync-Anywhere
- Schnittstelle: Die externe WAN-IP für SMTP/OWA/Anywhere etc..
- Typ: Verschlüsselt (HTTPS
- Port: 443
- Zertifikat: das selbe hochgeladene des Exchange Servers
Domänen
- Wie zuvor alle externen DNS Namen markieren
Echte Webserver
- Erneut unser SERVEREX01
Firewall Profil
- Exchange2016-2019-OWA-ActiveSync-Anywhere
Erweitert
- Host-Header durchreichen: Aktiv
Schritt 6 – Sophos Firewall Profile Ausnahmen
Jetzt müssen noch ein paar Globale Ausnahmen für spezielle URLs gemacht werden damit alles funktioniert. Wir benötigen 4 Ausnahmen in Summe
Ausnahme 1
Allgemein
- Name: Exchange-AV-OWA
Diese Prüfungen ausnehmen
- Antiviren-Scan
Virtueller Webserver
- Exchange2016-2019-OWA-ActiveSync-Anywhere
Für alle Anfragen: Web-Anfragen betreffend diesen Pfad:
- /OWA/ev.owa*
- /owa/ev.owa*
Ausnahme 2
Allgemein
- Name: Exchange-StaticHardening-OWA
Diese Prüfungen ausnehmen
- Statisches URL-Hardening
Virtueller Webserver
- Exchange2016-2019-OWA-ActiveSync-Anywhere
Für alle Anfragen: Web-Anfragen betreffend diesen Pfad:
- /ECP/*
- /ecp/*
- /EWS/*
- /ews/*
- /Microsoft-Server-ActiveSync*
- /microsoft-server-activesync*
- /OAB/*
- /oab/*
- /OWA/*
- /owa/*
Erweitert
- HTML während Statischem URL-Hardening oder Form-Hardening nie ändern: Aktiv
Ausnahme 3
Allgemein
- Name: Exchange-StaticHardening-Autodiscover
Diese Prüfungen ausnehmen
- Statisches URL-Hardening
Virtueller Webserver
- Exchange2016-2019-Autodiscover
Für alle Anfragen: Web-Anfragen betreffend diesen Pfad:
- /AutoDiscover/*
- /autodiscover/*
Erweitert
- HTML während Statischem URL-Hardening oder Form-Hardening nie ändern: Aktiv
Ausnahme 4
Outlook Anywhere Datenverkehr kann/darf nicht geprüft werden daher für die Anywhere Pfade alles ausnehmen.
Allgemein
- Name: Contoso- Exchange-Anywhere
Diese Prüfungen ausnehmen
- Alle Punkte
Diese Kategorien berspringen
- Alle Punkte
Virtueller Webserver
- Exchange2016-2019-OWA-ActiveSync-Anywhere
Für alle Anfragen: Web-Anfragen betreffend diesen Pfad:
- /RPC/*
- /rpc/*
- /MAPI/*
- /mapi/*
Erweitert
- HTML während Statischem URL-Hardening oder Form-Hardening nie ändern: Aktiv
Schritt 8 – Sophos Firewall Site-Path-Routing
Wir wollen selbstverständlich nicht, dass durch das Weiterleiten des HTTPS Ports auch das Exchange Admin Center im Internet aktiv wird. Obwohl es durch PW, WAF und Firewall geschützt ist, riskieren wir lieber nicht Zuviel und sorgen dafür, dass das Admin Center (ECP) nur von internen und von uns „geprooften“ IP/Netzen zugänglich ist.
In einem weiteren Schritt kann man zusätzlich für OWA und ECP eine zwei Faktor Authentifizierung hinzufügen (separate Anleitung). Damit das funktioniert und wir leider nur einen Pfad pro SPR anlegen können, legen wir für jeden unserer virtuellen Webserver je 2 Pfade an (ECP und ecp) und erst darunter einen Root („/“) für den Rest der extern zugänglich bleiben soll (Best Match Prinzip).
Webserver 1 – SPR Eintrag 1
- Name: Exchange-Autodiscover-ECP-Restrict-Access-1
- Virtueller Webserver: Exchange-Autodiscover
- Pfad: /ECP
- Echter Webserver: SERVEREX01-HTTPS
- Zugriffskontrolle: Aktivieren
Hier alle Netze (inklusive interner) Eintragen die zugreifen können sollen.
Alle anderen werden mit Permission-Denied damit automatisch abgewiesen.
Webserver 1 – SPR Eintrag 2
Gleich verfahren wir mit den restlichen Einträgen. Screenshots erübrigen sich damit.
Unterschiede sind fett hervorgehoben.
- Name: Exchange-Autodiscover-ECP-Restrict-Access-2
- Virtueller Webserver: Exchange-Autodiscover
- Pfad: /ecp
- Echter Webserver: SERVEREX01-HTTPS
- Zugriffskontrolle: Aktivieren
Hier alle Netze (inklusive interner) Eintragen die zugreifen können sollen.
Webserver 1 – Root
- Name: Exchange-Autodiscover-Root
- Virtueller Webserver: Exchange-Autodiscover
- Pfad: /
- Echter Webserver: SERVEREX01-HTTPS
- Zugriffskontrolle: Nicht aktiv
Webserver 2 – SPR Eintrag 1
- Name: Exchange-OWA-ActiveSync-Anywhere-ECP-Restrict-Access-1
- Virtueller Webserver: Exchange-OWA-ActiveSync-Anywhere
- Pfad: /ECP
- Echter Webserver: SERVEREX01-HTTPS
- Zugriffskontrolle: Aktivieren
Hier alle Netze (inklusive interner) Eintragen die zugreifen können sollen.
Webserver 2 – SPR Eintrag 2
Gleich verfahren wir mit den restlichen Einträgen. Screenshots erübrigen sich damit.
Unterschiede sind fett hervorgehoben.
- Name: Exchange-OWA-ActiveSync-Anywhere-ECP-Restrict-Access-2
- Virtueller Webserver: Exchange-OWA-ActiveSync-Anywhere
- Pfad: /ecp
- Echter Webserver: SERVEREX01-HTTPS
- Zugriffskontrolle: Aktivieren
Hier alle Netze (inklusive interner) Eintragen die zugreifen können sollen.
Webserver 2 – Root
- Name: Exchange-OWA-ActiveSync-Anywhere-Root
- Virtueller Webserver: Exchange-OWA-ActiveSync-Anywhere
- Pfad: /
- Echter Webserver: SERVEREX01-HTTPS
- Zugriffskontrolle: Nicht aktiv
Fertig sieht das dann so aus am Beispiel des Autodiscover (eingeschränkt über Suche zur besseren Übersicht)
Sophos Firewall – Andere Einstellungen und Infos
- Sollte Country Block aktiv sein, nicht vergessen eine Ausnahme berechtigter oder aller Länder für https tcp.443 für die verwendeten IP/Schnittstellen von AutoDiscover/OWA…
- Beim Testen der AutoDiscover/Anywhere Verbindung über Microsoft Remote Connectivity Analyzer (https://testconnectivity.microsoft.com) wird dieser Fehler anzeigen da nicht alle der vom Tester geöffneten Ports tatsächlich offen sind. Wir verwendet ja nur 443. Ein besserer Test wäre einen Client extern zu verbinden und Anywhere Verbindung in einem neuen Profil testen.
- Beim Verbinden und der PW Abfrage anstelle der Mail Adresse bei User die Methode DOMAIN\username
- Externe ggf. nicht Domain Clients sollten dem Root Zertifikatsserver vertrauen. Bedeutet Import des Base64 Root Zertifikats, natürlich ohne priv. Key, des Windows PKI Servers in die Vertrauenswürdigen Stammzertifizierungsstellen (Computerkonto)
- Bei Handy/Tablet etc ohne importierten Zertifikat SSL ignorieren verwenden.