Sophos Firewall WAF mit MFA absichern

Mit Sophos Firewall WAF MFA kann man Webanwendungen, die über die Web Application Firewall veröffentlicht werden, zusätzlich mit Multi-Factor Authentication absichern. Das ist besonders sinnvoll für interne Portale, Admin-Oberflächen, Kundenbereiche oder Partnerzugänge, die zwar über HTTPS erreichbar sein müssen, aber nicht nur durch die Anwendung selbst geschützt werden sollen.

WAF-MFA ersetzt keine sichere Anwendung, kein Patch-Management und kein sauberes Berechtigungskonzept. Es ist eine vorgelagerte Schutzschicht auf der Firewall. Die Firewall prüft zuerst die Anmeldung und den zweiten Faktor, bevor der Zugriff auf den geschützten Webserver weitergeleitet wird.

Wichtig ist die Version: Die integrierte MFA für WAF ist eine SFOS-22-Funktion. Auf älteren Firmwareständen muss man für WAF-Veröffentlichungen mit anderen Architekturen arbeiten, zum Beispiel mit externer Authentifizierung, dediziertem Reverse Proxy, VPN oder ZTNA.

Für die grundsätzliche Veröffentlichung eines Webservers über WAF passt zuerst die Anleitung Sophos Firewall WAF: Webserver sicher veröffentlichen. Dieser Artikel konzentriert sich auf die vorgelagerte Authentifizierung und MFA.

Wann WAF-MFA sinnvoll ist

WAF-MFA ist vor allem dann stark, wenn eine Webanwendung aus dem Internet erreichbar sein muss, aber nicht öffentlich für alle Besucher gedacht ist.

Typische Einsatzfälle:

• interne Portale mit externem Zugriff
• Admin-Oberflächen von Fachanwendungen
• Partner- oder Kundenportale mit begrenztem Benutzerkreis
• Legacy-Webanwendungen ohne eigene starke MFA
• Anwendungen, bei denen ein zusätzlicher Zugriffsschutz vor dem Backend gewünscht ist

Für öffentliche Websites, Shops oder Informationsseiten ist WAF-MFA meistens nicht passend, weil jeder Besucher zuerst eine Firewall-Anmeldung sehen würde. Bei komplexen privaten Anwendungen kann auch ZTNA, SSE oder ein dedizierter Reverse Proxy sinnvoller sein als WAF-MFA. Wenn WebDAV benötigt wird, sollte man besonders vorsichtig sein: Sophos WAF unterstützt WebDAV nicht sauber, was bei Anwendungen wie Nextcloud relevant werden kann.

Wann WAF-MFA nicht ausreicht

WAF-MFA ist eine vorgelagerte Zugriffsschicht. Diese Schicht beantwortet aber nicht jede Architekturfrage. Vor allem bei kritischen Portalen sollte man bewusst entscheiden, ob die Anwendung überhaupt öffentlich erreichbar sein soll.

• Anwendung ist nur für wenige interne Benutzer gedacht: VPN, ZTNA, feste Quellnetze oder eine nicht öffentliche Veröffentlichung prüfen.
• Anwendung enthält besonders sensible Daten: Backend-Berechtigungen, Logging, Audit Trail und Anwendungssessions zusätzlich prüfen.
• Anwendung braucht WebDAV oder Spezialprotokolle: WAF-Kompatibilität vor dem Rollout testen oder eine andere Architektur wählen.
• Externe Partner greifen selten zu: Token-Rollout, Supportprozess und Fallback besonders klar dokumentieren.
• Backend hat eigene Anmeldung und Rollen: WAF-MFA nur als zusätzliche Schicht betrachten, nicht als Ersatz für Backend-Rollen.

Wenn ein Portal weltweit erreichbar bleibt, sollte MFA nicht die einzige Massnahme sein. Feste Quellnetze, Länderbegrenzung, Threat Feeds, Schutzprofile und saubere Backend-Patches reduzieren das Risiko zusätzlich.

Voraussetzungen

Vor der Einrichtung sollten diese Punkte geklärt sein:

