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.

Einsatz und Planung

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. WebDAV wird von Sophos WAF nicht unterstützt; Anwendungen wie Nextcloud sind deshalb keine unterstützten WAF-Veröffentlichungen. Dafür eine andere Architektur mit passenden Firewall-Regeln und eigenem Zugriffsschutz planen; eine Veröffentlichung ohne WAF übernimmt nicht automatisch dessen Authentifizierung oder Anwendungsschutz.

WAF schützt auf Layer 7 unter anderem vor Cookie-, URL- und Formularmanipulation. Webserver, Protection Policy und Authentication Policy werden über die WAF-Regel verbunden; maximal 60 WAF-Regeln sind möglich. Den WAF-Dienst verwaltet man unter System services > Services. Ein Dienstneustart betrifft die veröffentlichten Anwendungen und ist kein erster Schritt bei einzelnen Loginfehlern.

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: Eine andere Architektur wählen; ein Pilot macht die fehlende WAF-Unterstützung nicht zu einer unterstützten Lösung. Bei anderen Spezialprotokollen die Kompatibilität vor dem Rollout gesondert prüfen.
• 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.

Konfiguration

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. Die Standardwerte sind 30 Sekunden für Default token timestep, 2 für Maximum verification code offset und 10 für Maximum initial verification code offset.
6. Konfiguration speichern.

Wenn Generate OTP token with next sign-in aktiv ist, wird User portal automatisch als Dienst ausgewählt. Benutzer melden sich zuerst am VPN portal oder User portal an und scannen dort den QR-Code. Für den Default-Administrator ist stattdessen die WebAdmin-Konsole vorgesehen, wenn MFA für dessen WebAdmin-Anmeldung erzwungen wird. Dieser Onboarding-Schritt muss vor dem ersten WAF-Zugriff funktionieren. Die allgemeine MFA-Planung ist in MFA für Sophos Firewall WebAdmin, VPN Portal und Remote Access aktivieren beschrieben.

Die beiden Offset-Werte sind keine normale Lösung für eine falsche Uhrzeit. Bei einem 30-Sekunden-Zeitschritt akzeptiert ein Maximum verification code offset von 2 beispielsweise einen noch unbenutzten Code aus den vorherigen 60 Sekunden. Ein grösseres Fenster macht die Anmeldung toleranter, verlängert aber auch die Gültigkeit älterer Codes. Deshalb zuerst NTP und Smartphone-Uhr korrigieren und den Offset nur begründet ändern.

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.

Beim Rollout zählt auch das mobile Betriebssystem: Der QR-Scan der Okta-App funktioniert für diese Tokens auf iOS und Android nicht. Auf iOS gilt diese Einschränkung zudem für Google Authenticator, Duo und Microsoft Authenticator. In diesen Fällen muss der Benutzer den Base32 secret manuell eintragen. Das gehört in die Benutzeranleitung; andernfalls wirkt ein reines QR-Code-Runbook trotz korrekter Firewall-Konfiguration defekt.

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. Form-basierte Authentifizierung erzeugt Session-Cookies und ermöglicht einen dedizierten Logout; die Firewall steuert die Anmeldung über das Formular und die Sessions.

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.

Die SFOS-23-XML-API-Dokumentation beschreibt ausschliesslich für den Client-Modus Form den optionalen Parameter RedirectToRequestedURL mit den Werten Enable und Disable. Mit Enable wird der Benutzer nach erfolgreicher Authentifizierung zur ursprünglich angeforderten URL zurückgeleitet. Die Dokumentation nennt dafür keinen Standardwert; der API-Parameter ist keine belegte GUI-Feldbezeichnung. Die Weiterleitung ersetzt weder Authentifizierung noch Berechtigungsprüfung.

Authentication forwarding richtig wählen

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

• None: Keine Backend-Authentifizierung durch die Firewall; die vorgelagerte Authentifizierung bleibt aktiv. Für das Entfernen eines vom Client mitgesendeten Basic-Headers ist zusätzlich Remove basic header relevant.
• 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 Client-Modus Basic erzeugt keine Session-Cookies und bietet keinen dedizierten Logout. Für WAF-MFA verlangt Sophos deshalb den Client-Modus Form. Davon unabhängig muss der Authentication forwarding mode zum Backend passen.

