Sophos Firewall VPN Portal gegen Brute Force absichern

Viele fehlgeschlagene Anmeldungen am Sophos Firewall VPN Portal zeigen zunächst, dass das Portal aus dem Internet erreichbar ist und automatisiert angegriffen wird. Sie beweisen noch keinen erfolgreichen Einbruch. Kritisch wird es, wenn die Versuche bestehende Benutzernamen verwenden, Konten in AD oder Microsoft Entra ID gesperrt werden oder im selben Zeitraum eine unbekannte erfolgreiche Anmeldung erscheint.

Für die Eindämmung gilt diese Reihenfolge:

1. Zeitfenster, Benutzer, Quell-IP und Authentifizierungsmethode in den Logs sichern.
2. Erfolgreiche Anmeldungen und Identitätsereignisse im gleichen Zeitraum prüfen.
3. Das VPN Portal über eine Local Service ACL auf benötigte Quellen oder Länder begrenzen.
4. Block login aktivieren und Port Sharing zwischen VPN Portal und SSL VPN ausschliessen.
5. Nicht benötigte Authentifizierungsmethoden entfernen sowie MFA oder Entra-Schutz kontrollieren.
6. Bekannte bösartige IPv4-Quellen ergänzend über Threat Feeds sperren und die Wirkung überwachen.

⚠️ Das VPN Portal nicht unvorbereitet abschalten. Sophos Connect Provisioning und Microsoft Entra ID SSO verwenden den VPN-Portal-Port. Vor Device-Access- oder Portänderungen braucht es einen getesteten zweiten Adminweg und einen Plan für Clientprofile, Redirect URIs und den Rückfall.

Vor jeder Änderung werden die aktuellen Einstellungen notiert oder per Konfigurationsbackup gesichert. Dazu gehören die WAN-Markierung für VPN portal, alle Felder und die Reihenfolge vorhandener Local-Service-ACL-Ausnahmen, Aktivierungszustand und drei Werte von Block login, Port und Protokoll von VPN Portal und SSL VPN sowie Auswahl und Reihenfolge der Authentifizierungsserver. Bei Provisioning oder Entra SSO werden ausserdem vpn_portal_port, Portal-URL und Redirect URI festgehalten. Für geänderte Threat Feeds sichert man URL, Indikatortyp, Action, Aktivierungszustand und weitere kundenspezifische Optionen. Für den Rückfall gelten diese Werte, nicht vermeintliche Defaults.

Angriff im Log Viewer bestätigen

Im Log Viewer öffnet man die Authentifizierungsereignisse und filtert auf:

• Log component: VPN Portal Authentication
• Status: Failed

Für jeden Treffer sind Zeitpunkt, Source IP, Source country, Username, Authentication mechanism und Reason relevant. Je nach Ansicht erscheinen nicht alle Angaben als Standardspalten; die Detailed view und zusätzliche Spalten zeigen die im jeweiligen Ereignis verfügbaren Details. Fehlt Kontext, werden anschliessend die Roh- und IdP-Logs geprüft. In einem SIEM wird nach dem Syslog-Feld log_component mit dem Wert VPN Portal Authentication und nach status mit dem Wert Failed gefiltert. Die genaue Syntax hängt vom eingesetzten SIEM ab.

Danach wird für dieselben Benutzernamen und dasselbe Zeitfenster auch nach Successful gesucht. Eine unbekannte erfolgreiche Anmeldung wiegt schwerer als die reine Anzahl fehlgeschlagener Versuche und wird als möglicher Kontovorfall untersucht.

Einzelne Quelle oder verteilter Angriff

Die Verteilung der Versuche zeigt, welche Schutzmassnahmen vorrangig sind:

• Viele Versuche von einer IP-Adresse: Block login kann die Quelle nach dem Schwellwert vorübergehend sperren.
• Wenige Versuche von vielen IP-Adressen: Ein verteiltes Botnetz bleibt je Quelle möglicherweise unter dem Schwellwert. ACLs, Identitätsschutz und Threat Feeds werden dann wichtiger.
• Viele Benutzernamen von derselben Quelle: Das kann auf Password Spraying oder Credential Stuffing hindeuten.
• Wiederholt derselbe echte Benutzer: AD-, Entra- oder RADIUS-Logs auf Kontosperren und erfolgreiche Anmeldungen prüfen.
• Zufällige, nicht vorhandene Namen: Das ist häufig automatisiertes Scanning, erzeugt aber weiterhin Last und Lograuschen.

