Förstå och säkert konfigurera Sophos Firewall-regler

En Sophos Firewall-regel avgör vilken trafik mellan zoner, nätverk, användare och tjänster som tillåts eller blockeras. Det avgörande är inte att aktivera så många alternativ som möjligt, utan att använda lämpliga matchningskriterier, rätt ordning, ändamålsenliga skyddsfunktioner och ett reproducerbart test.

Menysökvägen är:

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

Den här artikeln förklarar regelformuläret uppifrån och ned och använder genomgående exemplet LAN_to_WAN_Clients. Specialområden som NAT, TLS Inspection och IPS förklaras i den omfattning som behövs för brandväggsregeln. Detaljerade instruktioner länkas direkt på respektive plats.

Planera innan regeln skapas

Fastställ rätt ansvarsområde

Vanliga brandväggsregler styr vidarebefordrad trafik som passerar genom brandväggen. Andra uppgifter konfigureras på andra ställen:

• Lokala brandväggstjänster: WebAdmin, User Portal, VPN Portal, SSH, DNS och SNMP styrs via Administration > Device access, Local Service ACL och konfigurationen för respektive tjänst. För detta används Device Access och Local Service ACL.
• Systemgenererad trafik: Anslutningar som brandväggen själv upprättar kräver ingen vanlig brandväggsregel. Tjänstekonfigurationen, routning, WAN Link Manager och vid behov SD-WAN för System Traffic är avgörande.
• Adress- och portöversättning: NAT översätter trafik men tillåter den inte. Brandväggsregeln och NAT-regeln måste fungera tillsammans.
• Routning och returväg: En matchande brandväggsregel bevisar inte att routning, SD-WAN, VPN eller returvägen är korrekt.
• Webblogik: Webbkategorier, URL-grupper och åtgärder finns i Web Policy. Brandväggsregeln kopplar denna policy.
• HTTPS-dekryptering: En SSL/TLS inspection rule dekrypterar trafiken. Scan HTTP and decrypted HTTPS skannar endast HTTPS som redan har dekrypterats.
• Användaridentitet: AD SSO, STAS, Captive Portal, Entra ID SSO eller RADIUS måste först tillförlitligt koppla användaren till trafiken. Enheter utan inloggning kan vid en fast och entydig IP-adress konfigureras som Clientless Users; kopplingen är ingen autentisering.

Administrativ åtkomst genom brandväggen till servrar, switchar eller hypervisorer hör hemma i vanliga brandväggsregler. Åtkomst till själva brandväggen hör däremot till Device Access.

Ordning, IPv4 och IPv6

Sophos Firewall kontrollerar regler uppifrån och ned. Så snart alla matchningskriterier för en regel stämmer utvärderas inga efterföljande regler. En allmän regel LAN_to_WAN_Any ovanför LAN_to_WAN_Restricted gör därför den specifika regeln verkningslös.

En regel kan bland annat matcha Source zone, Source network, schema, Destination zone, Destination network, Service, användare och Exclusions. Alla konfigurerade kriterier måste stämma med anslutningen.

Automatiskt skapade MTA-, IPsec- eller Hotspot-regler kan visas högst upp i listan. Server Access Assistant skapar också en brandväggsregel tillsammans med DNAT, reflexiv SNAT och Loopback. Kontrollera därför ordningen igen efter guider, migreringar eller VPN-ändringar. För Sophos Firewall-hotspoten är denna kontroll uttryckligen en del av konfigurationsprocessen. Server Access Assistant förklaras i guiden om DNAT för publicerade servrar.

⚠️ Innan Drop-regeln med loggning skapas: Utgå inte från att den bevarar befintlig HTTP/HTTPS-blockering: dokumentationen om Drop, autentisering, Web Exceptions och blockeringssidor är motsägande. För all webbtrafik krävs före utrullning i produktion ett skriftligt klargörande från Sophos för exakt SFOS-version, build och bearbetningsväg, eller en uttryckligen godkänd, isolerad verifiering. Följ anvisningarna för verifiering, återställning och eskalering under Action och loggning längre ned.

Om SFOS inte hittar någon matchande regel tillämpas längst ned den implicita Drop-all-regeln med Firewall Rule ID #0. Den visar ingen Usage Count och skapar ingen vanlig trafiklogg för brandväggen. För att göra dessa droppar synliga i Log Viewer, Central Reporting eller syslog skapar man längst ned i regelbasen en snävt avgränsad Drop-regel med Log firewall traffic aktiverat. Välj då de Source- och Destination-zoner som faktiskt behövs var för sig i stället för zonen Any. Annars kan regeln även registrera intern trafik till lokala tjänster. Detaljerna finns i Analysera droppade paket på Sophos Firewall.

