Geo-Blocking auf der Sophos XGS: sinnvoll einsetzen, ohne dich selbst auszusperren

Geo-Blocking auf der Sophos XGS ist der wahrscheinlich billigste Sicherheitsgewinn, den die Firewall zu bieten hat — die Kurzanleitung passt in drei Sätze: Eingehend auf deine veröffentlichten Dienste darfst du grob sein und den Zugriff auf die Länder beschränken, aus denen dein Geschäft tatsächlich kommt; das eliminiert einen Großteil des automatisierten Angriffs-Grundrauschens mit zwei Handgriffen. Ausgehend gilt das Gegenteil: Hier braucht es Fingerspitzengefühl und vor allem eine Ausnahmenliste, die vor dem Länderfilter greift — denn Microsoft-365-Endpunkte, CDNs und Update-Server halten sich nicht an Landesgrenzen, und wer das ignoriert, debuggt ab Montag jede zweite kaputte Webseite. Und die Grenze der Ehrlichkeit gehört gleich mit dazu: Gegen einen gezielten Angreifer mit VPN ist Geo-Blocking wirkungslos — es ist ein Lärmschutzwall, keine Festungsmauer. Dieser Artikel zeigt Konfiguration, Ausnahmen, den Compliance-Bonus und das Monitoring dazu.

Was Geo-Blocking leistet und was nicht

Fangen wir mit dem Wirkprinzip an: Die XGS pflegt eine GeoIP-Datenbank, die IP-Bereiche Ländern zuordnet, und stellt dir diese Länder als Netzwerkobjekte für Firewall-Regeln zur Verfügung. Eine Geo-Regel ist also nichts Magisches, sondern eine ganz normale Firewall-Regel, deren Quelle oder Ziel ein Länderobjekt ist. Was sie leistet, ist trotzdem beachtlich: Der allergrößte Teil der Angriffe auf exponierte Dienste ist automatisiert — Scanner, Brute-Force-Bots und Exploit-Skripte, die schlicht das gesamte Internet abklappern. Diese Masse kommt messbar konzentriert aus einer Handvoll Regionen, und ein Länderfilter vor deinem VPN-Portal oder OWA sortiert sie aus, bevor auch nur ein Anmeldeversuch stattfindet. Weniger Rauschen bedeutet weniger Last, weniger Log-Müll und deutlich bessere Sicht auf die Versuche, die übrig bleiben.

Und was es nicht leistet: Es ist keine Barriere gegen gezielte Angreifer — wer dich konkret im Visier hat, mietet sich für ein paar Euro einen Server in Frankfurt oder nutzt ein VPN und kommt mit deutscher Absender-IP daher. Auch kompromittierte Rechner in »freundlichen« Ländern laufen unter deren Flagge. Dazu kommt die technische Unschärfe: GeoIP-Datenbanken sind gut, aber nicht perfekt, und Anycast-Netze großer Anbieter melden sich je nach Routing aus wechselnden Regionen. Geo-Blocking ist deshalb eine Schicht in der Verteidigung — eine sehr preiswerte mit hervorragendem Aufwand-Nutzen-Verhältnis, aber eben eine von mehreren, neben MFA, IPS und sauberem Publishing.

Sophos XGS Geo-Blocking konfigurieren: eingehend vs. ausgehend

Die Umsetzung auf der XGS ist erfreulich unspektakulär: Du legst Ländergruppen als Objekte an — etwa eine Gruppe »Erlaubte Herkunft« mit DACH und den EU-Ländern deiner Geschäftsbeziehungen und eine Gruppe »Hochrisiko ausgehend« mit einer kurzen, begründeten Länderliste — und verwendest sie in Firewall-Regeln. Eingehend ist die Logik ein Positivmodell: Die Regeln für deine veröffentlichten Dienste (VPN-Portal, OWA, veröffentlichte Anwendungen hinter der WAF) bekommen als Quelle die erlaubte Ländergruppe; alles andere fällt in die Auffangregel und wird verworfen. Wichtig ist die Entscheidung pro Dienst statt pauschal: Das VPN-Portal für Mitarbeiter verträgt eine engere Länderliste als ein Kundenportal, und der Mailfluss folgt ohnehin eigenen Gesetzen, weil Exchange Online aus Microsofts weltweiten Netzen einliefert.

