Exchange Hybrid hinter der Sophos XGS: WAF-Publishing ohne böse Überraschungen

Die Sophos XGS als Reverse Proxy für Exchange — dazu ist die Doku-Lage erstaunlich dünn, und wer im Hybrid-Betrieb OWA, EWS und Autodiscover veröffentlichen muss, landet schnell im Trial-and-Error. Die Kurzantwort vorab: Ja, das Publishing über die Web Application Firewall der XGS funktioniert zuverlässig — wenn man die Detailfallen kennt. Und davon gibt es drei Sorten: Pfadausnahmen (Exchange-Clients vertragen etliche WAF-Härtungen schlicht nicht), Zertifikatsketten (das vergessene Zwischenzertifikat ist der Klassiker) und die Hybrid-Endpunkte (Exchange Online ruft deinen Server aktiv an — und eine übermotivierte WAF-Regel lässt still den Frei/Gebucht-Abgleich sterben). Dieser Artikel liefert die erprobte Konfiguration: welche Endpunkte von außen erreichbar sein müssen, wie die WAF der XGS tickt, die Publishing-Regeln je Dienst samt Ausnahmen-Tabelle, das Zertifikats- und SNI-Handling, der Hybrid-Test — und was im Betrieb bei jedem CU-Update zu prüfen ist.

Exchange-Hybrid-Endpunkte: was von außen erreichbar sein muss

Bevor eine einzige WAF-Regel entsteht, gehört die Frage geklärt: Wer muss eigentlich von außen an diesen Server? Die Antwort hat zwei Zielgruppen mit unterschiedlichen Bedürfnissen. Zielgruppe eins sind die eigenen Benutzer unterwegs — sie brauchen je nach Nutzung /owa für den Browser, /Microsoft-Server-ActiveSync für native Mail-Apps, /mapi (und als Rückfallebene /rpc) für Outlook, dazu /oab für das Offline-Adressbuch und /autodiscover, damit die Clients ihre Konfiguration überhaupt finden. Zielgruppe zwei ist Exchange Online selbst, und das wird gern übersehen: Im Hybrid ruft die Microsoft-Cloud deinen On-Prem-Server aktiv an — über /EWS für den Frei/Gebucht-Abgleich und die Postfach-Migration (MRS-Proxy) sowie über /autodiscover für die Organisationssuche. Diese Aufrufe kommen aus Microsofts definierten IP-Bereichen und lassen sich entsprechend eng fassen.

Genauso wichtig ist die Negativliste: /PowerShell hat von außen unter keinen Umständen etwas verloren — dieser Pfad ist die Fernverwaltung des Servers und war in den Exchange-Sicherheitsvorfällen der vergangenen Jahre regelmäßig Teil der Angriffskette. Und /ecp ist ein Zwiespalt: Die OWA-Einstellungsseiten der Benutzer laufen technisch über diesen Pfad, das Admin Center aber auch. Der pragmatische Kompromiss: /ecp mitveröffentlichen, weil sonst die Benutzer-Optionen in OWA brechen, aber den administrativen Zugriff organisatorisch und über die Verwaltungsrollen absichern — Exchange-Administration gehört ohnehin ins interne Netz oder hinter das VPN, nicht an den öffentlichen Endpunkt. Wer OWA gar nicht von außen anbietet, spart sich den Zwiespalt komplett.

WAF-Grundlagen auf der Sophos XGS: die Firewall als Reverse Proxy

Die Web Application Firewall der XGS — im Regelwerk als Webserver-Schutz zu Hause — macht aus der Firewall einen echten Reverse Proxy: Sie terminiert die TLS-Verbindung des Clients, prüft die Anfrage auf Anwendungsebene und baut eine neue Verbindung zum Backend auf. Das Baukastenprinzip besteht aus vier Teilen. Erstens der echte Webserver: dein Exchange-Server mit interner Adresse und Port. Zweitens der virtuelle Server: die Außenseite mit öffentlichem Hostnamen, Port 443 und dem Zertifikat — hier klingelt das Internet. Drittens die Schutzrichtlinie: das Regelpaket auf Basis der eingebauten Application-Firewall-Engine, das Angriffe auf Anwendungsebene filtert — von SQL-Injection-Mustern bis zu Protokollverstößen. Und viertens die Ausnahmen: gezielte Abschaltungen einzelner Prüfungen für definierte Pfade — das Werkzeug, mit dem aus einer generischen WAF eine Exchange-taugliche wird.