IPv4- och IPv6-regler hanteras separat. En fungerande IPv4-regel skyddar inte automatiskt samma tjänst via IPv6. I dual-stack-miljöer måste båda regelverken planeras och testas medvetet.

Separera regelgrunderna tydligt

Innan regeln skapas bör Source, Destination, Services, Owner och testfall vara fastställda. Olika risker hör inte hemma i en samlingsregel:

• Klientinternet: Klientnätverk till WAN-zonen med lämplig Web Policy, Application Control, IPS och loggning.
• Serverinternet: Endast nödvändiga mål för uppdateringar, säkerhetskopiering eller molntjänster, oftast utan användarkoppling.
• Gäst-wifi: Guest-zon till internet, utan interna mål och vid behov med bandbreddsbegränsning.
• Management: Definierade administratörsnätverk till servrar och infrastruktur, separerade från vanlig klienttrafik.
• Remote Access VPN: VPN-zon till de interna mål och Services som faktiskt behövs.
• Site-to-Site: Lokala och fjärranslutna nätverk med korrekt routning, NAT och returväg.
• Publicerade system: WAN till DMZ eller serverzon med begränsad Source, DNAT eller WAF, IPS, loggning och aktuell patchnivå.
• Tillfällig åtkomst: En egen regel med ärende, Owner, slutdatum och planerad borttagning.

För nätverksstrukturen finns hjälp i Konfigurera Sophos Firewall-zoner och -gränssnitt.

⚠️ Any kan vara användbart för ett kort test, men är sällan en bra slutkonfiguration. Begränsa därefter regeln till de källor, mål och Services som verkligen behövs eller ta bort regeln igen.

Praktiskt exempel LAN_to_WAN_Clients

I exemplet får klienter i ett definierat LAN åtkomst till internet. Servrar, gäster, VoIP och management får egna regler.

• Rule name: LAN_to_WAN_Clients
• Description: Internetåtkomst för klientnätverk. Webfilter, App Control och IPS aktiverat. Owner IT, granskning 2026-12-01.
• Rule position: Bottom, placera därefter regeln under specifika blockerings- och specialregler
• Rule group: Internet Access
• Action: Accept
• Log firewall traffic: aktiverat
• Source zones: LAN
• Source networks and devices: net_LAN_Clients
• During scheduled time: All the time
• Destination zones: WAN
• Destination networks: Any
• Services: HTTP, HTTPS samt endast de bastjänster som faktiskt används direkt externt
• Web policy: Default Workplace Policy
• Block QUIC protocol: aktiverat
• IPS: lämplig klientpolicy
• App control: lämplig Application Policy för klienter
• Shape traffic: endast för ett konkret bandbreddsmål
• DSCP marking: endast om efterföljande enheter bearbetar markeringen

DNS och NTP hör endast hemma i denna LAN-to-WAN-regel om klienterna ansluter direkt till externa resolvrar eller tidsservrar. Om de använder brandväggen som DNS- eller tidstjänst är det lokal trafik.

Acceptanstestet ska omfatta en definierad klient, ett konkret mål, förväntat Firewall Rule ID, förväntat NAT Rule ID och en kontroll i Log Viewer. På så sätt kontrolleras inte bara att applikationen fungerar, utan även att den bearbetas av de avsedda reglerna.

Konfigurera brandväggsregeln

Övre avsnitt

Rule status, Rule name och Description

Rule status är aktiverat som standard för en ny regel. Förberedda regler kan förbli inaktiverade fram till underhållsfönstret. Permanent inaktiverade test- eller migreringsregler bör granskas regelbundet.

Namnet bör tydligt visa Source, Destination och syfte, till exempel:

• LAN_to_WAN_Clients
• Guest_to_WAN_WebOnly
• Server_to_WAN_Updates
• VoIP_to_WAN_SIP_RTP
• WAN_to_DMZ_HTTPS_Webserver

Description dokumenterar syfte, Owner, ärende, begränsningar och eventuellt slutdatum. Rule1, Allow eller Internet är till liten hjälp i den senare driften. Den separata processen beskrivs i Dokumentera Sophos Firewall-regler på ett meningsfullt sätt.

