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

Brandväggsregler är hjärtat i Sophos Firewall. Dessa regler bestämmer vilken trafik mellan zoner, nätverk, användare och tjänster som tillåts eller blockeras och vilka skyddsfunktioner som tillämpas.

Den här artikeln förklarar en Sophos Firewall-regel uppifrån och ned: Order, Groups, Action, Loggning, Källa, Destination, Services, User Matching, Exclusions, NAT, Web Filtering, TLS Inspection, Security Heartbeat, Application Control, IPS, Traffic Shaping, DSCP, NDR och Email Scan.

Menysökvägen är:

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

Regelmasken är uppdelad i flera områden: rubrikområde, källa, destination, tjänster, användarreferens, NAT länk och säkerhetsfunktioner. I praktiken är det viktigt att inte se masken som en samling individuella krokar. En regel fungerar bara korrekt om källan, destinationen, tjänsten, sekvensen, loggningen och de aktiverade skyddsfunktionerna matchar.

Innan du skapar den bör det också vara klart om det är en IPv4- eller IPv6-regel. Regelvyn väljs därefter i WebAdmin. I miljöer med dubbla stack måste IPv4 och IPv6 avsiktligt planeras och testas separat; en fungerande IPv4-regel bevisar inte automatiskt att IPv6 är lika säkrat.

Snabb navigering

• Vad brandväggsregler styr och vad de inte styr
• Grundläggande princip och sekvens
• Planera regelbas innan du skapar
• Separera regeltyper rent
• Fiktivt praktiskt exempel
• Rubrikområde: Status, Namn, Åtgärd och Loggning
• Källa, zon och schema
• Destination och tjänster
• Matcha kända användare
• Lägg till uteslutning
• Create linked NAT rule
• Webbfiltrering
• Synchronized Security Hjärtslag
• Andra säkerhetsfunktioner
• Skanna e-postinnehåll
• Kontrollera efter att du har sparat
• Vanlig drift och granskning
• Ny regel, ändra eller inaktivera befintlig regel?
• Typiska fel
• FAQ

Vilken nätverkspolicyartikel passar?

Brandväggsregler, NAT, WAF, VLANs och routing är tätt sammanflätade i Sophos Firewall. Det är därför viktigt för administratörer att först välja rätt ämne:

• Förstå brandväggsregeln från början: Den här artikeln.
• Klassificera NAT, SNAT, DNAT, MASQ eller PAT: Förstå NAT på Sophos Firewall: SNAT, DNAT, MASQ, PAT.
• Internen Server per Portweiterleitung veröffentlichen: Server per DNAT auf Sophos Firewall veröffentlichen.
• Säker offentlig webbapplikation: Konfigurera och organisera Sophos Firewall WAF.
• Regeln gäller inte eller felaktigt regel-ID visas: Sophos Firewall Regeln gäller inte: kontrollera orsaker.
• Använda FQDN hosts och wildcard FQDNs i regler: Använd Sophos Firewall FQDN hosts och wildcard FQDNs korrekt.
• Testregel specifikt: Testa brandväggsregel med Log Viewer, Policy Test och Packet Capture.
• WebAdmin, VPN Portal, User Portal, SSH, DNS eller SNMP skyddar brandväggen: Sophos Firewall Säker åtkomst: konfigurera Device Access korrekt.
• Planera zoner, gränssnitt eller VLANs: Sophos Firewall konfigurera zoner och gränssnitt.
• Bridge mit VLAN Tags betreiben: Sophos Firewall Bridge mit VLAN Tagging einsetzen.
• Kontrollera ruttordning eller SD-WAN-vägar: Sophos Firewall justera ruttprioritet.
• Svarspaket eller systemtrafik går via fel väg: SD-WAN Routing för svarspaket och systemtrafik.

Denna separation förhindrar typisk felsökning. En NAT-regel tillåter inte trafik, en brandväggsregel översätter inte en adress och en WAF-regel är inte detsamma som en vanlig DNAT-portvidarebefordran.

Vilka brandväggsregler styr och vad de inte

Brandväggsregler styr trafik som flödar genom brandväggen. Men dessa regler är inte den enda kontrollpunkten i SFOS. En hel del felsökning sker eftersom du letar efter ett beteende i brandväggsregellistan, även om ett annat område är ansvarigt.

• Trafik mellan zoner, nätverk, användare och tjänster: Brandväggsregler avgör om transittrafik tillåts, avvisas eller kontrolleras med säkerhetsfunktioner.
• WebAdmin, User Portal, VPN Portal, SSH, DNS eller SNMP till själva brandväggen: Device Access och Local Service ACL är ansvariga. Lokala brandväggstjänster behandlas inte som normal LAN-till-WAN eller WAN-till-DMZ-trafik.
• Adress- eller portöversättning: NAT-regler översätter trafik, men tillåter det inte automatiskt.
• Ruttning, returväg, SD-WAN och VPN vägar: Routing, SD-WAN, ruttföreträde och VPN konfiguration avgör vägen. En lämplig brandväggsregel visar sig inte fungera långt tillbaka.
• Webbkategorier, URL-grupper och webbpolicy: Webbfiltrering och webbpolicy styr webblogiken. Brandväggsregeln integrerar bara policyn.
• HTTPS-dekryptering: SSL/TLS inspektionsregler och CA distribution krävs. Scan HTTP and decrypted HTTPS skannar bara trafik som redan är dekrypterad.
• Användaridentitet: Autentisering, STAS, Captive Portal, Entra ID SSO eller RADIUS måste fungera. En användarregel matchar bara om brandväggen kan tilldela användaren trafiken.

