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 reale Benutzernamen getroffen werden, Konten in AD oder Microsoft Entra ID gesperrt werden oder zwischen den Fehlversuchen 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.

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. In einem SIEM werden entsprechend die Syslog-Felder log_component mit dem Wert VPN Portal Authentication und status mit dem Wert Failed verwendet; die konkrete Abfragesyntax hängt vom eingesetzten SIEM ab.

Danach wird für dieselben Benutzernamen und dasselbe Zeitfenster auch nach Successful gesucht. Eine unbekannte erfolgreiche Anmeldung ist wichtiger als die reine Anzahl fehlgeschlagener Versuche und muss wie ein möglicher Account-Incident behandelt werden.

Einzelne Quelle oder verteilter Angriff

Die Verteilung bestimmt, welcher Schutz greift:

• 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 passt zu Password Spraying oder Credential Stuffing.
• 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 erreichbare Fläche verkleinert, danach werden bekannte schlechte Quellen automatisiert ergänzt.

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 Request-Daten enthalten. Ausschnitte werden deshalb zeitlich und inhaltlich begrenzt, vor der Weitergabe redigiert 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. Die vollständigen Grundlagen stehen unter Device Access und Local Service ACL.

Vor der Änderung wird ein unabhängiger Zugang über Konsole, Management-LAN, Admin-VPN oder 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. 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.

Im Zielzustand ist das VPN Portal in der Device-Access-Matrix nicht pauschal für WAN freigegeben, sondern nur über die benötigten ACL-Ausnahmen erreichbar. Device-Access-Änderungen wirken sofort; der sichere Cutover mit Positivtest, Negativtest und Rückfall steht deshalb bewusst in der ausführlichen Device-Access-Anleitung.

Die Ausnahme wird danach aus einer erlaubten und einer nicht erlaubten externen Quelle geprüft. Solange noch eine breite WAN-Freigabe aktiv ist, beweist ein erfolgreicher Positivtest allein nicht, dass die Ausnahme wie erwartet begrenzt.

Eine Länderbegrenzung ist sinnvoll, wenn der Benutzerkreis geografisch klar ist. Sie ist aber keine Identitätskontrolle: Reisende, Mobilfunknetze, VPN-Anbieter und falsch zugeordnete IP-Geolokationen können legitime Benutzer aussperren. Weltweiter Zugriff braucht deshalb besonders starke Identität, MFA, Logging und einen Reviewprozess.

Login Security und Ports richtig setzen

Unter Administration > Admin and user settings > Login security aktiviert man Block login. Der Sophos Firewall Health Check verwendet als Ausgangspunkt fünf fehlgeschlagene Anmeldungen innerhalb von 60 Sekunden und eine Sperrdauer von fünf Minuten. Der passende produktive Wert hängt trotzdem von Benutzerzahl, Helpdesk-Prozess und gemeinsam genutzten NAT-Quellen ab.

Die Sperre arbeitet pro Quell-IP und betrifft nach Erreichen des Schwellwerts nicht nur das VPN Portal. WebAdmin, CLI, VPN Portal und User Portal öffnen dann ebenfalls nicht mehr aus dieser Quelle. Ein Büro, Hotel oder Provider-NAT kann dadurch mehrere legitime Benutzer und einen Administrator gleichzeitig betreffen. Ein Negativtest wird deshalb nie vom 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.

Port Sharing ausschliessen

Diese beiden Werte 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. Eine zufällige Portverschiebung allein verhindert keinen Angriff. Wird der VPN-Portal-Port geändert, müssen Portal-URL, Entra-Redirect-URI und bei Sophos Connect Provisioning der Wert vpn_portal_port angepasst und mit einem Pilotbenutzer neu getestet werden.

Authentifizierung und betroffene Konten schützen

Unter Authentication > Services > VPN portal authentication methods bleiben nur die Server aktiv, die das aktuelle Remote-Access-Konzept wirklich benötigt. Ein nicht mehr verwendeter lokaler, AD-, LDAP- oder RADIUS-Pfad bietet keinen Nutzen, kann aber weitere Zugangsdaten gegen das öffentliche Portal prüfen lassen.

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.

Ein realer Benutzer mit auffälligen Fehlversuchen wird nicht nur auf der Firewall betrachtet:

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. Entra SSO und .pro-Provisioning verwenden den Portal-Port. Bei manuell verteilten .ovpn-Dateien kann ein engerer Veröffentlichungsprozess möglich sein, Änderungen am Profil müssen dann aber kontrolliert verteilt und getestet werden.

Threat Feeds gegen bekannte Quellen ergänzen

Sophos Firewall kann bekannte bösartige Quell-IP-Adressen auch bei systemgerichtetem Traffic zu Diensten wie VPN Portal, WebAdmin und VPN abgleichen. Dafür eignen sich gepflegte IPv4-Feeds 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. Für einen neuen Feed gilt weiterhin: Abruf und IoC-Inhalt prüfen, zuerst die Wirkung beobachten und erst danach kontrolliert blockieren.

Damit Active-Threat-Response-Treffer im Log Viewer erscheinen, muss unter System services > Log settings für Active threat response die Option Local reporting aktiviert sein.

Threat Feeds ersetzen keine ACL und keine starke Identität. Sie erkennen nur enthaltene Indikatoren, Third-Party Feeds unterstützen als Quell-IP-IoCs derzeit IPv4, und eine neue oder nicht gelistete Bot-IP bleibt erreichbar. Umgekehrt kann ein False Positive einen legitimen Benutzer blockieren; deshalb braucht es einen dokumentierten Ausnahme- und Reviewprozess.

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 im Active-Threat-Response-Log, sofern diese Schutzschicht eingesetzt wird.
7. AD- oder Entra-Kontosperren sowie erfolgreiche unbekannte Anmeldungen bleiben aus.

Für längerfristige Erkennung sendet man Authentifizierungslogs an ein SIEM. Sinnvolle Alarme betrachten nicht nur die Zahl der Fehler, sondern auch viele verschiedene Quellen gegen denselben Benutzer, viele Benutzernamen von einer Quelle und erfolgreiche Anmeldungen nach einer Fehlversuchsserie.

FAQ