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

Brandväggsreglerna är kärnan 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, Logging, Source, Destination, Services, User Matching, Exclusions, NAT, Web Filtering, TLS Inspection, Security Heartbeat, Application Control, Traffic, Shaping, Shaping, Shaping, Shaping, Shaping. NDR och e-postskanning.

Menysökvägen är:

Rules and policies > Brandväggsregler > Lägg till brandväggsregel > Ny brandväggsregel

Regelmasken är uppdelad i flera områden: rubrikområde, källa, destination, Services, 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.

Snabbnavigering

• Vilka brandväggsregler styr och vad de inte gör
• Grundläggande princip och sekvens
• Planera regelbas före skapandet
• Separera regeltyper rent
• Fiktivt praktiskt exempel
• Rubrikområde: Status, Namn, Åtgärd och Loggning
• Källa, zon och schema
• Destination och tjänster
• Match known users
• Lägg till uteslutning
• Create linked NAT rule
• Webbfiltrering
• Synchronized Security Heartbeat
• 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, VLAN 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: Denna artikel.
• Klassificera NAT, SNAT, DNAT, MASQ eller PAT: Förstå NAT på Sophos Firewall: SNAT, DNAT, MASQ, PAT
• Publicera intern server via portvidarebefordran: Publicera server via DNAT till Sophos Firewall
• Säkra en offentlig webbapplikation: Sophos Firewall Konfigurera och organisera WAF
• Regeln gäller inte eller felaktig Rule ID visas: Sophos Firewall Regeln gäller inte: kontrollera orsaker
• Testregel specifikt: Testa brandväggsregeln med Log Viewer, Policy Test och Packet Capture
• WebAdmin, VPN Portal, User Portal, SSH, säker DNS eller SNMP för brandväggen: Sophos Firewall Säkra åtkomst: Konfigurera Device Access korrekt
• Planera zoner, gränssnitt eller VLANs: Sophos Firewall Konfigurera zoner och gränssnitt
• Manövrera bryggan med VLAN-taggar: Använd Sophos Firewall Bridge med VLAN Tagging
• Kontrollera ruttordning eller SD-WAN-vägar: Sophos Firewall Justera routingprioritet
• Svarspaket eller systemtrafik går via fel sökvä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 vanlig DNAT-portvidarebefordran.

Vilka brandväggsregler styr och vad de inte gör

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. Det är här det avgörs om genomfartstrafik är tillåten, 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. Lokala brandväggstjänster behandlas inte som normal LAN-till-WAN eller WAN-till-DMZ-trafik.
• Adress- eller portöversättning: NAT-regler. NAT översätter trafik men tillåter det inte automatiskt.
• Ruttval, returväg, SD-WAN och VPN vägar: Routing, SD-WAN, Route Precedence och VPN konfiguration. En lämplig brandväggsregel visar sig inte fungera långt tillbaka.
• Webbkategorier, URL-grupper och webbpolicy: Webbfiltrering och webbpolicy. Brandväggsregeln integrerar policyn, men själva webblogiken ligger i webbpolicyn.
• HTTPS-dekryptering: SSL/TLS-inspektionsregler och CA-distribution. Scan HTTP and decrypted HTTPS skannar endast trafik som redan är dekrypterad.
• Användaridentitet: Autentisering, STAS, Captive Portal, Entra ID SSO eller RADIUS. En användarregel matchar bara om brandväggen kan tilldela användaren trafiken.

För förvaltning och portaltjänster är Device Access och Local Service ACL den centrala artikeln. Om en regel matchar men anslutningen fortfarande misslyckas, hjälper Sophos Firewall-regeln inte: Kontrollera orsaker och Testa brandväggsregel med Log Viewer, Policy Test och Packet Capture.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.

Grundläggande princip och sekvens

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: Ja. LAN.
• Source networks and devices: Ja. net_LAN_Clients.
• Schema: Ja. All the time.
• Destinationszon: Ja. WAN.
• Destination networks: Ja. Any eller en FQDN-värd.
• Services: Ja. HTTP, HTTPS, DNS.
• Användarmatchning: Endast om aktiverad. AD grupp Internet-Users.
• Uteslutningar: Om den är inställd kan regeln hoppas över. Exkludera backupserver.

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

