MFA für Sophos Firewall WebAdmin, VPN Portal und Remote Access aktivieren

Für die lokale OTP-Funktion öffnet man Authentication > Multi-factor authentication, wählt zuerst Specific users and groups, aktiviert die benötigten Dienste und testet alles mit einer Pilotgruppe. All users sollte erst nach erfolgreichen Tests verwendet werden.

MFA schützt WebAdmin, VPN Portal und Remote Access vor der alleinigen Verwendung gestohlener Passwörter. Sie ersetzt aber weder enge Zugriffsregeln noch einen getesteten Notfallzugang. Dieser Artikel führt deshalb von der sicheren Aktivierung bis zu App-Auswahl, Recovery und Troubleshooting.

Sophos OTP sicher aktivieren

Vor dem Aktivieren

Vor der ersten Änderung sollten diese Punkte geklärt sein:

• Die Firewall verwendet unter Administration > Time eine korrekte Uhrzeit, idealerweise über NTP.
• Benutzer und Gruppen sind lokal oder über AD, LDAP beziehungsweise einen anderen Authentifizierungsserver verfügbar.
• Eine Pilotgruppe und ein zweiter getesteter Administrator existieren.
• Für den default admin sind Konsole und Recovery-Weg bekannt.
• Ein aktuelles Backup und ein dokumentierter Token-Reset-Prozess sind vorhanden.

Bei klassischem Active Directory hilft Active Directory auf Sophos Firewall hinzufügen bei der Benutzerquelle.

Unter Administration > Device access legt man fest, aus welchen Zonen WebAdmin, User Portal, VPN Portal und andere lokale Dienste erreichbar sind. Local service ACL exception rules grenzen den Zugriff weiter auf Managementnetze, VPN-Netze oder bekannte Quelladressen ein. Die genaue Härtung erklärt Sophos Firewall Zugriff absichern: Device Access richtig konfigurieren.

SSH gehört nicht zu den Diensten, die durch Sophos OTP geschützt werden. Es sollte über Device Access eingeschränkt und möglichst mit Public Key verwendet werden; der Ablauf steht unter Sophos Firewall per SSH verbinden.

⚠️ MFA reduziert das Risiko kompromittierter Passwörter, verkleinert aber nicht die Angriffsfläche eines öffentlich erreichbaren Dienstes. WebAdmin, SSH und Portale sollten nie breiter freigegeben sein als nötig.

Vor Negativtests prüft man zusätzlich Administration > Admin and user settings > Login security > Block login. Mehrere absichtliche Fehlversuche können die Quell-IP für WebAdmin, CLI, VPN Portal und User Portal sperren und damit auch einen Fallback-Admin aus demselben Netz blockieren. Eine zweite Quelle oder der Konsolenzugang sollte deshalb verfügbar sein.

MFA für eine Pilotgruppe konfigurieren

1. Am WebAdmin anmelden und Authentication > Multi-factor authentication öffnen.
2. Unter One-time password (OTP) zuerst Specific users and groups auswählen.
3. Add users and groups öffnen, die Pilotgruppe auswählen und übernehmen.
4. Generate OTP token with next sign-in aktivieren, wenn eine Authenticator-App verwendet wird.
5. Unter Require MFA for nur die tatsächlich benötigten Anmeldeflächen auswählen.
6. Unter OTP hash algorithm einen von der vorgesehenen App unterstützten Algorithmus festlegen.
7. Optionale OTP timestep settings nur ändern, wenn die App denselben Zeitschritt unterstützt; der Standard beträgt 30 Sekunden.
8. Mit Apply speichern.

Die Benutzeroptionen bedeuten:

• No OTP: MFA ist deaktiviert.
• All users: MFA gilt für alle Benutzer; erst nach dem Pilot verwenden.
• Specific users and groups: MFA gilt nur für die ausgewählten Konten oder Gruppen.

Ist Generate OTP token with next sign-in aktiviert, registrieren Benutzer eine Software-App beim nächsten Login. Das User Portal wird dabei automatisch als MFA-Dienst ausgewählt. Ist die Option deaktiviert, werden Hardware- oder manuell verwaltete Token unter Issued tokens zugewiesen.

Dienste bewusst auswählen

Unter SFOS 22 stehen diese Dienste unter Require MFA for zur Verfügung:

• User portal
• Web admin console
• VPN portal
• SSL VPN remote access
• IPsec remote access
• Web application firewall

MFA für das User Portal gilt zusätzlich für Captive Portal und Client Authentication Agents. Remote-Access-Benutzer müssen ihren Token zuerst über VPN Portal oder User Portal registrieren.

