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

Innan man väljer Add firewall rule väljer man uttryckligen IPv4 eller IPv6 på regelsidan. Följande exempel innebär inte ett gemensamt tillåtande för båda protokollfamiljerna.

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 positiva matchningskriterier för en regel stämmer och trafiken inte undantas av Exclusions tillämpas regeln och inga efterföljande regler utvärderas. En allmän regel LAN_to_WAN_Any ovanför LAN_to_WAN_Restricted gör därför den specifika regeln verkningslös för trafik som matchar den allmänna regeln och inte undantas från den.

En regels positiva matchningskriterier kan bland annat vara Source zone, Source network, schema, Destination zone, Destination network, Service och användare. Alla konfigurerade positiva kriterier måste stämma med anslutningen. Exclusions är däremot undantagskriterier: om alla konfigurerade kriterier i ett undantag matchar samtidigt hoppar SFOS över regeln och fortsätter att utvärdera efterföljande regler.

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 matcha intern trafik till lokala tjänster. Detaljerna finns i Analysera droppade paket på Sophos Firewall.

För en godkänd loggningsregel väljer man Add firewall rule > New firewall rule i rätt IPv4-/IPv6-regeluppsättning, ett entydigt namn, Rule position Bottom, Action Drop och Log firewall traffic. Välj Source zones och Destination zones var för sig; ställ in Source networks and devices, Destination networks och Services enligt den godkända omfattningen och välj sedan Save. Dokumentera först den befintliga ordningen och loggningskonfigurationen. Nya tillåtna testanslutningar och testanslutningar som avsiktligt inte tillåts måste matcha förväntade Rule IDs utan att påverka lokala tjänster. Vid avvikelser ska den nya regeln inaktiveras och det tidigare tillståndet återställas. Utredningen av webbtrafik under Action och loggning är fortfarande en förutsättning, inte ett test som har slutförts genom dessa steg.

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 en regel kan flyttas inom sin grupp. För att flytta en enskild regel till en position utanför gruppen måste man först koppla loss den med Detach; alternativt flyttar man hela gruppen. När den sista regeln tas bort försvinner även gruppen.

I SFOS-22-tabellen visar eller döljer man filter med Enable filter / Disable filter, väljer fält och värde under Add filter och återställer dem med Reset filter. När tabellen är filtrerad kan enskilda regler väljas, men inte regelgrupper. Regler eller grupper kan aktiveras eller inaktiveras med Enable / Disable; ett blandat urval av aktiva och inaktiva regler förhindrar denna åtgärd. More options erbjuder redigering, kloning, tillägg, borttagning, Detach, Reset data transfer count och gruppåtgärder. För en regel som ännu inte ingår i en grupp väljer man Add to group > New group, anger gruppnamnet och ställer in regeltyp samt käll- och destinationszoner; alternativt väljer man en befintlig grupp. Grupper kan redigeras eller tas bort. Kolumnen # visar positionen; med Rule handle drar man regeln eller gruppen, eller anger målpositionen vid Move To och bekräftar med Enter. Anteckna det tidigare tillståndet före varje flytt och kontrollera därefter att nya testflöden matchar förväntat Rule ID. En klon är inte automatiskt ett säkert tillåtande: kontrollera kriterier, status och position före aktivering.

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.

Symbolerna är konfigurationsindikatorer, inte testresultat: I SFOS 23 kontrollerar man under Features, i SFOS 22 under Feature and service, om webb-/FTP-/e-postskanning och Traffic Logging är aktiverade eller inaktiverade, om proxyfiltrering är vald och om policyer är tilldelade. En aktiverad proxy gäller 80/443; andra HTTP-/TLS-portar hanteras fortfarande av DPI. Web policy, App control, IPS och Shape traffic kan var och en visa None; IPS- och shaping-symbolerna visar en tilldelad policy, medan webb- och app-symbolerna dessutom visar dess åtgärd. För Heartbeat måste man skilja minimistatusen Green eller Yellow från No restriction och kontrollera det separata tillståndet för Block clients with no heartbeat. No restriction i sig bevisar inte att denna extra inställning är inaktiverad. Även aktiverade Exclusions måste beaktas vid matchningskontrollen.

