Aktuell

VPN-Spray-Attacken: Warum Sophos Central oft schweigt — und wie unsere Active-Defense-Pipeline reagiert

Verteiltes Password-Spraying gegen VPN-Portale ist längst Alltag — Sophos Central/Fusion zeigt davon aber nichts an, und die normale Firewall-Regel greift nicht. Wie SyslogViz3D das Muster trotzdem erkennt und was Sophos-Admins jetzt prüfen sollten.

29. September 2026

Ende 2025 registrierte die Sicherheitsfirma GreyNoise innerhalb von nur 16 Stunden über 1,7 Millionen Login-Versuche gegen Palo-Alto-GlobalProtect-VPN-Portale — verteilt auf mehr als 10.000 unterschiedliche IP-Adressen. Parallel dazu stieg die Zahl der IPs, die gezielt Cisco-SSL-VPN-Portale angreifen, von rund 200 auf über 1.270 pro Tag. Verteiltes Password-Spraying gegen VPN-Zugänge ist damit kein Randphänomen mehr, sondern ein etabliertes, massenhaft automatisiertes Angriffsmuster — unabhängig vom eingesetzten Firewall-Hersteller.

Genau hier liegt das eigentliche Problem: Klassischer Brute-Force-Schutz zählt Fehlversuche pro IP-Adresse und sperrt diese IP, sobald eine Schwelle überschritten wird. Bei einem verteilten Angriff mit tausenden IPs bleibt aber jede einzelne IP für sich betrachtet unauffällig — die klassische Schwellenwert-Logik greift schlicht nicht, weil kein einzelner Absender genug Versuche liefert, um aufzufallen.

1,7 Mio.

10.000+

beteiligte Angreifer-IPs in derselben Kampagne

200 → 1.270

IPs/Tag gegen Cisco-SSL-VPN — Anstieg binnen weniger Wochen

Warum Schwellenwert-Schutz hier versagt

„Nach 5 Fehlversuchen diese IP sperren“ funktioniert nur, wenn ein Angreifer auch tatsächlich von einer IP aus angreift. Verteilt sich derselbe Angriff auf tausende IPs, bleibt jede einzelne unterhalb jeder sinnvollen Schwelle — die Sperrlogik greift nie, obwohl der Angriff in Summe massiv ist.

Unsere Beobachtung bei Sophos XGS: Weder Warnung noch Block

In mehreren Kundenprojekten mit Sophos-XGS-Firewalls haben wir dasselbe Bild beobachtet: Verteiltes Password-Spraying gegen das SSL-VPN- beziehungsweise User-Portal taucht weder in Sophos Central noch im neueren Fusion-Dashboard als Warnung oder Vorfall auf. Auch eine regulär konfigurierte Firewall-Regel blockiert diese Versuche nicht — und das hat einen technischen Grund, keinen Konfigurationsfehler: Der Zugriff auf das VPN-/User-Portal läuft über einen lokalen Gerätedienst direkt auf der Firewall selbst (WAN-seitiger WebAdmin-/Portal-Zugriff), nicht über regulären Zone-zu-Zone-Verkehr, den die normale Firewall-Regelkette filtert. Eine klassische Regel „WAN → VPN-Zone blockieren“ greift deshalb schlicht nicht — sie prüft den falschen Verkehrspfad.

WAN-Zugriff auf das VPN-/User-Portal nicht offen für „Any“ lassen, sondern über die Local Service ACL Exception Rule (Administration → Device Access) auf feste Absender-IPs oder Länder einschränken.
Falls ein offener Zugriff geschäftlich nötig ist: separates Monitoring außerhalb der Firewall selbst einplanen — die Firewall-eigenen Logs/Dashboards erfassen diesen Dienst nicht wie regulären Netzwerk-Traffic.
Bestehende VPN-Portal-Zugriffsregeln aktiv gegenprüfen, nicht nur einmalig beim Rollout einrichten — genau diese Lücke bleibt in der Praxis oft jahrelang unbemerkt, weil sie nirgends alarmiert.

Wie SyslogViz3D das Muster trotzdem erkennt

Die Erkennung läuft bei uns unabhängig vom Firewall-Dashboard: SyslogViz3D wertet die Syslog-Daten direkt aus und erkennt Password-Spraying über Log-Korrelation — unter anderem das Muster „ein Benutzername, viele unterschiedliche Quell-IPs“ sowie eine langsame, über 24 Stunden verteilte Variante pro Absender-Subnetz. Diese Erkennung ist bewusst herstellerunabhängig aufgebaut und funktioniert unabhängig davon, was das jeweilige Firewall-Dashboard selbst anzeigt oder nicht.

Active-Defense-Pipeline: Erkennung herstellerunabhängig, Blockieren aktuell für Sophos

Active Defense

Unser Response-Modul haben wir kürzlich zu einer generischen Active-Defense-Pipeline umgebaut: Die automatische Reaktion (Blockieren, Entsperren, Session-Kill, Nutzersperre) ist architektonisch für beliebige Firewall-Hersteller vorbereitet und nicht mehr an einen einzelnen Detektor gebunden. Ausgeliefert wird die automatische Block-Aktion direkt auf der Firewall aktuell für Sophos XGS — weitere Hersteller sind vorbereitet und werden ergänzt, sobald der Bedarf bei einem Kundenprojekt konkret entsteht.

SIEM, das nicht auf das Firewall-Dashboard angewiesen ist

Wenn Ihre Firewall selbst nicht warnt, brauchen Sie eine Erkennung, die unabhängig davon läuft. Wir zeigen Ihnen, wie SyslogViz3D Ihre bestehende Infrastruktur ergänzt.

Mehr zu SyslogViz3D