• Die Webanwendung ist bereits über eine WAF-Regel geplant oder veröffentlicht.
• Die Firewall läuft auf SFOS 22 oder neuer.
• Benutzer oder Gruppen sind auf der Firewall vorhanden, zum Beispiel lokal, über AD, LDAP oder RADIUS.
• Die Benutzer können ihren OTP-Token einrichten.
• Die Systemzeit der Firewall ist korrekt und NTP funktioniert.
• Für die WAF-Regel wird HTTPS mit passendem Zertifikat verwendet.
• Es ist klar, ob der Backend-Webserver eigene Authentifizierung braucht oder ob die Firewall die Anmeldung vollständig übernehmen soll.
• Ein Testbenutzer und ein administrativer Fallback-Zugang sind vorhanden.

⚠️ MFA für WAF sollte zuerst mit einer Pilotgruppe getestet werden. Eine falsche Kombination aus MFA-Gruppe, WAF-Authentifizierungsrichtlinie und Backend-Authentifizierung kann legitime Benutzer aussperren oder eine Anwendung scheinbar “kaputt” machen.

Pilot, Fallback und Verantwortlichkeiten planen

WAF-MFA wirkt vor der eigentlichen Anwendung. Deshalb sollte man den Rollout nicht wie eine normale Firewall-Regel behandeln, sondern wie eine Änderung am Loginprozess der Anwendung. Benutzer sehen zuerst die Anmeldung der Sophos Firewall und erst danach, je nach Backend, die eigentliche Anwendung.

Vor dem Einschalten sollten diese Punkte feststehen:

• Welche Benutzergruppe testet zuerst?
• Wer kann den Zugriff wieder deaktivieren, wenn die Anmeldung fehlschlägt?
• Gibt es einen zweiten Admin-Zugang, der nicht von derselben WAF-Regel, demselben Portal oder demselben Testbenutzer abhängt?
• Welche Anwendungsteile müssen nach erfolgreichem Login getestet werden?
• Wer prüft reverseproxy.log, Log Viewer und Backend-Logs bei Fehlern?
• Wie werden Benutzer über Token, Session-Ablauf und mögliche zweite Backend-Anmeldung informiert?

Ein häufiger Planungsfehler ist die Vermischung von Firewall-Authentifizierung und Backend-Authentifizierung. Die WAF kann Benutzer vor dem Backend prüfen. Das heisst aber nicht automatisch, dass die Anwendung selbst keine eigene Anmeldung, Rollenprüfung oder Session-Verwaltung mehr braucht. Besonders bei Admin-Portalen und Kundendaten sollte die Backend-Berechtigung bewusst erhalten bleiben.

Wenn der veröffentlichte Dienst nur für wenige Personen gedacht ist, sollte man zusätzlich zur MFA die Quellen einschränken. Für die Grundveröffentlichung und Quellbegrenzung passt Sophos Firewall WAF: Webserver sicher veröffentlichen. Wenn Benutzerrechte oder Remote-Access-MFA allgemein geplant werden, hilft MFA für Sophos Firewall WebAdmin, VPN Portal und Remote Access aktivieren.

Ein Rollback sollte vor dem Einschalten vorbereitet sein. Praktisch heisst das: alte funktionierende Zugriffsmethode dokumentieren, WAF-Regel und Authentication Policy benennen, zuständige Person festlegen und einen Zeitpunkt wählen, an dem Benutzerfeedback und Logprüfung möglich sind. Wenn die Anwendung geschäftskritisch ist, sollte WAF-MFA zuerst für eine Testdomain, eine Pilotgruppe oder ein Wartungsfenster aktiviert werden.

Bausteine der Konfiguration

Für WAF-MFA müssen mehrere Einstellungen zusammenpassen:

• MFA-Einstellung: Legt fest, welche Benutzer MFA verwenden und ob Web application firewall geschützt wird.
• WAF authentication policy: Definiert Anmeldemodus, Benutzer/Gruppen, Vorlage und Session-Verhalten.
• WAF rule: Verknüpft den veröffentlichten Webserver mit der Authentication Policy.
• Backend authentication forwarding: Legt fest, ob die Firewall Anmeldedaten an den Webserver weitergibt.
• Token-Rollout: Stellt sicher, dass Benutzer ihren OTP-Code tatsächlich erzeugen können.

Der wichtigste Unterschied: MFA wird nicht nur global aktiviert. Die betroffene WAF-Regel muss auch eine passende Authentication Policy verwenden.

MFA für WAF aktivieren

Der Menüpfad lautet:

Authentication > Multi-factor authentication

Vorgehen:

1. Unter One-time password (OTP) entweder All users oder Specific users and groups auswählen.
2. Bei Specific users and groups die betroffenen Benutzer oder Gruppen hinzufügen.
3. Generate OTP token with next sign-in aktivieren, wenn Benutzer ihren Token selbst beim nächsten Login einrichten sollen.
4. Unter Require MFA for die Option Web application firewall aktivieren.
5. OTP hash algorithm und bei Bedarf OTP timestep settings bewusst setzen.
6. Konfiguration speichern.

Wenn Generate OTP token with next sign-in aktiv ist, wird User portal automatisch als Dienst für die QR-Code-Ersteinrichtung ausgewählt. Benutzer müssen den QR-Code in einem Portal sehen können, bevor der erste WAF-MFA-Login realistisch funktioniert. Je nach Umgebung ist zusätzlich das VPN Portal oder WebAdmin relevant. Die allgemeine MFA-Planung ist in MFA für Sophos Firewall WebAdmin, VPN Portal und Remote Access aktivieren beschrieben.

Token-Rollout und Benutzerkommunikation vorbereiten

WAF-MFA scheitert im Betrieb oft nicht an der eigentlichen WAF-Regel, sondern am Token-Rollout. Benutzer müssen wissen, wo der QR-Code erscheint, welche App verwendet werden soll, wie lange eine Session gültig ist und ob nach der Firewall-Anmeldung noch eine zweite Anmeldung an der Anwendung folgt.

Vor dem Einschalten der produktiven WAF-Regel sollte man festlegen:

• Token-Erstellung: Wo richtet der Benutzer den OTP-Token ein?
• Portal-Zugriff: Ist das User Portal oder ein anderer vorgesehener QR-Code-Pfad für die betroffenen Benutzer erreichbar?
• Authenticator-App: Welche App ist freigegeben und mit dem gewählten Algorithmus getestet?
• Fallback: Wer kann einen verlorenen oder defekten Token zurücksetzen?
• Notfallcodes: Ist bekannt, ob und wie zusätzliche einmalige Passcodes im Supportfall ausgegeben werden dürfen?
• Supportfall: Welche Informationen braucht der Helpdesk bei Loginproblemen?
• Kommunikation: Welche Loginabfolge sehen Benutzer ab dem Go-live?

Wenn Generate OTP token with next sign-in verwendet wird, sollte der erste Login kontrolliert getestet werden. Dabei ist wichtig, ob Benutzer den QR-Code im erwarteten Portal sehen und ob sie danach mit Passwort plus OTP erfolgreich auf die WAF-Anwendung zugreifen können. Die Portale selbst sind in Sophos Firewall Portale: WebAdmin, User Portal und VPN Portal einordnen beschrieben.

Für viele Firewall-Dienste wird der OTP-Code als Kombination aus Passwort und Passcode verarbeitet. Deshalb sollte in Benutzerkommunikation und Helpdesk-Runbook klar stehen, welche Eingabemaske die Benutzer tatsächlich sehen und ob Passwort und OTP getrennt oder kombiniert eingegeben werden müssen. Bei WAF-MFA mit Form-basierter Anmeldung ist dieser Punkt besonders wichtig, weil eine zweite Backend-Anmeldung sonst schnell als “MFA defekt” fehlinterpretiert wird.

Sophos Authenticator sollte nicht mehr als neue Standard-App eingeplant werden, da die App seit 2022 End of Life ist. In der Praxis sollten Intercept X for Mobile, Google Authenticator, Microsoft Authenticator, Duo Mobile, Okta Verify oder eine intern freigegebene App getestet werden. Entscheidend ist nicht nur der Name der App, sondern ob sie den gewählten Algorithmus, den Zeitschritt und den QR-Code der Firewall korrekt unterstützt.

Für Helpdesk und Betrieb sollte mindestens dokumentiert sein:

• veröffentlichter Hostname der WAF-Anwendung
• betroffene Benutzergruppe
• verwendete Authentication Policy
• verwendeter OTP-Algorithmus
• erlaubte Authenticator-App
• Ablauf für Token-Reset
• erwartete Meldung bei falschem Passwort oder falschem OTP
• Logstellen für Erstprüfung: Log Viewer und reverseproxy.log

Besonders bei externen Partnern oder selten genutzten Portalen sollte der erste Login nicht erst im produktiven Notfall passieren. Ein kurzer Pilot mit normalen Benutzern deckt oft Probleme auf, die Admins im eigenen Test nicht sehen: abweichende Authenticator-App, fehlender Portalzugriff, unklare zweite Backend-Anmeldung oder Session-Timeouts, die für die Anwendung zu kurz sind.

