Sophos Firewall v23: overzicht en nieuwe functies

Sophos Firewall v23 pakt verschillende taken aan die in het dagelijks beheer veel tijd kosten: regels doorzoeken, gebruikers correct identificeren, updates plannen en achterhalen waarom een cluster is overgeschakeld. Deze nieuwe hoofdversie brengt daarvoor een REST API, een AI-assistent en uitbreidingen voor WAF, DNS en DHCP.

Opmerking over de releasestatus: Net als in voorgaande jaren begint de volgende hoofdversie met een Early Access-fase voor Sophos Firewall v23 rond oktober, dit jaar al op 28 september 2026. Dit artikel is gebaseerd op EAP1. Tot de definitieve versie kunnen afzonderlijke functies en details nog veranderen.

Een deel van de vernieuwingen is direct op de firewall beschikbaar; voor andere functies zijn Sophos Fusion of extra software nodig. Voor de planning is vooral dit belangrijk: de nieuwe gebruikersherkenning via Synchronized Security vereist Sophos Endpoint op de betreffende apparaten en een geschikte Endpoint-licentie. Wie tot nu toe alleen Microsoft Defender of een andere endpointbeveiliging gebruikt, krijgt die functie dus niet door uitsluitend de firewall bij te werken. Sophos Endpoint zou dan aanvullend moeten worden ingevoerd en gelicentieerd. Bij al aanwezige Sophos-licenties hangt de extra inspanning af van het bestaande contract. De voorwaarden voor de overige functies leggen we in de betreffende hoofdstukken uit.

AI en automatisering

REST API: de firewallconfiguratie automatiseren

Met de nieuwe REST API kunnen scripts en beheertools de configuratie rechtstreeks op de firewall lezen en wijzigen. Aanmelden gebeurt met API-sleutels. Een beschrijving in OpenAPI 3.0-formaat documenteert de beschikbare aanroepen en gegevensvelden, zodat de interface eenvoudiger in bestaande tools kan worden geïntegreerd. De toegang verloopt via de firewall zelf en staat los van de Sophos Central API voor het exporteren en importeren van configuraties.

Gemeenschappelijke instellingen naar meerdere firewalls distribueren was al een centraal idee achter Sophos Central Firewall Management. Met firewallgroepen en overkoepelende beleidsregels zouden zulke wijzigingen centraal beheerd kunnen worden. In onze praktijk werkt dat echter slechts gedeeltelijk zo betrouwbaar als we voor de bedrijfsvoering nodig hebben. Bij terugkerende wijzigingen vertrouwen we daarom liever op eigen scripts en processen, waarvan we de uitvoering en het resultaat zelf kunnen controleren. Juist daarvoor is de nieuwe REST API een nuttige aanvulling.

Een voorbeeld zijn netwerkobjecten voor een nieuwe server die op de firewalls van meerdere vestigingen nodig zijn. Een script kan eerst nagaan of het object al bestaat, alleen de noodzakelijke wijziging uitvoeren en vervolgens de opgeslagen waarde opnieuw uitlezen. Uit het logboek blijkt welke firewall succesvol is bijgewerkt en waar nog werk nodig is. Dat is bijzonder nuttig als een vestiging tijdens de wijziging niet bereikbaar is en later gericht kan worden bijgewerkt.

API-sleutels worden beheerd onder Administration > API access. Ze nemen de rechten over van de bijbehorende beheerder. Voor automatiseringen is daarom een apart account met een passend rechtenprofiel aan te raden. Ook de toegestane bronadressen en de beheertoegang moeten correct zijn ingesteld. Beperk de toegang tot systemen die deze werkelijk nodig hebben voor hun beheertaken.

Allowed IP hosts: ook in v23 kunnen hier alleen IP-adressen of netwerken worden toegestaan. Een FQDN, dus een volledige DNS-naam, is nog steeds niet mogelijk. Voor een automatiseringsserver met een vast uitgaand IP-adres is dat geen probleem. Draait het script echter achter een verbinding met een wisselend openbaar IP-adres, dan kan de DNS-naam niet eenvoudig als toegestane bron worden opgegeven. Daarvoor is bijvoorbeeld een vast uitgangspunt of een gecontroleerde VPN-verbinding nodig. Juist bij een interface die automatisering moet vergemakkelijken, hadden we meer flexibiliteit gewenst.

De REST API guide is in de WebAdmin-interface te openen onder Administration > API access. De link staat rechts boven de lijst met API-sleutels, direct naast OpenAPI.yaml. De publieke Sophos Firewall API Reference beschrijft de endpoints, gegevensvelden en de eerste stappen voor authenticatie. Voor de concrete implementatie is het OpenAPI-bestand van de geïnstalleerde firewallbuild bepalend. Voordat bestaande XML-automatiseringen worden vervangen, moet worden nagegaan of alle benodigde functies worden ondersteund. Foutafhandeling, logging en een geteste terugvalprocedure blijven ook bij een moderne API noodzakelijk.

AI-assistent voor firewallregels

De nieuwe assistent in Sophos Fusion beantwoordt vragen over firewallregels. Hij plaatst conceptregels uitgeschakeld aan het einde van de tabel; het vrijgeven ervan blijft de taak van de beheerder.