Für WAF ist die Auswahl allein nicht ausreichend. Ab SFOS 22 benötigt man Webserver Protection, eine Form-basierte Authentication Policy und deren Zuweisung in der WAF-Regel. Der vollständige Ablauf steht unter Sophos Firewall WAF mit MFA absichern.

Passendes MFA-Modell wählen

Lokales Sophos OTP

Sophos OTP verwaltet die Token direkt auf der Firewall und benötigt keine zusätzliche RADIUS- oder Identity-Provider-Infrastruktur. Es eignet sich besonders für normale lokale Benutzer, kleine Umgebungen und eine schnelle Härtung von WebAdmin oder Remote Access.

Der Preis für die einfache Einführung ist ein eigener Token ausserhalb bestehender Microsoft-365-Prozesse. Benutzer und Helpdesk müssen App-Aufnahme, Passwort-plus-OTP-Eingabe sowie Gerätewechsel kennen.

RADIUS oder Entra ID SSO

Eine bestehende MFA-Plattform kann über RADIUS oder SSO besser zum zentralen Identity-Betrieb passen. Sie benötigt aber dienstspezifische Tests:

• Das VPN Portal unterstützt kein RADIUS mit Challenge-MFA.
• Sophos Connect unterstützt keine OTP-Challenge. Der Client sendet Passwort und OTP zusammen im Format passwordotp, unterstützt aber Call- und Push-MFA.
• User Portal und WebAdmin unterstützen zusätzlich Challenge-basierte MFA.
• Bei Entra ID SSO erfolgt MFA am Identity Provider; lokale Sophos-OTP-MFA kann nicht zusätzlich auf denselben SSO-Login gelegt werden.
• Entra SSO mit Sophos Connect benötigt unter Windows mindestens Clientversion 2.4. WebAdmin-SSO steht auf dem HA-Auxiliary-Gerät nicht zur Verfügung.

Für Remote Access gibt es die separate Anleitung Microsoft Entra ID SSO für Sophos Connect und VPN Portal einrichten. Soll Entra dagegen die WebAdmin-Anmeldung und Administratorrollen steuern, führt Entra ID SSO für Sophos Firewall WebAdmin durch Rollenmapping, Least Privilege, Pilotlogin und lokalen Notfallzugang.

Bei der Wahl des Remote-Access-Modells hilft Sophos Connect oder SSL VPN: Welche Lösung passt?; vor dem Rollout sollte man zudem die Sophos Connect Clientversion prüfen.

Unabhängig vom Modell beginnt man mit einer Pilotgruppe. Erst wenn WebAdmin, Portale, echte VPN-Clients, Gruppen, Timeouts, Logging und Fallback funktionieren, werden weitere Benutzer aufgenommen.

Token und Authenticator-App einrichten

Token registrieren und verwalten

Bei aktiviertem Generate OTP token with next sign-in meldet sich der Benutzer am VPN Portal oder User Portal an und scannt den QR-Code. Administratoren können den Token auch am WebAdmin registrieren, wenn dort MFA erzwungen wird. Der QR-Code erscheint nur für Benutzer und Gruppen, für die MFA konfiguriert ist.

Unter Authentication > Multi-factor authentication > Issued tokens lassen sich ausgestellte Token prüfen, vorübergehend deaktivieren, löschen oder manuell hinzufügen. Dort kann man ausserdem zusätzliche Einmalcodes erzeugen und den Zeitoffset eines Tokens prüfen beziehungsweise synchronisieren.

Bei einem verlorenen Smartphone oder App-Wechsel wird der alte Token nach einer Identitätsprüfung gelöscht. Danach meldet sich der Benutzer einmal nur mit dem Passwort am Portal an und registriert den neu angezeigten QR-Code. Ein alter Token sollte nicht parallel unkontrolliert weiterbestehen.

App und Hash-Algorithmus müssen zusammenpassen

SFOS 22 unterstützt SHA1, SHA256 und SHA512. Sophos empfiehlt SHA256 oder SHA512, aber der gewählte Algorithmus muss von der App unterstützt werden:

• Sophos Intercept X for Mobile und Google Authenticator unterstützen SHA256 und SHA512.
• Microsoft Authenticator unterstützt diese beiden Algorithmen in diesem Sophos-Workflow nicht. Ein QR-Scan kann trotzdem gelingen, der Login schlägt danach aber fehl.
• Duo Mobile und Okta Verify gehören zu den von Sophos aufgeführten Apps; ihre QR- und Algorithmus-Eignung muss zum verwendeten Betriebssystem und zur Konfiguration passen.
• Andere TOTP-Apps werden erst nach einem realen Pilot-Test freigegeben.