Rule position och Rule group

När en regel skapas erbjuder Rule position i SFOS 22 alternativen Top och Bottom. Därefter kan regeln flyttas i regeltabellen eller placeras specifikt med Move To. Välj endast Top när en specifik regel avsiktligt måste tillämpas före befintliga regler.

Rule group förbättrar överblicken men ändrar inte matchningslogiken. None är standardvärdet. Med Automatic tilldelar SFOS regeln till en befintlig grupp utifrån den första matchande regeltypen och Source-/Destination-zonerna. Brandväggen fortsätter att utvärdera de enskilda reglerna uppifrån och ned. En grupp kan inte lämnas tom. SFOS 22-hjälpen beskriver att först koppla loss regeln med Detach för att flytta den utanför gruppen; alternativt flyttar man hela gruppen. När den sista regeln tas bort försvinner även gruppen.

SFOS 23-hjälpen beskriver ett annat arbetssätt: klicka i sökfältet för en filtrerad sökning, välj ett föreslaget kriterium och slutför sökningen med hjälp av de ytterligare förslagen. Tryck på Enter för att filtrera regeltabellen. För att söka på regelnamn anger man namnet direkt i sökfältet och trycker på Enter; ta bort enskilda filter med x. Via Show/Hide columns väljer man vilka kolumner som ska visas, ändrar deras ordning genom att klicka och dra och låser upp till tre kolumner så att de alltid visas först. Aktivera eller inaktivera via Status eller gemensamt med Turn on / Turn off; en blandad markering av aktiva och inaktiverade regler förhindrar den gemensamma åtgärden. Inaktiverade regler visas nedtonade med överstruket namn. Dra en regel minst en position utanför gruppen för att ta bort medlemskapet; mellan två regler i en annan grupp läggs den till i den gruppen. View menu erbjuder Clone rule above/below, Add rule above/below, Move To och Edit group. Håll pekaren över Features för detaljer: skilj User/Network-typ och regelåtgärd från policyåtgärder och Heartbeat-trösklar. I SFOS 23-tabellen betyder User att Match known users är valt och Network att det inte är valt; policyikoner skiljer None, Accept, Drop och Reject, Heartbeat-ikoner Green, Yellow och No restriction. Presentationen bevisar ingen ändring av trafikmotorn.

För nya installationer listar SFOS 22/23-hjälpen en LAN-to-WAN-regel och den MTA-regel med Linked NAT som skapas automatiskt när MTA aktiveras; MTA är där aktivt som standard. Kontrollera ändå den egna installationen. Den implicita regeln #0 kan inte redigeras, tas bort eller flyttas och omfattas inte av filter. Återställ Sophos Firewall förklarar det annorlunda läget efter Factory Reset i SFOS 22.

Action och loggning

Action anger hur matchande trafik ska hanteras:

• Accept: tillåter anslutningen.
• Drop: är dokumenterat som att kassera icke-webbtrafik utan meddelande. Beteendet för HTTP/HTTPS är inte generellt garanterat på grund av dokumentationskonflikten nedan.
• Reject: avvisar anslutningen och skickar ett TCP-reset eller ett lämpligt ICMP-svar för UDP och ICMP.
• Protect with web server protection: skapar en WAF-regel. Alternativet är endast tillgängligt för IPv4 och kräver Webserver Protection. Konfigurationen hör ämnesmässigt hemma under Sophos Firewall WAF.

⚠️ Olöst dokumentationskonflikt för webbtrafik: Hjälpen för regelformuläret i SFOS 22/23 beskriver att Drop accepterar och granskar HTTP/HTTPS, autentiserar okända användare när Use web authentication for unknown users är aktiverat, tillåter förfrågningar som tillåts av ett matchande Web Exception och visar en HTML-blockeringssida för övriga förfrågningar. Guiden för loggning av kasserad trafik beskriver däremot tyst kassering generellt och kopplar webbblockeringssidan till detta autentiseringsalternativ. Dessa motsägande beskrivningar har inte lösts här som verifierat beteende för en viss SFOS-build. De bevisar inte att alla webbanslutningar kasseras tyst, att blockeringssidan enbart beror på autentiseringsalternativet eller att alla tjänster blockeras generellt.

