Sophos XG: Exchange 2016 und SFOS 16.05 Webserver Protection (Teil 2)

In Teil 1 wurde bereits die Grundkonfiguration der Sophos XG in Verbidnung mit Exchange 2016 durchgeführt, es fehlt allerdings noch etwas Konfigurationsarbeit damit auch Outlook Anywhere, MAPIoverHTTP und die REST Api funktionieren. Wie bereits in Teil 1 erwähnt sind die Sophos Vorlagen für Geschäftsanwendungen etwas veraltet, daher muss hier manuell nachgebessert werden. Etwas irritierend ist, dass es drei Vorlagen für Exchange gibt. die Vorlage “Exchange General” behandelt die klassischen Webservices, wie OWA, EWS und ActiveSync, enthält aber auch noch völlig veraltete Pfade für OMA (Outlook Mobile Access), welches schon lange keine Verwendung mehr findet.

Wenn die drei Standard Vorlagen genutzt werden, ist es erforderlich die Exchange Webservices (OWA, EWS, ActiveSync, etc), Autodiscover und Outlook Anywhere (RPC, MAPI) von einander zu trennen. Dies bedeutet allerdings auch, dass ein SAN Zertifikat mit drei Namen (Subject Alternate Names) verwendet werden muss.

Es geht auch etwas schöner, zumindest für die aktuellen Protokolle.

Umleitung von “/” nach ”/owa”

Mit den Standard Regeln wird beim Aufruf von des Root-Folders nur eine 404-Fehlerseite angezeigt:

image

Normalerweise führt hier der Exchange Server den Redirect nach /owa durch. Um dies zu erreichen kann die Regel “Exchange 2016 Webservices” angepasst werden:

SFOS Exchange 2016

Im Abschnitt “Geschützte Server” kann jetzt ein neuer Pfad hinzugefügt werden:

image

Hier wird ein Schrägstrich “/” als Pfad eingetragen und der Exchange Server als Webserver ausgewählt. Authentifizierung bleibt leer:

image

Danach wird im Abschnitt “Exceptions” eine neue Ausnahme angelegt:

image

Als Pfad wird wieder ein Schrägstrich “/” eingetragen und “Statisches URL-Hardening” als Prüfung ausgeschlossen:

image

Die Firewall Regel kann jetzt gespeichert werden und schon funktioniert die Umleitung nach /owa wieder.

MAPIoverHTTP (/mapi)

MAPIoderHTTP kann ebenfalls recht einfach aktiviert werden. Es wird wieder die Regel “Exchange Webservices” editiert:

Sophos XG

Diesmal werden im Bereich “Geschützter Server” zwei neue Pfade angelegt:

image

Hier werden jetzt die Pfade “/mapi” und “/MAPI” angelegt. Webserver ist wieder der Exchange Server, Authentifizierung bleibt leer:

image

Nachdem die beiden Pfade angelegt wurden, sieht es wie folgt in der Übersicht aus:

image

Zum Schluss muss noch die schon vorhandene Expeption editiert werden:

image