Unter iOS funktioniert der Sophos-QR-Scan mit Google Authenticator, Duo Mobile und Microsoft Authenticator nicht. Das Konto wird dort mit dem angezeigten Base32-Schlüssel manuell angelegt. Bei Okta Verify ist die manuelle Base32-Aufnahme unter iOS und Android nötig. Sie behebt bei Microsoft Authenticator jedoch nicht die fehlende SHA256-/SHA512-Unterstützung.

Die frühere Sophos Authenticator App ist seit dem 31. Juli 2022 End of Life und sollte nicht mehr für neue Rollouts eingeplant werden.

Für eine Migration von SHA1 auf einen stärkeren Algorithmus:

1. Pilot-App mit SHA256 oder SHA512 testen.
2. Den neuen Algorithmus unter Authentication > Multi-factor authentication auswählen.
3. Alte SHA1-Token unter Issued tokens löschen.
4. Benutzer nur mit Passwort anmelden und QR-Code beziehungsweise Base32-Schlüssel neu registrieren lassen.
5. Login mit richtigem und falschem Passcode kontrolliert testen.

Token mit unterschiedlichen Algorithmen können während der Migration parallel existieren. Nicht gelöschte Token verwenden jedoch weiterhin ihren alten Algorithmus.

Passwort und OTP richtig eingeben

Für native Sophos-OTP-Anmeldungen lautet das offizielle Format <password><passcode>, ohne Leerzeichen oder Trennzeichen.

Beispiel:

Passwort: MeinSicheresPasswort
OTP-Code: 123456
Eingabe:  MeinSicheresPasswort123456

Sophos Connect kann über otp: true ein separates drittes Eingabefeld anzeigen. Der Client hängt den Code intern an das Passwort an. Diese Darstellung ändert das Format, das an den Authentifizierungsserver gesendet wird, nicht.

Default-Admin absichern und wiederherstellen

MFA für den default admin aktivieren

Der lokale default Benutzer admin wird nicht über die normale Benutzerliste aktiviert. Man öffnet Administration > Device access, schaltet MFA for default admin ein und richtet dort den Hardware- oder Software-Token ein.

Vorher müssen zweiter Administrator, Managementzugriff und Konsolenzugang funktionieren. Zusätzliche Einmalcodes werden sicher, beispielsweise in einem Passwortmanager, hinterlegt. Der default admin bleibt ein Notfallkonto und wird nicht für tägliche Administration verwendet.

Andere Administratoren können den Token des default admin weder aktivieren oder deaktivieren noch bearbeiten oder löschen. Der gewählte globale OTP hash algorithm gilt auch für diesen Token.

Recovery über die Device Console

Fehlt der Token nur vorübergehend, kann man an der Device Console eine einmalige Anmeldung ohne MFA erlauben:

1. 2 für System Configuration eingeben.
2. 6 für Skip multi-factor authentication for next Admin user login eingeben.
3. Am WebAdmin anmelden und den Token prüfen.

Bei verlorenem Gerät oder dauerhaft unbrauchbarem Token wird MFA zurückgesetzt:

1. 2 für System Configuration eingeben.
2. 7 für Reset multi-factor authentication for Admin user eingeben.
3. Mit y bestätigen.
4. Am WebAdmin einmal nur mit dem Admin-Passwort anmelden.
5. Den Anweisungen zur neuen MFA-Registrierung folgen und anschliessend wieder mit MFA testen.

Diese beiden Optionen ändern nur den MFA-Zustand. Ist auch das Passwort des Default-Admins unbekannt, erklärt der separate Passwort-Recovery-Artikel den dokumentierten seriellen Weg für physische Appliances und die Grenzen bei einem kombinierten Passwort- und MFA-Verlust.

Testen, Logs prüfen und ausrollen

Jeden Dienst separat testen

Ein erfolgreicher WebAdmin-Login beweist nicht, dass Portale und VPN-Clients gleich funktionieren. Vor dem breiten Rollout prüft man:

• WebAdmin: Pilot-Admin mit richtigem und kontrolliert falschem OTP anmelden.
• Default admin: separaten Device-Access-Pfad und dokumentierten Recovery-Weg prüfen.
• User Portal und VPN Portal: QR- beziehungsweise Base32-Aufnahme sowie Login mit <password><passcode> testen.
• SSL VPN und IPsec Remote Access: echte Clients und genau die produktiv verwendete Benutzergruppe testen.
• Sophos Connect: gegebenenfalls drittes OTP-Feld, aktuelle Clientprofile sowie Call-/Push-Verhalten prüfen.
• RADIUS oder Entra SSO: Timeouts, IdP-Logs und das tatsächlich unterstützte Challenge-Verhalten prüfen.
• Device Access: Zugriff aus erlaubtem und nicht erlaubtem Quellnetz testen.

