Sophos Firewall-Regeln sinnvoll dokumentieren

Firewall-Regeln werden schnell unübersichtlich. Am Anfang ist jede Regel logisch: ein Server muss ins Internet, ein Dienst wird veröffentlicht, ein VPN braucht Zugriff, eine Anwendung benötigt spezielle Ports. Monate später weiss oft niemand mehr, warum eine Regel existiert, wer sie angefordert hat und ob sie noch gebraucht wird.

Die einfachste Gegenmassnahme ist keine grosse CMDB, sondern eine saubere Beschreibung direkt in der Sophos Firewall-Regel. Schon wenige konsistente Angaben helfen bei Troubleshooting, Audits, Aufräumarbeiten und Übergaben.

Für den Aufbau einer Regel ist Sophos Firewall-Regeln verstehen und richtig konfigurieren der Grundartikel. Wenn eine Regel nach dem Speichern geprüft werden soll, passt Sophos Firewall Regel testen mit Log Viewer und Packet Capture.

Warum Regel-Dokumentation wichtig ist

Eine Firewall-Regel ist nicht nur eine technische Freigabe, sondern eine Betriebsentscheidung: Wer darf wohin, über welchen Dienst, mit welchem Risiko und aus welchem Grund?

Ohne Dokumentation entstehen typische Probleme:

• Alte Regeln bleiben aktiv, weil niemand den Zweck kennt.
• Testregeln werden nie entfernt.
• Audits kosten unnötig viel Zeit.
• Störungen dauern länger, weil der Owner der Anwendung unklar ist.
• Änderungen werden direkt auf der Firewall gemacht, aber nicht nachvollziehbar dokumentiert.
• Regeln werden aus Angst vor Nebenwirkungen nicht bereinigt.

Eine gute Beschreibung verhindert diese Probleme nicht vollständig, senkt aber die Reibung im Betrieb deutlich.

Wo man die Beschreibung einträgt

Das Feld Description befindet sich direkt in der Firewall-Regel. Man öffnet die Regel unter:

Rules and policies > Firewall rules

Danach die betroffene Regel bearbeiten und das Beschreibungsfeld pflegen.

Das Feld ist begrenzt. Deshalb sollte es nicht die vollständige technische Dokumentation ersetzen, sondern die wichtigsten Betriebsinformationen direkt sichtbar machen. Details können in einem Ticket, Wiki, Change Request oder Projektordner liegen.

Was in die Regelbeschreibung gehört

In der Regel selbst sind Source, Destination, Services, NAT und Security Features bereits sichtbar. Die Beschreibung sollte deshalb nicht alles wiederholen, sondern erklären, was man später sonst nicht mehr erkennt.

Sinnvolle Angaben:

• Zweck: Warum existiert die Regel?
• Anwendung oder Dienst: Welche Applikation oder welcher Prozess braucht die Regel?
• Owner: Wer ist fachlich verantwortlich?
• Ticket oder Change: Wo ist die Änderung dokumentiert?
• Ersteller oder Änderer: Wer hat die Regel erstellt oder angepasst?
• Datum: Wann wurde die Regel erstellt oder zuletzt geprüft?
• Review: Wann soll die Regel wieder geprüft oder entfernt werden?
• Besonderheit: Welche bewusste Abweichung, Ausnahme oder welches Risiko gehört zur Regel?

Nicht jede Regel braucht alle Felder. Für eine Standard-Clientregel reicht oft weniger. Für DNAT, VPN, Management, Partnerzugriffe oder temporäre Ausnahmen sollte die Beschreibung genauer sein.

Namen und Description kombinieren

Der Regelname sollte kurz und strukturiert sein. Die Description erklärt den Kontext. Es gibt dabei nicht das eine perfekte Schema, das für jede Firma passt. Wichtig ist, dass ein Admin beim Blick auf die Regelbasis ungefähr versteht, was die Regel macht, ohne jede Regel einzeln öffnen zu müssen.

In der Praxis haben sich vor allem drei Varianten bewährt:

• Quelle, Ziel, Dienst: VLAN12_WAN_HTTPS ist eine gute Standardvariante für Client-, Server- und VPN-Regeln.
• Anwendung, Quelle, Ziel: ERP_VPNUSERS_SRVERP_HTTPS ist sinnvoll, wenn die Anwendung wichtiger ist als das Netzwerksegment.
• Regeltyp als Prefix: DNAT_WAN_SRVWEB01_HTTPS hilft bei DNAT, Drop-Regeln, temporären Regeln oder Sonderfällen.

