Server per DNAT auf Sophos Firewall veröffentlichen

Mit DNAT veröffentlicht man einen internen Server über eine öffentliche IP-Adresse oder einen öffentlichen Port. Die Sophos Firewall leitet eingehenden Traffic dann an den internen Zielserver weiter. Typische Beispiele sind Webserver, Reverse Proxies, VPN Gateways oder andere Dienste in einer DMZ.

Für den übergeordneten Hardening-Kontext passt der Hub Sophos Firewall Hardening: Best Practices für eine sichere Konfiguration.

Der Artikel erklärt, welche Punkte man vor und nach einer DNAT-Regel prüfen sollte und wie man die Freigabe möglichst eng absichert.

Planung vor der Veröffentlichung

Vor einer DNAT-Freigabe sollte klar sein, ob der Dienst wirklich öffentlich erreichbar sein muss und welche technische Variante am besten passt. Eine gute Planung verhindert offene Ports, doppelte NAT-Regeln und schwer nachvollziehbare Rückwege.

Voraussetzungen

• Öffentliche IP-Adresse oder WAN-Schnittstelle
• Interner Server mit fester IP-Adresse
• Bekannter Dienst und Port, zum Beispiel TCP 443
• Passende Firewall-Regel
• Optional: IPS, Webserver Protection oder Reverse Proxy je nach Dienst

⚠️ DNAT veröffentlicht einen internen Dienst nach aussen. Jeder veröffentlichte Dienst erhöht die Angriffsfläche. Es sollte nur veröffentlicht werden, was wirklich nötig ist. Quelle, Port und Ziel sollten möglichst eng begrenzt sein.

Vorab klären

Vor der Regelanlage sollte man diese Fragen beantworten:

• Welche öffentliche IP oder WAN-Schnittstelle wird verwendet?
• Welcher externe Port soll erreichbar sein?
• Auf welche interne IP wird weitergeleitet?
• Bleibt der Port gleich oder wird er übersetzt?
• Soll der Zugriff von überall oder nur von bestimmten Quellnetzen erlaubt sein?
• Muss Source NAT oder Reflexive NAT beachtet werden?
• Braucht es eine Loopback-Regel für interne Clients, die den öffentlichen FQDN verwenden?
• Wird nur ein interner Server veröffentlicht oder mehrere Server mit Load Balancing?
• Gibt es bereits eine Regel, die denselben Port verwendet?
• Befindet sich die Sophos Firewall direkt am Internet oder hinter einem Provider-Router?
• Müssen zusätzlich Regeln in einer Cloud Security Group geöffnet werden?

Diese Informationen verhindern spätere Konflikte mit bestehenden NAT- oder Firewall-Regeln.

Wenn die Begriffe Original source, Original destination, Translated destination, Translated service, Loopback oder Reflexive Rule noch unklar sind, sollte zuerst NAT auf Sophos Firewall verstehen: SNAT, DNAT, MASQ, PAT gelesen werden. Diese Seite hier konzentriert sich auf die konkrete Veröffentlichung eines internen Dienstes.

DNAT, WAF, VPN oder ZTNA?

Nicht jeder öffentlich erreichbare Dienst sollte automatisch per DNAT veröffentlicht werden. DNAT ist technisch einfach, aber auch sehr direkt: Die Firewall leitet einen Port an ein internes Ziel weiter. Ob das sinnvoll ist, hängt vom Dienst, von den Quellen und vom Schutzbedarf ab.

• Nicht-HTTP-Dienst mit klar definierten Quellen: DNAT mit enger Source-Einschränkung, Logging und IPS kann passen.
• Öffentliche HTTP- oder HTTPS-Anwendung: Zuerst Sophos Firewall WAF prüfen.
• Adminzugriff wie SSH oder RDP: Für einzelne feste Ziele Clientless SSL VPN, sonst VPN, ZTNA oder eine feste Quell-IP statt offenem DNAT verwenden.
• Zugriff nur für wenige Partner oder Standorte: Quell-IP, VPN oder Site-to-Site-Verbindung bevorzugen.
• Anwendung soll intern und extern unter demselben Namen erreichbar sein: Split DNS oder bewusst geplante Loopback-Regel prüfen.

Für klassische Webanwendungen ist WAF häufig der bessere Startpunkt, weil Hostnamen, Zertifikate, Pfade, Web-Schutzprofile und optional Authentifizierung berücksichtigt werden können. Für administrative Zugriffe sollte DNAT nur in Ausnahmefällen verwendet werden. Wenn ein interner Dienst nicht wirklich öffentlich sein muss, sind VPN oder eine ZTNA-Architektur meistens die sauberere Lösung. Die bestehenden ZTNA-Grundlagen stehen in Wie man Sophos ZTNA einrichtet und Sophos ZTNA Gateway erstellen.

Wenn die Firewall hinter einem Router steht

DNAT funktioniert auch, wenn die Sophos Firewall nicht direkt die öffentliche IP-Adresse besitzt, sondern hinter einem NAT-Router des Providers steht.

In diesem Fall braucht es zwei Weiterleitungen:

1. Auf dem Provider-Router wird der öffentliche Port an die WAN-IP der Sophos Firewall weitergeleitet.
2. Auf der Sophos Firewall wird der Port per DNAT an den internen Server weitergeleitet.

Viele Provider-Router bieten dafür klassische Portweiterleitungen oder eine Funktion wie Exposed Host beziehungsweise DMZ Host. Bei einer Exposed-Host-Funktion werden häufig sehr viele oder alle eingehenden Ports an die Firewall weitergeleitet. Das kann praktisch sein, sollte aber bewusst abgesichert werden, weil die eigentliche Kontrolle dann vollständig auf der Sophos Firewall liegt.

Wenn keine fixe öffentliche IP vorhanden ist, kann man Dynamic DNS auf der Sophos Firewall einrichten und extern prüfen. Wichtig bleibt: Die Portweiterleitung auf dem Provider-Router muss auf die Sophos Firewall zeigen.

Bei einer zusätzlichen öffentlichen IPv4-Adresse auf einem direkt angeschlossenen WAN-Segment kann noch die vorgelagerte ARP-Auflösung fehlen. Erst wenn ein Capture die Anfrage und den fehlenden Firewall-Reply belegt, passt der separate Ablauf Proxy ARP auf Sophos Firewall konfigurieren; DNAT benötigt diesen manuellen Schritt nicht pauschal.

In Cloud Umgebungen gilt dasselbe Prinzip. Bei Azure reicht die DNAT-Regel auf der Sophos Firewall allein nicht aus. Zusätzlich müssen die passenden Inbound rules in der Network Security Group geöffnet werden, sonst erreicht der Traffic die Firewall gar nicht.

DNAT und Firewall-Regel konfigurieren

Eine Server-Veröffentlichung besteht immer aus zwei Teilen: Die NAT-Regel übersetzt Ziel oder Port, die Firewall-Regel erlaubt und kontrolliert den Traffic.

Server Access Assistant oder manuelle DNAT-Regel?

Sophos Firewall bietet für Serververöffentlichungen zwei Wege:

• Server access assistant (DNAT): Passt als schneller Standardfall für eine einzelne Veröffentlichung. Der Assistent erstellt mehrere Regeln automatisch und setzt sie oben in die Regelbasis.
• Manuelle DNAT-Regel: Passt für komplexere Umgebungen mit Alias-IP, PAT, Load Balancing, speziellen Quellen oder bewusstem Regel-Design. Jedes Feld muss selbst gesetzt und getestet werden.

Der Assistent kann hilfreich sein, weil er nicht nur eine eingehende DNAT-Regel erzeugt, sondern je nach Auswahl auch eine Loopback-Regel, eine reflexive SNAT-Regel und die passende Firewall-Regel anlegt. Das spart Zeit, ist aber kein Ersatz für eine Prüfung der erzeugten Regeln.

⚠️ Für denselben DNS-Host-Eintrag lassen sich DNAT und Weighted Load Balancing nicht gleichzeitig konfigurieren. Wenn dieser DNS-Host bereits für eine gewichtete Verteilung verwendet wird, muss das Design vor der Veröffentlichung getrennt geplant werden; der Assistent verbindet beide Funktionen nicht zu einer gemeinsamen Regel.

Server Access Assistant verwenden

Der Assistent ist der schnellste Weg zu einer ersten Veröffentlichung. Er ist besonders nützlich, wenn ein einzelner interner Server über eine WAN-Adresse und einen klaren Service erreichbar werden soll.

Benötigte eigene Service-Objekte muss man vor dem Start erstellen. Die Auswahl unter Services legt noch keine Portübersetzung fest: In der erzeugten DNAT-Regel stehen Translated source (SNAT) und Translated service (PAT) zunächst auf Original. Für PAT bearbeitet man die erzeugte NAT-Regel nach dem Speichern und prüft die PAT-Felder sowie die passende Firewall-Regel. Nach der Änderung müssen deren Services und übrige Match-Kriterien wieder zur NAT-Regel passen. Eine eingetragene öffentliche IP unter WAN IP address setzt Inbound interface der erzeugten DNAT-Regel auf Any; das ist nicht dasselbe wie die bewusste Auswahl eines WAN-Interfaces. Externe Quellen nicht nur für eine automatische Loopback-Regel auf Any erweitern.

Bei einer Alias-IP als Original destination verwendet der Assistent in den erzeugten SNAT- und Loopback-Regeln die zugrunde liegende physische Schnittstelle als Translated source, nicht automatisch die Alias-IP. Soll diese Alias-IP die übersetzte Quelle sein, erstellt man einen IP-Host für den Alias und wählt ihn in den betroffenen erzeugten Regeln manuell als Translated source aus. Das ist keine pauschale SNAT-Vorgabe für jede Veröffentlichung; die Einschränkung eingehender Quellen bleibt bestehen. Nach dem Speichern die erzeugten Regel-IDs und den tatsächlichen Wert von Translated source kontrollieren, die benötigten Loopback- und vom Server gestarteten Pfade mit neuen Sessions auf die erwarteten Quelladressen prüfen und nach Änderungen die Firewall-Kriterien passend halten.

Vorgehen:

1. Rules and policies > NAT rules öffnen.
2. IPv4 oder IPv6 auswählen.
3. Add NAT rule > Server access assistant (DNAT) auswählen. Alternativ kann man den Assistenten auch unter Rules and policies > Firewall rules > Add firewall rule starten.
4. Unter Internal server IP address den internen Server auswählen oder eine IP-Adresse eintragen.
5. Unter WAN IP address das WAN-Interface oder die öffentliche IP-Adresse auswählen.
6. Unter Services den internen Dienst auswählen, zum Beispiel HTTPS.
7. Unter External source networks and devices die erlaubten Quellen setzen. Für öffentliche Dienste ist Any nur dann passend, wenn der Dienst wirklich aus dem gesamten Internet erreichbar sein muss.
8. ⚠️ Save and finish aktiviert die erzeugten Regeln sofort und setzt sie an die Spitze beider Tabellen: NAT und Firewall. Deshalb zuerst die Go-live-Vorbereitung abschliessen: öffentliches Ziel, erlaubte Quellen, Services, Regelkonflikte und Reihenfolge sowie den dokumentierten Rollback-Umfang bestätigen. Erst danach Einstellungen und Regeln prüfen und mit Save and finish speichern.

Nach dieser Vorabprüfung gehört auch nach dem Speichern ein Review dazu: erzeugte Regeln und IDs erfassen, ihre tatsächliche Reihenfolge in beiden Tabellen prüfen und bei Bedarf bewusst anpassen. Die benötigten Pfade anschliessend mit neuen Sessions validieren. Eine automatisch erzeugte Regel kann technisch funktionieren und trotzdem zu breit, zu hoch platziert oder für den Betrieb schlecht benannt sein.

Damit der Assistent automatisch eine Loopback-Regel erzeugt, müssen zwei Bedingungen erfüllt sein: Als WAN-Ziel muss ein Firewall-Interface ausgewählt und External source networks and devices auf Any gesetzt sein. Bei einer eingetragenen öffentlichen IP-Adresse oder eingeschränkten externen Quellen erzeugt der Assistent keine Loopback-Regel. In vielen Umgebungen ist Split DNS ohnehin übersichtlicher als Loopback NAT.

Nach der Verwendung des Assistenten sollte man immer kontrollieren:

• Sind NAT- und Firewall-Regel an der richtigen Position?
• Ist die Source wirklich so eng wie geplant oder steht sie noch auf Any?
• Wurde eine Loopback-Regel erzeugt, obwohl Split DNS die sauberere Lösung wäre?
• Wurde eine reflexive Regel erzeugt, die für ausgehenden Server-Traffic gar nicht benötigt wird?
• Passt die Firewall-Regel zur Zielzone nach NAT und zum öffentlichen Zielobjekt vor NAT?

Für produktive Umgebungen ist oft eine manuell benannte und bewusst platzierte DNAT-Regel besser nachvollziehbar. Der Assistent ist gut für einen schnellen Start, aber die erzeugten Regeln gehören danach in denselben Review wie manuell erstellte Regeln.

DNAT-Regel erstellen

Ein typisches manuelles DNAT-Beispiel veröffentlicht extern TCP 443 auf einen internen Webserver in der DMZ. Die Regel übersetzt nur Zieladresse und optional Zielport. Eine Firewall-Regel wird dadurch nicht ersetzt.

Vorgehen:

1. Rules and policies > NAT rules öffnen.
2. IPv4 oder IPv6 auswählen.
3. Add NAT rule > New NAT rule auswählen.
4. Rule name sprechend setzen, zum Beispiel DNAT_WEB_DMZ_HTTPS.
5. Rule position so wählen, dass spezifische DNAT-Regeln vor allgemeinen Regeln stehen.
6. Original source auf erlaubte externe Quellen setzen. Nur bei bewusst öffentlichen Diensten Any verwenden.
7. Original destination auf das WAN-Host-Objekt, die öffentliche IP oder das passende WAN-Interface setzen.
8. Original service auf den extern erreichbaren Service setzen, zum Beispiel HTTPS.
9. Translated destination (DNAT) auf den internen Server oder die Servergruppe setzen.
10. Translated service (PAT) auf Original lassen oder den internen Zielport setzen, wenn Port Forwarding nötig ist.
11. Inbound interface bewusst setzen. Bei Internetzugriff ist das üblicherweise das WAN-Interface; bei Sonderfällen kann Any nötig sein.
12. Outbound interface bei DNAT auf interne Server normalerweise auf Any lassen, damit Routing und Zielzone sauber greifen.
13. Loopback, reflexive rule, Load balancing und Health check nur aktivieren, wenn sie fachlich gebraucht werden.
14. Regel speichern und aktivieren.

Wenn nur wenige externe Quell-IP-Adressen zugreifen müssen, sollte die Original Source nicht Any sein, sondern auf diese Quellen beschränkt werden.

Bei produktiven Freigaben ist ein Host-Objekt für die öffentliche IP meist sauberer als die direkte Auswahl eines WAN-Interfaces. Das Objekt bleibt nachvollziehbar, wenn sich Interfaces, Alias-Adressen oder Provider-Details später ändern.

Original und Translated richtig verstehen

Bei NAT-Regeln ist die Unterscheidung zwischen Original und Translated wichtig.

• Original source / destination / service beschreibt den Traffic, wie er bei der Sophos Firewall ankommt.
• Translated source / destination / service beschreibt den Traffic, wie er die Sophos Firewall nach der Übersetzung wieder verlässt.

Für eine eingehende DNAT-Regel bedeutet das:

• Original destination ist die öffentliche IP oder WAN-Adresse der Firewall.
• Original service ist der externe Port, den der Client anspricht.
• Translated destination (DNAT) ist der interne Server.
• Translated service (PAT) ist der interne Port auf dem Zielserver, falls der Port übersetzt werden soll.
• Translated source (SNAT) bleibt bei normalen DNAT-Regeln meistens auf Original.

Port Forwarding und PAT

Port Forwarding ist technisch eine Service-Translation. Auf der Sophos Firewall wird dafür Translated service (PAT) verwendet.

Beispiel:

• Extern: TCP 20120
• Intern: TCP 22

Der externe Client verbindet sich auf Port 20120, die Sophos Firewall leitet intern aber auf SSH-Port 22 weiter. Das kann sinnvoll sein, ersetzt aber keine Zugriffsbeschränkung. Ein geänderter externer Port reduziert vielleicht etwas Hintergrundrauschen, macht einen Dienst aber nicht sicher.

Wichtig: Das Protokoll muss gleich bleiben. TCP kann auf einen anderen TCP-Port übersetzt werden, UDP auf einen anderen UDP-Port. TCP zu UDP ist keine gültige Portübersetzung.

Wenn HTTPS veröffentlicht wird, muss man zuerst unter Administration > Admin and user settings die tatsächlich konfigurierten Ports von WebAdmin, User Portal und VPN Portal erfassen. Ältere NAT-Beispiele nennen 4444 für WebAdmin und 443 für User Portal; das bestätigt nicht die Portbelegung des installierten Builds oder der eigenen Konfiguration. Konflikte möglichst mit einer anderen veröffentlichten IP oder einem anderen externen Dienstport lösen. Managementports nicht als Diagnose-Abkürzung ändern; falls eine Änderung nötig ist, vorher einen unabhängigen Managementzugang sichern und anschliessend Portale, VPN-Clients und den externen DNAT-Zugriff getrennt prüfen.

Quell-IP und Rückweg bewusst planen

Bei einer normalen DNAT-Veröffentlichung sollte Translated source (SNAT) meistens auf Original bleiben. Dann sieht der interne Server die echte externe Quell-IP. Das ist wichtig für Server-Logs, Rate Limits, Fail2Ban-ähnliche Schutzmechanismen, Applikationslogs, WAF- oder Reverse-Proxy-Auswertung und spätere Incident-Analyse.

SNAT auf die Firewall oder eine interne Adresse kann trotzdem nötig sein, wenn der Rückweg sonst nicht über die Sophos Firewall läuft. Das ist zum Beispiel möglich, wenn der veröffentlichte Server ein anderes Default Gateway verwendet, in einem fremden Routingsegment steht oder eine asymmetrische Routing-Situation besteht.

Die Entscheidung sollte bewusst getroffen werden:

• Source bleibt Original: Der Server sieht die echte externe IP. Dafür muss der Rückweg sauber über die Firewall laufen.
• Source wird per SNAT übersetzt: Der Rückweg ist einfacher kontrollierbar. Dafür sieht der Server nur die Firewall- oder SNAT-IP, und die echte Client-IP geht im Serverlog verloren.

Wenn ein Dienst nur mit SNAT funktioniert, sollte man nicht sofort dabei bleiben und das Thema abhaken. Besser ist zuerst zu prüfen, ob Gateway, Route, VLAN, Server-Firewall oder Routingdesign korrigiert werden können. SNAT kann ein legitimer Workaround sein, macht spätere Analysen aber schwerer.

Beim Test sollte deshalb immer kontrolliert werden, welche Source-IP der Server tatsächlich sieht. Wenn statt der externen Client-IP nur die Firewall-IP auftaucht, muss klar dokumentiert sein, ob das Absicht ist.

Firewall-Regel prüfen

Eine NAT-Regel allein erlaubt den Traffic nicht automatisch. Zusätzlich braucht es eine passende Firewall-Regel.

Bei DNAT ist die Sicht in der Firewall-Regel ungewohnt, weil die Firewall gleichzeitig den ursprünglichen Zugriff von aussen und das übersetzte interne Ziel kennen muss.

Die wichtigste Faustregel:

⚠️ Bei DNAT verwendet die Firewall-Regel die Zielzone nach NAT, aber das Zielnetzwerk vor NAT.

Der Ablauf ist wichtig: Bei eingehendem Traffic sucht Sophos Firewall zuerst die passende DNAT-Regel und bestimmt dadurch das übersetzte Ziel. Danach wird die Firewall-Regel gematcht. Für die Destination zone verwendet die Firewall die Zone, in der das übersetzte Ziel liegt. Für Destination networks bleibt aber das ursprüngliche Zielobjekt aus der DNAT-Regel relevant.

Typische Zuordnung:

• Source zone: Meist WAN, wenn der Zugriff aus dem Internet kommt.
• Source networks and devices: Möglichst eingeschränkt, zum Beispiel einzelne IPs, Netze, Länder oder Gruppen.
• Destination zones: Zone des internen Servers nach DNAT, zum Beispiel DMZ oder SERVER.
• Destination networks: Öffentliche Zieladresse beziehungsweise WAN-Host-Objekt aus Original destination.
• Services: Ohne PAT genügt der Service aus Original service. Bei einer Portübersetzung gehören der externe Original-Service und der interne Service aus Translated service in die Firewall-Regel. Im Beispiel TCP 20120 auf TCP 22 müssen deshalb beide Service-Objekte ausgewählt sein.
• Security Profile: Je nach Dienst IPS, Malware Scan, Web Policy oder andere passende Prüfung.
• Logging: Für veröffentlichte Dienste aktivieren.

Ohne passende Firewall-Regel wird der Traffic trotz DNAT verworfen.

Dieser Punkt ist eine häufige Fehlerquelle: Wenn man als Destination network den internen Server einträgt, obwohl die Regel das öffentliche WAN-Objekt erwartet, matcht die Regel nicht. Die genaue Logik wird im Artikel NAT auf Sophos Firewall verstehen: SNAT, DNAT, MASQ, PAT ausführlicher eingeordnet.

Auch bei NAT-Regeln gilt die Reihenfolge. Sophos prüft NAT-Regeln von oben nach unten und verwendet die erste passende Regel. Eine zu allgemeine NAT-Regel oberhalb kann deshalb verhindern, dass die spezifische DNAT-Regel greift.

Bereits bestehende Verbindungen behalten ihre NAT-Übersetzung, auch wenn man die NAT-Regel nachträglich ändert. Für Tests nach einer Änderung sollte man deshalb neue Sessions erzeugen oder alte Verbindungen sauber beenden, sonst bewertet man möglicherweise noch einen alten Zustand.

Erweiterte NAT-Optionen

Diese Optionen werden erst relevant, wenn interne Clients öffentliche Namen verwenden, Rückwege speziell übersetzt werden müssen oder mehrere Zielserver beteiligt sind.

Loopback, Reflexive und Linked NAT Rules

Die Sophos Firewall bietet mehrere NAT-Optionen, die leicht verwechselt werden:

• Loopback rule: Hilft, wenn interne Clients einen internen Server über die öffentliche IP oder den öffentlichen DNS-Namen erreichen sollen.
• Reflexive rule: Erstellt eine spiegelnde SNAT-Regel für neue, vom veröffentlichten Server ausgehende Verbindungen. Sie ist nicht für die zustandsbehafteten Antwortpakete einer eingehenden DNAT-Session nötig.
• Linked NAT rule: Wird aus einer Firewall-Regel heraus erstellt und ist eine verknüpfte SNAT-Regel. Eine Linked NAT Rule ist nicht dasselbe wie eine eingehende DNAT-Regel für einen veröffentlichten Server.

Auch diese NAT-Regeln erteilen keine Zugriffsberechtigung. Für benötigten Loopback-Zugriff prüft man unter Rules and policies > Firewall rules eine vorhandene, ausreichend eng begrenzte Regel oder erstellt bei Bedarf eine passende Regel:

• Source zones: Tatsächliche Client-Zone, zum Beispiel LAN.
• Source networks and devices: Nur das benötigte interne Client-Subnetz.
• Destination zones: Zone des übersetzten Servers, zum Beispiel DMZ.
• Destination networks: Ursprüngliches öffentliches Ziel aus Original destination, nicht die interne Server-IP.
• Services: Bei PAT beide Service-Objekte aus Original service und Translated service (PAT); im vorhandenen Beispiel TCP 20120 und TCP 22.

Für neue ausgehende Verbindungen, die der Server unabhängig von eingehenden DNAT-Sessions startet, muss die Firewall-Regel unter Source zones die tatsächliche Server-Zone und unter Source networks and devices die interne Server-IP oder Server-IP-Liste erlauben. Destination zones, Destination networks und Services auf die benötigten Ziele und Dienste begrenzen, statt pauschal Any zu übernehmen. Eine ausreichend eng begrenzte vorhandene Regel kann genügen; eine neue Regel ist nicht immer nötig. Zustandsbehaftete Antworten auf eingehende DNAT-Sessions benötigen weder eine reflexive NAT-Regel noch eine neue ausgehende Freigabe. NAT-Reihenfolge und Rückweg separat prüfen, Logging aktivieren und die benötigten internen und serverseitig gestarteten Pfade jeweils mit neuen Sessions testen.

Für klassische Server-Veröffentlichungen ist meist eine eigenständige DNAT-Regel plus passende Firewall-Regel am übersichtlichsten. Linked NAT Rules können sinnvoll sein, wenn eine Firewall-Regel direkt eine spezielle SNAT-Übersetzung benötigt. In allgemeinen Umgebungen bleiben eigenständige, klar benannte NAT-Regeln jedoch meistens einfacher zu verstehen und zu warten.

Wichtig: Loopback- und reflexive Regeln werden aus der ursprünglichen DNAT-Regel abgeleitet. Wenn die ursprüngliche DNAT-Regel später geändert wird, sollte man die abgeleiteten Regeln separat prüfen. Sonst kann es passieren, dass der externe Zugriff korrekt angepasst wurde, interne Loopback-Zugriffe oder ausgehender Server-Traffic aber weiterhin nach der alten Logik laufen.

Das ist kein kosmetisches Detail. Sophos erstellt Loopback- und reflexive Regeln mit Bezug auf Name und ID der ursprünglichen DNAT-Regel, aber spätere Änderungen an der ursprünglichen Regel aktualisieren die abgeleiteten Regeln nicht automatisch. Nach Änderungen an öffentlicher IP, Zielserver, Service oder Quellen sollten diese Regeln deshalb bewusst geöffnet und verglichen werden.

Load Balancing und Health Check

Wenn mehrere interne Server hinter einer öffentlichen IP veröffentlicht werden, kann DNAT auch für Load Balancing oder Failover verwendet werden.

Mögliche Methoden sind zum Beispiel:

• Round-robin
• First alive
• Random
• Sticky IP
• One-to-one

Wenn die Firewall erkennen soll, ob ein Zielserver verfügbar ist, muss ein Health check konfiguriert werden. Ohne Health Check kann die Firewall Traffic auch an einen Server weiterleiten, der nicht erreichbar ist.

DNAT-Veröffentlichungen per XML API ausrollen

Die XML API kann die geplante Veröffentlichung mit NATRule anlegen oder ändern. Sie ersetzt weder die separate Firewall-Freigabe noch die Abnahme des Datenflusses. Das vollständige NAT-Modell und die allgemeine Objektstruktur gehören zu NAT auf Sophos Firewall verstehen; hier geht es um den sicheren Change für einen veröffentlichten Server. Zugang, TLS-Prüfung, Servicekonto, Secrets und explizite Schreiboperationen zuerst nach XML API Zugriff absichern vorbereiten.

Geplanten Datenfluss in den Request übertragen

Für das vorhandene HTTPS-Beispiel beschreibt OriginalSourceNetworks mit seinen Network-Einträgen die erlaubten externen Quellen, OriginalDestinationNetworks das öffentliche Ziel und OriginalServices mit Service den externen Dienst. TranslatedDestination verweist auf den internen Server; TranslatedService bleibt ohne PAT auf Original, andernfalls bezeichnet es den internen Service. TranslatedSource bleibt für normalen DNAT ohne bewusst geplantes SNAT ebenfalls Original. Die Original-Felder begrenzen den eingehenden Flow, die Translated-Felder bestimmen dessen Übersetzung. Vorhandene Host- und Serviceobjekte samt Adressfamilie zuerst lesen und mit dem Change vergleichen; keine Beispielnamen als reale Objekte voraussetzen. Die Firewall-Regel muss weiterhin die Zielzone nach NAT, das öffentliche Ziel vor NAT und bei PAT beide Services abdecken.

InboundInterfaces und OutboundInterfaces enthalten jeweils Interface-Einträge und begrenzen das Matching. Sie sind nicht die interface-spezifische Quellübersetzung: Nur wenn diese tatsächlich benötigt wird, verwendet man OverrideInterfaceNATPolicy mit Enable und die zugehörige InterfaceNATPolicyList. Deren Override-Einträge ordnen specific_interface einer specific_translatedsourceid zu. Für eine normale Serververöffentlichung diesen Sonderfall nicht vorsorglich aktivieren. Der Kommentar im dokumentierten Beispiel nennt abweichend OverrideInterfaceDefaultNATPolicy, während das XML-Element OverrideInterfaceNATPolicy heisst. Daraus keinen zweiten Schalter oder gültigen alternativen Tag ableiten; bei ungeklärter Override-Syntax den Request stoppen und die API help des installierten Builds beziehungsweise Support heranziehen.

Die Einfügeposition ist eine eigene Entscheidung: Position bietet top, bottom, after und before. Bei after steht der Name der vorhandenen Bezugregel unter After > Name, bei before unter Before > Name; diese Bezugselemente sind im Beispiel für Set-Requests vorgesehen. Nicht beide Richtungen gleichzeitig setzen und den Bezugnamen nicht mit dem eigenen NATRule-Namen verwechseln. Vor dem Schreiben die Bezugregel lesen und Konflikte oberhalb prüfen; nach dem Schreiben die tatsächliche Position kontrollieren. NAT- und Firewall-Reihenfolge bleiben zwei getrennte Tabellen. LinkedFirewallrule ist im Beispiel nur für das Erstellen von Linked NAT in einem Set-Request vorgesehen, nicht als automatische Firewall-Freigabe für eine eingehende DNAT-Regel.

Optionale Verteilung nicht zur Pflicht machen

Für eine einfache Veröffentlichung an einen Server sind Load Balancing und Health Check keine Pflicht. HealthCheck gilt laut Objektbeschreibung nur bei aktivierter Verteilung. Die Prüfwerte unter LoadBalance gehören zum aktivierten Health Check: ProbeMethod ist ICMP oder TCP; Port wird nur bei TCP benötigt und liegt zwischen 1 und 65535. Die Parametertabelle nennt für ProbeInterval 5 bis 65535 Sekunden, Standard 60, für ResponseTimeOut 1 bis 10 Sekunden, Standard 2, und für DeactivateHostAfter 1 bis 10 Versuche, Standard 3. Die dortigen Mandatory-Markierungen für Prüfwerte sind keine Pflicht für jeden NAT-Request. Die passende Methode, aktivierte Prüfung und gültigen Werte in API help des eingesetzten Builds bestätigen; keine vollständig ausgefüllte Load-Balance-Vorlage an jeden DNAT-Change anhängen. Ein ICMP-Erfolg bestätigt zudem keinen funktionierenden Anwendungsdienst.

Schreiben, Zustand lesen und Veröffentlichung abnehmen

1. Den vorgesehenen Flow, erlaubte Quellen, öffentlichen und internen Service, NAT-/Firewall-IDs und Positionen dokumentieren. Bestehenden Zustand sichern und Abhängigkeiten einschliesslich separat erzeugter Loopback- und reflexiver Regeln prüfen. Den vorhandenen Go-live- und Rollback-Ablauf auch für die Automation verwenden.
2. Die ungefährliche Leseabfrage vom vorgesehenen Automationshost ausführen. Dann nur die für NATRule und den installierten Build bestätigte explizite Set-Operation verwenden. Weder einen ausgelassenen Operationswert noch generisches Upsert-Verhalten voraussetzen; bleibt der konkrete Payload ungeklärt, nicht schreiben. IPFamily und Status bewusst festlegen, statt eine unerwartete IPv4-Regel oder sofortige Aktivierung aus einem Default zu übernehmen.
3. Antwort und objektspezifischen XML-Status sichern, Secrets bereinigen und die gespeicherte Regel erneut lesen beziehungsweise in Rules and policies > NAT rules öffnen. Original-/Translated-Werte, Interfaces, Status, ID und tatsächliche Position mit dem Plan vergleichen. Die separate Firewall-Regel sowie benötigte abgeleitete Regeln ebenfalls einzeln kontrollieren; deren Erstellung oder Aktualisierung nicht allein aus einem NATRule-Request ableiten.
4. Erst danach den geplanten Aktivierungsschritt durchführen und mit neuen Sessions die erlaubte und eine kontrolliert nicht erlaubte externe Quelle, benötigten internen Zugriff sowie benötigte serverseitig gestartete Verbindungen prüfen. Log Viewer, NAT Rule ID, Firewall Rule ID, Capture und Server-Log müssen zum geplanten Flow und zur erwarteten Quell-IP passen. Ein gespeichertes Objekt oder ein XML-Status bestätigt noch keine sichere, funktionierende Veröffentlichung.
5. Bei Abweichungen nicht blind wiederholen. Zuerst tatsächlichen Zustand und Antwort vergleichen; dann nur neue exklusive Regeln zurücknehmen oder geänderte gemeinsame Regeln auf den dokumentierten Zustand und ihre alte Position zurücksetzen. Separat erzeugte Regeln separat behandeln, gemeinsam genutzte Freigaben nicht pauschal abschalten und den Rückweg mit neuen Sessions kontrollieren.

NATRule-Antworten objektspezifisch einordnen

Die Dokumentation für SFOS 22 und 23 führt die folgenden Operation-/Code-/Symbol-Zuordnungen auf. Message.* sind nicht aufgelöste Meldungsschlüssel der Dokumentationsseite, keine hier aufgelösten Antworttexte oder nachgewiesenen Laufzeitergebnisse. Codes nicht als HTTP-Status behandeln und nicht allein aus dem Symbolnamen eine eindeutige Fehlerursache, erfolgreiche Speicherung oder Retry-Regel ableiten.

Dass 548 und 549 denselben Schlüssel tragen, erlaubt gerade keine eindeutige Unterscheidung anhand dieses Labels. Die NATRule-Zuordnung für 503 und 504 darf ebenso wenig durch generische API-Code-Erklärungen ersetzt werden. Bei unerwarteter Antwort die bereinigte vollständige Antwort, Operation, installierten Build und gelesenen Regelzustand festhalten; die objektspezifische Status Message Information und bei Bedarf Support verwenden. Die zentrale API-Sicherheitsanleitung erklärt den Umgang mit Teilerfolg, Warnungen und Lesekontrollen vor einem erneuten Schreibversuch.

Absicherung und Go-live

Ein veröffentlichter Dienst ist sofort Teil der öffentlichen Angriffsfläche. Deshalb gehören enger Zugriff, Logging, Security Profile und ein klarer Rollback zum Go-live.

Go-live und Rollback planen