Dat is een zinvolle manier om met AI samen te werken. Een verzoek als ‘Maak een concept voor HTTPS-toegang van het medewerkersnetwerk tot de interne webserver’ kan voorbereidend werk uit handen nemen. Voor activering moet nog steeds duidelijk zijn welke concrete objecten bedoeld zijn, of gebruikers beperkt moeten worden en welke beveiligingscontroles erbij horen.

Vooral de plaats van de regel is belangrijk. Een inhoudelijk correcte toestemmingsregel kan zonder effect blijven als een andere regel eerder van toepassing is. Omgekeerd kan een te hoog geplaatste regel meer verkeer toestaan dan bedoeld. De assistent neemt de beveiligingsbeslissing dus niet over. Zijn waarde ligt in de voorbereiding van het regelbeheer en in het sneller vinden van samenhangen.

AI-diensten gericht toestaan of blokkeren

Voor de controle van AI-gebruik komen de webcategorie Generative AI en applicatiefilters binnen Sophos AI Defense beschikbaar.

Onder Diagnostics > URL category lookup kan de classificatie van een domein worden opgezocht. Bij openai.com toont de firewall de categorie Generative AI. Dat helpt bij probleemoplossing: wordt een AI-dienst onverwacht geblokkeerd, dan kan eerst de categorie worden gecontroleerd en daarna het toepasselijke webbeleid.

Voor bedrijven begint een zinvolle configuratie met een eenvoudige beslissing: welke AI-diensten zijn voor welk werk toegestaan? Een ontwikkelafdeling heeft mogelijk andere tools nodig dan de boekhouding. Pas daarna kan een bruikbaar netwerkbeleid worden opgesteld.

Dat een domein is toegestaan, zegt echter niets over welke informatie daar mag worden ingevoerd. Toegangscontrole en gegevensbescherming zijn verschillende taken. Ook bij een toegestane dienst zijn regels nodig voor klantgegevens, broncode en vertrouwelijke documenten. Netwerkfilters kunnen zulke organisatorische regels ondersteunen, maar vervangen geen inhoudelijke beoordeling van iedere prompt.

Regelbeheer en bediening

Nieuwe tabel voor firewallregels

De weergave onder Rules and policies > Firewall rules is ingrijpend vernieuwd. In plaats van uitklapbare mappen staan de regels nu in één doorlopende tabel. De groepering blijft behouden, maar wordt in de kolom Group weergegeven. Daarnaast zijn er een vrije tekstzoekfunctie, filters en een aanpasbare kolomweergave.

Daarmee verdwijnt een ergernis van de oude interface: na het bewerken en opslaan van een firewallregel klapte de groep weer dicht. Wie daarna een volgende regel uit dezelfde groep wilde bewerken, moest de map opnieuw openen. Bij meerdere wijzigingen achter elkaar was dat onnodig omslachtig. Doordat de groep nu in een kolom staat, vervalt dat telkens opnieuw uitklappen.

Kolommen kiezen en ordenen

Via het tandwiel rechts boven de tabel kan worden ingesteld welke kolommen zichtbaar zijn. Overbodige gegevens kunnen worden verborgen, extra details worden getoond en de volgorde van de kolommen kan worden gewijzigd. Kolommen kunnen bovendien worden vastgezet. Zo blijft bijvoorbeeld de regelnaam in beeld terwijl een brede tabel wordt bekeken.

Bijzonder prettig: in onze test bleef de gekozen weergave ook na uitloggen en opnieuw inloggen bewaard. De passende indeling hoeft dus niet bij iedere aanmelding opnieuw te worden samengesteld.

Voor een snel overzicht zijn naam, groep, actie, status en verkeer vaak voldoende. Bij het oplossen van problemen zijn bron- en doelnetwerken, diensten en logging juist interessant. Als bijvoorbeeld de toegang tot een oude applicatieserver moet worden verwijderd, wil je de doelen van de betreffende regels naast elkaar zien. Niet iedere regel afzonderlijk hoeven te openen bespaart tijd en maakt vergelijken eenvoudiger.

De volgende kolommen zijn beschikbaar. De namen komen overeen met de Engelstalige interface; voor de leesbaarheid zijn ze hier thematisch gegroepeerd:

• Regel en overzicht: Name, Type, Group, ID, Features, Traffic (In/Out), Status, Action, Schedule, Description.
• Netwerken en diensten: Src networks, Src zones, Dst zones, Dst networks, Services.
• Gebruikers en logging: Users, Exclude users from accounting, Web authentication for unknown users, Log.
• Beveiligingsfuncties en beleidsregels: Email, Web policy, IPS policy, Application policy.
• Bandbreedte en prioriteit: Traffic shaping policy, Traffic shaping (applications), Traffic shaping (web category), DSCP marking.
• Security Heartbeat: Source HB, Block client with no source HB, Destination HB, Block client with no destination HB.
• Uitzonderingen: Excluded source address, Excluded destination address, Excluded source zone, Excluded destination zone, Excluded service.

Oude weergave voorlopig nog beschikbaar

Met de schakelaar New design kan nog naar de vorige weergave worden teruggekeerd. Wie niet met de nieuwe tabel uit de voeten kan, heeft voorlopig een alternatief. Hoelang Sophos beide weergaven naast elkaar blijft aanbieden, is onbekend.

NAT-regels: nog steeds niet groeperen of klonen

