Der letzte Artikel zur Sophos XG in Verbindung mit Exchange ist schon wieder etwas in die Jahre gekommen, daher gibt es hier mal wieder eine aktualisierte Version. Zur Zeit ist die SFOS 18 aktuell, getestet habe ich die Version 18.0.4 MR-4. Meine kleine Testumgebung ist wie folgt aufgebaut:
Exchange ist auf die Hostnamen outlook.frankyswebweblab.de für die Webservices und autodisocver.frankysweblab.de für Autodiscover konfiguriert. Intern und extern sind die gleichen Hostnamen konfiguriert. Alles weitere folgt im Artikel.
Konfiguration Sophos XG Webserver Protection
Damit später die Webserver Protection der Sophos XG konfiguriert werden kann, muss zunächst ein SSL-Zertifikat installiert werden. Leider unterstützt die XG in der Version 18 immer noch keine automatisierten Let’s Encrypt Zertifikate. Das Let’s Encrypt Feature (wie es schon lange auf der Sophos UTM vorhanden ist), ist schon lange auf der Wunschliste der Benutzer, vielleicht schafft es das Feature ja in einer der nächsten Versionen. Aktuell muss also noch ein entsprechendes Zertifikat beschafft werden. Da die meisten Verbindungen via Webserver Protection zu Exchange von externen Clients kommen, sollte es sich hier um ein Zertifikat einer öffentlichen CA handeln, damit das Zertifikat von allen Clients als Vertrauenswürdig anerkannt wird. Auf dem Zertifikat müssen der DNS-Name für die Exchange Webservices und für Autodiscover enthalten sein (weitere Informationen finden sich im Exchange Zertifikate Whitepaper). In meinem Fall enthält das Zertifikat den Namen outlook.frankysweblab.de und autodiscover.frankysweblab.de.
Das Zertifikat kann unter dem Punkt “Certificates” hinzugefügt werden:
Das Zertifikat kann im PFX oder PEM Format hochgeladen werden:
Nachdem das Zertifikat hochgeladen wurde, wird es in der Übersicht angezeigt. Auch wenn es in dieser Übersicht nicht angezeigt wird, das Zertifikat enthält die DNS-Namen outlook.frankysweblab.de und autodiscover.frankysweblab.de. Beide Namen sind wichtig, damit später keine Zertifikatswarnungen oder Fehler bei der Einrichtung der Outlook Clients auftreten:
Jetzt kann unter dem Punkt “Web servers” der Exchange Server als Webserver hinzugefügt werden. Wenn es mehrere Exchange Server in der Organisation gibt, muss hier der Virtual Server des Loadbalancers angegeben werden. Es können hier nicht einfach alle Exchange Server angegeben werden (dies ist auch bei der Sophos UTM der Fall). Entweder muss hier also der eine Exchange Server angelegt werden, oder aber ein Loadbalancer zwischen XG und Exchange implementiert werden:
Der Exchange Server wird hier als IP oder als FQDN Host angelegt:
In meinem Fall habe ich den Exchange Server als IP Host angegeben:
Zum Abschluss muss nun noch der Wert im Feld “Type” auf “Encrypted (HTTPS)”, sowie der “Time-out” auf “1850” umgestellt werden:
Jetzt können zwei neue “Protection Policy” für Exchange 2019 angelegt werden. Die Sophos Templates eignen sich nicht für Exchange 2019/2016, da sie komplett veraltet sind. Es sollte daher eine neue Policy für Exchange 2019 angelegt werden (funktioniert auch mit Exchange 2016):
Die Policy für die Exchange 2019 Dienste wie OWA und EWS, kann beispielsweise “Exchange Webservices”genannt werden und bekommt zunächst folgende Einstellungen:
Hinweis: Die Einstellung “Pass Outlook Anywhere” wird nicht mehr benötigt, alle Clients ab Outlook 2010 sprechen MAPIoverHTTP. Auf Exchange 2019 Server ist dies auch das bevorzugte Protokoll, auf Exchange 2016/2013 Servern muss es ggf. noch aktiviert werden.
Hier die vollständige Liste der Entry URLs:
- /ecp
- /ECP
- /ews
- /EWS
- /Microsoft-Server-ActiveSync
- /oab
- /OAB
- /owa
- /OWA
- /
- /mapi
- /MAPI
Die folgenden 4 Filter Regeln müssen ausgeschlossen werden:
- 960010
- 960015
- 981204
- 981176
Eine weitere Policy ist für Autodiscover erforderlich, diese wird wie folgt konfiguriert:
Hier die Entry URLs:
- /autodiscover
- /Autodiscover
Die folgenden beiden Filter Regeln müssen ausgeschlossen werden:
- 960015
- 960911
Nachdem die beiden Regeln erstellt wurden, sieht es in der Übersicht nun so aus:
Jetzt können zwei neue Firewall Regeln für Exchange angelegt werden:
Die erste Regel ist für die Exchange Webservices, die Einstellungen können den Screenshots entnommen werden. Wichtig ist, dass als “Hosted address” der WAN Port der Sophos XG ausgewählt wird:
Als “Protected Server” wird natürlich der Exchange 2019 Server ausgewählt:
Im Bereich “Advanced” wird nun die zuvor erstellte Protection Policy ausgewählt und “Pass host header” aktiviert (“Pass host header” ist insbesondere für nachgelagerte Loadbalancer wichtig):
Die zweite Firewall Regel ist für Autodiscover, die Regel wird nahezu identisch zur ersten Regel konfiguriert. Wichtig ist hier, dass im Feld “Domains” der Eintrag “outlook.frankysweblab.de” durch “autodiscover.frankysweblab.de” ersetzt wird:
Hinweis: Das zuvor konfigurierte Zertifikat muss beide Namen enthalten, zwei einzelne Zertifikat mit jeweils einem Hostnamen funktionieren hier nicht.
Als Protected Server wird wieder der Exchange 2019 Server ausgewählt:
Im Bereich Exceptions kann jetzt die Protection Policy für Autodiscover ausgewählt und die Einstellung “Pass host header” aktiviert werden:
Beim Speichern der Firewall Regel wird eine Warnung angezeigt, dass das Zertifikat den Hostnamen “autodisocver.frankysweblab.de” nicht abdecken würde. Die Meldung ist allerdings Quatsch. Die XG scheint hier einfach nur den CN (Common Name) des Zertifikats auszuwerten, nicht aber die SAN-Einträge (Subject Alternate Name”. Die Regel lässt sich aber trotzdem speichern und funktioniert auch:
Nachdem die beiden Regeln erstellt wurden, sieht es nun wie folgt in der Übersicht aus:
Zum Schluss müssen nun noch die beiden DNS-Einträge “outlook.frankysweblab.de” und “autodiscover.frankysweblab.de” auf die WAN IP der Sophos XG zeigen (im öffentlichen DNS).
Hallo,
kann es sein, dass hier in den Richtlinien ein dicker Fehler sich eingeschlichen hat? Sollte es nicht heißen „überwachen“ und nicht wie auf den Bildern zu sehen „ablehnen“???
Mit freundlichen Grüßen.
Oliver Spenn
Überwachen bedeutet der Webserver monitort nur – tut aber nix.
Ablehnen bedeutet er arbeitet – ist an.
Damit die Empfänger-Verfizierung (Empfänger verifizieren „Mit Serveranfrage“ oder Recipient Verification) korrekt funktioniert (Bounce bei nicht existenten E-Mailadressen beispielsweise), muss etwas bei dem Exchange-Server nachjustiert werden:
falls bei
Get-TransportAgent
der
„Recipient Filter Agent“ gelistet ist, dann:
Enable-TransportAgent „Recipient Filter Agent“
Falls nicht, dann:
& „D:\Exchange Server\Scripts\install-AntispamAgents.ps1“
Disable-TransportAgent „Content Filter Agent“
Disable-TransportAgent „Sender Id Agent“
Disable-TransportAgent „Sender Filter Agent“
Disable-TransportAgent „Protocol Analysis Agent“
Restart-Service MSExchangeTransport
Get-TransportAgent
nachzulesen mit Bildern hier:
https://support.mxguardian.net/hc/en-us/articles/360048500492-Enable-Recipient-Filtering-for-Exchange-2013-2016-2019
Ich habe aus einer funktionierenden Konfiguration ein Template erstellt. Dieses kann nach wenigen Bearbeitungsschritten direkt auf der Firewall importiert werden. Dadurch erspart man sich das mühsame erstellen der Policies und Firewall-Regeln.
Das XML-File und eine kleine Anleitung findet sich in meinem GitHub-Repo: https://github.com/hifishch/sophosxg-templates/tree/main/WAF%20Microsoft_Exchange_2016
Hallo,
danke für die super Anleitung und überhaupt für diese super Seite! Zum Glück bin ich drübergestolpert – Wahnsinns Arbeit!
Bei mir gehen die Mails zwar raus aber es kommen keine Mails rein. Und scheinbar wird intern die Domain falsch aufgelöst mydomain.com wird zu mydomain.com/owa umgeleitet (nur hinter der Firewall).
Das ist meine erste Sophos Firewall und der Support hat mich gleich mal enttäuscht. Vielleicht kann mich ja hier jemand in die richtige Richtung schupsen?
Danke schonmal und LG aus Wien,
NR
hast du mittlerweile eine Lösung gefunden?
OWA Zugriff hat nichts mit deinem Mailfluss zu tun. Den konfigurierst du unter EMAIL – nicht unter Web Server protection.
Das ändern der URL findet durch den Exchange server statt. da im ECP mal unter virtuelle Verzeichnisse gucken was konfiguriert ist unter Server
Hallo, gehört hier nicht ganz hin aber gibt es so etwas auch für die Einrichtung des RemoteDesktopGateways; also /rpc usw.
Ich versuche das gerade auf einer XG hinzubekommen aber im Internet hab ich bis jetzt für eine XG noch nichts richtiges gefunden.
mfg.
hartmut
Hallo,
ich habe das ganze jetzt mal mit Windows 2019 und Exchange 2019 ausprobiert.
Mein Setup läuft in 3 VM´s (DC, Mail und Sophos XG 18.5.1 mit 2 Interfaces).
Als Client nehme ich ein iPhone, das über einen AP15 sich über die WiFi Zone (Public WAN IP) verbindet.
Aber, es fehlen die „Protected server Exceptions“ und Filter Rule Nummern bei den FW Regeln.
Sophos hat das hier beschrieben
https://support.sophos.com/support/s/article/KB-000040209?language=en_US
Ein Webmail über OWA funktioniert soweit.
ActiveSync läuft mit dem Sophos Artikel dann auch.
Sophos gibt ja weitere Filternummern und einen anderen Filter Level an.
Die fehlenden Filter Nummern lassen sich ganz gut über die Shell ermitteln.
Einfach mit dem CMD anzeigen lassen… Die Nummern stehen dann im Log.
tail -n 5000 -f /log/reverseproxy.log | grep security2:error
Gruß
Jürgen
Hi, vielen Dank für den Link. Das Ganze hat mich EXTREM voran gebracht.
Ich bin Frankysweb echt dankbar, da hier viel Content auf hohem Level ist, aber über diesen Beitrag von Franky zur XG bin ich sehr enttäuscht.
Du hast mit deinem Post für mich den Beitrag allerdings gerettet :-)
Danke nochmal :-)
Hi Zusammen,
um Let´s Encrypt Zertifikate auf der Sophos zu updaten habe ich mir aus vielen Foren eine PS7 Script gebaut, welches das Zertifikat auf der Sophos updatet.
1. Powershell7 installieren
2. PS-Module KEMP-ADC instalieren ( Install-Module -Name Kemp.LoadBalancer.Powershell -RequiredVersion 7.2.54.0 )
3. ein PS Script mit folgendem Inhalt erstellen
# replace Certificate on Sophos XG
# Username, Password, Name, CertificateFile muss dem Wert aus Zeile $PFXfileProd entsprechen, Zertifikate Password müssen angepasst werden
# $uri = bitte die IP der Sophos eintragen
$request = „***Username******Password***UploadCertificate***CertName***pkcs12***cert.pfx******CertPassword***“
$uri = „https://x.x.x.x:4444/webconsole/APIController?reqxml=“
$PFXfileProd = „C:\temp\cert.pfx“
$Form = @{
reqxml = $request
$((Get-Item $PFXfileProd).Basename) = Get-Item -Path $PFXfileProd
}
$Result = Invoke-RestMethod -Uri $Uri -Method Post -Form $Form -SkipCertificateCheck
Viel Spaß damit
Gruß Daniel
leider hat er die Formatierung geändert so kann es leider nicht funktionieren.
Vielleicht kann ich das Script Franky schicken und er fügt es ein.
Gruß Daniel
Hi, vielen Dank für das Script. Ich würde mal anhand dessen behaupten, du nutzt hinter deiner Sophos noch einen Kemp?
Ich habe versucht anhand dieser Anleitung es so aufzubauen: Sophos XGS mit Webserver Protection -> Kemp (für Pre-Auth) -> Exchange 2016
Leider werden bei mir die Active Sync Verbindung abgewiesen. Inbound Anomaly Score Exceeded (Total Score: 10). Hast du es auch nach dieser Anleitung eingerichtet und evtl. noch Anpassungen gemacht? Ich habe schon versucht div. weitere Filterregeln auszuklammern.
Gruß, Christian
Hallo Daniel! Klingt sehr interessant. Kann man das vollständige Script wo downloaden? LG, Andreas
Hallo, ich hatte auch das Problem mit „no signature found“.
Anhand der Anleitung für Exchange 2016 von Sophos direkt konnte ich es zum Laufen bringen. (Noch nicht groß getestet, aber man kann sich einloggen.)
https://support.sophos.com/support/s/article/KB-000038003?language=en_US
Womit es bei mir geklappt hat:
– Bei der Protection Policy „Exchange Webservices“ noch die IDs 960018, 960032, 981203 hinzufügen
– Bei den Firewallregeln des Exchange Webservice müssen noch 3 Ausnahmen angelegt werden:
1. /ecp/* /ECP/* /ews/* /EWS/* /Microsoft-Server-ActiveSync* /oab/* /OAB/* /owa/* /OWA/*
Operation: egal, alle Checkboxen aus, außer Static URL Hardening, Never change HTML during static URL hardening or form hardening (wurde oben im Forum verlinkt)
2. /owa/ev.owa* /OWA/ev.owa*
Operation: egal, Alle Checkboxen aus, außer Antivirus
3. /mapi/* /MAPI/*
Operation: egal, Alle Checkboxen an (!)
– Bei den Firewallregeln für Autodiscover braucht man eine Ausnahme: /autodiscover/* /Autodiscover/*
Operation: egal, Alle Checkboxen aus, außer Static URL Hardening und Never change HTML during static URL hardening or form hardening
In der Anleitung wird auch noch /RPC/* behandelt, aber das ist ja rpc-over-http, was wir eh nicht mehr verwenden.
Wenn das hier nicht gut formatiert wird, schaut am besten direkt auf den Sophos-Link
Hallo Flomp
Danke für die Hilfestellung.
Was aber noch nicht funktioniert, sind User mit Umlaute.
Sonst aber 1a
Regards,
Hallo,
ich habe die Verbindung zum Exchange nur hinbekommen nachdem ich die Ausnahmen in der Firewallregel genau wie früher in der SG hinzugefügt habe. Aber den Hinweis dazu habe ich in der Anleitung nicht gefunden.
Ist das eine Besonderheit bei mir?
ActiveSync geht auch mit Ausnahme noch nicht. OWA und MAPI und so sind aber jetzt okay.
*kopfkratz*
Ralph
Hallo Ich habe das gleiche Problem mit „no signature found“ trotz der oben beschrieben Ausnahmen
Guten Morgen Michi,
hast du das Problem gelöst bekommen? Ich stehe vor dem selben Problem. Wenn ja, was hast du geändert?
Danke,
Alireza
gibts dafür ein bereits angefertigtes Skript irgendwo?
Mit einem Powershell-Script kann man auch unter der Sophos XG LetsEncrypt-Zertifikate über die API relativ bequem wechseln, die über Posh-ACME angefordert wurden. Wünschenswert wäre aber, wenn Sophos endlich den Zertifikatstausch nativ anbieten würde.
Autodiscover funktioniert bei mir mit Filter Strengh 3 und den genannten Ausnahmeregeln ebenfalls nicht -> Forbidden. Mit Filter Strengh 1 und 2 klappt es wieder problemlos.
Erfolgreiche Logins im OWA werden mir mit „Forbidden“ quittiert. Anhand des Reverseproxy Logs kam raus dass die Rule mit ID 949110 den Zugriff blockiert. Mit Filter Strength 1 und 2 passiert das nicht. Wahrscheinlich wird die entsprechende Regel dort einfach nicht angewendet. Die ID zu den Exchange Webservices als Ausnahme hinzugefügt und schon klappte der Login auch mit Filter Strengh 3.
Bei mir kommt ebenfalls die Meldung
Request blocked
The web application firewall has blocked access to /owa/auth/logon.aspx for the following reason:
No signature found
Wurde das überhaupt mal getestet bevor man es postet? Scheinbar nicht.
Hallo Franky,
sind 1850 Sekunden nicht arg lang? Woher hast du diesen Wert?
VG
Hatte mich auch gewundert und bin bei 300 geblieben. Bei großen Bestandspostfächern wurde dann aber per ActiveSync nichts geladen. Mit den 1850 war kamm dann alles.
Hallo Franky,
ein weiteres Problem tritt bei mir nach der Einrichtung anhand dieser Anleitung auf. Bei aufrufen per Browser erscheint folgende Meldung:
Request blocked
The web application firewall has blocked access to /owa/auth/logon.aspx for the following reason:
No signature found
Auch funktioniert die Verbindung mit den iPhones nicht mehr. Hättest du eine Idee woran es liegen kann?
Vielen Dank.
Dies konnte ich nun selbst lösen dank eines Foreneintrages:
https://www.frankysweb.de/community/exchange2016/sophos-xg-waf-und-exchange-2016/
Hallo Franky,
nach der Konfiguration haben wir das Problem, dass keine Anhänge versendet werden können außerhalb des Netzwerkes. Wenn man im lokalen Netz drin ist, es also nicht über die Sophos läuft funktioniert es tadellos. Jedoch wenn man sich von Extern mit dem Exchange verbindet, egal ob per OWA, Outlook oder Smartphone, ist der Versand von Mails mit Anhang nicht möglich. Bei Google Recherche findet man das Problem, jedoch keine richtige Lösung. Hast du hier schon Erfahrung?
Vielen Dank & einen schönen Sonntag :)
Grüße Chris
Zusätzlich ist mir noch folgendes aufgefallen, eine Verbindung mit Outlook bei Windows 10 ist von außerhalb auch nicht möglich. Im Outlook Verbindungsstatus wird unter „Authn“ angezeigt: „Fehler*“…
Die Frage ist viel mehr, wie geht es mit der Entwicklung von Sophos UTM (FW 9.8, 9.9, 9.10) überhaupt weiter und wie entwickelt sich die XG Serie. Von vielen Seiten merkt man Stillstand oder 0 Kommunikation des Herstellers, wie ist euer Bauchgefühl?
Sophos hat mir persönlich leider zu oft Fehler gemacht in der Entwicklung der XG. Viele Updates haben das System verschlimmbessert.
Ich bin nun auf Fortigate Firewalls umgestiegen und seither 0 Probleme.
Bin mit der utm sehr zufrieden, doch fehlen or einige features. Auch ist ds update Intervall der UTM zu lange, hier würde ich whr updates erwarten, nicht nur neue features.
Der xg fehlen mor noch zu viele features.
Schade, ist ein tolles Produkt.
Die Sophos Politik sieht so aus, dass UTM (SG) Kunden mit großem Aufwand (z.B. kostenloser Migration der Lizenzen) der Umstieg schmackhaft gemacht werden soll.
Das lässt wiederum vermuten, dass die UTM Schiene über kurz oder lang eingestellt wird; schon jetzt hat die Betreuung deutlich nachgelassen
Wer sich, wie ich, eine XG Migration unterjubeln lassen hat, wird leider auch nicht wirklich glücklich.
Im Unternehmensumfeld mit komplexeren Firewallanforderungen ist die Konfiguration sehr hakelig; die GUI ist wesentlich unübersichtlicher, als die der UTM.
Außerdem hat sie sehr lange Ladezeiten.
Wer Probleme hat, muss sich mit dem dürftigen Support rumschlagen.
Das gesamte Produkt wirkt unausgereift; von der UTM bekannte Features fehlen z.T.
Meine persönliche Meinung:
Sophos hat die UTM, die unter Astaro einmal Spitzenklasse war, zugunsten der XG auf’s Abstellgleis geschoben.
Dumm nur, dass die XG der UTM immer noch nicht das Wasser reichen kann.
Darum kann ich Sophos leider nicht mehr empfehlen und schaue mich mittelfristig für einen Ersatz für unser Firmenumfeld um.
Updates für SG sind dürftig und die verwendete Software teilw. steinalt (bspw. Strongswan für IPSEC). XG wird besser, allerdings in sehr kleinen Schritten. Letsencrypt Feature wurde vor sieben Jahren das erste mal angefragt, bisher nicht umgesetzt. Beim letzten Update hat man sich damit gerühmt jetzt DHCP Optionen zu können (Ernsthaft??). Die Bedienung ist unübersichtlich und sehr träge. Das können andere besser.
Unterstützt die XG mittlerweile zertifikate von let’sEncrypt?