In die Liste der Pfade für die Ausnahme werden jetzt die beiden Pfade “/mapi/*” und “/MAPI/*” hinzugefügt:

image

Die Liste der Ausnahmen sieht nun wie folgt aus:

image

Hinweis: Als ich diesen Screenshot erstellt habe ist mir aufgefallen, dass ich vergessen habe die Ausnahmen für “/oma/*” und “/OMA/*” zu löschen (Blauer Kasten). Diese beiden Pfade können ersatzlos gelöscht werden. Outlook Mobile Access (OMA) wird schon lange nicht mehr verwendet und ist auf einem Exchange 2016 Server nicht mehr verfügbar.

Nachdem die Firewall Regel gespeichert wurde funktioniert MAPIoverHTTP (Das neue Outlook Anywhere).

REST API (/api)

Mit dem Stand CU4 für Exchange 2016 ist die REST-Api zwar noch nicht offiziell freigegeben, aber immerhin schon für Tests verfügbar. Die Standard Regeln berücksichtigen die neue API ebenfalls nicht, daher muss sie auf dem gleichen Weg wie MAPIoverHTTP freigegeben werden.

Hier wird wieder, wie schon bei MAPIoverHTTP, die Exchange Webservices Firewall Regel angepasst und zwei neue Pfade hinzugefügt. Diesmal “/api” und /”API”:

image

In die vorhandene Ausnahmeliste werden dann die Pfade “/api/*” und “/API/*” angegeben:

image

Jetzt sollte die Ausnahmeliste wie folgt aussehen:

image

Die Firewall Regel kann nun gespeichert werden und die REST-API funktioniert.

RPCoverHTTP (/rpc)

Bei dem klassischen Outlook Anywhere (RPCoverHTTP) wird es schon etwas trickreicher. Hier empfiehlt es sich vorher zu überlegen, ob dieses Protokoll noch benötigt wird, denn alle von Exchange 2016 unterstützen Outlook Versionen sprechen auch MAPIoverHTTP.

Ich würde an dieser Stelle auf RPCoverHTTP verzichten, zumindest wenn wie in meinem Fall nur zwei Hostnames zur Verfügung stehen. Der Hintergrund ist, dass die meisten Schutzmechanismen der Webserver Protection für Outlook Anywhere abgeschaltet werden müssen. Dieses gilt dann auch für die restlichen Webservices wie OWA und EWS. Wenn Outlook Anywhere, also das klassische RPCoverHTTP noch benötigt wird, empfehle ich einen dritten Hostnamen in das Zertifikat aufzunehmen (bsp. rpc.frankysweb.de) und die Exchange Konfiguration auf diesen Hostnamen anzupassen (wie auch von Sophos vorgesehen). So lässt sich eine neue Geschäftsanwendungsregel aus der Vorlage nutzen, um nur die notwendigen Schutzmechanismen für Outlook Anywhere (RPCoverHTTP) zu deaktivieren und nicht auch gleich für alle anderen Dienste.

Ich habe es trotzdem ausprobiert, ob es möglich ist mit zwei Hostnamen und zwei Firewallregeln auszukommen: Ja, geht, ist aber Kacke, denn meiner Ansicht nach deaktiviert es faktisch die Webserver Protection. Nahezu alle Features müssen deaktiviert werden. Da ich diese Konfiguration für derart unsauber halte möchte ich es auch nicht veröffentlichen. Wer unbedingt darauf besteht, kann mir eine Mail schreiben und bekommt dann ein kleines HowTo.

4 Kommentare zu “Sophos XG: Exchange 2016 und SFOS 16.05 Webserver Protection (Teil 2)”

  1. Hallo,
    lässt sich das ganze a) ohne Web Server Protection Subscription machen? Und b) gilt dieses Szenario auch wenn ich ein Site-to-Site VPN habe und die Outlook Clients in der Branch meinen Exchange Server im HQ über die VPN Verbindung erreichen möchten?

    1. Hi Vincent,
      du könntest auch ein DNAT Eintrag anlegen, oder eben die Benutzer nur via VPN auf den Exchange lassen. Die Exchange URLs müssen natürlich trotzdem konfiguriert werden.
      Gruß, Frank

  2. Hallo,
    eben diesen DNAT Eintrag habe ich gemacht. Der Sophos support hat dazu geraten. Nur funktioniert dies einfach nicht. DNAT für IP und die 3 FQDN also autodiscover, owa, und servername. sowohl port 80 und 443. Nichts davon funktioniert bzw. es hat funktioniert und nun nicht mehr.
    Im Sophos Forum gibt es dieses Problem auch nicht nur einmal.
    Mfg Vincent

  3. Hi Franky, ein Distri hat dich empfohlen, irgendwie gibt es wenig Leute die so geile HowTo schreiben. Läuft soweit alles. In der neusten XG Home ist „websocket durchlassen“ beim Pfad-spezifisches Routing hinzugekommen, ist wohl egal, habe es nicht angehakt. Warum gibt es eigentlich diverse Pfade wie mapi in Groß und klein, hinten mit „/“ und dann wieder ohne „/“ ?

    Viele Grüße Sven

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.