Eine DNAT-Veröffentlichung sollte wie eine kleine Produktionsänderung behandelt werden. Sobald die Regel aktiv ist, kann der Dienst aus dem Internet erreichbar sein. Deshalb sollte vor dem Go-live klar sein, welche Regel aktiv wird, wie der Zugriff getestet wird und wie man bei Problemen zurückgeht.

Vor dem Go-live prüfen:

• Aktuelle Firewall-Konfiguration sichern oder mindestens die betroffenen NAT- und Firewall-Regeln dokumentieren.
• IDs aller zu dieser Änderung gehörenden DNAT-, Loopback-, reflexiven NAT- und Firewall-Regeln erfassen; bei geänderten bestehenden Regeln den bisherigen Aktivierungszustand und die Position festhalten.
• Bestehende NAT-Regeln auf dieselbe öffentliche IP, denselben externen Port und dieselbe WAN-Schnittstelle prüfen.
• Provider-Router, Cloud Security Group oder vorgelagerte Firewall-Regeln mit der Sophos-Konfiguration abgleichen.
• DNS-TTL berücksichtigen, wenn ein Hostname neu auf die veröffentlichte Adresse zeigt.
• Testquelle ausserhalb des eigenen LAN vorbereiten, zum Beispiel Mobilfunk, externer Standort oder kontrollierter Online-Porttest.
• Erwartete Logstellen festlegen: Log Viewer, NAT Rule ID, Firewall Rule ID, Packet Capture und Server-Log.
• Rollback-Kriterium definieren, zum Beispiel falscher Dienst erreichbar, Server antwortet nicht, Zertifikatsfehler, Security Profile blockiert legitimen Traffic oder unerwartete Quell-IP auf dem Server.

Beim Rollback prüft man für jede erfasste Regel zuerst, ob andere Freigaben sie mitverwenden. Nur neu angelegte, zu dieser Änderung gehörende Regeln deaktivieren; das schliesst separat erzeugte Loopback- und reflexive NAT-Regeln ein. Geänderte bestehende Regeln auf den dokumentierten Zustand und die bisherige Position zurücksetzen, statt eine gemeinsam genutzte Firewall-Regel pauschal zu deaktivieren. Anschliessend die benötigten externen, internen und vom Server gestarteten Pfade mit neuen Sessions prüfen; das Deaktivieren garantiert kein sofortiges Ende bestehender Verbindungen. Wenn eine alte Veröffentlichung ersetzt wurde, sollte klar sein, ob die alte Regel wieder aktiviert werden darf oder ob zuerst Provider-Portweiterleitung, DNS oder Monitoring zurückgestellt werden müssen.

Bei kritischen Diensten sollte man nicht mehrere Dinge gleichzeitig ändern. Wenn DNS, Provider-Router, NAT-Regel, Firewall-Regel und Serverkonfiguration gleichzeitig angepasst werden, ist ein Fehler später schwer zuzuordnen. Besser ist ein kurzer Ablauf mit klaren Schritten: vorbereiten, aktivieren, extern testen, Logs prüfen, Server prüfen, Ergebnis dokumentieren.

Zugriff möglichst eng einschränken

Nicht jeder veröffentlichte Dienst muss aus dem gesamten Internet erreichbar sein. Wenn möglich, sollte man den Zugriff begrenzen.

Sinnvolle Einschränkungen:

• Nur einzelne Quell-IP-Adressen erlauben.
• Nur bekannte FQDN-Hosts erlauben, wenn die Gegenseite dynamische IPs verwendet.
• Nur bestimmte Länder erlauben.
• Bestimmte Länder explizit blockieren.
• Zugriff nur über VPN ermöglichen.
• Statt direkter Veröffentlichung eine ZTNA Lösung verwenden.

Für administrative Dienste wie SSH, RDP oder interne Admin-Portale ist DNAT meistens nicht die beste Lösung. Wenn der Zugriff nicht öffentlich sein muss, ist VPN oder ZTNA fast immer die bessere Wahl.

Sicherheit verbessern

Für veröffentlichte Dienste sollte man prüfen:

• Ist der Server aktuell gepatcht?
• Gibt es eine WAF oder Reverse-Proxy-Option?
• Ist IPS auf der Firewall-Regel aktiv?
• Sind nur notwendige Ports geöffnet?
• Wird der Dienst geloggt?
• Gibt es Geo-IP-, Threat-Feed- oder Quell-IP-Einschränkungen?
• Ist MFA möglich, falls es sich um ein Portal handelt?

Für Webanwendungen kann statt reinem DNAT auch Web Server Protection / WAF sinnvoll sein.

Bots und Threat Feeds

Öffentliche Ports wie HTTP, HTTPS, SSH oder RDP stehen permanent im Fokus von Bots. Sobald ein Port im Internet erreichbar ist, sieht man oft sehr schnell Verbindungsversuche, Scans, Loginversuche oder Exploit-Traffic im Log Viewer.

Das bedeutet nicht automatisch, dass der Server kompromittiert ist. Es zeigt aber, dass der Dienst Teil der öffentlichen Angriffsfläche ist. Deshalb empfehlen wir, veröffentlichte Dienste zusätzlich mit IPS, Logging, engen Quellen und Third-Party Threat Feeds abzusichern.

Threat Feeds liefern der Firewall laufend aktuelle Indicators of Compromise, zum Beispiel bösartige IP-Adressen oder Domains. Dadurch kann die Firewall bekannte Angreifer, Botnetze oder Scanner blockieren, bevor sie den veröffentlichten Dienst erreichen.

Mehr dazu: Sophos Firewall Threat Feeds

Test

Nach dem Speichern der DNAT-Regel:

• Aus einem externen Netz testen, nicht aus demselben LAN
• Nur den erwarteten öffentlichen Port prüfen, nicht breit gegen fremde Adressen scannen
• Log Viewer auf Firewall Rule ID, NAT Rule ID, Source, Original Destination, übersetztes Ziel und erlaubten oder verworfenen Status prüfen
• Packet Capture mit externer Source, öffentlicher Destination und internem Ziel vergleichen
• Server-Logs kontrollieren
• Sichtbare Quell-IP auf dem Zielsystem kontrollieren

Wenn der Test aus dem internen LAN auf die öffentliche IP erfolgen soll, kann zusätzlich Hairpin NAT oder eine interne DNS-Lösung nötig sein.

Testmatrix für DNAT-Freigaben

Ein einzelner Porttest reicht für eine produktive DNAT-Freigabe selten aus. Besser ist eine kleine Testmatrix, die erlaubte und unerwünschte Pfade trennt. So sieht man nicht nur, ob der Dienst erreichbar ist, sondern auch, ob Einschränkungen, Logging und Rückweg korrekt funktionieren.

Sinnvolle Testquellen:

• Externe erlaubte Quelle: Verbindung von Mobilfunk, externem Standort oder Partnernetz auf öffentliche IP und externen Port testen. Im Log Viewer müssen erwartete Firewall Rule ID und NAT Rule ID erscheinen.
• Externe nicht erlaubte Quelle: Wenn die Freigabe auf bestimmte Quellen begrenzt ist, sollte ein Test von einer nicht erlaubten Quelle bewusst scheitern. Sonst ist die Source-Einschränkung zu breit.
• Interner Client mit internem DNS-Namen: Prüfen, ob interne Benutzer direkt zur internen Server-IP auflösen. Das ist oft sauberer als Loopback NAT.
• Interner Client mit öffentlichem FQDN: Nur testen, wenn dieser Zugriff wirklich benötigt wird. Falls er scheitert, zuerst Split DNS prüfen und Loopback NAT nicht automatisch ergänzen.
• Zielserver selbst: Server-Log, lokale Firewall, gebundener Dienst, Zertifikat und sichtbare Source-IP prüfen. So erkennt man, ob der Server die echte externe IP oder eine SNAT-Adresse sieht.
• Monitoring oder externer Health Check: Prüfen, ob der Test dieselbe URL, denselben Port und dieselbe Quelllogik verwendet wie die echte Überwachung.

Nach jedem Test sollte man nur einen Befund bewerten: Kommt der Traffic bei der Sophos Firewall an, greift die erwartete NAT-Regel, greift die erwartete Firewall-Regel, erreicht das Paket den Server und kommt eine Antwort zurück. Wenn mehrere Dinge gleichzeitig geändert werden, ist der nächste Fehler sonst kaum noch zuzuordnen.

Ein sauberer DNAT-Test vergleicht drei Sichtweisen:

• Externer Client: Verbindung zur öffentlichen IP und zum externen Port funktioniert oder wird bewusst blockiert.
• Sophos Firewall: Log Viewer zeigt die erwartete Firewall Rule ID und NAT Rule ID.
• Interner Server: Dienst sieht die erwartete Source-IP, antwortet über den richtigen Gateway und protokolliert den Zugriff.

Wenn nur eine dieser Sichtweisen geprüft wird, bleiben typische Fehler unentdeckt. Ein erfolgreicher externer Porttest sagt zum Beispiel noch nicht, ob Logging, IPS, Source-Einschränkung oder Server-Owner sauber dokumentiert sind.

Troubleshooting und Betrieb

Nach dem Go-live sollte man nicht nur prüfen, ob der Dienst erreichbar ist. Wichtig sind Log Viewer, NAT Rule ID, Firewall Rule ID, Server-Logs und regelmässige Reviews alter Freigaben.

Troubleshooting

Häufige Fehler:

• Firewall-Regel fehlt
• falsche WAN-IP gewählt
• Portweiterleitung auf dem Provider-Router fehlt
• Azure Network Security Group blockiert den Port
• Dienst läuft intern nicht
• Server-Gateway zeigt nicht auf die Sophos Firewall
• NAT-Regel steht unter einer anderen, die vorher greift
• Firewall-Regel nutzt bei DNAT das falsche Destination network
• Port wird bereits von einem anderen Dienst verwendet
• Loopback fehlt, wenn interne Clients den öffentlichen FQDN verwenden
• Health Check fehlt oder ist falsch, wenn Load Balancing verwendet wird
• Test erfolgt aus dem internen Netz und nicht von extern
• Der Zielserver antwortet über einen anderen Gateway zurück
• Ein Security Profile blockiert den Traffic, wird aber nicht im richtigen Log gesucht

Der Log Viewer ist bei DNAT-Problemen der wichtigste Startpunkt. Dort sieht man, ob Traffic ankommt, welche Firewall-Regel und welche NAT-Regel greifen und ob der Traffic erlaubt oder verworfen wird. Wenn der Treffer nicht zur Erwartung passt, hilft Sophos Firewall-Regel greift nicht: Ursachen prüfen.

Für tieferes Troubleshooting sollte man nicht nur die Sophos Firewall betrachten. Wenn der Log Viewer den Traffic erlaubt und Packet Capture zeigt, dass Pakete zum Server weitergehen, liegt die Ursache häufig auf dem Zielsystem: lokale Firewall, falscher Default Gateway, Dienst nicht gebunden, Zertifikatproblem, Anwendung lauscht auf anderem Port oder vorgeschalteter Reverse Proxy antwortet nicht wie erwartet.

Eine schnelle Einordnung hilft, damit man nicht an der falschen Stelle sucht:

• Im Log Viewer erscheint kein Treffer: Traffic erreicht die Firewall nicht oder die falsche WAN-IP wird angesprochen. Provider-Router, Cloud-Security-Group, öffentliche IP und Packet Capture auf WAN prüfen.
• Firewall Rule ID passt, NAT Rule ID fehlt: NAT-Regel matcht nicht oder steht zu tief. Original destination, Original service, Inbound Interface und NAT-Reihenfolge prüfen.
• NAT Rule ID passt, Dienst antwortet nicht: Zielserver oder Rückweg stimmt nicht. Server-Firewall, Default Gateway, Routing und Packet Capture Richtung Server prüfen.
• Extern funktioniert es, intern über FQDN nicht: Split DNS oder Loopback fehlt. Interne DNS-Auflösung prüfen und Loopback nur bewusst ergänzen.
• Nach Änderung des Assistenten verhält sich nur ein Teil falsch: Abgeleitete Loopback- oder reflexive Regel passt nicht mehr. Erzeugte NAT- und Firewall-Regeln einzeln prüfen.

SMTP über DNAT nach SFOS-22-Upgrade

Werden eingehende E-Mails nach einem Upgrade auf SFOS 22 sporadisch verspätet oder gar nicht zugestellt, kommt NC-184583 als Ursache infrage. Sophos nennt SFOS 22.0 GA Respin Build 411 ausdrücklich als betroffen, beschreibt das Problem aber allgemeiner für Upgrades auf v22.x. MR1 und MR2 sind nicht separat als betroffen oder behoben aufgeführt. Als Fix steht nur SFOS 23.0 EAP0 Build 275 – eine EAP-Version, die man nicht pauschal auf einem Produktivsystem einsetzen sollte. Einen öffentlichen Workaround gibt es nicht; Sophos verweist an den Support.

Davon getrennt führen die Release Notes von SFOS 22.0 MR3 Build 576 vom 16. Oktober 2026 den behobenen Fehler NC-180464: SMTP-Verkehr über DNAT wurde nach einem Upgrade fälschlich verworfen. Diese zweite Issue-ID ist kein Beleg, dass auch NC-184583 in MR3 behoben ist. Bei einem passenden Fehlerbild beide IDs, den installierten Build und die bisherigen Beobachtungen mit Sophos Support abgleichen, bevor daraus ein Fix-Versprechen für das eigene System wird.

Ein Porttest auf TCP 25 genügt bei diesem Fehlerbild nicht. Man sollte mehrere kontrollierte echte Nachrichten senden und UTC-Zeit, Absender, Empfänger sowie Message-ID notieren. Anschliessend vergleicht man Sender-Queue oder Bounce mit Queue und Transport-Log des internen Mailservers. Für den Support gehören Firmware-Build, Zeitstempel, Rule IDs, fwlog.log, firewall_rule.log, nat_rule.log und die Mailserver-Logs ins Beweispaket. Logpfade und Consolidated Troubleshooting Report sind unter Sophos Firewall Services und Logs per CLI prüfen beschrieben. Im Supportfall sollte NC-184583 ausdrücklich genannt werden.