Ausgehend drehst du das Modell um: Standardmäßig bleibt der Verkehr offen, und du blockst gezielt eine Hochrisiko-Liste — nicht »alles außer EU«, dazu gleich mehr im Ausnahmen-Kapitel. Entscheidend ist dabei die Reihenfolge im Regelwerk, denn die XGS arbeitet Regeln von oben nach unten ab: Ganz oben stehen die Erlauben-Regeln mit FQDN-Gruppen für M365, Update-Dienste und CDN-abhängige Anwendungen, darunter erst die ausgehende Geo-Block-Regel mit aktiviertem Logging, und darunter die normalen Alltagsregeln mit Web-Filter und IPS. Wer die Ausnahmen unter den Geo-Block sortiert, hat sie faktisch nicht — die Länderobjekte gewinnen dann jedes Mal. Die zweite Skizze zeigt die Soll-Reihenfolge für beide Richtungen, die Tabelle darunter die empfohlene Basiskonfiguration.

Skizze 1: Von oben nach unten — Ausnahmen über dem Geo-Block, Geo-Block über den Alltagsregeln, eingehend zum Schluss die Auffangregel.

Ein Wort noch zu Multi-Site-Umgebungen: Die Länder- und Ausnahmengruppen gehören zentral definiert und an allen Standorten identisch verwendet — sonst funktioniert dieselbe Anwendung am Standort Nord und bricht am Standort Süd, und die Fehlersuche wird zur Schnitzeljagd. Wie du Objekte und Regeln standortübergreifend konsistent hältst, ist Kernthema des Multi-Site-Artikels [LINK: A1].

Die Ausnahmen-Falle: M365, CDNs, Updates

Jetzt zum Kapitel, das über Erfolg oder Frust entscheidet. Der Reflex »wir blocken ausgehend einfach alles außer EU und USA« klingt nach konsequenter Härtung — und zerlegt zuverlässig den Alltag. Der Grund: Das moderne Internet ist geographisch gelogen. Content Delivery Networks beantworten Anfragen vom nächstgelegenen oder gerade günstigsten Knoten, und der steht je nach Routing-Wetterlage auch mal in Singapur. Anycast-Adressen großer Anbieter tragen je nach Datenbankstand wechselnde Länderfahnen. Software-Hersteller verteilen Updates über weltweite Spiegelserver, und so manche brave europäische SaaS-Anwendung lädt ihre Login-Maske oder ihre Skripte von einem CDN-Host, der geographisch woanders einsortiert wird. Ein Länderfilter trifft all das mit voller Härte — nur eben nicht die Angreifer.

Die Lösung ist kein Verzicht, sondern Architektur: Ausnahmen werden über FQDN-Hostgruppen gebaut, nicht über Länderfreigaben. Eine Gruppe für die Microsoft-365-Endpunkte, eine für Update-Dienste (Windows Update, Browser-Hersteller, die wichtigsten Software-Lieferanten), eine für geschäftskritische SaaS-Anwendungen — und diese Gruppen bekommen Erlauben-Regeln oberhalb des Geo-Blocks. Der Charme: Du öffnest exakt die benötigten Ziele, egal in welchem Land ihre IPs gerade wohnen, statt ganze Länder freizugeben, weil ein CDN dort einen Knoten hat. Für Microsoft 365 gilt dabei dieselbe Endpunktliste, die auch bei der TLS-Inspection den Ton angibt — wie du sie sauber pflegst und automatisch aktuell hältst, steht im Artikel zur TLS-Inspection [LINK: A7]. Die Weltkarten-Skizze bringt beide Richtungen und die Ausnahmenlogik auf ein Bild.