Fehlversuche werden nur in kontrollierter Zahl ausgeführt, nachdem Block login geprüft wurde. Das erwartete Ergebnis ist nicht nur ein erfolgreicher Login: Ein falscher Code muss abgelehnt, der Versuch geloggt und der Dienst ausschliesslich aus den vorgesehenen Netzen erreichbar sein.

Authentifizierungslogs richtig lesen

Im Log viewer prüft man erfolgreiche und fehlgeschlagene Anmeldungen mit Dienst, Benutzer, Quelle, Uhrzeit und dokumentiertem Grund. Je nach Ereignis liefert SFOS nur einen generischen Hinweis wie falsche Zugangsdaten. Ohne zusätzlichen Nachweis sollte man daraus nicht ableiten, ob Passwort, OTP oder abgelaufener Code allein die Ursache war.

Bei externer MFA gehören RADIUS-, NPS- oder IdP-Logs zur selben Prüfung. Für lokale Logdateien und Service-Zuordnung hilft Sophos Firewall Troubleshooting: Services und Logs. Für längere Aufbewahrung und Korrelation eignet sich Sophos Firewall Syslog an SIEM senden.

Vor dem breiten Rollout

• Pilotgruppe mit allen benötigten Diensten erfolgreich getestet.
• Zweiter Administrator, Einmalcodes und Device-Console-Recovery dokumentiert.
• Benutzer über App-Aufnahme und Passwort-plus-OTP informiert.
• Token-Reset für verlorene oder neue Smartphones geregelt.
• Device Access, Login-Sperren und zentrale Log-Aufbewahrung geprüft.
• Bei externer MFA Zuständigkeit, Timeouts und Fallback festgelegt.

Troubleshooting

Token, QR-Code und Eingabe

OTP-Code wird nicht akzeptiert

Zuerst Uhrzeit von Firewall und Smartphone, verwendete App, Hash-Algorithmus und Zeitschritt vergleichen. Unter Issued tokens kann man den Zeitoffset prüfen und synchronisieren. Bei einer Algorithmusmigration muss der alte Token gelöscht und neu registriert worden sein.

Ein Wechsel des NTP-Servers sollte separat geplant werden, weil die Firewall dabei bestehende IPsec-Tunnel neu verbindet.

QR-Code erscheint nicht oder lässt sich nicht scannen

Der Benutzer muss zur ausgewählten MFA-Gruppe gehören und sich am VPN Portal oder User Portal anmelden. Administratoren können bei aktivierter WebAdmin-MFA auch dort registrieren. Zusätzlich müssen Portal und Quelle unter Administration > Device access erlaubt sein.

Unter iOS beziehungsweise bei Okta Verify verwendet man bei den genannten Einschränkungen den Base32-Schlüssel statt des QR-Scans.

Anmeldung meldet falsches Passwort

Bei nativer Sophos-OTP-Anmeldung muss die Eingabe exakt aus Passwort und unmittelbar angehängtem Passcode bestehen. Ohne separates OTP-Feld ist nur das Passwort unvollständig.

Zugriff, Gruppen und Remote Access

Portal ist nicht erreichbar

Zuerst Zone, Quelle und den benötigten Dienst unter Administration > Device access prüfen. Eine enge Local Service ACL Exception Rule ist sicherer als eine pauschale WAN-Freigabe.

MFA greift nicht für Remote Access

MFA- und Remote-Access-Konfiguration müssen dieselbe tatsächlich importierte Benutzergruppe verwenden. Danach Clientprofil neu importieren beziehungsweise verteilen und die Verbindung mit dem echten Client testen. Vor der ersten VPN-Verbindung muss der Token am VPN Portal oder User Portal registriert sein.

MFA gilt nur für einen Teil der Benutzer

Nicht nur sichtbare Gruppennamen vergleichen, sondern die aus AD, LDAP, RADIUS oder Entra ID tatsächlich gematchten Gruppen. Nach dem Entfernen eines AD-Benutzers aus einer MFA-Gruppe kann noch eine letzte Anmeldung mit MFA nötig sein; erst folgende Logins benötigen keinen OTP mehr.

Lockout und externe MFA

Administrator ist ausgesperrt

Für den default admin verwendet man die oben beschriebenen Device-Console-Optionen 6 oder 7. Bei einem anderen Admin wird der vorbereitete zweite Administrator aus einer erlaubten Quelle verwendet und danach Gruppen-, Token- und Login-Sperrstatus geprüft.

RADIUS- oder Entra-MFA funktioniert nicht zuverlässig

RADIUS-Timeouts, IdP-Logs, Gruppen und das Challenge-Verhalten des konkreten Dienstes prüfen. Ein erfolgreicher Test des Authentifizierungsservers beweist noch keinen produktiven Login über VPN Portal, Sophos Connect oder WebAdmin. Jeder dieser Wege wird separat getestet.