Naar de inhoud
Avanet

Begrijp en configureer de Sophos Firewall-regels veilig

Sophos Firewall

Firewallregels vormen de kern van de Sophos Firewall. Deze regels bepalen welk verkeer tussen zones, netwerken, gebruikers en diensten wordt toegestaan ​​of geblokkeerd en welke beveiligingsfuncties worden toegepast.

In dit artikel wordt een Sophos Firewall-regel van boven naar beneden uitgelegd: Volgorde, Groepen, Actie, Logboekregistratie, Bron, Bestemming, Services, Gebruikersmatching, Uitsluitingen, NAT, Webfiltering, TLS Inspection, Security Heartbeat, Application Control, IPS, Verkeersvorming, DSCP, NDR en E-mailscannen.

Het menupad is:

Rules and policies > Firewallregels > Firewallregel toevoegen > Nieuwe firewallregel

Sophos Firewall Voeg een firewallregel toe met alle opties, van regelstatus tot beveiligingsfuncties
Sophos Firewall - Firewallregel toevoegen: De regel wordt van boven naar beneden geconfigureerd en wordt later geëvalueerd op basis van de regelvolgorde.

Het regelmasker is onderverdeeld in verschillende gebieden: headergebied, bron, bestemming, Services, gebruikersreferentie, NAT-koppeling en beveiligingsfuncties. In de praktijk is het belangrijk om het masker niet te zien als een verzameling losse haakjes. Een regel werkt alleen goed als de bron, bestemming, dienst, volgorde, logging en de geactiveerde beveiligingsfuncties overeenkomen.

Voordat u deze maakt, moet ook duidelijk zijn of het een IPv4- of IPv6-regel is. De regelweergave wordt dienovereenkomstig geselecteerd in de WebAdmin. In dual-stack-omgevingen moeten IPv4 en IPv6 opzettelijk afzonderlijk worden gepland en getest; een functionerende IPv4-regel bewijst niet automatisch dat IPv6 even veilig is.

Snelle navigatie

Welk artikel over netwerkbeleid past?

Firewallregels, NAT, WAF, VLAN’s en routing zijn nauw met elkaar verweven in de Sophos Firewall. Het is daarom belangrijk dat beheerders eerst het juiste onderwerp kiezen:

Deze scheiding voorkomt typische probleemoplossing. Een NAT-regel staat geen verkeer toe, een firewallregel vertaalt een adres niet en een WAF-regel is niet hetzelfde als reguliere DNAT-poortdoorschakeling.

Welke firewallregels bepalen en wat niet

Firewallregels regelen het verkeer dat door de firewall stroomt. Maar deze regels zijn niet het enige controlepunt in SFOS. Veel probleemoplossing vindt plaats omdat u zoekt naar gedrag in de lijst met firewallregels, ook al is een ander gebied verantwoordelijk.

  • Verkeer tussen zones, netwerken, gebruikers en diensten: Firewallregels. Hier wordt bepaald of doorgaand verkeer wordt toegestaan, geweigerd of gecontroleerd met veiligheidskenmerken.
  • WebAdmin, User Portal, VPN Portal, SSH, DNS of SNMP naar de firewall zelf: Device Access en Local Service ACL. Lokale firewallservices worden niet behandeld als normaal LAN-naar-WAN- of WAN-naar-DMZ-verkeer.
  • Adres- of poortvertaling: NAT-regels. NAT vertaalt verkeer, maar staat dit niet automatisch toe.
  • Routekeuze, terugreis, SD-WAN- en VPN-paden: Routering, SD-WAN, Route Precedence en VPN configuratie. Een geschikte firewallregel bewijst geen werkende weg terug.
  • Webcategorieën, URL-groepen en webbeleid: Webfiltering en webbeleid. De firewallregel integreert het beleid, maar de eigenlijke weblogica ligt in het webbeleid.
  • HTTPS-decodering: SSL/TLS-inspectieregels en CA-distributie. Scan HTTP and decrypted HTTPS scant alleen verkeer dat al is gedecodeerd.
  • Gebruikersidentiteit: Authenticatie, STAS, Captive Portal, Entra ID SSO of RADIUS. Een gebruikersregel komt alleen overeen als de firewall de gebruiker aan het verkeer kan toewijzen.

Voor beheer- en portaaldiensten is Device Access en Local Service ACL het centrale artikel. Als een regel overeenkomt, maar de verbinding nog steeds mislukt, kunnen Sophos Firewall-regel werkt niet: controleer oorzaken en Test firewallregel met Log Viewer, Policy Test en Packet Capture helpen. Vooral bij gemengde IPv4/IPv6-netwerken moet u ook controleren of een toepassing via IPv6 een strengere IPv4-regel omzeilt. Als IPv6 niet actief wordt gebruikt, moet de IPv6-strategie toch bewust worden gedocumenteerd: deactiveren, blokkeren, goed reguleren of gecontroleerd invoeren.

Basisprincipe en volgorde

Firewallregels regelen het verkeer tussen zones en netwerken. Regels staan ​​verkeer toe, weigeren of blokkeren en kunnen aanvullende beveiligingsfuncties toepassen.

Sophos Firewall controleert firewallregels van boven naar beneden. Zodra een regel overeenkomt, worden daaropvolgende firewallregels niet meer gecontroleerd. Wat belangrijk is, is niet alleen wat er in een regel staat, maar ook waar het in de lijst met regels staat.

Een regel past alleen als alle relevante criteria tegelijkertijd gelden:

  • Bronzone: Ja. LAN.
  • Source networks and devices: Ja. net_LAN_Clients.
  • Schema: Ja. All the time.
  • Bestemmingszone: Ja. WAN.
  • Destination networks: Ja. Any of een FQDN-host.
  • Services: Ja. HTTP, HTTPS, DNS.
  • Gebruikersmatching: Alleen indien geactiveerd. AD-groep Internet-Users.
  • Uitsluitingen: Indien ingesteld, kan de regel worden overgeslagen. Back-upserver uitsluiten.

