Dokumentera Sophos Firewall-regler

Firewallregler blir snabbt oöverskådliga. I början är varje regel logisk: en server behöver internetåtkomst, en tjänst publiceras, en VPN behöver åtkomst eller en applikation kräver specifika portar. Några månader senare vet ofta ingen längre varför regeln finns, vem som begärde den eller om den fortfarande behövs.

Den enklaste motåtgärden är inte en stor CMDB, utan en tydlig beskrivning direkt i Sophos Firewall-regeln. Redan några konsekventa uppgifter hjälper vid troubleshooting, revisioner, städning och överlämningar.

För regelns uppbyggnad är Förstå och konfigurera Sophos Firewall-regler korrekt grundartikeln. När en regel har sparats passar Testa Sophos Firewall-regel med Log Viewer och Packet Capture.

Varför Regeldokumentation Är Viktig

En firewallregel är inte bara ett tekniskt tillstånd, utan ett driftbeslut: vem får nå vad, via vilken tjänst, med vilken risk och av vilken anledning?

Utan dokumentation uppstår typiska problem:

• Gamla regler förblir aktiva eftersom ingen känner till syftet.
• Testregler tas aldrig bort.
• Revisioner tar onödigt mycket tid.
• Störningar tar längre tid eftersom applikationens owner är oklar.
• Ändringar görs direkt på firewallen men dokumenteras inte begripligt.
• Regler städas inte bort av rädsla för sidoeffekter.

En bra beskrivning förhindrar inte alla dessa problem, men minskar friktionen i driften tydligt.

Var Beskrivningen Anges

Fältet Description finns direkt i firewallregeln. Regeln öppnas under:

Rules and policies > Firewall rules

Därefter redigeras den aktuella regeln och beskrivningsfältet fylls i.

Fältet är begränsat. Det ska därför inte ersätta fullständig teknisk dokumentation, utan göra den viktigaste driftinformationen synlig direkt i firewallen. Detaljer kan ligga i ett ticket, wiki, change request eller projektmapp.

Vad Som Hör Hemma I Regelbeskrivningen

Source, Destination, Services, NAT och Security Features syns redan i regeln. Beskrivningen ska därför inte upprepa allt, utan förklara det som annars inte längre är uppenbart senare.

Användbara uppgifter:

• Syfte: Varför finns regeln?
• Applikation / tjänst: Vilken applikation eller process behöver regeln?
• Owner: Vem är ansvarig?
• Ticket / change: Var är ändringen dokumenterad?
• Skapare / ändrare: Vem skapade eller ändrade regeln?
• Datum: När skapades eller granskades regeln senast?
• Review: När ska regeln granskas eller tas bort?
• Särskild notering: Medveten avvikelse, undantag eller risk.

Alla regler behöver inte alla fält. För en standardklientregel räcker ofta mindre. DNAT, VPN, management, partneråtkomst eller temporära undantag bör beskrivas mer exakt.

Kombinera Namn Och Description

Regelnamnet ska vara kort och strukturerat. Description förklarar sammanhanget. Det finns inte ett perfekt schema som passar alla företag. Viktigt är att en administratör ungefär förstår vad regeln gör när regelbasen skannas, utan att varje regel måste öppnas.

I praktiken fungerar framför allt tre varianter bra:

• Källa, destination, tjänst: VLAN12_WAN_HTTPS. Bra standardvariant för klient-, server- och VPN-regler.
• Applikation, källa, destination: ERP_VPNUSERS_SRVERP_HTTPS. Nyttigt när applikationen är viktigare än nätsegmentet.
• Regeltyp som prefix: DNAT_WAN_SRVWEB01_HTTPS. Hjälpsamt vid DNAT, Drop-regler, temporära regler eller specialfall.

Vi använder ofta mönstret SOURCE_DESTINATION_PORT, eftersom det förblir tekniskt och snabbt läsbart även efter månader. Åtgärden behöver inte nödvändigtvis stå i namnet, eftersom Sophos Firewall redan visar Accept, Drop eller Reject i regeln.

Typiska exempel:

• 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

Beroende på miljö kan schemat utökas något:

• ZONE_SOURCE_DESTINATION_PORT, till exempel LAN_VLAN12_WAN_HTTPS
• APP_SOURCE_DESTINATION_PORT, till exempel ERP_VPNUSERS_SRVERP_HTTPS
• CHANGE_SOURCE_DESTINATION_PORT, till exempel CHG1842_VPNUSERS_SRVERP_HTTPS

I små miljöer räcker ofta ett enkelt mönster. I större miljöer med många VLANs, VPNs, servernät och DNAT-regler blir en konsekvent standard mycket mer värdefull. Prefix som DNAT, DROP eller TEMP är användbara när de gör det snabbare att skanna regelbasen eller markerar en särskild regeltyp.

Mycket generiska namn bör undvikas eftersom de inte hjälper senare:

• Rule1
• Test
• Allow
• Internet
• Temp

Kompakt Exempel

Exempel på en produktionsregel:

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

Om utrymmet är begränsat kan man arbeta kortare. Syfte, owner och ticket ska ändå framgå:

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

För en temporär regel ska utgångsdatumet vara särskilt tydligt:

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

Vad Som Inte Ska Skrivas I Description

Description-fältet ska inte innehålla:

• lösenord,
• API-nycklar,
• personuppgifter utan anledning,
• konfidentiella kunddata,
• fullständiga åtkomstinstruktioner för tredje part,
• långa externa URL:er utan intern kontext.

Om externa leverantörer är inblandade räcker ofta en intern kontaktperson, ett ticket eller en dokumentationsreferens. Känsliga detaljer hör hemma i ett lämpligt ticket-, dokumentations- eller lösenordssystem, inte i en firewallregel.

Review Och Städning

Regelbeskrivningen är bara första steget. Avgörande är att regler granskas regelbundet.

Praktiskt arbetssätt:

1. Markera regler utan Description.
2. Kontrollera regler med Test, Temp, Allow any eller otydliga namn.
3. Utvärdera Usage Counter och Log Viewer.
4. Leta efter owner eller ticket.
5. Inaktivera regler som inte längre behövs, observera dem och ta bort dem senare.
6. Dokumentera ändringen.

Vid varje städning bör Log firewall traffic vara aktiverat för relevanta regler, så att Log Viewer visar om en regel fortfarande används. För tester efter ändringar hjälper Testa Sophos Firewall-regel med Log Viewer och Packet Capture.

Minimistandard För Nya Regler

Nya Sophos Firewall-regler bör minst ha:

• ett tydligt namn,
• tydlig Source och Destination i stället för onödigt Any,
• logging aktiverat för viktiga regler,
• en Description med syfte, owner och ticket,
• reviewdatum för temporära eller riskabla regler,
• inga hemligheter i beskrivningsfältet,
• ett test efter sparande.

För publicerade servrar är även Publicera server med DNAT på Sophos Firewall relevant. För NAT-grunder passar Förstå NAT på Sophos Firewall: SNAT, DNAT, MASQ, PAT.

FAQ