Sophos Firewall-Regeln verstehen und sicher konfigurieren

Eine Sophos-Firewall-Regel entscheidet, welcher Traffic zwischen Zonen, Netzen, Benutzern und Diensten erlaubt oder blockiert wird. Entscheidend sind nicht möglichst viele aktivierte Optionen, sondern passende Match-Kriterien, die richtige Reihenfolge, angemessene Schutzfunktionen und ein nachvollziehbarer Test.

Der Menüpfad lautet:

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

Dieser Artikel erklärt die Regelmaske von oben bis unten und verwendet durchgehend das Beispiel LAN_to_WAN_Clients. Spezialthemen wie NAT, TLS Inspection oder IPS werden so weit erklärt, wie es für die Firewall-Regel nötig ist; die Detailanleitungen sind direkt an der passenden Stelle verlinkt.

Vor dem Anlegen planen

Zuständigkeit richtig einordnen

Normale Firewall-Regeln steuern weitergeleiteten Traffic, der durch die Firewall fliesst. Andere Aufgaben werden an anderen Stellen konfiguriert:

• Lokale Firewall-Dienste: WebAdmin, User Portal, VPN Portal, SSH, DNS und SNMP werden über Administration > Device access, Local Service ACL und die jeweilige Dienstkonfiguration gesteuert. Dafür ist Device Access und Local Service ACL zuständig.
• Systemgenerierter Traffic: Verbindungen, welche die Firewall selbst erzeugt, benötigen keine normale Firewall-Regel. Massgeblich sind Dienstkonfiguration, Routing, WAN Link Manager und gegebenenfalls SD-WAN für System Traffic.
• Adress- und Portübersetzung: NAT übersetzt Traffic, erlaubt ihn aber nicht. Firewall- und NAT-Regel müssen gemeinsam passen.
• Routing und Rückweg: Eine passende Firewall-Regel beweist noch nicht, dass Routing, SD-WAN, VPN oder der Rückweg stimmen.
• Weblogik: Webkategorien, URL-Gruppen und Aktionen stehen in der Web Policy. Die Firewall-Regel bindet diese Policy ein.
• HTTPS-Entschlüsselung: Eine SSL/TLS inspection rule entschlüsselt den Traffic. Scan HTTP and decrypted HTTPS scannt nur bereits entschlüsseltes HTTPS.
• Benutzeridentität: AD SSO, STAS, Captive Portal, Entra ID SSO oder RADIUS müssen den Benutzer zuerst zuverlässig dem Traffic zuordnen. Geräte ohne Login lassen sich bei einer festen, eindeutigen IP als Clientless Users einrichten; diese Zuordnung ist keine Authentifizierung.

Managementzugriffe durch die Firewall auf Server, Switches oder Hypervisoren gehören in normale Firewall-Regeln. Der Zugriff auf die Firewall selbst gehört dagegen zu Device Access.

Reihenfolge, IPv4 und IPv6

Sophos Firewall prüft Regeln von oben nach unten. Sobald alle Match-Kriterien einer Regel passen, werden nachfolgende Regeln nicht mehr ausgewertet. Eine allgemeine LAN_to_WAN_Any-Regel oberhalb von LAN_to_WAN_Restricted macht die spezifische Regel deshalb wirkungslos.

Eine Regel kann unter anderem nach Source zone, Source network, Zeitplan, Destination zone, Destination network, Service, Benutzer und Exclusions matchen. Alle konfigurierten Kriterien müssen zur Verbindung passen.

Automatisch erzeugte MTA-, IPsec- oder Hotspot-Regeln können oben in der Liste erscheinen. Nach Assistenten, Migrationen oder VPN-Änderungen sollte die Reihenfolge deshalb erneut geprüft werden. Beim Sophos Firewall Hotspot gehört diese Kontrolle ausdrücklich zum Einrichtungsablauf. Findet SFOS keine passende Regel, greift unten die implizite Drop-all-Regel mit Firewall Rule ID #0. Sie zeigt keinen Usage Count; der verworfene Traffic wird als Ereignis geloggt.

IPv4- und IPv6-Regeln werden getrennt verwaltet. Eine funktionierende IPv4-Regel schützt nicht automatisch denselben Dienst über IPv6. In Dual-Stack-Umgebungen müssen beide Regelwerke bewusst geplant und getestet werden.

Regelbasis sauber trennen

Vor dem Anlegen sollten Source, Destination, Services, Owner und Testfall feststehen. Unterschiedliche Risiken gehören nicht in eine Sammelregel:

• Client-Internet: Client-Netze zur WAN-Zone, mit passender Web Policy, Application Control, IPS und Logging.
• Server-Internet: Nur benötigte Update-, Backup- oder Cloud-Ziele; meist ohne Benutzerbezug.
• Gäste-WLAN: Guest-Zone zum Internet, ohne interne Ziele und bei Bedarf mit Bandbreitenlimit.
• Management: Definierte Adminnetze zu Servern und Infrastruktur, getrennt vom normalen Clienttraffic.
• Remote Access VPN: VPN-Zone zu den tatsächlich benötigten internen Zielen und Diensten.
• Site-to-Site: Lokale und entfernte Netze mit passendem Routing, NAT und Rückweg.
• Veröffentlichte Systeme: WAN zu DMZ oder Serverzone mit enger Quelle, DNAT oder WAF, IPS, Logging und aktuellem Patchstand.
• Temporäre Freigaben: Eigene Regel mit Ticket, Owner, Ablaufdatum und geplantem Rückbau.

Für die Netzstruktur hilft Sophos Firewall Zonen und Interfaces konfigurieren.

⚠️ Any kann für einen kurzen Test helfen, ist aber selten eine gute Endkonfiguration. Danach sollte die Regel auf die wirklich benötigten Quellen, Ziele und Services begrenzt oder wieder entfernt werden.

Praxisbeispiel LAN_to_WAN_Clients

Im Beispiel dürfen Clients aus einem definierten LAN ins Internet. Server, Gäste, VoIP und Management erhalten eigene Regeln.

• Rule name: LAN_to_WAN_Clients
• Description: Internetzugriff für Client-Netz. Webfilter, App Control und IPS aktiv. Owner IT, Review 2026-12-01.
• Rule position: Bottom, danach unterhalb spezifischer Block- und Sonderregeln einsortieren
• Rule group: Internet Access
• Action: Accept
• Log firewall traffic: aktiviert
• Source zones: LAN
• Source networks and devices: net_LAN_Clients
• During scheduled time: All the time
• Destination zones: WAN
• Destination networks: Any
• Services: HTTP, HTTPS sowie nur die tatsächlich direkt extern verwendeten Basisdienste
• Web policy: Default Workplace Policy
• Block QUIC protocol: aktiviert
• IPS: passende Client-Policy
• App control: passende Client-Application-Policy
• Shape traffic: nur bei einem konkreten Bandbreitenziel
• DSCP marking: nur wenn nachgelagerte Geräte die Markierung auswerten

DNS und NTP gehören nur dann in diese LAN-to-WAN-Regel, wenn Clients externe Resolver oder Zeitserver direkt ansprechen. Nutzen sie die Firewall als DNS- oder Zeitdienst, handelt es sich um lokalen Traffic.

Zur Abnahme gehören ein definierter Client, ein konkretes Ziel, die erwartete Firewall Rule ID, die erwartete NAT Rule ID und ein Blick in den Log Viewer. So wird nicht nur geprüft, ob die Anwendung funktioniert, sondern auch, ob sie von den vorgesehenen Regeln verarbeitet wird.

Firewall-Regel konfigurieren

Kopfbereich

Rule status, Rule name und Description

Rule status ist bei einer neuen Regel standardmässig aktiv. Vorbereitete Regeln können bis zum Wartungsfenster deaktiviert bleiben. Dauerhaft deaktivierte Test- oder Migrationsregeln sollten regelmässig überprüft werden.

Der Name sollte Source, Destination und Zweck erkennen lassen, zum Beispiel:

• LAN_to_WAN_Clients
• Guest_to_WAN_WebOnly
• Server_to_WAN_Updates
• VoIP_to_WAN_SIP_RTP
• WAN_to_DMZ_HTTPS_Webserver

Die Description dokumentiert Zweck, Owner, Ticket, Einschränkungen und gegebenenfalls das Ablaufdatum. Rule1, Allow oder Internet helfen im späteren Betrieb kaum. Der eigene Ablauf steht unter Sophos Firewall-Regeln sinnvoll dokumentieren.

Rule position und Rule group

Beim Anlegen bietet Rule position in SFOS 22 Top oder Bottom. Danach kann die Regel in der Regeltabelle verschoben oder mit Move To gezielt positioniert werden. Top sollte nur gewählt werden, wenn eine spezifische Regel bewusst vor bestehenden Regeln greifen muss.

Rule group verbessert die Übersicht, verändert aber nicht die Match-Logik. None ist der Standard. Bei Automatic ordnet SFOS die Regel anhand des ersten passenden Regeltyps und der Source-/Destination-Zonen einer vorhandenen Gruppe zu. Die Firewall wertet weiterhin die einzelnen Regeln von oben nach unten aus.

Action und Logging

Action legt die Behandlung passenden Traffics fest:

• Accept: erlaubt die Verbindung.
• Drop: verwirft sie normalerweise ohne Antwort. Ist Use web authentication for unknown users aktiv, kann SFOS bei Webtraffic stattdessen eine Blockseite anzeigen.
• Reject: verwirft sie und sendet bei TCP einen Reset beziehungsweise bei UDP und ICMP eine passende ICMP-Antwort.
• Protect with web server protection: erstellt eine WAF-Regel. Diese Option ist nur für IPv4 verfügbar und benötigt Webserver Protection. Die Konfiguration gehört fachlich zu Sophos Firewall WAF.

Drop eignet sich für stilles Verwerfen; Reject liefert bei internen Tests oder beim Troubleshooting schneller eine erkennbare Rückmeldung.

Log firewall traffic sollte bei wichtigen Regeln aktiv sein. Zusätzlich müssen unter System services > Log settings die passenden lokalen, Sophos-Central- oder Syslog-Ziele aktiviert sein. Ohne Destroy-Ereignis kann eine Session ohne abschliessenden Session-Log bleiben, beispielsweise bei einem abrupten Leitungsausfall.

Für längere Aufbewahrung eignen sich Central Firewall Reporting oder ein Syslog-/SIEM-Server. Logging dient nicht nur dem Troubleshooting, sondern auch dem Review: Welche Quellen treffen die Regel, welche Ziele werden verwendet und ist die Freigabe noch angemessen?

Dasselbe Kontrollkästchen ist die Datenquelle für NetFlow v5 auf der Sophos Firewall: Ohne Log firewall traffic exportiert NetFlow die Verbindungen dieser Regel nicht.

Source, Destination und Services

Im Bereich Source wird festgelegt, woher der Traffic kommt:

• Source zones: zum Beispiel LAN, VPN, DMZ, Guest oder WAN.
• Source networks and devices: einzelne Hosts, Netze, IP-Ranges, Gruppen, FQDN Hosts oder Länderobjekte.
• During scheduled time: All the time, Arbeitszeiten oder ein Wartungsfenster.

Die Zone allein ist meist zu breit. Für das Clientbeispiel wird deshalb LAN mit net_LAN_Clients kombiniert. Bei zeitgesteuerten Regeln müssen Firewall-Uhrzeit, Zeitzone und Schedule zusammenpassen.

Wie wiederkehrende und einmalige Zeitfenster erstellt, zugewiesen und an den Umschaltgrenzen geprüft werden, zeigt Sophos Firewall Zeitpläne für Regeln und Policies einrichten.

Unter Destination and services stehen:

• Destination zones: zum Beispiel WAN, DMZ, LAN oder VPN.
• Destination networks: Any, ein Host, ein Netz, eine Gruppe, ein Länderobjekt oder ein FQDN Host.
• Services: Protokoll- und Portdefinitionen wie HTTP, HTTPS, DNS, NTP oder ein eigener Service.

Wie IP-Hosts, Netze, Ranges, Listen, Services und Gruppen angelegt und vor Änderungen geprüft werden, erklärt Sophos Firewall Hosts und Services richtig verwenden.

Any kann bei einer allgemeinen Client-Internetregel vertretbar sein. Server-, Management- und VPN-Regeln sollten deutlich engere Ziele und Services verwenden. Bei dynamischen Cloudzielen helfen gegebenenfalls FQDN Hosts und Wildcard-FQDNs.

Benutzer, Exclusions und Linked NAT

Match known users

Mit Match known users werden Benutzer oder Gruppen zu Match-Kriterien. Danach stehen abhängig von der Konfiguration weitere Felder zur Verfügung:

• Use web authentication for unknown users: leitet unbekannte Webbenutzer zu AD SSO oder Captive Portal um. Die Authentifizierung und der Zugriff aus der betroffenen Zone müssen zuvor konfiguriert sein. Wie Authentifizierung, Device Access, DNS-Voraussetzung und Benutzerregel zusammenspielen, zeigt Sophos Firewall Captive Portal einrichten und testen.
• Users or groups: begrenzt die Regel auf ausgewählte Identitäten.
• Exclude this user activity from data accounting: nimmt den Traffic dieser Benutzer aus der individuellen Datenverbrauchserfassung aus.

Eine Benutzerregel funktioniert nur mit zuverlässiger Benutzerzuordnung. Unterhalb sollte keine breite Fallback-Regel denselben Traffic ohne Benutzerbezug erlauben. Bei der Abnahme müssen Benutzer, Gruppe und Rule ID im Log Viewer zusammenpassen.

Add exclusion

Add exclusion nimmt Traffic aus dieser Regel aus. SFOS überspringt die Regel nur, wenn alle konfigurierten Exclusion-Kriterien gemeinsam passen, und prüft danach die nächste Regel.

Als Kriterien stehen Source zones, Source networks and devices, Destination zones, Destination networks und Services zur Verfügung.

Eine sinnvolle Ausnahme wäre ein Update-Server, der aus einer allgemeinen Clientregel ausgeschlossen wird und oberhalb eine eigene Regel mit anderen Schutzfunktionen erhält. Werden Exclusions zahlreich oder schwer verständlich, ist eine separate spezifische Regel meist besser.

Create linked NAT rule

Eine Linked NAT Rule ist eine Source-NAT-Regel, die nur für den Traffic der verknüpften Firewall-Regel gilt. In der NAT-Regel lassen sich im Wesentlichen die übersetzte Source und die interface-spezifische Source-Translation festlegen.

Die Factory-Konfiguration enthält normalerweise eine Default-SNAT-Regel mit MASQ. Vor einer zusätzlichen Linked NAT Rule sollte geprüft werden, ob diese Regel den Traffic bereits korrekt abdeckt. Matcht eine höher platzierte unabhängige NAT-Regel, gewinnt sie vor der Linked NAT Rule.

Bei DNAT ermittelt SFOS zuerst das übersetzte Ziel und verwendet anschliessend dessen Zone für das Firewall-Regel-Matching. Eine Portweiterleitung auf einen Server in der DMZ benötigt in der Firewall-Regel deshalb typischerweise Destination zone DMZ, obwohl der Client die öffentliche WAN-Adresse anspricht.

Bei einer unerwarteten NAT Rule ID sollte deshalb auch die Reihenfolge unter Rules and policies > NAT rules geprüft werden. Nach NAT-Änderungen muss eine neue Verbindung erzeugt werden, weil bestehende Sessions nicht erneut ausgewertet werden. NAT erlaubt keinen Traffic von selbst: Die Firewall-Regel entscheidet über Allow oder Drop, NAT übersetzt Adressen oder Ports. Die Details erklärt NAT auf Sophos Firewall verstehen.

Schutzfunktionen auswählen

Nicht jede Option ist mit der Base License verfügbar. Vor dem Rollout sollte man unter Administration > Licensing prüfen:

• Normale Firewall-Regeln: Base License
• IPS und Security Heartbeat: Network Protection
• Web Security, Application Control und Web-Malware-Schutz: Web Protection
• Sandboxing und Dateianalyse: Zero-Day Protection
• Mail-Schutz: Email Protection
• WAF: Webserver Protection
• NDR Active threat intelligence: Xstream Protection Bundle

Standard Protection und Xstream Protection enthalten Web Protection. Das Avanet-Bundle Epic Protection enthält Web Protection ebenfalls. Die vollständige Einordnung steht unter Sophos Firewall Lizenz-Bundles vergleichen.

Web Filtering

Web policy bindet eine Web Policy mit Kategorien, URL-Gruppen, Benutzern und Aktionen ein. Ohne Web Policy gibt es über dieses Feld keine kategoriebasierte Webkontrolle. Die Policy selbst wird unter Web Protection erstellt und getestet.

Apply web category-based traffic shaping verwendet die Bandbreitenvorgaben aus den Webkategorien. Die Option ist nur sinnvoll, wenn dort tatsächlich Limits oder Garantien konfiguriert sind.

Block QUIC protocol blockiert für die Regel ausgehendes UDP auf Port 80 und 443. QUIC kann nicht wie normaler HTTP-/HTTPS-Traffic gescannt werden und umgeht Web Filtering. SFOS aktiviert die Option standardmässig, wenn eine Web Policy oder der Malware-Scan gewählt wird. Details stehen unter QUIC und HTTP/3 blockieren.

Scan HTTP and decrypted HTTPS prüft HTTP und bereits entschlüsseltes HTTPS auf Malware. Die Option aktiviert keine Entschlüsselung. Dafür braucht es unter Rules and policies > SSL/TLS inspection rules eine passende SSL/TLS inspection rule.

Use Zero-day protection sendet verdächtige Downloads nach dem Malware-Scan zur zusätzlichen Analyse. Die Funktion benötigt Zero-Day Protection und kann je nach Dateityp und Policy eine Verzögerung verursachen.

Scan FTP for malware ist nur nötig, wenn die Regel FTP erlaubt. Bei Legacy-Systemen sollte der Scan separat getestet werden.

Use web proxy instead of DPI engine beschränkt Proxy-Filtering auf die üblichen Ports 80 und 443. Der Web Proxy wird unter anderem für SafeSearch, YouTube-Restriktionen, Google-Workspace-Domainbeschränkungen, Pharming Protection, Web Cache oder Parent Proxy benötigt. Im DPI-Modus gelten SSL/TLS inspection rules für HTTP und TLS auf allen Ports.

Die zusätzliche Regel- und NAT-Kette für einen übergeordneten Proxy beschreibt Upstream Proxy auf Sophos Firewall einrichten. Dabei unterscheidet sich ein Proxy im WAN deutlich von einem Proxy in LAN oder DMZ.

Ein ausdrücklich konfigurierter Direct-Web-Proxy-Client verwendet dagegen den Listener auch ohne diesen Schalter. Den vollständigen Aufbau mit Port, Device Access, PAC-Datei, Regel und Tests erklärt Direct Web Proxy mit PAC-Datei einrichten.

Decrypt HTTPS during web proxy filtering gehört zum Web-Proxy-Modus. Im DPI-Modus wird Decryption über SSL/TLS inspection rules gesteuert. Web Exceptions können Decryption, Malware-Scan, Zero-Day Protection und Policy Checks überspringen und sollten deshalb eng begrenzt sowie regelmässig geprüft werden.

Synchronized Security Heartbeat

Heartbeat-Regeln benötigen:

• eine im gleichen Sophos-Central-Konto registrierte Firewall mit aktiviertem Security Heartbeat;
• einen verwalteten Sophos Endpoint mit Trial- oder Volllizenz;
• Network Protection auf der Firewall.

Für die Erkennung fehlender Heartbeats müssen unter System > Sophos Central > Optional configurations > Missing heartbeat zones die betroffenen Zonen ausgewählt sein.

Mit Minimum source HB permitted und Minimum destination HB permitted wird ein minimaler Gesundheitsstatus verlangt. Destination Heartbeat ist nur für interne Ziele geeignet, nicht für die WAN-Zone.