Im Client-Modus Basic ist Basic prompt nur der Hinweistext im Browserdialog. Beim Forwarding-Modus Basic ergänzt Username affix einen konfigurierten Präfix oder Suffix, wenn nur ein Benutzername eingegeben wird. Vollständig qualifizierte Anmeldenamen separat prüfen, damit Domain oder Suffix nicht doppelt beim Backend ankommen. HTTP Basic folgt RFC 7617; die Kodierung verschlüsselt die Zugangsdaten nicht.

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. Die folgende Checkliste und die Bindung über Protected servers beziehen sich auf SFOS 22; für SFOS 23 sind zusätzlich die anschliessend beschriebenen expliziten Kontrollen pro Pfad unter Traffic routing erforderlich.

Beim Speichern einer WAF-Regel startet die Firewall alle Webserver-Protection-Regeln neu. Bestehende Verbindungen über diese Regeln gehen verloren und müssen erneut aufgebaut werden. Die Änderung deshalb mit den Verantwortlichen aller betroffenen Anwendungen in einem geeigneten Änderungsfenster planen, die bisherigen Einstellungen sichern und danach Erreichbarkeit, Login mit OTP und Backend-Zugriff prüfen. Diese Wirkung und der Rückweg wurden hier nicht auf einer Appliance getestet.

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.

SFOS 23: MFA für jeden Portalpfad zuordnen

Die äussere Regelaktion Protect with web server protection allein genügt nicht. Für jeden zu schützenden Portalpfad auf jedem veröffentlichten Hostnamen und in jeder zugehörigen WAF-Regel muss die Pfadkonfiguration stimmen; die bisherigen MFA-Schritte und Session-Limits bleiben unverändert.

1. Unter Traffic routing jeden geschützten Portalpfad bearbeiten oder ergänzen und Action > Protect setzen. Die vorgesehenen Backend-Objekte aus Web server > Web servers zuweisen.
2. Im Feld Authentication die vorgesehene Authentication Policy auswählen. Diese muss den Client-Modus Form verwenden und die beabsichtigte Benutzergruppe enthalten; die Gruppenzuordnung muss zur MFA-Konfiguration passen. Allowed client networks sowie weitere Quellen- und Zugriffsbeschränkungen einschliesslich bewusst gewählter Netz- und Ländersperren pro Pfad prüfen.
3. Wenn nur bestimmte Portalpfade erlaubt sind, / mit Block als Auffangroute behalten. Ist Protect für / zur Veröffentlichung der gesamten Anwendung beabsichtigt, dort dieselbe vorgesehene Authentifizierung und passende Zugriffsbeschränkungen zuweisen. Alternative Pfade und Hostnamen ausdrücklich auf gleichwertigen Schutz oder beabsichtigte Sperre prüfen.
4. Die bestehenden Tests für erfolgreichen Login mit Passwort und OTP, Backend-Funktion, Logout, Session-Ablauf und erneuten Login beibehalten. Falsches OTP und Benutzer ausserhalb der erlaubten Gruppe müssen scheitern; alternative Pfade oder Hostnamen dürfen keinen ungeschützten Zugang eröffnen. Client-Ergebnis mit WAF-, Authentifizierungs- und Backend-Logs korrelieren.

Dokumentationsgrenze bei Passthrough: Die Regelübersicht beschreibt Authentifizierung als Funktion von Protect; gleichzeitig bietet die Einstellungstabelle für die Routing-Aktion Passthrough ein Feld Authentication. Diese Spannung belegt weder eine MFA-Durchsetzung noch eine MFA-Umgehung bei Passthrough. Erforderliche WAF-MFA deshalb auf explizit konfigurierte Protect-Pfade stützen, nicht auf unbestätigtes Passthrough-Verhalten. Notwendige WebSocket-Tunnel mit den Verantwortlichen für WAF-Routing und Authentifizierung separat abstimmen.

Basic with passthrough bezeichnet einen Authentifizierungsmodus zur Weitergabe von Zugangsdaten; Passthrough unter Traffic routing ist dagegen eine Routing-Aktion zur Traffic-Behandlung. Der ähnliche Name begründet keine MFA-Eigenschaft. Für die Grundveröffentlichung müssen die Verantwortlichen die SFOS-23-Pfadkonfiguration gemeinsam mit der MFA-Zuordnung prüfen: Das unveränderte Sophos-Angriffsschutz-Tutorial ist keine vollständige SFOS-23-Routing-Anleitung, und WAF-Regeln unterstützen nur IPv4.