Skizze 2: Eingehend entscheidet die Herkunft, ausgehend das Ziel — und die grünen Ausnahmen stehen im Regelwerk über dem Länderfilter.

Geo-Blocking und Datenresidenz: der Compliance-Bonus

Neben dem Sicherheitsgewinn hat Geo-Blocking einen zweiten, oft übersehenen Nutzen: Es macht geographische Datenflüsse sichtbar und steuerbar — und das zahlt auf Compliance-Konten ein. Wer ausgehende Verbindungen in definierte Regionen blockt oder zumindest protokolliert, kann zwei Dinge, die im Gespräch mit Datenschutzbeauftragten und Kunden Gold wert sind: erstens belegen, dass unkontrollierter Datenverkehr zu Diensten außerhalb des vorgesehenen Rechtsraums technisch unterbunden wird, und zweitens auffällige Ausreißer erkennen — etwa die Fachabteilungs-Software, die ihre Telemetrie klammheimlich an einen Analytics-Dienst außerhalb der EU schickt. Als flankierende technische Maßnahme im Sinne der Datenschutz-Grundverordnung macht das eine gute Figur.

Die ehrliche Einordnung gehört aber zwingend dazu, bevor jemand das Wort »Nachweis« in eine Präsentation schreibt: Eine Geo-IP-Regel kontrolliert, wohin Pakete fließen — nicht, wo ein Cloud-Anbieter Daten speichert und verarbeitet. Der EU-Endpunkt eines Dienstes sagt nichts darüber, in welcher Region das Backend repliziert; Datenresidenz entscheidet sich beim Anbieter und im Vertrag, die Firewall kann sie nur flankieren. Wer Geo-Blocking als Residenz-Beweis verkauft, betreibt Compliance-Theater. Die ausführliche und ehrliche Einordnung — was Microsofts EU Data Boundary garantiert, wo die Grenzen netzwerkseitiger Kontrolle liegen und wie eine belastbare Nachweisführung aussieht — liefert der Datenresidenz-Artikel [LINK: C7].

Monitoring: was geblockt wird, sichtbar machen

Ein Geo-Filter ohne Blick ins Log ist eine Wette, kein Konzept — das Monitoring gehört deshalb von Anfang an dazu, und zwar mit unterschiedlicher Dosierung je Richtung. Ausgehende Geo-Blocks loggst du ausnahmslos: Diese Treffer sind selten, und jeder einzelne ist interessant — entweder ist es eine fehlende Ausnahme (dann willst du sie schnell finden) oder tatsächlich ein System, das in eine Hochrisiko-Region telefoniert (dann willst du das erst recht wissen). Eingehend ist Augenmaß gefragt: Das WAN-Grundrauschen produziert schnell Zehntausende Blocks am Tag, und wer das vollständig protokolliert, flutet Log-Speicher und Auswertung. Bewährt hat sich, die Geo-Blocks auf die veröffentlichten Dienste zu loggen — dort sind sie aussagekräftig — und die generische Auffangregel nur stichprobenweise oder zeitweise mitzuschreiben.

Für die Auswertung reichen die Bordmittel erstaunlich weit: Der Log Viewer beantwortet die Ad-hoc-Frage »warum geht X nicht«, und die Berichte zeigen Trends nach Ländern, Diensten und Zeitverlauf. Genau diese Berichte sind nebenbei ein unterschätztes Kommunikationswerkzeug Richtung Geschäftsführung — dazu gleich mehr im Praxis-Kasten. Wenn ausgehende Geo-Treffer zusätzlich neben Anmelde- und Endpoint-Ereignissen liegen sollen, ist die Weiterleitung ins SIEM der nächste Schritt; das ist ein eigenes Thema mit eigenem Artikel. Für die tägliche Diagnose gilt der Pfad aus der dritten Skizze: erst der Log Viewer, dann die Zielanalyse, dann die chirurgische FQDN-Ausnahme — und niemals als Abkürzung ein ganzes Land öffnen, weil eine Webseite klemmt.