För hanterings- och portaltjänster är Device Access och Local Service ACL den centrala artikeln. Om en regel matchar men anslutningen fortfarande misslyckas, fungerar inte Sophos Firewall-regeln: kontrollera orsaker och testbrandväggsregel med Log Viewer, Policy Test och Packet Capture kan hjälpa.

Särskilt med blandade IPv4/IPv6-nätverk bör du också kontrollera om en applikation via IPv6 går förbi en strängare IPv4-regel. Om IPv6 inte används aktivt bör IPv6-strategin ändå dokumenteras medvetet: avaktivera, blockera, reglera ordentligt eller införa den på ett kontrollerat sätt.

Grundprincip och ordningsföljd

Brandväggsregler styr trafik mellan zoner och nätverk. Regler tillåter, avvisar eller blockerar trafik och kan tillämpa ytterligare säkerhetsfunktioner.

Sophos Firewall kontrollerar brandväggsregler uppifrån och ned. Så snart en regel matchar kontrolleras inte längre efterföljande brandväggsregler. Det som är viktigt är inte bara vad som finns i en regel, utan också var det finns i listan över regler.

En regel passar bara om alla relevanta kriterier gäller samtidigt:

• Källzon: Måste matcha, till exempel LAN.
• Källnätverk och enheter: Måste matcha, till exempel net_LAN_Clients.
• Schema: Måste matcha, till exempel All the time.
• Destinationszon: Måste matcha, till exempel WAN.
• Destinationsnätverk: Måste matcha, till exempel Any eller en FQDN-värd.
• Tjänster: Måste passa, till exempel HTTP, HTTPS och DNS.
• Användarmatchning: Måste matcha om det är aktiverat, till exempel AD grupp Internet-Users.
• Uteslutningar: Kan hoppa över regeln om den är inställd, till exempel på en utesluten backupserver.

Den första matchningsregeln vinner. Om en generell LAN_to_WAN_Any-regel placeras ovanför en specifik LAN_to_WAN_Restricted-regel, kommer den specifika regeln aldrig att uppnås.

Särskilt viktigt: Alla regler skapas inte manuellt. Sophos Firewall kan automatiskt skapa regler, till exempel för MTA, IPsec anslutningar eller hotspots. Sådana regler kan hamna högst upp på regellistan och ändra befintliga matchningar. Efter guider, VPN ändringar, MTA aktivering eller migrering, bör du alltid kontrollera om den förväntade regeln är före eller efter de automatiskt genererade reglerna.

I slutet av listan med regler finns den implicita släpp-all-regeln. Denna standardregel kan inte flyttas eller redigeras som en vanlig regel. Om trafiken inte hittar en matchande regel kommer den att kasseras där. I loggar och tester bör du därför skilja på om din egen blockeringsregel gäller eller om trafiken helt enkelt misslyckas tills standardfallet.

Planera regelbasen innan du skapar den

En enda brandväggsregel kan skapas snabbt. Vad som är svårare är en regelbas som fortfarande är begriplig, testbar och säker efter två år. Innan du inför nya regler bör du därför först klargöra vilken säkerhetszon, grupp och driftslogik regeln tillhör.

Användbara vägledande frågor:

• Vilken trafik bör egentligen tillåtas? Notera källan, destinationen och tjänsterna innan du skapar.
• Hör trafiken hemma i sin egen zon? Separera medvetet servrar, klienter, gäster, ledning, VPN och DMZ.
• Finns det redan en specifik regel? Kontrollen av den befintliga regulatorn är för att skapa och andra liknande regel.
• Är NAT inblandad? Planera brandväggsregeln och NAT-regeln tillsammans, men blanda inte ihop dem.
• Hur kommer testet att genomföras senare? Aktivera loggning och definiera en specifik testtrafik.
• Är frisläppandet tillfälligt? Dokumentets utgångsdatum eller biljett i beskrivningen.

För rena zoner och gränssnitt passar Sophos Firewall Konfigurera zoner och gränssnitt först. Om en befintlig regel inte fungerar, hjälper checklistan Sophos Firewall Regeln fungerar inte: Kontrollera orsaker.

⚠️ En bred Any-regel är ofta bekvämt, men sällan en bra slutlig konfiguration. Det kan hjälpa på kort sikt för tester. Det bör sedan ersättas eller tas bort igen av specifika källor, destinationer och tjänster.

Separera regeltyper rent

En bra regelbas skiljer tydligt olika risker från varandra. Det vanligaste felet är inte ett enda felaktigt alternativ, utan en generell regel som täcker klienter, servrar, VPN, gäster och hantering samtidigt. Detta fungerar snabbt i början, men blir senare svårt att testa och svårt att härda.