De eerste matchingregel wint. Als een algemene LAN_to_WAN_Any-regel boven een specifieke LAN_to_WAN_Restricted-regel ligt, wordt de specifieke regel nooit bereikt.

Plan de regelbasis voordat u deze maakt

Er kan snel één enkele firewallregel worden gemaakt. Wat lastiger is, is een regelbasis die na twee jaar nog steeds begrijpelijk, toetsbaar en veilig is. Voordat u nieuwe regels introduceert, moet u daarom eerst verduidelijken tot welke beveiligingszone, groep en bedrijfslogica de regel behoort.

Handige richtvragen:

  • Welk soort verkeer zou eigenlijk moeten worden toegestaan?: Noteer bron, bestemming en Services voordat u deze maakt.
  • Hoort het verkeer in de eigen zone?: Scheid servers, clients, gasten, beheer, VPN en DMZ bewust van elkaar.
  • Is er al een specifieke regel?: Controleer bestaande regels in plaats van een tweede soortgelijke regel te maken.
  • Is NAT erbij betrokken?: Plan firewallregels en NAT-regels samen, maar verwar ze niet.
  • Hoe wordt dit later gecontroleerd?: Activeer logging en definieer specifiek testverkeer.
  • Is de vrijgave tijdelijk?: Documenteer de vervaldatum of het ticket in de beschrijving.

Voor schone zones en interfaces past Sophos Firewall Zones en interfaces configureren als eerste. Als een bestaande regel niet werkt, kan de checklist Sophos Firewall Regel werkt niet: Controleer oorzaken helpen.

⚠️ Een brede Any-regel is vaak handig, maar zelden een goede eindconfiguratie. Het kan op korte termijn helpen bij tests. Het moet dan worden vervangen of weer verwijderd door specifieke bronnen, bestemmingen en diensten.

Scheid regeltypen netjes van elkaar

Een goede rulebase scheidt verschillende risico’s zichtbaar van elkaar. De meest voorkomende fout is niet één onjuiste optie, maar een algemene regel die zowel clients, servers, VPN, gasten en management omvat. Dit werkt in het begin snel, maar wordt later lastig te testen en lastig uit te harden.

  • Klant internet: Typische bron: Klantnetwerken; Typisch doelwit: WAN; Waar moet u op letten?: Webbeleid, Application Control, IPS, TLS Inspection, QUIC, logboekregistratie.
  • Serverinternet: Typische bron: Servernetwerken; Typisch doelwit: gedefinieerde update-, back-up- of clouddoelen; Waar moet u op letten?: strenger dan klantregels, vaak zonder gebruikersreferentie.
  • Gast-WLAN: Typische bron: Gastzone; Typisch doelwit: WAN; Waar moet u op letten?: geen bewuste controle over interne targets, bandbreedte en DNS.
  • Beheer: Typische bron: Beheernetwerken; Typisch doelwit: Firewall, servers, switches, hypervisors; Waar moet u op letten?: meng je niet met normale klantregels.
  • VPN Toegang op afstand: Typische bron: VPN of eigen externe toegangszone; Typisch doelwit: interne doelzones; Waar moet u op letten?: alleen benodigde doelen en diensten, inloggen in de introductiefase.
  • Site naar site: Typische bron: lokale en externe VPN-zones of XFRM-zones; Typisch doelwit: Partner- of locatienetwerken; Waar moet u op letten?: Controleer routing, NAT, retourpad en loggen samen.
  • Gepubliceerd systeem: Typische bron: WAN of gedefinieerde bronnen; Typisch doelwit: DMZ of serverzone; Waar moet u op letten?: DNAT/WAF, IPS, logging, patchniveau en bronbeperking.
  • Tijdelijke toegang: Typische bron: gedefinieerde ondersteunings- of projectbron; Typisch doelwit: smal doel; Waar moet u op letten?: Documentticket, vervaldatum, eigenaar en demontage.

Als twee verbindingen verschillende eigenaren, beveiligingsfuncties of beoordelingscycli hebben, zijn afzonderlijke regels meestal schoner. Indien voor hetzelfde beroepsdoel slechts een aanvullende dienst nodig is, kan een bestaande regel worden uitgebreid.

Fictief praktijkvoorbeeld

Er wordt bijvoorbeeld een schone clientregel gemaakt:

Doel: Clients van de interne LAN hebben toegang tot internet. Webfilter, Application Control, IPS en loggen moeten actief zijn. Servers, gasten en beheernetwerken krijgen hun eigen regels en worden niet gemengd met deze clientregel.

  • Regelnaam: LAN_to_WAN_Clients. Duidelijke naam met bron en bestemming.
  • Beschrijving: Internet Access für Client-Netz, erstellt für Standard-Client-Traffic. Later zul je weten waarom de regel bestaat.
  • Rule position: Onder specifieke blok- en serverregels. Er moeten eerst specifieke regels van kracht worden.
  • Rule group: Internet Access. Beter overzicht.
  • Actie: Accept. Verkeer is toegestaan ​​.
  • Firewallverkeer registreren: Ingeschakeld. Problemen oplossen met de Log Viewer.
  • Source zones: LAN. Verkeer komt uit de zone LAN.
  • Source networks and devices: net_LAN_Clients. Niet alle LAN-netwerken, alleen clients.
  • Tijdens geplande tijd: All the time. Internettoegang moet permanent zijn.
  • Destination zones: WAN. Doel is internet.
  • Destination networks: Any. Vooral praktisch voor internet van klanten.
  • Services: HTTP, HTTPS, DNS, NTP. Alleen noodzakelijke basisvoorzieningen.
  • Web policy: Default Workplace Policy. Beheer webtoegang op basis van categorieën.
  • Block QUIC protocol: Ingeschakeld. Webfiltering en scannen blijven effectief.
  • IPS: Klantbeleid. Exploitbescherming voor uitgaand clientverkeer.
  • App-controle: Beleid voor clientapplicaties. Blokkeer ongewenste apps.
  • Verkeer vormgeven: Optioneel. Alleen als er bandbreedte nodig is.
  • DSCP marking: Leeg. Alleen nodig als downstream-apparaten DSCP.