Skizze 3: Der Diagnose-Pfad bei Geo-Kollateralschäden — vom Log Viewer zur dokumentierten FQDN-Ausnahme, nie zur pauschalen Länderöffnung.

FAQ — häufige Fragen zum Geo-Blocking auf der Sophos XGS

Bringt Geo-Blocking überhaupt etwas gegen VPN-nutzende Angreifer?

Gegen den einzelnen, gezielten Angreifer mit VPN oder gemietetem Server im erlaubten Land: nein, und jede andere Antwort wäre gelogen. Der Wert liegt woanders — in der Masse. Der Löwenanteil der Angriffe auf exponierte Dienste ist automatisiert und kommt konzentriert aus wenigen Regionen; ein Länderfilter sortiert dieses Grundrauschen aus, bevor ein einziger Anmeldeversuch stattfindet. Das entlastet die Systeme, hält die Logs lesbar und lässt die verbleibenden, potenziell gezielten Versuche überhaupt erst auffallen. Geo-Blocking ist damit eine Filterschicht mit hervorragendem Aufwand-Nutzen-Verhältnis — aber eben eine Schicht: Gegen die Klasse der Angriffe helfen MFA, gehärtetes Publishing und IPS, nicht die Landesflagge der Absender-IP.

Blockt Geo-Blocking auch Microsoft-365-Traffic?

Es kann — und zwar genau dann, wenn ausgehende Länderfilter ohne saubere Ausnahmen gebaut wurden. Microsoft betreibt seine Endpunkte und Content-Netze weltweit und arbeitet vielfach mit Anycast-Adressen, deren Länderzuordnung in GeoIP-Datenbanken wechseln kann; ein pauschaler Block auf Nicht-EU-Ziele trifft dann früher oder später auch M365-Verkehr, gern zuerst bei Teams. Die Lösung ist immer dieselbe: Die Microsoft-365-Endpunkte als FQDN-Gruppen fassen und mit einer Erlauben-Regel oberhalb des Geo-Blocks freigeben — nie über Länderfreigaben. Praktischerweise ist das dieselbe Endpunktliste, die auch für die TLS-Inspection-Ausnahmen gebraucht wird; einmal sauber gepflegt, bedient sie beide Baustellen.

Sollte ich eingehend alles außer DACH blocken?

Als Ausgangspunkt für Verwaltungszugänge und das Mitarbeiter-VPN: ja, das ist ein völlig legitimer und wirksamer Standard. Als Pauschalregel für alles Eingehende: nein — die Entscheidung gehört pro Dienst getroffen. Ein Kundenportal braucht die Länder deiner Kunden, veröffentlichte Anwendungen die deiner Partner und Dienstleister, und der Mailfluss folgt eigenen Regeln, weil Exchange Online aus Microsofts weltweiten Netzen einliefert — dort beschränkst du besser auf die Quell-Netze des Dienstes statt auf Länder. Und denk den Reisefall mit: Der Kollege im Auslandsurlaub, der »nur kurz ins VPN« will, ist der häufigste Selbst-Aussperr-Klassiker. Definiere vorher, wie damit umgegangen wird — temporäre Freigabe auf Zuruf, dokumentierter Prozess — statt es am Feiertag zu improvisieren.

Warum funktionieren manche Webseiten nach Aktivierung nicht mehr?

Fast immer aus demselben Grund: Die Seite selbst wohnt im erlaubten Raum, aber Teile von ihr kommen woanders her. Moderne Webseiten laden Schriften, Skripte, Bilder und Videos von CDN-Knoten, die geographisch dort antworten, wo das Routing sie gerade hinführt — und schon blockt deine ausgehende Geo-Regel die halbe Seite, während die Grundseite lädt und alles kaputt aussieht. Auch SaaS-Anwendungen mit europäischer Datenhaltung liefern Login und Assets gern über globale CDNs aus. Der Diagnoseweg: Log Viewer öffnen, den Drop der Geo-Regel finden, Ziel-Host identifizieren — und dann eine gezielte FQDN-Ausnahme oberhalb des Geo-Blocks setzen. Was du dir verkneifst: das betroffene Land komplett zu öffnen. Damit hebelst du den Filter aus, statt ihn zu pflegen.

