Förstå och konfigurera Sophos Firewall-regler

Firewall Rules är kärnan i Sophos Firewall. De avgör vilken trafik mellan zoner, nätverk, användare och tjänster som tillåts eller blockeras, och vilka skyddsfunktioner som används.

Den här artikeln förklarar en Sophos Firewall Rule uppifrån och ned: ordning, grupper, Action, logging, Source, Destination, Services, User Matching, Exclusions, NAT, Web Filtering, TLS Inspection, Security Heartbeat, Application Control, IPS, Traffic Shaping, DSCP, NDR och e-postskanning.

Menysökvägen är:

Rules and policies > Firewall rules > Add firewall rule > New firewall rule

Snabbnavigering

• Grundprincip och ordning
• Praktiskt exempel
• Övre delen: status, namn, åtgärd och logging
• Source
• Destination and services
• Match known users
• Add exclusion
• Create linked NAT rule
• Web filtering
• Synchronized Security Heartbeat
• Other security features
• Scan email content
• Kontroll efter sparande
• Vanliga fel

Grundprincip och ordning

Firewall Rules styr trafik mellan zoner och nätverk. De kan tillåta, släppa eller blockera trafik och tillämpa extra Security Features.

Sophos Firewall kontrollerar Firewall Rules uppifrån och ned. Så snart en regel matchar kontrolleras inte efterföljande regler. Därför är det inte bara viktigt vad som står i regeln, utan även var den ligger i regellistan.

En regel matchar bara om alla relevanta kriterier stämmer samtidigt:

Den första matchande regeln vinner. Om en generell LAN_to_WAN_Any-regel ligger ovanför en mer specifik LAN_to_WAN_Restricted-regel nås den specifika regeln aldrig.

Praktiskt exempel

I detta exempel skapas en tydlig klientregel:

Mål: klienter från det interna LAN får gå ut på internet. Web Filtering, Application Control, IPS och logging ska vara aktiva. Servrar, gäster och managementnät får egna regler och blandas inte in i denna klientregel.

Detta exempel är medvetet inte ett Any-fripass. I praktiken bör klientnät, servernät, gäst-Wi-Fi, VoIP och management behandlas separat.

Övre delen: status, namn, åtgärd och logging

Rule status

Rule status aktiverar eller inaktiverar regeln.

En ny regel är normalt aktiv. För förberedda regler kan statusen inaktiveras och regeln aktiveras senare. Inaktiverade regler bör granskas regelbundet så att gamla test- eller migreringsregler inte blir kvar i konfigurationen.

Praktiskt exempel: en ny regel för en server förbereds men aktiveras först under servicefönstret.

Rule name

Namnet ska omedelbart visa vad regeln gör.

Bra namn:

• LAN_to_WAN_Clients
• Guest_to_WAN_WebOnly
• Server_to_WAN_Updates
• VoIP_to_WAN_SIP_RTP
• WAN_to_DMZ_HTTPS_Webserver

Namn som Rule1, Test, Allow eller Internet är mindre användbara eftersom det senare inte går att se vilken uppgift regeln hade.

Description

Beskrivningen är viktig för drift, support och revisioner. Den bör ange:

• varför regeln finns
• vem som begärde regeln
• vilka begränsningar som satts medvetet
• om det finns ett ärende, projekt eller slutdatum

Exempel:

Internet Access for client network 10.10.10.0/24. Web filtering and IPS enabled. Requested by IT, reviewed on 10 June 2026.

Hur man använder fältet korrekt och dokumenterar Firewall Rules spårbart beskrivs mer utförligt i Dokumentera en Sophos Firewall Rule enkelt.

Rule position

Rule position anger var den nya regeln infogas.

Grundregel: specifikt före generellt. En regel för en enskild server eller en viss applikation ligger oftast ovanför en generell internetregel.

Rule group

Rule group är en organisatorisk gruppering. Gruppen är ingen säkerhetsgräns och ingen separat policy engine. Firewallen kontrollerar fortfarande enskilda regler uppifrån och ned.

Användbara grupper:

• Internet Access
• Server Rules
• DNAT
• VPN
• Guest
• Management
• Block Rules

I små miljöer kan None räcka. I större miljöer lönar sig tydlig gruppering tidigt eftersom regelbasen snabbt blir svår att läsa.

Action

Action avgör vad som händer med matchande trafik.

För normala klient- eller serverregler används oftast Accept. För blockregler är Drop tystare, medan Reject ofta är bekvämare vid troubleshooting.

Log firewall traffic

Log firewall traffic bör nästan alltid vara aktiverat på viktiga regler.

Utan logging saknas viktig information senare i Log viewer. Många troubleshootingfall misslyckas inte på grund av regeln i sig, utan för att logging inte var aktiverat och man inte ser vilken regel som faktiskt matchade.

Viktigt: firewallen loggar normalt Firewall-sessioner när en anslutning avslutas och ett Destroy-event skapas. Alla anslutningar visas därför inte exakt när klienten startar dem.

För att loggar ska synas lokalt, i Sophos Central eller via syslog måste även System services > Log settings vara rätt konfigurerat. För längre lagring är Sophos Central Firewall Reporting eller en syslogserver lämplig. Mer information: Aktivera Central Firewall Reporting.

Source

I Source definieras var trafiken kommer ifrån.

Source zones

Source zones är zonen som trafiken kommer från.

Exempel:

• LAN för interna klientnät
• VPN för Remote Access-användare
• DMZ för servernät
• Guest för gäst-Wi-Fi
• WAN för inkommande internettrafik

Praktiskt exempel: för en internetregel från klienter till internet väljs LAN. För en DNAT-regel utifrån till en intern server använder tillhörande Firewall Rule oftast WAN som Source zone.

Source networks and devices

Source networks and devices begränsar källan mer exakt.

Möjliga objekt:

• enskilda hosts
• nätverk
• IP ranges
• hostgrupper
• FQDN Hosts
• landsobjekt

Any verkar enkelt i början, men är ofta för brett. Ett konkret klientnät, en hostgrupp eller ett tydligt namngivet nätverksobjekt är bättre.

Praktiskt exempel: i stället för Any som Source används net_LAN_Clients. Servrar, skrivare, gäster och managementenheter får egna regler.

During scheduled time

During scheduled time anger när regeln gäller.

Typiska värden:

• All the time
• arbetstid
• servicefönster
• tillfällig åtkomst

Schedules är användbara när åtkomst bara ska tillåtas vid vissa tider. Vid troubleshooting måste man alltid kontrollera att firewalltid, tidszon och schedule verkligen stämmer.

Praktiskt exempel: extern serviceåtkomst till en server tillåts endast under ett definierat servicefönster.

Destination and services

I Destination and services definieras vart trafiken får gå och vilka portar eller protokoll som är tillåtna.

Destination zones

Destination zones är målzonen.

Exempel:

• WAN för internetåtkomst
• DMZ för servrar i en DMZ
• LAN för interna mål
• VPN för fjärranvändare eller Site-to-Site-tunnlar

Praktiskt exempel: för klienttrafik till internet används WAN. För klientåtkomst till en intern server kan Server eller DMZ användas om dessa zoner finns.

Destination networks

Destination networks begränsar målet mer exakt.

För klientregler mot internet är Any ofta en praktisk start. För servrar, managementnät eller VPN-åtkomst bör målen begränsas mycket tydligare.

Exempel:

• Any för generell internetåtkomst
• FQDN Host som updates.vendor.com
• hostobjekt för en intern server
• nätverksobjekt för en fjärrsite via VPN
• landsobjekt för Geo-IP-regler

Praktiskt exempel: en backupserver får bara gå till leverantörens cloud backup-destinationer, inte till Any.

Services

Services är protokoll- och portdefinitioner.

Exempel:

• HTTP för TCP 80
• HTTPS för TCP 443
• DNS för TCP/UDP 53
• NTP för UDP 123
• egna services som Synology_5555