Zwei Grundlagen entscheiden über Erfolg oder Frust. Grundlage eins: Sophos liefert vordefinierte Exchange-Schutzvorlagen mit — unter anderem für OWA, Autodiscover und Outlook Anywhere. Die sind der richtige Startpunkt, denn sie bringen die bekanntesten Exchange-Verträglichkeitsausnahmen bereits mit; blanke Standard-Webserver-Richtlinien auf Exchange loszulassen ist dagegen der schnellste Weg zu kryptischen Client-Fehlern. Grundlage zwei: Die Härtungsfunktionen der WAF — statisches URL-Hardening, Formular-Härtung, Cookie-Signierung — sind für klassische Webanwendungen gedacht, in denen ein Browser brav HTML lädt und Formulare abschickt. Exchange-Clients sind keine Browser: ActiveSync-Handys, Outlook über MAPI und die EWS-Aufrufe aus der Cloud sprechen eigene Protokolle über HTTPS, und wer ihnen umgeschriebene URLs oder signierte Cookies unterschiebt, produziert Verbindungsabbrüche statt Sicherheit. Die Kunst ist deshalb nicht »alles an«, sondern die richtige Richtlinie mit den richtigen Ausnahmen je Pfad.

Publishing-Regeln für OWA, ECP, EWS, ActiveSync und Autodiscover

Jetzt zur konkreten Bauanleitung. Das bewährte Muster: ein virtueller Server für mail.firma.de auf Port 443 mit dem SAN-Zertifikat, dahinter der Exchange-Server als Backend — und die Differenzierung passiert über pfadspezifische Regeln und Ausnahmen. Für /owa gilt die strengste Gangart, denn hier reden echte Browser: Die OWA-Vorlage darf weitgehend scharf bleiben, inklusive der Filterung typischer Web-Angriffsmuster. Für /Microsoft-Server-ActiveSync gilt das Gegenteil: URL-Hardening, Formular-Härtung und Cookie-Signierung müssen für diesen Pfad aus, sonst synchronisiert kein einziges Handy — die Geräte können mit manipulierten Antworten schlicht nichts anfangen. Ähnlich /mapi und /rpc für Outlook Anywhere: lange Verbindungen, große Requests, keine Toleranz für umgeschriebene Inhalte.

Der sensibelste Pfad ist /EWS, denn hier treffen sich Benutzer-Clients und die Hybrid-Aufrufe aus Exchange Online — was genau dort ausgenommen werden muss, bekommt im Free/Busy-Kapitel seinen eigenen Faktenkasten. /autodiscover braucht Erreichbarkeit von überall (Clients wie Cloud finden darüber den Weg) und verträgt ebenfalls keine Härtungsspielereien. Und für die Hybrid-Härtung gilt die schöne Option aus der Architektur-Skizze: Wer OWA und ActiveSync gar nicht von außen anbieten will, beschränkt die verbleibenden Pfade /EWS und /autodiscover auf Microsofts Quell-IP-Bereiche — dann ist der Server für das Internet praktisch unsichtbar und nur noch für die Cloud da. Die Tabelle fasst die Behandlung je Dienst zusammen; sie ist das Herzstück dieses Artikels und der Teil, den du dir an die Wand pinnen darfst.

Skizze 1: Ein virtueller Server, eine Pfad-Weiche — grün veröffentlichen, gelb abwägen, rot niemals. Die Hybrid-Pfade lassen sich auf EXO-Quellnetze einschränken.

Zertifikate und SNI richtig handhaben

Die halbe Fehlersuche beim Exchange-Publishing ist Zertifikatskunde, deshalb hier die Ordnung. Auf den virtuellen Server gehört ein öffentliches SAN-Zertifikat, das beide benötigten Namen abdeckt — mail.firma.de und autodiscover.firma.de. Der entscheidende Handgriff dabei: die vollständige Kette importieren, also neben dem Serverzertifikat auch das Zwischenzertifikat der ausstellenden CA. Hier lauert der beliebteste Fehler des ganzen Themas, und er ist besonders fies, weil er asymmetrisch zuschlägt: Desktop-Browser reparieren eine fehlende Zwischeninstanz oft selbstständig, indem sie das fehlende Glied nachladen — ActiveSync-Geräte und die EWS-Aufrufe aus Exchange Online tun das nicht und brechen kommentarlos ab. Das Fehlerbild »geht am PC, aber kein Handy synchronisiert« ist deshalb bis zum Beweis des Gegenteils ein Ketten-Problem, kein ActiveSync-Problem.