Helaas heeft Sophos de nieuwe weergave niet naar de NAT-regels doorgetrokken. Ook in v23 worden ze anders behandeld: NAT-regels kunnen nog steeds niet worden gegroepeerd of gekloond. Firewallregels kunnen wel worden gekloond, maar voor NAT-regels ontbreekt deze functie nog altijd.

Juist bij het publiceren van meerdere vergelijkbare diensten zou dit handig zijn. Als voor een tweede webserver bijna dezelfde doorstuurregel nodig is, wil je een bestaande NAT-regel kopiëren en daarna het doel en de dienst aanpassen. Nu moet de regel opnieuw worden gemaakt. Dat kost tijd en vergroot de kans dat een van de overige instellingen onbedoeld afwijkt.

We noemden deze wensen al in ons artikel over Sophos Firewall v22. De nieuwe weergave van firewallregels is een welkome vooruitgang. Des te jammerder is het dat het NAT-beheer bij zulke basale bedieningsfuncties achterblijft.

WebAdmin, serienummer en clusterstatus

De WebAdmin-interface gebruikt HTTP/2 om pagina-elementen sneller over te dragen. Ook blijven het serienummer en de toestand van het HA-cluster zichtbaar wanneer tussen instellingenpagina’s wordt gewisseld.

HTTP/2 kan helpen bij het laden van veel pagina-elementen, vooral over verbindingen met een hogere latentie. Of een bepaalde weergave daardoor sneller aanvoelt, hangt echter ook af van de verwerking op de firewall. Een trage databasequery of het opslaan van een complexe configuratie wordt niet vanzelf snel door een ander transportprotocol. In mijn eerste test merkte ik weinig snelheidswinst: het opslaan van een firewallregel duurde nog altijd meerdere seconden.

De zichtbare apparaatidentiteit heeft een direct begrijpelijk voordeel: bij meerdere geopende firewallsessies is eenvoudiger te controleren op welk systeem je werkt. Voor wijzigingen aan een HA-cluster is het bovendien verstandig de rol en toestand van de betreffende apparaten te bekijken.

Wie voor support meerdere vrijwel identieke klantomgevingen open heeft, kent de twijfel vlak voordat een wijziging wordt opgeslagen. Een voortdurend zichtbaar serienummer maakt vergelijking met het ticket eenvoudiger, zonder de huidige instellingenpagina te verlaten. Een kleine verandering met een heel concreet nut.

Hoge beschikbaarheid: sneller detecteren, gerichter overschakelen

Hardwaretoestand als aanleiding

Het HA-cluster bewaakt naast verbindingen en diensten nu ook de toestand van bepaalde hardwareonderdelen, waaronder de SSD. Als die achteruitgaat, kan het cluster overschakelen naar de andere firewall.

Een HA-cluster kan alleen goed op een fout reageren als die ook wordt herkend. Een apparaat kan via zijn netwerkinterfaces nog bereikbaar zijn terwijl er intern al problemen ontstaan. Deze extra hardwarecontrole is daarom relevant voor de bedrijfsvoering.

Een defecte SSD kan bijvoorbeeld schrijfbewerkingen verstoren terwijl de HA-link blijft functioneren. Alleen verbindingen bewaken zou de toestand van de schijf niet aan het licht brengen. De aanvullende hardwarebewaking kan hier ingrijpen voordat een verzwakte node volledig uitvalt.

Na zo’n overschakeling moet de oorzaak alsnog worden onderzocht. De tweede node houdt de diensten beschikbaar, maar repareert geen kapotte SSD. Bij het beheer horen daarom een controle van het getroffen apparaat, een beoordeling van de resterende redundantie en zo nodig vervanging van de hardware.

Kortere detectietijd

Door de versnelde bewaking herkent het HA-cluster het uitvallen van de andere firewall binnen 300 ms in plaats van de eerdere vier seconden.

Die 300 ms geven de tijd aan tot de firewall de uitval van het andere apparaat in het cluster herkent. Voordat een toepassing weer normaal functioneert, kunnen nog andere stappen nodig zijn: de resterende firewall moet de dienstverlening overnemen, naburige netwerkapparaten moeten het verkeer via de juiste route afhandelen en bestaande verbindingen moeten blijven werken of opnieuw worden opgebouwd.

Voor een zinvolle test is daarom meer nodig dan één ping. Een lopend telefoongesprek, een bestandsoverdracht en een VPN-verbinding laten verschillende effecten zien. Pas zulke metingen beantwoorden de vraag of de omschakeling snel genoeg is voor de eigen bedrijfsprocessen.

Minder onterechte omschakelingen bij hoge belasting

De twee firewalls wisselen regelmatig korte statusberichten uit, de zogeheten HA-Heartbeats. Die berichten worden nu met voorrang en gescheiden van het normale dataverkeer verwerkt.

Dat pakt een probleem bij hoge belasting aan: als een systeem zwaar wordt belast, kan een vertraagd antwoord op een uitval lijken. Een omschakeling die daardoor wordt geactiveerd, zorgt voor extra onrust in een toch al drukke omgeving.

Bij de acceptatietest zijn daarom beide situaties van belang: herkent het cluster een echte uitval en blijft het bij hoge belasting zonder daadwerkelijke apparaatstoring stabiel? Een eenvoudige werkingstest in rust beantwoordt maar de helft van die vraag.

