Sophos Firewall-Regeln verstehen und sicher konfigurieren

Firewall-Regeln sind das Herzstück der Sophos Firewall. Diese Regeln legen fest, welcher Traffic zwischen Zonen, Netzwerken, Benutzern und Diensten erlaubt oder blockiert wird und welche Schutzfunktionen dabei angewendet werden.

Dieser Artikel erklärt eine Sophos Firewall-Regel von oben bis unten: Reihenfolge, Gruppen, Action, Logging, Source, Destination, Services, User Matching, Exclusions, NAT, Web Filtering, TLS Inspection, Security Heartbeat, Application Control, IPS, Traffic Shaping, DSCP, NDR und E-Mail-Scanning.

Der Menüpfad lautet:

Rules and policies > Firewall rules > Add firewall rule > New firewall rule

Die Regelmaske ist in mehrere Bereiche gegliedert: Kopfbereich, Source, Destination, Services, Benutzerbezug, NAT-Verknüpfung und Security Features. Für die Praxis ist wichtig, die Maske nicht als Sammlung einzelner Haken zu verstehen. Eine Regel funktioniert nur sauber, wenn Quelle, Ziel, Service, Reihenfolge, Logging und die aktivierten Schutzfunktionen zusammenpassen.

Vor dem Anlegen sollte ausserdem klar sein, ob es um eine IPv4- oder IPv6-Regel geht. Die Regelansicht wird im WebAdmin entsprechend gewählt. In Dual-Stack-Umgebungen müssen IPv4 und IPv6 bewusst getrennt geplant und getestet werden; eine funktionierende IPv4-Regel beweist nicht automatisch, dass IPv6 gleich abgesichert ist.

Schnellnavigation

• Was Firewall-Regeln steuern und was nicht
• Grundprinzip und Reihenfolge
• Regelbasis vor dem Anlegen planen
• Regeltypen sauber trennen
• Fiktives Praxisbeispiel
• Kopfbereich: Status, Name, Action und Logging
• Quelle, Zone und Zeitplan
• Destination and services
• Match known users
• Add exclusion
• Create linked NAT rule
• Web filtering
• Synchronized Security Heartbeat
• Other security features
• Scan email content
• Nach dem Speichern prüfen
• Regelbetrieb und Review
• Neue Regel, bestehende Regel ändern oder deaktivieren?
• Typische Fehler
• FAQ

Welcher Netzwerk-Policy-Artikel passt?

Firewall-Regeln, NAT, WAF, VLANs und Routing greifen in der Sophos Firewall eng ineinander. Für Admins ist deshalb wichtig, zuerst das richtige Thema zu wählen:

• Firewall-Regel von Grund auf verstehen: Dieser Artikel.
• NAT, SNAT, DNAT, MASQ oder PAT einordnen: NAT auf Sophos Firewall verstehen: SNAT, DNAT, MASQ, PAT.
• Internen Server per Portweiterleitung veröffentlichen: Server per DNAT auf Sophos Firewall veröffentlichen.
• Öffentliche Webanwendung absichern: Sophos Firewall WAF einrichten und einordnen.
• Regel greift nicht oder falsche Rule ID erscheint: Sophos Firewall Regel greift nicht: Ursachen prüfen.
• Regel gezielt testen: Firewall-Regel testen mit Log Viewer, Policy Test und Packet Capture.
• WebAdmin, VPN Portal, User Portal, SSH, DNS oder SNMP der Firewall absichern: Sophos Firewall Zugriff absichern: Device Access richtig konfigurieren.
• Zonen, Interfaces oder VLANs planen: Sophos Firewall Zonen und Interfaces konfigurieren.
• Bridge mit VLAN Tags betreiben: Sophos Firewall Bridge mit VLAN Tagging einsetzen.
• Routing-Reihenfolge oder SD-WAN-Pfade prüfen: Sophos Firewall Routing-Priorität anpassen.
• Reply Packets oder System Traffic gehen über falschen Pfad: SD-WAN Routing für Reply Packets und System Traffic.

Diese Trennung verhindert typische Fehlersuchen. Eine NAT-Regel erlaubt keinen Traffic, eine Firewall-Regel übersetzt keine Adresse, und eine WAF-Regel ist nicht dasselbe wie eine normale DNAT-Portweiterleitung.

Was Firewall-Regeln steuern und was nicht

Firewall-Regeln steuern Traffic, der durch die Firewall fliesst. Diese Regeln sind aber nicht der einzige Kontrollpunkt in SFOS. Viele Fehlersuchen entstehen, weil man ein Verhalten in der Firewall-Regelliste sucht, obwohl ein anderer Bereich zuständig ist.

• Traffic zwischen Zonen, Netzen, Benutzern und Diensten: Firewall-Regeln entscheiden, ob Durchgangstraffic erlaubt, verworfen oder mit Security Features geprüft wird.
• WebAdmin, User Portal, VPN Portal, SSH, DNS oder SNMP zur Firewall selbst: Device Access und Local Service ACL sind zuständig. Lokale Firewall-Dienste werden nicht wie normaler LAN-to-WAN- oder WAN-to-DMZ-Traffic behandelt.
• Adress- oder Portübersetzung: NAT-Regeln übersetzen Traffic, erlauben ihn aber nicht automatisch.
• Wegwahl, Rückweg, SD-WAN und VPN-Pfade: Routing, SD-WAN, Route Precedence und VPN-Konfiguration entscheiden über den Pfad. Eine passende Firewall-Regel beweist noch keinen funktionierenden Rückweg.
• Webkategorien, URL-Gruppen und Web Policy: Web filtering und Web Policy steuern die Weblogik. Die Firewall-Regel bindet die Policy nur ein.
• HTTPS-Entschlüsselung: SSL/TLS inspection rules und CA-Verteilung sind nötig. Scan HTTP and decrypted HTTPS scannt nur Traffic, der bereits entschlüsselt ist.
• Benutzeridentität: Authentifizierung, STAS, Captive Portal, Entra ID SSO oder RADIUS müssen funktionieren. Eine Benutzerregel matcht nur, wenn die Firewall den Benutzer dem Traffic zuordnen kann.