Services bör väljas så snävt som möjligt. Any är bara rimligt om alla protokoll verkligen måste tillåtas eller om andra kontroller används medvetet.

Praktiskt exempel: för vanliga webbklienter räcker ofta en grupp med HTTP, HTTPS, DNS och NTP. För serveråtkomst från internet tillåts endast den faktiskt publicerade tjänsten.

Match known users

Med Match known users blir användaridentitet en del av matchningen. Regeln gäller då inte bara IP-adresser, utan kända användare eller grupper.

Det är användbart när:

• Web Policies ska gälla per AD-grupp
• reporting ska vara användarbaserat
• olika användargrupper ska ha olika internetbehörigheter
• MFA, Captive Portal eller SSO redan är korrekt konfigurerat

Fallgrop: om autentisering inte fungerar korrekt kanske regeln inte matchar. Trafiken faller då till en mer generell regel under eller blockeras av drop-all-regeln.

För första tester är det ofta bättre att börja utan User Matching och lägga till användarkriterier senare.

Add exclusion

Med Add exclusion kan trafik undantas från en regel. Firewallen hoppar bara över regeln om alla angivna exclusion-kriterier matchar och kontrollerar sedan nästa regel.

Exclusions kan innehålla Source zones, Source networks and devices, Destination zones, Destination networks och Services.

Praktiskt exempel: en generell klientregel mot internet använder Web Filtering. En viss uppdateringsserver ska dock gå via en egen regel med andra Security Features. Då kan servern undantas från den generella regeln.

Exclusions är kraftfulla, men gör regler svårare att läsa. Om en regel har många undantag är en separat specifik regel ofta mer begriplig.

Create linked NAT rule

Med Create linked NAT rule kan en Source NAT-regel skapas direkt från Firewall Rule. Denna Linked NAT Rule visas sedan i NAT-regeltabellen.

För nybörjare låter det bekvämt, men i praktiken är fristående NAT-regler oftast tydligare. Om en generisk NAT-regel redan täcker samma trafik korrekt bör ingen extra Linked NAT Rule skapas.

För en normal klient-till-internet-regel räcker oftast standard-SNAT-regeln med MASQ, så länge den är aktiv och passar regelbasen.

Viktigt: NAT tillåter inte trafik av sig självt. NAT översätter adresser eller portar. Om trafik tillåts avgörs fortfarande av matchande Firewall Rule.

Mer information: Förstå NAT på Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Web filtering

I Web filtering konfigureras Web Policy, malware scan och webbfilterbeteende.

Web policy

Web policy styr webbåtkomst via kategorier, användare, grupper, URL groups och regler.

Praktiskt exempel: för klienter används en Web Policy som blockerar malware, phishing, adult content och riskkategorier, men tillåter business-applikationer.

Om ingen Web Policy är satt sker ingen kategoribaserad web filtering via detta alternativ.

Apply web category-based traffic shaping

Detta alternativ tillämpar Traffic Shaping baserat på webbkategorier. Det är endast meningsfullt om motsvarande Traffic Shaping-regler eller Web Category Policies används.

Praktiskt exempel: streamingkategorier begränsas medan business-applikationer prioriteras.

Block QUIC protocol

QUIC använder UDP 80 och UDP 443. Många webbläsare använder QUIC för Google-tjänster och andra moderna webbapplikationer.

Om Web Filtering eller Malware Scan på webbtrafik är viktigt bör Block QUIC protocol vara aktiverat i många miljöer. Webbläsare faller då normalt tillbaka till HTTPS över TCP, som är lättare att kontrollera och inspektera.

Scan HTTP and decrypted HTTPS

Detta alternativ skannar HTTP och redan dekrypterad HTTPS efter malware.

Viktigt: alternativet dekrypterar inte HTTPS automatiskt. För att faktiskt inspektera HTTPS krävs passande SSL/TLS inspection rules under Rules and policies > SSL/TLS inspection rules.

Praktiskt exempel: om TLS Inspection är aktiv för LAN_to_WAN_Clients kan Scan HTTP and decrypted HTTPS skanna nedladdade filer i dekrypterad HTTPS-trafik.