DNS-beveiliging, hotfixes en firmware

DNS over HTTPS en DNSSEC

De firewall kan DNS-verzoeken nu via versleutelde HTTPS naar een resolver versturen en DNS-antwoorden met DNSSEC controleren. Ook Sophos DNS Protection kan eenvoudiger worden geactiveerd.

Deze twee DNS-technieken lossen verschillende problemen op. DNS over HTTPS, kortweg DoH, versleutelt het transport naar de resolver. DNSSEC controleert ondertekende DNS-gegevens. Een versleutelde verbinding bevestigt op zichzelf nog niet dat een DNS-antwoord echt is, terwijl een geldige handtekening het verzoek niet verbergt voor waarnemers op het transportpad.

Voor invoering moet eerst het bestaande DNS-pad duidelijk zijn. Vraagt de client de firewall, een interne Windows-DNS-server of rechtstreeks een openbare resolver? Interne naamruimtes moeten nog steeds op de juiste plaats worden opgelost. Daarvoor blijven bijvoorbeeld DNS Request Routes relevant.

Ook browsers met eigen DoH-instellingen verdienen aandacht. Als een client een andere resolver gebruikt, kan zijn daadwerkelijke DNS-pad afwijken van de centraal bedoelde configuratie. Een werkingstest moet daarom zowel interne namen als externe resolutie en de gewenste filterbeslissingen omvatten.

Zichtbare hotfixes en beveiligingsupdates

Bij het bekijken van de interface viel ons nog een verandering op: onder Backup & firmware is weer een eigen gedeelte voor hotfixes aanwezig. Het tabblad heet Hotfix: Security updates. Vroeger stond de hotfixinstelling onder Firmware. Met een vinkje kon worden bepaald of belangrijke hotfixes automatisch moesten worden geïnstalleerd. Nadat die instelling uit de interface verdween, hebben hotfixes nu weer een zichtbare plek gekregen.

De nieuwe weergave gaat over de status van beveiligingsupdates. De oude aan-uitschakelaar is op de getoonde pagina niet zichtbaar. Dat de instelling tussentijds niet zichtbaar was, betekent ook niet dat de firewall geen hotfixes meer ontving: automatische installatie blijft als functie bestaan.

Waarvoor hotfixes dienen

Hotfixes zijn gerichte correcties voor dringende problemen, vooral beveiligingslekken. Ze kunnen buiten de gewone firmware-releases worden verspreid. Een belangrijke correctie hoeft daardoor niet te wachten op de volgende Maintenance Release en op de planning van een volledige firmware-update binnen het bedrijf.

Wordt bijvoorbeeld een kwetsbaarheid in een beheerdienst ontdekt, dan kan een geschikte hotfix het getroffen onderdeel corrigeren. Automatische installatie verkort de tijd tussen het beschikbaar komen van de oplossing en het toepassen ervan op de firewall. Zij is standaard ingeschakeld en zou tijdens normaal gebruik ingeschakeld moeten blijven. Hotfixes vervangen gewone firmware-updates echter niet: die brengen ook andere foutcorrecties, wijzigingen aan onderdelen en nieuwe functies mee.

Patchstatus direct bekijken

De interface laat nu zien welke beveiligingslekken door geïnstalleerde hotfixes zijn verholpen. Bij ieder item staan de CVE-aanduiding, de ernst, de installatiedatum en een link naar het bijbehorende beveiligingsadvies. Deze gegevens zijn ook in de rapportage beschikbaar.

Dat helpt bij een veelgestelde beheervraag: is een concrete kwetsbaarheid op precies deze firewall al verholpen? Een firmwareversienummer biedt niet altijd het volledige antwoord als daarnaast hotfixes worden uitgerold.

Vraagt een klant naar een nieuw beveiligingsadvies, dan kan de lokale status zo nauwkeuriger worden onderbouwd. In plaats van de beveiligingsstatus alleen uit de firmwareversie af te leiden, kan de betreffende CVE met de installatiedatum van de hotfix worden gecontroleerd en in het ticket worden vastgelegd.

Voor de documentatie moet de weergegeven patchstatus samen met het bijbehorende advies worden beoordeeld. Een geïnstalleerde fix beantwoordt de vraag over die specifieke correctie. Hij bewijst niet dat het hele systeem veilig is geconfigureerd of dat een eerdere aanval uitgesloten is. Daarvoor blijven configuratiecontrole, loganalyse en zo nodig onderzoek noodzakelijk.

Terugkerende firmware-updates

In Sophos Fusion kunnen terugkerende onderhoudsmomenten worden ingesteld waarop firewalls automatisch nieuwe firmwareversies installeren. Niet alle apparaten hoeven tegelijkertijd te worden bijgewerkt. Eerst kunnen geselecteerde firewalls worden bijgewerkt en daarna de overige. Voor afzonderlijke apparaten zijn afwijkende instellingen mogelijk, bijvoorbeeld als een vestiging een eigen onderhoudsvenster nodig heeft.

Dat is vooral handig bij meerdere vestigingen. Zo kan de firewall van een klein kantoor als eerste de update ontvangen. Daarna worden daar de VPN-verbindingen, gebruikersaanmeldingen en gepubliceerde diensten gecontroleerd. Pas als die controles slagen, volgen de andere locaties. Zo hoeft niet iedere installatie afzonderlijk te worden gestart, terwijl de volgorde wel beheersbaar blijft.

