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.

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.

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.
• 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:

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. Konfiguration speichern.

Wenn Benutzer ihren Token selbst einrichten sollen, müssen sie Zugriff auf ein Portal haben, auf dem der QR-Code angezeigt wird. In vielen Umgebungen ist dafür das User Portal oder VPN Portal 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:

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

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.

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

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.

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.

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.

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.

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:

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:

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

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.

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