Sophos Firewall-regels goed documenteren

Firewallregels worden snel onoverzichtelijk. In het begin is elke regel logisch: een server moet naar internet, een service wordt gepubliceerd, een VPN heeft toegang nodig of een applicatie vereist specifieke poorten. Maanden later weet vaak niemand meer waarom een regel bestaat, wie hem heeft aangevraagd en of hij nog nodig is.

De eenvoudigste tegenmaatregel is geen grote CMDB, maar een duidelijke beschrijving direct in de Sophos Firewall-regel. Een paar consistente gegevens helpen al bij troubleshooting, audits, opruimacties en overdrachten.

Voor de opbouw van een regel is Sophos Firewall-regels begrijpen en correct configureren het basisartikel. Als een regel na het opslaan getest moet worden, is Sophos Firewall-regel testen met Log Viewer en Packet Capture passend.

Waarom Regeldocumentatie Belangrijk Is

Een firewallregel is niet alleen een technische vrijgave, maar een operationele beslissing: wie mag waarheen, via welke dienst, met welk risico en om welke reden?

Zonder documentatie ontstaan typische problemen:

• Oude regels blijven actief omdat niemand het doel kent.
• Testregels worden nooit verwijderd.
• Audits kosten onnodig veel tijd.
• Storingen duren langer omdat de owner van de applicatie onduidelijk is.
• Wijzigingen worden direct op de firewall gedaan, maar niet begrijpelijk vastgelegd.
• Regels worden niet opgeschoond uit angst voor bijwerkingen.

Een goede beschrijving voorkomt deze problemen niet volledig, maar verlaagt de frictie in het beheer duidelijk.

Waar De Beschrijving Wordt Ingevuld

Het veld Description bevindt zich direct in de firewallregel. Open de regel via:

Rules and policies > Firewall rules

Bewerk daarna de betreffende regel en vul het beschrijvingsveld in.

Het veld is beperkt. Daarom moet het niet de volledige technische documentatie vervangen, maar de belangrijkste operationele informatie direct zichtbaar maken. Details kunnen in een ticket, wiki, change request of projectmap staan.

Wat In De Regelbeschrijving Hoort

Source, Destination, Services, NAT en Security Features zijn al zichtbaar in de regel. De beschrijving moet daarom niet alles herhalen, maar uitleggen wat later anders niet meer duidelijk is.

Nuttige gegevens:

• Doel: Waarom bestaat de regel?
• Applicatie / dienst: Welke applicatie of welk proces heeft de regel nodig?
• Owner: Wie is verantwoordelijk?
• Ticket / change: Waar is de wijziging gedocumenteerd?
• Maker / bewerker: Wie heeft de regel gemaakt of aangepast?
• Datum: Wanneer is de regel gemaakt of voor het laatst gecontroleerd?
• Review: Wanneer moet de regel opnieuw worden gecontroleerd of verwijderd?
• Bijzonderheid: Bewuste afwijking, uitzondering of risico.

Niet elke regel heeft alle velden nodig. Voor een standaard clientregel is vaak minder voldoende. Voor DNAT, VPN, management, partnertoegang of tijdelijke uitzonderingen moet de beschrijving nauwkeuriger zijn.

Naam En Description Combineren

De regelnaam moet kort en gestructureerd zijn. De Description legt de context uit. Er is niet één perfect schema dat voor elk bedrijf past. Belangrijk is dat een beheerder bij het scannen van de regelbasis ongeveer begrijpt wat de regel doet, zonder elke regel afzonderlijk te openen.

In de praktijk werken vooral drie varianten goed:

• Bron, bestemming, dienst: VLAN12_WAN_HTTPS. Goede standaard voor client-, server- en VPN-regels.
• Applicatie, bron, bestemming: ERP_VPNUSERS_SRVERP_HTTPS. Nuttig als de applicatie belangrijker is dan het netwerksegment.
• Regeltype als prefix: DNAT_WAN_SRVWEB01_HTTPS. Handig bij DNAT, Drop-regels, tijdelijke regels of uitzonderingen.

Wij gebruiken vaak het patroon SOURCE_DESTINATION_PORT, omdat het technisch blijft en ook na maanden snel leesbaar is. De actie hoeft niet per se in de naam te staan, omdat Sophos Firewall Accept, Drop of Reject al in de regel toont.

Typische voorbeelden:

• 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

Afhankelijk van de omgeving kan het schema iets worden uitgebreid:

• ZONE_SOURCE_DESTINATION_PORT, bijvoorbeeld LAN_VLAN12_WAN_HTTPS
• APP_SOURCE_DESTINATION_PORT, bijvoorbeeld ERP_VPNUSERS_SRVERP_HTTPS
• CHANGE_SOURCE_DESTINATION_PORT, bijvoorbeeld CHG1842_VPNUSERS_SRVERP_HTTPS

Voor kleine omgevingen is een eenvoudig patroon vaak genoeg. In grotere omgevingen met veel VLANs, VPNs, servernetwerken en DNAT-regels is een consequente standaard veel waardevoller. Prefixen zoals DNAT, DROP of TEMP zijn zinvol wanneer ze helpen bij snel scannen of een bijzonder regeltype aangeven.

Zeer generieke namen kun je beter vermijden, omdat je er later niets meer uit kunt afleiden:

• Rule1
• Test
• Allow
• Internet
• Temp

Compact Voorbeeld

Voorbeeld van een productieregel:

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

Als er weinig ruimte is, kan het korter. Het doel, de owner en het ticket moeten dan nog steeds herkenbaar blijven:

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

Voor een tijdelijke regel moet de einddatum bijzonder duidelijk zijn:

Temp vendor access voor migratie, Owner IT, CHG-1910, remove after 2026-07-31

Wat Niet In De Description Hoort

Niet in het Description-veld horen:

• wachtwoorden,
• API-sleutels,
• persoonsgegevens zonder reden,
• vertrouwelijke klantgegevens,
• volledige toegangsprocedures voor derden,
• lange externe URL’s zonder interne context.

Als externe dienstverleners betrokken zijn, is vaak een interne contactpersoon, ticket of documentatieverwijzing voldoende. Gevoelige details horen in een geschikt ticket-, documentatie- of wachtwoordsysteem, niet in een firewallregel.

Review En Opschonen

Regeldocumentatie is alleen de eerste stap. Beslissend is dat regels regelmatig worden gecontroleerd.

Praktische aanpak:

1. Regels zonder Description markeren.
2. Regels met Test, Temp, Allow any of onduidelijke naam controleren.
3. Usage Counter en Log Viewer analyseren.
4. Owner of ticket zoeken.
5. Niet meer benodigde regels uitschakelen, observeren en later verwijderen.
6. Wijzigingen documenteren.

Bij elke opruimactie moet Log firewall traffic voor relevante regels actief zijn, zodat Log Viewer toont of een regel nog wordt gebruikt. Voor tests na wijzigingen helpt Sophos Firewall-regel testen met Log Viewer en Packet Capture.

Minimumstandaard Voor Nieuwe Regels

Nieuwe Sophos Firewall-regels zouden minimaal moeten hebben:

• een duidelijke naam,
• duidelijke Source en Destination in plaats van onnodig Any,
• logging actief voor belangrijke regels,
• een Description met doel, owner en ticket,
• een reviewdatum voor tijdelijke of risicovolle regels,
• geen geheimen in het beschrijvingsveld,
• een test na het opslaan.

Voor gepubliceerde servers is ook Server via DNAT op Sophos Firewall publiceren relevant. Voor NAT-basiskennis past NAT op Sophos Firewall begrijpen: SNAT, DNAT, MASQ, PAT.

FAQ