Om garanterad blockering eller ett visst svar krävs, begär skriftligt klargörande från Sophos för exakt SFOS-version, build och bearbetningsväg, eller verifiera i en uttryckligen godkänd, isolerad testmiljö. Testa icke-webbtrafik, HTTP och HTTPS separat; för webbtrafik även kända/okända användare, autentisering på/av och matchande Web Exception finns/saknas. Använd endast definierade testklienter, mål och tjänster, aktivera Log firewall traffic och skapa nya anslutningar. Dokumentera build, regelposition, Firewall Rule ID, användare, Action, webb-/TLS-inställningar samt resultat från loggar, Packet Capture och webbläsare. En timeout, blockeringssida eller Policy Tester ensam bevisar inte avsedd blockering. Vid oväntad åtkomst eller oklart resultat: rulla inte ut i produktion, återställ teständringarna och eskalera underlaget till Sophos Support. Reject ger protokollsvaret som beskrivs ovan; det rekommenderas inte här som en overifierad ersättning för webbkontroll.

Log firewall traffic bör vara aktiverat för viktiga regler. Loggar lagras som standard lokalt på brandväggen; kontrollera lokala logginställningar och Syslog-mål under System services > Log settings. Överföring till molntjänsten kräver dessutom att Sophos Central services aktiveras på sidan Sophos Central. SFOS 22-hjälpen kallar målet Sophos Fusion (tidigare Sophos Central), SFOS 23-hjälpen Sophos Central; namnet ersätter inte detta separata krav. Utan en Destroy-händelse kan en session sakna avslutande sessionslogg, exempelvis vid ett plötsligt anslutningsavbrott.

För längre lagring lämpar sig Central Firewall Reporting eller en Syslog-/SIEM-server. Loggning används inte bara för troubleshooting utan även för granskning: vilka källor träffar regeln, vilka mål används och är åtkomsten fortfarande lämplig?

Samma kryssruta är datakällan för NetFlow v5 på Sophos Firewall: utan Log firewall traffic exporterar NetFlow inte anslutningarna för denna regel.

Source, Destination och Services

I avsnittet Source anges varifrån trafiken kommer:

• Source zones: till exempel LAN, VPN, DMZ, Guest eller WAN.
• Source networks and devices: enskilda värdar, nätverk, IP-intervall, grupper, FQDN Hosts eller landsobjekt.
• During scheduled time: All the time, arbetstider eller ett underhållsfönster.

Zonen i sig är oftast för bred. I klientexemplet kombineras därför LAN med net_LAN_Clients. För tidsstyrda regler måste brandväggens tid, tidszonen och Schedule stämma överens.

Konfigurera scheman för regler och policyer i Sophos Firewall visar hur återkommande och enstaka tidsfönster skapas, tilldelas och testas vid sina växlingsgränser.

Under Destination and services finns:

• Destination zones: till exempel WAN, DMZ, LAN eller VPN.
• Destination networks: Any, en värd, ett nätverk, en grupp, ett landsobjekt eller en FQDN Host.
• Services: protokoll- och portdefinitioner som HTTP, HTTPS, DNS, NTP eller en egen Service.

I Använda värdar och tjänster i Sophos Firewall på rätt sätt förklaras hur IP hosts, nätverk, intervall, listor, Services och grupper skapas och kontrolleras före ändringar.

Any kan vara motiverat i en allmän klientinternetregel. Server-, management- och VPN-regler bör använda betydligt snävare mål och Services. För dynamiska molnmål kan FQDN Hosts och Wildcard FQDNs vara till hjälp.

Användare, Exclusions och Linked NAT

Match known users

Med Match known users blir användare eller grupper matchningskriterier. Beroende på konfigurationen blir därefter fler fält tillgängliga:

• Use web authentication for unknown users: omdirigerar okända webbanvändare till AD SSO eller Captive Portal. Autentisering och åtkomst från den berörda zonen måste konfigureras i förväg. Konfigurera och testa Sophos Firewall Captive Portal visar hur autentisering, Device Access, DNS-kravet och användarregeln samverkar.
• Users or groups: begränsar regeln till valda identiteter.
• Exclude this user activity from data accounting: undantar dessa användares trafik från den individuella registreringen av dataförbrukning.

En användarregel fungerar endast med tillförlitlig användartilldelning. En bred fallbackregel längre ned får inte tillåta samma trafik utan användarkoppling. Vid acceptanstestet måste användare, grupp och Rule ID i Log Viewer stämma överens.

Add exclusion

Add exclusion undantar trafik från den här regeln. SFOS hoppar endast över regeln om alla konfigurerade Exclusion-kriterier matchar samtidigt och kontrollerar därefter nästa regel.