Für Management- und Portaldienste ist Device Access und Local Service ACL der zentrale Artikel. Wenn eine Regel zwar matcht, aber die Verbindung trotzdem scheitert, helfen Sophos Firewall Regel greift nicht: Ursachen prüfen und Firewall-Regel testen mit Log Viewer, Policy Test und Packet Capture.

Besonders bei gemischten IPv4-/IPv6-Netzen sollte man zusätzlich prüfen, ob eine Anwendung über IPv6 an einer engeren IPv4-Regel vorbeiläuft. Wenn IPv6 nicht aktiv genutzt wird, sollte die IPv6-Strategie trotzdem bewusst dokumentiert sein: deaktivieren, blockieren, sauber regeln oder kontrolliert einführen.

Grundprinzip und Reihenfolge

Firewall-Regeln kontrollieren Traffic zwischen Zonen und Netzwerken. Regeln erlauben, verwerfen oder blockieren Traffic und können zusätzliche Security Features anwenden.

Sophos Firewall prüft Firewall-Regeln von oben nach unten. Sobald eine Regel passt, werden nachfolgende Firewall-Regeln nicht mehr geprüft. Entscheidend ist also nicht nur, was in einer Regel steht, sondern auch, wo sie in der Regelliste steht.

Eine Regel passt nur, wenn alle relevanten Kriterien gleichzeitig zutreffen:

• Source zone: Muss passen, zum Beispiel LAN.
• Source networks and devices: Muss passen, zum Beispiel net_LAN_Clients.
• Schedule: Muss passen, zum Beispiel All the time.
• Destination zone: Muss passen, zum Beispiel WAN.
• Destination networks: Muss passen, zum Beispiel Any oder ein FQDN Host.
• Services: Müssen passen, zum Beispiel HTTP, HTTPS und DNS.
• User Matching: Muss passen, wenn es aktiviert ist, zum Beispiel AD-Gruppe Internet-Users.
• Exclusions: Können die Regel überspringen, wenn sie gesetzt sind, zum Beispiel bei einem ausgenommenen Backup-Server.

Die erste passende Regel gewinnt. Wenn eine allgemeine LAN_to_WAN_Any-Regel oberhalb einer spezifischen LAN_to_WAN_Restricted-Regel steht, wird die spezifische Regel nie erreicht.

Regelbasis vor dem Anlegen planen

Eine einzelne Firewall-Regel ist schnell erstellt. Schwieriger ist eine Regelbasis, die nach zwei Jahren noch verständlich, testbar und sicher ist. Deshalb sollte man vor neuen Regeln zuerst klären, in welche Sicherheitszone, Gruppe und Betriebslogik die Regel gehört.

Hilfreiche Leitfragen:

• Welcher Traffic soll wirklich erlaubt werden? Source, Destination und Services vor dem Anlegen notieren.
• Gehört der Traffic in eine eigene Zone? Server, Clients, Gäste, Management, VPN und DMZ bewusst trennen.
• Gibt es bereits eine spezifische Regel? Bestehende Regeln prüfen, statt eine zweite ähnliche Regel anzulegen.
• Ist NAT beteiligt? Firewall-Regel und NAT-Regel gemeinsam planen, aber nicht verwechseln.
• Wie wird später geprüft? Logging aktivieren und einen konkreten Testtraffic definieren.
• Ist die Freigabe temporär? Ablaufdatum oder Ticket in der Beschreibung dokumentieren.

Für saubere Zonen und Interfaces passt zuerst Sophos Firewall Zonen und Interfaces konfigurieren. Wenn eine bestehende Regel nicht greift, hilft die Checkliste Sophos Firewall Regel greift nicht: Ursachen prüfen.

⚠️ Eine breite Any-Regel ist oft bequem, aber selten eine gute Endkonfiguration. Für Tests kann sie kurzfristig helfen. Danach sollte sie durch konkrete Quellen, Ziele und Dienste ersetzt oder wieder entfernt werden.

Regeltypen sauber trennen

Eine gute Regelbasis trennt unterschiedliche Risiken sichtbar voneinander. Der häufigste Fehler ist nicht eine einzelne falsche Option, sondern eine Sammelregel, die Clients, Server, VPN, Gäste und Management gleichzeitig abdeckt. Das funktioniert am Anfang schnell, wird aber später schwer testbar und schwer zu härten.

• Client-Internet: Source sind Client-Netze, Ziel ist meist WAN. Web Policy, Application Control, IPS, TLS Inspection, QUIC und Logging bewusst planen.
• Server-Internet: Source sind Server-Netze, Ziele sollten definierte Update-, Backup- oder Cloud-Ziele sein. Diese Regeln sind enger als Client-Regeln und oft ohne Benutzerbezug.
• Gäste-WLAN: Source ist die Guest-Zone, Ziel meist WAN. Interne Ziele ausschliessen, Bandbreite und DNS bewusst steuern.
• Management: Source sind Admin-Netze, Ziele sind Firewall, Server, Switches oder Hypervisoren. Nicht mit normalen Client-Regeln vermischen.
• VPN Remote Access: Source ist VPN oder eine eigene Remote-Access-Zone, Ziele sind interne Zielzonen. Nur benötigte Ziele und Dienste erlauben und in der Einführungsphase loggen.
• Site-to-Site: Source sind lokale und entfernte VPN-Zonen oder XFRM-Zonen, Ziele sind Partner- oder Standortnetze. Routing, NAT, Rückweg und Logging gemeinsam prüfen.
• Veröffentlichtes System: Source ist WAN oder eine definierte Quelle, Ziel ist eine DMZ- oder Serverzone. DNAT/WAF, IPS, Logging, Patchstand und Quellbegrenzung gehören dazu.
• Temporärer Zugriff: Source ist eine definierte Support- oder Projektquelle, Ziel bleibt eng. Ticket, Ablaufdatum, Owner und Rückbau dokumentieren.