Eigenes Authentication Template sicher anpassen

Ein eigenes Formular wird unter Web server > Authentication templates > Add angelegt. Im HTML müssen das Formular mit action="<?login_path?>" und method="POST" sowie die Felder httpd_username und httpd_password erhalten bleiben. Für MFA muss zusätzlich otp_field vorhanden sein. Entfernt oder benennt man diese Elemente um, kann die Anmeldung trotz optisch korrekter Seite nicht funktionieren.

Für Bilder, Styles und Skripte stellt SFOS unter anderem die Platzhalter <?assets_path?>, <?admin_contact?>, <?company_logo?> und <?company_text?> bereit. Hochladbare Assets sind auf .jpg, .jpeg, .png, .ico, .css und .js begrenzt. Das Template sollte zuerst mit einem Testbenutzer geprüft werden; produktive Zugangsdaten, externe Tracker und nicht überprüftes JavaScript gehören nicht in die Anmeldeseite.

Nach Add einen Namen vergeben, die HTML-Datei und ihre Assets auswählen, Upload und danach Save ausführen. Die gespeicherte Vorlage anschliessend in der Form-Authentication-Policy auswählen. Ein minimales Formular mit den erforderlichen technischen Namen sieht so aus; es ist ein dokumentarisches Beispiel, kein auf einer Appliance getestetes Template:

<form action="<?login_path?>" method="POST">
  <label>Username <input name="httpd_username" type="text"></label>
  <label>Password <input name="httpd_password" type="password"></label>
  <?otp_field?><label>OTP <input name="otp_field" type="password"></label><?otp_field?>
  <button type="submit">Login</button>
</form>

Widersprüche in der Template-Dokumentation: Ein Passwort-Kurzbeispiel verwendet type="text", während die Felddefinition und das vollständige Beispiel type="password" zeigen. Das Passwortfeld deshalb maskiert belassen. Zudem nennt eine Notiz nur <?login_path?> als ersetzte Variable, die optionale Tabelle beschreibt aber auch Ersetzungen für <?assets_path?> und <?admin_contact?>. Das ist keine verifizierte Aussage über jede Firmware. Vor dem Rollout gerendertes Formular, Asset-Pfade, OTP-Eingabe und Login mit einer Pilotgruppe prüfen; keine funktionierende Vorlage ungeprüft ersetzen.

<?assets_path?> bezeichnet den Pfad der hochgeladenen Begleitdateien, beispielsweise in <link rel="stylesheet" href="<?assets_path?>/stylesheet.css">. Bilder und CSS lassen sich so ausserhalb des Formulars halten. <?admin_contact?> verweist laut Feldbeschreibung auf Administration > Notification settings > Email settings > Send notifications to email address; prüfen, ob diese Adresse öffentlich angezeigt werden darf. <?company_logo?> durch den eigenen Logo-Pfad und <?company_text?> durch den gewünschten sichtbaren Text ersetzen, nicht ungeprüft automatische Ersetzung erwarten. Bei sichtbaren Platzhaltern oder Loginfehlern zur gesicherten funktionierenden Vorlage zurückkehren und die Ursache mit dem Support klären, statt MFA zu deaktivieren.

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.

Maximum sessions gilt gemeinsam für alle WAF-Regeln mit Form-Authentifizierung. Beim Erreichen des Limits schliesst die Firewall alte oder abgelaufene Sessions, um neue zuzulassen. Wiederholte Anmeldungen können deshalb auch durch die globale Kapazität entstehen, nicht nur durch den Timeout einer einzelnen Policy.

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.

Globale WAF-Einstellungen sicher einordnen

Web server > General settings betrifft alle geschützten Webserver, nicht nur das MFA-Portal. Vor Änderungen Werte sichern, betroffene Anwendungen und Client-Kompatibilität erfassen sowie Wartungsfenster und Rückweg planen. Die folgenden Hinweise sind dokumentarisch geprüft; Auswirkungen und Rücknahme wurden nicht auf einer Appliance getestet.

Slow HTTP protection begrenzt das Warten auf unvollständige Request-Header. Bei einem Slow-HTTP-DoS bleiben Verbindungen durch langsam eintreffende Teilstücke belegt, bis keine Kapazität mehr frei ist:

• Soft limit: minimale Zeit zum Empfang eines Request-Headers.
• Hard limit: maximale Zeit zum Empfang des Headers.
• Extension rate: Datenmenge in Bytes; beim Überschreiten wird der Soft-Timeout jeweils um eine Sekunde verlängert.
• Skipped networks/hosts: gezielte Ausnahmen. Nur IP-Hosttypen IP und Network verwenden, keine IP ranges oder IP lists. Breite Ausnahmen nehmen auch unerwünschte Clients vom Schutz aus.

Nach Anpassungen normale und langsame legitime Clients sowie die übrigen WAF-Anwendungen prüfen. Keine beliebigen Timeout-Werte als allgemeine Lösung für Loginprobleme übernehmen.

TLS version settings bestimmt die erlaubten Client-Verbindungen. Die dokumentierten Profile unterscheiden sich auch in den Chiffren:

• TLS v1 or later: ohne SSLv3; Legacy-Profil, keine Empfehlung für neue Portale.
• TLS v1.1 or later: ohne SSLv3 und TLSv1; ebenfalls kein moderner Rollout-Standard.
• TLS v1.2 (wide compatibility): nur TLSv1.2, einschliesslich nicht empfohlener Legacy-Chiffren.
• TLS v1.2 (strict): nur TLSv1.2 mit empfohlenen Chiffren.
• TLS v1.3: nur TLSv1.3-Chiffren.

Client-Unterstützung vor der Auswahl prüfen; etwa IE 8 oder älter und Windows XP können mit TLS 1.2 nicht verbinden. Legacy-Kompatibilität nicht durch pauschales Absenken der Sicherheit herstellen. Ein strenges Profil zuerst mit den tatsächlich benötigten Clients und allen veröffentlichten Anwendungen prüfen.

Bei Custom TLS verwenden Protocols, Cipher suite und TLS v1.3 cipher suite only OpenSSL-Syntax. TLSv1.3-Chiffren gehören ausschliesslich in das separate TLSv1.3-Feld, nicht in Cipher suite. Ungültige Protokolle oder Chiffren können den Start des Apache-Dienstes verhindern und WAF beeinträchtigen. Ohne validierte Konfiguration kein produktives Custom-TLS-Experiment; bei Ausfall gesicherte Werte wiederherstellen und Dienststatus sowie HTTPS-Zugriff auf alle betroffenen Portale kontrollieren.

SFOS 23 – Worker customization: Die Firewall berechnet die WAF-Kapazität anhand von CPU und RAM. Die berechneten Werte sind für die Hardware optimiert; meist sind keine Änderungen nötig. Höhere Werte können WAF-Leistung und Systemressourcen verschlechtern. Use custom worker profile nur nach sorgfältiger Kapazitäts- und Auswirkungsprüfung aktivieren, nicht als pauschalen Loginfix:

• Start servers: Worker-Prozesse beim Webserverstart.
• Server limit: maximale Worker-Prozesszahl.
• Minimum spare threads: mindestens bereitgehaltene freie Threads.
• Maximum spare threads: freie Threads, oberhalb derer Überschüsse entfernt werden.
• Threads per child: maximale Threadzahl pro Worker-Prozess.
• Asynchronous request worker factor: Steuerung der Prozessskalierung für asynchrone Verbindungen und Requests.

Keine universellen Zahlen aus fremden Systemen übernehmen. Ausgangswerte sichern, repräsentative Last und Ressourcen beobachten und nach jeder begründeten Änderung Login, OTP, Sessions und Backend-Zugriff erneut prüfen. Bei Verschlechterung die gesicherte Ausgangskonfiguration wiederherstellen; eine erfolgreiche Rücknahme ist hier nicht behauptet.

WAF-Authentifizierung über die XML API automatisieren

Für die Automatisierung gehören drei getrennte Objekte zusammen: FormTemplate stellt das Anmeldeformular bereit, ReverseAuthentication definiert Client- und Backend-Authentifizierung, und FirewallRule bindet die Policy an die Veröffentlichung beziehungsweise ihre Pfade. Zuerst die funktionierende Vorlage, Policy und alle verwendenden Regeln sichern. Zugang, explizite Schreiboperationen, Antwortauswertung und sichere Wiederholungen erklärt Sophos Firewall XML API Zugriff absichern. Die folgenden Angaben beschreiben die SFOS-22/23-Referenzen, keinen auf einer Appliance getesteten Schreibablauf. Vor Änderungen die API help des installierten Builds prüfen; bei ungeklärten Feldern oder Upload-Bindungen nicht schreiben.