För nya installationer anger SFOS-22/23-hjälpen en LAN-to-WAN-regel samt den MTA-regel med Linked NAT som skapas automatiskt när MTA-läget är aktiverat; MTA är där aktiverat som standard. Detta ersätter inte kontroll av den egna installationen. Den implicita regeln #0 kan inte redigeras, tas bort eller flyttas och undantas alltid från filter. Detta ska skiljas från en Factory Reset: båda hjälpversionerna beskriver att alla brandväggsregler tas bort och att därefter endast regeln Auto added firewall policy for MTA finns. Man får inte dra slutsatsen att ett LAN-to-WAN-tillåtande återställs automatiskt. En återställning är inte en metod för att rensa bort enskilda regler; säkerhetskopiering, oberoende administratörsåtkomst och en återställningsplan ingår i den separata proceduren Återställa Sophos Firewall.

Startöversikten Access rules and policies för SFOS 22/23 beskriver även regelgrupper som skapas som standard med en brandväggsregel för att kassera trafik mot WAN, DMZ och interna zoner (LAN, Wi-Fi, VPN och DMZ). Här avses synliga, grupperade brandväggsregler, inte den implicita regeln #0. Denna översikt och de ovan nämnda detaljerade standardinställningarna för installation och återställning styrker dock inte att alla installationer har samma ursprungliga regeluppsättning. Kontrollera därför, på din specifika SFOS-version, din build och din installation, under Rules and policies > Firewall rules, vilka regler och grupper som faktiskt finns och är aktiverade, vilka käll-/destinationszoner och andra matchningskriterier de använder och på vilken position de ligger. Att en grupp finns bevisar inte i sig isolering: en tidigare matchande tillåtelseregel kan redan tillåta trafiken. Kontrollera den önskade zonsepareringen med nya, uttryckligen godkända testanslutningar och de förväntade Rule IDs; för webbtrafik gäller fortfarande den ovan beskrivna dokumentationskonflikten om Drop. Dra inga slutsatser om garanterade gruppnamn, villkor för skapande eller en generell blockerande effekt utifrån startöversikten.

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 en TCP-reset för TCP; för UDP och ICMP anger hjälpen uttryckligen att ett ICMP Port Unreachable-meddelande skickas till källan.
• 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.

När man väljer Protect with web server protection visas Preconfigured template. None innebär att man själv anger WAF-detaljerna. De dokumenterade mallarna är Exchange Autodiscover, Exchange Outlook Anywhere, Exchange General, Microsoft Lync, Microsoft Remote Desktop Gateway 2008 and R2, Microsoft Remote Desktop Web 2008 and R2 och Microsoft Sharepoint 2010 and 2013. Dessa historiska namn säger inget om dagens stöd eller säkerhet för respektive serverversion. Före användning måste mallen stämma överens med den tjänst som faktiskt körs; den efterföljande WAF-konfigurationen och godkännandet av den krävs fortfarande.

⚠️ 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 ger ingen entydig regel 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.

MAC-baserad regel: klargör begränsningarna före blockeringsförsöket

En MAC-host kan möjliggöra ytterligare enhetsidentifiering för direkt synliga klienter, till exempel när deras DHCP-adress ändras. En MAC-adress är dock inte en stark identitet: den kan ändras eller efterliknas. Källanvisningen beskriver MAC-Filtering som säkrare och visar Block_MAC för IPv4 från LAN till WAN med Drop, loggning, position Top, grupp None, schema All the time, mål och Services Any. Denna kombination innebär här ingen utfästelse om en fullständig internetblockering: den HTTP-/HTTPS-/Web Exceptions-konflikt som dokumenteras ovan är fortfarande olöst.

MAC-baserad internetfiltrering begränsas i anvisningen till enheter som är direkt anslutna till brandväggen. Om en router, en annan brandvägg eller en Layer-3-switch finns däremellan ser man inte automatiskt klientens ursprungliga MAC-adress. Anvisningen anger MAC binding för lokala användare för detta; utan att identitetskopplingen och den faktiska paketvägen har klargjorts är detta ingen garanti för routad MAC-filtrering och ingen ersättning för autentisering. Före ett försök måste den MAC-adress som är synlig vid brandväggens ingång faktiskt tillhöra testklienten.

