Sophos Firewall: Länder und bösartige IPs blockieren

Sobald Dienste aus dem Internet erreichbar sind, sieht man meist schnell unerwünschten Traffic: Portscans, Login-Versuche, bekannte Bot-Netze oder Zugriffe aus Ländern, aus denen gar keine Benutzer erwartet werden. Auf der Sophos Firewall kann man solche Quellen auf mehreren Ebenen blockieren.

Dieser Artikel erklärt zwei typische Varianten:

• Länder oder Quellnetze mit einer Firewall Regel blockieren
• unerwünschte Quellen mit einer Black Hole DNAT Rule ins Leere übersetzen

Zusätzlich empfehlen wir Sophos Firewall Threat Feeds, damit bekannte bösartige IPs, Domains oder URLs automatisch blockiert werden können.

Orientierung

Bevor man Quellen blockiert, sollte klar sein, welcher Traffic gemeint ist: veröffentlichte Dienste, lokale Firewall-Dienste, ausgehender Client-Traffic oder WAF-Traffic. Die passende Methode hängt genau davon ab.

Welche Methode passt wann?

• Firewall Rule mit Drop: Blockiert Traffic anhand von Source Country, Source Network oder Source Host. Das passt für Ländersperren, einzelne Netze oder manuell gepflegte Bad-IP-Listen.
• Black Hole DNAT: Leitet unerwünschten Traffic auf eine nicht existierende interne IP um. Das ist nützlich, wenn Traffic zu veröffentlichten Diensten früh abgefangen werden soll.
• WAF Blocked countries: Gilt für Webserver, die über WAF veröffentlicht werden. Länder werden direkt in der WAF-Regel blockiert.
• Local service ACL exception rule: Steuert lokale Firewall-Dienste wie WebAdmin, User Portal, VPN Portal oder SSH. Das ist der richtige Ort, wenn die Firewall selbst geschützt werden soll.
• Threat Feeds: Nutzen dynamische Listen bekannter bösartiger Quellen. Das passt für Bot-Netze, Scanner, Malware-Infrastruktur und bekannte Angreifer-IP-Adressen.

Welche Methode sinnvoll ist, hängt davon ab, wo der Traffic technisch verarbeitet wird. Firewall-Regeln greifen nicht in jedem Fall für Traffic, der zu einer in WAF verwendeten Hosted Address geht. In solchen Fällen ist eine WAF-Länderregel oder eine Black Hole DNAT Rule oft besser geeignet.

Eingehend, ausgehend oder lokale Firewall

Vor einer Block-Regel sollte klar sein, welcher Traffic-Typ gemeint ist. Sonst blockiert man an der falschen Stelle und wundert sich später, warum der Angriff weiterhin sichtbar ist oder warum legitimer Traffic ausfällt.

• Eingehend zu veröffentlichtem Server: Zum Beispiel Portweiterleitung auf RDP, HTTPS, SMTP oder eine eigene Applikation. Entscheidend sind DNAT-Reihenfolge, WAF-Regel, Firewall Rule, IPS und Logging.
• Eingehend zur Firewall selbst: Zum Beispiel WebAdmin, User Portal, VPN Portal, SSH, Ping oder DNS auf der Firewall. Hier zählen Device Access und Local Service ACL Exception Rules.
• Ausgehend von internen Clients: Clients sprechen verdächtige Ziele im Internet an. Sinnvolle Kontrollen sind Firewall Rule, Threat Feeds, Web Protection, DNS Protection und Logging.
• Webserver über WAF: Öffentliche Webanwendung hinter Web Server Protection. Die wichtigsten Kontrollen sind WAF-Regel, Blocked countries, Authentifizierung, MFA und WAF-Logs.

Diese Trennung ist wichtig, weil eine Länderregel in Rules and policies > Firewall rules nicht automatisch jede Angriffsfläche der Firewall absichert. Für veröffentlichte Server steht meist die NAT- und WAF-Kette im Vordergrund. Für Admin-Portale zählt zuerst, ob der lokale Firewall-Dienst überhaupt aus der Zone erreichbar ist. Für ausgehenden Client-Traffic sind Threat Feeds, Web Protection und DNS Protection oft die saubereren Werkzeuge.

Nicht mit Device Access verwechseln

Country Blocking und Black Hole DNAT schützen in erster Linie Traffic, der durch Firewall- oder NAT-Regeln verarbeitet wird. Lokale Dienste der Sophos Firewall sind ein anderer Fall. Dazu gehören zum Beispiel WebAdmin, SSH, User Portal, VPN Portal, DNS, Ping und teilweise auch Remote-Access-Dienste.

Für diese lokalen Dienste ist zuerst Administration > Device access relevant. Dort entscheidet man, aus welchen Zonen ein Dienst grundsätzlich erreichbar ist. Wenn ein Zugriff nur für einzelne Admin-IP-Adressen, Länder oder Supportquellen erlaubt werden soll, sind Local service ACL exception rules der richtige Kontrollpunkt. Der Ablauf steht in Sophos Firewall Zugriff absichern: Device Access richtig konfigurieren.

⚠️ Eine Country-Block-Regel ersetzt keine saubere Device-Access-Konfiguration. Wenn WebAdmin, User Portal, VPN Portal oder SSH zu breit erreichbar sind, bleibt die Firewall selbst eine Angriffsfläche. Country Blocking kann das Risiko reduzieren, aber nicht die grundlegende Zugriffshärtung ersetzen.

Für besonders schützenswerte lokale Dienste sollte WAN unter Local service ACL nicht pauschal aktiviert werden. Besser ist eine Exception Rule, die nur die erwarteten Quellen erlaubt oder unerwünschte Länder blockiert. Bei WebAdmin ist eine feste Admin-IP oder ein Management-VPN meist sauberer als ein Länderfilter, weil Geo-IP keine echte Identitätsprüfung ist.

Block-Regeln planen

Länder- und IP-Blocklisten sollten nicht aus Reflex entstehen. Gute Regeln haben einen klaren Zweck, stehen an der richtigen Position und werden später überprüft.

Länder mit einer Firewall Regel blockieren

Für allgemeines Country Blocking kann man eine Firewall Regel mit Drop erstellen.

Menüpfad:

Rules and policies > Firewall rules

Empfohlene Felder:

• Rule name: sprechender Name, zum Beispiel BLOCK_COUNTRY_PANAMA.
• Rule position: Top.
• Action: Drop.
• Source zones: Any.
• Source networks and devices: Land, Ländergruppe, IP-Liste oder Host-Gruppe.
• During scheduled time: All the time.
• Destination zones: Any.
• Destination networks: Any.
• Services: Any oder ein definierter Service.

Für Country Blocking ist wichtig, dass Source zones und Destination zones nicht zu eng gesetzt werden. Wenn man nur WAN als Source zone einträgt, greift die Regel möglicherweise nicht für alle relevanten Traffic-Pfade.

Länder und Ländergruppen werden als Objekte unter Hosts and services verwendet. Für mehrere Länder ist eine Country host group übersichtlicher als viele einzelne Länder direkt in jeder Regel. Bad-IP-Listen gehören dagegen in passende IP-Host- oder IP-Host-Group-Objekte. Dabei muss man die Grenzen kennen: IP-Host-Listen sind nicht für beliebig grosse dynamische Feeds gedacht. Für laufend wechselnde Angreifer-Infrastruktur sind Threat Feeds wartbarer.

Country Blocking sollte ausserdem als Best-Effort-Kontrolle verstanden werden. Geo-IP-Daten können falsch sein, Benutzer reisen, Angreifer verwenden Proxies oder kompromittierte Systeme in erlaubten Ländern, und Cloud-Dienste nutzen weltweit verteilte Infrastruktur. Deshalb sollte eine Länderregel nie die einzige Schutzmassnahme sein.

Wann man nicht zu breit blockieren sollte

Eine Block-Regel ist schnell erstellt, kann aber später schwer nachvollziehbare Nebenwirkungen erzeugen. Besonders vorsichtig sollte man sein, wenn produktive Anwendungen von externen Plattformen, CDNs, Zahlungsanbietern, Cloud-Diensten, Monitoring-Anbietern oder Supportpartnern abhängen.

Vor einer breiten Länder- oder IP-Sperre sollte man deshalb klären:

• Gibt es Benutzer, Partner oder Dienstleister in den betroffenen Ländern?
• Nutzt eine Anwendung Cloud- oder CDN-Infrastruktur mit wechselnden Quelladressen?
• Werden Updates, Webhooks, Monitoring, Backups oder Supportzugriffe über externe Dienste ausgelöst?
• Gibt es eine Möglichkeit, zuerst nur zu loggen oder die Regel zeitlich begrenzt zu testen?
• Ist klar, wer False Positives prüft und wie eine Ausnahme freigegeben wird?

Für Internetdienste mit echter Benutzeranmeldung sind Länderregeln oft nur eine Zusatzmassnahme. MFA, enge Firewall-Regeln, aktuelle Zielsysteme, IPS, WAF-Schutz, Logging und Threat Feeds bleiben wichtiger als eine möglichst lange Sperrliste.

Allowlist vor Blocklist planen

Bei kritischen Diensten ist eine Allowlist oft sauberer als eine immer längere Blocklist. Wenn ein Dienst nur von festen Partnern, Filialen, Monitoring-Systemen oder Admin-Standorten erreichbar sein muss, sollte man zuerst diese Quellen erlauben und den Rest blockieren. Das reduziert Pflegeaufwand und verhindert, dass man reaktiv jede neue Scanner-IP einzeln sperrt.

Eine Allowlist passt besonders gut für:

• Admin-Zugriffe auf veröffentlichte Management-Dienste
• B2B-Schnittstellen mit bekannten Partner-IP-Adressen
• Monitoring, Backup, Webhooks oder API-Endpunkte mit festen Quellsystemen
• temporäre Supportzugriffe mit Ticket, Ablaufdatum und Review

Eine Blocklist passt eher, wenn ein Dienst bewusst öffentlich erreichbar bleiben muss, aber auffällige Quellen reduziert werden sollen. Dann sollte die Regel mit Logging, Review-Datum und klaren Ausnahmen betrieben werden. Für Webserver, die über WAF veröffentlicht werden, ist zusätzlich Sophos Firewall WAF: Webserver sicher veröffentlichen relevant, weil dort Länder, Authentifizierung und Webserver-Schutz näher an der veröffentlichten Anwendung gesteuert werden.

WAF-Länderfilter separat behandeln

Bei Webserver Protection gibt es in der WAF-Regel eigene Felder für Allowed client networks, Blocked client networks, Blocked countries und Block IP addresses of unknown country-origin. Diese Einstellungen gehören zur veröffentlichten Webanwendung und sind nicht dasselbe wie eine normale Firewall-Drop-Regel.

Das ist praktisch, weil der Länderfilter direkt an der WAF-Veröffentlichung hängt. Gleichzeitig muss man vorsichtig sein: Block IP addresses of unknown country-origin kann legitime Benutzer ausschliessen, wenn deren IP-Adresse nicht eindeutig zugeordnet werden kann. Vor der Aktivierung sollte man die eigene externe IP-Adresse mit der GeoIP2 Databases Demo prüfen. Diese Option sollte man nur aktivieren, wenn der Effekt getestet und im Supportprozess bekannt ist.

Für WAF-Regeln gilt: Länderfilter sind nur ein Baustein. Authentifizierung, MFA, Zertifikat, Webserver Protection, IPS/WAF-Signaturen, Logging und ein aktueller Backend-Server bleiben wichtiger als eine lange Liste blockierter Länder.

Black Hole DNAT und Threat Feeds

Bei veröffentlichten Diensten kann es sinnvoll sein, unerwünschte Quellen bereits vor der produktiven DNAT-Regel abzufangen. Für dynamische Angreifer-Infrastruktur sind zusätzlich Threat Feeds hilfreich.

Black Hole DNAT für unerwünschte Quellen

Eine Black Hole DNAT Rule übersetzt Traffic auf ein Ziel, das es im Netzwerk nicht gibt. Der Traffic läuft damit ins Leere und erreicht den eigentlichen Dienst nicht.

Das ist besonders nützlich, wenn ein Dienst per DNAT veröffentlicht wird und man bestimmte Quellen vor der eigentlichen Portweiterleitung abfangen möchte.