Dit voorbeeld is bewust geen Any gratis ticket. In de praktijk moeten clientnetwerken, servernetwerken, gastnetwerken, VoIP en beheer afzonderlijk worden beschouwd. Voor de eerste productieve test moet dit voorbeeld een korte testcase bevatten: gedefinieerde client, specifiek doeladres, verwachte Rule ID, verwachte NAT Rule ID en een kijkje in Log Viewer of Central/Syslog. Zonder deze goedkeuringsstap blijft het onduidelijk of de regel daadwerkelijk de verwachte verbinding verwerkt.

Kopgebied: Status, Naam, Actie en Logging

Regelstatus

Regelstatus activeert of deactiveert de regel.

Meestal is er een nieuwe regel actief. Voor voorbereide regels kunt u de status deactiveren en de regel pas later activeren. Gedeactiveerde regels moeten regelmatig worden gecontroleerd, zodat er geen oude test- of migratieregels in de configuratie achterblijven.

Praktijkvoorbeeld: Er wordt een nieuwe regel voor een server voorbereid, maar deze wordt pas geactiveerd in het onderhoudsvenster.

Regelnaam

De naam moet meteen duidelijk maken wat de regel doet.

Goede namen:

  • LAN_to_WAN_Clients
  • Guest_to_WAN_WebOnly
  • Server_to_WAN_Updates
  • VoIP_to_WAN_SIP_RTP
  • WAN_to_DMZ_HTTPS_Webserver

Namen als Rule1, Test, Allow of Internet zijn minder nuttig omdat u niet langer kunt zien welke taak de regel heeft.

Beschrijving

De beschrijving is van belang voor de bedrijfsvoering, ondersteuning en audits. Het zou moeten zeggen:

  • waarom de regel bestaat
  • die de regel heeft aangevraagd
  • welke beperkingen bewust zijn gesteld
  • of er een ticket-, project- of vervaldatum is

Voorbeeld:

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

Hoe u dit veld op de juiste manier gebruikt en de firewallregels op een begrijpelijke manier documenteert, wordt gedetailleerder beschreven in het artikel Sophos Firewall regels verstandig documenteren.

Rule position

Rule position geeft aan waar de nieuwe regel wordt ingevoegd.

  • Top: Alleen voor zeer specifieke regels, blokregels of tests.
  • Bottom: Vaak handig voor nieuwe standaardregels.
  • Above rule: Als een regel specifiek vóór een bestaande regel in werking moet treden.
  • Below rule: Als een regel specifiek een bestaande regel moet volgen.

Basisregel: specifiek vóór algemeen. Een regel voor een individuele server of een specifieke applicatie ligt doorgaans hoger dan een algemene internetregel.

Rule group

Rule group is een organisatiegroep. De groep zelf is geen veiligheidsgrens of zijn eigen beleidsmotor. De firewall blijft elke regel van boven tot onder controleren.

Voorbeelden van nuttige groepen zijn:

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

In kleine omgevingen kan None voldoende zijn. In grotere omgevingen is het in een vroeg stadium duidelijk groeperen de moeite waard, anders wordt de basis van de regels snel verwarrend.

Actie

Actie bepaalt wat er gebeurt met overeenkomend verkeer.

  • Accept: Verkeer is toegestaan ​​. Normale regels voor toestaan ​​.
  • Drop: Verkeer wordt stilzwijgend weggegooid. Blokkeerregels waarbij de cliënt geen reactie mag ontvangen.
  • Reject: Verkeer wordt afgewezen en de client ontvangt een reactie. Probleemoplossing of interne blokkeringsregels.
  • Protect with web server protection: WAF-beveiliging wordt toegepast. Webserverbescherming, niet voor normale LAN-naar-WAN-regels.

Voor normale client- of serverregels gebruikt u meestal Accept. Voor blokregels is Drop stiller, Reject is vaak prettiger voor het oplossen van problemen.

Firewallverkeer registreren

Log firewall verkeer moet bijna altijd worden geactiveerd voor belangrijke regels.

Zonder loggen ontbreekt later belangrijke informatie in de Logviewer. Veel gevallen van probleemoplossing mislukken niet vanwege de regel zelf, maar omdat er geen logboekregistratie heeft plaatsgevonden en het niet mogelijk is om te zien welke regel daadwerkelijk van toepassing is.

Belangrijk: De firewall registreert doorgaans firewallsessies wanneer een verbinding wordt verbroken en er een Destroy-gebeurtenis plaatsvindt. Niet elke verbinding verschijnt precies op het moment dat de client deze start.

Om logs lokaal zichtbaar te maken, in Sophos Central of via Syslog, moet ook System services > Log settings correct worden geconfigureerd. Voor langere opslag is Sophos Central Firewall Reporting of een Syslog-server zinvol. Meer hierover: Centrale firewallrapportage inschakelen en Sophos Firewall Syslog veilig naar SIEM verzenden.

Voor productieve regels moet loggen niet alleen worden gezien als een manier om problemen op te lossen. Het is ook de basis voor reviews: wordt de regel nog gebruikt, op welke bronnen zijn ze van toepassing, welke doelen worden er echt aangesproken en of een regel te breed is?