Vooraf moet duidelijk zijn wie de resultaten controleert en bij problemen verdere updates stopt. Automatische installatie vervangt geen back-up en evenmin een voorbereide terugvalprocedure. De benodigde stappen staan in onze handleidingen voor firmware-updates en back-up en herstel.

Identiteit en aanmelding

Entra ID met Synchronized User ID

Via Synchronized Security kan de firewall nu ook gebruikers herkennen die met Entra ID werken. Daardoor kunnen apparaten met een lokale AD-koppeling en apparaten met een cloudidentiteit naast elkaar worden gebruikt. Voor deze herkenning zijn Sophos Endpoint op de betreffende apparaten en een geschikte Endpoint-licentie nodig.

De praktische vraag daarachter is: hoe weet de firewall welke gebruiker achter een verbinding zit? Alleen een IP-adres volstaat niet altijd voor een zinvolle gebruikersgebonden regel. Bij de overstap van een lokaal domein naar een cloudidentiteit moet deze koppeling betrouwbaar blijven werken.

Een typisch voorbeeld is een bedrijf dat nieuwe laptops alleen nog met Entra ID verbindt, terwijl oudere apparaten nog lid zijn van het lokale AD-domein. Voor het webbeleid van de boekhouding mag deze technische overgangsfase geen verschil maken: doorslaggevend is de gebruikersgroep. Juist deze continuïteit is belangrijk bij een stapsgewijze migratie naar de cloud.

Voor de planning is het onderscheid met de al bekende Entra ID-aanmelding bij het Captive Portal belangrijk. Hier gaat het om de samenwerking met Sophos Endpoint. Uit een bestaande Entra ID-omgeving volgt dus niet automatisch dat de firewall gebruikers op deze manier kan herkennen. Tijdens een proef moet worden gecontroleerd welke gebruiker daadwerkelijk verschijnt en welke groepsregel vervolgens van toepassing is.

Google Workspace als Identity Provider

Gebruikers kunnen zich met hun Google Workspace-account aanmelden bij het Captive Portal, VPN Portal, Sophos Connect en de WebAdmin-interface. Google Workspace vervult daarbij de rol van Identity Provider en kan bij de aanmelding ook meervoudige authenticatie verlangen.

Voor organisaties die Google als centrale gebruikersdirectory inzetten, is dat een belangrijke aanvulling. Accounts en aanmeldregels worden bij voorkeur beheerd waar ook de overige bedrijfstoegang wordt geregeld.

Een school met Google Workspace hoeft bijvoorbeeld voor de VPN-toegang van docenten niet daarnaast een aparte wachtwoorddatabase op de firewall bij te houden. Dat vermindert dubbel beheer en maakt het eenvoudiger de aanmelding via de centrale Identity Provider te beveiligen.

Toch is een geslaagde aanmelding maar een deel van de integratie. Daarna moeten de juiste rechten worden toegepast. Een gewone medewerker mag via een werkende SSO-aanmelding geen beheertoegang krijgen. Bij het testen horen daarom gebruikersattributen, groepsindeling, toegestane diensten en het intrekken van toegangsrechten bij elkaar.

MFA-instelling via e-mail

Voor het instellen van meervoudige authenticatie kan de firewall de benodigde QR-code per e-mail versturen. Als de registratie niet binnen 24 uur wordt afgerond, vervalt de ongebruikte code. Bij bestaande installaties blijft voorlopig de eerdere instelling via het portaal beschikbaar.

Dit verandert het instelproces voor nieuwe gebruikers. Voor de uitrol moeten e-mailadressen en e-mailbezorging worden gecontroleerd. Anders eindigt de eerste VPN-aanmelding in een supportverzoek, terwijl de authenticatie zelf correct is ingesteld.

Een QR-code voor registratie bevat informatie die relevant is voor de beveiliging. De ontvangende mailbox moet daarom ook goed zijn beveiligd. De helpdesk heeft bovendien een duidelijke werkwijze nodig voor verlopen registraties en onjuist opgegeven adressen. Bij opnieuw verzenden mag de identiteit van de aanvrager niet ongecontroleerd blijven.

Chromebook-SSO

Met een nieuwe uitbreiding voor Chromebooks kan de gebruikersaanmelding aan de firewall worden doorgegeven zonder dat de gebruiker zich opnieuw bij het Captive Portal hoeft aan te melden. De uitbreiding ondersteunt alle nog ondersteunde SFOS-versies.

Vooral op scholen zijn herhaalde portaalaanmeldingen hinderlijk. Belangrijk is daar niet alleen de eerste succesvolle aanmelding, maar ook het wisselen tussen gebruikers en apparaten. Een test met gedeelde Chromebooks moet aantonen dat na een gebruikerswissel geen oude koppeling wordt hergebruikt.

Omdat de uitbreiding versieoverstijgend bedoeld is, moet de invoering apart van de v23-upgrade worden gepland. Een nieuwe clientcomponent en nieuwe firewallfirmware tegelijk uitrollen bemoeilijkt het opsporen van mogelijke fouten.

Terminalservers: gebruikerskoppeling met XDR Sensor