Ist Geo-Blocking DSGVO-relevant?

In zwei Richtungen, beide unaufgeregt. Erstens als Plus: Geo-Blocking ist eine klassische technische Maßnahme zur Angriffsflächen-Reduktion und kann als Baustein der nach Artikel 32 geforderten Sicherheit der Verarbeitung dokumentiert werden; ausgehende Filter flankieren zudem eine EU-orientierte Datenhaltung, ohne sie zu beweisen. Zweitens als Pflicht: Die Geo-Entscheidung basiert auf IP-Adressen, und die landen samt Blockereignis in den Firewall-Logs — damit gelten dieselben Spielregeln wie für jede Firewall-Protokollierung: Rechtsgrundlage, angemessene Aufbewahrungsfristen, geregelter Zugriff. Neue Datenkategorien entstehen durch Geo-Blocking nicht; es verarbeitet, was die Firewall ohnehin sieht. Kurz: datenschutzrechtlich eher ein Aktivposten — solange das Logging-Konzept insgesamt sauber aufgesetzt ist.

Wie logge ich Geo-Blocks sinnvoll?

Mit unterschiedlicher Dosierung je Richtung. Ausgehende Geo-Blocks: immer und vollständig loggen — diese Ereignisse sind selten und jedes einzelne ist entweder eine fehlende Ausnahme oder ein System mit erklärungsbedürftigem Kommunikationsziel; beides willst du zeitnah sehen. Eingehend: gezielt statt vollständig — Logging auf den Geo-Regeln der veröffentlichten Dienste liefert aussagekräftige Berichte, während das Vollprotokoll der generischen Auffangregel nur das WAN-Grundrauschen konserviert und Speicher wie Aufmerksamkeit flutet; dort reichen Stichproben oder zeitlich begrenzte Aufzeichnung. Für die Auswertung genügen zunächst Log Viewer und die Berichte der XGS — der Monatsreport nach Herkunftsländern ist nebenbei hervorragendes Anschauungsmaterial für die Geschäftsführung. Und bei jeder Verschärfung gilt: erst eine Woche Nur-Loggen, dann scharf schalten.

Fazit: Grobes Sieb eingehend, Skalpell ausgehend

Geo-Blocking auf der XGS ist der seltene Fall einer Sicherheitsmaßnahme, die wenig kostet, sofort wirkt und trotzdem ehrlich bleiben muss: Eingehend darfst du mit dem groben Sieb arbeiten — Länderfilter vor VPN-Portal, OWA und Verwaltungszugängen eliminieren das automatisierte Grundrauschen fast nebenbei. Ausgehend regiert das Skalpell: kurze Hochrisiko-Liste, FQDN-Ausnahmen für M365, CDNs und Updates konsequent oberhalb des Blocks, jede Ausnahme dokumentiert, jeder ausgehende Treffer geloggt. Dazu die realistische Erwartung — Lärmschutzwall, keine Festungsmauer — und ein Monitoring, das aus Blockzahlen Erkenntnisse macht. So konfiguriert ist Geo-Blocking der Quick-Win, als der es gehandelt wird; anders konfiguriert ist es die Quelle der seltsamsten Tickets des Jahres.

Von hier aus weiter im Cluster: Das Gesamtbild der XGS in Microsoft-Umgebungen liefert der Pillar-Artikel [LINK: Pillar]. Warum die M365-Endpunktlisten auch jenseits des Geo-Blockings dein Freund sind — Stichwort TLS-Inspection-Ausnahmen — zeigt [LINK: A7]. Die ehrliche Einordnung, was Firewall-Maßnahmen zur Datenresidenz beitragen können und was nicht, liefert [LINK: C7]. Und wie Länder- und Ausnahmenobjekte über mehrere Standorte konsistent bleiben, ist Thema des Multi-Site-Artikels [LINK: A1].