Bron, Zone en Schema

In het gebied Bron definieert u waar het verkeer vandaan komt.

Source zones

Source zones is de zone waar het verkeer vandaan komt.

Voorbeelden:

  • LAN voor interne clientnetwerken
  • VPN voor gebruikers met externe toegang
  • DMZ voor servernetwerken
  • Guest voor gasten-WLAN
  • WAN voor inkomend internetverkeer

Praktijkvoorbeeld: LAN is geselecteerd voor een internetregel van clients naar internet. Voor een DNAT-regel van een externe naar een interne server wordt WAN doorgaans gebruikt als bronzone in de bijbehorende firewallregel.

Source networks and devices

Source networks and devices beperkt de bron nauwkeuriger.

Mogelijke objecten zijn bijvoorbeeld:

  • individuele gastheren
  • Netwerken
  • IP-bereiken
  • Gastgroepen
  • FQDN-hosts
  • Landobjecten

Om te beginnen lijkt de Any comfortabel, maar is hij vaak te breed. Een specifiek clientnetwerk, een hostgroep of een duidelijk benoemd netwerkobject is beter.

Praktisch voorbeeld: Gebruik in plaats van Any in de broncode net_LAN_Clients. Servers, printers, gasten en beheerapparaten krijgen hun eigen regels.

Tijdens geplande tijd

Gedurende de geplande tijd bepaalt wanneer de regel van toepassing is.

Typische waarden:

  • All the time
  • Werktijden
  • Onderhoudsvenster
  • tijdelijke releases

Schema’s zijn handig als toegang alleen op bepaalde tijden mag worden toegestaan. Bij het oplossen van problemen moet u altijd controleren of de firewalltijd, tijdzone en planning echt kloppen.

Praktijkvoorbeeld: Externe onderhoudstoegang tot een server is alleen toegestaan ​​tijdens een gedefinieerd onderhoudsvenster.

Bestemming en diensten

In het gebied Bestemming en services definieert u waar het verkeer is toegestaan en welke poorten of protocollen zijn toegestaan.

Destination zones

Destination zones is de doelzone.

Voorbeelden:

  • WAN voor internettoegang
  • DMZ voor servers in een DMZ
  • LAN voor interne doelen
  • VPN voor externe gebruikers of site-to-site-routes

Praktijkvoorbeeld: WAN wordt gebruikt voor internetverkeer van klanten. Server of DMZ kunnen worden gebruikt voor clients om toegang te krijgen tot een interne server als deze zones dienovereenkomstig zijn aangemaakt.

Destination networks

Destination networks verkleint het doel nauwkeuriger. Voor internetregels voor klanten is Any vaak een haalbaar begin. Voor servers, beheernetwerken of VPN-toegang moeten de doelen aanzienlijk meer worden beperkt.

Voorbeelden:

  • Any voor algemene internettoegang
  • FQDN-host zoals updates.vendor.com
  • Hostobject van een interne server
  • Netwerkobject van een extern station via VPN
  • Landobject voor Geo-IP-regels

Praktisch voorbeeld: Een back-upserver mag alleen naar de cloudback-upbestemmingen van de fabrikant gaan, niet naar Any.

Services

Services zijn protocol- en poortdefinities.

Voorbeelden:

  • HTTP voor TCP 80
  • HTTPS voor TCP 443
  • DNS voor TCP/UDP 53
  • NTP voor UDP 123
  • eigen Services zoals Synology_5555

Services moet zo beperkt mogelijk worden gekozen. Any heeft alleen zin als alle protocollen echt moeten worden toegestaan ​​of als je bewust met andere besturingen werkt.

Praktijkvoorbeeld: Voor normale webclients is een groep met HTTP, HTTPS, DNS en NTP vaak voldoende. Voor servertoegang vanaf internet is alleen de daadwerkelijk gepubliceerde dienst toegestaan.

Match known users

Met Match known users wordt de gebruikersidentiteit onderdeel van de matching. De regel geldt dan niet meer alleen voor IP-adressen, maar voor bekende gebruikers of groepen.

Dit is zinvol als:

  • Webbeleid moet gelden per AD-groep
  • Rapportage moet gebruikersgerelateerd zijn
  • verschillende gebruikersgroepen krijgen verschillende internetrechten
  • MFA, Captive Portal of SSO zijn al correct ingesteld

Struikelblok: Als de authenticatie niet goed werkt, komt de regel mogelijk niet overeen. Vervolgens daalt het verkeer naar een meer algemene regel hieronder of wordt het verwijderd door de drop-all-regel.

Voor eerste tests is het vaak beter om te beginnen zonder gebruikersmatching en later gebruikerscriteria toe te voegen.

Als gebruikersmatching wordt gebruikt, mag er geen brede fallback-regel zijn die hetzelfde verkeer toestaat zonder gebruikersreferentie. Anders lijkt de gebruikersregel schoon, maar onbekende gebruikers blijven toch bij de algemene regel. Bij acceptatie moet de Log Viewer daarom de gebruiker, groep en Rule ID tonen.

Uitsluiting toevoegen

Met Exclusief toevoegen kan verkeer worden uitgesloten van een regel. De firewall slaat deze regel alleen over als alle uitsluitingscriteria overeenkomen en controleert vervolgens de volgende regel.

Uitsluitingen kunnen Source zones, Source networks and devices, Destination zones, Destination networks en Services zijn.

Praktisch voorbeeld: een algemene internetregel voor clients maakt gebruik van webfilters. Een specifieke updateserver moet echter zijn eigen regel met andere beveiligingsfuncties uitvoeren. Dan kunt u deze server uitsluiten van de algemene regel.