För ett uttryckligen godkänt, isolerat pilotförsök blockeras endast ett nytt IPv4-TCP-flöde som inte är webbtrafik till en kontrollerad WAN-testserver:

1. Jämför MAC-adressen på testklienten med den vid brandväggens ingång. Ange namnet MAC_Host, Type MAC address och den faktiskt verifierade MAC-adressen under Hosts and services > MAC host > Add, och välj sedan Save. 37:97:0E:AB:56:46 är anvisningens oförändrade exempelvärde och ska inte användas utan kontroll.
2. Välj IPv4 och Add firewall rule > New firewall rule under Rules and policies > Firewall rules. För Block_MAC anger man Action Drop, Log firewall traffic, Rule position Top, Rule group None, Source zones LAN, Source networks and devices MAC_Host, During scheduled time All the time och Destination zones WAN. Begränsa målet till den kontrollerade testservern och Services till den godkända TCP-testtjänsten som inte är en webbtjänst, i stället för att använda de ursprungliga Any-värdena. Dokumentera först ordningen och konfigurationens tillstånd och välj därefter Save.
3. Skapa ett nytt testflöde, till exempel ett godkänt TCP-iPerf3-flöde, och kontrollera Block_MAC samt Rule ID i Log Viewer och att paketflödet kasseras. En annan kontrollklient som inte är blockerad måste fortfarande kunna nå testmålet. Enbart en timeout räcker inte.
4. Efter pilotförsöket ska testregeln inaktiveras eller tas bort, den tidigare ordningen återställas och ett nytt tillåtet testflöde från den ursprungliga klienten verifieras med hjälp av förväntat Rule ID. Ta endast bort testets MAC-host om ingen annan konfiguration behöver den.

Vid utebliven matchning ska MAC-synlighet, IPv4-val, Source, Schedule och ordning kontrolleras; utöka inte regeln till alla enheter. Vid oväntad åtkomst eller om kontrollklienten slutar fungera ska försöket återtas och underlaget utredas med exakt version och build. HTTP, HTTPS, Web Exceptions, andra zoner/mål/tjänster och IPv6 omfattas inte av detta pilotförsök. En fullständig MAC-baserad internetblockering får utlovas först efter separat utredning och kontroll av dessa fall.

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.

Okänd betyder här: inloggad på klienten, men ännu inte autentiserad på brandväggen. AD SSO med Kerberos/NTLM eller Captive Portal konfigureras under Authentication > Web authentication, och åtkomst från de nödvändiga zonerna under Administration > Device access. Som standard räknas matchande trafik in i den individuella dataförbrukningen. Exclude this user activity from data accounting undantar den från beräkningen, till exempel om dessa användare inte ska ha någon datagräns; detta är varken ett ytterligare tillåtande eller en autentisering.

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.

Det dokumenterade landexemplet tillåter HTTPS från afrikanska länder till 172.16.16.0 och använder en Exclusion med endast Source zone WAN och ett valt landsobjekt som Source network. Regeln hoppas över endast om båda kriterierna stämmer; trafiken kan tillåtas av en senare regel eller hamna på #0. Adressen är ett oförändrat exempel, inte en fullständig nätdefinition med prefix. För ett eget test ska man välja ett målobjekt som faktiskt finns, dokumentera regelordningen och kontrollera ett undantaget och ett icke undantaget testflöde med hjälp av Rule IDs. En Exclusion är inte en global blockering.

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.

För utgående klienttrafik kan man skapa ett tillåtande i brandväggen och Source NAT tillsammans:

1. Välj protokollfamilj under Rules and policies > Firewall rules och öppna Add firewall rule > New firewall rule. Ange namn och position; använd i exemplet Source zones LAN, Source networks and devices Network_LAN, Destination zones WAN och Destination networks Any. Network_LAN måste innehålla det egna, verifierade klientnätet. Anvisningen visar Services Any; i produktion väljer man i stället endast godkända tjänster.
2. Välj Create linked NAT rule, ange NAT-namn och position och ställ in Translated source (SNAT) på MASQ. Spara först Linked NAT Rule med Save och därefter brandväggsregeln med Save.
3. Kontrollera brandväggsregeln i brandväggstabellen och den länkade SNAT-regeln i NAT-tabellen med hjälp av Firewall Rule ID och namn. Först utvärderas brandväggsregeln, därefter Source NAT. För Linked NAT kan endast den översatta källan och Source Translation som är specifik för det utgående gränssnittet ändras; övriga kriterier, inklusive användare/grupper, hämtas från brandväggsregeln.

Källangivelsen 10.145.16.10/24 är anvisningens oförändrade exempelvärde, inte ett värde som ska kopieras som nätadress utan kontroll. MASQ använder IP-adressen för det utgående gränssnitt som faktiskt valts. Kontrollera först lämplig rutt, gränssnitt och högre placerade NAT-regler. Ett nytt testflöde måste visa förväntat Firewall Rule ID, NAT Rule ID och den förväntade översatta källan. Vid felaktig översättning ska ordning och utgående gränssnitt kontrolleras; vid misslyckande ska den nya brandväggs- och Linked NAT-konfigurationen återtas och det tidigare tillståndet inklusive ordningen återställas, utan att andra nödvändiga NAT-regler ändras.

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 söker efter skadlig kod i HTTP och redan dekrypterad HTTPS, men aktiverar inte dekryptering. I DPI-läge krävs en lämplig SSL/TLS inspection rule under Rules and policies > SSL/TLS inspection rules; i webbproxyläge används Decrypt HTTPS during web proxy filtering. Kontrollera före utrullningen vilken bearbetningsväg som faktiskt används och att klienterna litar på certifikatutfärdaren för dekryptering.

Use Zero-day protection kräver Scan HTTP and decrypted HTTPS och skickar filer som laddats ned via HTTP/HTTPS för ytterligare analys av okända eller ännu inte offentliggjorda hot. Funktionen kräver Zero-Day Protection och kan orsaka en fördröjning beroende på filtyp och policy; den aktiverar inte HTTPS-dekryptering på egen hand.

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.

Även när Use web proxy instead of DPI engine är aktiverat fortsätter DPI-motorn att filtrera HTTP och SSL/TLS på andra portar; inställningen gäller proxyn för 80/443, inte all trafik. Webbproxyfiltrering på en brygga utan IP-adress beskrivs i hjälpen som ett fall där trafiken kasseras och får inte aktiveras utan kontroll. Decrypt HTTPS during web proxy filtering dekrypterar även i Direct Proxy-läget som uttryckligen konfigurerats på klienten. I DPI-läget tillämpas Web Policies inklusive Web Exceptions endast om en Web Policy har angetts, skanning av skadlig kod/innehåll är aktiv eller ATP är aktivt. Dessa villkor ska skiljas från den URL-baserade Micro-App-identifiering som förklaras under Application Control, IPS och Traffic Shaping.

Behandla endast vissa mål via webbproxyn

Om SafeSearch, YouTube-begränsningar eller Google Workspace-inloggningar ska begränsas till vissa domäner medan annan trafik använder DPI-dekryptering, skapar man en separat, högre placerad regel. Kontrollera först Web Protection-licensen, lämpliga globala webbinställningar, klientens förtroende för dekrypterings-CA:n och önskad Web Policy. FQDN-grupper bestämmer målen; de konfigurerar inte själva de tillåtna kontodomänerna eller filtreringsåtgärderna.