Tillgängliga kriterier är Source zones, Source networks and devices, Destination zones, Destination networks och Services.

Ett lämpligt undantag kan vara en uppdateringsserver som exkluderas från en allmän klientregel och får en egen regel med andra skyddsfunktioner ovanför. Om Exclusions blir många eller svåra att förstå är en separat specifik regel oftast bättre.

Create linked NAT rule

Att koppla loss en Linked NAT Rule i NAT-tabellen gör den redigerbar och låter den utvärderas enligt egna kriterier, oberoende av den ursprungliga brandväggsregeln. Dokumentera omfattning och NAT-ordning före ändringen och kontrollera sedan ett nytt testflöde; detta är inte bara ett namnbyte.

En Linked NAT Rule är en Source NAT-regel som endast gäller för trafiken i den länkade brandväggsregeln. I NAT-regeln kan i huvudsak översatt Source och gränssnittsspecifik Source Translation anges.

I många installationer finns redan en Default SNAT rule med MASQ. Det beror dock på konfigurations- och migreringsläget och måste kontrolleras i den aktuella NAT-regeltabellen. Innan en extra Linked NAT Rule läggs till bör man kontrollera om en befintlig regel redan hanterar trafiken korrekt. Om en oberoende NAT-regel högre upp matchar har den företräde framför Linked NAT Rule.

Vid DNAT fastställer SFOS först det översatta målet och använder sedan dess zon för matchningen av brandväggsregeln. Portvidarebefordran till en server i DMZ kräver därför normalt Destination zone DMZ i brandväggsregeln, även om klienten ansluter till den publika WAN-adressen.

Vid ett oväntat NAT Rule ID bör man därför även kontrollera ordningen under Rules and policies > NAT rules. Efter NAT-ändringar måste en ny anslutning skapas eftersom befintliga sessioner inte utvärderas på nytt. NAT tillåter inte trafik i sig: brandväggsregeln avgör Allow eller Drop, medan NAT översätter adresser eller portar. Detaljerna beskrivs i Förstå NAT på Sophos Firewall.

Välj skyddsfunktioner

Alla alternativ är inte tillgängliga med Base License. Kontrollera följande under Administration > Licensing före utrullningen:

• Vanliga brandväggsregler: Base License
• IPS och Security Heartbeat: Network Protection
• Web Security, Application Control och skydd mot webbskadlig kod: Web Protection
• Sandboxing och filanalys: Zero-Day Protection
• E-postskydd: Email Protection
• WAF: Webserver Protection
• NDR Active threat intelligence: Xstream Protection Bundle

Standard Protection och Xstream Protection innehåller Web Protection. Avanets paket Epic Protection innehåller också Web Protection. Den fullständiga översikten finns i Jämför Sophos Firewall-licenspaket.

Web Filtering

Web policy kopplar en Web Policy med kategorier, URL-grupper, användare och åtgärder. Utan Web Policy ger detta fält ingen kategoribaserad webbkontroll. Själva policyn skapas och testas under Web Protection.

Apply web category-based traffic shaping använder bandbreddsinställningarna i webbkategorierna. Alternativet är endast relevant om gränser eller garantier faktiskt har konfigurerats där.

Block QUIC protocol blockerar utgående UDP på port 80 och 443 för regeln. QUIC kan inte skannas som normal HTTP-/HTTPS-trafik och kringgår Web Filtering. SFOS aktiverar alternativet som standard när en Web Policy eller skanning efter skadlig kod väljs. Mer information finns i Blockera QUIC och HTTP/3.

Scan HTTP and decrypted HTTPS kontrollerar HTTP och redan dekrypterad HTTPS efter skadlig kod. Alternativet aktiverar inte dekryptering. För det krävs en lämplig SSL/TLS inspection rule under Rules and policies > SSL/TLS inspection rules.

Use Zero-day protection skickar misstänkta nedladdningar till ytterligare analys efter skanningen efter skadlig kod. Funktionen kräver Zero-Day Protection och kan orsaka en fördröjning beroende på filtyp och policy.

Scan FTP for malware behövs bara om regeln tillåter FTP. För äldre system bör skanningen testas separat.

Use web proxy instead of DPI engine begränsar proxyfiltreringen till standardportarna 80 och 443. Web Proxy krävs bland annat för SafeSearch, YouTube Restrictions, Google Workspace Domain Restrictions, Pharming Protection, Web Cache och Parent Proxy. I DPI-läge gäller SSL/TLS inspection rules för HTTP och TLS på alla portar.