Uitsluitingen zijn krachtig, maar ze maken regels moeilijker leesbaar. Als een regel veel uitzonderingen bevat, is een aparte specifieke regel vaak begrijpelijker.

Create linked NAT rule

Met Create linked NAT rule kan rechtstreeks vanuit de firewallregel een bron-NAT-regel worden gemaakt. Deze gekoppelde NAT-regel verschijnt vervolgens in de NAT-regeltabel.

Dit klinkt handig voor beginners, maar in de praktijk zijn onafhankelijke NAT-regels meestal duidelijker. Als een generieke NAT-regel al hetzelfde verkeer dekt, moet u geen extra gekoppelde NAT-regel maken.

Voor een normale client-naar-internetregel is de standaard SNAT-regel met MASQ doorgaans voldoende, zolang deze actief is en correct aansluit bij de regelsbasis. Belangrijk: NAT staat op zichzelf geen verkeer toe. NAT vertaalt adressen of poorten. De juiste firewallregel bepaalt nog steeds of verkeer is toegestaan.

Meer hierover: NAT begrijpen op Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Webfiltering

In het gebied Webfiltering worden het webbeleid, de malwarescan en het webfiltergedrag geconfigureerd.

Web policy

Web policy regelt de webtoegang via categorieën, gebruikers, groepen, URL-groepen en regels.

Praktijkvoorbeeld: Voor clients wordt een webbeleid gebruikt dat malware, phishing, inhoud voor volwassenen en risicovolle categorieën blokkeert, maar zakelijke toepassingen toestaat.

Als er geen webbeleid is ingesteld, vindt via deze optie geen categoriegebaseerde webfiltering plaats.

Hoe u categorieën, URL-groepen, webbeleid en directe waarschuwingen samen plant, wordt beschreven in Sophos Firewall Webcategorieën en directe waarschuwingen gebruiken.

Pas op webcategorieën gebaseerde verkeersvorming toe

Deze optie past traffic shaping toe op basis van webcategorieën. Het heeft alleen zin als de juiste verkeersvormende regels of webcategoriebeleid worden gebruikt.

Praktijkvoorbeeld: Streamingcategorieën zijn beperkt, zakelijke toepassingen blijven de voorkeur genieten.

Block QUIC protocol

QUIC maakt gebruik van UDP 80 en UDP 443. Veel browsers gebruiken QUIC voor Google-services en andere moderne webapplicaties.

Als webfiltering of malwarescans voor webverkeer belangrijk zijn, moet Block QUIC protocol in veel omgevingen ingeschakeld blijven. Browsers vallen dan meestal terug naar normale HTTPS via TCP, wat gemakkelijker te controleren en te controleren is.

Meer hierover: Sophos Firewall QUIC en HTTP/3 correct blokkeren.

Scan HTTP and decrypted HTTPS

Deze optie scant HTTP en reeds gedecodeerde HTTPS op malware.

Belangrijk: Deze optie decodeert HTTPS niet automatisch. Om HTTPS echt te kunnen controleren, zijn de juiste SSL/TLS-inspectieregels vereist onder Rules and policies > SSL/TLS-inspectieregels.

Praktisch voorbeeld: Als TLS Inspection actief is voor LAN_to_WAN_Clients, kan Scan HTTP and decrypted HTTPS gedownloade bestanden controleren in gedecodeerd HTTPS-verkeer.

Meer hierover: TLS Inspection geleidelijk uitrollen naar Sophos Firewall.

Gebruik zero-day-bescherming

Gebruik Zero-day-bescherming stuurt verdachte downloads naar Sophos Zero-Day Protection voor verdere analyse. Dit is handig voor client- en serverregels die downloads van internet willen controleren.

De functie vereist een geschikte licentie en kan afhankelijk van het bestandstype en beleid tot vertragingen leiden.

FTP scannen op malware

Deze optie scant FTP-verkeer op malware. Het is alleen relevant als FTP daadwerkelijk wordt gebruikt en de bijbehorende Services doorgaans is toegestaan.

FTP is minder gebruikelijk geworden in moderne omgevingen, maar komt nog steeds voor in oudere systemen, machinebesturingen of oudere updatemechanismen.

Gebruik webproxy in plaats van DPI engine

Sophos Firewall kan webverkeer controleren via DPI engine of via Web Proxy.

Voor moderne instellingen is DPI meestal de betere standaardkeuze, omdat het HTTP- en SSL/TLS-verkeer op alle poorten kan verwerken. De webproxy is nog steeds nuttig als speciale proxyfuncties vereist zijn, bijvoorbeeld SafeSearch-handhaving, YouTube-beperkingen, Google-app-domeinbeperkingen, pharming-bescherming, webcache of bovenliggende proxy.

Als Gebruik webproxy in plaats van DPI engine niet is ingeschakeld, werkt de regel in de DPI-modus.

HTTPS decoderen tijdens webproxyfiltering

Deze optie behoort tot de webproxymodus. Dit is alleen relevant als Gebruik webproxy in plaats van DPI engine is geactiveerd en HTTPS moet worden gedecodeerd in de proxymodus.

In de DPI-modus wordt de HTTPS-decodering hier niet beheerd, maar via SSL/TLS-inspectieregels.

Synchronized Security Hartslag

Met Configureer Synchronized Security Heartbeat kan de Sophos Endpoint-status worden opgenomen in de firewallregel.

Typische opties:

  • Stel de minimale status in voor bronapparaten
  • Blokkeer klanten zonder hartslag
  • Stel de minimale status in voor doelapparaten
  • Blokkeer verzoeken naar bestemmingen zonder hartslag

Dit is sterk, maar heeft alleen zin als Sophos Endpoint, Sophos Central en Security Heartbeat correct zijn ingesteld.