• Client Internet: Källan är klientnätverk, målet är vanligtvis WAN. Planera medvetet webbpolicy, Application Control, IPS, TLS Inspection, QUIC och loggning.
• Serverinternet: Källan är servernätverk, mål bör definieras för uppdatering, backup eller molnmål. Dessa regler är snävare än klientregler och har ofta ingen användarreferens.
• Gäst-WLAN: Källa är gästzonen, destinationen är vanligtvis WAN. Uteslut interna mål, kontrollera medvetet bandbredd och DNS.
• Hantering: Källan är administratörsnätverk, mål är brandvägg, servrar, switchar eller hypervisorer. Blanda inte med vanliga klientregler.
• VPN Fjärråtkomst: Källan är VPN eller dess egen fjärråtkomstzon, mål är interna målzoner. Tillåt endast nödvändiga destinationer och tjänster och logga dem i introduktionsfasen.
• Site-to-Site: Källan är lokala och avlägsna VPN-zoner eller XFRM-zoner, destinationer är partner- eller webbplatsnätverk. Kontrollera routing, NAT, returväg och loggning tillsammans.
• Publicerat system: Källan är WAN eller en definierad källa, Target är en DMZ eller serverzon. DNAT/WAF, IPS, loggning, patchstatus och källbegränsning ingår.
• Tillfällig åtkomst: Källa är en definierad stöd- eller projektkälla, målet förblir smalt. Dokumentbiljett, utgångsdatum, ägare och demontering.

Om två anslutningar har olika ägare, skyddsfunktioner eller granskningscykler är separata regler vanligtvis renare. Om endast en tilläggstjänst krävs för samma yrkesändamål kan en befintlig regel utökas.

Fiktivt praktiskt exempel

Som ett exempel skapas en ren klientregel:

Mål: Klienter från den interna LAN får åtkomst till Internet. Webbfilter, Application Control, IPS och loggning bör vara aktiva. Servrar, gäster och ledningsnätverk får sina egna regler och blandas inte med denna klientregel.

• Regelnamn: LAN_to_WAN_Clients så att källan och destinationen är omedelbart synliga.
• Description: Internet Access für Client-Netz, erstellt für Standard-Client-Traffic, så att det senare förblir tydligt varför regeln finns.
• Regelposition: Nedanför specifika block- och serverregler, så att specifika regler träder i kraft först.
• Regelgrupp: Internet Access för bättre överblick.
• Åtgärd: Accept eftersom den definierade trafiken ska tillåtas.
• Logga brandväggstrafik: Aktiverad så att felsökning förblir möjlig i Log Viewer.
• Källzoner: LAN eftersom trafiken kommer från zonen LAN.
• Källnätverk och enheter: net_LAN_Clients, inte alla LAN-nätverk.
• Under schemalagd tid: All the time om internetåtkomst ska vara permanent.
• Destinationszoner: WAN eftersom destinationen är Internet.
• Destinationsnätverk: Any, ofta praktiskt för klientinternet.
• Tjänster: HTTP, HTTPS, DNS, NTP, det vill säga endast nödvändiga bastjänster.
• Webbpolicy: Default Workplace Policy för att styra webbåtkomst baserat på kategorier.
• Blockera QUIC-protokoll: Aktiverat så att webbfiltrering och skanning förblir effektiva.
• IPS: Klientpolicy för exploateringsskydd för utgående klienttrafik.
• Appkontroll: Klientapplikationspolicy för att blockera oönskade appar.
• Forma trafik: Valfritt, endast om bandbredd krävs.
• DSCP-märkning: Tom, om inte nedströmsenheter utvärderar DSCP.

Det här exemplet är medvetet inte en Any gratisbiljett. I praktiken bör klientnätverk, servernätverk, gäst WLAN, VoIP och hantering övervägas separat.

För det första produktiva testet bör detta exempel innehålla ett kort testfall: definierad klient, specifik måladress, förväntad Rule ID, förväntad NAT Rule ID och en titt på Log Viewer eller Central/Syslog. Utan detta godkännandesteg förblir det oklart om regeln faktiskt behandlar den förväntade anslutningen.

Rubrikområde: Status, Namn, Åtgärd och Loggning

Regelstatus

Regelstatus aktiverar eller inaktiverar regeln.

En ny regel är vanligtvis aktiv. För förberedda regler kan du avaktivera statusen och aktivera regeln först senare. Inaktiverade regler bör kontrolleras regelbundet så att inga gamla test- eller migreringsregler finns kvar i konfigurationen.

Praktiskt exempel: En ny regel för en server förbereds men aktiveras endast i underhållsfönstret.

Vid felsökning är statusen en snabb uteslutning: en avaktiverad regel kan vara i rätt grupp, namnges korrekt och ändå aldrig matcha. En annan Rule ID visas sedan i Log Viewer eller standardfallet i slutet.

Regelnamn

Namnet bör omedelbart göra det klart vad regeln gör.

Bra namn:

• LAN_to_WAN_Clients
• Guest_to_WAN_WebOnly
• Server_to_WAN_Updates
• VoIP_to_WAN_SIP_RTP
• WAN_to_DMZ_HTTPS_Webserver

Namn som Rule1, Test, Allow eller Internet är mindre användbara eftersom du inte längre kan se vilken uppgift regeln har.

Beskrivning

Beskrivningen är viktig för verksamhet, support och revisioner. Det borde stå:

• varför regeln finns
• som begärde regeln
• vilka restriktioner som medvetet satts
• om det finns en biljett, projekt eller utgångsdatum

Exempel:

Internet Access für Client-Netz 10.10.10.0/24. Webfilter und IPS aktiv. Angefordert durch IT, geprüft am 10.06.2026.

Hur man använder detta fält på rätt sätt och dokumenterar brandväggsregler på ett begripligt sätt beskrivs mer i detalj i artikeln Sophos Firewall regler bör dokumenteras förnuftigt.

Regelposition

Regelposition avgör var den nya regeln kommer att infogas.

• Top: Använd endast för mycket specifika regler, blockregler eller tester.
• Bottom: Ofta användbart för nya standardregler.
• Above rule: Används när en regel specifikt måste träda i kraft innan en befintlig regel.
• Below rule: Använd om en regel specifikt ska följa en befintlig regel.