Konfigurera en upstream proxy på Sophos Firewall beskriver den extra regel- och NAT-kedjan för en parent proxy. En proxy i WAN behöver en annan väg än en proxy i LAN eller DMZ.

En uttryckligen konfigurerad Direct Web Proxy-klient använder däremot listenern även utan detta alternativ. Konfigurera Direct Web Proxy med en PAC-fil förklarar hela konfigurationen med port, Device Access, PAC-fil, regel och tester.

Decrypt HTTPS during web proxy filtering hör till Web Proxy-läget. I DPI-läge styrs Decryption via SSL/TLS inspection rules. Web Exceptions kan hoppa över Decryption, Malware Scan, Zero-Day Protection och Policy Checks och bör därför begränsas noggrant och granskas regelbundet.

Synchronized Security Heartbeat

Heartbeat-regler kräver:

• en brandvägg som är registrerad på samma Sophos Fusion-konto och har Security Heartbeat aktiverat;
• en hanterad Sophos Endpoint med provlicens eller fullständig licens;
• Network Protection på brandväggen.

För att identifiera saknade heartbeats måste de berörda zonerna väljas under System > Sophos Fusion > Optional configurations > Missing heartbeat zones.

Med Minimum source HB permitted och Minimum destination HB permitted krävs en lägsta hälsostatus. Destination Heartbeat lämpar sig endast för interna mål, inte för WAN-zonen.

För båda trösklarna gäller: Green tillåter bara Green; Yellow tillåter Green eller Yellow; No restriction tillåter även Red och enheter utan Heartbeat. Kontrollera också de separata blockeringsalternativen för saknade Heartbeats. Guiden för saknade Heartbeats skiljer förlorade från aldrig skickade Heartbeats; Synchronized User ID beskriver utloggning efter förlust eller viloläge/väckning och kontroll av en ny inloggning.

Alternativen Block clients with no heartbeat och Block request to destination with no heartbeat hanterar enheter utan heartbeat. En enhet som aldrig har skickat en heartbeat förblir tillåten som standard och blockeras först när båda alternativen är aktiverade. Detta måste testas medvetet med enheter utan Sophos Endpoint.

En Web Exception som hoppar över Policy checks kan tillåta webbförfrågningar trots Block clients with no heartbeat. Den praktiska kontrollprocessen finns i Analysera varningar om saknad Security Heartbeat.

Application Control, IPS och Traffic Shaping

Identify and control applications (App control) kopplar en Application Filter Policy. Application Control kräver Web Protection. För URL-baserade Micro Apps i krypterad trafik, till exempel filuppladdningar och -nedladdningar i Dropbox eller Gmail, krävs en lämplig dekrypterande SSL/TLS inspection rule. Filter, loggar och False Positives förklaras i Konfigurera Application Control.

Malware- och innehållsskanning använder Web > General settings. För att välja webbproxyfiltrering krävs först en Web Policy eller Scan HTTP and decrypted HTTPS. En Application Filter Policy för URL-baserade Micro Apps gäller fortfarande i den dekrypterande DPI-sökvägen med Web policy None, avstängd malware scanning och ATP. Detta tar inte bort de egna aktiveringsvillkoren för Web Exceptions i DPI. Detaljguiderna beskriver proxy på en bridge utan IP och HTTPS-dekryptering med Direct Web Proxy.

Apply application-based traffic shaping policy använder den bandbreddspolicy som har tilldelats en applikation eller kategori under Applications > Traffic shaping default. Application Objects är däremot avsedda för SD-WAN-rutter. En Rules Policy som valts via Shape traffic formar all trafik för brandväggsregeln. Den aktuella hjälpen för regelformuläret beskriver inte prioriteten mellan en Application Policy och en Rules Policy. För en reproducerbar design bör endast en variant användas per tillämpningsfall, och en nödvändig kombination bör testas på den SFOS-version som används. När Match known users är aktiverat gäller däremot användarens Traffic Shaping Policy. Om användaren saknar en egen policy gäller gruppens policy.

Detect and prevent exploits (IPS) kopplar en IPS Policy. IPS kräver Network Protection eller en giltig provlicens och måste vara globalt aktiverat under Intrusion prevention > IPS policies. Klient-, server-, webbserver- och VoIP-trafik kräver olika, testade policies. Säker utrullning beskrivs i Konfigurera och testa IPS.