Praktijkvoorbeeld: Clients met rode Security Heartbeat hebben geen toegang meer tot servers of hebben geen internettoegang meer.

Voor een eerste clientregel geldt dat u de hartslag niet blindelings moet activeren, anders blokkeert u mogelijk apparaten die helemaal geen hartslag kunnen verzenden.

Andere beveiligingsfuncties

Applicaties identificeren en beheren (App-controle)

Via Applicaties identificeren en beheren (App-beheer) wordt een applicatiefilterbeleid geselecteerd.

Hierdoor kunnen applicaties worden herkend en gecontroleerd, bijvoorbeeld:

  • Teamviewer
  • Poort
  • Boodschappers
  • Streamen
  • Cloudopslag
  • Gereedschappen voor afstandsbediening

Voor Application Control is een geschikte licentie vereist. In de praktijk is deze feature opgenomen in de Sophos Firewall bundels met Web Protection, bijvoorbeeld Standard Protection, Xstream Protection of Epic Protection.

TLS Inspection is vaak cruciaal voor applicatiedetectie in gecodeerd verkeer. Zonder decodering ziet de firewall, afhankelijk van de service, alleen hostnamen, SNI, certificaatinformatie of IP’s en niet de volledige inhoud.

Het aangepaste proces voor filters, regelbinding, logboeken en fout-positieve controle is beschikbaar in Sophos Firewall Application Control instellen en testen.

Apply application-based traffic shaping policy

Deze optie past verkeersvorming toe die is gedefinieerd in het toepassingsbeleid of het toepassingsobject.

Praktisch voorbeeld: Microsoft Teams moet worden erkend en geprioriteerd met een specifiek verkeersvormingsbeleid. Vervolgens moet het juiste Application Control-beleid worden geselecteerd en moet het applicatiegebaseerde verkeersvormingsbeleid worden toegepast.

Als u al een expliciet beleid voor verkeersvorming heeft ingesteld in het veld Vormverkeer, moet duidelijk worden gedocumenteerd welk beleid voorrang moet hebben en waarom.

Detecteer en voorkom exploits (IPS)

Er is een IPS-beleid geselecteerd onder Exploits detecteren en voorkomen (IPS).

IPS controleert het verkeer op bekende aanvalspatronen en exploits. Voor clientverkeer naar internet wordt een ander beleid gebruikt dan voor serververkeer of gepubliceerde services.

Praktische voorbeelden:

  • Clientregel LAN_to_WAN: Client- of LAN naar WAN IPS-beleid
  • DNAT-regel naar webserver: IPS-beleid van server of webserver
  • VoIP-regel: test zorgvuldig, want agressieve IPS-profielen kunnen VoIP verstoren

IPS moet niet zomaar overal met het strengste beleid worden geactiveerd. Een IPS-beleid dat te breed of onjuist is, kan legitiem verkeer verstoren of onnodige belasting veroorzaken.

In het speciale artikel Sophos Firewall IPS instellen en veilig testen wordt de globale activering, licentiestatus, beleidsselectie, logboekregistratie en fout-positieve analyse gedetailleerder uitgelegd.

Verkeer vormgeven

Met Shape traffic kan een traffic shaping-beleid rechtstreeks op de regel worden toegepast. Dit is relevant voor:

  • VoIP
  • Onlinevergaderingen
  • Back-upverkeer
  • Gast WLAN
  • langzame WAN-routes

Praktisch voorbeeld: Gast WLAN krijgt een limietbeleid zodat het zakelijk verkeer niet wordt verdrongen.

Meer hierover: Configureer Application Traffic Shaping op Sophos Firewall.

DSCP marking

DSCP marking markeert pakketten voor servicekwaliteit op downstream-netwerkapparaten.

Dit heeft alleen zin als switches, routers of WAN-apparaten deze DSCP-waarden ook evalueren. De Sophos Firewall kan markeringen aanbrengen, maar de rest van het netwerk moet deze markeringen consistent behandelen.

Praktijkvoorbeeld: VoIP-verkeer krijgt een DSCP-markering zodat switches en WAN-routers dit verkeer bij voorkeur behandelen.

Scannen met NDR Actieve bedreigingsinformatie

Scannen met NDR Actieve bedreigingsinformatie maakt gebruik van Sophos NDR Bedreigingsinformatie om het netwerkverkeer aanvullend te beoordelen.

Deze optie is alleen nuttig als de omgeving de vereiste componenten Sophos Central en NDR gebruikt. In veel omgevingen is dit niet de eerste optie voor een basisregel, maar het kan een waardevolle toevoeging zijn in beter bewaakte netwerken.

E-mailinhoud scannen

Het gebied E-mailinhoud scannen heeft betrekking op e-mailprotocollen.

Mogelijke opties:

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

Als u daar protocollen activeert, moeten de betreffende standaardpoorten ook in de Services van de regel worden opgenomen of via Poorten toevoegen worden toegevoegd.

Dit gebied is vaak niet relevant voor normale webclientregels. U moet dit bewust plannen voor mailservers of client-mailverkeer.

Praktijkvoorbeeld: Een interne mailserver mag extern SMTP versturen. Vervolgens wordt er een aparte serverregel aangemaakt, wordt loggen geactiveerd en wordt het scannen van e-mail gecontroleerd op afstemming met de mailarchitectuur.

Controleer na het opslaan

Na het opslaan moet u de regel testen en er niet zomaar vanuit gaan dat alles correct werkt.

Om te controleren:

  1. Staat de meetlat in de juiste positie?
  2. Is Firewallverkeer loggen actief?
  3. Toen de regels veranderden, werd de hitteller gereset of werd er een duidelijke nieuwe test gemaakt?
  4. Komt de regel overeen in de Logviewer?
  5. Verschijnt de verwachte firewall Rule ID?
  6. Geldt de gewenste NAT-regel?
  7. Werkt DNS?
  8. Worden webfilters, IPS, Application Control en TLS Inspection toegepast zoals verwacht?
  9. Zijn er onverwachte problemen of SSL/TLS-fouten?