Wenn zwei Verbindungen unterschiedliche Besitzer, Schutzfunktionen oder Review-Zyklen haben, sind getrennte Regeln meist sauberer. Wenn nur ein zusätzlicher Service für denselben fachlichen Zweck nötig ist, kann eine bestehende Regel erweitert werden.

Fiktives Praxisbeispiel

Als Beispiel wird eine saubere Client-Regel erstellt:

Ziel: Clients aus dem internen LAN dürfen ins Internet. Webfilter, Application Control, IPS und Logging sollen aktiv sein. Server, Gäste und Management-Netze bekommen eigene Regeln und werden nicht mit dieser Client-Regel vermischt.

• Rule name: LAN_to_WAN_Clients, damit Quelle und Ziel sofort sichtbar sind.
• Description: Internet Access für Client-Netz, erstellt für Standard-Client-Traffic, damit später klar bleibt, warum die Regel existiert.
• Rule position: Unter spezifischen Block- und Serverregeln, damit spezifische Regeln zuerst greifen.
• Rule group: Internet Access für bessere Übersicht.
• Action: Accept, weil der definierte Traffic erlaubt werden soll.
• Log firewall traffic: Aktiviert, damit Troubleshooting im Log Viewer möglich bleibt.
• Source zones: LAN, weil der Traffic aus der LAN-Zone kommt.
• Source networks and devices: net_LAN_Clients, nicht alle LAN-Netze.
• During scheduled time: All the time, wenn Internetzugriff dauerhaft gelten soll.
• Destination zones: WAN, weil das Ziel das Internet ist.
• Destination networks: Any, für Client-Internet oft praktikabel.
• Services: HTTP, HTTPS, DNS, NTP, also nur benötigte Basisdienste.
• Web policy: Default Workplace Policy, um Webzugriffe kategoriebasiert zu steuern.
• Block QUIC protocol: Aktiviert, damit Webfilter und Scanning wirksam bleiben.
• IPS: Client-Policy für Exploit-Schutz bei ausgehendem Clienttraffic.
• App control: Client-Application-Policy, um unerwünschte Apps zu blockieren.
• Shape traffic: Optional, nur bei Bandbreitenbedarf.
• DSCP marking: Leer, ausser nachgelagerte Geräte werten DSCP aus.

Dieses Beispiel ist bewusst kein Any-Freifahrtschein. In der Praxis sollte man Client-Netze, Server-Netze, Gäste-WLAN, VoIP und Management getrennt betrachten.

Für den ersten produktiven Test sollte zu diesem Beispiel ein kurzer Testfall gehören: definierter Client, konkrete Zieladresse, erwartete Rule ID, erwartete NAT Rule ID und ein Blick in Log Viewer oder Central/Syslog. Ohne diesen Abnahmeschritt bleibt unklar, ob die Regel wirklich die erwartete Verbindung verarbeitet.

Kopfbereich: Status, Name, Action und Logging

Rule status

Rule status aktiviert oder deaktiviert die Regel.

Eine neue Regel ist normalerweise aktiv. Für vorbereitete Regeln kann man den Status deaktivieren und die Regel erst später einschalten. Deaktivierte Regeln sollten regelmässig geprüft werden, damit keine alten Test- oder Migrationsregeln in der Konfiguration liegen bleiben.

Praxisbeispiel: Eine neue Regel für einen Server wird vorbereitet, aber erst im Wartungsfenster aktiviert.

Rule name

Der Name sollte sofort verständlich machen, was die Regel tut.

Gute Namen:

• LAN_to_WAN_Clients
• Guest_to_WAN_WebOnly
• Server_to_WAN_Updates
• VoIP_to_WAN_SIP_RTP
• WAN_to_DMZ_HTTPS_Webserver

Weniger hilfreich sind Namen wie Rule1, Test, Allow oder Internet, weil man später nicht mehr erkennt, welche Aufgabe die Regel hat.

Description

Die Beschreibung ist wichtig für Betrieb, Support und Audits. Dort sollte stehen:

• warum die Regel existiert
• wer die Regel angefordert hat
• welche Einschränkungen bewusst gesetzt wurden
• ob es ein Ticket, Projekt oder Ablaufdatum gibt

Beispiel:

Internet Access für Client-Netz 10.10.10.0/24. Webfilter und IPS aktiv. Angefordert durch IT, geprüft am 10.06.2026.

Wie man dieses Feld sauber nutzt und Firewall-Regeln nachvollziehbar dokumentiert, ist im Artikel Sophos Firewall-Regeln sinnvoll dokumentieren ausführlicher beschrieben.

Rule position

Rule position legt fest, wo die neue Regel eingefügt wird.

• Top: Nur für sehr spezifische Regeln, Blockregeln oder Tests verwenden.
• Bottom: Häufig sinnvoll für neue Standardregeln.
• Above rule: Verwenden, wenn eine Regel gezielt vor einer bestehenden Regel greifen muss.
• Below rule: Verwenden, wenn eine Regel gezielt nach einer bestehenden Regel greifen soll.

Grundregel: Spezifisch vor allgemein. Eine Regel für einen einzelnen Server oder eine bestimmte Anwendung steht meist weiter oben als eine allgemeine Internetregel.

Rule group

Rule group ist eine organisatorische Gruppierung. Die Gruppe selbst ist keine Sicherheitsgrenze und keine eigene Policy-Engine. Die Firewall prüft weiterhin die einzelnen Regeln von oben nach unten.

