Sophos Firewall-Regeln sinnvoll dokumentieren

Eine Firewall-Regel ist nicht nur eine technische Freigabe, sondern eine Betriebsentscheidung: Wer darf wohin, über welchen Dienst und aus welchem Grund? Ohne diese Einordnung bleiben alte Test-, Partner- oder Migrationsregeln oft jahrelang aktiv, weil niemand ihren Zweck sicher beurteilen kann.

Die wichtigsten Angaben gehören deshalb direkt in Rule name und Description. Ein Ticket oder Wiki enthält die Details, die Regel selbst zeigt den täglichen Betriebskontext. Für eine belastbare Bereinigung reicht die Beschreibung allein aber nicht; dazu gehören auch Rule ID, Logging, Nutzungsdaten, Owner-Bestätigung und ein kontrollierter Beobachtungszeitraum.

Für den technischen Aufbau ist Sophos Firewall-Regeln verstehen und sicher konfigurieren der Grundartikel. Die folgende Anleitung konzentriert sich auf Benennung, Dokumentation und Review.

Wo die Dokumentation eingetragen wird

Der Pfad lautet Rules and policies > Firewall rules. Dort zuerst IPv4 oder IPv6 wählen und eine bestehende Regel bearbeiten beziehungsweise über Add firewall rule > New firewall rule anlegen.

In den allgemeinen Einstellungen sind für die Dokumentation besonders relevant:

• Rule name: kurzer, scanbarer Name der Verbindung.
• Rule position: Position in der von oben nach unten ausgewerteten Regelliste.
• Rule group: organisatorische Gruppierung der Regel.
• Description: Zweck, Owner, Ticket, Review und bewusste Ausnahme.
• Log firewall traffic: erzeugt Logs und Reportdaten für passende Verbindungen.

Rule group verbessert die Übersicht, ändert aber nicht die Auswertungslogik. Sophos Firewall prüft die einzelnen Regeln von oben nach unten und stoppt beim ersten Treffer. Eine Gruppe kann nicht leer bleiben. Soll eine Regel über die Gruppengrenze hinaus verschoben werden, muss man sie zuerst mit Detach lösen oder die ganze Gruppe verschieben. Nach neuen, geklonten oder automatisch erzeugten Regeln muss deshalb die tatsächliche Rule position kontrolliert werden.

Wer Regeln per API verwaltet, muss in SFOS 22 einige feste Grenzen beachten. Ein Rule name darf höchstens 60 Zeichen und kein Komma enthalten. Für Rule groups erlaubt die API 150 Zeichen im Namen, 255 Zeichen in der Beschreibung und höchstens 200 Regelreferenzen. Diese Grenzen gelten für die API. Für die Description nennt die aktuelle WebAdmin-Hilfe kein Zeichenlimit. Sie sollte trotzdem kurz bleiben, damit sie in der Regeltabelle lesbar ist.

Was in die Description gehört

Source, Destination, Services, Action und Security-Profile sind bereits in der Regel sichtbar. Die Description sollte nicht dieselben Felder abschreiben, sondern die Informationen ergänzen, die später sonst fehlen.

Ein praxistauglicher Mindeststandard besteht aus:

• Zweck: Welcher Geschäfts- oder Betriebsprozess benötigt die Freigabe?
• Owner: Welches Team verantwortet Anwendung und Entscheidung?
• Change oder Ticket: Wo liegen Freigabe, Test und technische Details?
• Review oder Ablaufdatum: Wann wird die Regel erneut geprüft oder entfernt?
• Ausnahme: Welche bewusste Abweichung oder Einschränkung muss ein Admin kennen?

Ersteller und Änderungszeitpunkt müssen nicht manuell gepflegt werden, wenn Configuration Audit und Change-Prozess diese Information zuverlässig liefern. Ein Personenname in der Description wird schnell veraltet; ein dauerhaftes Team oder eine Rolle ist meist der bessere Owner.

Kompakte Vorlage

Für viele Regeln reicht eine einzelne strukturierte Zeile:

Zweck=ERP-Zugriff; Owner=APP-TEAM; Change=CHG-1842; Review=2027-01-31

Bei einer bewussten Ausnahme kommt ein kurzer Hinweis dazu:

Zweck=Partner-Upload; Owner=INTEGRATION; Change=CHG-1910; Review=2027-01-31; Ausnahme=nur definierte Partnernetze

Ausführliches Praxisbeispiel

Eine ausführlich dokumentierte DNAT-Regel kann so aussehen:

DNAT - Synology HTTPS
---
OWNER: NETOPS
LAST REVIEW: 2027-01-31
SOURCE: PARTNER_NETS
DESTINATION: WAN_Public_IP
SERVICE: TCP 5555 -> TCP 443
COMMENT: Access to Synology DSM only from defined partner networks
DOC: CHG-1842

Das Format zeigt Source, Destination und Service auch ausserhalb von WebAdmin. Ändert jemand die Regel, muss man jedoch auch die Description nachziehen. Sonst widersprechen sich beide. Wir empfehlen deshalb die kompakte Vorlage. Wenn Configuration Audit die Änderungen zuverlässig erfasst, genügen in der Description Zweck, Owner, Ticket und Review. Das ausführliche Beispiel kann im Change oder Runbook stehen.

Die Description ist ein Wegweiser, keine vollständige CMDB. Lange Testprotokolle, Architekturentscheidungen und Rollback-Anleitungen gehören ins verlinkte Ticket oder Runbook.

Regeln konsistent benennen

Ein guter Name lässt sich in der Regelübersicht erfassen, ohne die Regel zu öffnen. Das Schema muss nicht für jede Firma gleich sein, aber innerhalb einer Umgebung konsequent bleiben.

Bewährt hat sich beispielsweise:

PREFIX_QUELLE_ZIEL_DIENST

Beispiele:

• ALLOW_VLAN12_WAN_HTTPS
• ALLOW_VPNUSERS_SRVERP_HTTPS
• DNAT_WAN_SRVWEB01_HTTPS
• TEMP_PARTNER_SRVAPP_SFTP
• DROP_VLANIOT_INTERNAL_ANY

ALLOW und DROP nennen die Aktion, DNAT kennzeichnet die Firewall-Regel einer Veröffentlichung und TEMP eine temporäre Freigabe. DNAT bezeichnet hier nicht die NAT-Regel selbst. Quelle, Ziel und Dienst zeigen die Richtung. Kürzel sollten im internen Namensstandard erklärt sein; sonst wird aus einem kompakten Namen nur ein neues Rätsel.

Generische Namen wie Rule1, Test, Allow, Internet oder Temp vermeiden. Ebenso ungünstig sind Namen, die nur ein Ticket enthalten. CHG-1842 lässt sich zwar nachschlagen, erklärt aber im Störungsfall weder Richtung noch Dienst.

Temporäre und veröffentlichte Zugriffe

Temporäre Regeln brauchen ein echtes Ablaufdatum und einen Owner. Ein Präfix wie TEMP erleichtert die Suche, ersetzt aber keinen Rückbauprozess. Das Datum gehört sowohl in die Description als auch in das Ticket oder Change-System, damit eine fällige Prüfung nicht nur vom Blick in die Firewall abhängt.

Bei veröffentlichten Servern reicht die Firewall-Regel allein nicht zur Dokumentation. DNAT-Regel, Firewall Rule ID, öffentlicher Dienst, interner Zielhost und Freigabe gehören gemeinsam ins Ticket. In der Firewall-Description genügt der Verweis auf Change und Zweck; NAT-Details sollten nicht als schwer lesbare zweite Konfiguration in Textform dupliziert werden.

Für die technische Umsetzung helfen Server per DNAT auf Sophos Firewall veröffentlichen und NAT auf Sophos Firewall verstehen.

Was nicht in die Description gehört

Die Regelbeschreibung ist für Administratoren sichtbar und kein Secret Store. Nicht eintragen:

• Passwörter, API-Schlüssel oder Tokens,
• private Schlüssel oder Preshared Keys,
• personenbezogene oder vertrauliche Kundendaten ohne zwingenden Grund,
• vollständige Zugangsanleitungen für externe Personen,
• lange URLs mit Session-, Token- oder vertraulichen Parametern.

Ein interner Ticket-Identifier wie CHG-1842 reicht. Der eigentliche Link und sensible Details bleiben im dafür vorgesehenen System mit eigener Zugriffskontrolle.