Grundregel: specifik före allmän. En regel för en enskild server eller en specifik applikation är vanligtvis högre upp än en allmän Internetregel.

Regelgrupp

Regelgrupp är en organisationsgrupp. Gruppen i sig är inte en säkerhetsgräns eller en egen policymotor. Brandväggen fortsätter att kontrollera varje regel uppifrån och ned.

Exempel på användbara grupper inkluderar:

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

I små miljöer kan None vara tillräckligt. I större miljöer lönar det sig tidigt med tydlig gruppering, annars blir regelbasen snabbt förvirrande.

Åtgärd

Åtgärd avgör vad som händer med matchande trafik.

• Accept: Trafik är tillåten. Detta är standard för normala tillåtna regler.
• Drop: Trafiken kasseras tyst. Användbart för blockregler där klienten inte ska få något svar.
• Reject: Trafiken avvisas och klienten får svar. Detta är ofta mer användbart för felsökning eller interna blockeringsregler.
• Protect with web server protection: WAF skydd tillämpas. Detta är en del av webbserverskyddet, inte normala LAN-till-WAN-regler.

För vanliga klient- eller serverregler använder du vanligtvis Accept. För blockregler är Drop tystare, Reject är ofta trevligare för felsökning.

En detalj är viktig med webbtrafik: webbpolicy och Använd webbautentisering för okända användare kan utlösa omdirigeringar, captive-portaler eller blockera sidor. När du testar bör du därför inte bara utvärdera beteendet i webbläsaren, utan även kontrollera Rule ID, åtgärd och användarmatchning i Log Viewer.

Logga brandväggstrafik

Loggbrandväggstrafik bör nästan alltid vara aktiverad för viktiga regler.

Utan loggning kommer viktig information att saknas senare i Loggvisaren. Många felsökningsfall misslyckas inte på grund av själva regeln, utan för att det inte fanns någon loggning och det inte går att se vilken regel som faktiskt gällde.

Viktigt: Brandväggen loggar vanligtvis brandväggssessioner när en anslutning avslutas och en Destroy-händelse inträffar. Inte alla anslutningar visas i det exakta ögonblicket som klienten startar den.

För att loggar ska vara synliga lokalt, i Sophos Central eller via syslog, måste Systemtjänster > Logginställningar också konfigureras på lämpligt sätt. För längre lagring är Sophos Central brandväggsrapportering eller en syslog-server vettigt. Mer om detta: Aktivera central brandväggsrapportering och Sophos Firewall Skicka syslog säkert till SIEM.

För produktiva regler bör loggning inte bara ses som en felsökningskrok. Det ligger också till grund för granskningar: Används regeln fortfarande, vilka källor gäller de, vilka mål som verkligen riktas och om en regel är för bred.

Källa, zon och schema

I området Källa definierar du varifrån trafiken kommer.

Källzoner

Källzoner är den zon som trafiken kommer ifrån.

Exempel:

• LAN för interna klientnätverk
• VPN för användare med fjärråtkomst
• DMZ för servernätverk
• Guest för gäster-WLAN
• WAN för inkommande internettrafik

Praktiskt exempel: LAN väljs för en Internetregel från klienter till Internet. För en DNAT-regel från extern till en intern server, används vanligtvis WAN som källzon i den associerade brandväggsregeln.

Källnätverk och enheter

Källnätverk och enheter begränsar källan mer exakt.

Möjliga objekt är till exempel:

• enskilda värdar
• Nätverk
• IP-intervall
• Värdgrupper
• FQDN värdar
• Landobjekt

Till att börja med verkar Any bekväm, men är ofta för bred. Ett specifikt klientnätverk, en värdgrupp eller ett tydligt namngivet nätverksobjekt är bättre.

Praktiskt exempel: Istället för Any i källan används net_LAN_Clients. Servrar, skrivare, gäster och hanteringsenheter får egna regler.

Under schemalagd tid

Under schemalagd tid avgör när regeln gäller.

Typiska värden:

• All the time
• Arbetstider
• Underhållsfönster
• tillfälliga utsläpp

Scheman är till hjälp om åtkomst endast ska tillåtas vid vissa tider. Vid felsökning måste du alltid kontrollera om brandväggens tid, tidszon och schema verkligen stämmer.

Praktiskt exempel: Extern underhållsåtkomst till en server är endast tillåten under ett definierat underhållsfönster.

Destination och tjänster

I området Destination och tjänster definierar du var trafiken är tillåten och vilka portar eller protokoll som är tillåtna.

Destinationszoner

Destinationszoner är destinationszonen.

Exempel:

• WAN för internetåtkomst
• DMZ för servrar i en DMZ
• LAN för interna mål
• VPN för fjärranvändare eller rutter från plats till plats

Praktiskt exempel: För klientinternettrafik använder du WAN. Server eller DMZ kan användas för klienter att komma åt en intern server om dessa zoner skapas i enlighet med detta.

Destinationsnätverk

Destinationsnätverk begränsar destinationen mer exakt.

För klientens internetregler är Any ofta en hållbar start. För servrar, hanteringsnätverk eller VPN-åtkomst bör målen begränsas betydligt mer.

Exempel:

• Any för allmän Internetåtkomst
• FQDN värd gillar updates.vendor.com
• Värdobjekt för en intern server
• Nätverksobjekt för en fjärrstation via VPN
• Landobjekt för Geo-IP-regler