Nur die Quell-IP manuell zu blockieren löst einen verteilten Angriff selten dauerhaft. Zuerst wird die Erreichbarkeit des Portals eingeschränkt; bekannte bösartige Quellen werden danach ergänzend automatisiert blockiert.

Rohlogs gezielt prüfen

Wenn der Log Viewer nicht genug Kontext liefert, lädt man unter Diagnostics > Tools > Troubleshooting logs die betroffenen Dateien herunter:

• vpnportal.log für den Portalzugriff;
• access_server.log für Benutzerauthentifizierung und Autorisierung;
• oauth_sso_vpn.log zusätzlich bei Microsoft Entra ID SSO.

sslvpn.log gehört dagegen zum SSL-VPN-Dienst und ist erst relevant, wenn der Fehler beim Tunnelaufbau statt bei der Portal-Anmeldung liegt. Authentifizierungslogs können Benutzernamen, öffentliche IP-Adressen und weitere sensible Anfragedaten enthalten. Ausschnitte werden deshalb zeitlich und inhaltlich begrenzt, vor der Weitergabe bereinigt und nicht ungeprüft in öffentliche Tickets kopiert. Weitere Logdateien ordnet Sophos Firewall Services und Logs zu; ein strukturiertes Supportarchiv beschreibt Sophos Firewall Logs sichern.

VPN Portal auf benötigte Quellen begrenzen

Das VPN Portal ist ein lokaler Firewall-Dienst. Normale Firewall- oder DNAT-Regeln steuern diesen Zugriff nicht; dafür ist Administration > Device access zuständig. Eine ausführliche Beschreibung bietet Device Access und Local Service ACL.

Vor der Änderung wird ein unabhängiger Zugang über Konsole, Management-LAN, Admin-VPN oder Sophos Fusion (ehemals Sophos Central) geöffnet und tatsächlich getestet. Danach legt man zuerst die enge Ausnahme an:

1. Unter Administration > Device access > Local service ACL exception rule auf Add klicken.
2. Rule name: zum Beispiel vpn-portal-from-approved-countries.
3. Rule position: Top.
4. IP version: IPv4; bei veröffentlichtem IPv6 ist zusätzlich eine getrennte IPv6-Regel nötig.
5. Source zone: WAN.
6. Source networks and hosts: feste Partnernetze, eine gepflegte IP-Liste oder eine Country Group mit den tatsächlich benötigten Ländern.
7. Destination host: die WAN-Schnittstelle oder die auf der Sophos Firewall konfigurierte WAN-IP, an der der Zugriff ankommt. Hinter einem vorgeschalteten NAT-Router ist damit nicht dessen öffentliche Adresse gemeint.
8. Services: nur VPN portal.
9. Action: Accept.
10. Regel speichern.

Nach dem Speichern wird die Ausnahme zuerst aus einer erlaubten externen Quelle getestet. Anschliessend entfernt man über den geprüften zweiten Adminzugang die pauschale WAN-Freigabe für VPN portal in der Device-Access-Matrix und speichert die Änderung. Device-Access-Änderungen wirken sofort. Danach folgen zwei Tests: Die erlaubte Quelle muss das Portal weiterhin erreichen, eine nicht erlaubte externe Quelle darf es nicht mehr erreichen. Scheitert der Positivtest, wird die bisherige WAN-Freigabe über den zweiten Adminzugang wiederhergestellt. Weitere Varianten des Cutovers beschreibt die Device-Access-Anleitung.

Eine Länderbegrenzung ist sinnvoll, wenn der Benutzerkreis geografisch klar ist. Sie ersetzt jedoch keine Identitätskontrolle: Reisende, Mobilfunknetze, VPN-Anbieter und falsch zugeordnete IP-Geolokationen können legitime Benutzer aussperren. Bei weltweitem Zugriff sind deshalb MFA, eine robuste Authentifizierung, aussagekräftige Logs und eine regelmässige Prüfung besonders wichtig.

Eine wichtige Ausnahme betrifft den auf der Firewall konfigurierten Web Proxy: Dessen HTTP- und HTTPS-Anfragen behandelt SFOS als intern und nicht als Verkehr aus einer Zone. Benutzer mit Proxyzugriff können dadurch das VPN Portal und andere HTTP-Dienste der Firewall erreichen, obwohl sie in Device Access für ihre Zone deaktiviert sind. Wird der Web Proxy verwendet, erfolgt der Portalaufruf im Negativtest einmal direkt und einmal nachweislich über den expliziten oder transparenten Webproxy. Device Access kann diesen internen Proxy-Pfad nicht zonenbasiert sperren; bei unerwünschtem Zugriff muss der Proxyzugriff selbst eingeschränkt werden.

Login Security und Ports richtig setzen