Voor Sophos Authentication for Thin Client, afgekort SATC, kan een lichte XDR Sensor worden gebruikt. Die helpt de firewall het netwerkverkeer op een gedeelde server aan individuele gebruikers toe te wijzen en kan naast een bestaande endpointbeveiliging draaien.

Op een terminalserver delen veel sessies hetzelfde server-IP-adres. Een IP-gebaseerde toestemming maakt daarom geen onderscheid tussen iemand van de boekhouding en een externe medewerker op dezelfde host. Voor gebruikersgebonden web- of firewallregels is een aanvullende koppeling nodig.

De mogelijkheid een sensor naast een bestaand beveiligingsproduct in te zetten is interessant voor gemengde omgevingen. Dat is echter geen algemene compatibiliteitsgarantie voor elke combinatie. Licentie, besturingssysteem en ondersteunde samenwerking moeten vooraf worden gecontroleerd. Bij de functietest moeten minstens twee gelijktijdig aangemelde gebruikers verschillende regels krijgen. De gevolgen voor de terminalserver zelf moeten afzonderlijk van de beslissingen van de firewall worden beoordeeld.

WAF: meer controle over gepubliceerde toepassingen

Verschillende acties per URL-pad

De Web Application Firewall krijgt acties per pad: Protect, Block, Redirect en Passthrough. De laatste is bedoeld voor WebSockets zonder WAF-inspectie.

Met Protect blijft een pad onder WAF-controle. Block weigert de toegang met HTTP 403. Redirect stuurt de browser naar een ander adres. Passthrough is dus een bewust gekozen uitzondering voor het betreffende WebSocket-verkeer, geen extra controleniveau.

Daardoor kan de behandeling van een toepassing beter op haar opbouw worden afgestemd. Na een portalwijziging kan bijvoorbeeld /altes-portal naar /kundenportal doorverwijzen, terwijl een buiten gebruik gesteld gedeelte onder /legacy met HTTP 403 wordt geblokkeerd. Het eigenlijke toepassingsgedeelte blijft onder WAF-controle. Zulke beslissingen direct bij het voorgeschakelde toegangspunt beheren kan wijzigingen aan de backend verminderen.

Bij doorverwijzingen moet het doel exact kloppen. Een verkeerd pad kan aanmeldprocessen of opgeslagen links verstoren; een ondoordachte doorverwijzing kan lussen veroorzaken. Voor een uitzondering zonder WAF-controle moet bovendien duidelijk zijn welke bescherming in de toepassing zelf overblijft. Een werkende verbinding bewijst nog geen gelijkwaardige beveiligingscontrole.

Meer paden en regels

Per padvermelding zijn maximaal 128 paden voorzien. De limiet voor WAF-regels ligt standaard op 100 en kan worden verhoogd naar 200.

Bij de planning moeten de regellimiet en de prestaties afzonderlijk worden bekeken. Meer configureerbare regels betekenen niet automatisch dat een appliance onbeperkt veel actieve toepassingen met dezelfde responstijd kan bedienen. TLS-verwerking, inspectie, uploads en de snelheid van backendservers bepalen mede de benodigde resources.

Een zinvolle acceptatietest gebruikt daarom typische verzoeken van de werkelijke toepassingen. Een statische testpagina vertegenwoordigt bijvoorbeeld een portaal met grote bestandsuploads nauwelijks.

Nieuwe verwerking met Apache Event MPM

De WAF stapt over op Apache Event MPM om gelijktijdige verzoeken beter te verwerken.

Eenvoudig gezegd gaat het erom capaciteit beter te benutten terwijl afzonderlijke verbindingen op verdere verwerking wachten. Bij veel gelijktijdige toegang is die verdeling doorslaggevend: niet iedere open verbinding moet onnodig resources bezet houden die voor andere verzoeken nodig zijn. De capaciteit van de backend blijft daarnaast een eigen grens.

De belangrijkste bedrijfswaarde is het gedrag onder belasting. Een toepassing kan technisch bereikbaar blijven, maar toch zo langzaam antwoorden dat gebruikers hun werk afbreken. Bij belastingtests moeten daarom niet alleen geslaagde verbindingen worden bekeken, maar ook responstijden en foutpercentages.

Voor een bruikbare vergelijking vóór en na de wijziging moeten hardware, beveiligingsprofiel, backend en testverkeer gelijk blijven. Pas dan kan worden beoordeeld welk verschil de nieuwe verwerking in de eigen omgeving maakt. Uit alleen de architectuurwijziging kan geen algemene doorvoersnelheid worden afgeleid.

DHCP, routing en netwerkdiensten

DHCP op de nieuwe Control Plane

De DHCP-dienst draait nu op de nieuwe Control Plane en kan grotere adresreeksen en meer reserveringen verwerken. Het DHCP-verkeer wordt bovendien al vóór de dienst door de firewall gecontroleerd om de gevolgen van een stortvloed aan verzoeken te beperken. Instellingen waarvoor eerder de commandoregel nodig was, zijn nu via de interface bereikbaar.

Dit raakt een fundamentele afhankelijkheid van het netwerk. Als clients geen adres krijgen, lijken veel andere diensten eveneens verstoord. Bij een upgrade moet de DHCP-server daarom net zo bewust worden gecontroleerd als VPN of internettoegang.