WAF Authentication Policy erstellen

Der Menüpfad lautet:

Web server > Authentication policies

Für WAF-MFA sollte der Client-Modus auf Form gesetzt werden. Bei Form-basierter Authentifizierung kann die Firewall die Anmeldung über ein Formular und Sessions steuern.

Vorgehen:

1. Add öffnen.
2. Einen sprechenden Namen vergeben, zum Beispiel WAF_MFA_Portal_Users.
3. Bei Mode die Option Form auswählen.
4. Eine passende Authentication template auswählen.
5. Die Benutzer oder Gruppen auswählen, die Zugriff auf diese WAF-Veröffentlichung erhalten.
6. Den Authentication forwarding mode bewusst wählen.
7. Session timeout und Session lifetime passend zur Anwendung setzen.
8. Speichern.

Authentication forwarding richtig wählen

Der Authentication forwarding mode entscheidet, was zwischen Firewall und Backend passiert.

• None: Die Firewall authentifiziert den Benutzer, der Webserver bekommt keine Anmeldedaten.
• Basic: Die Firewall gibt Benutzername und Passwort per HTTP Basic Authentication an das Backend weiter.

Wenn die Anwendung keine eigene Authentifizierung benötigt oder die vorgelagerte Firewall-Anmeldung genügen soll, ist None oft sauberer. Wenn das Backend selbst HTTP Basic Authentication erwartet, muss der Forwarding-Modus zur Anwendung passen.

Bei None sollte man zusätzlich prüfen, ob Remove basic header gesetzt werden muss. Damit verhindert man, dass ein vom Client gesendeter Basic-Authentication-Header unnötig an den Webserver weitergereicht wird. Das ist besonders wichtig, wenn alte Clients, gespeicherte Browserdaten oder frühere Veröffentlichungen noch Basic-Header erzeugen.

⚠️ Basic Authentication sollte nur mit HTTPS verwendet werden. Ausserdem muss klar sein, ob das Backend wirklich die von der Firewall weitergegebenen Anmeldedaten verarbeiten soll.

Der Modus Basic ist nicht einfach eine bequemere Variante von Form-Sessions. Bei Basic Authentication entstehen keine dedizierten Session-Cookies und ein sauberer Logout über die Firewall ist nicht gleich wie bei Form-basierter Anmeldung. Für WAF-MFA und steuerbares Session-Verhalten ist deshalb Form der sauberere Ausgangspunkt.

Authentication Policy in der WAF-Regel verwenden

Die WAF-Regel wird unter Rules and policies > Firewall rules bearbeitet. Die Aktion lautet Protect with web server protection.

In der betroffenen WAF-Regel müssen diese Punkte zusammenpassen:

• Richtiger Hosted address und Listening Port.
• Richtige Domain und passendes HTTPS-Zertifikat.
• Richtiger geschützter Webserver.
• Gewünschte Authentication policy ausgewählt.
• Benutzergruppe in der Authentication Policy passt zur MFA-Gruppe.
• Zugriffsbeschränkungen über Allowed client networks, Länder oder Threat Feeds sind bewusst gesetzt.

Für öffentliche oder stark exponierte Portale sollte MFA nicht die einzige Schutzmassnahme sein. Länder- und Quellenbegrenzung ist in Sophos Firewall: Länder und bösartige IPs blockieren beschrieben. Für dynamische Sperrlisten passt Sophos Firewall Threat Feeds.

Sessions und Timeout planen

Bei Form-basierter WAF-Authentifizierung arbeitet die Firewall mit Sessions. In der Authentication Policy legt man fest:

• Session timeout: nach welcher Inaktivität sich Benutzer neu anmelden müssen
• Session lifetime: wie lange eine Anmeldung maximal gültig bleibt

Zusätzlich gibt es unter Web server > General settings die maximale Anzahl gleichzeitiger Sessions für formbasierte Reverse-Proxy-Authentifizierung. Der Standardwert liegt bei 25,000, der unterstützte Bereich bei 100 bis 100,000.

Kurze Sessions erhöhen die Sicherheit, können aber Benutzer stören. Sehr lange Sessions sind bequemer, erhöhen aber das Risiko, dass ein gestohlener oder geteilter Browserzugang länger nutzbar bleibt. Für Admin-Portale sollte man eher konservativ starten und das Verhalten im Betrieb beobachten.

