Sophos Firewall CAPTCHA für WebAdmin und User Portal verwalten

Seit SFOS 18.0 MR3 kann die Sophos Firewall beim WebAdmin Login und beim User Portal ein CAPTCHA anzeigen. Dieser Schutz wurde nach einer Sicherheitslücke eingeführt und soll automatisierte Loginversuche erschweren.

Man kann CAPTCHA per Device Console deaktivieren oder wieder aktivieren. Das sollte aber nur bewusst passieren. WebAdmin, User Portal, VPN Portal und SSH gehören zur direkten Angriffsfläche der Firewall. Wenn diese Dienste aus unsicheren Netzen erreichbar sind, sollte CAPTCHA nicht die einzige Schutzmassnahme sein und auch nicht leichtfertig entfernt werden.

Einordnung

CAPTCHA ist in SFOS kein Ersatz für ein sauberes Administrationsdesign. Es ist eine zusätzliche Hürde vor bestimmten Loginseiten. Entscheidend bleibt, ob diese Loginseiten überhaupt aus WAN, VPN, Gastnetzen oder breiten internen Netzen erreichbar sein müssen.

Welche Loginseiten betroffen sind

Die Device-Console-Befehle in diesem Artikel steuern CAPTCHA für zwei konkrete Loginseiten:

• WebAdmin Console: Befehlsteil webadminconsole, also der Admin-Login der lokalen WebAdmin-Oberfläche.
• User Portal: Befehlsteil userportal, also das Benutzerportal für VPN-Konfigurationen, OTP und Benutzerfunktionen.

Sophos beschreibt CAPTCHA für Administratoren am WebAdmin und für lokale oder Gastbenutzer am User Portal, wenn diese über WAN- oder VPN-Interfaces zugreifen. Das ist nicht dasselbe wie eine vollständige Absicherung aller Remote-Access-Dienste. VPN Portal, SSL VPN, IPsec, SSH, DNS, SNMP und andere lokale Firewall-Dienste müssen zusätzlich über Administration > Device access, Local Service ACL, MFA, Logging und ein sauberes Remote-Access-Konzept kontrolliert werden.

Auch die Ports helfen bei der Einordnung: WebAdmin nutzt standardmässig 4444, User Portal 4443 und VPN Portal 443. Seit SFOS 20.0 ist das VPN Portal ein eigener Dienst. Bei Upgrades kann der frühere User-Portal-Port deshalb auf das VPN Portal wandern, während das User Portal auf 4443 oder, falls nicht frei, auf 65040 gelegt wird. Vor einem CAPTCHA-Test sollte man deshalb immer prüfen, welche Loginseite und welcher Port tatsächlich aufgerufen werden.

Der dokumentierte Default ist für die globalen und VPN-spezifischen Befehle enabled. Wenn ein Login aus einem LAN-Interface kein CAPTCHA zeigt, ist das nicht automatisch eine Fehlkonfiguration: Sophos verlangt für LAN-Zugriffe kein CAPTCHA. Mit lokalen Benutzern sind hier Sophos-Firewall-Benutzer gemeint, nicht Benutzer aus einem externen Authentifizierungsserver wie Active Directory.

Auf XG 85 und XG 85w ist CAPTCHA laut Sophos nicht verfügbar. Wenn eine solche Appliance kein CAPTCHA zeigt, ist das deshalb kein normaler Deaktivierungsfall, sondern eine Plattformgrenze.

Wichtig: Fehlgeschlagene CAPTCHA-Versuche sind nicht dasselbe wie fehlgeschlagene Anmeldungen. Wenn ein CAPTCHA schon vor der eigentlichen Anmeldung scheitert, sollte man Login-Sperren, Authentifizierungslogs und Portalzugriffe deshalb getrennt bewerten.

Für die Grundlogik lokaler Firewall-Dienste ist Device Access und Local Service ACL auf Sophos Firewall der wichtigste Anschlussartikel. Wenn nicht klar ist, ob ein Zugriff über normale Firewall-Regeln oder über Device Access gesteuert wird, hilft Sophos Firewall Regel greift nicht: Ursachen prüfen.

Was dieser Artikel nicht abdeckt

Der Artikel behandelt nur die globale CAPTCHA-Einstellung für WebAdmin Console und User Portal. Das ersetzt kein Remote-Access-Hardening und ist keine Anleitung, um SSL VPN, IPsec, Sophos Connect oder Microsoft Entra ID SSO abzusichern.

Wenn es um Remote Access geht, sind andere Fragen wichtiger:

• SSL VPN einrichten und testen: Sophos Firewall SSL VPN Remote Access einrichten.
• Sophos Connect vorbereiten: Sophos Connect auf Sophos Firewall konfigurieren.
• MFA für Admins und Remote Access: MFA für Sophos Firewall WebAdmin, VPN Portal und Remote Access aktivieren.
• Portal- und Dienstzugriff begrenzen: Device Access richtig konfigurieren.

Auch SPX Portal und andere Portal- oder Mail-Funktionen sollten nicht aus diesen Befehlen abgeleitet werden. Beim SPX Portal bleibt CAPTCHA aktiv und kann nicht über diese Device-Console-Befehle ausgeschaltet werden.

Wann man CAPTCHA nicht deaktivieren sollte

CAPTCHA sollte aktiv bleiben, wenn einer dieser Punkte zutrifft:

• WebAdmin ist aus WAN oder aus breiten internen Netzen erreichbar.
• User Portal ist aus dem Internet erreichbar.
• VPN Portal oder SSL VPN sind öffentlich erreichbar.
• MFA ist nicht konsequent für Admins und Remote-Access-Benutzer aktiviert.
• Es gibt viele fehlgeschlagene Loginversuche im Log.
• Es existiert kein dediziertes Management-Netz.
• Zugriff auf WebAdmin oder SSH ist nicht über Device Access eingeschränkt.

CAPTCHA verhindert keine gezielten Angriffe und ersetzt keine MFA. Es reduziert aber automatisierte Loginversuche und Hintergrundrauschen. Wenn man es entfernt, sollten andere Kontrollen sauber greifen.

Entscheidung und Vorbereitung

Aktiv lassen oder temporär deaktivieren?

In der Praxis gibt es nur wenige gute Gründe, CAPTCHA abzuschalten. Diese Entscheidung sollte wie eine kleine Sicherheitsänderung behandelt werden.

Typische Entscheidungen:

• WebAdmin oder User Portal ist aus dem Internet erreichbar: CAPTCHA aktiv lassen und zuerst Erreichbarkeit, MFA und Logs prüfen.
• Nur Management-Netz oder Admin-VPN darf zugreifen: Eine temporäre Deaktivierung kann vertretbar sein, wenn sie dokumentiert ist.
• Barrierefreiheitsproblem bei einzelnen Admins oder Benutzern: Quelle begrenzen, MFA aktiv lassen und Ausnahme dokumentieren.
• Automatisierter Test in Laborumgebung: Nur isoliert deaktivieren und nicht für produktive Portale übernehmen.
• Supportfall mit zeitlich begrenzter Änderung: Vorher Status sichern, nachher wieder aktivieren oder die Ausnahme bewusst dokumentieren.

Wenn die Begründung nur “bequemer” ist, sollte CAPTCHA nicht deaktiviert werden. Besser ist, den Zugriff auf WebAdmin oder User Portal so zu gestalten, dass berechtigte Benutzer weniger Hürden haben, ohne die Loginseite unnötig breit zu exponieren.

Bessere Alternative: Erreichbarkeit reduzieren

Oft ist nicht CAPTCHA das eigentliche Problem, sondern eine zu breit erreichbare Loginseite. Wenn ein Portal nur gelegentlich gebraucht wird, ist es meistens sauberer, die Erreichbarkeit zu reduzieren, statt den zusätzlichen Login-Schutz zu entfernen.

Typische Alternativen:

• Admins sollen WebAdmin ohne öffentliches Loginrauschen erreichen: WebAdmin nur aus Management-Netz, Admin-VPN oder fester Admin-IP erlauben.
• Benutzer brauchen das User Portal nur für den ersten VPN-Download: Portal zeitlich begrenzt oder nur aus internen/VPN-Netzen erreichbar machen.
• Externer Support braucht kurzfristig Zugriff: Temporäre Local Service ACL Exception Rule mit Review-Datum nutzen.
• CAPTCHA stört automatisierte Labortests: Nur in isolierter Testumgebung deaktivieren, nicht auf produktive Portale übertragen.

Diese Reihenfolge ist wichtig: Erst die Angriffsfläche verkleinern, dann über CAPTCHA entscheiden. Wenn WebAdmin, User Portal oder VPN Portal weiterhin breit erreichbar bleiben, sollte die Deaktivierung sehr gut begründet und zusätzlich mit MFA, Logging und regelmässigem Review abgesichert sein.

Vor dem Deaktivieren prüfen

Vor einer Änderung sollten diese Punkte geprüft werden:

1. Device Access: Ist WebAdmin oder User Portal nur aus vertrauenswürdigen Quellen erreichbar?
2. MFA: Ist MFA für WebAdmin, VPN Portal und Remote Access aktiv?
3. Logging: Werden fehlgeschlagene Logins und Portalzugriffe kontrolliert?
4. SSH-Zugriff: Ist SSH nur temporär oder aus einem Management-Netz erlaubt?
5. Fallback: Ist klar, wie CAPTCHA bei Bedarf wieder aktiviert wird?
6. Grund: Gibt es wirklich einen technischen Grund, zum Beispiel Barrierefreiheit, Automatisierung in einem isolierten Labor oder ein temporäres Support-Szenario?

Für die Zugriffsbeschränkung ist Device Access richtig konfigurieren der zentrale Artikel. Für Admin- und Portal-Logins sollte zusätzlich MFA für Sophos Firewall WebAdmin, VPN Portal und Remote Access aktivieren geprüft werden.

⚠️ Achtung: CAPTCHA sollte nicht deaktiviert werden, um öffentlich erreichbare Portale bequemer zu machen. Zuerst die Erreichbarkeit reduzieren, MFA aktivieren und Logs prüfen.

Änderung in der Device Console

SSH und Device Console öffnen

Die CAPTCHA-Einstellung wird über die Device Console geändert. Dafür braucht man SSH-Zugriff auf die Firewall.

1. SSH-Zugriff unter Administration > Device access nur für eine vertrauenswürdige Quelle erlauben.
2. Per SSH mit dem Benutzer admin verbinden.
3. In der Konsolenübersicht die Device Console öffnen.

Die Anleitung Sophos Firewall per SSH verbinden beschreibt den sicheren SSH-Zugriff mit macOS, Linux und Windows.

Nach der Änderung sollte SSH wieder auf das notwendige Minimum eingeschränkt werden. Die folgenden system captcha-authentication-global Befehle gehören in die Device Console, nicht in die Advanced Shell. Wenn stattdessen Logdateien mit tail, grep oder less geprüft werden, ist die Advanced Shell richtig. Die Unterscheidung ist in Sophos Firewall Troubleshooting: Services und Logs erklärt.

CAPTCHA-Status anzeigen

Vor jeder Änderung sollte zuerst der aktuelle Status geprüft werden.

Für die globale Einstellung von WebAdmin:

system captcha-authentication-global show for webadminconsole

Für die globale Einstellung des User Portal:

system captcha-authentication-global show for userportal

Der Befehl zeigt, ob CAPTCHA für die jeweilige Loginseite aktiv ist. Das Ergebnis sollte mit Datum, Firewall, Admin und Grund dokumentiert werden, damit man die Änderung später nachvollziehen kann.

Wenn keine bewusste Ausnahme dokumentiert ist, sollte der erwartete Normalzustand enabled sein.

Global oder nur VPN-spezifisch ändern?

Die globalen Befehle gelten für WebAdmin Console und User Portal über WAN- oder VPN-Interfaces. Wenn man sie deaktiviert, übersteuert man damit auch die VPN-spezifische CAPTCHA-Einstellung.

Der sichere Ausgangspunkt ist deshalb: global enabled lassen, Status mit show prüfen und nur bei einem klaren VPN-Sonderfall die VPN-spezifische Einstellung ändern.

Wenn das Problem nur Benutzer oder Administratoren betrifft, die über VPN zugreifen, sollte man zuerst prüfen, ob eine VPN-spezifische Änderung reicht:

system captcha-authentication-vpn show for webadminconsole
system captcha-authentication-vpn show for userportal

Eine VPN-spezifische Deaktivierung ist enger als eine globale Deaktivierung. Trotzdem gilt auch hier: Grund dokumentieren, echten Login testen und nach dem Supportfall wieder bewusst entscheiden, ob CAPTCHA aktiv bleiben soll.

Sonderfall: IPsec-Tunnel mit Remote Subnet Any

Bei Site-to-Site-IPsec-Verbindungen kann CAPTCHA unerwartet greifen, wenn ein Tunnel mit Remote Subnet Any konfiguriert wurde. Dann behandelt die Firewall den Zugriff über diese Verbindung unter Umständen breiter als gewünscht. Das ist besonders relevant, wenn Administratoren oder lokale Benutzer über einen Standorttunnel auf WebAdmin oder User Portal zugreifen.

Vor einer CAPTCHA-Änderung sollte man in solchen Umgebungen prüfen:

• Gibt es policy-based IPsec-Verbindungen mit Remote Subnet Any?
• Erfolgt der WebAdmin- oder User-Portal-Zugriff über einen Site-to-Site-Tunnel?
• Ist der Tunnel wirklich die richtige Managementstrecke oder nur historisch gewachsen?
• Reicht eine gezielte IPsec-Route für einzelne Remote-Hosts oder Remote-Netze?
• Wäre ein dediziertes Managementnetz oder Admin-VPN sauberer?

Wenn nur bestimmte Remote-Hosts oder Netze betroffen sind, ist eine gezielte IPsec-Route oft sauberer als eine globale CAPTCHA-Deaktivierung. Der Ablauf ist im Artikel IPsec Route auf Sophos Firewall erstellen beschrieben. Trotzdem gilt: Eine Routing-Korrektur ersetzt keine Prüfung von Device Access, MFA und Log Viewer.

CAPTCHA für WebAdmin deaktivieren

Wenn CAPTCHA für den WebAdmin Login bewusst deaktiviert werden soll:

system captcha-authentication-global disable for webadminconsole

Wenn nur VPN-Zugriffe betroffen sind, ist stattdessen dieser engere Befehl zu prüfen:

system captcha-authentication-vpn disable for webadminconsole

Danach sollte man sofort prüfen:

1. WebAdmin Login aus dem Management-Netz testen.
2. WebAdmin Login aus nicht erlaubten Netzen testen.
3. Log Viewer auf fehlgeschlagene Logins prüfen.
4. MFA für Administratoren kontrollieren.

WebAdmin sollte nicht aus beliebigen Quellen erreichbar sein. Wenn externer Zugriff nötig ist, sind VPN, Sophos Central Firewall Management, eine feste Admin-IP oder eine Local Service ACL Exception Rule die bessere Grundlage.

CAPTCHA für User Portal deaktivieren

Wenn CAPTCHA für das User Portal bewusst deaktiviert werden soll:

system captcha-authentication-global disable for userportal

Wenn nur VPN-Benutzer betroffen sind, ist stattdessen dieser engere Befehl zu prüfen:

system captcha-authentication-vpn disable for userportal

Das User Portal sollte nur erreichbar sein, wenn es wirklich gebraucht wird, zum Beispiel für VPN-Konfigurationen, OTP-Token oder Benutzerfunktionen. In vielen Umgebungen wird das Portal einmal für eine Einrichtung benötigt und bleibt danach unnötig offen.

Nach der Änderung prüfen:

1. User Portal Login mit einem normalen Benutzer testen.
2. MFA- oder OTP-Prozess prüfen, falls verwendet.
3. Erreichbarkeit aus WAN, VPN, LAN und Gastnetzen kontrollieren.
4. Fehlgeschlagene Logins im Log Viewer prüfen.

Wenn das User Portal öffentlich erreichbar bleiben muss, sollten MFA, starke Passwörter, Logging, eingeschränkte Quellen und gegebenenfalls Sophos Firewall Threat Feeds geprüft werden.

CAPTCHA wieder aktivieren

Für WebAdmin:

system captcha-authentication-global enable for webadminconsole

Für User Portal:

system captcha-authentication-global enable for userportal

Für die VPN-spezifische Einstellung:

system captcha-authentication-vpn enable for webadminconsole
system captcha-authentication-vpn enable for userportal

Nach der Aktivierung sollte man den Status erneut anzeigen:

system captcha-authentication-global show for webadminconsole
system captcha-authentication-global show for userportal
system captcha-authentication-vpn show for webadminconsole
system captcha-authentication-vpn show for userportal

Wenn CAPTCHA wegen eines Supportfalls deaktiviert wurde, sollte es nach Abschluss des Falls wieder aktiviert oder die Deaktivierung bewusst dokumentiert werden.

Nachkontrolle und Betrieb

Nachkontrolle nach der Änderung

Nach einer CAPTCHA-Änderung sollte man nicht nur den show-Befehl ausführen. Entscheidend ist, ob die betroffene Loginseite weiterhin nur aus den vorgesehenen Netzen erreichbar ist und ob Anmeldeereignisse nachvollziehbar bleiben.

Sinnvolle Nachkontrolle:

1. Status für WebAdmin und User Portal mit show prüfen.
2. Administration > Device access öffnen und erlaubte Zonen für WebAdmin, User Portal, SSH, VPN Portal und SSL VPN kontrollieren.
3. WebAdmin oder User Portal aus einem erlaubten Netz testen.
4. Zugriff aus einem nicht erlaubten Netz testen, wenn das ohne Risiko möglich ist.
5. Im Log Viewer fehlgeschlagene und erfolgreiche Anmeldeereignisse prüfen.
6. MFA für Admins und Remote-Access-Benutzer getrennt kontrollieren.
7. Offene SSH-Freigabe nach der Änderung wieder entfernen oder eng begrenzen.