1. Välj IPv4 eller IPv6 under Rules and policies > Firewall rules, öppna Add firewall rule > New firewall rule och ange namn och position. Välj Action Accept, den källzon som faktiskt behövs och det godkända klientnätet. Källanvisningen använder Any där; denna breda källa är inte ett nödvändigt krav i produktion.
2. Ange Destination zones WAN, Destination networks med de fördefinierade grupperna SafeSearch enforcement, YouTube restrictions enforcement och Google app enforcement samt Services HTTP, HTTPS. Välj endast de grupper som behövs för det önskade användningsfallet.
3. Aktivera Scan HTTP and decrypted HTTPS, Block QUIC protocol, Use web proxy instead of DPI engine och Decrypt HTTPS during web proxy filtering. Den faktiska Web Policy måste motsvara den önskade begränsningen. Aktivera Log firewall traffic för pilotförsöket och spara med Save.
4. Placera regeln ovanför DPI-reglerna. Kontrollera önskad SafeSearch-/YouTube-/kontobegränsning, Rule ID och webb-/TLS-loggar med nya anslutningar; testa även ett annat mål som fortfarande ska matcha den avsedda DPI-regeln och SSL/TLS inspection rule.

Om begränsningen uteblir ska regelposition, FQDN-tilldelning, Web Policy och QUIC kontrolleras; vid certifikatfel ska CA-förtroendet och dekrypteringskonfigurationen kontrolleras. Vid oväntat beteende ska den nya proxyregeln inaktiveras eller tidigare värden och position återställas, och därefter ska den ursprungliga DPI-vägen kontrolleras igen. Stäng inte generellt av TLS-skydd eller certifikatkontroll.

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, även när både skanning efter skadlig kod och ATP är avstängda. 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-build 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.

DSCP-valet måste passa QoS-designen för hela sträckan: EF beskriver Expedited Forwarding för låg fördröjning och små förluster vid realtidstjänster; AF beskriver Assured Forwarding med paket som kasseras vid överbelastning; CS används för kompatibilitet med IP-Precedence. Detta är klasskoncept, inte en tjänstekvalitet som garanteras enbart av märkningen. De dokumenterade värdena är:

Det ursprungliga ICMP-exemplet använder 8.8.8.8, Source zone LAN, Destination zone WAN, källa och mål Any samt AF31. För en egen kontroll ersätter man detta med godkända, konkreta klient- och målobjekt; varken denna publika adress eller ett brett tillåtande krävs. Anteckna det tidigare DSCP-värdet före testet, återställ det efter testet och kontrollera med nya paket. Om den förväntade prioriteringen uteblir måste regelmatchning, faktisk märkning vid utgående trafik och QoS-hanteringen i efterföljande enheter undersökas var för sig.

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.

Förbered brandväggsregler via XML API

XML-objekten FirewallRule och FirewallRuleGroup lämpar sig för spårbara regeländringar och gruppunderhåll. De ersätter varken planering av åtkomst eller acceptanstest med nya testanslutningar. Säkrad åtkomst, HTTP POST till APIController, uttryckliga XML-operationer, TLS-kontroll, lagring av hemligheter och utvärdering av XML-status i stället för HTTP-framgång förklaras i Säkra åtkomsten till XML API. Först måste en ofarlig läsfråga fungera från den avsedda automationsvärden med ett konto med snävt begränsade behörigheter.

Bevara regeltyp, överordnad struktur och ordning

I SFOS-22/23-referensen är Name, Position och PolicyType obligatoriska uppgifter för Add/Edit. Name är en UTF-8-sträng med högst 60 tecken och utan kommatecken. Under FirewallRule anger PolicyType med värdet Network att blocket NetworkPolicy ska användas, respektive med värdet User att blocket UserPolicy ska användas. Blanda inte dessa grenar och skicka inte båda utan att först kontrollera dem. HTTPBased och HTTPBasedPolicy hör till WAF-konfigurationen, medan autentiseringskopplingen hör till WAF-autentisering. WAF-sökvägsåtgärder är inte en numerisk översättning av nätverksåtgärder.