Wenn sehr viele Benutzer oder mehrere WAF-Portale dieselbe Firewall nutzen, sollte die globale Session-Grenze nicht erst bei Fehlermeldungen geprüft werden. Formbasierte WAF-Authentifizierung ist ein gemeinsamer Reverse-Proxy-Betriebsparameter und gehört deshalb in die Kapazitäts- und Monitoring-Überlegung.

OTP-Algorithmus und Authenticator-App

SFOS 22 unterstützt neben SHA1 auch SHA256 und SHA512 für OTP-Tokens. Das ist aus Sicherheitssicht sinnvoll, funktioniert aber nur, wenn die verwendete Authenticator-App den gewählten Algorithmus unterstützt.

Wichtige Punkte:

• SHA256 oder SHA512 sind sicherer als SHA1.
• Nicht jede Authenticator-App unterstützt diese Algorithmen in diesem Kontext.
• Microsoft Authenticator kann bei SHA256 oder SHA512 zwar den QR-Code scannen, die Anmeldung kann danach aber fehlschlagen.
• Wenn der Algorithmus geändert wird, müssen alte Tokens gelöscht und neu gescannt werden.
• Änderungen am Token-Zeitschritt gelten nur für neu erzeugte Tokens und müssen zur verwendeten App passen.

Für produktive Rollouts sollte man die gewünschte App und den Algorithmus mit einer kleinen Pilotgruppe testen. Erst danach sollten bestehende Benutzer breit migriert werden.

Wenn ein Benutzer die App verliert oder der Algorithmus geändert wird, reicht es oft nicht, nur die Benutzerkommunikation zu wiederholen. Unter Authentication > Multi-factor authentication > Issued tokens können Token zurückgesetzt oder zusätzliche einmalige Codes erzeugt werden. Dieser Ablauf sollte intern geregelt sein, weil er einen starken Sicherheitsbezug hat.

Testplan nach der Einrichtung

Nach der Konfiguration sollte man nicht nur prüfen, ob die Loginseite erscheint. Wichtig ist, den kompletten Zugriffspfad zu testen.

1. Externen Browser oder externes Testnetz verwenden.
2. WAF-URL mit einem Benutzer aus der erlaubten Gruppe öffnen.
3. Login mit korrektem Passwort und OTP testen.
4. Login mit falschem OTP testen.
5. Benutzer ausserhalb der erlaubten Gruppe testen.
6. Session-Ablauf nach Inaktivität prüfen.
7. Backend-Funktion der Anwendung prüfen.
8. Log Viewer und reverseproxy.log auf Auffälligkeiten prüfen.
9. Logout, erneuter Login und Session-Ablauf mit demselben Browser prüfen.
10. Test mit einem zweiten Hostnamen oder alternativen Pfad durchführen, falls die Anwendung mehrere WAF-Regeln nutzt.

Für die Logdateien hilft Sophos Firewall Troubleshooting: Services und Logs. WAF-Ereignisse hängen typischerweise am Reverse Proxy und tauchen zusätzlich im Log Viewer auf.

Für die Abnahme sollte jeder Testfall einem sichtbaren Ergebnis zugeordnet werden:

• Benutzer: Firewall-Login erscheint, OTP wird abgefragt, danach öffnet die erwartete Anwendung.
• Sophos Firewall: Log Viewer und reverseproxy.log zeigen erlaubte oder abgelehnte WAF-Authentifizierung.
• Authentifizierungsquelle: AD, LDAP, RADIUS oder lokale Benutzerquelle zeigt den erwarteten erfolgreichen oder fehlgeschlagenen Login.
• Backend: Anwendung erreicht den richtigen Benutzer- oder Gastzustand und zeigt keine unerwartete zweite Fehlerseite.

Wenn nur der Browser erfolgreich wirkt, aber keine passenden Logs sichtbar sind, ist die Abnahme unvollständig. Dann sollte man prüfen, ob die richtige WAF-Regel matched, ob die Authentication Policy wirklich aktiv ist und ob Logs am erwarteten Ort landen.

Go-live und Betrieb nach der Aktivierung