Der zweite Baustein ist SNI, die Server Name Indication: Der Client nennt beim TLS-Aufbau den gewünschten Hostnamen, und die XGS wählt danach den passenden virtuellen Server samt Zertifikat aus — so lassen sich mail.firma.de und autodiscover.firma.de sauber auf derselben öffentlichen IP und demselben Port betreiben, auf Wunsch mit unterschiedlich strengen Pfad-Regeln (der Autodiscover-Server braucht ja nur einen einzigen Pfad). Die drei SNI-Grundregeln stehen in der Skizze; die wichtigste davon ist banal und wird trotzdem verletzt: Der Hostname im virtuellen Server muss exakt zum Namen im Zertifikat passen. Bleibt die Frage, woher die Zertifikate kommen und wie ihre Erneuerung nicht zum jährlichen Überraschungsei wird — Ausstellung, Automatisierung und interne PKI sind Thema des Zertifikats-Artikels [LINK: B12]; hier genügt die Betriebsregel: Ablaufdatum ins Monitoring, und nach jedem Tausch die Kette erneut prüfen, denn der Tausch ist der Moment, in dem das Zwischenzertifikat traditionell verloren geht.

Skizze 2: Links die Kette (das Zwischenzertifikat gehört mit auf die XGS!), rechts die SNI-Zuordnung — der Name entscheidet über virtuellen Server und Zertifikat.

Hybrid-Mailfluss und Free/Busy testen

Im Hybrid ist dein On-Prem-Exchange kein Solist mehr, sondern Teil eines Duetts — und die XGS sitzt zwischen den Stimmen. Die Kommunikationsmatrix hat vier Kernflüsse: Exchange Online ruft deinen Server über 443 auf /EWS an (Frei/Gebucht-Abgleich, Postfach-Migration über den MRS-Proxy, OAuth-Austausch) und liefert Mails per SMTP auf Port 25 ein; in der Gegenrichtung spricht dein Server über 443 und 25 mit der Cloud. Die WAF ist dabei nur für die 443-Seite zuständig — der SMTP-Fluss läuft als klassische DNAT-Regel an ihr vorbei, und dessen Feinheiten von Konnektor-TLS bis zur Beschränkung auf EXO-Quellnetze gehören in den Mailfluss-Artikel [LINK: B5]. Für die 443-Seite gilt die Härtungs-Chance aus der Skizze: Diese Aufrufe kommen ausschließlich aus Microsofts dokumentierten IP-Bereichen — die Hybrid-Pfade dürfen und sollten auf genau diese Quellen beschränkt werden.

Und dann ist da die eine Falle, die Hybrid-Projekte zuverlässig Stunden kostet — würdig ihres eigenen Faktenkastens gleich im Anschluss: Die EWS-Aufrufe aus der Cloud sind Maschinenverkehr mit OAuth-Token, großen SOAP-Bodies und null Toleranz für WAF-Kreativität. Getestet wird der Hybrid-Zustand deshalb immer aus beiden Richtungen: Ein Cloud-Postfach fragt den Kalender eines On-Prem-Kollegen ab und umgekehrt (Frei/Gebucht in beide Richtungen), eine Testmigration eines kleinen Postfachs prüft den MRS-Pfad, und Microsofts Remote Connectivity Analyzer klopft von außen Autodiscover, EWS und ActiveSync durch — er ist das ehrlichste kostenlose Werkzeug für diesen Job, weil er sich exakt wie die Cloud verhält und Zertifikatsketten nicht durchgehen lässt.

Skizze 3: Vier Flüsse, jede Zeile eine Firewall-Regel — und die grünen EXO-Pfeile lassen sich auf Microsofts Quellnetze festnageln.

Betrieb: CU-Updates und ihre Nebenwirkungen

Exchange-Publishing ist kein Bauwerk, sondern ein Betrieb — und der Taktgeber sind die kumulativen Updates. Ein CU ist faktisch eine Neuinstallation des Servers über sich selbst: Es fasst die virtuellen Verzeichnisse an, setzt gelegentlich Authentifizierungseinstellungen zurück und verändert das Verhalten einzelner Endpunkte — alles Dinge, die eine fein abgestimmte WAF-Konfiguration aus dem Tritt bringen, ohne dass auf der Firewall ein Bit geändert wurde. Die Betriebsregel: Nach jedem CU (und erst recht nach außerplanmäßigen Sicherheitsupdates) läuft die komplette Test-Checkliste — das Backend hat sich unter der WAF bewegt. Gleiches gilt umgekehrt nach SFOS-Firmware-Updates. Dazu der Jahreskalender: Zertifikatserneuerung mit Ketten-Kontrolle, quartalsweise die Microsoft-Quell-IP-Listen der Hybrid-Beschränkungen, und jede WAF-Ausnahme sollte noch begründbar sein. Wer vor der Frage steht, ob statt der XGS-WAF ein dedizierter Load Balancer her muss: Für den typischen Ein-Server-Mittelstand nicht — die Abwägung samt Kemp-Erfahrungen steht im Bestandsartikel [LINK: Kemp-Bestandscontent].