Praktiskt exempel: En backupserver får bara gå till tillverkarens molnbackupdestinationer, inte till Any.

Tjänster

Tjänster är protokoll- och portdefinitioner.

Exempel:

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

Tjänster bör väljas så nära som möjligt. Any är bara vettigt om alla protokoll verkligen måste tillåtas eller om du medvetet arbetar med andra kontroller.

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

Matcha kända användare

Med Matcha kända användare blir användaridentiteten en del av matchningen. Regeln gäller då inte längre bara för IP-adresser, utan för kända användare eller grupper.

Detta är vettigt om:

• Webbpolicyer bör gälla per AD grupp
• Rapporteringen ska vara användarrelaterad
• Olika användargrupper får olika interneträttigheter
• MFA, Captive Portal eller SSO är redan korrekt konfigurerade

Stumbling block: Om autentiseringen inte fungerar korrekt kanske regeln inte matchar. Då sjunker trafiken till en mer allmän regel nedan eller sjunker av släpp-all-regeln.

För inledande tester är det ofta bättre att börja utan användarmatchning och lägga till användarkriterier senare.

Om användarmatchning används bör det inte finnas en bred reservregel som tillåter samma trafik utan användarreferens. Annars verkar användarregeln ren, men okända användare slutar fortfarande med den allmänna regeln. När Log Viewer är godkänd bör därför användaren, gruppen och Rule ID visas.

Lägg till uteslutning

Med Lägg till uteslutning kan trafik uteslutas från en regel. Brandväggen hoppar bara över denna regel om alla uteslutningskriterier matchar och kontrollerar sedan nästa regel.

Undantag kan inkludera källzoner, källnätverk och enheter, destinationszoner, destinationsnätverk och tjänster.

Praktiskt exempel: En allmän klientinternetregel använder webbfilter. En specifik uppdateringsserver bör dock köra sin egen regel med andra säkerhetsfunktioner. Då kan du utesluta denna server från den allmänna regeln.

Uteslutningar är kraftfulla, men de gör regler svårare att läsa. Om en regel innehåller många undantag är en separat specifik regel ofta mer förståelig.

Create linked NAT rule

Med Create linked NAT rule kan en Source NAT-regel skapas direkt från brandväggsregeln. Denna länkade NAT-regel visas sedan i regeltabellen NAT.

Detta låter bekvämt för nybörjare, men i praktiken är oberoende NAT-regler vanligtvis tydligare. Om en generisk NAT-regel redan täcker samma trafik, bör du inte skapa en ytterligare länkad NAT-regel.

För en normal klient-till-internet-regel är standardregeln SNAT med MASQ vanligtvis tillräcklig, så länge den är aktiv och passar regelbasen korrekt.

Viktigt: NAT tillåter inte trafik i sig. NAT översätter adresser eller portar. Lämplig brandväggsregel avgör fortfarande om trafik tillåts.

En länkad NAT-regel använder matchningskriterierna för den länkade brandväggsregeln. I den länkade NAT-regeln kan du i huvudsak redigera den översatta källan eller en gränssnittsspecifik källöversättning. Om mer logik behövs är en oberoende NAT regel vanligtvis mer transparent.

Med DNAT är utvärderingsordningen också viktig: Brandväggen bestämmer först det översatta målet med hjälp av regeln DNAT. För matchning av brandväggsregel använder den sedan målzonen som detta översatta mål tillhör. Därför pekar inkommande portvidarebefordran till en server i DMZ vanligtvis till Destinationszon DMZ i brandväggsregeln, även om klienten ursprungligen adresserade den offentliga WAN-adressen.

Linked NAT Rules är endast relevanta för trafik som matchar den associerade brandväggsregeln. Men om en oberoende NAT-regel ovanför den länkade NAT-regeln matchar samma trafik, vinner denna övre NAT-regel. Om NAT ID är oväntat bör du inte bara kontrollera brandväggsregeln, utan även ordningen i Rules and policies > NAT rules.

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

Webbfiltrering

I området Webbfiltrering konfigureras webbpolicy, skanning av skadlig programvara och webbfilterbeteende.

Webbpolicy

Webbpolicy styr webbåtkomst via kategorier, användare, grupper, URL-grupper och regler.

Praktiskt exempel: En webbpolicy används för klienter som blockerar skadlig programvara, nätfiske, barnförbjudet innehåll och riskabla kategorier, men tillåter affärsapplikationer.

Om ingen webbpolicy är inställd kommer kategoribaserad webbfiltrering inte att ske via detta alternativ.

Hur man planerar kategorier, URL-grupper, webbpolicyer och omedelbara varningar tillsammans beskrivs i Sophos Firewall Använda webbkategorier och omedelbara varningar.

Tillämpa webbkategoribaserad trafikformning

Det här alternativet tillämpar trafikformning baserat på webbkategorier. Det är bara vettigt om lämpliga regler för trafikformning eller webbkategoripolicyer används.

Praktiskt exempel: Streamingkategorier är begränsade, affärsapplikationer förblir att föredra.

Blockera protokollet QUIC

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

Om webbfiltrering eller skanning av skadlig programvara efter webbtrafik är viktigt, bör Blockera QUIC-protokoll lämnas aktiverat i många miljöer. Webbläsare går då vanligtvis tillbaka till normal HTTPS över TCP, vilket är lättare att kontrollera och kontrollera.

Mer om detta: Sophos Firewall Blockera QUIC och HTTP/3 korrekt.