Shape traffic tilldelar hela regeln en Traffic Shaping Policy, till exempel för VoIP, möten, säkerhetskopiering eller gäster. Garantier och gränser måste passa den tillgängliga WAN-bandbredden. Läs mer: Konfigurera Application Traffic Shaping.

DSCP marking märker endast utgående IPv4- och IPv6-paket som matchar den här regeln. En DSCP-markering som redan finns på inkommande trafik skrivs då över. Svarspaket och systemgenererad trafik märks inte av brandväggsregeln. Markeringen i sig ger varken prioritering eller klassificering; alla berörda switchar, routrar och WAN-enheter måste behandla de valda DSCP-värdena konsekvent.

Ett avgränsat QoS-test använder en definierad klient, ett godkänt testmål och ICMP med AF31 = 26. Bekräfta regelmatchningen och kontrollera markeringen med Packet Capture vid WAN-egress samt svaret separat. CS0 = 0 är svaret i det dokumenterade exemplet, inte en garanti för godtyckliga markeringar hos motparten. Skapa ingen bred Any-tillåtelse; ta bort testregeln efteråt. Testa en Sophos Firewall-regel förklarar paketfångsten.

NDR Active threat intelligence

Scan with NDR Active threat intelligence kontrollerar trafiken med utvalda NDR-signaturer. Åtgärden är fast inställd på Log threats: funktionen identifierar och loggar händelser men blockerar inte trafiken.

Krav:

• Xstream Protection Bundle;
• global aktivering av NDR Active threat intelligence;
• aktiverad IPS-loggning;
• alternativet valt i varje relevant brandväggsregel.

XGS Appliances samt virtuella, programvarubaserade och vanliga molndistributioner stöds, men inte XGS 87, 87w, 88 och 88w. XDR eller MDR och överföring till Sophos Fusion är valfritt för vidare analys.

Scan email content

Under Scan email content kan IMAP, IMAPS, POP3, POP3S, SMTP och SMTPS väljas. Skyddet kräver Email Protection. Om standardportarna saknas under Services kan de läggas till via Add ports.

E-posttrafik bör inte döljas i en allmän klientinternetregel. En separat e-postregel gör Source, Destination, protokoll, loggning och skyddsfunktioner tydligare.

För en befintlig SMTP-server som publiceras via DNAT kopplar Konfigurera Mail Protection i Legacy mode samman inkommande och utgående regler med NAT, skanningspolicy, TLS och Legacy-proxyloggar.

För e-posthämtning räcker inte enbart kryssrutan: CA-förtroende, globala skanningsgränser, en valfri POP-IMAP-policy och den faktiska regelmatchningen måste fungera tillsammans. Skanna och testa POP3 och IMAP på Sophos Firewall innehåller hela pilot- och valideringsförloppet.

Testa och underhåll regeln

Acceptanstest efter att regeln sparats

Efter konfigurationen sparas regeln med Save. Den är inte klar förrän det definierade testfallet ger de förväntade resultaten:

Gör endast en ändring per test så att orsak och verkan kan kopplas samman.

1. Kontrollera regelpositionen och Rule group.
2. Kontrollera Log firewall traffic och målen under System services > Log settings.
3. Skapa exakt en testanslutning med en definierad klient, ett mål och en Service.
4. Kontrollera Firewall Rule ID, Rule name, användare och Action i Log Viewer.
5. Kontrollera NAT Rule ID och översatta adresser.
6. Verifiera DNS och routning separat.
7. Kontrollera Web Policy, Application Control, IPS och TLS Inspection mot förväntad Action.
8. Var uppmärksam på oväntade Drops, SSL/TLS-fel eller prestandaproblem.
9. Ta bort testregeln eller begränsa den till produktionsobjekten.

Policy Tester simulerar regelvalet men skapar inget verkligt paketflöde och bekräftar varken routning eller returväg. Därför finns hela processen för Policy Test, Log Viewer och Packet Capture i Testa en Sophos Firewall-regel.

Ny regel, befintlig regel eller inaktivering

En befintlig regel kan utökas om Source, Destination, syfte, Owner och skyddsbehov är oförändrade. En egen regel är bättre om loggning, slutdatum, Security Features, ansvariga eller granskningscykel skiljer sig åt.

Tillfällig supportåtkomst, servrar, gäster, VoIP, IoT och management bör inte försvinna i en allmän klientregel. För otydliga äldre regler är kontrollerad inaktivering oftast säkrare än omedelbar borttagning:

1. Klargör syfte, Owner och beroenden.
2. Fastställ loggning och testfönster.
3. Informera berörda team.
4. Inaktivera regeln och utför definierade tester.
5. Ta bort regeln först efter en spårbar observationsperiod.

En sällan använd nödregel kan vara viktig. Omvänt är en ofta använd bred regel inte automatiskt säker.

Återställa en regeländring

Före en ändring bör man anteckna den aktuella positionen och alla berörda fält eller exportera ett spårbart konfigurationsläge. En befintlig regel bör inte byggas om för ett annat syfte. En ny regel som till en början är inaktiverad ger en tydligare återställningsväg och lämnar den befintliga åtkomsten oförändrad.

Om acceptanstestet misslyckas inaktiverar man den nya regeln eller återställer, för en redigerad regel, de tidigare värdena och dess föregående position. Skapa därefter både det tillåtna testflödet och ett avsiktligt otillåtet testflöde på nytt och kontrollera förväntat Firewall Rule ID i Log Viewer. Vid en ändring av managementvägen måste oberoende administrativ åtkomst finnas kvar under hela processen.

Dataräknare, granskning och ändringsspårning

Reset data transfer count återställer mängden överförda data för en regel. Det är inte en sessions- eller träffräknare. I SFOS 22-hjälpen dokumenterar Sophos Unused på olika sätt på två ställen: hjälpen för regeltabellen anger 24 timmar utan matchande trafik, medan Control Center-widgeten Active firewall rules anger 12 timmar och en daglig kontroll. Statusen är därför inte ett tillförlitligt kriterium för att ta bort en regel. New och Changed visas i 24 timmar från att regeln skapades eller ändrades, och en regel kan ha flera statusar samtidigt. I SFOS 23-hjälpen anger både regeltabell och widget 12 timmar för Unused. Det är en dokumentationsjämförelse, inte en tidsmätning testad på en appliance-build.

Active firewall rules visar antalet aktiva regler och matchande trafik i byte under de senaste 24 timmarna. Widgeten skiljer WAF (Webserver Protection), User (med användare eller grupper) och Network (utan dessa kriterier). Scanned är det totala antalet regler i diagrammet, inte antalet regler med malware-skanning. Disabled betyder konfigurerad men avstängd; regeln kan samtidigt vara Changed. Håll pekaren över diagrammet för volymen; klicka på antal eller status för att öppna motsvarande filtrerade regeltabell.

Control Center-widgeten är synlig för alla administratörer oavsett deras rättigheter. Att den syns bevisar därför inte skrivrättighet på den egentliga regelsidan. Dessa indikationer måste bedömas tillsammans med loggar, regelbeskrivning och användningsfall. För att utvärdera mängden överförda data kan även Reports > Dashboards > Traffic dashboard > Allowed policies användas. Om en förväntad regel saknas i tabellen bör man först återställa det aktiva filtret. SFOS 22-hjälpen begränsar även gruppåtgärder i en filtrerad vy.

Regelbundna granskningar kontrollerar minst:

• Source, Destination och Services;
• återstående Any-objekt;
• Owner, ärende och slutdatum;
• loggning och faktisk användning;
• NAT, Web Policy, IPS, TLS Inspection och andra skyddsfunktioner;
• inaktiverade, tillfälliga och automatiskt skapade regler.

En säkerhetskopia bör finnas före större ändringar. Audit Trail Logs och Config Studio visar konfigurationsändringar. För grupper som hanteras via Sophos Fusion bekräftar Firewall Management Task Queue om ändringen har nått rätt appliance. Firewall Health Check kompletterar den regelbundna säkerhetsgranskningen.

Typiska fel

• Den förväntade regeln tillämpas inte eller Rule ID #0 visas: Kontrollera ordningen, IPv4/IPv6 och alla kriterier för Source, Destination, Service, användare och Exclusions.
• Firewall Rule ID är korrekt, men NAT Rule ID eller paketvägen är fel: Kontrollera NAT-ordningen, routning, SD-WAN och returvägen.
• Regeln tillämpas men skyddet saknas eller applikationen slutar fungera: Kontrollera licens, global aktivering, loggning, Web Policy, QUIC, TLS Inspection, IPS och Traffic Shaping Policy var för sig.

Om Rule ID, NAT ID eller paketvägen är oväntade hjälper Sophos Firewall-regeln tillämpas inte till med en strukturerad orsaksanalys.