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.

Diese Anleitung zeigt, welche Punkte man vor und nach einer DNAT-Regel prüfen sollte und wie man die Freigabe möglichst eng absichert.

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. Veröffentliche nur, was wirklich nötig ist, und schränke Quelle, Port und Ziel möglichst eng ein.

Vorab klären

Vor dem Erstellen der Regel 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 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 DynDNS verwenden. Die Sophos Firewall kann Dynamic DNS einrichten, damit ein DNS-Name immer auf die aktuelle öffentliche IP zeigt. Wichtig ist trotzdem: Die Portweiterleitung auf dem Provider-Router muss auf die Sophos Firewall zeigen.

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-Regel erstellen

Ein typisches DNAT-Beispiel:

• Original source: Any oder definierte Quellnetze
• Original destination: WAN-IP oder WAN-Schnittstelle
• Original service: HTTPS
• Translated destination: interner Server
• Translated service: unverändert oder interner Zielport

Vorgehen:

1. Rules and policies öffnen.
2. Zum Bereich NAT rules wechseln.
3. Neue NAT-Regel erstellen.
4. Original Source, Destination und Service definieren.
5. Translated Destination auf den internen Server setzen.
6. Optional Translated Service setzen.
7. 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.

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.

Sophos beschreibt die Felder in der offiziellen Anleitung Add a NAT rule.

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 ausserdem prüfen, ob es Konflikte mit WebAdmin oder User Portal der Sophos Firewall gibt. Standardmässig nutzt die Admin-Konsole HTTPS-Port 4444, das User Portal HTTPS-Port 443. Bei Überschneidungen müssen die Firewall-eigenen Ports oder die veröffentlichten Dienste sauber getrennt werden.

Loopback, Reflexive und Linked NAT Rules

Sophos kennt 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 zu einer DNAT-Regel, damit Rückverkehr oder bestimmte Gegenrichtungen passend übersetzt werden.
• Linked NAT rule: Wird aus einer Firewall Regel heraus erstellt und ist eine verknüpfte SNAT-Regel. Sie ist nicht dasselbe wie eine eingehende DNAT-Regel für einen veröffentlichten Server.

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. Für allgemeine Umgebungen empfiehlt Sophos jedoch, NAT-Regeln möglichst unabhängig und einfach zu halten, statt unnötig viele verknüpfte NAT-Regeln pro Firewall Regel zu erstellen.

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.

Firewall Regel prüfen

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

Die Firewall Regel sollte definieren:

• Source zone: meistens WAN
• Source network: möglichst eingeschränkt
• Destination zone: Zone des internen Servers, zum Beispiel DMZ
• Destination network: interner Server
• Services: nur benötigte Ports
• Security Profile: je nach Dienst IPS, Malware Scan oder Web Policy
• Logging: aktivieren

Ohne passende Firewall Regel wird der Traffic trotz DNAT verworfen.

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.

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.

Weitere Informationen:

• Wie man Sophos ZTNA einrichtet
• Sophos ZTNA Gateway erstellen

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 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 Erstellen der DNAT-Regel:

• Aus einem externen Netz testen, nicht aus demselben LAN
• Portscan auf die öffentliche IP prüfen
• Log Viewer auf NAT und Firewall Events prüfen
• Server-Logs kontrollieren
• Prüfen, ob der Client die erwartete Quell-IP sieht

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.

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
• 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 Log Viewer ist bei DNAT-Problemen der wichtigste Startpunkt. Dort sieht man, ob Traffic ankommt, welche Regel greift und ob er erlaubt oder verworfen wird.

Empfehlung

DNAT-Regeln sollten regelmässig geprüft werden. Alte Freigaben sind ein typisches Sicherheitsrisiko. Eine gute Dokumentation enthält Zweck, Zielserver, externe Ports, verantwortliche Person, Ablaufdatum und letzte Prüfung.