Skanna HTTP och dekrypterad HTTPS

Det här alternativet skannar HTTP och redan dekrypterad HTTPS efter skadlig programvara.

Viktigt: Det här alternativet dekrypterar inte HTTPS automatiskt. För att HTTPS verkligen ska kontrolleras krävs lämpliga SSL/TLS inspektionsregler under Rules and policies > SSL/TLS inspection rules.

Praktiskt exempel: Om TLS Inspection är aktiv för LAN_to_WAN_Clients, kan Skanna HTTP och dekrypterad HTTPS skanna nedladdade filer i dekrypterad HTTPS-trafik.

Mehr dazu: TLS Inspection auf Sophos Firewall schrittweise ausrollen.

Använd nolldagsskydd

Använd Zero-day-skydd skickar misstänkta nedladdningar till Sophos Zero-Day Protection för vidare analys. Detta är användbart för klient- och serverregler som vill kontrollera nedladdningar från Internet.

Funktionen kräver en lämplig licens och kan leda till förseningar beroende på filtyp och policy.

Skanna FTP efter skadlig programvara

Det här alternativet söker igenom FTP-trafik efter skadlig programvara. Det är endast relevant om FTP faktiskt används och lämpliga tjänster i allmänhet är tillåtna.

FTP har blivit mindre vanligt i moderna miljöer, men det förekommer fortfarande i äldre system, maskinkontroller eller äldre uppdateringsmekanismer.

Använd webproxy är tillgänglig för DPI-motor

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

För moderna inställningar är DPI vanligtvis ett bättre standardval eftersom det kan hantera HTTP- och SSL/TLS-trafik på alla portar. Web Proxy är fortfarande användbar om speciella proxyfunktioner krävs, till exempel SafeSearch-tillämpning, YouTube-begränsningar, Google-apps domänbegränsningar, pharming-skydd, webbcache eller överordnad proxy.

Om Använd webbproxy är tillgänglig för DPI-motor internt markörhjul, fungerar regler på DPI-plats.

Dekryptera HTTPS under webbproxyfiltrering

Det finns ett alternativ till att lyssna på webbproxyn. Det är relevant att Använd webproxy är tillgänglig för DPI-motor är aktiverad och HTTPS dekrypteras i proxy.

I DPI-läge kontrolleras inte HTTPS-dekryptering här, utan via SSL/TLS inspektionsregler.

Synchronized Security Hjärtslag

Med Konfigurera Synchronized Security Heartbeat kan Sophos Endpoint-statusen inkluderas i brandväggsregeln.

Typiska alternativ:

• Ställ in lägsta status för källenheter
• Blockera klienter utan hjärtslag
• Ställ in lägsta status för målenheter
• Blockera förfrågningar till destinationer utan ett hjärtslag

Detta är starkt, men är bara vettigt om Sophos Endpoint, Sophos Central och Security Heartbeat är korrekt inställda.

Praktiskt exempel: Klienter med röd Security Heartbeat får inte längre komma åt servrar eller har inte längre tillgång till Internet.

För en första klientregel bör du inte aktivera hjärtslag blint, annars kan du blockera enheter som inte kan skicka ett hjärtslag alls. Destinationshjärtslag är också endast lämpligt för interna målenheter, inte för destinationer i WAN-zonen.

Kombinationen av hjärtslagsblockering och webbundantag är särskilt knepig. Om Blockera klienter utan hjärtslag är aktivt och ett webbundantag hoppar över Policykontroller, kan webbförfrågningar fortfarande komma igenom. Sådana undantag bör därför dokumenteras, strikt begränsas och kontrolleras i Log Viewer.

Andra säkerhetsfunktioner

Identifiera och kontrollera applikationer (appkontroll)

En Application Filter-policy väljs via Identifiera och kontrollera applikationer (appkontroll).

Detta gör att applikationer kan kännas igen och kontrolleras, till exempel:

• TeamViewer
• Port
• Messenger
• Streaming
• Cloud Storage
• Fjärrkontrollverktyg

Application Control kräver en lämplig licens. I praktiken ingår denna funktion i Sophos Firewall-paketen med Web Protection, till exempel Standard Protection, Xstream Protection eller Epic Protection.

För applikationsdetektering i krypterad trafik är TLS Inspection ofta avgörande. Utan dekryptering, beroende på tjänst, ser brandväggen bara värdnamn, SNI, certifikatinformation eller IP:er och inte hela innehållet.

Den egna processen för filter, regelbindning, loggar och falsk positiv kontroll finns i Sophos Firewall Konfigurera och testa Application Control.

Tillämpa applikationsbaserad trafikformningspolicy

Det här alternativet tillämpar trafikformning som definieras i programpolicyn eller Application Object.

Praktiskt exempel: Microsoft Teams bör erkännas och prioriteras med en specifik policy för trafikformning. Sedan måste lämplig Application Control-policy väljas och den programbaserade trafikformningspolicyn måste tillämpas.

Om du redan har ställt in en explicit trafikformningspolicy i fältet Shapetrafik, bör det tydligt dokumenteras vilken policy som ska ha företräde och varför.

Upptäck och förhindra utnyttjanden (IPS)

En IPS-policy väljs under Detektera och förhindra utnyttjanden (IPS).

IPS kontrollerar trafik för kända attackmönster och utnyttjande. En annan policy används för klienttrafik till Internet än för servertrafik eller publicerade tjänster.

Praktiska exempel:

• Klientregel LAN_to_WAN: Klient- eller LAN-till-WAN-IPS policy
• DNAT regel till webbserver: server eller webbserver IPS policy
• VoIP-regel: Testa noggrant eftersom aggressiva IPS-profiler kan störa VoIP

IPS ska inte bara aktiveras överallt med den hårdaste policyn. En IPS-policy som är för bred eller felaktig kan bryta legitim trafik eller skapa onödig belastning.

Den dedikerade artikeln Sophos Firewall Konfigurera och testa IPS på ett säkert sätt förklarar global aktivering, licensstatus, policyval, loggning och falsk positiv analys i mer detalj.

Forma trafiken

Med Shape-trafik kan en trafikformningspolicy tillämpas direkt på regeln.

Detta är relevant för:

• VoIP
• Onlinemöten
• Backup trafik
• Gäst WLAN
• långsamma WAN rutter

Praktiskt exempel: Gäst WLAN får en limitpolicy så att den inte tränger ut affärstrafik.

Mehr dazu: Application Traffic Shaping auf Sophos Firewall konfigurieren.

DSCP-märkning

DSCP-märkning markerar paket för tjänstens kvalitet på nedströms nätverksenheter.

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

Praktiskt exempel: VoIP-trafik får en DSCP-märkning så att switchar och WAN-routrar behandlar denna trafik företräde.

Skanna med NDR Aktiv hotintelligens

Skanna med NDR Aktiv hotintelligens använder Sophos NDR hotintelligens för ytterligare bedömning av nätverkstrafik.

Det här alternativet är bara användbart om miljön använder de nödvändiga komponenterna Sophos Central och NDR. I många miljöer är det inte det första alternativet för en basregel, men det kan vara ett värdefullt tillägg i mer övervakade nätverk.

Skanna e-postinnehåll

Området Skanna e-postinnehåll gäller e-postprotokoll.

Möjliga alternativ:

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

Om du aktiverar protokoll där måste även lämpliga standardportar ingå i regelns tjänster eller läggas till via Lägg till portar.

Detta område är ofta inte relevant för vanliga webbklientregler. Du bör planera det medvetet för e-postservrar eller klient-e-posttrafik.

Praktiskt exempel: En intern e-postserver får skicka SMTP externt. En separat serverregel skapas sedan, loggning aktiveras och e-postskanning kontrolleras för att matcha e-postarkitekturen.

Kontrollera efter att du har sparat

Efter att ha sparat bör du testa regeln och inte bara utgå från att allt fungerar korrekt.

För att kontrollera:

1. Är regeln i rätt läge?
2. Är Loggbrandväggstrafik aktiv?
3. När reglerna ändrades, återställdes träffräknaren eller skapades ett klart nytt test?
4. Stämmer regeln i Loggvisaren?
5. Visas den förväntade brandväggen Rule ID?
6. Gäller den önskade NAT-regeln?
7. Fungerar DNS?
8. Används webbfilter, IPS, Application Control och TLS Inspection som förväntat?
9. Finns det några oväntade fall eller SSL/TLS-fel?

Artikeln Testa brandväggsregeln med Log Viewer, Policy Test och Packet Capture hjälper dig att utföra en ren kontroll.

När du gör produktiva förändringar är en liten före-och-efter-jämförelse vettig:

• Säkerhetskopierings- eller återställningspunkt tillgänglig: Återställning är fortfarande möjlig om regeln ger biverkningar.
• Revisionsspår eller ändringsbiljett noterat: Senare kommer det att framgå vem som gjorde ändringen och när.
• Testfall definierat i förväg: Framgång utvärderas inte bara utifrån känsla.
• Endast en förändring per test: Orsak och verkan förblir spårbara.
• Log Viewer eller centrala loggar kontrollerade: De riktiga Rule ID och NAT ID är synliga.
• Demonteringsbeslut dokumenterat: Tillfälliga testregler förblir inte permanent aktiva.

Om du har flera brandväggar eller centralt hanterade grupper bör du också kontrollera om ändringen har nått rätt apparat eller grupp. För Sophos Central hjälper Firewall Management Task Queue, lokala ändringar kan spåras med Audit Trail Logs.

Regelbunden drift och genomgång

En brandväggsregel är inte klar bara för att den har sparats. Bra regler har ett tydligt syfte, loggas, är testbara och kan kontrolleras igen senare. Särskilt i mogna miljöer uppstår många risker inte från en enda felaktig regel, utan från gamla undantag, tjänster som är för breda eller regler utan ägare.

En enkel rutin är värt besväret för regelbundna recensioner:

• Görs regeln fortfarande? Oanvända regler kan ofta inaktiveras och tas bort senare.
• Är källan fortfarande korrekt? Klientnätverk, servernätverk och VPN-områden förändras över tiden.
• Är Any fortfarande motiverad? Breda källor, mål eller tjänster bör medvetet dokumenteras.
• Är loggning aktiv och användbar? Utan loggar är senare analyser och revisioner betydligt svagare.
• Passar NAT, webbfilter, IPS och TLS Inspection fortfarande? Säkerhetsfunktioner kan fungera annorlunda efter uppgraderingar, appändringar eller certifikatändringar.
• Finns det ett utgångsdatum? Tillfälliga projekt- eller stödregler förblir annars permanent aktiva.

För kritiska regler bör du också dokumentera vem som är tekniskt ansvarig. Detta är särskilt viktigt för publicerade tjänster, VPN-regler, hanteringsåtkomst, tjänsteleverantörsgodkännanden och regler med Any i tjänster eller destination.