FAQ — häufige Fragen zum Exchange-Publishing über die Sophos XGS

Kann die Sophos XGS als Reverse Proxy für Exchange dienen?

Ja — die Web Application Firewall der XGS ist ein vollwertiger Reverse Proxy: Sie terminiert TLS am virtuellen Server, prüft die Anfragen auf Anwendungsebene gegen Schutzrichtlinien und reicht sie an den Exchange-Server als Backend weiter. Für den typischen Mittelstand mit einem oder zwei Exchange-Servern ersetzt sie damit die Rolle, die früher TMG, UAG oder ein dedizierter Load Balancer spielten — inklusive der Exchange-spezifischen Schutzvorlagen, die Sophos gleich mitliefert. Die ehrliche Einordnung dazu: Es funktioniert zuverlässig, aber nicht per Einschaltknopf — der Unterschied zwischen »läuft« und »läuft stabil« steckt in den pfadspezifischen Ausnahmen, der vollständigen Zertifikatskette und den Hybrid-Besonderheiten, also genau den Themen dieses Artikels. Wer die drei beherrscht, bekommt ein Publishing, das auch der Auditor gern sieht: Schutz auf Anwendungsebene statt nackter Portweiterleitung.

Welche Pfade brauchen WAF-Ausnahmen?

Merksatz: Alles, was kein Browser ist, verträgt keine Browser-Härtungen. Konkret brauchen /Microsoft-Server-ActiveSync, /mapi, /rpc, /EWS, /autodiscover und /oab Ausnahmen von den inhaltsverändernden Funktionen — statisches URL-Hardening, Formular-Härtung und Cookie-Signierung gehören dort ab, für /EWS zusätzlich der Antivirus-Scan der Anfrageinhalte, und die Limits für Anfragegrößen und Timeouts gehören großzügig gefasst (Outlook hält lange Verbindungen, EWS transportiert große SOAP-Bodies). Weitgehend scharf bleiben darf die Richtlinie auf /owa und /ecp, wo tatsächlich Browser reden. Zwei Disziplinregeln dazu: Ausnahmen immer pfadgenau setzen, niemals global — sonst ist die WAF nur noch Dekoration. Und jede Ausnahme mit einem Satz Begründung dokumentieren, denn in zwei Jahren fragt garantiert jemand, warum sie da ist. Die Sophos-Exchange-Vorlagen bringen einen guten Teil davon bereits mit — prüfen statt blind vertrauen gilt trotzdem.

Warum funktioniert Autodiscover nach dem Publishing nicht?

Die Verdächtigen in absteigender Häufigkeit: Erstens die Zertifikatskette — fehlt das Zwischenzertifikat auf der XGS, scheitern ausgerechnet die pingeligen Clients (Handys, Cloud-Aufrufe), während der Test-Browser fröhlich funktioniert. Zweitens der Namensraum: autodiscover.firma.de muss öffentlich auflösen, auf die XGS zeigen, im Zertifikat als SAN stehen und im virtuellen Server exakt so heißen — ein Tippfehler in einem der vier Glieder genügt. Drittens übermotivierte WAF-Härtungen auf dem /autodiscover-Pfad, die die XML-Antworten verstümmeln. Das Diagnose-Werkzeug der Wahl ist Microsofts Remote Connectivity Analyzer: Er dokumentiert jeden Schritt der Autodiscover-Kette einzeln und zeigt auf einen Blick, welches Glied reißt — damit ist die Ursache in zehn Minuten gefunden statt in zwei Stunden geraten.

Brauche ich noch einen separaten Load Balancer?

Für die typische Mittelstandsumgebung mit einem Exchange-Server: nein — dort gibt es schlicht nichts zu balancieren, und die XGS-WAF liefert Publishing samt Schutzschicht komplett. Bei zwei Servern wird es zur Abwägungsfrage: Die WAF kann mehrere Backends bedienen und verteilt Anfragen darauf, und weil die Exchange-Client-Access-Architektur seit 2016 zustandslos ist, braucht es keine ausgefeilte Sitzungs-Persistenz mehr — für viele Zwei-Server-Umgebungen reicht das völlig. Ein dedizierter Load Balancer spielt seine Stärken aus, wenn feinere Health-Checks je Dienst (ist /owa gesund, /EWS aber nicht?), differenzierte Verteilstrategien oder größere Serverfarmen ins Spiel kommen. Die ausführliche Abwägung samt Praxiserfahrungen mit Kemp-Systemen steht im Bestandsartikel [LINK: Kemp-Bestandscontent] — die Kurzfassung für die Entscheidung: erst prüfen, ob die eingebaute WAF den Bedarf deckt, denn ein Gerät weniger ist auch ein Betriebsthema weniger.