Unter Administration > Admin and user settings > Login security aktiviert man Block login und füllt die drei Eingabefelder für Anzahl der Fehlversuche, Zeitfenster und Sperrdauer aus. Ein reines Konfigurationsbeispiel sind fünf Fehlversuche innerhalb von 60 Sekunden und fünf Minuten Sperrdauer; dies ist weder ein universeller Sophos-Default noch ohne Pilotbetrieb als Produktionswert zu übernehmen. Die produktiven Werte hängen von Benutzerzahl, Helpdesk-Prozess und gemeinsam genutzten NAT-Quellen ab. Der Sperrtest erfolgt von einer kontrollierten Quell-IP, während der zweite Adminweg geöffnet bleibt.

Die Sperre arbeitet pro Quell-IP und gilt nach Erreichen des Schwellwerts für alle Dienste; dazu gehören beispielsweise WebAdmin, CLI, VPN Portal und User Portal. Hinter einem Büro-, Hotel- oder Provider-NAT können dadurch mehrere legitime Benutzer und ein Administrator gleichzeitig betroffen sein. Ein Negativtest wird deshalb nie über den einzigen verfügbaren Adminzugang ausgeführt.

Bei einem verteilten Angriff ist Block login nur eine Schutzschicht. Viele Bots können jeweils unter dem Schwellwert bleiben. Fehlgeschlagene CAPTCHA-Eingaben zählen zudem nicht als fehlgeschlagene Anmeldung und lösen die Sperre nicht aus.

Port Sharing ausschliessen

Diese Port- und Protokolleinstellungen werden verglichen:

• Administration > Admin and user settings > VPN portal HTTPS port, standardmässig TCP 443
• Remote access VPN > SSL VPN > SSL VPN global settings > Port, standardmässig 8443 mit TCP oder UDP

Verwenden VPN Portal und SSL VPN denselben Port und dasselbe Protokoll, greifen die Login-Security-Einstellungen nicht. Zudem wird das VPN Portal aus den für SSL VPN erlaubten Zonen erreichbar, selbst wenn es dort in Device Access deaktiviert ist.

Die Kombination muss deshalb eindeutig sein. Ein blosser Portwechsel verhindert keinen Angriff. Wird der VPN-Portal-Port geändert, müssen die Portal-URL, die Entra-Redirect-URI und bei Sophos Connect Provisioning der Wert vpn_portal_port angepasst und mit einem Pilotbenutzer getestet werden.

Authentifizierung und betroffene Konten schützen

Unter Authentication > Services > VPN portal authentication methods bleiben nur die Server aktiv, die für das aktuelle Remote-Access-Konzept benötigt werden. Ein nicht mehr verwendeter lokaler, AD-, LDAP- oder RADIUS-Pfad bietet keinen Nutzen, ermöglicht aber unnötige Anmeldeversuche gegen ein weiteres Benutzerverzeichnis. Mindestens ein Server muss ausgewählt bleiben. RADIUS mit Challenge-based MFA unterstützt das VPN Portal nicht und darf deshalb nicht als Portal-MFA eingeplant werden.

MFA verhindert nicht jeden Fehlversuch, reduziert aber das Risiko, dass ein bekanntes oder erratenes Passwort allein genügt. Für lokale und Verzeichnisbenutzer beschreibt MFA für VPN Portal und Remote Access die Einrichtung. Bei Microsoft Entra ID SSO werden zusätzlich Entra-MFA, Conditional Access, Sign-in Logs und Risk Events geprüft.

Auffällige Fehlversuche gegen ein bestehendes Benutzerkonto werden nicht nur auf der Firewall untersucht:

1. Kontosperren und erfolgreiche Anmeldungen im zuständigen Identity Provider prüfen.
2. Unbekannte erfolgreiche Sitzungen nach dem eigenen Incident-Prozess beenden.
3. Passwort und registrierte MFA-Methoden bei einem Kompromittierungsverdacht zurücksetzen.
4. Gruppenmitgliedschaft und Remote-Access-Berechtigung kontrollieren.
5. Erst danach mit einem dokumentierten Pilotlogin prüfen, ob der legitime Zugriff wieder funktioniert.

Das VPN Portal kann nur dann vollständig aus WAN entfernt werden, wenn kein benötigter Ablauf davon abhängt. .pro-Provisioning verbindet sich über vpn_portal_port. Bei Entra SSO müssen die für VPN Portal und Remote Access verwendete URL sowie die registrierte Redirect URI zum veröffentlichten Gateway und Port passen. Bei manuell verteilten .ovpn-Dateien ist unter Umständen eine engere Veröffentlichung möglich; Profiländerungen müssen jedoch kontrolliert verteilt und getestet werden.