Ny regel, ändra eller avaktivera befintlig regel?

Inte varje ny begäran behöver omedelbart en ny brandväggsregel. För många liknande regler gör listan förvirrande, men regler som är för sammanfattade blir snabbt för breda. Ett enkelt beslut hjälper innan du sparar något i WebAdmin:

• Samma källa, samma destination, samma syfte, bara en extra tjänst: Utöka befintlig regel. Regeln förblir tekniskt sammanhängande och lättare att testa.
• Samma nätverk, men olika skyddskrav, annan loggning eller annan ägare: Skapa din egen regel. Webbfilter, IPS, TLS Inspection, NDR eller loggning kan kontrolleras separat.
• Tillfällig tjänsteleverantör eller supportåtkomst: Skapa din egen tillfälliga regel. Ägare, biljett, utgångsdatum och testfönster förblir väl synliga.
• Server, gäster, VoIP, IoT eller hantering påverkas: Kontrollera din egen regel eller zon. Olika risker bör inte försvinna i en klientinternetregel.
• En regel är otydlig eller gammal: Inaktivera och observera först. Direkt radering tar bort möjligheten att kontrollera träffar, loggar och beroenden på ett kontrollerat sätt.
• En regel är säkerligen onödig efter en granskning: Ta bort efter säkerhetskopiering och dokumentation. Regeluppsättningen blir mindre utan att blint fungerande beroenden bryts.

För normala driftsförändringar är denna process robust:

1. Notera syfte, ägare, biljett och förväntad trafik.
2. Kontrollera befintliga regler för samma källa, destination, tjänst och regelgrupp.
3. Bestäm om en befintlig regel ska utökas eller om din egen regel är renare.
4. För produktiva förändringar, planera backup, revisionsspår och testfall.
5. Efter att ha sparat, kontrollera Log Viewer, Rule ID, NAT beslut och påverkade säkerhetsfunktioner.

Om beslutet misslyckas främst på grund av bristande dokumentation, bör Sophos Firewall regler dokumenteras förnuftigt först. Om det är oklart om en befintlig regel fortfarande behövs, hjälper ett kontrollerat test med Testa brandväggsregel med Log Viewer, Policy Test och Packet Capture.

Ordna träffräknare korrekt

Hiträknare hjälper till med städning, men är inte fullständiga bevis. En sällan använd nödregel kan fortfarande vara viktig. Omvänt kan en bred regel ha många träffar även om den tillåter för mycket.

För recensioner bör du alltid kombinera träffräknare med Log Viewer, regelbeskrivning och faktisk användningsfall. Om en regel är otydlig ska den inte raderas omedelbart. En kontrollerad process är bättre: klargör syftet, aktivera loggning, definiera testfönster, informera intressenter och först därefter avaktivera eller ta bort det.

Om du tydligt vill definiera ett nytt test kan dataräknaren för en regel återställas. Detta ersätter inte en loggkontroll, men det hjälper att se om denna regel behandlar trafik igen under testfönstret. Reports > Dashboards > Traffic dashboard > Allowed policies är också användbar för utvärderingar av överförda data.

Gör ändringar begripliga

En säkerhetskopia bör finnas tillgänglig innan större regeländringar. Audit Trail och Config Studio hjälper sedan till att kontrollera skillnader på ett begripligt sätt. Den praktiska processen finns i Sophos Firewall Kontrollera granskningsloggar och Sophos Firewall Använd Config Studio.

Om många regler justeras bör du inte bara jämföra konfigurationen, utan även köra riktiga testfall. En regel kan vara syntaktisk korrekt och fortfarande tillåta felaktig trafik, använda fel NAT sökväg eller störa ett program genom IPS, webbfilter eller TLS Inspection.

Typiska misstag

Regeln är för långt ner: En mer allmän regel ovan matchar trafiken först.

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

Destinationen är för bred: Servrar eller hanteringsnätverk bör sällan tillåtas åtkomst till Internet med Any.

Tjänsterna är för breda: Any tillåter betydligt mer än nödvändigt. Specifika tjänster eller tjänstegrupper är bättre.

Loggningen är inte aktiv: Den viktigaste informationen saknas då i Log Viewer.

IPv6 glömdes bort: IPv4 är korrekt reglerat, men IPv6 körs på andra regler eller förblir öppet omedvetet.

Regelgrupp är definitivt förvirrad: En regelgrupp förbättrar bara översikten. En regelgrupp är inte sin egen säkerhetsgräns och ändrar inte utvärderingslogiken.

HTTPS is not scanned: Scan HTTP and decrypted HTTPS is active, but there is no matching SSL/TLS inspection rule or no decryption.

Webbfiltret fungerar inte: Ingen webbpolicy inställd, fel användare, fel källzon eller QUIC inte blockerad.

Användarmatchning fungerar inte: Autentisering, AD SSO, captive portal eller användarmappning fungerar inte korrekt.

NAT saknas: Brandväggsregeln tillåter trafik, men SNAT/MASQ matchar inte.

Säkerhetsfunktionen matchar inte trafik: En felaktig IPS-policy, proxyalternativ eller e-postskanningsalternativ kan bryta legitim trafik.

Om det efter dessa punkter fortfarande är oklart varför trafiken körs annorlunda än förväntat, bör du fortsätta att kontrollera på ett strukturerat sätt med Log Viewer, Policy tester och Packet Capture. Lämplig procedur finns i Testa brandväggsregel med Log Viewer, Policy Test och Packet Capture.

FAQ