IPFamily tillåter IPv4 eller IPv6; tabellen anger IPv4 som standardvärde. Status tillåter Enable eller Disable, men anger ON som standardvärde. För förberedda regler ska statusen medvetet sättas till Disable och den sparade protokollfamiljen kontrolleras, i stället för att dokumentationens standardvärden används som säkra värden i nyttolasten. Enligt parametertabellen tillåter Position värdena Bottom, Top, After eller Before; exemplet skriver dessa värden med gemener. Bekräfta därför skiftläge och fullständig operation i API help för den installerade builden. After/Name och Before/Name anger den befintliga ankarregeln; referensen begränsar dessa taggar till Set-requests. Section skiljer mellan Central_TOP, Local och Central_Bottom: klargör ägarskap och administrationsväg före ett lokalt skrivförsök, och kringgå inte en central begränsning genom att använda ett annat avsnitt.

I det valda policyblocket hålls källa och mål åtskilda: SourceZones/Zone, SourceNetworks/Network, DestinationZones/Zone, DestinationNetworks/Network och Services/Service innehåller referenser som kan upprepas. Schedule hänvisar till ett befintligt schema. Tabellerna begränsar nätverks- och tjänstreferenser till 60 tecken; de dokumenterar inget gemensamt maxantal för samtliga kriterier. Samma överordnade element kan finnas under Exclusions och betyder där undantag från denna regel, inte ytterligare tillåtanden. Läs före skrivning in de zoner, värdar, tjänster och scheman som faktiskt finns och kontrollera den avsedda matchningen, inklusive efterföljande regler.

För UserPolicy kompletterar MatchIdentity, ShowCaptivePortal och Identity/Member användarkopplingen. För Member dokumenteras flera användar-/gruppreferenser med högst 256 tecken. Identitetskopplingen och webbautentiseringen måste fungera separat. DataAccounting beskrivs endast när identitetsmatchning är aktiverad och undantar användartrafik från dataförbrukningsberäkningen; det autentiserar inte. Här motsäger exemplet och tabellen varandra: exemplet visar Include/Exclude, tabellen Enable/Disable. Även WebCategoryBaseQoSPolicy och ApplicationBaseQoSPolicy visar Apply/Revoke i exemplet, medan tabellen beskriver en sträng. Översätt inte sådana värden automatiskt och behandla dem inte som utbytbara. Om det konkreta värdet för objektet och builden fortfarande är oklart ska skrivbegäran stoppas och frågan klargöras med Sophos.

Action i Network-/User-grenen tillåter Accept, Drop eller Reject; tabellen anger Drop som standardvärde. En uttrycklig åtgärd är fortfarande nödvändig, och den ovan förklarade konflikten om HTTP-/HTTPS-hanteringen för Drop gäller även vid API-ändringar. LogTraffic tillåter Enable/Disable, med det dokumenterade standardvärdet Disable; välj medvetet loggning för acceptanstestet. SkipLocalDestined gäller trafik till appliance-enhetens IP-adress och ersätter inte Device Access. Policyreferenser som WebFilter, ApplicationControl, IntrusionPrevention och TrafficShapingPolicy måste motsvara det tidigare planerade skyddet. Skanning, proxy, dekryptering, Zero-Day och Heartbeat är fortfarande olika kontroller med de förutsättningar som förklarats ovan. Framför allt motsäger standardangivelser som OFF, NULL eller NoRestriction delvis de angivna inmatningsvärdena; varken dessa angivelser eller tomma element i exemplen visar hur utelämnande, tömning eller uppdatering fungerar i den aktuella builden.

När befintliga skyddsalternativ överförs måste värdedomänen kontrolleras för varje fält: ProxyMode anger förutom Enable/Disable även true/false; NDRActiveThreatIntelligence anger endast true/false. Trösklarna MinimumSourceHBPermitted och MinimumDestinationHBPermitted tillåter GREEN, YELLOW och No Restriction, medan kolumnen för standardvärden skriver NoRestriction. Detta är andra inmatningsvärden än de separata Heartbeat-reglagen, inte en automatisk översättning av GUI-benämningarna. De användarrelaterade selektorerna WebFilterInternetScheme och ApplicationControlInternetScheme anger Enable/Disable, men standardvärdet är 0; förväxla dem inte med ett policynamn. XML-kommentarerna knyter WebCategoryBaseQoSPolicy till ett valt WebFilter och ApplicationBaseQoSPolicy till ett valt Application Filter. För Traffic Shaping anger tabellen TrafficShappingPolicy/TrafficShapingPolicy, men XML-exemplet använder TrafficShapingPolicy: dra inte slutsatsen att taggarna är utbytbara eller att båda accepteras. DSCPMarking är dokumenterat som en sträng; serialiseringen av GUI-värdet måste stämma med builden. Jämför varje berört skyddsalternativ före och efter ändringen; normalisera inte okända inmatningsvärden och låt inget skyddsalternativ gå förlorat utan att det uppmärksammas.

