Sophos Firewall-Regeln verstehen und richtig konfigurieren

Firewall-Regeln sind das Herzstück der Sophos Firewall. Sie entscheiden, 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

Schnellnavigation

• Grundprinzip und Reihenfolge
• Fiktives Praxisbeispiel
• Kopfbereich: Status, Name, Action und Logging
• Source
• 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
• Typische Fehler

Grundprinzip und Reihenfolge

Firewall-Regeln kontrollieren Traffic zwischen Zonen und Netzwerken. Sie 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:

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.

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.

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

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 Wie man eine Sophos Firewall Regel einfach dokumentiert ausführlicher beschrieben.

Rule position

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

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.

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.

Source

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.

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.

Apply web category-based traffic shaping

Diese Option wendet Traffic Shaping anhand von Web-Kategorien an. Sie ist nur sinnvoll, 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.

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. Sie ist nur relevant, 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. Sie ist nur relevant, 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.

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.

Shape traffic

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

Das ist relevant für:

• VoIP
• Videokonferenzen
• 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.

Prüfe:

1. Steht die Regel an der richtigen Position?
2. Ist Log firewall traffic aktiv?
3. Matcht die Regel im Log viewer?
4. Wird die erwartete Firewall Rule ID angezeigt?
5. Greift die gewünschte NAT-Regel?
6. Funktioniert DNS?
7. Werden Webfilter, IPS, Application Control und TLS Inspection wie erwartet angewendet?
8. 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.

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.

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.