Bestehende Regeln kontrolliert prüfen

Eine fehlende Description ist ein Anlass für einen Review, aber kein Grund, die Regel sofort zu löschen. Auch der SFOS-Status Unused ist nur eine Momentaufnahme. Die aktuelle Sophos-Hilfe nennt je nach Ansicht 12 oder 24 Stunden ohne passenden Traffic. Monatliche Jobs, Notfallzugriffe oder saisonale Anwendungen können trotzdem legitim sein.

Ein sicherer Review läuft so ab:

1. Regeln mit fehlender Description, generischem Namen, TEMP oder abgelaufenem Review-Datum markieren.
2. Rule ID, Position, Aktivierungsstatus, Source, Destination, Services, Action und Security-Profile erfassen. Verwendete Hosts und Services bei Bedarf über Object Usage prüfen; dessen Zähler zeigt Konfigurationsabhängigkeiten, nicht den Traffic einer Regel.
3. Vor More options > Reset data transfer count Zeitstempel und aktuellen Zählerstand im Change sichern. Den Zähler nur zurücksetzen, wenn der anschliessende Beobachtungszeitraum auch seltene Verbindungen abdeckt.
4. Unter Reports > Dashboards > Traffic dashboard bei Allowed policies die übertragenen Daten prüfen.
5. Im Log viewer nach Rule ID, Quelle, Ziel und Dienst suchen.
6. Owner und Ticket gegen den aktuellen Geschäftsbedarf prüfen.
7. Nicht mehr benötigte Regeln in einem vereinbarten Fenster deaktivieren und beobachten. Fällt erwarteter Traffic aus, die Regel sofort wieder aktivieren, ihre Position kontrollieren und den Test mit der erwarteten Rule ID wiederholen.
8. Entscheidung, Test und Rückbau im Change dokumentieren.

Die deaktivierte Regel wird erst gelöscht, wenn der vereinbarte Beobachtungszeitraum ohne Störung abgelaufen ist und der Owner zustimmt. Ein Zähler von null beweist nichts, wenn der Zeitraum zu kurz war. Auch ein fehlender Logeintrag reicht nicht als Nachweis. Möglicherweise war Log firewall traffic ausgeschaltet, eine Verbindung brach ohne protokolliertes Destroy-Ereignis ab oder die Logziele waren nicht passend konfiguriert. Unter System services > Log settings wird festgelegt, welche Firewall-Logs lokal, an Sophos Central oder an Syslog-Server gesendet werden.

Änderung und Wirkung nachvollziehen

Die Description erklärt, warum eine Regel existieren soll. Sie zeigt nicht, wer sie tatsächlich geändert hat. Configuration Audit erfasst in SFOS 22 den vorherigen und neuen Zustand sowie Zeitstempel, Administrator und Quell-IP. Der Status wird in der Device Console mit system configuration-audit show geprüft, nicht in der Advanced Shell. Die Funktion ist standardmässig aktiviert.

Für den Betriebsprozess sollten drei Nachweise zusammenspielen:

• Description und Ticket: Zweck, Owner, Freigabe und Review.
• Configuration Audit: wer wann welche Konfiguration geändert hat.
• Log Viewer und Reports: welche Verbindungen die Regel tatsächlich verarbeitet.

Der Artikel Sophos Firewall Audit Trail Logs prüfen beschreibt Configuration Audit und Auswertung genauer. Nach jeder Regeländerung zeigt Firewall-Regel mit Log Viewer, Policy Test und Packet Capture testen, ob die erwartete Rule ID wirklich greift.

Mindeststandard für neue Regeln

Vor dem Abschluss eines Changes sollte eine neue Regel diese Punkte erfüllen:

• konsistenter Rule name,
• Rule position und Rule group bewusst geprüft,
• Source, Destination und Services ohne unnötig breites Any,
• Description mit Zweck, Owner, Change und Review,
• Log firewall traffic nach Betriebs- und Datenschutzbedarf gesetzt,
• keine Secrets oder personenbezogenen Details in Name und Description,
• Funktionstest mit erwarteter Rule ID,
• Ablauf- und Rückbauprozess für temporäre Regeln.

FAQ