Sinnvolle Gruppen sind zum Beispiel:

• Internet Access
• Server Rules
• DNAT
• VPN
• Guest
• Management
• Block Rules

In kleinen Umgebungen kann None ausreichen. In grösseren Umgebungen lohnt sich eine klare Gruppierung früh, weil die Regelbasis sonst schnell unübersichtlich wird.

Action

Action bestimmt, was mit passendem Traffic passiert.

• Accept: Traffic wird erlaubt. Das ist der Standard für normale Allow-Regeln.
• Drop: Traffic wird still verworfen. Sinnvoll für Blockregeln, bei denen der Client keine Antwort erhalten soll.
• Reject: Traffic wird abgelehnt und der Client erhält eine Antwort. Das ist beim Troubleshooting oder bei internen Blockregeln oft hilfreicher.
• Protect with web server protection: WAF-Schutz wird angewendet. Das gehört zur Webserver Protection, nicht zu normalen LAN-to-WAN-Regeln.

Für normale Client- oder Server-Regeln verwendet man meistens Accept. Für Blockregeln ist Drop leiser, Reject ist beim Troubleshooting oft angenehmer.

Log firewall traffic

Log firewall traffic sollte bei wichtigen Regeln fast immer aktiviert werden.

Ohne Logging fehlen später im Log viewer wichtige Informationen. Viele Troubleshooting-Fälle scheitern nicht an der Regel selbst, sondern daran, dass nicht geloggt wurde und man nicht sieht, welche Regel tatsächlich gegriffen hat.

Wichtig: Die Firewall loggt Firewall-Sessions typischerweise, wenn eine Verbindung beendet wird und ein Destroy-Event entsteht. Nicht jede Verbindung erscheint exakt in dem Moment, in dem der Client sie startet.

Damit Logs lokal, in Sophos Central oder per Syslog sichtbar sind, muss zusätzlich System services > Log settings passend konfiguriert sein. Für längere Aufbewahrung ist Sophos Central Firewall Reporting oder ein Syslog-Server sinnvoll. Mehr dazu: Central Firewall Reporting aktivieren und Sophos Firewall Syslog sicher an SIEM senden.

Für produktive Regeln sollte Logging nicht nur als Troubleshooting-Haken verstanden werden. Es ist auch die Grundlage für Reviews: Wird die Regel noch benutzt, welche Quellen treffen sie, welche Ziele werden wirklich angesprochen und ob eine Regel zu breit ist.

Quelle, Zone und Zeitplan

Im Bereich Source definiert man, woher der Traffic kommt.

Source zones

Source zones ist die Zone, aus der der Traffic kommt.

Beispiele:

• LAN für interne Client-Netze
• VPN für Remote Access Benutzer
• DMZ für Servernetze
• Guest für Gäste-WLAN
• WAN für eingehenden Internettraffic

Praxisbeispiel: Für eine Internetregel von Clients ins Internet wird LAN ausgewählt. Für eine DNAT-Regel von extern auf einen internen Server wird in der zugehörigen Firewall-Regel meist WAN als Source zone verwendet.

Source networks and devices

Source networks and devices grenzt die Quelle genauer ein.

Mögliche Objekte sind zum Beispiel:

• einzelne Hosts
• Netzwerke
• IP ranges
• Host-Gruppen
• FQDN Hosts
• Länderobjekte

Für den Anfang wirkt Any bequem, ist aber oft zu breit. Besser ist ein konkretes Client-Netz, eine Host-Gruppe oder ein klar benanntes Netzwerkobjekt.

Praxisbeispiel: Statt Any in der Source verwendet man net_LAN_Clients. Server, Drucker, Gäste und Management-Geräte bekommen eigene Regeln.

During scheduled time

During scheduled time bestimmt, wann die Regel gilt.

Typische Werte:

• All the time
• Arbeitszeiten
• Wartungsfenster
• temporäre Freigaben

Zeitpläne sind hilfreich, wenn ein Zugriff nur zu bestimmten Zeiten erlaubt sein soll. Beim Troubleshooting muss man dann aber immer prüfen, ob die Firewall-Uhrzeit, Zeitzone und Schedule wirklich passen.

Praxisbeispiel: Ein externer Wartungszugriff auf einen Server wird nur während eines definierten Wartungsfensters erlaubt.

Destination and services

Im Bereich Destination and services definiert man, wohin der Traffic darf und welche Ports oder Protokolle erlaubt sind.

Destination zones

Destination zones ist die Zielzone.

Beispiele:

• WAN für Internetzugriff
• DMZ für Server in einer DMZ
• LAN für interne Ziele
• VPN für entfernte Benutzer oder Site-to-Site-Strecken

Praxisbeispiel: Für Client-Internettraffic verwendet man WAN. Für Zugriff von Clients auf einen internen Server kann Server oder DMZ verwendet werden, wenn diese Zonen entsprechend angelegt sind.

Destination networks

Destination networks grenzt das Ziel genauer ein.

Für Client-Internetregeln ist Any oft ein praktikabler Start. Bei Servern, Management-Netzen oder VPN-Zugriffen sollte man Ziele deutlich stärker begrenzen.

Beispiele:

• Any für allgemeinen Internetzugriff
• FQDN Host wie updates.vendor.com
• Hostobjekt eines internen Servers
• Netzwerkobjekt einer Gegenstelle über VPN
• Länderobjekt für Geo-IP-Regeln

Praxisbeispiel: Ein Backup-Server darf nur zu den Cloud-Backup-Zielen des Herstellers, nicht zu Any.

Services

Services sind Protokoll- und Portdefinitionen.

Beispiele:

• HTTP für TCP 80
• HTTPS für TCP 443
• DNS für TCP/UDP 53
• NTP für UDP 123
• eigene Services wie Synology_5555

Services sollten so eng wie möglich gewählt werden. Any ist nur sinnvoll, wenn wirklich alle Protokolle erlaubt sein müssen oder wenn man bewusst mit anderen Kontrollen arbeitet.

Praxisbeispiel: Für normale Webclients reicht oft eine Gruppe mit HTTP, HTTPS, DNS und NTP. Für einen Serverzugriff aus dem Internet wird nur der tatsächlich veröffentlichte Service erlaubt.

Match known users

Mit Match known users wird Benutzeridentität Teil des Matchings. Die Regel gilt dann nicht mehr nur für IP-Adressen, sondern für bekannte Benutzer oder Gruppen.

Das ist sinnvoll, wenn:

• Web Policies pro AD-Gruppe greifen sollen
• Reporting benutzerbezogen sein soll
• unterschiedliche Benutzergruppen unterschiedliche Internetrechte bekommen
• MFA, Captive Portal oder SSO bereits sauber eingerichtet sind

Stolperstein: Wenn Authentifizierung nicht sauber funktioniert, matcht die Regel eventuell nicht. Dann fällt der Traffic auf eine allgemeinere Regel darunter oder wird durch die Drop-all-Regel verworfen.

Für erste Tests ist es oft besser, ohne User Matching zu starten und Benutzerkriterien erst später zu ergänzen.

Wenn User Matching genutzt wird, sollte darunter keine breite Fallback-Regel liegen, die denselben Traffic ohne Benutzerbezug erlaubt. Sonst wirkt die Benutzerregel zwar sauber, aber unbekannte Benutzer landen trotzdem auf der allgemeinen Regel. Bei der Abnahme sollte der Log Viewer deshalb Benutzer, Gruppe und Rule ID zeigen.

Add exclusion

Mit Add exclusion kann Traffic aus einer Regel ausgenommen werden. Die Firewall überspringt diese Regel nur dann, wenn alle gesetzten Exclusion-Kriterien passen, und prüft danach die nächste Regel.

Exclusions können Source zones, Source networks and devices, Destination zones, Destination networks und Services enthalten.

Praxisbeispiel: Eine allgemeine Client-Internetregel verwendet Webfilter. Ein bestimmter Update-Server soll aber über eine eigene Regel mit anderen Security Features laufen. Dann kann man diesen Server aus der allgemeinen Regel ausnehmen.

Exclusions sind mächtig, aber sie machen Regeln schwerer lesbar. Wenn eine Regel viele Ausnahmen enthält, ist eine separate spezifische Regel oft verständlicher.

Create linked NAT rule

Mit Create linked NAT rule kann direkt aus der Firewall-Regel eine Source NAT-Regel erzeugt werden. Diese Linked NAT Rule erscheint anschliessend in der NAT-Regeltabelle.

Für Einsteiger klingt das bequem, in der Praxis sind eigenständige NAT-Regeln meistens übersichtlicher. Wenn bereits eine generische NAT-Regel denselben Traffic sauber abdeckt, sollte man keine zusätzliche Linked NAT Rule erstellen.

Für eine normale Client-zu-Internet-Regel reicht meistens die Default-SNAT-Regel mit MASQ, solange sie aktiv ist und korrekt zur Regelbasis passt.

Wichtig: NAT erlaubt keinen Traffic von selbst. NAT übersetzt Adressen oder Ports. Ob Traffic erlaubt ist, entscheidet weiterhin die passende Firewall-Regel.

Mehr dazu: NAT auf Sophos Firewall verstehen: SNAT, DNAT, MASQ, PAT.

Web filtering

Im Bereich Web filtering werden Web Policy, Malware Scan und das Webfilter-Verhalten konfiguriert.

Web policy

Web policy steuert Webzugriffe über Kategorien, Benutzer, Gruppen, URL-Gruppen und Regeln.

Praxisbeispiel: Für Clients wird eine Web Policy verwendet, die Malware, Phishing, Adult Content und riskante Kategorien blockiert, aber Business-Anwendungen erlaubt.

Wenn keine Web Policy gesetzt ist, findet kein kategoriebasiertes Webfiltering über diese Option statt.

Wie man Kategorien, URL-Gruppen, Web Policies und Instant Alerts zusammen plant, ist in Sophos Firewall Web-Kategorien und Instant Alerts nutzen beschrieben.

Apply web category-based traffic shaping

Diese Option wendet Traffic Shaping anhand von Web-Kategorien an. Sinnvoll ist sie nur, wenn entsprechende Traffic-Shaping-Regeln oder Web-Kategorie-Policies verwendet werden.

Praxisbeispiel: Streaming-Kategorien werden limitiert, Business-Anwendungen bleiben bevorzugt.

Block QUIC protocol

QUIC nutzt UDP 80 und UDP 443. Viele Browser verwenden QUIC für Google-Dienste und andere moderne Webanwendungen.

Wenn Webfiltering oder Malware Scan auf Webtraffic wichtig ist, sollte Block QUIC protocol in vielen Umgebungen aktiviert bleiben. Browser fallen dann in der Regel auf normales HTTPS über TCP zurück, das sich besser kontrollieren und prüfen lässt.

Mehr dazu: Sophos Firewall QUIC und HTTP/3 richtig blockieren.

Scan HTTP and decrypted HTTPS

Diese Option scannt HTTP und bereits entschlüsseltes HTTPS auf Malware.

Wichtig: Diese Option entschlüsselt HTTPS nicht automatisch. Damit HTTPS wirklich geprüft werden kann, braucht es passende SSL/TLS inspection rules unter Rules and policies > SSL/TLS inspection rules.

Praxisbeispiel: Wenn TLS Inspection für LAN_to_WAN_Clients aktiv ist, kann Scan HTTP and decrypted HTTPS heruntergeladene Dateien im entschlüsselten HTTPS-Traffic prüfen.

Mehr dazu: TLS Inspection auf Sophos Firewall schrittweise ausrollen.

Use Zero-day protection

Use Zero-day protection sendet verdächtige Downloads zur weiteren Analyse an Sophos Zero-Day Protection. Das ist sinnvoll für Client- und Serverregeln, bei denen Downloads aus dem Internet geprüft werden sollen.

Die Funktion benötigt eine passende Lizenz und kann je nach Dateityp und Policy zu Verzögerungen führen.

Scan FTP for malware

Diese Option scannt FTP-Traffic auf Malware. Relevant ist sie nur, wenn FTP tatsächlich verwendet wird und die passenden Services in der Regel erlaubt sind.

In modernen Umgebungen ist FTP seltener geworden, aber bei Legacy-Systemen, Maschinensteuerungen oder älteren Update-Mechanismen kommt es noch vor.

Use web proxy instead of DPI engine

Sophos Firewall kann Webtraffic über den DPI engine oder über den Web Proxy prüfen.

Für moderne Setups ist DPI meistens die bessere Standardwahl, weil HTTP und SSL/TLS Traffic auf allen Ports verarbeitet werden kann. Der Web Proxy ist weiterhin sinnvoll, wenn spezielle Proxy-Funktionen benötigt werden, zum Beispiel SafeSearch-Erzwingung, YouTube-Restriktionen, Google-App-Domain-Beschränkung, Pharming Protection, Web Cache oder Parent Proxy.

Wenn Use web proxy instead of DPI engine nicht aktiviert ist, arbeitet die Regel im DPI-Modus.

Decrypt HTTPS during web proxy filtering

Diese Option gehört zum Web-Proxy-Modus. Relevant ist sie nur, wenn Use web proxy instead of DPI engine aktiviert ist und HTTPS im Proxy-Modus entschlüsselt werden soll.

Im DPI-Modus wird HTTPS-Decryption nicht hier gesteuert, sondern über SSL/TLS inspection rules.

Synchronized Security Heartbeat

Mit Configure Synchronized Security Heartbeat kann der Sophos Endpoint-Status in die Firewall-Regel einbezogen werden.

Typische Möglichkeiten:

• Mindeststatus für Quellgeräte festlegen
• Clients ohne Heartbeat blockieren
• Mindeststatus für Zielgeräte festlegen
• Anfragen an Ziele ohne Heartbeat blockieren

Das ist stark, aber nur sinnvoll, wenn Sophos Endpoint, Sophos Central und Security Heartbeat sauber eingerichtet sind.

Praxisbeispiel: Clients mit rotem Security Heartbeat dürfen nicht mehr auf Server zugreifen oder bekommen keinen Internetzugriff mehr.

Für eine erste Client-Regel sollte man Heartbeat nicht blind aktivieren, sonst blockiert man unter Umständen Geräte, die gar keinen Heartbeat senden können.

Other security features

Identify and control applications (App control)

Über Identify and control applications (App control) wird eine Application Filter Policy ausgewählt.

Damit lassen sich Anwendungen erkennen und steuern, zum Beispiel:

• TeamViewer
• Tor
• Messenger
• Streaming
• Cloud Storage
• Remote-Control-Tools

Application Control benötigt eine passende Lizenz. In der Praxis ist diese Funktion in den Sophos Firewall Bundles mit Web Protection enthalten, zum Beispiel Standard Protection, Xstream Protection oder Epic Protection.

Für Anwendungserkennung bei verschlüsseltem Traffic ist TLS Inspection oft entscheidend. Ohne Decryption sieht die Firewall je nach Dienst nur Hostnamen, SNI, Zertifikatsinformationen oder IPs und nicht den vollständigen Inhalt.

Der eigene Ablauf für Filter, Regelbindung, Logs und False-Positive-Prüfung steht in Sophos Firewall Application Control einrichten und testen.

Apply application-based traffic shaping policy

Diese Option wendet Traffic Shaping an, das in der Application Policy oder beim Application Object definiert wurde.

Praxisbeispiel: Microsoft Teams soll erkannt und mit einer bestimmten Traffic-Shaping-Policy priorisiert werden. Dann muss die passende Application Control Policy gewählt sein und die application-based traffic shaping policy angewendet werden.

Wenn man im Feld Shape traffic bereits eine explizite Traffic Shaping Policy setzt, sollte klar dokumentiert sein, welche Policy Vorrang haben soll und warum.

Detect and prevent exploits (IPS)

Unter Detect and prevent exploits (IPS) wird eine IPS Policy ausgewählt.

IPS prüft Traffic auf bekannte Angriffsmuster und Exploits. Für Clienttraffic ins Internet verwendet man eine andere Policy als für Servertraffic oder veröffentlichte Dienste.

Praxisbeispiele:

• Client-Regel LAN_to_WAN: Client- oder LAN-to-WAN-IPS-Policy
• DNAT-Regel zu Webserver: Server- oder Webserver-IPS-Policy
• VoIP-Regel: Vorsichtig testen, weil aggressive IPS-Profile VoIP stören können

IPS sollte nicht einfach überall mit der härtesten Policy aktiviert werden. Eine zu breite oder falsche IPS Policy kann legitimen Traffic brechen oder unnötig Last erzeugen.

Der eigene Artikel Sophos Firewall IPS einrichten und sicher testen erklärt globale Aktivierung, Lizenzstatus, Policy-Auswahl, Logging und False-Positive-Analyse detaillierter.

Shape traffic

Mit Shape traffic kann eine Traffic Shaping Policy direkt auf die Regel angewendet werden.

Das ist relevant für:

• VoIP
• Online-Meetings
• Backup-Traffic
• Gäste-WLAN
• langsame WAN-Strecken

