Ausgangslage: Brute-Force aufs VPN-Portal
Der konkrete Auslöser für diesen Beitrag war kein theoretisches “Security-Hardening”, sondern ganz banal: Brute-Force-Versuche auf VPN-Portal einiger Kunden-Firewalls. Sobald ein Portal oder ein VPN-Endpunkt öffentlich erreichbar ist, dauert es meist nicht lange, bis automatisierte Scans und Login-Versuche auftauchen. Das ist nicht persönlich – das ist schlicht das Grundrauschen des Internets.
Genau an diesem Punkt wird vielen erst klar, dass es bei einer Sophos XGS nicht nur um “Firewall Rules” für Durchsatzverkehr geht, sondern auch um die Systemservices, die die Firewall selbst bereitstellt. Denn Portale, Admin-Zugänge und VPN-Dienste sind in der Logik der XGS keine gewöhnlichen Ziele in der DMZ, sondern lokale Dienste der Firewall. Und wenn der Angriff auf einen solchen Dienst geht, dann hilft es wenig, irgendwo im Regelwerk “irgendwas zu blocken”, während der Service selbst weiterhin weltweit offen steht.
Deshalb dreht sich dieser Artikel um eine einfache, aber wirkungsvolle Idee: Systemservices so einschränken, dass sie nur dort erreichbar sind, wo sie wirklich gebraucht werden, zum Beispiel nur aus DACH/EU oder sogar nur aus definierten Admin-Netzen. Das senkt die Angriffsfläche massiv, reduziert Login-Spam und sorgt dafür, dass aus “ständig klopft jemand an” wieder ein kontrollierbarer Zustand wird.
Die wichtigste Unterscheidung: Transit-Traffic vs. Local Services
Viele Stolperfallen entstehen, weil man intuitiv im Bereich “Firewall Rules” sucht. Das ist verständlich – aber bei Systemservices nicht immer richtig.
Bei der XGS gibt es zwei Welten:
- Transit-Traffic ist Verkehr, der durch die Firewall fließt (LAN ↔ WAN, VPN ↔ LAN, DMZ ↔ WAN). Dafür sind klassische Firewall Rules gedacht.
- Local Services sind dagegen Dienste, die an der Firewall selbst enden – also genau die Systemservices, die wir hier absichern wollen. Diese steuerst du in der Praxis über Device Access und Local service ACL exception rules.
Wenn man diese Trennung im Kopf hat, wirkt plötzlich vieles “logisch”, was vorher frustrierend war: Eine Geo-Block-Firewall-Regel kann perfekt aussehen – und trotzdem schützt sie deinen WebAdmin auf WAN nicht so, wie du es erwartest, weil du gerade in der falschen Welt konfigurierst.
Das Zielbild, das sich in der Praxis bewährt
In einem sauberen Standard-Setup ist WAN für Systemservices erstmal zu. Das klingt hart, fühlt sich aber sofort gut an, weil du die Oberfläche klein hältst:
Management (WebAdmin/SSH) gehört idealerweise nur ins LAN oder hinter ein VPN. Am besten erfolgt der Zugriff über Sophos Central. Portale und VPN-Dienste bekommen gezielte Ausnahmen.
Und hier kommt der entscheidende Stilwechsel: Statt “ein bisschen blocken” fährst du eine Allow-Logik. Du erlaubst ganz konkret, wer rein darf – und alles andere fällt zuverlässig hinten runter. Das ist weniger fehleranfällig und später viel leichter zu erklären (auch im Team oder gegenüber Kunden).
In diesem Fall wurden explizit Nord Amerika und Australien ausgesperrt, da der Großteil der "angreifenden" IPs aus diesen Weltregionen stammten. Besser wäre es jedoch eine explizite Zulassungsliste zu pflegen.
Umsetzung: Geo-IP für Systemservices – sauber, nachvollziehbar, wartbar
Der angenehmste Weg ist, dir zuerst eine Country Group zu bauen, z. B. DACH oder EU. Damit musst du später nicht in zehn Regeln Länder einzeln pflegen, sondern änderst eine Gruppe und bist fertig.
Danach gehst du zu Device Access und nimmst WAN-Zugriffe raus, wo du sie nicht brauchst. Für viele Umgebungen ist das schon die halbe Miete: WebAdmin und SSH auf WAN sind in den meisten Szenarien einfach überflüssig.
Anschließend baust du für die Dienste, die wirklich extern benötigt werden (klassisch: SSL VPN oder IPsec), eine Local service ACL exception als “Allow”, z. B. “SSL VPN nur aus DACH”. Direkt darunter legst du eine zweite ACL als Drop-Catch-All an (“SSL VPN von überall sonst: Drop”).
Das wirkt erstmal redundant – ist aber genau der Trick, der später Ruhe reinbringt: Du siehst sofort, was erlaubt ist, und du weißt, dass wirklich alles andere blockiert wird.
Weitere Informationen:
Die klassischen Stolperfallen – und wie man sie elegant umschifft
Ein häufiger Grund, warum Country-Blocking “nicht greift”, ist nicht Geo-IP selbst, sondern die Verarbeitungskette. Besonders dann, wenn Webserver über WAF/Hosted Address laufen oder DNAT-Konstrukte im Spiel sind, kann eine vermeintlich passende Firewall Rule wirkungslos sein, weil der Traffic bereits an anderer Stelle behandelt wird.
Die praktische Konsequenz ist simpel:
Wenn du einen Dienst über WAF veröffentlichst, gehören länderspezifische Einschränkungen oft in die WAF-Logik (Blocked Countries) oder werden über passende NAT-/Blackhole-Ansätze gelöst – nicht über eine “normale” Geo-Firewall-Regel.
Und bei Systemservices gilt ohnehin: Wenn es die Firewall selbst ist, dann ist Device Access + Local ACL dein Werkzeugkasten.
Troubleshooting, wenn es nicht so blockt, wie du es erwartest
Wenn Geo-Blocking sich “unzuverlässig” anfühlt, lohnt sich ein sehr kurzer, aber konsequenter Ablauf:
- Trifft die Regel überhaupt? In Sophos ist Reihenfolge und Matching entscheidend. Wenn etwas früher matched, kommt deine Geo-Logik nie dran.
- Sind Pattern Updates aktuell? Geo-IP basiert auf Datenständen – wenn da etwas hängt, wirkt deine Policy “falsch”, obwohl sie formal korrekt ist.
- Ist die IP korrekt klassifiziert? Gerade bei Cloud-Providern, Mobilfunk-Blöcken oder schnell rotierenden Netzen kann Geolocation abweichen. Hier hilft die direkte Prüfung der IP-Zuordnung (und wenn es wirklich falsch ist: sauber dokumentieren und an Sophos weitergeben).
Sophos’ eigene “Blockliste” als Quick-Win gegen unnötige Brute-Forces
Wenn man das VPN-Portal (oder andere WAN-Portale) offen haben muss, landet man schnell in der Realität: Passwort-Sprays und Brute-Force-Wellen kommen in Schüben – mal aus “typischen” Ländern, mal querbeet über Bot-Netze. Geo-IP-Einschränkungen sind dabei ein sehr guter erster Filter, aber sie lösen nicht jeden Fall.
Was viele nicht auf dem Schirm haben: Sophos selbst pflegt in einem Support-KBA eine Liste von auffälligen/quellseitigen IP-Adressen, die im Kontext dieser WAN-Portal-Brute-Forces wiederholt beobachtet wurden – mit dem Hinweis, diese IPs per Local service ACL exception rule zu blocken. Das ist ausdrücklich kein hochwertiger Schutz (die Liste ist naturgemäß nie vollständig und Angreifer wechseln Quellen), aber es ist ein praktischer Lärmreduzierer: Du eliminierst damit oft einen spürbaren Anteil an “Dauerklopfen”, ohne sofort in tägliche Blocklisten-Pflege abzurutschen.
In der Umsetzung passt das sehr gut zu dem Ansatz aus diesem Artikel: Du baust ohnehin Systemservice-Regeln über Device Access / Local Services. Also kannst du Sophos’ IP-Liste einfach als zusätzliche Schicht ergänzen:
Erst legst du die genannten IPs als IP Hosts (oder als Gruppe) an, dann setzt du in Administration > Device access eine Local service ACL exception rule auf Drop – passend für den betroffenen Service (z. B. VPN Portal / User Portal / SSL VPN, je nachdem, was bei dir exponiert ist).
Wichtig ist nur die Erwartungshaltung: Diese Liste ist kein “Schutzschild”, sondern ein Entlastungsmechanismus. Den echten Sicherheitsgewinn holst du weiterhin über Attack-Surface-Reduction (Portal nur wenn nötig, andere Ports/Services auf WAN aus, Allow-Listen, MFA, saubere ACL-Logik). Aber als Ergänzung ist Sophos’ Blockliste oft genau das, was den Alltag ruhiger macht.
Weitere Informationen: