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

Vor Add firewall rule wählt man auf der Regelseite ausdrücklich IPv4 oder IPv6. Die folgenden Beispiele sind keine gemeinsame Freigabe für beide Protokollfamilien.

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 positiven Match-Kriterien einer Regel passen und keine Exclusion die Regel überspringen lässt, 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 und Benutzer matchen. Alle positiven konfigurierten Kriterien müssen zur Verbindung passen. Exclusions sind keine positiven Kriterien: Wenn alle Kriterien einer Exclusion gemeinsam passen, überspringt SFOS diese Regel und prüft die nachfolgenden Regeln.

Automatisch erzeugte MTA-, IPsec- oder Hotspot-Regeln können oben in der Liste erscheinen. Auch der Server Access Assistant legt zusammen mit DNAT, reflexivem SNAT und Loopback eine Firewall-Regel an. 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; den Server Access Assistant erklärt die Anleitung zu DNAT für veröffentlichte Server.

⚠️ Vor dem Anlegen der protokollierenden Drop-Regel: Man darf nicht annehmen, dass sie die bisherige HTTP-/HTTPS-Sperrwirkung erhält: Die Dokumentation zu Drop, Authentifizierung, Web Exceptions und Blockseiten widerspricht sich. Bei jeglichem Webtraffic ist vor dem produktiven Ausrollen eine schriftliche Sophos-Klärung für die genaue SFOS-Version, den Build und den Verarbeitungspfad oder eine ausdrücklich freigegebene, isolierte Prüfung erforderlich. Die Vorgaben zu Prüfung, Rücknahme und Eskalation stehen unter Action und Logging weiter unten.

Findet SFOS keine passende Regel, greift unten die implizite Drop-all-Regel mit Firewall Rule ID #0. Sie zeigt keinen Usage Count und erzeugt keinen normalen Firewall-Traffic-Logeintrag. Sollen diese Drops im Log Viewer, in Central Reporting oder im Syslog erscheinen, erstellt man am Ende der Regelbasis eine eigene Drop-Regel mit aktiviertem Log firewall traffic. Dafür wählt man die tatsächlich benötigten Source- und Destination-Zonen einzeln statt Zone Any; andernfalls kann die Regel auch internen Traffic zu lokalen Diensten erfassen. Die Details erklärt Dropped Packets auf Sophos Firewall analysieren.

Für eine freigegebene Protokollierungsregel wählt man im richtigen IPv4-/IPv6-Regelwerk Add firewall rule > New firewall rule, einen eindeutigen Namen, Rule position Bottom, Action Drop und Log firewall traffic. Source zones und Destination zones einzeln auswählen; Source networks and devices, Destination networks und Services auf den genehmigten Umfang setzen, danach Save. Vorher die bestehende Reihenfolge und Logging-Konfiguration festhalten. Neue erlaubte und bewusst nicht erlaubte Testverbindungen müssen die erwarteten Rule IDs treffen, ohne lokale Dienste zu beeinträchtigen. Bei Abweichungen die neue Regel deaktivieren und den vorherigen Stand wiederherstellen. Die Webtraffic-Klärung unter Action und Logging bleibt Voraussetzung, nicht ein durch diese Schritte erledigter Test.

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. Eine Gruppe kann nicht leer bleiben. Für SFOS 22 beschreibt die Hilfe: Innerhalb ihrer Gruppe kann man eine Regel verschieben. Soll eine einzelne Regel ausserhalb ihrer Gruppe an eine andere Position wechseln, muss man sie zuerst mit Detach lösen; alternativ verschiebt man die ganze Gruppe. Löscht man die letzte Regel einer Gruppe, wird auch die Gruppe gelöscht.

In der SFOS-22-Tabelle blendet man Filter mit Enable filter / Disable filter ein oder aus, wählt unter Add filter Feld und Wert und setzt sie mit Reset filter zurück. Im gefilterten Zustand lassen sich einzelne Regeln, aber keine Regelgruppen auswählen. Regeln oder Gruppen lassen sich mit Enable / Disable umschalten; eine gemischte Auswahl aktiver und inaktiver Regeln verhindert diese Aktion. More options bietet Bearbeiten, Klonen, Hinzufügen, Löschen, Detach, Reset data transfer count und Gruppenaktionen. Für eine noch nicht gruppierte Regel wählt man Add to group > New group, vergibt den Gruppennamen und legt Regeltyp sowie Source-/Destination-Zonen fest; alternativ wählt man eine bestehende Gruppe. Gruppen lassen sich bearbeiten oder löschen. Die Spalte # zeigt die Position; mit dem Rule handle zieht man Regel oder Gruppe, oder trägt bei Move To die Zielposition ein und bestätigt mit Enter. Vor jeder Verschiebung den bisherigen Stand notieren und danach neue Testflows auf das erwartete Rule ID prüfen. Ein Klon ist keine automatisch sichere Freigabe: Kriterien, Status und Position vor Aktivierung prüfen.

Die SFOS-23-Hilfe beschreibt einen anderen Bedienablauf: Für eine gefilterte Suche klickt man in das Suchfeld, wählt ein vorgeschlagenes Kriterium aus und vervollständigt die Suche mithilfe der weiteren Vorschläge. Mit Enter wird die Regeltabelle gefiltert. Für die Suche nach einem Regelnamen gibt man diesen direkt in das Suchfeld ein und drückt Enter; einzelne Filter lassen sich mit x entfernen. Über Show/Hide columns wählt man die sichtbaren Spalten aus, ändert ihre Reihenfolge durch Klicken und Ziehen und fixiert bis zu drei Spalten, damit diese immer zuerst angezeigt werden. Regeln werden über Status oder gesammelt mit Turn on / Turn off aktiviert beziehungsweise deaktiviert; eine gemischte Auswahl aktiver und deaktivierter Regeln erlaubt diese Sammelaktion nicht. Deaktivierte Regeln erscheinen verblasst mit durchgestrichenem Namen. Beim Ziehen mindestens eine Position ausserhalb der Gruppe verliert eine Regel ihre Mitgliedschaft; zwischen zwei Regeln einer anderen Gruppe wird sie dort aufgenommen. Im View menu stehen Clone rule above/below, Add rule above/below, Move To und Edit group bereit. Über Features lassen sich Details per Hover prüfen: Benutzer-/Netzwerktyp und Regelaktion sind von Policy-Aktionen und Heartbeat-Schwellen zu unterscheiden. In der SFOS-23-Tabelle bedeutet User aktiviertes Match known users, Network dessen Nichtauswahl; Policy-Symbole unterscheiden None, Accept, Drop und Reject, Heartbeat-Symbole Green, Yellow und No restriction. Diese Darstellung belegt keine Änderung der Traffic-Engine.

Die Symbole sind Konfigurationshinweise, keine Testergebnisse: In SFOS 23 prüft man unter Features, in SFOS 22 unter Feature and service, ob Web-/FTP-/Mail-Scanning und Traffic Logging ein- oder ausgeschaltet sind, ob Proxy-Filtering gewählt ist und ob Policies zugewiesen sind. Ein eingeschalteter Proxy betrifft 80/443; andere HTTP-/TLS-Ports bleiben bei DPI. Web policy, App control, IPS und Shape traffic können jeweils None anzeigen; IPS- und Shaping-Symbole zeigen eine zugewiesene Policy, Web- und App-Symbole zusätzlich deren Aktion. Bei Heartbeat muss man den Mindeststatus Green oder Yellow von No restriction unterscheiden und den separaten Zustand von Block clients with no heartbeat prüfen. No restriction allein beweist nicht, dass dieser zusätzliche Schalter ausgeschaltet ist. Auch aktivierte Exclusions müssen bei der Match-Prüfung berücksichtigt werden.

Für Neuinstallationen nennen die SFOS-22/23-Hilfen eine LAN-to-WAN-Regel sowie die bei aktiviertem MTA-Modus automatisch erzeugte MTA-Regel mit Linked NAT; MTA ist dort standardmässig aktiv. Das ersetzt keine Kontrolle der eigenen Installation. Die implizite Regel #0 kann nicht bearbeitet, gelöscht oder verschoben werden und bleibt von Filtern ausgenommen. Davon zu unterscheiden ist ein Factory Reset: Beide Hilfen beschreiben das Entfernen aller Firewall-Regeln und anschliessend nur die Regel Auto added firewall policy for MTA. Daraus darf man keine automatisch wiederhergestellte LAN-to-WAN-Freigabe ableiten. Ein Reset ist kein Verfahren zum Aufräumen einzelner Regeln; Backup, unabhängiger Adminzugang und Wiederherstellungsplan gehören in den gesonderten Ablauf Sophos Firewall zurücksetzen.

Die Startup-Übersicht Access rules and policies für SFOS 22/23 beschreibt zusätzlich standardmässig erstellte Regelgruppen mit einer Firewall-Regel zum Verwerfen von Traffic in Richtung WAN, DMZ und interne Zonen (LAN, Wi-Fi, VPN und DMZ). Damit sind sichtbare, gruppierte Firewall-Regeln gemeint, nicht die implizite Regel #0. Diese Übersicht und die oben genannten detaillierten Installations- und Reset-Defaults belegen jedoch keinen einheitlichen anfänglichen Regelbestand für jede Installation. Prüfe deshalb auf deiner konkreten SFOS-Version, deinem Build und deiner Installation unter Rules and policies > Firewall rules, welche Regeln und Gruppen tatsächlich vorhanden und aktiviert sind, welche Source-/Destination-Zonen und weiteren Match-Kriterien sie verwenden und an welcher Position sie stehen. Eine vorhandene Gruppe allein beweist keine Isolation: Eine vorherige passende Freigabe kann den Traffic bereits erlauben. Prüfe die gewünschte Zonentrennung mit neuen, ausdrücklich autorisierten Testverbindungen und den erwarteten Rule IDs; für Web-Traffic gilt weiterhin der oben beschriebene Dokumentationskonflikt zu Drop. Leite aus der Startup-Übersicht weder garantierte Gruppennamen noch Erstellungsbedingungen oder eine allgemeine Sperrwirkung ab.

Action und Logging

Action legt die Behandlung passenden Traffics fest:

• Accept: erlaubt die Verbindung.
• Drop: ist für Nicht-Webtraffic als Verwerfen ohne Benachrichtigung dokumentiert. Für HTTP/HTTPS ist das Verhalten wegen des unten beschriebenen Dokumentationskonflikts nicht pauschal zugesichert.
• Reject: verwirft die Verbindung und sendet bei TCP einen TCP-Reset; für UDP und ICMP nennt die Hilfe ausdrücklich eine ICMP-Port-unreachable-Nachricht an die Quelle.
• 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.

Bei Protect with web server protection erscheint Preconfigured template. None bedeutet, die WAF-Details selbst festzulegen. Die dokumentierten Vorlagen sind Exchange Autodiscover, Exchange Outlook Anywhere, Exchange General, Microsoft Lync, Microsoft Remote Desktop Gateway 2008 and R2, Microsoft Remote Desktop Web 2008 and R2 und Microsoft Sharepoint 2010 and 2013. Diese historischen Namen sind keine Aussage zur heutigen Unterstützung oder Sicherheit der jeweiligen Serverversion. Vor Verwendung muss die Vorlage zum tatsächlich betriebenen Dienst passen; die anschliessende WAF-Konfiguration und deren Abnahme bleiben erforderlich.

⚠️ Offener Dokumentationskonflikt zu Webtraffic: Die SFOS-22/23-Hilfe zur Regelmaske beschreibt bei Drop das Annehmen und Prüfen von HTTP/HTTPS, Authentifizierung unbekannter Benutzer bei aktiviertem Use web authentication for unknown users, das Zulassen durch eine passende Web Exception und eine HTML-Blockseite für die übrigen Requests. Die Anleitung zum Logging verworfenen Traffics beschreibt dagegen allgemein stilles Verwerfen und verknüpft die Web-Blockseite mit dieser Authentifizierungsoption. Diese widersprüchlichen Beschreibungen sind hier nicht als verifiziertes Verhalten eines bestimmten SFOS-Builds aufgelöst. Weder stilles Verwerfen aller Webverbindungen noch eine ausschliesslich von der Authentifizierungsoption abhängige Blockseite oder das pauschale Blockieren aller Services darf daraus abgeleitet werden.

Benötigt man garantiertes Blockieren oder ein bestimmtes Antwortverhalten, holt man eine schriftliche Sophos-Klärung für die genaue SFOS-Version, den Build und den Verarbeitungspfad ein oder prüft in einer ausdrücklich freigegebenen, isolierten Testumgebung. Nicht-Webtraffic, HTTP und HTTPS werden getrennt geprüft; bei Webtraffic zusätzlich bekannte/unbekannte Benutzer, Authentifizierung an/aus und passende Web Exception vorhanden/nicht vorhanden. Nur definierte Testclients, Ziele und Services verwenden, Log firewall traffic aktivieren und neue Verbindungen erzeugen. Build, Regelposition, Firewall Rule ID, Benutzer, Action, Web-/TLS-Einstellungen sowie die Ergebnisse aus Logs, Packet Capture und Browser dokumentieren. Ein Timeout, eine Blockseite oder der Policy Tester allein beweist die gewünschte Sperrwirkung nicht. Bei unerwartetem Zugriff oder unklarem Ergebnis nicht produktiv ausrollen, Teständerungen zurücknehmen und die Belege an Sophos Support eskalieren. Reject bietet die oben beschriebene Protokollantwort; es wird hier nicht als ungeprüfter Ersatz für Webkontrolle empfohlen.

Log firewall traffic sollte bei wichtigen Regeln aktiv sein. Logs werden standardmässig lokal auf der Firewall gespeichert; lokale Logeinstellungen und Syslog-Ziele prüft man unter System services > Log settings. Für die Übertragung an den Cloud-Dienst ist zusätzlich auf der Seite Sophos Central die Aktivierung von Sophos Central services erforderlich. Die SFOS-22-Hilfe bezeichnet das Ziel als Sophos Fusion (ehemals Sophos Central), die SFOS-23-Hilfe als Sophos Central; die Bezeichnung ersetzt diese separate Voraussetzung nicht. 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.

MAC-basierte Regel: Grenzen vor dem Sperrversuch klären

Ein MAC-Host kann bei direkt sichtbaren Clients eine zusätzliche Gerätezuordnung ermöglichen, etwa wenn sich ihre DHCP-Adresse ändert. Eine MAC-Adresse ist jedoch keine starke Identität: Sie lässt sich ändern oder nachbilden. Die Quellanleitung bezeichnet MAC-Filtering als sicherer und zeigt Block_MAC für IPv4 von LAN nach WAN mit Drop, Logging, Position Top, Gruppe None, Zeitplan All the time, Ziel und Services Any. Diese Kombination ist hier keine Zusage einer vollständigen Internetsperre: Der oben dokumentierte HTTP-/HTTPS-/Web-Exception-Konflikt bleibt offen.

MAC-basierte Internetfilterung ist in der Anleitung auf direkt mit der Firewall verbundene Geräte begrenzt. Liegt ein Router, eine andere Firewall oder ein Layer-3-Switch dazwischen, sieht man nicht automatisch die ursprüngliche Client-MAC. Die Anleitung nennt dafür MAC binding bei lokalen Benutzern; das ist ohne Klärung der Identitätszuordnung und des tatsächlichen Paketpfads keine Garantie für geroutetes MAC-Filtering und kein Ersatz für Authentifizierung. Vor einem Versuch muss die am Firewall-Eingang sichtbare MAC tatsächlich zum Testclient gehören.

Für einen ausdrücklich freigegebenen, isolierten Pilot wird nur ein neuer Nicht-Web-IPv4-TCP-Flow zu einem kontrollierten WAN-Testserver gesperrt:

1. MAC am Testclient und am Firewall-Eingang abgleichen. Unter Hosts and services > MAC host > Add den Namen MAC_Host, Type MAC address und die tatsächlich geprüfte MAC eintragen, dann Save. 37:97:0E:AB:56:46 ist der unveränderte Beispielwert der Anleitung und wird nicht blind übernommen.
2. Unter Rules and policies > Firewall rules IPv4 und Add firewall rule > New firewall rule wählen. Für Block_MAC Action Drop, Log firewall traffic, Rule position Top, Rule group None, Source zones LAN, Source networks and devices MAC_Host, During scheduled time All the time und Destination zones WAN setzen. Ziel auf den kontrollierten Testserver und Services auf den genehmigten Nicht-Web-TCP-Testdienst begrenzen, statt die ursprünglichen Any-Werte zu übernehmen. Vorher Reihenfolge und Konfigurationsstand festhalten, danach Save.
3. Einen frischen Testflow, zum Beispiel einen freigegebenen TCP-iPerf3-Flow, erzeugen und Block_MAC samt Rule ID im Log Viewer sowie den verworfenen Paketfluss prüfen. Ein anderer, nicht gesperrter Kontrollclient muss das Testziel weiterhin erreichen. Ein Timeout allein genügt nicht.
4. Nach dem Pilot die Testregel deaktivieren oder entfernen, vorherige Reihenfolge wiederherstellen und vom ursprünglichen Client einen neuen erlaubten Testflow anhand des erwarteten Rule ID nachweisen. Den Test-MAC-Host nur entfernen, wenn ihn keine andere Konfiguration benötigt.

Bei fehlendem Match MAC-Sichtbarkeit, IPv4-Auswahl, Source, Schedule und Reihenfolge prüfen, nicht die Regel auf alle Geräte erweitern. Bei unerwartetem Zugriff oder Kontrollclient-Ausfall den Versuch zurücknehmen und die Belege mit genauer Version und Build klären. HTTP, HTTPS, Web Exceptions, andere Zonen/Ziele/Dienste und IPv6 sind nicht durch diesen Pilot abgedeckt. Eine vollständige MAC-basierte Internetsperre darf erst nach gesonderter Klärung und Prüfung dieser Fälle zugesichert werden.

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.

Unbekannt bedeutet hier: am Endgerät angemeldet, aber noch nicht an der Firewall authentifiziert. AD SSO mit Kerberos/NTLM oder Captive Portal konfiguriert man unter Authentication > Web authentication, den Zugriff aus den benötigten Zonen unter Administration > Device access. Standardmässig zählt passender Traffic zum individuellen Datenverbrauch. Exclude this user activity from data accounting nimmt ihn daraus aus, etwa wenn für diese Benutzer kein Datenlimit gelten soll; es ist weder eine zusätzliche Freigabe noch eine Authentifizierung.

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.

Das dokumentierte Länderbeispiel erlaubt HTTPS aus afrikanischen Ländern zu 172.16.16.0 und verwendet eine Exclusion mit nur Source zone WAN und einem ausgewählten Länderobjekt als Source network. Nur wenn beide Kriterien passen, wird diese Regel übersprungen; der Traffic kann durch eine spätere Regel erlaubt werden oder bei #0 landen. Die Adresse ist ein unverändertes Beispiel, keine vollständige Netzdefinition mit Präfix. Für einen eigenen Test ein tatsächlich vorhandenes Zielobjekt wählen, Regelreihenfolge dokumentieren und einen ausgeschlossenen sowie einen nicht ausgeschlossenen Testflow anhand der Rule IDs prüfen. Eine Exclusion ist keine globale Sperre.

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.

Wird eine Linked NAT Rule in der NAT-Tabelle entknüpft, wird sie bearbeitbar und anhand ihrer eigenen Kriterien unabhängig von der ursprünglichen Firewall-Regel ausgewertet. Vor dem Entknüpfen deshalb Scope und NAT-Reihenfolge dokumentieren und danach einen neuen Testflow prüfen; es ist keine reine Umbenennung.

In vielen Installationen ist bereits eine Default-SNAT-Regel mit MASQ vorhanden. Das hängt jedoch vom Einrichtungs- und Migrationsstand ab und muss in der konkreten NAT-Regeltabelle geprüft werden. Vor einer zusätzlichen Linked NAT Rule sollte man kontrollieren, ob eine vorhandene 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.

Für ausgehenden Clienttraffic kann man Firewall-Freigabe und Source NAT gemeinsam anlegen:

1. Unter Rules and policies > Firewall rules die Protokollfamilie wählen und Add firewall rule > New firewall rule öffnen. Namen und Position festlegen; im Beispiel Source zones LAN, Source networks and devices Network_LAN, Destination zones WAN und Destination networks Any verwenden. Network_LAN muss das eigene, geprüfte Clientnetz enthalten. Die Anleitung zeigt Services Any; produktiv wählt man stattdessen nur genehmigte Dienste.
2. Create linked NAT rule auswählen, NAT-Namen und Position festlegen und Translated source (SNAT) auf MASQ setzen. Zuerst die Linked NAT Rule mit Save speichern, danach die Firewall-Regel mit Save.
3. Die Firewall-Regel in der Firewall-Tabelle und die verknüpfte SNAT-Regel in der NAT-Tabelle anhand von Firewall Rule ID und Name prüfen. Zuerst wird die Firewall-Regel, danach Source NAT ausgewertet. Bei Linked NAT sind nur übersetzte Source und outbound-interface-spezifische Source Translation veränderbar; die übrigen Kriterien einschliesslich Benutzer/Gruppen stammen aus der Firewall-Regel.

Die Quelldarstellung 10.145.16.10/24 ist der unveränderte Beispielwert der Anleitung, kein Wert zum ungeprüften Kopieren als Netzadresse. MASQ verwendet die IP-Adresse des tatsächlich gewählten ausgehenden Interfaces. Vorher passende Route, Interface und höher platzierte NAT-Regeln kontrollieren. Ein neuer Testflow muss das erwartete Firewall Rule ID, NAT Rule ID und die erwartete übersetzte Source zeigen. Bei falscher Übersetzung Reihenfolge und Egress prüfen; bei Fehlschlag die neue Firewall- und Linked-NAT-Konfiguration zurücknehmen und vorherigen Zustand samt Reihenfolge wiederherstellen, ohne andere benötigte NAT-Regeln zu verändern.

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, schaltet aber keine Entschlüsselung ein. Im DPI-Modus braucht es dafür unter Rules and policies > SSL/TLS inspection rules eine passende SSL/TLS inspection rule; im Web-Proxy-Modus verwendet man Decrypt HTTPS during web proxy filtering. Vor dem Rollout den tatsächlich verwendeten Verarbeitungspfad und das Clientvertrauen in die Decryption-CA prüfen.

Use Zero-day protection setzt Scan HTTP and decrypted HTTPS voraus und sendet heruntergeladene HTTP-/HTTPS-Dateien zur zusätzlichen Analyse auf unbekannte oder noch nicht veröffentlichte Bedrohungen. Die Funktion benötigt Zero-Day Protection und kann je nach Dateityp und Policy eine Verzögerung verursachen; sie schaltet die HTTPS-Entschlüsselung nicht selbst ein.

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.

Auch bei eingeschaltetem Use web proxy instead of DPI engine filtert die DPI-Engine HTTP und SSL/TLS auf anderen Ports weiter; der Schalter betrifft den Proxy für 80/443, nicht sämtlichen Traffic. Web-Proxy-Filtering auf einer Bridge ohne IP-Adresse ist in der Hilfe als Drop-Fall beschrieben und darf nicht ungeprüft aktiviert werden. Decrypt HTTPS during web proxy filtering entschlüsselt auch im ausdrücklich am Client konfigurierten Direct-Proxy-Modus. Im DPI-Modus greifen Web Policies einschliesslich Web Exceptions nur, wenn eine Web Policy gesetzt ist, Malware-/Content-Scanning aktiv ist oder ATP aktiv ist. Diese Bedingungen sind von der unter Application Control, IPS und Traffic Shaping erläuterten URL-basierten Micro-App-Erkennung zu unterscheiden.

Nur bestimmte Ziele über den Web Proxy verarbeiten

Sollen SafeSearch, YouTube-Beschränkungen oder Google-Workspace-Anmeldungen auf bestimmte Domains begrenzt werden, während anderer Traffic die DPI-Entschlüsselung verwendet, legt man eine eigene, höher platzierte Regel an. Vorher Web-Protection-Lizenz, passende globale Webeinstellungen, Clientvertrauen in die Decryption-CA und die gewünschte Web Policy prüfen. FQDN-Gruppen bestimmen die Ziele; sie konfigurieren nicht selbst die zugelassenen Kontodomains oder Filteraktionen.

1. Unter Rules and policies > Firewall rules IPv4 oder IPv6 wählen, Add firewall rule > New firewall rule öffnen, Namen und Position setzen. Action Accept, die tatsächlich benötigte Quellzone und das genehmigte Clientnetz wählen. Die Quellanleitung verwendet dort Any; diese breite Quelle ist keine notwendige Produktionsvorgabe.
2. Destination zones WAN, Destination networks mit den vorgegebenen Gruppen SafeSearch enforcement, YouTube restrictions enforcement und Google app enforcement sowie Services HTTP, HTTPS setzen. Nur für den gewünschten Anwendungsfall benötigte Gruppen auswählen.
3. Scan HTTP and decrypted HTTPS, Block QUIC protocol, Use web proxy instead of DPI engine und Decrypt HTTPS during web proxy filtering aktivieren. Die eigentliche Web Policy muss zur gewünschten Einschränkung passen. Log firewall traffic für den Pilot aktivieren und mit Save speichern.
4. Die Regel oberhalb der DPI-Regeln positionieren. Mit neuen Verbindungen die gewünschte SafeSearch-/YouTube-/Kontobeschränkung, Rule ID und Web-/TLS-Logs prüfen; auch ein anderes Ziel testen, das weiterhin die vorgesehene DPI-Regel und SSL/TLS inspection rule treffen soll.

Bei ausbleibender Einschränkung Regelposition, FQDN-Zuordnung, Web Policy und QUIC prüfen; bei Zertifikatsfehlern CA-Vertrauen und Decryption-Konfiguration. Bei unerwartetem Verhalten die neue Proxyregel deaktivieren oder vorherige Werte und Position wiederherstellen, danach den ursprünglichen DPI-Pfad erneut prüfen. Nicht pauschal TLS-Schutz oder Zertifikatsprüfung ausschalten.

Synchronized Security Heartbeat

Heartbeat-Regeln benötigen:

• eine im gleichen Sophos-Fusion-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 Fusion > 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.

Für beide Schwellen gilt: Green lässt nur Green zu; Yellow lässt Green oder Yellow zu; No restriction lässt auch Red und Geräte ohne Heartbeat zu. Die separaten No-Heartbeat-Blockoptionen bleiben zu prüfen. Den Unterschied zwischen verlorenem und nie gesendetem Heartbeat erklärt die Missing-Heartbeat-Anleitung; Abmeldung bei Heartbeat-Verlust oder Sleep/Wake und die Prüfung einer neuen Anmeldung stehen unter Synchronized User ID.

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.

Die Einstellungen für Malware- und Content-Scanning stammen aus Web > General settings. Für die Auswahl von Web-Proxy-Filtering muss zuerst eine Web Policy oder Scan HTTP and decrypted HTTPS gewählt sein. Eine Application Filter Policy für URL-basierte Micro Apps greift im entschlüsselnden DPI-Pfad auch mit Web policy None, ausgeschaltetem Malware-Scan und ebenfalls ausgeschaltetem ATP. Das hebt die eigenen Aktivierungsbedingungen von Web Exceptions im DPI-Modus nicht auf. Die Sonderfälle Proxy auf einer Bridge ohne IP-Adresse und HTTPS-Entschlüsselung beim Direct Web Proxy werden in diesen Detailanleitungen behandelt.

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. Die aktuelle Hilfe zur Regelmaske beschreibt die Priorität zwischen einer Application- und einer Rules-Policy nicht. Für ein nachvollziehbares Design sollte man pro Anwendungsfall nur eine Variante verwenden und eine notwendige Kombination auf dem eingesetzten SFOS-Build testen. Bei aktiviertem Match known users gilt dagegen die Traffic-Shaping-Policy des Benutzers; ohne Benutzerpolicy greift die Policy seiner Gruppe.

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 nur ausgehende IPv4- und IPv6-Pakete, die diese Regel treffen. Eine bereits eingehend gesetzte DSCP-Markierung wird dabei überschrieben. Reply Packets und systemgenerierter Traffic erhalten durch die Firewall-Regel keine DSCP-Markierung. Die Markierung allein priorisiert oder klassifiziert nichts; alle beteiligten Switches, Router und WAN-Geräte müssen die gewählten DSCP-Werte konsistent auswerten.

Ein enger QoS-Test verwendet einen definierten Client, ein freigegebenes Testziel und ICMP mit AF31 = 26. Nach dem Regelmatch prüft man die Markierung per Packet Capture am WAN-Egress und die Antwort separat. CS0 = 0 ist die Antwort im dokumentierten Beispiel, keine Garantie für beliebige Markierungen der Gegenstelle. Keine breite Any-Freigabe für diesen Test anlegen; Testregel danach zurückbauen. Den Capture-Ablauf erklärt Sophos Firewall-Regel testen.

Die DSCP-Auswahl muss zum QoS-Design der gesamten Strecke passen: EF beschreibt Expedited Forwarding für geringe Verzögerung und geringe Verluste bei Echtzeitdiensten; AF beschreibt Assured Forwarding mit Verwerfen bei Überlast; CS dient der Kompatibilität mit IP-Precedence. Das sind Klassenkonzepte, keine von der Markierung allein garantierte Dienstqualität. Die dokumentierten Werte sind:

Das ursprüngliche ICMP-Beispiel verwendet 8.8.8.8, Source zone LAN, Destination zone WAN, Quelle und Ziel Any sowie AF31. Für eine eigene Prüfung ersetzt man dies durch freigegebene konkrete Client- und Zielobjekte; weder diese öffentliche Adresse noch eine breite Freigabe sind erforderlich. Vor dem Test den vorherigen DSCP-Wert notieren, nach dem Test wiederherstellen und mit neuen Paketen prüfen. Bleibt die erwartete Priorisierung aus, muss man Regelmatch, tatsächliche Egress-Markierung und die QoS-Behandlung der nachgelagerten Geräte getrennt untersuchen.

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 Appliances, virtuelle, Software- und gängige Cloud-Deployments, jedoch nicht XGS 87, 87w, 88 und 88w. XDR oder MDR und die Übertragung an Sophos Fusion sind für die weiterführende 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.

Für einen bestehenden, per DNAT veröffentlichten SMTP-Server verbindet Mail Protection im Legacy Mode einrichten die eingehende und ausgehende Regel mit NAT, Scan-Policy, TLS und den Legacy-Proxy-Logs.

Für den Mailabruf reicht die Checkbox allein nicht: CA-Vertrauen, globale Scan-Grenzen, optionale POP-IMAP-Policy und der tatsächliche Regelmatch müssen zusammenpassen. Der vollständige Pilot- und Testablauf steht unter POP3 und IMAP auf Sophos Firewall scannen und testen.

Firewall-Regeln über die XML API vorbereiten

Die XML-Objekte FirewallRule und FirewallRuleGroup eignen sich für nachvollziehbare Regeländerungen und Gruppenpflege. Sie ersetzen weder die Planung der Zugriffe noch die Abnahme mit neuen Testverbindungen. Den abgesicherten Zugang, HTTP POST an APIController, explizite XML-Operationen, TLS-Prüfung, Secret-Ablage und die Auswertung von XML-Status statt HTTP-Erfolg erklärt XML API Zugriff absichern. Zuerst muss vom vorgesehenen Automationshost eine ungefährliche Leseabfrage mit einem eng berechtigten Konto funktionieren.

Regeltyp, Elternstruktur und Reihenfolge beibehalten

In der SFOS-22/23-Referenz sind Name, Position und PolicyType Pflichtangaben für Add/Edit. Name ist ein UTF-8-String mit höchstens 60 Zeichen ohne Komma. Unter FirewallRule wählt PolicyType mit Network den Block NetworkPolicy beziehungsweise mit User den Block UserPolicy. Diese Zweige nicht vermischen und nicht beide ungeprüft senden. HTTPBased und HTTPBasedPolicy gehören zur WAF-Konfiguration, die Authentifizierungsbindung zur WAF-Authentifizierung. WAF-Pfadaktionen sind keine numerische Übersetzung von Netzwerkaktionen.

IPFamily erlaubt IPv4 oder IPv6; die Tabelle nennt IPv4 als Default. Status erlaubt Enable oder Disable, nennt aber ON als Default. Für vorbereitete Regeln den Status bewusst auf Disable setzen und die gespeicherte Protokollfamilie prüfen, statt Dokumentationsdefaults als sichere Nutzlastwerte zu übernehmen. Position erlaubt laut Parametertabelle Bottom, Top, After oder Before; das Beispiel schreibt diese Werte klein. Deshalb Schreibweise und vollständige Operation in API help des installierten Builds bestätigen. After/Name und Before/Name bezeichnen die bestehende Ankerregel; die Referenz beschränkt diese Tags auf Set-Requests. Section unterscheidet Central_TOP, Local und Central_Bottom: Eigentümerschaft und Verwaltungsweg vor einem lokalen Schreibversuch klären, nicht eine zentrale Einschränkung durch einen anderen Abschnitt umgehen.

Im gewählten Policy-Block bleiben Quelle und Ziel getrennt: SourceZones/Zone, SourceNetworks/Network, DestinationZones/Zone, DestinationNetworks/Network und Services/Service enthalten wiederholbare Referenzen. Schedule verweist auf einen vorhandenen Zeitplan. Die Tabellen begrenzen Netzwerk- und Servicereferenzen auf 60 Zeichen; sie dokumentieren keine gemeinsame Höchstzahl aller Kriterien. Dieselben Eltern können unter Exclusions stehen und bedeuten dort Ausnahmen von dieser Regel, keine zusätzlichen Freigaben. Vor dem Schreiben die tatsächlich vorhandenen Zonen, Hosts, Services und Zeitpläne lesen und den beabsichtigten Match einschliesslich nachfolgender Regeln prüfen.

Bei UserPolicy ergänzen MatchIdentity, ShowCaptivePortal und Identity/Member den Benutzerbezug. Für Member sind mehrere Benutzer-/Gruppenreferenzen mit höchstens 256 Zeichen dokumentiert. Die Identitätszuordnung und Web-Authentifizierung müssen separat funktionieren. DataAccounting ist nur bei aktiviertem Identitätsmatching beschrieben und nimmt Benutzertraffic aus der Datenabrechnung aus; es authentifiziert nicht. Hier widersprechen sich Beispiel und Tabelle: Das Beispiel zeigt Include/Exclude, die Tabelle Enable/Disable. Auch WebCategoryBaseQoSPolicy und ApplicationBaseQoSPolicy zeigen im Beispiel Apply/Revoke, während die Tabelle einen String beschreibt. Solche Werte nicht automatisch übersetzen oder als austauschbar behandeln. Bleibt der konkrete Wert für Objekt und Build ungeklärt, den Schreib-Request stoppen und mit Sophos klären.

Action im Network-/User-Zweig erlaubt Accept, Drop oder Reject; die Tabelle nennt Drop als Default. Eine explizite Aktion bleibt notwendig, und der oben erklärte Konflikt zur HTTP-/HTTPS-Behandlung von Drop gilt auch bei API-Änderungen. LogTraffic erlaubt Enable/Disable, mit dokumentiertem Default Disable; Logging für die Abnahme bewusst wählen. SkipLocalDestined betrifft Traffic zur Appliance-IP und ist kein Ersatz für Device Access. Policyreferenzen wie WebFilter, ApplicationControl, IntrusionPrevention und TrafficShapingPolicy müssen zum zuvor geplanten Schutz passen. Scanning, Proxy, Decryption, Zero-Day und Heartbeat bleiben unterschiedliche Kontrollen mit den oben erklärten Voraussetzungen. Insbesondere widersprechen Default-Angaben wie OFF, NULL oder NoRestriction teilweise den ausgewiesenen Eingabewerten; weder diese Angaben noch leere Beispielelemente belegen, wie Weglassen, Leeren oder Aktualisieren im konkreten Build wirkt.

Bei der Übertragung vorhandener Schutzoptionen muss man die Wertedomäne je Feld prüfen: ProxyMode nennt zusätzlich zu Enable/Disable auch true/false; NDRActiveThreatIntelligence nennt nur true/false. Die Schwellen MinimumSourceHBPermitted und MinimumDestinationHBPermitted erlauben GREEN, YELLOW und No Restriction, während die Default-Spalte NoRestriction schreibt. Das sind andere Eingaben als die separaten Heartbeat-Schalter, keine automatische Übersetzung der GUI-Bezeichnungen. Die benutzerbezogenen Selektoren WebFilterInternetScheme und ApplicationControlInternetScheme nennen Enable/Disable, aber Default 0; sie nicht mit einem Policy-Namen verwechseln. Die XML-Kommentare binden WebCategoryBaseQoSPolicy an einen ausgewählten WebFilter und ApplicationBaseQoSPolicy an einen ausgewählten Application Filter. Bei Traffic Shaping nennt die Tabelle TrafficShappingPolicy/TrafficShapingPolicy, das XML-Beispiel aber TrafficShapingPolicy: keine Austauschbarkeit oder Annahme beider Tags ableiten. DSCPMarking ist als String dokumentiert; die Serialisierung des GUI-Werts muss zum Build passen. Jede betroffene Schutzoption vor und nach der Änderung vergleichen; unbekannte Eingaben nicht normalisieren und keine Schutzoption stillschweigend verlieren.

Gruppenmitgliedschaft ist keine Sicherheitsentscheidung

FirewallRuleGroup fasst bestehende Regeln über SecurityPolicyList/SecurityPolicy zusammen. SourceZones/Zone und DestinationZones/Zone sind getrennte Eltern für die Gruppenzuordnung, keine neuen Match-Kriterien der einzelnen Regeln. Das kleingeschriebene Policytype der Gruppe unterscheidet sich vom PolicyType einer Regel. Die dokumentierten Gruppenselektoren sind User/network rule, Network rule, User rule, WAF rule und Any; diese Werte nicht aus dem Regeltyp ableiten oder in andere Schreibweisen normalisieren.

Der Gruppenname ist verpflichtend, ohne Komma, mit UTF-8 und höchstens 150 Zeichen; Description ist optional mit höchstens 255 Zeichen. Für SecurityPolicy nennt die Referenz höchstens 60 Zeichen je Regelname, kein Komma und bis zu 200 Werte. Das ist ein dokumentiertes Mitgliedschaftslimit, kein getestetes Kapazitätsversprechen. Für eine Gruppe Internet Access zunächst die vorhandenen Regelnamen lesen, nur die genehmigten Mitglieder auswählen und Quelle/Ziel getrennt zuordnen. Das Herstellerbeispiel mit Doppelpunkten und einer kommaseparierten Auswahl sämtlicher Typen ist kein ausführbarer Payload.

Vor einem Gruppen-Update Mitgliedschaft, Regelpositionen und Status sichern. Danach dieselben Regeln in WebAdmin und per freigegebener Leseabfrage wieder abgleichen. Die Beschreibung «Add/Remove» bei SecurityPolicy legt keine sichere inkrementelle Listenänderung oder Ersetzungssemantik fest. Bei ungeklärtem Umgang mit ausgelassenen oder leeren Listen nicht schreiben. Eine Gruppe kann laut GUI-Hilfe nicht leer bestehen; das Entfernen der letzten Regel kann auch die Gruppe entfernen. Gruppierung schafft Übersicht, aber weder Isolation noch Vorrang: Entscheidend bleiben die Match-Kriterien und die tatsächliche Reihenfolge jeder Regel.

Antworten nach Operation unterscheiden und Zustand nachlesen

Die folgenden Zuordnungen stammen übereinstimmend aus den SFOS-22/23-Referenzen. Die Message.*-Bezeichner bleiben unaufgelöste Dokumentationssymbole, keine zugesicherten Laufzeitmeldungen, Übersetzungen oder eindeutigen Ursachen. Ein gleicher Code kann je Operation etwas anderes bezeichnen. Insbesondere sind dies XML-Statuscodes, keine HTTP-Statuscodes.

Für das Anlegen und Bearbeiten von Network-/User-Regeln sind diese Unterschiede relevant:

• Add firewall rule — 200 — Message.FWRuleAddSuccess; Edit firewall rule — 200 — Message.FWRuleEditSuccess.
• Edit firewall rule — 202 — Message.FirewallRuleUpdateWithRename: alten und neuen Namen, Referenzen und gespeicherten Regeltyp prüfen, nicht bloss vollständigen Erfolg annehmen.
• Add firewall rule — 500 — Message.FWRuleAddFail; Edit firewall rule — 500 — Message.FWRuleEditFail.
• Add firewall rule — 502 — Message.FWRuleRecordExists; Edit firewall rule — 502 — Message.FWRuleUpdateRecordExist: vorhandene und gewünschte Regel anhand des gelesenen Zustands vergleichen, nicht automatisch überschreiben.
• Add firewall rule — 541 — Message.VHIPRangeConflict; Edit firewall rule — 541 — Message.FWRuleFailMaxUser. Daraus keinen einheitlichen Fehlergrund oder numerischen Benutzergrenzwert ableiten.
• Add firewall rule — 551 — Message.CannotSelectDestHBIfWANSelected; Edit firewall rule — 551 — Message.CannotSelectDestHBIfWANSelected: Zielzonen und Destination-Heartbeat-Konfiguration zusammen prüfen.
• Edit firewall rule — 552 — Message.CannotImportDiffPolicytypeWithSameName: bestehenden Namen und Regeltyp abgleichen, nicht durch Umbenennen oder Typwechsel auf Verdacht umgehen.
• Add firewall rule — 596 — Message.CMLOCALOperationrestriction; Edit firewall rule — 596 — Message.CMLOCALOperationrestriction: Verwaltungszuständigkeit und den freigegebenen Änderungsweg klären.

Die gemeinsam aufgeführten WAF-spezifischen Antworten gehören zur WAF-Anleitung; deren Port-, Redirect- und Protected-Server-Konflikte nicht auf Network-/User-Regeln übertragen.

Auch für Gruppen hält man die Operation fest: Add firewall rule group — 200 — Message.FWGroupAddSuccess, 500 — Message.FWGroupAddFail, 502 — Message.FWGroupRecordExists; Edit firewall rule group — 200 — Message.FWGroupAddSuccess, 500 — Message.FWGroupAddFail, 502 — Message.FWGroupRecordExists. Die Edit-Referenz verwendet tatsächlich dieselben Add-Symbole. Vor einem erneuten Versuch den gespeicherten Gruppennamen, die Mitgliedschaft und beide Zonenlisten lesen; aus den Symbolnamen keine Anlegeoperation bei Edit folgern.

Beim Löschen gilt Delete firewall rule — 200 — Message.FWDelSuccess, 500 — Message.FWRuleDeleteFail, 596 — Message.CMLOCALOperationrestriction. Die Delete-Tabelle markiert Name als optional und beschreibt ihn widersprüchlich als Anker für Before/After. Daraus keine namenlose, pauschale Löschung ableiten. Vor Remove das exakte Ziel, Abhängigkeiten, Gruppenzugehörigkeit, Linked NAT, Verwaltungszuständigkeit und den bestätigten Payload in API help prüfen. Kontrolliertes Deaktivieren mit Beobachtungsfenster bleibt bei unklaren Altregeln der sicherere erste Schritt.

Nach jeder Antwort und auch nach Timeout oder Verbindungsabbruch vor einem Retry zuerst den tatsächlichen gespeicherten Zustand lesen: Name, Typ, Status, Protokollfamilie, Position, Kriterien, Exclusions, Schutzreferenzen und Gruppenmitgliedschaft müssen zum freigegebenen Soll passen. Bei Remove zusätzlich prüfen, ob genau die Zielregel fehlt und benötigte Regeln sowie NAT unverändert bestehen. Ein unbekanntes Ergebnis kann bereits eine Änderung enthalten. Kein blindes Wiederholen, automatisches Upsert oder Erweitern auf Any; bei Abweichungen stoppen, bereinigte Antwort und Audit Trail sichern und den bestätigten Rückweg verwenden. Erst danach folgen die unten beschriebenen neuen erlaubten und bewusst nicht erlaubten Testflows. Diese Dokumentationsprüfung ist kein Appliance- oder API-Labtest.

Regel testen und betreiben

Abnahme nach dem Speichern

Nach der Konfiguration speichert man die Regel mit Save. Sie ist 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.

Der Policy Tester simuliert die Regelauswahl, erzeugt aber keinen echten Paketfluss und bestätigt weder Routing noch Rückweg. Für Policy Test, Log Viewer und Packet Capture gibt es deshalb den vollständigen 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.

Eine Regeländerung zurücknehmen

Vor einer Änderung notiert man die aktuelle Position und alle betroffenen Felder oder exportiert einen nachvollziehbaren Konfigurationsstand. Eine bestehende Regel sollte nicht für einen anderen Zweck umgebaut werden: Eine neue, zunächst deaktivierte Regel bietet einen klareren Rückweg und lässt die bisherige Freigabe unverändert.

Schlägt die Abnahme fehl, deaktiviert man die neue Regel oder stellt bei einer bearbeiteten Regel die vorherigen Werte und ihre frühere Position wieder her. Danach erzeugt man sowohl den erlaubten als auch einen bewusst nicht erlaubten Testflow neu und prüft die erwartete Firewall Rule ID im Log Viewer. Bei einer Änderung am Managementpfad muss während des gesamten Ablaufs ein unabhängiger administrativer Zugang erhalten bleiben.

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. In der SFOS-22-Hilfe dokumentiert Sophos Unused an zwei Stellen unterschiedlich: Die Hilfe zur Regeltabelle nennt 24 Stunden ohne passenden Traffic, die Control-Center-Kachel Active firewall rules 12 Stunden und eine tägliche Prüfung. Der Status ist deshalb kein belastbares Löschkriterium. New und Changed bleiben jeweils 24 Stunden ab Erstellung beziehungsweise Änderung bestehen, und eine Regel kann mehrere Status gleichzeitig besitzen. In der SFOS-23-Hilfe nennen Regeltabelle und Kachel übereinstimmend 12 Stunden für Unused. Das ist ein Vergleich der Dokumentation, keine auf einem Appliance-Build getestete Zeitmessung.

Die Zeitfenster können sich überlappen: Eine um 10:00 erstellte Regel bleibt bis 10:00 am Folgetag New. Eine Änderung um 11:00 führt bis 11:00 am Folgetag zu Changed; zwischen 11:00 und dem nächsten 10:00 trägt die Regel beide Status. Ein bei der täglichen Prüfung um 12:00 festgestellter Unused-Status bleibt bis zur nächsten Prüfung bestehen. Wird die Regel um 13:00 deaktiviert, kann sie bis 13:00 am Folgetag zugleich Changed und Disabled sein, danach nur Disabled. Diese Dokumentationsbeispiele ersetzen weder die Prüfung tatsächlicher Nutzung noch einen Löschentscheid. Vor Reset data transfer count den aktuellen Wert dokumentieren: Das Zurücksetzen stellt keinen früheren Zählerstand wieder her und ändert keine Regelberechtigung.

Active firewall rules zeigt Regeln nach Typ und Status sowie den passenden Traffic in Bytes der letzten 24 Stunden. Die Kachel unterscheidet WAF (Webserver Protection), User (mit Benutzern oder Gruppen) und Network (ohne diese Kriterien). Scanned bezeichnet die gesamte Regelanzahl im Diagramm, nicht die Anzahl malwaregescannter Regeln. Disabled bedeutet konfiguriert, aber ausgeschaltet; eine deaktivierte Regel kann zugleich Changed sein. Per Hover lässt sich das Datenvolumen prüfen; ein Klick auf Anzahl oder Status öffnet die entsprechend gefilterte Regeltabelle.

Die Control-Center-Kachel ist für alle Administratoren sichtbar, unabhängig von ihren Rechten. Ihre Sichtbarkeit beweist deshalb keine Schreibberechtigung auf der eigentlichen Regelseite. Diese 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. Fehlt eine erwartete Regel in der Tabelle, setzt man zuerst den aktiven Filter zurück; die SFOS-22-Hilfe beschränkt zudem Gruppenaktionen bei gefilterter Ansicht.

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 über Sophos Fusion 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.