Wie veröffentliche ich Exchange nur für Hybrid, nicht für Benutzer?

Das ist ein ausgesprochen sinnvolles Szenario — etwa wenn die Benutzer längst in der Cloud arbeiten und der On-Prem-Server nur noch als Hybrid-Anker für Verwaltung und Restpostfächer dient. Das Rezept in drei Schritten: Erstens die Pfadliste radikal kürzen — veröffentlicht werden nur noch /EWS (Frei/Gebucht, Migration, OAuth) und /autodiscover; OWA, ActiveSync, MAPI und der ganze Benutzerzoo fliegen aus dem virtuellen Server. Zweitens die Quellbeschränkung: Die verbleibenden Pfade werden auf Microsofts dokumentierte Quell-IP-Bereiche für Exchange Online begrenzt — damit ist der Server für das restliche Internet faktisch unsichtbar, obwohl er technisch veröffentlicht ist. Drittens der SMTP-Fluss auf Port 25, der als eigene DNAT-Regel ebenfalls auf die EXO-Netze beschränkt gehört. Das Ergebnis ist die angenehmste Form des Exchange-Publishings: null Angriffsfläche für Passwort-Sprays, weil es schlicht keinen Anmelde-Endpunkt für Menschen mehr gibt — nur noch Maschinenverkehr zwischen zwei bekannten Parteien.

Was ändert sich mit Exchange SE?

Fürs Publishing: erfreulich wenig. Die Subscription Edition ist technisch der direkte Nachfolger von Exchange 2019 (Upgrade als In-Place-Verfahren), die Client-Access-Architektur samt virtueller Verzeichnisse bleibt erhalten — damit gelten Publishing-Regeln, Pfad-Ausnahmen und Zertifikatsanforderungen aus diesem Artikel unverändert weiter. Was sich ändert, ist der Rahmen: Exchange 2016 und 2019 haben ihr Support-Ende erreicht — wer On-Prem-Exchange im Hybrid weiterbetreibt, kommt am Wechsel nicht vorbei, schon weil ein ungepatchter, öffentlich veröffentlichter Exchange die denkbar schlechteste Kombination ist. Und das Abo-Modell verschärft den Betriebspunkt aus dem CU-Kapitel eher: Die Update-Kadenz bleibt, also bleibt auch die Regel, nach jedem Update die Test-Checkliste zu fahren.

Fazit: Erprobte Konfiguration schlägt Trial-and-Error

Exchange-Publishing über die XGS-WAF ist kein Hexenwerk, aber auch kein Selbstläufer — es ist ein Handwerk mit drei Gewerken: die richtige Richtlinie mit pfadgenauen Ausnahmen (Browser-Härtungen nur dort, wo Browser reden), die vollständige Zertifikatskette samt sauberem SNI (das Zwischenzertifikat ist der ewige Verdächtige) und der Respekt vor den Hybrid-Pfaden, allen voran /EWS mit seiner Free/Busy-Falle. Dazu die Betriebsdisziplin, nach jedem CU die Checkliste zu fahren, und als Härtungs-Bonus die Quell-IP-Beschränkung der Cloud-Pfade. Wer diese Konfiguration einmal sauber aufbaut, hat ein Publishing, das jahrelang unauffällig läuft — und unauffällig ist bei einem öffentlich erreichbaren Exchange das größte Kompliment, das der Betrieb vergeben kann.

Von hier aus weiter im Cluster: Das Gesamtbild der XGS in Microsoft-Umgebungen zeichnet der Pillar-Artikel [LINK: Pillar]. Die zweite Hälfte des Hybrid-Duetts — SMTP-Fluss, Konnektoren, SPF und die Beschränkung der Einlieferung auf Exchange Online — behandelt der Mailfluss-Artikel [LINK: B5]. Woher die Zertifikate kommen und wie ihre Erneuerung automatisiert wird, klärt [LINK: B12]. Und die Abwägung WAF gegen dedizierten Load Balancer vertieft der Bestandsartikel [LINK: Kemp-Bestandscontent].