Threat Feeds gegen bekannte Quellen ergänzen

Sophos Firewall kann bekannte bösartige Quell-IP-Adressen auch beim Datenverkehr zu Diensten der Firewall selbst abgleichen, darunter VPN Portal, WebAdmin und VPN. Laut SFOS-22-Hilfe gilt dieser Source-IP-Abgleich für MDR, NDR Essentials und Third-Party Threat Feeds, nicht jedoch für Sophos X-Ops Threat Feeds. Für einen eigenen Brute-Force-Feed eignet sich daher ein gepflegter Third-Party Feed mit IPv4-Adressen als zusätzliche Schutzschicht.

Die vollständige Einrichtung, Lizenzanforderungen, Monitor-Pilot, Block-Betrieb, False Positives und die von Avanet getesteten Cybora-Feeds erklärt Sophos Firewall Threat Feeds einrichten.

Damit Active-Threat-Response-Treffer lokal im Log Viewer erscheinen, muss unter System services > Log settings für Active threat response die Option Local reporting aktiviert sein. XGS 87/87w und 107/107w unterstützen kein lokales Reporting; dort verwendet man Sophos Fusion oder einen Syslog-Server als Logziel.

Threat Feeds ersetzen weder eine ACL noch eine starke Authentifizierung. Sie erfassen nur die darin gelisteten Adressen. Third-Party Feeds akzeptieren als IP-Indikatoren derzeit einzelne IPv4-Adressen, jedoch keine IPv6-Adressen, IP-Ranges oder Netzwerkadressen; neue oder nicht gelistete Bot-Adressen bleiben erreichbar. Umgekehrt kann ein False Positive legitime Benutzer blockieren. Ein neuer Feed startet deshalb in Monitor, wird auf Abruffehler und unerwartete Treffer geprüft und wechselt erst danach kontrolliert auf Block. Eine Threat Exclusion wirkt für alle Active-Threat-Response-Module und wird deshalb eng begrenzt, begründet und terminiert; Treffer und Ausnahmen gehören in einen regelmässigen Review.

Beim Rückfall wird ein geänderter Feed auf den dokumentierten vorherigen Modus zurückgesetzt; ein neu hinzugefügter Feed wird deaktiviert, aber nicht ungeprüft gelöscht. Danach wird geprüft, ob eine zuvor fälschlich blockierte legitime Quelle das Portal wieder erreicht und ob die übrigen Schutzschichten weiterhin greifen.

Wirkung kontrollieren und weiter überwachen

Nach jeder Änderung wird derselbe definierte Test wiederholt:

1. Erlaubte externe Quelle erreicht das VPN Portal und ein Pilotbenutzer kann sich anmelden.
2. Nicht erlaubte Quelle erreicht das Portal nicht mehr.
3. VPN Portal und SSL VPN verwenden eine eindeutige Port-Protokoll-Kombination.
4. Ein kontrollierter Fehlversuch erscheint mit erwarteter Quell-IP und Authentifizierungsmethode im Log Viewer.
5. Sophos Connect Provisioning, Entra SSO und der eigentliche VPN-Tunnel funktionieren weiterhin.
6. Threat-Feed-Treffer erscheinen am konfigurierten Logziel, sofern diese Schutzschicht eingesetzt wird.
7. Im festgelegten Beobachtungszeitraum treten keine neuen AD- oder Entra-Kontosperren und keine unbekannten erfolgreichen Anmeldungen auf.

Schlägt ein Test fehl, wird zunächst nur die zuletzt vorgenommene Änderung auf ihren dokumentierten Ausgangswert zurückgesetzt. Das kann Feedmodus, Authentifizierungsserver, Block login, Port und Redirect URI oder die Device-Access-Konfiguration betreffen. Beim Device-Access-Rückfall wird über den zweiten Adminweg zuerst die alte WAN-Freigabe wiederhergestellt und erst danach die neue ACL-Ausnahme entfernt. Ein Port-Rückfall stellt Port und Protokoll, .pro, Portal-URL und Redirect URI gemeinsam wieder her. Anschliessend werden der erlaubte und der nicht erlaubte Zugriff erneut geprüft.

Für die längerfristige Erkennung werden die Authentifizierungslogs an ein SIEM gesendet. Alarme sollten unter anderem auslösen, wenn viele Quellen denselben Benutzer angreifen, eine Quelle zahlreiche Benutzernamen ausprobiert oder nach einer Serie von Fehlversuchen eine erfolgreiche Anmeldung folgt.

FAQ