Das Known Issue beschreibt den direkten DNAT-Pfad zum internen Mailserver. Im Sophos Firewall MTA Mode nimmt die Firewall die Nachricht selbst an und leitet sie weiter. Sophos bestätigt jedoch weder, dass MTA Mode sicher ausgenommen ist, noch dass eine Umstellung der offizielle Workaround wäre.

Soll derselbe direkte DNAT-Pfad transparent geprüft werden, zeigt Mail Protection im Legacy Mode einrichten, wie DNAT, SNAT, SMTP-Regeln und Proxy-Scanning zusammen abgenommen werden. Das ist ein reguläres Design und kein Workaround für NC-184583.

Wann Black Hole DNAT zusätzlich hilft

Wenn ein Dienst bewusst öffentlich erreichbar bleiben muss, aber bestimmte Quellen vor der eigentlichen Veröffentlichung abgefangen werden sollen, kann eine Black-Hole-DNAT-Regel oberhalb der produktiven DNAT-Regel sinnvoll sein. Das passt zum Beispiel bei bekannten Bad-IP-Listen, dauerhaft unerwünschten Ländern oder wiederkehrenden Scanner-Quellen.

Diese Technik ersetzt keine saubere Freigabe. Die produktive DNAT-Regel muss weiterhin eng sein, Logging muss aktiv sein und der veröffentlichte Server muss aktuell gehalten werden. Black Hole DNAT ist eine zusätzliche Block-Ebene vor einer Veröffentlichung, nicht die eigentliche Sicherheitsarchitektur.

Sinnvoll ist Black Hole DNAT vor allem in diesen Fällen:

• Wiederkehrende Scanner-Quellen treffen denselben veröffentlichten Dienst: Die Quellen können vor der produktiven DNAT-Regel ins Leere laufen.
• Einzelne Länder sollen keinen Zugriff auf eine Portweiterleitung haben: Die Block-Regel kann oberhalb der eigentlichen DNAT-Regel stehen.
• Eine gepflegte Bad-IP-Gruppe existiert bereits: Die Gruppe kann als Original source der Black-Hole-Regel verwendet werden.
• Ein Dienst muss öffentlich bleiben, soll aber weniger Bot-Traffic erreichen: Die produktive Regel bleibt erhalten, unerwünschte Quellen werden vorher abgefangen.

Nicht passend ist Black Hole DNAT für lokale Firewall-Dienste wie WebAdmin, User Portal, VPN Portal oder SSH zur Firewall selbst. Dafür sind Device Access und Local Service ACL exception rules zuständig. Für Webserver über WAF sollte man zuerst die WAF-Regel, Blocked countries, Authentication und WAF-Logs prüfen.

Wichtig ist die Reihenfolge: Die Black-Hole-DNAT-Regel muss oberhalb der produktiven DNAT-Regel stehen. Danach sollte man im Log Viewer prüfen, ob blockierte Quellen wirklich die Black-Hole-Regel treffen und erlaubte Quellen weiterhin die produktive NAT- und Firewall-Regel verwenden. Der genaue Ablauf steht in Sophos Firewall: Länder und bösartige IPs blockieren.

Betriebscheck

DNAT-Regeln sollten regelmässig geprüft werden. Alte Freigaben sind ein typisches Sicherheitsrisiko, weil veröffentlichte Dienste oft noch erreichbar bleiben, obwohl die Anwendung längst umgezogen, ersetzt oder nur temporär benötigt wurde.

Für produktive DNAT-Regeln sollte mindestens dokumentiert sein:

• Zweck der Freigabe: Später muss klar sein, warum der Dienst überhaupt öffentlich erreichbar ist.
• Verantwortliche Person oder Team: Ohne Owner werden alte Freigaben selten entfernt.
• Öffentliche IP und externer Port: Erleichtert Prüfung, Monitoring und externe Scans.
• Interner Zielserver und Zielport: Wichtig bei Servermigrationen, Load Balancing und Zertifikatswechseln.
• Erwartete Quellen: Hilft zu erkennen, ob Any wirklich nötig ist.
• Schutzmassnahmen: IPS, WAF-Alternative, MFA, Threat Feeds, Logging und Patchstand sollten nachvollziehbar sein.
• Ablaufdatum oder Review-Termin: Temporäre Freigaben brauchen ein klares Ende.

Ein sinnvoller Review besteht nicht nur aus einem Blick auf die Regel. Man sollte extern prüfen, ob nur die erwarteten Ports offen sind, im Log Viewer kontrollieren, welche Quellen tatsächlich zugreifen, und auf dem Zielserver prüfen, ob die Anwendung noch gepflegt wird. Wenn der Dienst nur intern oder für wenige Partner benötigt wird, sollte VPN, ZTNA, eine Quell-IP-Einschränkung oder eine WAF-Regel neu bewertet werden.

Beim Entfernen alter DNAT-Regeln sollte man nicht nur die NAT-Regel löschen. Häufig hängen Firewall-Regeln, Host-Objekte, Service-Objekte, Loopback Rules, Reflexive Rules, DNS-Einträge, Monitoring-Checks oder Provider-Portweiterleitungen daran. Besser ist ein kurzer Decommission-Ablauf:

1. Letzte Zugriffe im Log Viewer prüfen.
2. Zuständige Person oder Fachbereich bestätigen lassen, dass der Dienst nicht mehr benötigt wird.
3. Betroffene DNAT-, separat erzeugte Loopback- und reflexive NAT- sowie Firewall-Regeln anhand ihrer IDs zuordnen und andere Nutzer und Abhängigkeiten prüfen. Zunächst nur Regeln deaktivieren, die ausschliesslich zur stillgelegten Veröffentlichung gehören; nicht mehr benötigte separat erzeugte Regeln ausdrücklich einschliessen. Nicht davon ausgehen, dass das Deaktivieren der DNAT-Regel alle abgeleiteten Regeln mit abschaltet; nicht mehr benötigte exklusive Regeln separat deaktivieren. Eine gemeinsam genutzte Firewall-Freigabe nicht pauschal abschalten: nach Abhängigkeitsprüfung erhalten oder nur die stillgelegten Kriterien vorsichtig entfernen.
4. Mit neuen externen Sessions prüfen, ob der stillgelegte Port nicht mehr erreichbar ist. Benötigte interne und vom Server gestartete Pfade ebenfalls mit neuen Sessions auf den geplanten Zustand prüfen, einschliesslich weiterhin benötigter gemeinsam genutzter Veröffentlichungen. Bestehende Sessions belegen keinen Entzug der Freigabe.
5. Monitoring und Server-Logs nach Fehlern prüfen und die Auswirkungen während einer Beobachtungsphase verfolgen.
6. Erst danach nachweislich ungenutzte Objekte, DNS-Einträge und Provider-Regeln bereinigen.

Wenn eine Freigabe weiterhin benötigt wird, sollte der Review mit einem konkreten Ergebnis enden: unverändert belassen, enger einschränken, auf WAF umstellen, hinter VPN/ZTNA verschieben oder mit Ablaufdatum erneut prüfen.

FAQ