De schaalbaarheid wordt bijvoorbeeld relevant op een school wanneer ’s ochtends veel apparaten vrijwel tegelijkertijd met wifi verbinden en om een adres vragen. Voor gebruikers lijkt een haperende adrestoewijzing al snel op een wifi-probleem. Snelle verwerking van leases helpt op een plek die bij het zoeken naar fouten gemakkelijk wordt vergeten.

Bij de test horen nieuwe leases, verlengingen van bestaande leases en gereserveerde adressen. Ook doorgegeven waarden zoals gateway, DNS-server en individuele DHCP-opties moeten kloppen. Juist zelden gebruikte instellingen vallen vaak pas op als een specifiek apparaat opnieuw opstart.

Ook het opvragen van toegewezen adressen is vernieuwd. DHCP-opties worden consistenter volgens de onderliggende standaarden verwerkt. Bestaande bijzondere configuraties verdienen daarom een gerichte vergelijking vóór en na de upgrade.

Tot de instellingen die naar de interface zijn overgebracht behoren negatieve bevestigingen en een beperking tot één lease per client. Een negatieve bevestiging geeft aan dat een client het gevraagde adres niet mag gebruiken en opnieuw over zijn adresconfiguratie moet onderhandelen. Zulke instellingen moeten vanuit het eigen netwerkontwerp worden beoordeeld, vooral als meerdere DHCP-diensten aanwezig zijn.

mDNS-reflector voor Bonjour en apparaatdetectie

Met de mDNS-reflector kunnen apparaten ook diensten in andere geselecteerde netwerken ontdekken. Dat werkt met zowel IPv4 als IPv6. Voor de daaropvolgende verbinding met het gevonden apparaat blijft een passende firewallregel nodig.

Dat is bijvoorbeeld relevant als printers en medewerkers zich in verschillende VLAN’s bevinden. De printer kan correct geadresseerd en in principe bereikbaar zijn, maar toch niet bij de automatische apparaatdetectie verschijnen. Dienstontdekking en de aansluitende gegevensverbinding zijn twee afzonderlijke stappen.

Bij de configuratie moeten alleen de benodigde netwerkparen en diensten worden toegestaan. Een gastennetwerk hoeft niet alle apparaten in de interne infrastructuur te ontdekken. Na de inrichting moeten zowel de gewenste werking als de grens worden getest: de bedoelde printer wordt gevonden en is bruikbaar, andere interne diensten blijven onbereikbaar.

Routing-engine en experimentele BFD

De firewall gebruikt een bijgewerkte versie van de routingsoftware FRR. De verschillende routingprotocollen kunnen via een gemeenschappelijke console worden beheerd. Daarnaast komt er experimentele BFD-ondersteuning voor BGP en statische routes op afzonderlijk gebruikte firewalls.

BFD staat voor Bidirectional Forwarding Detection en dient om een uitgevallen verbinding tussen routingburen snel te herkennen. Dat is een andere taak dan de rolwisseling van een firewall-HA-cluster. Snellere foutdetectie kan helpen verkeer eerder naar een alternatieve route te sturen.

Zeer korte controle-intervallen zijn echter geen doel op zich. Als de andere kant of het transportpad onder belasting niet betrouwbaar antwoordt, kan een agressieve instelling onnodige toestandwisselingen veroorzaken. De experimentele status moet daarom serieus worden genomen: beoordeel BFD eerst in een geschikte testomgeving.

Dat is bijvoorbeeld interessant bij twee gerouteerde vestigingsverbindingen. De lokale interface kan actief blijven terwijl de buur via de voorkeursroute niet meer bereikbaar is; de linkstatus alleen herkent die storing niet. Een passende BFD-koppeling kan in zo’n architectuur helpen de uitval eerder vast te stellen.

IPv6 IPoE en 4in6

De firewall ondersteunt meer aansluitvarianten met IPv6 IPoE en 4in6-tunnels, waaronder de Japanse internetdienst Xpass.

Bij 4in6 wordt IPv4-verkeer via een IPv6-verbinding vervoerd. Deze functies zijn vooral relevant als de internetprovider juist dit aansluitmodel vereist. Voor een klassieke aansluiting is dat op zichzelf geen reden om de WAN-configuratie aan te passen.

De uitbreidingen hebben ook betrekking op dynamische adressen, tunnelendpoints en MTU/MSS. Voor foutopsporing is hun samenspel belangrijk: een tunnel die succesvol opkomt, garandeert nog niet dat grote pakketten of alle toepassingen goed werken. Providerparameters, naamomzetting en pakketgroottes moeten daarom samen worden gecontroleerd.

Uitrol op IONOS Cloud

Sophos Firewall kan nu ook op IONOS Cloud draaien met de officiële SFOS-image. De installatie gebeurt handmatig met een eigen image en niet via een kant-en-klare Marketplace-vermelding.

Bij het ontwerp moet dus worden bepaald hoe openbare en interne netwerken worden verbonden, hoe de beheertoegang wordt beschermd en wie de levenscyclus van de virtuele machine verzorgt. Een ondersteunde installatieplaats beantwoordt nog niet de vragen over redundantie, herstel en bewaking.

In het bijzonder mag het eigen beheermodel niet stilzwijgend functies veronderstellen van een volledig beheerde clouddienst. Ook een virtuele firewall heeft gepland onderhoud en controleerbare back-ups nodig.