Wenn die Loginseite aus WAN erreichbar bleibt, sollte die Deaktivierung besonders kritisch bewertet werden. In diesem Fall sind MFA, enge Quellen, Logging und ein regelmässiger Review Pflicht. Noch besser ist meist, WebAdmin oder User Portal gar nicht breit aus dem Internet erreichbar zu machen.

Zusätzlich sollte man Administration > Admin and user settings > Login security getrennt bewerten. Fehlgeschlagene CAPTCHA-Versuche lösen laut Sophos keine Login-Sperre aus. Echte fehlgeschlagene Anmeldungen können dagegen je nach Einstellung den Zugriff auf WebAdmin, CLI, VPN Portal und User Portal von der Quell-IP blockieren. Deshalb sollte man im Log Viewer unterscheiden, ob ein CAPTCHA scheitert oder ob die eigentliche Anmeldung fehlschlägt.

Änderung nachvollziehbar dokumentieren

Bei sicherheitsrelevanten Änderungen sollte später klar sein, warum CAPTCHA deaktiviert wurde und ob die Änderung noch nötig ist. Dazu reicht oft ein kurzer Eintrag im Change- oder Ticket-System.

Dokumentieren:

• Ausgangsstatus für WebAdmin und User Portal.
• Grund der Änderung.
• Betroffene Firewall und SFOS-Version.
• Zeitpunkt, ausführender Admin und geplanter Rückbau.
• Welche Zugriffsbegrenzungen und MFA-Kontrollen währenddessen aktiv sind.
• Ergebnis der Nachkontrolle im Log Viewer.

Wenn mehrere Admins an der Firewall arbeiten, ist zusätzlich der Sophos Firewall Audit Trail hilfreich. Für Login- und Service-Fehlersuche passt Sophos Firewall Troubleshooting: Services und Logs.

Empfohlene Schutzmassnahmen

Wenn CAPTCHA deaktiviert wird, sollten mindestens diese Kontrollen bestehen:

• WebAdmin nur aus Management-Netz, Admin-VPN oder fester Admin-IP erreichbar.
• SSH nur bei Bedarf und nur aus vertrauenswürdigen Quellen erlaubt.
• MFA für Administratoren aktiv.
• User Portal nur dort erreichbar, wo es gebraucht wird.
• VPN Portal und SSL VPN mit MFA und Logging abgesichert.
• Fehlgeschlagene Logins werden regelmässig geprüft.
• Externe Portale werden durch Device Access, Local Service ACL, Country Blocking oder Threat Feeds reduziert.

Für öffentlich erreichbare Dienste passt zusätzlich Sophos Firewall: Länder und bösartige IPs blockieren. Für einen breiteren Sicherheitscheck hilft Sophos Firewall Health Check richtig nutzen.

Typische Fehler und Troubleshooting

• CAPTCHA deaktivieren, weil es unbequem ist: Loginoberflächen werden leichter automatisiert angegriffen. Besser Zugriff begrenzen und MFA aktivieren.
• WebAdmin aus WAN erreichbar lassen: Das ist direkte Management-Angriffsfläche. Besser Management-IP, VPN oder Central Management nutzen.
• User Portal dauerhaft offen lassen: Das Portal wird unnötiges Ziel für Bots und Brute Force. Besser nur bei Bedarf erreichbar machen.
• SSH nach Änderung offen lassen: CLI-Zugriff bleibt exponiert. SSH wieder einschränken oder deaktivieren.
• Status nicht dokumentieren: Spätere Prüfung wird schwierig. Vorher und nachher show ausführen.
• Falsche Konsole verwendet: Der Befehl wird nicht erkannt. In der SSH-Menüauswahl die Device Console öffnen.
• VPN Portal mit User Portal verwechselt: Es entsteht eine falsche Erwartung an das CAPTCHA-Verhalten. Betroffene Loginseite und Device-Access-Dienst getrennt prüfen.
• User Portal teilt sich Port mit SSL VPN: CAPTCHA erscheint für das User Portal nicht wie erwartet oder der falsche Dienst wird getestet. Eindeutige Portal- und VPN-Ports planen und mit echtem Benutzer testen.
• Änderung bleibt nach Supportfall aktiv: Der Schutz wird dauerhaft reduziert. Rückbauzeitpunkt und Review im Ticket dokumentieren.

Häufige Fragen