Nach einem erfolgreichen Test sollte WAF-MFA nicht einfach breit eingeschaltet und danach vergessen werden. Die ersten Stunden nach dem Go-live sind wichtig, weil echte Benutzer andere Browser, andere Authenticator-Apps, gespeicherte Passwörter, alte Bookmarks und andere Session-Zustände mitbringen als ein Admin-Test.

Für den Go-live ist ein kleiner Betriebsplan sinnvoll:

• Rollout-Gruppe: zuerst Pilotgruppe, danach weitere Benutzergruppen.
• Supportfenster: Helpdesk oder zuständige Admins während der ersten Logins erreichbar halten.
• Monitoring: Log Viewer, reverseproxy.log und Authentifizierungsquelle beobachten.
• Token-Reset: klarer Ablauf für verlorene oder falsch eingerichtete OTP-Tokens.
• Session-Verhalten: Session timeout und Session lifetime nach realer Nutzung prüfen.
• Rückfallweg: WAF-Regel, Authentication Policy und Änderungsschritte dokumentiert halten.

Bei geschäftskritischen Anwendungen sollte man den Go-live nicht auf einen Zeitpunkt legen, an dem niemand Loginprobleme sauber prüfen kann. Besser ist ein kontrolliertes Fenster mit Testbenutzern aus verschiedenen Gruppen, danach ein kurzer Review der Logs und erst anschliessend die Ausweitung auf weitere Benutzer.

Nach einigen Tagen sollte die Konfiguration nochmals geprüft werden:

• Gibt es Benutzer, die MFA umgehen, weil sie über eine andere WAF-Regel oder eine andere URL zugreifen?
• Wird der Zugriff weiterhin nur für die geplanten Gruppen erlaubt?
• Passen Session-Dauer und Inaktivitäts-Timeout zur Anwendung?
• Werden abgelehnte Logins und Token-Probleme im Betrieb tatsächlich gesehen?
• Gibt es Supportfälle, die auf unklare Benutzerkommunikation oder falsche Authenticator-App hinweisen?
• Sind alte Testregeln, Testdomains oder temporäre Ausnahmen wieder entfernt?

Dieser Nachlauf ist besonders wichtig, wenn mehrere Hostnamen, Pfade oder WAF-Regeln auf dieselbe Anwendung zeigen. Sonst kann es passieren, dass ein Pfad sauber mit MFA geschützt ist, ein zweiter Pfad aber weiterhin ohne vorgelagerte Authentifizierung erreichbar bleibt.

Typische Fehler

• Web application firewall unter Require MFA for nicht aktiviert: WAF-Login fragt keinen zweiten Faktor ab.
• Authentication Policy verwendet nicht Form: MFA-Verhalten passt nicht zur erwarteten WAF-Konfiguration.
• WAF-Regel nutzt keine Authentication Policy: Benutzer erreichen die Anwendung ohne vorgelagerte Anmeldung.
• MFA-Gruppe und WAF-Policy-Gruppe unterscheiden sich: Benutzer werden nicht wie erwartet abgefragt oder abgelehnt.
• Backend erwartet eigene Basic Authentication, Forwarding steht auf None: Firewall-Login funktioniert, Backend lehnt Zugriff ab.
• Forwarding steht auf Basic, Backend erwartet keine Authentifizierung: Anwendung reagiert unerwartet oder sieht unnötige Header.
• OTP-App unterstützt den gewählten Hash-Algorithmus nicht: QR-Code wird gescannt, Login schlägt trotzdem fehl.
• Sophos Authenticator als neue Standard-App eingeplant: Die App ist EOL und sollte nicht mehr als neue Rollout-Basis dienen.
• Session lifetime zu lang: Benutzer bleiben länger angemeldet als betrieblich gewünscht.
• Globale WAF-Session-Grenze nicht beachtet: Formbasierte Reverse-Proxy-Logins können bei vielen Benutzern oder mehreren Portalen an Grenzen stossen.
• Fallback-Zugang hängt von derselben WAF-Regel ab: Admins können die Änderung im Fehlerfall nicht mehr sauber zurücknehmen.
• Token-Rollout wurde nicht getestet: Benutzer scheitern beim ersten Login, obwohl die WAF-Regel technisch korrekt ist.
• Zweite URL oder zweite WAF-Regel bleibt ohne MFA aktiv: Benutzer umgehen die vorgelagerte MFA unbeabsichtigt.
• Temporäre Pilot-Ausnahmen werden nicht entfernt: Der produktive Schutz ist uneinheitlich und schwer auditierbar.