Dreigingsmeldingen en kleinere wijzigingen

NDR-meldingen zonder automatische isolatie

Detecties door NDR Essentials en NDR Active Threat Intelligence kunnen een melding activeren zonder het getroffen eindapparaat automatisch van het netwerk te isoleren.

Daarmee worden detectie en reactie duidelijker gescheiden. Dat kan helpen bij het invoeren van nieuwe detectiebronnen: eerst wordt de kwaliteit van de meldingen beoordeeld en daarna wordt bepaald welke gebeurtenissen een blokkade moeten veroorzaken. De verschillen tussen de methoden leggen we uit in ons artikel over NDR Active Threat Intelligence.

Een melding alleen heeft echter slechts nut als iemand haar opvolgt. Verantwoordelijkheid, reactietijd en escalatieroute moeten vastliggen. Ook moet afzonderlijk worden gecontroleerd welke blokkeeracties in Active Threat Response nog zijn geconfigureerd. Uit een wijziging in de alarmering mag niet worden geconcludeerd dat alle beschermingsacties zijn uitgeschakeld.

E-mailinhoudslijsten en webcategorieën

Andere wijzigingen betreffen ID-gebaseerde verwijzingen voor e-mailinhoudslijsten en het versiebeheer van webcategorieën.

Bij de e-mailinhoudslijsten, de Content Control Lists, wordt de verwijzing losgemaakt van de zichtbare naam. Een naam helpt mensen bij de oriëntatie, een stabiele ID zorgt voor een eenduidige koppeling. Het versiebeheer van webcategorieën gaat daarentegen over de afstemming van de gebruikte categoriedefinities met Sophos op de achtergrond.

Deze punten zijn minder zichtbaar dan een nieuwe interface, maar horen bij een volledig overzicht van deze release. Bij configuratiewijzigingen en herstel is het belangrijk dat een beleid nog steeds het bedoelde object gebruikt. Voor webfilters moeten bekende toegestane en geblokkeerde testpagina’s na een upgrade nog de verwachte beslissing opleveren.

eDirectory wordt niet meer ondersteund

Sophos Firewall v23 ondersteunt het native eDirectory-servertype niet meer. Een nog aanwezige eDirectory-koppeling verhindert daarom de upgrade. Mogelijke alternatieven zijn Entra ID SSO, Active Directory, RADIUS of een LDAP-koppeling met de bestaande eDirectory-server.

Belangrijk is het onderscheid tussen aanmelden en automatische gebruikersherkenning: LDAP kan gebruikers bij de bestaande directory authenticeren, maar vervangt de native eDirectory-SSO niet. Ook bij het herstellen van een back-up of het importeren van een configuratie wordt de oude eDirectory-koppeling niet overgenomen.

De overstap en de gevolgen voor gebruikers, groepen en diensten beschrijven we in onze handleiding Sophos Firewall: eDirectory vóór SFOS 23 migreren.

Conclusie

De REST API is voor mij een van de nuttigste vernieuwingen in Sophos Firewall v23. Ze maakt terugkerende wijzigingen eenvoudiger en biedt een goede basis om configuraties met eigen tools te analyseren. Ook voor analyses met AI zijn API’s nuttig: regels en objecten kunnen gestructureerd worden uitgelezen, vergeleken en op afwijkingen onderzocht. Welke wijzigingen daaruit volgen, moet nog altijd een beheerder beslissen. Maar al bij het verzamelen en voorbereiden van informatie kan veel handwerk worden bespaard.

Ook de nieuwe weergave van firewallregels bevalt mij. De groepsindeling als kolom, vrij te kiezen details en de permanent opgeslagen weergave maken het werk aangenamer. Jammer is dat deze vernieuwing niet ook bij NAT-regels is ingevoerd. Vooral daar ontbreken groeperen en klonen nog altijd, hoewel die functies bij het opbouwen en onderhouden van grotere configuraties goed van pas zouden komen.

Van Sophos Firewall Config Studio had ik bovendien graag meer functies rechtstreeks in de firewall gezien: het vergelijken van meerdere configuratiestanden, het samenvoegen van configuratiesjablonen en rapporten die bij firewall-, NAT- en TLS-regels ook de waarden van de gebruikte objecten tonen. Zulke tools helpen wijzigingen te begrijpen en voor te bereiden. In deze vorm blijven ze voorbehouden aan het afzonderlijke Config Studio.

Qua snelheid zag ik in mijn eerste test daarentegen geen wezenlijke verbetering. Het opslaan van een firewallregel duurt nog steeds meerdere seconden. Bij een enkele wijziging maakt dat weinig uit. Maar als een regelset wordt opgeschoond en veel regels achter elkaar worden bewerkt, stapelen de wachttijden zich op en onderbreken ze voortdurend de workflow. De verbeteringen aan de interface zijn welkom. Voor het dagelijks beheer wens ik vooral dat veelvoorkomende taken sneller kunnen worden uitgevoerd en firewall- en NAT-regels op een consistentere manier kunnen worden beheerd.

FAQ

Bronnen

• Sophos Firewall v23: aankondiging van de release, aankondiging van 28 september 2026.
• Sophos Firewall OS v23: Key New Features, technische gids voor nieuwe functies, stand van 28 september 2026.
• Sophos Firewall v23: feedback en ervaringen, doorlopende reacties uit de community.