Planera regelbasen innan du skapar

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 typ av trafik ska egentligen tillåtas?: Notera källa, destination och Services 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?: Kontrollera befintliga regler istället för att skapa en andra liknande regel.
• Är NAT inblandad?: Planera brandväggsregler och NAT-regler tillsammans, men blanda inte ihop dem.
• Hur kommer det att kontrolleras senare?: Aktivera loggning och definiera specifik testtrafik.
• Är utgivningen tillfällig?: Dokumentera 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, kommer checklistan Sophos Firewall Regel fungerar inte: Kontrollera orsaker att hjälpa.

⚠️ En bred Any-regel är ofta bekväm, 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 ledning samtidigt. Detta fungerar snabbt i början, men blir senare svårt att testa och svårt att härda.

• Klient Internet: Typisk källa: Klientnätverk; Typiskt mål: WAN; Vad ska man vara uppmärksam på?: Webbpolicy, Application Control, IPS, TLS Inspection, QUIC, Loggning.
• Server Internet: Typisk källa: Servernätverk; Typiskt mål: definierade mål för uppdatering, backup eller moln; Vad ska man vara uppmärksam på?: stramare än klientreglerna, ofta utan användarreferens.
• Gäst-WLAN: Typisk källa: Gästzon; Typiskt mål: WAN; Vad ska man vara uppmärksam på?: ingen medveten kontroll av interna mål, bandbredd och DNS.
• Ledning: Typisk källa: Administratörsnätverk; Typiskt mål: Brandvägg, servrar, switchar, hypervisorer; Vad ska man vara uppmärksam på?: blanda inte med vanliga klientregler.
• VPN Fjärråtkomst: Typisk källa: VPN eller egen fjärråtkomstzon; Typiskt mål: interna målzoner; Vad ska man vara uppmärksam på?: endast nödvändiga mål och tjänster, loggning i introduktionsfasen.
• Webbplats till webbplats: Typisk källa: lokala och fjärranslutna VPN-zoner eller XFRM-zoner; Typiskt mål: Partner- eller platsnätverk; Vad ska man vara uppmärksam på?: Kontrollera routing, NAT, returväg och loggning tillsammans.
• Publicerad System: Typisk källa: WAN eller definierade källor; Typiskt mål: DMZ eller serverzon; Vad ska man vara uppmärksam på?: DNAT/WAF, IPS, loggning, patchnivå och källbegränsning.
• Tillfällig åtkomst: Typisk källa: definierat stöd eller projektkälla; Typiskt mål: smalt mål; Vad ska man vara uppmärksam på?: 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 tillåts åtkomst till Internet. Webbfilter, Application Control, IPS och loggning ska vara aktiva. Servrar, gäster och ledningsnätverk får sina egna regler och blandas inte med denna klientregel.

• Regelnamn: LAN_to_WAN_Clients. Rensa namn med källa och destination.
• Beskrivning: Internet Access für Client-Netz, erstellt für Standard-Client-Traffic. Senare kommer du att få veta varför regeln finns.
• Rule position: Under specifika block- och serverregler. Särskilda regler bör träda i kraft först.
• Rule group: Internet Access. Bättre överblick.
• Åtgärd: Accept. Trafik är tillåten.
• Logga brandväggstrafik: Aktiverad. Felsökning av Log Viewer.
• Source zones: LAN. Trafiken kommer från LAN-zonen.
• Source networks and devices: net_LAN_Clients. Inte alla LAN-nätverk, bara klienter.
• Under schemalagd tid: All the time. Internetåtkomst bör vara permanent.
• Destination zones: WAN. Målet är Internet.
• Destination networks: Any. Mest praktiskt för klientinternet.
• Services: HTTP, HTTPS, DNS, NTP. Endast nödvändiga bastjänster.
• Web policy: Default Workplace Policy. Kontrollera webbåtkomst baserat på kategorier.
• Block QUIC protocol: Aktiverad. Webbfiltrering och skanning förblir effektiva.
• IPS: Kundpolicy. Exploateringsskydd för utgående kundtrafik.
• Appkontroll: Klientapplikationspolicy. Blockera oönskade appar.
• Forma trafik: Valfritt. Endast om bandbredd krävs.
• DSCP marking: Tom. Endast nödvändigt om nedströmsenheter utvärderar DSCP.