Client-Modus, Backend und Sessions auseinanderhalten

Im Objekt ReverseAuthentication sind Name, VirtualWebserverMode und RealWebserverMode als Pflichtfelder beschrieben. Name erlaubt höchstens 60 Zeichen. VirtualWebserverMode wählt Basic oder Form für den Client; der dokumentierte Default Basic ist keine MFA-Empfehlung. Für WAF-MFA bleibt Form erforderlich. BasicPrompt ist der optionale Basic-Hinweistext mit höchstens 255 Zeichen. FormTemplate referenziert im Form-Modus die gespeicherte Vorlage. UserGroupList enthält wiederholbare UserGroup-Einträge für vorhandene Benutzer oder Gruppen; diese Auswahl muss weiterhin zur MFA-Gruppe passen. Das Wort Mode in Anwendbarkeitsnotizen ist kein zusätzlich belegtes XML-Tag.

RealWebserverMode wählt unabhängig davon Basic oder None für das Backend; auch hier nennt die Tabelle Basic als Default. Bei Basic gehört UsernameAffix zur Backend-Anmeldung. Prefix und Suffix sind optionale Texte mit je höchstens 255 Zeichen und nur für die passende Affix-Auswahl vorgesehen. Bei None ist stattdessen RemoveBasicHeader mit Enable oder Disable relevant. Der dort notierte Default ON ist nicht selbst ein zulässiger Eingabewert; explizite Werte nur nach Build-Prüfung verwenden. Die vorhandenen HTTPS-, Backend- und Benutzernamenprüfungen bleiben erforderlich.

Widersprüche nicht in einen Payload übernehmen: Für UsernameAffix zeigt das XML-Muster None/Prefix/Suffix/PrefixAndSuffix, die Tabelle nennt dagegen Basic, Prefix, Suffix, PrefixandSuffix und zugleich den Default None. Weder Schreibweise noch zusätzliche Auswahlwerte erraten. Ebenso zeigt das Muster SessionTimeout und SessionLifetime als Schalter, ihre jeweiligen Limit-Felder als Integer und die Scope-Felder als Hours/Minutes/Days. Die Tabelle bestätigt für SessionTimeoutLimit den Bereich 1 bis 9999, vertauscht aber bei SessionLifetime und SessionLifetimeLimit Integer und Schalter; Angaben wie ON und 8 Hours passen nicht konsistent zu den Datentypen. Diese Unstimmigkeiten belegen keine verlässlichen Defaults oder ausführbare Session-Konfiguration. Die gewünschte Inaktivitätsgrenze und maximale Lebensdauer im installierten Build bestätigen, den gespeicherten Zustand nachlesen und die vorhandenen Session-, Logout- und erneuten Login-Tests durchführen. Die SFOS-23-Ergänzung RedirectToRequestedURL und ihr gesonderter Rückleitungstest bleiben davon unabhängig.

Vorlage und Begleitdateien zuordnen

Die FormTemplate-Referenz zeigt FormTemplate als Objekt mit Name, Description, Template und Assets, darunter wiederholbare Asset-Einträge. Name und Template sind Pflichtfelder: Der Name erlaubt höchstens 60 Zeichen, Template ist ein String mit höchstens 255 Zeichen zur Auswahl und zum Upload der HTML-Vorlage. Description ist optional. Die optionalen Asset-Strings erlauben je höchstens 255 Zeichen und mehrere Werte für verwendete Bilder, Stylesheets oder JavaScript-Dateien.

Das Muster lässt Template und Asset leer. Es legt damit weder Multipart-Teilnamen noch Dateipfade, eine Base64-Kodierung oder direkt übertragbaren HTML-Inhalt fest. Keine Zertifikats-Upload-Bindung auf FormTemplates übertragen. Ohne bestätigten Upload-Vertrag die bestehende GUI-Abfolge Upload > Save verwenden und danach die gespeicherte Vorlage über FormTemplate in der Form-Policy auswählen. Die erforderlichen Formularfelder und erlaubten Asset-Dateitypen aus dem vorigen Abschnitt gelten weiterhin. Gerendertes Formular, Assets und OTP-Login mit einem Testbenutzer prüfen; eine erfolgreiche Objektspeicherung allein beweist kein funktionierendes Formular.