Praxisbeispiel: Gäste-WLAN bekommt eine Limit-Policy, damit es Business-Traffic nicht verdrängt.

Mehr dazu: Application Traffic Shaping auf Sophos Firewall konfigurieren.

DSCP marking

DSCP marking markiert Pakete für Quality-of-Service auf nachgelagerten Netzwerkgeräten.

Das ist nur sinnvoll, wenn Switches, Router oder WAN-Geräte diese DSCP-Werte auch auswerten. Die Sophos Firewall kann markieren, aber das restliche Netzwerk muss diese Markierungen konsistent behandeln.

Praxisbeispiel: VoIP-Traffic bekommt eine DSCP-Markierung, damit Switches und WAN-Router diesen Traffic bevorzugt behandeln.

Scan with NDR Active threat intelligence

Scan with NDR Active threat intelligence nutzt Sophos NDR Threat Intelligence zur zusätzlichen Bewertung von Netzwerktraffic.

Diese Option ist nur sinnvoll, wenn die Umgebung die benötigten Sophos Central- und NDR-Komponenten verwendet. In vielen Umgebungen ist sie nicht die erste Option für eine Basisregel, aber sie kann in stärker überwachten Netzwerken ein wertvoller Zusatz sein.

Scan email content

Der Bereich Scan email content betrifft E-Mail-Protokolle.

Mögliche Optionen:

• Scan IMAP
• Scan IMAPS
• Scan POP3
• Scan POP3S
• Scan SMTP
• Scan SMTPS

Wenn man dort Protokolle aktiviert, müssen die passenden Standardports auch in den Services der Regel enthalten sein oder über Add ports ergänzt werden.

Für normale Web-Client-Regeln ist dieser Bereich oft nicht relevant. Für Mailserver oder Client-Mailtraffic sollte man ihn bewusst planen.

Praxisbeispiel: Ein interner Mailserver darf SMTP nach extern senden. Dann wird eine eigene Server-Regel erstellt, Logging aktiviert und E-Mail-Scanning passend zur Mailarchitektur geprüft.

Nach dem Speichern prüfen

Nach dem Speichern sollte man die Regel testen und nicht einfach davon ausgehen, dass alles korrekt funktioniert.

Zu prüfen:

1. Steht die Regel an der richtigen Position?
2. Ist Log firewall traffic aktiv?
3. Wurde bei geänderten Regeln der Trefferzähler zurückgesetzt oder ein klarer neuer Test erzeugt?
4. Matcht die Regel im Log viewer?
5. Wird die erwartete Firewall Rule ID angezeigt?
6. Greift die gewünschte NAT-Regel?
7. Funktioniert DNS?
8. Werden Webfilter, IPS, Application Control und TLS Inspection wie erwartet angewendet?
9. Gibt es unerwartete Drops oder SSL/TLS Fehler?

Für eine saubere Prüfung hilft der Artikel Firewall-Regel testen mit Log Viewer, Policy Test und Packet Capture.

Bei produktiven Änderungen ist ein kleiner Vorher-nachher-Vergleich sinnvoll:

• Backup oder Restore-Punkt vorhanden: Rückbau bleibt möglich, wenn die Regel Nebenwirkungen erzeugt.
• Audit Trail oder Change-Ticket notiert: Später ist klar, wer die Änderung wann gemacht hat.
• Testfall vorher definiert: Erfolg wird nicht nur nach Gefühl bewertet.
• Nur eine Änderung pro Test: Ursache und Wirkung bleiben nachvollziehbar.
• Log Viewer oder zentrale Logs geprüft: Die echte Rule ID und NAT ID sind sichtbar.
• Rückbauentscheidung dokumentiert: Temporäre Testregeln bleiben nicht dauerhaft aktiv.

Bei mehreren Firewalls oder zentral verwalteten Gruppen sollte zusätzlich geprüft werden, ob die Änderung auf der richtigen Appliance oder Gruppe angekommen ist. Für Sophos Central hilft die Firewall Management Task Queue, lokale Änderungen lassen sich mit Audit Trail Logs nachvollziehen.

Regelbetrieb und Review

Eine Firewall-Regel ist nicht fertig, nur weil sie gespeichert wurde. Gute Regeln haben einen klaren Zweck, werden geloggt, sind testbar und werden später wieder überprüft. Gerade in gewachsenen Umgebungen entstehen viele Risiken nicht durch eine einzelne falsche Regel, sondern durch alte Ausnahmen, zu breite Services oder Regeln ohne Besitzer.

Für regelmässige Reviews lohnt sich eine einfache Routine:

• Wird die Regel noch getroffen? Unbenutzte Regeln können oft deaktiviert und später entfernt werden.
• Ist die Source noch korrekt? Client-Netze, Servernetze und VPN-Bereiche ändern sich mit der Zeit.
• Ist Any noch begründet? Breite Quellen, Ziele oder Services sollten bewusst dokumentiert sein.
• Ist Logging aktiv und sinnvoll? Ohne Logs sind spätere Analysen und Audits deutlich schwächer.
• Passen NAT, Webfilter, IPS und TLS Inspection noch? Security Features können nach Upgrades, App-Änderungen oder Zertifikatswechseln anders wirken.
• Gibt es ein Ablaufdatum? Temporäre Projekt- oder Supportregeln bleiben sonst dauerhaft aktiv.

Bei kritischen Regeln sollte man zusätzlich dokumentieren, wer fachlich verantwortlich ist. Das ist besonders wichtig für veröffentlichte Dienste, VPN-Regeln, Managementzugriffe, Dienstleisterfreigaben und Regeln mit Any bei Services oder Destination.

Neue Regel, bestehende Regel ändern oder deaktivieren?