Die Optionen Block clients with no heartbeat und Block request to destination with no heartbeat behandeln Geräte ohne Heartbeat. Ein Gerät, das noch nie einen Heartbeat gesendet hat, bleibt standardmässig erlaubt und wird erst blockiert, wenn beide Optionen aktiv sind. Das muss mit Geräten ohne Sophos Endpoint bewusst getestet werden.

Eine Web Exception, die Policy checks überspringt, kann Webrequests trotz Block clients with no heartbeat zulassen. Der praktische Prüfablauf steht unter Fehlende Security-Heartbeat-Warnungen analysieren.

Application Control, IPS und Traffic Shaping

Identify and control applications (App control) bindet eine Application Filter Policy ein. Application Control benötigt Web Protection. Für URL-basierte Micro Apps in verschlüsseltem Traffic, etwa Datei-Uploads und -Downloads innerhalb von Dropbox oder Gmail, ist eine passende entschlüsselnde SSL/TLS inspection rule erforderlich. Filter, Logs und False Positives werden unter Application Control einrichten erklärt.

Apply application-based traffic shaping policy verwendet die Bandbreitenpolicy, die unter Applications > Traffic shaping default einer Anwendung oder Kategorie zugewiesen wurde. Application Objects sind dagegen für SD-WAN-Routen bestimmt. Eine über Shape traffic gewählte Rules-Policy formt den gesamten Traffic der Firewall-Regel. Sophos dokumentiert die Priorität bei gleichzeitiger Application- und Rules-Policy nicht einheitlich; für ein nachvollziehbares Design sollte pro Anwendungsfall nur eine Variante verwendet und eine notwendige Kombination auf dem eingesetzten SFOS-Build getestet werden.

Detect and prevent exploits (IPS) bindet eine IPS Policy ein. IPS benötigt Network Protection oder eine gültige Trial-Lizenz und muss unter Intrusion prevention > IPS policies global eingeschaltet sein. Client-, Server-, Webserver- und VoIP-Traffic benötigen unterschiedliche, getestete Policies. Der sichere Rollout steht unter IPS einrichten und testen.

Shape traffic weist der gesamten Regel eine Traffic Shaping Policy zu, beispielsweise für VoIP, Meetings, Backups oder Gäste. Garantien und Limits müssen zur verfügbaren WAN-Bandbreite passen. Mehr dazu: Application Traffic Shaping konfigurieren.

DSCP marking markiert Pakete für nachgelagerte Switches, Router oder WAN-Geräte. Die Markierung allein priorisiert nichts; alle beteiligten Geräte müssen die gewählten DSCP-Werte konsistent behandeln.

NDR Active threat intelligence

Scan with NDR Active threat intelligence prüft den Traffic mit kuratierten NDR-Signaturen. Die Aktion ist fest auf Log threats gesetzt: Die Funktion erkennt und protokolliert Ereignisse, blockiert den Traffic aber nicht.

Voraussetzungen sind:

• Xstream Protection Bundle;
• globale Aktivierung von NDR Active threat intelligence;
• aktiviertes IPS-Logging;
• Auswahl der Option in jeder relevanten Firewall-Regel.

Unterstützt werden XGS-, virtuelle, Software- und gängige Cloud-Deployments, jedoch nicht XGS 87, 87w, 88 und 88w. XDR oder MDR und die Übertragung an Sophos Central sind für die weiterführende Central-Analyse optional.

Scan email content

Unter Scan email content lassen sich IMAP, IMAPS, POP3, POP3S, SMTP und SMTPS auswählen. Der Schutz benötigt Email Protection. Fehlen die Standardports in Services, können sie über Add ports ergänzt werden.

Mailtraffic sollte nicht in einer allgemeinen Client-Internetregel versteckt werden. Eine eigene Mailregel macht Source, Destination, Protokolle, Logging und Schutzfunktionen klarer.

Regel testen und betreiben

Abnahme nach dem Speichern

Nach dem Speichern ist die Regel erst fertig, wenn der definierte Testfall die erwarteten Ergebnisse liefert:

Pro Test sollte nur eine Änderung vorgenommen werden, damit Ursache und Wirkung zuordenbar bleiben.

1. Regelposition und Rule group kontrollieren.
2. Log firewall traffic und die Ziele unter System services > Log settings prüfen.
3. Mit einem definierten Client, Ziel und Service genau eine Testverbindung erzeugen.
4. Firewall Rule ID, Rule name, Benutzer und Action im Log Viewer prüfen.
5. NAT Rule ID und übersetzte Adressen kontrollieren.
6. DNS und Routing separat verifizieren.
7. Web Policy, Application Control, IPS und TLS Inspection anhand der erwarteten Aktion prüfen.
8. Auf unerwartete Drops, SSL/TLS-Fehler oder Performanceprobleme achten.
9. Die Testregel zurückbauen oder auf die produktiven Objekte begrenzen.

Für Policy Test, Log Viewer und Packet Capture gibt es den eigenen Ablauf Sophos Firewall-Regel testen.

Neue Regel, bestehende Regel oder Deaktivierung

Eine bestehende Regel kann erweitert werden, wenn Source, Destination, Zweck, Owner und Schutzbedarf gleich bleiben. Eine eigene Regel ist besser, wenn Logging, Ablaufdatum, Security Features, Verantwortliche oder Review-Zyklus abweichen.

Temporärer Supportzugriff, Server, Gäste, VoIP, IoT und Management sollten nicht in einer allgemeinen Clientregel verschwinden. Bei unklaren Altregeln ist kontrolliertes Deaktivieren meist sicherer als sofortiges Löschen:

1. Zweck, Owner und Abhängigkeiten klären.
2. Logging und Testfenster festlegen.
3. Betroffene Teams informieren.
4. Regel deaktivieren und definierte Tests ausführen.
5. Erst nach nachvollziehbarer Beobachtung entfernen.

Eine selten genutzte Notfallregel kann wichtig sein. Umgekehrt ist eine häufig genutzte breite Regel nicht automatisch sicher.

Datenzähler, Review und Änderungsnachweis

Reset data transfer count setzt den übertragenen Datenzähler einer Regel zurück. Das ist kein Session- oder Trefferzähler. Der Status Unused sagt nur aus, dass während der letzten 24 Stunden kein passender Traffic gefunden wurde. Beide Hinweise müssen mit Logs, Regelbeschreibung und Use Case bewertet werden. Für die Auswertung der übertragenen Daten eignet sich zusätzlich Reports > Dashboards > Traffic dashboard > Allowed policies.

Regelmässige Reviews prüfen mindestens:

• Source, Destination und Services;
• verbleibende Any-Objekte;
• Owner, Ticket und Ablaufdatum;
• Logging und tatsächliche Nutzung;
• NAT, Web Policy, IPS, TLS Inspection und weitere Schutzfunktionen;
• deaktivierte, temporäre und automatisch erzeugte Regeln.

Vor grösseren Änderungen sollte ein Backup vorhanden sein. Audit Trail Logs und Config Studio zeigen Konfigurationsänderungen; bei Central-verwalteten Gruppen bestätigt die Firewall Management Task Queue, ob die Änderung auf der richtigen Appliance angekommen ist. Der Firewall Health Check ergänzt den regelmässigen Sicherheitsreview.

Typische Fehler

• Die erwartete Regel greift nicht oder Rule ID #0 erscheint: Reihenfolge, IPv4/IPv6 sowie alle Source-, Destination-, Service-, Benutzer- und Exclusion-Kriterien prüfen.
• Die Firewall Rule ID stimmt, aber NAT Rule ID oder Paketweg nicht: NAT-Reihenfolge, Routing, SD-WAN und Rückweg kontrollieren.
• Die Regel greift, aber Schutzwirkung fehlt oder die Anwendung bricht: Lizenz, globale Aktivierung, Logging sowie Web Policy, QUIC, TLS Inspection, IPS und Traffic-Shaping-Policy einzeln prüfen.

Wenn Rule ID, NAT ID oder Paketweg unerwartet sind, hilft Sophos Firewall Regel greift nicht bei der strukturierten Ursachenprüfung.