Troubleshooting

MFA wird nicht abgefragt

Zuerst prüfen, ob Web application firewall unter Require MFA for aktiviert ist. Danach kontrollieren, ob die WAF-Regel wirklich eine Authentication Policy verwendet und ob diese Policy die erwarteten Benutzer oder Gruppen enthält.

Login funktioniert, aber die Anwendung öffnet nicht

Dann liegt das Problem oft nach der Firewall-Anmeldung. Backend-Erreichbarkeit, Zertifikat, Host Header, Pfad, Protection Policy und Authentication forwarding prüfen. Wenn das Backend eigene Authentifizierung erwartet, muss der Forwarding-Modus dazu passen.

Benutzer kann sich nach Algorithmuswechsel nicht anmelden

Wenn von SHA1 auf SHA256 oder SHA512 gewechselt wurde, müssen bestehende Tokens gelöscht und neu gescannt werden. Zusätzlich muss die Authenticator-App den neuen Algorithmus unterstützen.

Passwort und OTP werden an das Backend weitergegeben

Bei WAF-MFA sollte geprüft werden, ob die Firewallversion aktuell ist. In den SFOS-22.0-Release-Notes ist ein behobener WAF-Fehler dokumentiert, bei dem der OTP-Code nicht aus dem Passwort entfernt wurde, bevor Daten an das Backend weitergegeben wurden.

Backend fragt nach erfolgreicher MFA erneut nach Login

Wenn nach einem Upgrade auf SFOS 22 die MFA-Anmeldung erfolgreich ist, das Backend aber trotzdem erneut eine Anmeldung verlangt, sollte man nicht sofort Benutzer, Token oder Passwortregeln ändern. In der Sophos Known-Issues-Liste ist mit NC-177509 ein WAF/MFA-Problem dokumentiert, bei dem Form-basierte WAF-MFA mit Authentication forwarding zu einer zusätzlichen Backend-Anmeldung führen kann.

Prüfen:

• WAF Authentication Policy verwendet Form.
• Authentication forwarding mode ist aktiv und passt zur Backend-Anwendung.
• Die betroffene WAF-Regel nutzt genau diese Authentication Policy.
• Der Fehler tritt nach erfolgreicher MFA auf, nicht schon bei der Firewall-Anmeldung.
• reverseproxy.log, Log Viewer und Backend-Access-Log decken denselben Testzeitpunkt ab.
• Die verwendete SFOS-Version und bekannte Hinweise aus der Sophos Known Issues List sind geprüft.

Als Workaround sollte nicht blind auf weniger Schutz umgestellt werden. Zuerst muss klar sein, ob das Backend wirklich weitergeleitete Anmeldedaten erwartet oder ob Authentication forwarding mode auf None gestellt werden kann. Bei produktiven Portalen gehören Testbenutzer, Rollback, Supportfall und Benutzerkommunikation zusammen geplant.

Zu viele oder alte Sessions

Session timeout, Session lifetime und die globalen WAF-Session-Einstellungen prüfen. In produktiven Umgebungen sollte klar sein, ob lange Sessions gewünscht sind oder ob Benutzer nach Inaktivität zügig neu authentifiziert werden müssen.

Checkliste

• WAF-Regel ist dokumentiert und extern getestet.
• HTTPS-Zertifikat passt zum veröffentlichten Hostnamen.
• MFA gilt für die richtige Benutzergruppe.
• Require MFA for > Web application firewall ist aktiviert.
• WAF Authentication Policy verwendet Form.
• Authentication forwarding passt zur Backend-Anwendung.
• Token-Rollout, Portalzugriff und Helpdesk-Ablauf sind vorbereitet.
• Session timeout und Session lifetime sind bewusst gesetzt.
• OTP-App und Hash-Algorithmus wurden getestet.
• Fallback-Admin-Zugriff ist vorhanden.
• Rollback und zuständige Person sind dokumentiert.
• Authentifizierungsquelle und Backend-Login wurden getrennt geprüft.
• Log Viewer und reverseproxy.log wurden nach dem Test geprüft.
• Go-live-Supportfenster und Token-Reset-Ablauf sind festgelegt.
• Alternative Hostnamen, Pfade und WAF-Regeln wurden auf MFA-Umgehung geprüft.
• Temporäre Pilot-Ausnahmen wurden nach dem Rollout entfernt.

Häufige Fragen