Authentication Policy an die Regel binden

Bei FirewallRule betrifft diese Zuordnung den WAF-Zweig HTTPBasedPolicy, nicht NetworkPolicy oder UserPolicy. Die Parametertabelle beschreibt Authentication als optionalen skalaren String für eine Authentication Policy. Im Pfadmuster steht die entsprechende Zuordnung als AccessPaths > AccessPath > auth_profile. Der Musterkommentar trennt die regelweite Variante mit Authentication und Quellenkontrollen von AccessPaths; er belegt keine beliebige Kombination oder automatische Vererbung. Regelweite und pfadbezogene Schreibweisen nicht ungeprüft vermischen und nicht annehmen, dass eine auf der Firewall vorhandene Policy schon jeden Pfad schützt.

In SFOS 23 beschreibt die Tabelle path als Pflicht-Array von Strings mit mehreren Werten, höchstens 63 Zeichen, ohne Komma und mit UTF-8-Unterstützung; SFOS 22 nennt hier einen Skalar. Das Muster verwendet sowohl path als auch Path. backend ist in der SFOS-23-Tabelle optional; das ist keine Zusage, dass ein geschütztes Portal ohne Backend funktioniert. Das neue pfadbezogene action zeigt wörtlich 0/1/2/3, ohne belastbare Zuordnung zu den GUI-Aktionen. Keine Zahlenzuordnung raten und diese Werte nicht mit dem Netzwerkfeld Action gleichsetzen. Routing, Backend und Schutzprofil erklärt WAF: Webserver sicher veröffentlichen.

Für die Authentifizierungsänderung zuerst die tatsächlichen Hostnamen und Pfade der Zielregel lesen, die gewünschte Form-Policy pro geschütztem Pfad zuordnen und anschliessend den gespeicherten Zustand mit dem Soll vergleichen. Alle alternativen Pfade, Hostnamen und Regeln sowie falsches OTP und Benutzer ausserhalb der Gruppe prüfen. Dabei gelten die bereits beschriebenen Protect-Kontrollen, die Passthrough-Dokumentationsgrenze und das Änderungsfenster für WAF-Regeln unverändert.

Objektantworten vor einem Retry auswerten

Die folgenden Zuordnungen sind XML-Statuswerte und wörtliche, nicht aufgelöste Message.*-Symbole der Referenz, keine HTTP-Statuscodes oder nachgewiesenen Laufzeit-Meldungstexte. Für die FirewallRule-Bindung sind besonders die Unterschiede zwischen Add und Edit wichtig:

• Add firewall rule: 200 / Message.FWRuleAddSuccess, 500 / Message.FWRuleAddFail, 502 / Message.FWRuleRecordExists.
• Edit firewall rule: 200 / Message.FWRuleEditSuccess, 202 / Message.FirewallRuleUpdateWithRename, 500 / Message.FWRuleEditFail, 502 / Message.FWRuleUpdateRecordExist. Bei 202 auch den tatsächlichen Namen und alle Zuordnungen nachlesen.
• Unterschiedliche Zuordnungen: Add 541 / Message.VHIPRangeConflict, Edit 541 / Message.FWRuleFailMaxUser; Add 543 / Message.CannotSetupRedirectionFromHTTP, Edit 543 / Message.CannotUseDefaultPort; Add 544 / Message.CannotUseDefaultPort, Edit 544 / Message.CannotSetupRedirectionFromHTTP. Derselbe Code allein reicht nicht zur Interpretation.
• Weitere unterscheidende Zeilen: Edit 552 / Message.CannotImportDiffPolicytypeWithSameName; Add 554 / Message.CannotUseFQDNWildCardAsProtectedServer, Edit 554 / Message.CannotUpdateFQDNWildCardAsProtectedServer.
• Delete firewall rule: 200 / Message.FWDelSuccess, 500 / Message.FWRuleDeleteFail, 596 / Message.CMLOCALOperationrestriction. 596 steht auch bei Add und Edit; den tatsächlichen Berechtigungs- und Verwaltungszustand klären, nicht durch blindes Wiederholen oder Löschen umgehen. Eine Regel zu löschen ist kein Reparaturweg für eine fehlende Authentifizierungsbindung.

Auch die beiden vorgelagerten Objekte haben eigene Antworten:

• Add Authentication Policy: 200 / Message.ReverseAuthAddSuccess, 500 / Message.ReverseAuthAddFail, 502 / Message.ReverseAuthRecodExist.
• Edit Authentication Policy: 200 / Message.ReverseAuthUpdateSuccess, 500 / Message.ReverseAuthUpdateFail.
• Add FormTemplate: 200 / Message.FormTemplateAddSuccess, 500 / Message.FormTemplateAddFail.
• Edit FormTemplate: 200 / Message.FormTemplateUpdateSuccess, 500 / Message.FormTemplateUpdateFail, 502 / Message.FormTemplateRecodExist. Die Schreibweise Recod in diesen Symbolen bleibt wörtlich erhalten; daraus keinen zusätzlichen Status für eine andere Operation ableiten.

Operation, Code, tatsächliche Antwort und den gespeicherten Zustand von Vorlage, Policy und Zielregel gemeinsam festhalten. Bei Fehlern, Warnungen oder unklarer Antwort zuerst prüfen, was wirklich übernommen wurde; nicht durch einen zweiten Namen, eine breitere Gruppe oder einen ungeschützten Pfad umgehen. Bei ungeklärter Syntax oder Upload-Zuordnung stoppen und mit bereinigten Daten Support hinzuziehen. Erst nach bestätigter Speicherung folgen die vorhandenen positiven und negativen MFA-, Backend-, Session-, Logout-, Rückleitungs- und Alternativpfadtests. Dokumentarische Prüfung ersetzt keine Abnahme auf der eigenen Firewall.

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.

Validierung und Betrieb

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 Rückleitung unter SFOS 23 zusätzlich ohne gültige WAF-Session eine tatsächlich geschützte URL mit einem Pfad ungleich / öffnen. Nach erfolgreichem Login mit Passwort und OTP bei RedirectToRequestedURL auf Enable prüfen, ob wieder genau die ursprünglich angeforderte URL erreicht wird und der Backend-Zugriff den vorgesehenen Berechtigungen entspricht. Eine erfolgreiche Weiterleitung allein ist kein Nachweis für MFA oder Zugriffsberechtigung; alle oben genannten Negativ-, Backend-, Session-, Logout-, erneuten Login- und Alternativpfadtests bleiben erforderlich.

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 greift, 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.

Troubleshooting

Weitere häufige Fehler

• Authentication Policy verwendet nicht Form: MFA-Verhalten passt nicht zur erwarteten WAF-Konfiguration.
• Sophos Authenticator als neue Standard-App eingeplant: Die App ist EOL und sollte nicht mehr als neue Rollout-Basis dienen.
• 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.

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.

Backend fragt nach erfolgreicher MFA erneut nach Login

Auf SFOS 22.0 GA Respin Build 411 kann NC-177509 auftreten: Die formbasierte WAF-MFA ist erfolgreich, danach verlangt das Backend jedoch eine weitere, nicht umgehbare Anmeldung. Dabei wird der OTP-Code nicht vom Passwort getrennt, bevor die Firewall die Zugangsdaten an das Backend weitergibt. Behoben ist dieses Fehlerbild ab SFOS 22.0 MR1 Build 490.

Für die Korrektur des nicht entfernten OTP-Codes existiert zusätzlich die Referenz NC-177201. Die IDs sind nicht austauschbar: NC-177509 ordnet betroffene und behobene Builds zu, NC-177201 bezeichnet den konkreten Fixtext. In einem Supportfall deshalb Fehlerbild, Build und beide Referenzen angeben.

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-Zugriffslog decken denselben Testzeitpunkt ab.
• Die eingesetzte SFOS-Version ist geprüft.

Auf einem betroffenen GA-System sollte man reverseproxy.log, Log Viewer und Backend-Log sichern und ein Update auf MR1 Build 490 oder neuer einplanen. Ist ein zeitnahes Update nicht möglich, keine unbestätigten Änderungen am Authentifizierungsfluss vornehmen, sondern mit den gesicherten Daten ein Sophos Supportticket eröffnen. Nicht pauschal MFA abschwächen oder Authentication Forwarding umstellen: None passt nur, wenn das Backend keine weitergegebenen Anmeldedaten benötigt. Bei produktiven Portalen gehören Testbenutzer, Rollback und Benutzerkommunikation zum Vorgehen.

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