Mer information: Rulla ut TLS Inspection på Sophos Firewall stegvis.

Use Zero-day protection

Use Zero-day protection skickar misstänkta nedladdningar till Sophos Zero-Day Protection för vidare analys. Det är användbart för klient- och serverregler där nedladdningar från internet ska kontrolleras.

Funktionen kräver lämplig licens och kan orsaka fördröjningar beroende på filtyp och policy.

Scan FTP for malware

Detta alternativ skannar FTP-trafik efter malware. Det är bara relevant om FTP faktiskt används och matchande Services är tillåtna i regeln.

FTP är mindre vanligt i moderna miljöer, men förekommer fortfarande i legacy-system, maskinstyrning eller äldre uppdateringsmekanismer.

Use web proxy instead of DPI engine

Sophos Firewall kan inspektera webbtrafik via DPI engine eller via Web Proxy.

För moderna setup är DPI oftast det bättre standardvalet, eftersom HTTP- och SSL/TLS-trafik kan behandlas på alla portar. Web Proxy är fortfarande användbart när särskilda proxyfunktioner behövs, till exempel SafeSearch enforcement, YouTube-begränsningar, Google app domain restriction, Pharming Protection, Web Cache eller Parent Proxy.

Om Use web proxy instead of DPI engine inte är aktiverat arbetar regeln i DPI-läge.

Decrypt HTTPS during web proxy filtering

Detta alternativ hör till Web Proxy-läge. Det är bara relevant om Use web proxy instead of DPI engine är aktiverat och HTTPS ska dekrypteras i proxy-läge.

I DPI-läge styrs HTTPS-decryption inte här, utan via SSL/TLS inspection rules.

Synchronized Security Heartbeat

Med Configure Synchronized Security Heartbeat kan Sophos Endpoint-status inkluderas i Firewall Rule.

Typiska möjligheter:

• ange minsta status för källenheter
• blockera klienter utan Heartbeat
• ange minsta status för målenheter
• blockera förfrågningar till mål utan Heartbeat

Detta är starkt, men bara meningsfullt om Sophos Endpoint, Sophos Central och Security Heartbeat är korrekt konfigurerade.

Praktiskt exempel: klienter med röd Security Heartbeat får inte längre åtkomst till servrar eller internet.

För en första klientregel bör Heartbeat inte aktiveras blint, annars kan enheter som inte kan skicka Heartbeat blockeras.

Other security features

Identify and control applications (App control)

Via Identify and control applications (App control) väljs en Application Filter Policy.

Den kan känna igen och styra applikationer som:

• TeamViewer
• Tor
• Messenger
• Streaming
• Cloud Storage
• Remote-Control-Tools

Application Control kräver lämplig licens. I praktiken ingår funktionen i Sophos Firewall Bundles med Web Protection, till exempel Standard Protection, Xstream Protection eller Epic Protection.

För applikationsidentifiering i krypterad trafik är TLS Inspection ofta avgörande. Utan decryption ser firewallen beroende på tjänst bara hostnames, SNI, certifikatinformation eller IPs, men inte hela innehållet.

Apply application-based traffic shaping policy

Detta alternativ tillämpar Traffic Shaping som definierats i Application Policy eller på Application Object.

Praktiskt exempel: Microsoft Teams ska identifieras och prioriteras med en viss Traffic Shaping Policy. Då måste rätt Application Control Policy vara vald och application-based traffic shaping policy tillämpas.

Om en explicit Traffic Shaping Policy redan är satt i Shape traffic bör det dokumenteras tydligt vilken policy som ska ha företräde och varför.

Detect and prevent exploits (IPS)

Under Detect and prevent exploits (IPS) väljs en IPS Policy.

IPS kontrollerar trafik mot kända attackmönster och exploits. Klienttrafik till internet använder en annan policy än servertrafik eller publicerade tjänster.

Praktiska exempel:

• klientregel LAN_to_WAN: klient- eller LAN-to-WAN-IPS-policy
• DNAT-regel till webbserver: server- eller webserver-IPS-policy
• VoIP-regel: testa försiktigt eftersom aggressiva IPS-profiler kan störa VoIP