Het artikel De firewallregel testen met Log Viewer, Policy Test en Packet Capture helpt bij een schone controle.

Bij het maken van productieve veranderingen is een kleine vergelijking vóór en na zinvol:

  • Er bestaat een back-up- of herstelpunt: Ontmanteling blijft mogelijk als de regel bijwerkingen oplevert.
  • Audittrail of wijzigingsticket genoteerd: later zal duidelijk worden wie de wijziging heeft doorgevoerd en wanneer.
  • Testcase vooraf gedefinieerd: Succes wordt niet alleen op gevoel beoordeeld.
  • Slechts één wijziging per test: Oorzaak en gevolg blijven begrijpelijk.
  • Log Viewer of centrale logboeken gecontroleerd: de echte Rule ID en NAT ID zijn zichtbaar.
  • Ontmantelingsbesluit gedocumenteerd: tijdelijke testregels blijven niet permanent actief.

Als u meerdere firewalls of centraal beheerde groepen heeft, controleer dan ook of de wijziging het juiste apparaat of de juiste groep heeft bereikt. Voor Sophos Central helpt de Firewall Management Task Queue; lokale wijzigingen kunnen worden gevolgd met Audit Trail Logs.

Regelmatig gebruik en beoordeling

Een firewallregel is niet gereed alleen maar omdat deze is opgeslagen. Goede regels hebben een duidelijk doel, worden vastgelegd, zijn toetsbaar en kunnen later opnieuw worden gecontroleerd. Vooral in volwassen omgevingen komen veel risico’s niet voort uit één enkele onjuiste regel, maar uit oude uitzonderingen, te brede regels of regels zonder eigenaar.

Een eenvoudige routine is de moeite waard voor regelmatige beoordelingen:

  • Zal de regel nog worden gemaakt?: Ongebruikte regels kunnen vaak later worden uitgeschakeld en verwijderd.
  • Klopt de bron nog?: Clientnetwerken, servernetwerken en VPN-gebieden veranderen in de loop van de tijd.
  • Is Any nog steeds gerechtvaardigd?: Brede bronnen, doelen of Services moeten doelbewust worden gedocumenteerd.
  • Is loggen actief en nuttig?: Zonder logs zijn daaropvolgende analyses en audits aanzienlijk zwakker.
  • Passen NAT, webfilter, IPS en TLS Inspection nog?: Beveiligingsfuncties kunnen anders werken na upgrades, app-wijzigingen of certificaatwijzigingen.
  • Is er een vervaldatum?: Anders blijven tijdelijke project- of ondersteuningsregels permanent actief.

Voor kritische regels moet u ook documenteren wie technisch verantwoordelijk is. Dit is met name belangrijk voor gepubliceerde services, VPN-regels, beheertoegang, gedeelde dienstenproviders en regels met Any op Services of bestemming.

Nieuwe regel, bestaande regel wijzigen of deactiveren?

Niet elk nieuw verzoek heeft onmiddellijk een nieuwe firewallregel nodig. Te veel vergelijkbare regels maken de lijst verwarrend, maar regels die te samengevat zijn, worden snel te breed. Een eenvoudige beslissing helpt voordat u iets opslaat in de WebAdmin:

  • Dezelfde bron, dezelfde bestemming, hetzelfde doel, slechts één extra dienst: Bestaande regel uitbreiden. De regel blijft technisch coherent en gemakkelijker te testen.
  • Dezelfde netwerken, maar verschillende beschermingseisen, verschillende houtkap of andere eigenaar: Maak uw eigen regel. Webfilters, IPS, TLS Inspection, NDR of logging kunnen afzonderlijk worden gecontroleerd.
  • Tijdelijke dienstverlener of ondersteuningstoegang: Creëer uw eigen tijdelijke regel. Eigenaar, ticket, vervaldatum en testvenster blijven duidelijk zichtbaar.
  • Servers, gasten, VoIP, IoT of management worden getroffen: Controleer uw eigen regel of zone. Verschillende risico’s mogen niet verdwijnen in één internetregel voor klanten.
  • Een regel is onduidelijk of oud: Deactiveer eerst en observeer. Directe verwijdering neemt de mogelijkheid weg om hits, logs en afhankelijkheden op een gecontroleerde manier te controleren.
  • Een regel is na een review zeker overbodig: Verwijderen na back-up en documentatie. De set regels wordt kleiner zonder blind functionerende afhankelijkheden te doorbreken.

Voor normale operationele veranderingen is dit proces robuust:1. Noteer het doel, de eigenaar, het ticket en het verwachte verkeer. 2. Controleer bestaande regels voor dezelfde bron, bestemming, service en Rule group. 3. Bepaal of een bestaande regel wordt uitgebreid of dat uw eigen regel schoner is. 4. Plan voor productieve wijzigingen een back-up, audittrail en testcase. 5. Controleer na het opslaan van Log Viewer, Rule ID de NAT-beslissing en de betreffende beveiligingsfuncties.

Als de beslissing voornamelijk mislukt vanwege een gebrek aan documentatie, moeten Sophos Firewall-regels op zinvolle wijze worden gedocumenteerd eerst worden opgevolgd. Als het onduidelijk is of een bestaande regel nog nodig is, helpt een gecontroleerde test met Test firewallregel met Log Viewer, Policy Test en Packet Capture.

Rangschik de treffertellers correct

Hittellers helpen bij het opruimen, maar zijn geen volledig bewijs. Een zelden gebruikte noodregel kan toch belangrijk zijn. Omgekeerd kan een brede regel veel treffers hebben, ook al staat deze te veel toe.