Nicht jede neue Anforderung braucht sofort eine neue Firewall-Regel. Zu viele ähnliche Regeln machen die Liste unübersichtlich, aber zu stark zusammengefasste Regeln werden schnell zu breit. Eine einfache Entscheidung hilft, bevor man im WebAdmin etwas speichert:

• Gleiche Source, gleiche Destination, gleicher Zweck, nur ein zusätzlicher Service: Bestehende Regel erweitern. Die Regel bleibt fachlich zusammenhängend und leichter testbar.
• Gleiche Netze, aber anderer Schutzbedarf, anderes Logging oder anderer Owner: Eigene Regel erstellen. Webfilter, IPS, TLS Inspection, NDR oder Logging können getrennt geprüft werden.
• Temporärer Dienstleister- oder Supportzugriff: Eigene befristete Regel erstellen. Owner, Ticket, Ablaufdatum und Testfenster bleiben klar sichtbar.
• Server, Gäste, VoIP, IoT oder Management sind betroffen: Eigene Regel oder eigene Zone prüfen. Unterschiedliche Risiken sollten nicht in einer Client-Internetregel verschwinden.
• Eine Regel ist unklar oder alt: Erst deaktivieren und beobachten. Direktes Löschen nimmt die Möglichkeit, Treffer, Logs und Abhängigkeiten kontrolliert zu prüfen.
• Eine Regel ist nach einem Review sicher überflüssig: Entfernen nach Backup und Dokumentation. Das Regelwerk wird kleiner, ohne blind funktionierende Abhängigkeiten zu brechen.

Für normale Betriebsänderungen ist dieser Ablauf robust:

1. Zweck, Owner, Ticket und erwarteten Traffic notieren.
2. Vorhandene Regeln nach gleicher Source, Destination, Service und Rule group prüfen.
3. Entscheiden, ob eine bestehende Regel erweitert oder eine eigene Regel sauberer ist.
4. Bei produktiven Änderungen Backup, Audit Trail und Testfall einplanen.
5. Nach dem Speichern Log Viewer, Rule ID, NAT-Entscheidung und betroffene Security Features prüfen.

Wenn die Entscheidung vor allem an fehlender Dokumentation scheitert, sollte zuerst Sophos Firewall-Regeln sinnvoll dokumentieren nachgezogen werden. Wenn unklar ist, ob eine bestehende Regel überhaupt noch gebraucht wird, hilft ein kontrollierter Test mit Firewall-Regel testen mit Log Viewer, Policy Test und Packet Capture.

Trefferzähler richtig einordnen

Trefferzähler helfen beim Aufräumen, sind aber kein vollständiger Nachweis. Eine selten genutzte Notfallregel kann trotzdem wichtig sein. Umgekehrt kann eine breite Regel viele Treffer haben, obwohl sie zu viel erlaubt.

Für Reviews sollte man Trefferzähler immer mit Log Viewer, Regelbeschreibung und tatsächlichem Use Case verbinden. Wenn eine Regel unklar ist, sollte sie nicht sofort gelöscht werden. Besser ist ein kontrollierter Ablauf: Zweck klären, Logging aktivieren, Testfenster definieren, Stakeholder informieren und erst danach deaktivieren oder entfernen.

Änderungen nachvollziehbar machen

Vor grösseren Regelwerksänderungen sollte ein Backup vorhanden sein. Danach helfen Audit Trail und Config Studio, Unterschiede nachvollziehbar zu prüfen. Der praktische Ablauf steht in Sophos Firewall Audit Trail Logs prüfen und Sophos Firewall Config Studio nutzen.

Wenn viele Regeln angepasst werden, sollte man nicht nur die Konfiguration vergleichen, sondern auch echte Testfälle ausführen. Eine Regel kann syntaktisch korrekt sein und trotzdem falschen Traffic erlauben, den falschen NAT-Pfad verwenden oder eine Anwendung durch IPS, Webfilter oder TLS Inspection stören.

Typische Fehler

Die Regel steht zu weit unten: Eine allgemeinere Regel darüber matcht den Traffic zuerst.

Source ist zu breit: Any funktioniert zwar, macht Regeln aber unklar und erhöht die Angriffsfläche.

Destination ist zu breit: Server oder Management-Netze sollten selten mit Any ins Internet dürfen.

Services sind zu breit: Any erlaubt deutlich mehr als nötig. Besser sind konkrete Services oder Service-Gruppen.

Logging ist nicht aktiv: Im Log Viewer fehlen dann die wichtigsten Informationen.

IPv6 wurde vergessen: IPv4 ist sauber geregelt, aber IPv6 läuft über andere Regeln oder bleibt unbewusst offen.

Rule group wird mit Sicherheit verwechselt: Eine Regelgruppe verbessert nur die Übersicht. Eine Regelgruppe ist keine eigene Sicherheitsgrenze und ändert die Auswertungslogik nicht.

HTTPS wird nicht gescannt: Scan HTTP and decrypted HTTPS ist aktiv, aber es gibt keine passende SSL/TLS inspection rule oder keine Decryption.

Webfilter greift nicht: Keine Web Policy gesetzt, falscher User, falsche Source zone oder QUIC nicht blockiert.

User Matching greift nicht: Authentifizierung, AD SSO, Captive Portal oder User-Zuordnung funktionieren nicht sauber.

NAT fehlt: Die Firewall-Regel erlaubt den Traffic, aber SNAT/MASQ passt nicht.

Security Feature passt nicht zum Traffic: Eine falsche IPS Policy, Proxy-Option oder E-Mail-Scan-Option kann legitimen Traffic brechen.

Wenn nach diesen Punkten unklar bleibt, warum Traffic anders läuft als erwartet, sollte man strukturiert mit Log Viewer, Policy tester und Packet Capture weiterprüfen. Der passende Ablauf steht in Firewall-Regel testen mit Log Viewer, Policy Test und Packet Capture.

FAQ