Gruppmedlemskap är inget säkerhetsbeslut

FirewallRuleGroup samlar befintliga regler via SecurityPolicyList/SecurityPolicy. SourceZones/Zone och DestinationZones/Zone är separata överordnade element för grupptilldelningen, inte nya matchningskriterier för de enskilda reglerna. Gruppens Policytype, med gemener i slutledet, skiljer sig från en regels PolicyType. De dokumenterade gruppselektorerna är User/network rule, Network rule, User rule, WAF rule och Any; härled inte dessa värden från regeltypen och normalisera dem inte till andra skrivsätt.

Gruppnamnet är obligatoriskt, ska vara i UTF-8 utan kommatecken och får innehålla högst 150 tecken; Description är valfritt med högst 255 tecken. För SecurityPolicy anger referensen högst 60 tecken per regelnamn, inga kommatecken och upp till 200 värden. Medlemskapsgränsen är ingen kapacitetsgaranti. För en grupp Internet Access ska man först läsa in befintliga regelnamn, endast välja godkända medlemmar och tilldela källa och mål separat. Tillverkarens exempel med kolon och ett kommaseparerat urval av samtliga typer är inte en körbar nyttolast.

Säkra medlemskap, regelpositioner och status före en gruppuppdatering. Stäm därefter av samma regler igen i WebAdmin och med en godkänd läsfråga. Beskrivningen «Add/Remove» för SecurityPolicy fastställer varken en säker inkrementell liständring eller hur ersättning fungerar. Skriv inte om hanteringen av utelämnade eller tomma listor är oklar. Enligt GUI-hjälpen kan en grupp inte finnas utan medlemmar; om den sista regeln tas bort kan även gruppen tas bort. Gruppering ger överblick, men varken isolering eller företräde: varje regels matchningskriterier och faktiska ordning är fortfarande avgörande.

Skilj svar åt efter operation och läs tillbaka tillståndet

Följande kopplingar överensstämmer mellan SFOS-22/23-referenserna. Beteckningarna Message.* förblir dokumentationssymboler vars innebörd inte har klarlagts, inte garanterade meddelanden vid körning, översättningar eller entydiga orsaker. Samma kod kan beteckna olika saker beroende på operation. Observera särskilt att detta är XML-statuskoder, inte HTTP-statuskoder.

För att skapa och redigera Network-/User-regler är följande skillnader relevanta:

• Add firewall rule — 200 — Message.FWRuleAddSuccess; Edit firewall rule — 200 — Message.FWRuleEditSuccess.
• Edit firewall rule — 202 — Message.FirewallRuleUpdateWithRename: kontrollera det gamla och det nya namnet, referenserna och den sparade regeltypen; utgå inte bara från att allt har lyckats.
• Add firewall rule — 500 — Message.FWRuleAddFail; Edit firewall rule — 500 — Message.FWRuleEditFail.
• Add firewall rule — 502 — Message.FWRuleRecordExists; Edit firewall rule — 502 — Message.FWRuleUpdateRecordExist: jämför den befintliga och den önskade regeln utifrån det inlästa tillståndet; skriv inte över automatiskt.
• Add firewall rule — 541 — Message.VHIPRangeConflict; Edit firewall rule — 541 — Message.FWRuleFailMaxUser. Härled inte en gemensam felorsak eller en numerisk användargräns från detta.
• Add firewall rule — 551 — Message.CannotSelectDestHBIfWANSelected; Edit firewall rule — 551 — Message.CannotSelectDestHBIfWANSelected: kontrollera målzonerna och Destination Heartbeat-konfigurationen tillsammans.
• Edit firewall rule — 552 — Message.CannotImportDiffPolicytypeWithSameName: stäm av befintligt namn och regeltyp; försök inte kringgå problemet genom namn- eller typbyte på chans.
• Add firewall rule — 596 — Message.CMLOCALOperationrestriction; Edit firewall rule — 596 — Message.CMLOCALOperationrestriction: klargör administrationsansvaret och den godkända ändringsvägen.