Voor beoordelingen moet u hitcounters altijd combineren met Log Viewer, regelbeschrijving en feitelijk gebruik. Als een regel onduidelijk is, mag deze niet onmiddellijk worden verwijderd. Een gecontroleerd proces is beter: verduidelijk het doel, activeer logging, definieer testvensters, informeer belanghebbenden en deactiveer of verwijder het pas daarna.

Maak wijzigingen traceerbaar

Er moet een back-up beschikbaar zijn vóór grote regelwijzigingen. Audit Trail en Config Studio helpen vervolgens om verschillen op een begrijpelijke manier te controleren. Het praktische proces vindt u in Sophos Firewall Audit Trail-logboeken controleren en Sophos Firewall Config Studio gebruiken.

Als er veel regels worden aangepast, moet je niet alleen de configuratie vergelijken, maar ook echte testcases draaien. Een regel kan syntactisch correct zijn en toch onjuist verkeer toestaan, het verkeerde NAT-pad gebruiken of een applicatie verstoren via IPS, webfiltering of TLS Inspection.

Typische fouten

De regel gaat te ver: Een algemenere regel hierboven stemt eerst overeen met het verkeer.

Bron is te breed: Any werkt, maar maakt regels onduidelijk en vergroot het aanvalsoppervlak.

Bestemming is te breed: Servers of beheernetwerken mogen zelden toegang krijgen tot internet met Any.

Services zijn te breed: Any laat aanzienlijk meer toe dan nodig is. Specifieke Services- of servicegroepen zijn beter.

Loggen is niet actief: De belangrijkste informatie ontbreekt dan in de Log Viewer.

IPv6 vergeten: IPv4 is goed geregeld, maar IPv6 draait op andere regels of blijft onbewust open.

Rule group is zeker in de war: Een regelgroep verbetert alleen het overzicht. Een regelgroep is niet zijn eigen beveiligingsgrens en verandert niets aan de evaluatielogica.

HTTPS wordt niet gescand: Scan HTTP and decrypted HTTPS is actief, maar er is geen geschikte SSL/TLS-inspectieregel of decodering.

Webfilter werkt niet: Geen webbeleid ingesteld, verkeerde gebruiker, verkeerde bronzone of QUIC niet geblokkeerd.

Gebruikersmatching werkt niet: Authenticatie, AD SSO, captive portal of gebruikerstoewijzing werken niet correct.

NAT ontbreekt: De firewallregel staat verkeer toe, maar SNAT/MASQ past niet.

Beveiligingsfunctie komt niet overeen met verkeer: Een onjuist IPS-beleid, proxy-optie of optie voor het scannen van e-mail kan legitiem verkeer onderbreken. Mocht het na deze punten onduidelijk blijven waarom het verkeer anders loopt dan verwacht, voer dan verder gestructureerd testen uit met Log Viewer, Policy tester en Packet Capture. De juiste procedure vindt u in Test firewallregel met Log Viewer, Policy Test en Packet Capture.

Veelgestelde vragen

In welke volgorde controleert Sophos Firewall de firewallregels?

Sophos Firewall controleert regels van boven naar beneden. De eerste matchingregel wint. Daarom moeten specifieke regels, blokregels en speciale gevallen vóór algemene regels komen.

Moet u Any in de Sophos-firewallregels gebruiken?

Any kan handig zijn voor testen of zeer algemene internetregels, maar moet bewust worden gerechtvaardigd. Voor servers, beheer, VPN, toegang tot serviceproviders en kritieke netwerken, concrete bronnen, doelen en Services zijn aanzienlijk beter.

Heeft u eigen Sophos firewallregels voor IPv6 nodig?

Ja. IPv4- en IPv6-regels worden afzonderlijk behandeld. In dual-stack-omgevingen moet IPv6 doelbewust worden toegestaan, geblokkeerd of op een gecontroleerde manier worden geïntroduceerd. Anders kan een goed verscherpte IPv4-regelbasis worden omzeild door genegeerd IPv6-verkeer.

Waarom zie ik geen toegestane verbinding in de logviewer?

Vaak is Logboekfirewallverkeer meestal niet actief of is het juiste logtype niet geactiveerd voor lokale logbestanden, Sophos Central of Syslog onder System services > Log settings. Bovendien verschijnen sommige sessies pas als logvermelding wanneer de verbinding wordt verbroken.

Vervangt een firewallregel een NAT-regel?

Nee. De firewallregel bepaalt of verkeer wordt toegestaan of geblokkeerd. NAT vertaalt adressen of poorten. Voor internettoegang, DNAT en VPN moeten de firewallregel en de NAT-regel overeenkomen.

Hebben firewallregels ook controle over WebAdmin, SSH of VPN Portal?

Niet zoals normaal doorgaand verkeer. De toegang tot lokale firewallservices wordt voornamelijk beheerd via Device Access en Local Service ACL. Normale firewallregels zijn verantwoordelijk voor verkeer via de firewall.

Hoe test je een Sophos Firewall-regel op een schone manier?

Definieer eerst een concreet testgeval: bron, doel, service, verwachte regel en verwachte NAT-beslissing. Gebruik dan Log Viewer, Policy tester en eventueel Packet Capture. Voor complexe gevallen dient u de hittellers opnieuw in te stellen of een duidelijk testvenster te gebruiken.

Moeten onduidelijke firewallregels onmiddellijk worden verwijderd?

Nee. Onduidelijke productieregels moeten eerst op een gecontroleerde manier worden gedocumenteerd, geregistreerd en gedeactiveerd. Alleen als het doel, de eigenaar, de hits en de logs zijn gecontroleerd, heeft verwijdering zin.