Black Hole DNAT sollte gezielt eingesetzt werden. Es eignet sich vor allem für Traffic zu veröffentlichten Diensten, bei denen eine normale DNAT-Regel darunter liegt. Für allgemeinen ausgehenden Client-Traffic, lokale Firewall-Dienste oder Webserver, die über WAF veröffentlicht werden, ist meist eine Firewall Rule, Device Access beziehungsweise eine WAF-Einstellung der bessere Kontrollpunkt.

In der NAT-Regel ist wichtig, dass man die ursprüngliche Sicht des Angreifers und das übersetzte Dummy-Ziel nicht verwechselt. Die Regel gehört in Rules and policies > NAT rules oberhalb der produktiven DNAT-Regel. Original source enthält die gesperrte IP-Liste, das Land oder die Ländergruppe. Original destination ist die öffentliche WAN-Adresse oder das WAN-Host-Objekt, das der Angreifer anspricht. Translated destination ist der nicht geroutete Dummy-Host. Source- und Service-Translation bleiben in diesem Muster normalerweise auf Original.

Nach dem Speichern sollte man im Log Viewer prüfen, ob die erwartete NAT Rule ID getroffen wird. Wenn die normale DNAT-Regel weiterhin matcht, steht die Black-Hole-Regel zu tief, die Source passt nicht oder der angesprochene Service beziehungsweise die Destination stimmt nicht mit dem Testtraffic überein.

Zur Black-Hole-DNAT-Regel gehört weiterhin eine passende Firewall-Regel beziehungsweise ein Logpfad, damit der Treffer nachvollziehbar bleibt. NAT übersetzt nur, es ist keine eigenständige Zugriffserlaubnis. Wenn später niemand mehr weiss, warum der Dummy-Host existiert oder welche Quelle abgefangen wird, wird diese Technik schnell zur Altlast.

Beispiel:

• Rule name: BLOCK_BAD_IPS_COUNTRIES.
• Rule position: Top.
• Original source: Bad-IP-Liste, Land oder Ländergruppe.
• Original destination: öffentliche WAN-IP oder WAN-Host-Objekt.
• Original service: Any oder der veröffentlichte Service.
• Translated source (SNAT): Original.
• Translated destination (DNAT): Dummy-Host, der nicht existiert.
• Translated service (PAT): Original.
• Inbound interface: Any.
• Outbound interface: Any.

Der Dummy-Host sollte eine IP-Adresse verwenden, die im eigenen Netzwerk nicht existiert und nicht geroutet wird. Wichtig ist, dass diese Regel oberhalb der eigentlichen DNAT-Regeln steht. NAT-Regeln werden von oben nach unten verarbeitet. Wenn zuerst die normale DNAT-Regel matcht, kommt die Black Hole DNAT Rule zu spät.

Der Dummy-Host sollte nicht zufällig gewählt werden. Sinnvoll ist eine Adresse aus einem internen, nicht verwendeten Dokumentations- oder Dummy-Netz, das nicht geroutet wird und nicht später für echte Systeme eingeplant ist. Die Regel sollte klar beschreiben, warum dieser Host existiert, damit er nicht versehentlich gelöscht oder produktiv verwendet wird.

Warum die Reihenfolge entscheidend ist

Bei NAT-Regeln gewinnt die erste passende Regel. Eine Black Hole DNAT Rule muss daher sehr weit oben stehen, meist ganz oben in der NAT-Regeltabelle.

Beispielhafte Reihenfolge:

1. Black Hole DNAT für Bad-IP-Liste und gesperrte Länder
2. spezifische DNAT-Regeln für veröffentlichte Dienste
3. spezielle SNAT-Regeln
4. allgemeine MASQ-Regel für ausgehenden Traffic

Bei Firewall Rules gilt dasselbe Prinzip: spezifische Block-Regeln stehen oberhalb allgemeiner Allow-Regeln. Sonst kann es passieren, dass der Traffic bereits erlaubt wurde, bevor die Drop-Regel geprüft wird.

Quelle nicht unnötig auf Any lassen

Bei veröffentlichten Diensten sollte man die Source so weit wie möglich einschränken.

Sinnvolle Quellen können sein:

• einzelne öffentliche IP-Adressen
• Netze von Partnern oder Filialen
• Länder, aus denen der Zugriff erwartet wird
• FQDN Hosts oder DNS Host Groups, wenn passend
• gepflegte Host Groups mit erlaubten Admin-IP-Adressen

Any ist nur dann sinnvoll, wenn der Dienst wirklich weltweit erreichbar sein muss. Dann sollte man zusätzliche Schutzmassnahmen aktivieren: Logging, IPS, MFA wo möglich, starke Authentifizierung, aktuelle Zielsysteme und Threat Feeds.

Für IPv6 muss man separat planen. Eine IPv4-Länderregel beweist nicht, dass dieselbe Anwendung über IPv6 ebenfalls geschützt ist. In Dual-Stack-Umgebungen braucht es passende IPv6-Regeln, Logging und einen Testpfad. Wenn IPv6 nicht produktiv genutzt wird, sollte es bewusst deaktiviert, blockiert oder dokumentiert eingeführt werden.

Threat Feeds zusätzlich verwenden

Manuelle Listen und Länderregeln sind statisch. Angreifer-Infrastruktur ändert sich aber laufend. Darum empfehlen wir zusätzlich Sophos Firewall Threat Feeds.

Threat Feeds helfen besonders bei:

• bekannten Scanner-IP-Adressen
• Bot-Netzen
• Malware-Infrastruktur
• kompromittierten Hosts
• dynamisch gepflegten Bad-IP-Listen

So muss man nicht jede einzelne IP manuell pflegen. Die Firewall kann bekannte schlechte Quellen bereits blockieren, bevor sie den veröffentlichten Dienst erreichen.

Test und Betrieb

Eine Block-Regel ist erst dann sinnvoll, wenn man sie testen, im Log Viewer nachvollziehen und später wieder bewerten kann.

Betrieb und Review von Blocklisten

Blocklisten sind nur dann hilfreich, wenn sie im Betrieb nachvollziehbar bleiben. Eine Länderregel oder Bad-IP-Liste sollte deshalb nicht einfach dauerhaft wachsen, ohne dass jemand die Treffer, Ausnahmen und Nebenwirkungen prüft.

Für jede manuelle Blockliste sollte dokumentiert sein:

• warum die Quelle blockiert wurde
• ob es sich um eine temporäre oder dauerhafte Sperre handelt
• wer die Liste pflegt
• wann die Regel erneut geprüft wird
• welche Dienste oder DNAT-Regeln betroffen sind
• wie ein False Positive freigegeben wird

Gerade bei Cloud-, CDN-, Hosting- oder Support-Netzen sollte man vorsichtig sein. Eine einzelne IP-Adresse kann später einem anderen Kunden gehören, ein CDN-Range kann legitime Dienste enthalten, und ein externer Dienstleister kann seine Ausgangs-IP ändern. Wenn ein legitimer Zugriff blockiert wird, sollte nicht sofort die ganze Regel deaktiviert werden. Besser ist eine enge Ausnahme mit Grund, Ticket und Review-Datum.

Für veröffentlichte Server sollte man zusätzlich prüfen, ob die Blockliste wirklich vor der produktiven DNAT-Regel greift. Der Betriebscheck in Server per DNAT auf Sophos Firewall veröffentlichen hilft dabei, veröffentlichte Dienste, NAT-Regeln und Logging gemeinsam zu bewerten. Wenn blockierte Quellen über eine Firewall-Regel laufen, ist Firewall-Regel testen mit Log Viewer, Policy Test und Packet Capture der passende Testpfad.

Ein sinnvoller Review besteht nicht nur aus einem Blick auf die Regel. Man sollte im Log Viewer prüfen, ob die Regel überhaupt noch trifft, welche Quellen betroffen sind und ob die Treffer zum erwarteten Risiko passen. Für längerfristige Auswertung sind Central Firewall Reporting oder Sophos Firewall Syslog an SIEM senden besser als lokale Logs allein.

Testablauf nach der Änderung

Nach einer neuen Block-Regel sollte nicht nur geprüft werden, ob der unerwünschte Zugriff verschwindet. Wichtig ist auch, ob erwünschter Traffic weiterhin funktioniert und ob die Firewall den Treffer nachvollziehbar protokolliert.

Praktischer Ablauf:

1. Regel mit sprechendem Namen, Logging und enger Beschreibung erstellen.
2. Falls möglich zuerst mit einer kleinen Source-Liste oder einem einzelnen Land testen.
3. Erwarteten Block von einer passenden externen Quelle prüfen.
4. Im Log Viewer nach Source, Destination, Service, Firewall Rule ID und NAT Rule ID filtern.
5. Einen legitimen Zugriff aus einer erlaubten Quelle testen.
6. Bei veröffentlichten Servern prüfen, ob die produktive DNAT-Regel weiterhin für erlaubte Quellen greift.
7. Review-Datum und Owner der Regel dokumentieren.

Wenn kein sauberer Test von aussen möglich ist, sollte die Änderung mindestens mit Log Viewer, Packet Capture und einem engen Wartungsfenster überwacht werden. Eine Block-Regel ohne sichtbare Treffer und ohne Owner ist nach einigen Monaten kaum noch von Altlast zu unterscheiden.

Troubleshooting

Wenn eine Block-Regel nicht greift, sollte man zuerst Reihenfolge, Matching und Logsichtbarkeit prüfen, bevor man weitere Sperren ergänzt.

Typische Fehler

• Black Hole DNAT steht unterhalb der normalen DNAT-Regel: Die normale DNAT-Regel matcht zuerst, die Block-Regel greift nicht.
• Dummy-Ziel existiert doch im Netzwerk: Traffic landet unerwartet auf einem echten System.
• Source wird in NAT und Firewall Rule unterschiedlich gepflegt: Regeln werden schwer nachvollziehbar und driften auseinander.
• Country Blocking wird als einzige Schutzmassnahme verwendet: Bots aus erlaubten Ländern können weiterhin angreifen.
• WAF und DNAT werden vermischt: Eine Firewall-Drop-Regel schützt nicht automatisch jede WAF-Veröffentlichung. WAF Blocked countries separat prüfen.
• Lokale Firewall-Dienste werden mit normalen Firewall-Regeln geschützt: Für WebAdmin, User Portal, VPN Portal und SSH zuerst Device Access und Local Service ACL prüfen.
• IPv6 wird vergessen: Eine IPv4-Regel blockiert keinen IPv6-Pfad.
• Temporäre IP-Sperren werden nie überprüft: Alte Einträge blockieren später legitime Zugriffe oder erzeugen unnötige Komplexität.
• Cloud- oder CDN-Ranges werden zu breit blockiert: Geschäftsanwendungen, Updates oder externe Dienstleister können ausfallen.
• Logging ist deaktiviert: Im Log Viewer ist nicht klar, welche Regel gegriffen hat.

Fehlersuche

Wenn eine Block-Regel nicht greift, sollte man in dieser Reihenfolge prüfen:

1. Steht die NAT- oder Firewall-Regel wirklich oberhalb der Allow-Regeln?
2. Matcht die Source IP zur Bad-IP-Liste oder zum gewählten Land?
3. Wird der Traffic durch eine WAF-Regel, DNAT-Regel oder Firewall Regel verarbeitet?
4. Ist Logging auf der betroffenen Firewall Regel aktiv?
5. Zeigt der Log Viewer die erwartete Firewall Rule ID oder NAT Rule ID?
6. Sieht man den Traffic in Diagnostics > Packet capture?
7. Gibt es eine neuere Ausnahme, Host Group oder Threat-Feed-Exclusion, die den erwarteten Block beeinflusst?
8. Wurde eine temporäre Sperre nach einem Incident dauerhaft stehen gelassen?

Für die Analyse helfen auch Firewall-Regel greift nicht: Reihenfolge, Matching und Logs prüfen, Packet Capture Tool im WebAdmin verwenden und NAT auf Sophos Firewall verstehen: SNAT, DNAT, MASQ, PAT.

Wenn der blockierte Traffic eigentlich zu einem veröffentlichten Server gehört, sollte zusätzlich die produktive DNAT-Regel geprüft werden: Steht die Black-Hole-DNAT-Regel wirklich darüber, wird dieselbe öffentliche Zieladresse getroffen und ist der Service identisch oder bewusst breiter gewählt? Für die komplette Veröffentlichung passt Server per DNAT auf Sophos Firewall veröffentlichen.

FAQ