Detta exempel är medvetet inte en Any gratisbiljett. I praktiken bör klientnätverk, servernätverk, gästnätverk, 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.

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
• vem 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 förnuftigt dokumentera regler.

Rule position

Rule position anger var den nya regeln kommer att infogas.

• Top: Endast för mycket specifika regler, blockregler eller tester.
• Bottom: Ofta användbart för nya standardregler.
• Above rule: Om en regel specifikt måste träda i kraft innan en befintlig regel.
• Below rule: 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.

Rule group

Rule group ä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. Normala tillåtna regler.
• Drop: Trafiken kasseras tyst. Blockera regler där klienten inte ska få ett svar.
• Reject: Trafiken avvisas och klienten får svar. Felsökning eller interna blockeringsregler.
• Protect with web server protection: WAF-skydd tillämpas. Webserverskydd, inte för vanliga LAN-till-WAN-regler.

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

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 System services > Log settings också konfigureras på lämpligt sätt. För längre lagring är Sophos Central Firewall Reporting eller en Syslog-server vettigt. Mer om detta: Aktivera central brandväggsrapportering och Skicka Sophos Firewall 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.

Source zones

Source zones är zonen där 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 WAN vanligtvis som källzon i den associerade brandväggsregeln.

Source networks and devices

Source networks and devices 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änd net_LAN_Clients. Servrar, skrivare, gäster och hanteringsenheter får sina 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.

Destination zones

Destination zones är målzonen.

Exempel:

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

Praktiskt exempel: WAN används för klientinternettrafik. Server eller DMZ kan användas för klienter att komma åt en intern server om dessa zoner skapas i enlighet därmed.

Destination networks

Destination networks begränsar målet 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 tillgång till internet
• FQDN-värd som updates.vendor.com
• Värdobjekt för en intern server
• Nätverksobjekt för en fjärrstation via VPN
• Landsobjekt för Geo-IP-regler

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

Services

Services är protokoll- och portdefinitioner.

Exempel:

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

Services bör väljas så snävt 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.

Match known users

Med Match known users blir användaridentitet 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 den accepteras bör Log Viewer därför visa användaren, gruppen och Rule ID.

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 Source zones, Source networks and devices, Destination zones, Destination networks och Services.

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 käll-NAT-regel skapas direkt från brandväggsregeln. Denna länkade NAT-regel visas sedan i NAT-regeltabellen.

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 standard-SNAT-regeln 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.

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.

Web policy

Web policy 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.

Använd 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.

Block QUIC protocol

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

Om webbfiltrering eller skanning av skadlig programvara efter webbtrafik är viktigt, bör Block QUIC protocol 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.

Scan HTTP and decrypted 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-inspektionsregler.

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

Mer om detta: Rulla ut TLS Inspection till Sophos Firewall gradvis.

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 bara relevant om FTP faktiskt används och den matchande Services vanligtvis är tillåten.

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

Använd webbproxy istället för DPI engine

Sophos Firewall kan kontrollera webbtrafik via DPI engine eller via webbproxy.

För moderna inställningar är DPI vanligtvis det bättre standardvalet eftersom det kan hantera HTTP- och SSL/TLS-trafik på alla portar. Webproxyn ä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 istället för DPI engine inte är aktiverat fungerar regeln i DPI-läge.

Dekryptera HTTPS under webbproxyfiltrering

Det här alternativet tillhör webbproxyläget. Det är endast relevant om Använd webbproxy istället för DPI engine är aktiverat och HTTPS ska dekrypteras i proxyläge.