De WAF-specifika svar som anges gemensamt hör till WAF-anvisningen; överför inte dess port-, omdirigerings- och Protected Server-konflikter till Network-/User-regler.

Även för grupper ska operationen dokumenteras: Add firewall rule group — 200 — Message.FWGroupAddSuccess, 500 — Message.FWGroupAddFail, 502 — Message.FWGroupRecordExists; Edit firewall rule group — 200 — Message.FWGroupAddSuccess, 500 — Message.FWGroupAddFail, 502 — Message.FWGroupRecordExists. Edit-referensen använder faktiskt samma Add-symboler. Läs in det sparade gruppnamnet, medlemskapet och båda zonlistorna före ett nytt försök; dra inte slutsatsen av symbolnamnen att Edit utför en skapandeoperation.

Vid borttagning gäller Delete firewall rule — 200 — Message.FWDelSuccess, 500 — Message.FWRuleDeleteFail, 596 — Message.CMLOCALOperationrestriction. Delete-tabellen markerar Name som valfritt och beskriver det motsägelsefullt som ett ankare för Before/After. Härled inte en generell borttagning utan namn från detta. Kontrollera före Remove det exakta målet, beroenden, grupptillhörighet, Linked NAT, administrationsansvar och den bekräftade nyttolasten i API help. För oklara äldre regler är kontrollerad inaktivering med ett observationsfönster fortfarande det säkrare första steget.

Efter varje svar, och även efter timeout eller anslutningsavbrott, ska det faktiska sparade tillståndet läsas in före ett nytt försök: namn, typ, status, protokollfamilj, position, kriterier, Exclusions, skyddsreferenser och gruppmedlemskap måste motsvara det godkända önskade tillståndet. Vid Remove ska man dessutom kontrollera att exakt målregeln saknas och att nödvändiga regler samt NAT finns kvar oförändrade. Ett okänt resultat kan redan innebära att en ändring har gjorts. Upprepa inte blint, använd inte automatisk Upsert och utöka inte till Any; stoppa vid avvikelser, spara det rensade svaret och Audit Trail och använd den bekräftade återställningsvägen. Först därefter följer de nya tillåtna testflöden och testflöden som avsiktligt inte tillåts som beskrivs nedan.

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.

Tidsfönstren kan överlappa: en regel som skapats kl. 10:00 förblir New till kl. 10:00 följande dag. En ändring kl. 11:00 ger statusen Changed till kl. 11:00 följande dag; mellan kl. 11:00 och nästa kl. 10:00 har regeln båda statusarna. En Unused-status som konstaterats vid den dagliga kontrollen kl. 12:00 kvarstår till nästa kontroll. Om regeln inaktiveras kl. 13:00 kan den ha både Changed och Disabled till kl. 13:00 följande dag, därefter endast Disabled. Dessa dokumentationsexempel ersätter varken kontroll av faktisk användning eller ett beslut om borttagning. Dokumentera det aktuella värdet före Reset data transfer count: återställningen återställer inte ett tidigare räknarvärde och ändrar inte vad regeln tillåter.

Active firewall rules visar regler efter typ och status samt den trafik som matchar dem, i byte, under de senaste 24 timmarna. Panelen skiljer mellan WAF (Webserver Protection), User (med användare eller grupper) och Network (utan dessa kriterier). Scanned avser det totala antalet regler i diagrammet, inte antalet regler där skanning efter skadlig kod utförs. Disabled betyder konfigurerad men avstängd; en inaktiverad regel kan samtidigt vara Changed. Datavolymen kan kontrolleras genom att hålla muspekaren över ett värde; ett klick på antalet eller statusen öppnar regeltabellen med motsvarande filter.

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.