Wir verwenden häufig das Muster SOURCE_DESTINATION_PORT, weil es technisch bleibt und auch nach Monaten noch schnell lesbar ist. Die Aktion muss nicht zwingend in den Namen, da die Sophos Firewall Accept, Drop oder Reject bereits in der Regel anzeigt.

Typische Beispiele:

• VLAN12_WAN_HTTPS
• VLAN20_WAN_DNS
• VLANGUEST_WAN_WEB
• SRVEXC01_WAN_SMTP
• WSTONY01_SRVFILE_SMB
• VPNUSERS_SRVERP_HTTPS
• ADMINNET_FIREWALL_HTTPS
• DNAT_WAN_SRVWEB01_HTTPS
• DNAT_WAN_SRVDMS01_TCP5555
• DROP_VLANIOT_INTERNAL_ANY

Je nach Umgebung kann man das Schema leicht erweitern:

• ZONE_SOURCE_DESTINATION_PORT, zum Beispiel LAN_VLAN12_WAN_HTTPS
• APP_SOURCE_DESTINATION_PORT, zum Beispiel ERP_VPNUSERS_SRVERP_HTTPS
• CHANGE_SOURCE_DESTINATION_PORT, zum Beispiel CHG1842_VPNUSERS_SRVERP_HTTPS

Für kleine Umgebungen reicht oft ein einfaches Muster. In grösseren Umgebungen mit vielen VLANs, VPNs, Servernetzen und DNAT-Regeln lohnt sich ein konsequenter Standard stärker. Prefixe wie DNAT, DROP oder TEMP sind sinnvoll, wenn sie beim schnellen Scannen helfen oder auf eine besondere Regelart hinweisen.

Eher vermeiden sollte man sehr generische Namen, weil man daraus später nichts mehr ableiten kann:

• Rule1
• Test
• Allow
• Internet
• Temp

Kompaktes Beispiel

Beispiel für eine produktive Regel:

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

Wenn wenig Platz vorhanden ist, kann man kürzer arbeiten. Wichtig ist dann vor allem, dass Zweck, Owner und Ticket noch erkennbar bleiben:

ERP VPN access, Owner Finance, CHG-1842, Review 2026-12

Für eine temporäre Regel sollte das Ablaufdatum besonders klar sein:

Temp vendor access für Migration, Owner IT, CHG-1910, remove after 2026-07-31

Was man nicht in die Beschreibung schreiben sollte

Nicht in das Description-Feld gehören:

• Passwörter,
• API-Schlüssel,
• personenbezogene Daten ohne Grund,
• vertrauliche Kundendaten,
• vollständige Zugangsanleitungen für Dritte,
• lange externe URLs ohne internen Kontext.

Wenn externe Dienstleister beteiligt sind, reicht oft ein interner Ansprechpartner, ein Ticket oder ein Dokumentationsverweis. Sensible Details gehören in ein geeignetes Ticket- oder Dokumentationssystem, nicht in eine Firewall-Regel.

Review und Aufräumen

Regelbeschreibung ist nur der erste Schritt. Entscheidend ist, dass Regeln regelmässig geprüft werden.

Praktischer Ablauf:

1. Regeln ohne Description markieren.
2. Regeln mit Test, Temp, Allow any oder unklarem Namen prüfen.
3. Usage Counter und Log Viewer auswerten.
4. Owner oder Ticket suchen.
5. Nicht mehr benötigte Regeln deaktivieren, beobachten und später entfernen.
6. Änderungen dokumentieren.

Bei jeder Bereinigung sollte Log firewall traffic für relevante Regeln aktiv sein, damit man im Log Viewer sieht, ob eine Regel noch genutzt wird. Für Tests nach Änderungen hilft Sophos Firewall Regel testen mit Log Viewer und Packet Capture.

Mindeststandard für neue Regeln

Für neue Sophos Firewall-Regeln sollte mindestens gelten:

• sprechender Name,
• klare Source und Destination statt unnötig Any,
• Logging bei wichtigen Regeln aktiv,
• Description mit Zweck, Owner und Ticket,
• Review-Datum bei temporären oder riskanten Regeln,
• keine geheimen Informationen im Beschreibungsfeld,
• Test nach dem Speichern.

Für veröffentlichte Server ist zusätzlich Server per DNAT auf Sophos Firewall veröffentlichen relevant. Für NAT-Grundlagen passt NAT auf Sophos Firewall verstehen: SNAT, DNAT, MASQ, PAT.

FAQ