I DPI-läge kontrolleras inte HTTPS-dekryptering här, utan snarare 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.

Andra säkerhetsfunktioner

Identifiera och kontrollera applikationer (appkontroll)

En applikationsfilterpolicy väljs via Identifiera och kontrollera applikationer (Appkontroll).

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

• Team Viewer
• Gate
• Budbärare
• Streaming
• Molnlagring
• Fjärrkontrollverktyg

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

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

Den anpassade processen för filter, regelbindning, loggar och falsk positiv kontroll är tillgänglig i Sophos Firewall Konfigurera och testa Application Control.

Apply application-based traffic shaping policy

Det här alternativet tillämpar trafikformning som definierats i applikationspolicyn eller applikationsobjektet.

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 trafiken 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: IPS-policy för server eller webbserver
• 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 IPS och testa det säkert 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.

Mer om detta: Konfigurera Application Traffic Shaping på Sophos Firewall.

DSCP marking

DSCP marking markerar paket för tjänstekvalitet på nedströmsnä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 Threat Intelligence för att ytterligare bedöma nätverkstrafik.

Det här alternativet är bara användbart om miljön använder de nödvändiga Sophos Central- och NDR-komponenterna. 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 lämpliga standardportar också inkluderas i regelns Services 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 till för 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 finns: Demontering förblir möjlig om regeln ger biverkningar.
• Revisionsspår eller ändringsbiljett noterat: senare kommer det att stå klart vem som gjorde ändringen och när.
• Testfall definierat i förväg: Framgång bedöms inte bara av känsla.
• Endast en förändring per test: Orsak och verkan förblir begripliga.
• Log Viewer eller centrala loggar kontrollerade: de riktiga Rule ID och NAT ID är synliga.
• Nedmonteringsbeslut dokumenterat: temporära 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 till; lokala ändringar kan spåras med Audit Trail Logs.

Regelbunden drift och granskning

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, regler som är för vida eller regler utan ägare.

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

• Kommer regeln fortfarande att göras?: Oanvända regler kan ofta inaktiveras och tas bort senare.
• Stämmer källan fortfarande?: Klientnätverk, servernätverk och VPN-områden förändras över tiden.
• Är Any fortfarande motiverad?: Breda källor, mål eller Services bör medvetet dokumenteras.
• Är loggning aktiv och användbar?: Utan loggar är efterföljande 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?: I annat fall förblir tillfälliga projekt- eller stödregler 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örsandelar och regler med Any på Services 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.
• Servrar, 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: Avaktivera först och observera. Direkt radering tar bort möjligheten att kontrollera träffar, loggar och beroenden på ett kontrollerat sätt.
• En regel är verkligen överflö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 Rule group. 3. Bestäm om en befintlig regel utökas eller om din egen regel är renare. 4. För produktiva förändringar, planera säkerhetskopiering, revisionsspår och testfall. 5. Efter att ha sparat Log Viewer, Rule ID, kontrollera NAT-beslut och berörda säkerhetsfunktioner.

Om beslutet misslyckas i första hand på grund av bristande dokumentation, bör Sophos Firewall-regler dokumenteras på ett meningsfullt sätt först följas upp. 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 faktiska 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.

Gör ändringar spårbara

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 Check Audit Trail Logs och Sophos Firewall Use 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 en applikation via IPS, webbfiltrering eller TLS Inspection.

Typiska fel

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.

Services är för breda: Any tillåter betydligt mer än nödvändigt. Specifika Services eller servicegrupper ä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.

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

HTTPS skannas inte: Scan HTTP and decrypted HTTPS är aktiv, men det finns ingen lämplig SSL/TLS-inspektionsregel eller dekryptering.

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 passar 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 går annorlunda än förväntat, bör du utföra ytterligare strukturerade tester med Log Viewer, Policy tester och Packet Capture. Lämplig procedur finns i Testa brandväggsregel med Log Viewer, Policy Test och Packet Capture.

Vanliga frågor