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. Nach neuen, geklonten oder automatisch erzeugten Regeln muss deshalb die tatsächliche Rule position kontrolliert werden.

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

Für Teams mit einer ausführlicheren Konvention kann eine dokumentierte DNAT-Regel beispielsweise so aussehen:

DNAT - Synology HTTPS
---
AUTHOR: Patrizio
LAST MODIFIED: 24.06.2026 [PP]
SOURCE: WAN_CH, WAN_DE
DESTINATION: WAN_Public_IP
SERVICE: TCP 5555 -> TCP 443
COMMENT: Access to Synology DSM only from defined countries
DOC: https://ticket/CHG-1842

AUTHOR und LAST MODIFIED sind nur sinnvoll, wenn das Team diese Angaben konsequent pflegt. Wenn Configuration Audit den Änderungsnachweis zuverlässig liefert, reichen in der Description Zweck, Owner, Ticket und Review; das ausführliche Beispiel kann dann 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:

TYP_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, DNAT, TEMP oder DROP helfen beim Scannen. Quelle, Ziel und Dienst machen die Richtung sichtbar. Kürzel sollten in einem 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 Hinweis für Review, aber kein Grund zum sofortigen Löschen. Auch der SFOS-Status Unused ist nur ein kurzfristiges Signal: Er bedeutet, dass die Regel während der letzten 24 Stunden keinen passenden Traffic gefunden hat. 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, Source, Destination, Services, Action und Security-Profile erfassen.
3. Unter More options bei Bedarf Reset data transfer count wählen und einen für die Anwendung repräsentativen Zeitraum beobachten.
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 zuerst deaktivieren, im vereinbarten Zeitraum beobachten und erst danach löschen.
8. Entscheidung, Test und Rückbau im Change dokumentieren.

Ein Zähler von null ist kein Beweis, wenn der Beobachtungszeitraum zu kurz war. Ebenso beweist ein fehlender Logeintrag nichts, wenn Log firewall traffic vorher ausgeschaltet war oder die lokalen beziehungsweise externen Logziele nicht passend konfiguriert sind. Unter System services > Log settings wird festgelegt, welche Firewall-Logs lokal, an Sophos Central oder an Syslog-Server gehen.

Änderung und Wirkung nachvollziehen

Die Description erklärt, warum eine Regel existieren soll. Sie beweist nicht, wer sie tatsächlich geändert hat. SFOS 22 kann Änderungen an Firewall-Regeln über Configuration Audit mit vorheriger und neuer Konfiguration, Zeitstempel, Administrator und Quell-IP erfassen. Der Status wird mit system configuration-audit show geprüft; standardmässig ist die Funktion 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