IPS bör inte bara aktiveras överallt med den hårdaste policyn. En för bred eller fel IPS Policy kan bryta legitim trafik eller skapa onödig last.

Shape traffic

Med Shape traffic kan en Traffic Shaping Policy tillämpas direkt på regeln.

Det är relevant för:

• VoIP
• videokonferenser
• backuptrafik
• gäst-Wi-Fi
• långsamma WAN-länkar

Praktiskt exempel: gäst-Wi-Fi får en limit policy så att business-trafik inte trängs undan.

Mer information: Konfigurera Application Traffic Shaping på Sophos Firewall.

DSCP marking

DSCP marking markerar paket för Quality of Service på efterföljande nätverksenheter.

Det är bara meningsfullt om switchar, routrar eller WAN-enheter också utvärderar dessa DSCP-värden. Sophos Firewall kan markera, men resten av nätverket måste behandla markeringarna konsekvent.

Praktiskt exempel: VoIP-trafik får DSCP-markering så att switchar och WAN-routrar prioriterar trafiken.

Scan with NDR Active threat intelligence

Scan with NDR Active threat intelligence använder Sophos NDR Threat Intelligence för extra bedömning av nätverkstrafik.

Alternativet är bara meningsfullt om miljön använder nödvändiga Sophos Central- och NDR-komponenter. I många miljöer är det inte första valet för en basregel, men kan vara ett värdefullt tillägg i mer övervakade nätverk.

Scan email content

Avsnittet Scan email content gäller e-postprotokoll.

Möjliga alternativ:

• Scan IMAP
• Scan IMAPS
• Scan POP3
• Scan POP3S
• Scan SMTP
• Scan SMTPS

Om protokoll aktiveras här måste motsvarande standardportar också ingå i regelns Services eller läggas till via Add ports.

För normala webbklientregler är detta avsnitt ofta inte relevant. För mailservrar eller klientmailtrafik bör det planeras medvetet.

Praktiskt exempel: en intern mailserver får skicka SMTP utåt. Då skapas en separat serverregel, logging aktiveras och e-postskanning kontrolleras enligt mailarkitekturen.

Kontroll efter sparande

Efter sparande bör regeln testas i stället för att anta att allt fungerar korrekt.

Kontrollera:

1. Står regeln på rätt position?
2. Är Log firewall traffic aktiverat?
3. Matchar regeln i Log viewer?
4. Visas förväntad Firewall Rule ID?
5. Tillämpas förväntad NAT-regel?
6. Fungerar DNS?
7. Tillämpas Web Filtering, IPS, Application Control och TLS Inspection som förväntat?
8. Finns oväntade drops eller SSL/TLS-fel?

För en ren kontroll hjälper Testa Firewall Rules med Log Viewer, Policy Test och Packet Capture.

Vanliga fel

Regeln ligger för långt ned: en mer generell regel ovanför matchar trafiken först.

Source är för bred: Any fungerar ibland, men gör regler otydliga och ökar attackytan.

Destination är för bred: servrar eller managementnät bör sällan få gå till internet med Any.

Services är för breda: Any tillåter mycket mer än nödvändigt. Konkreta services eller servicegrupper är bättre.

Logging är inte aktiverat: då saknas den viktigaste informationen i Log Viewer.

HTTPS skannas inte: Scan HTTP and decrypted HTTPS är aktivt, men det finns ingen matchande SSL/TLS inspection rule eller ingen decryption.

Web Filtering tillämpas inte: ingen Web Policy är satt, fel användare, fel Source zone eller QUIC är inte blockerat.

User Matching tillämpas inte: autentisering, AD SSO, Captive Portal eller användarmappning fungerar inte korrekt.

NAT saknas: Firewall Rule tillåter trafiken, men SNAT/MASQ matchar inte.

Security Feature passar inte trafiken: fel IPS Policy, proxyalternativ eller e-postskanningsalternativ kan bryta legitim trafik.