Sophos Firewall Hardening: best practices voor een veilige configuratie

Sophos Firewall hardening betekent dat de aanvalsvlakte rond de firewall zelf en de diensten die via de firewall worden gepubliceerd bewust wordt verkleind. Het is geen enkele magische instelling, maar een herhaalbaar beheerproces: beheerstoegang beperken, MFA afdwingen, firmware actueel houden, regels beoordelen, beveiligingsfuncties inschakelen en logs analyseren.

Dit artikel is het centrale startpunt. Het vervangt de detailhandleidingen niet, maar ordent de belangrijkste best practices en verwijst naar de passende Avanet KB-artikelen.

Wat eerst gecontroleerd moet worden

Bij hardening telt de volgorde. Een perfect afgestemde IPS-policy helpt weinig als WebAdmin wereldwijd via WAN bereikbaar is of een oud VPN Portal zonder MFA openstaat.

De belangrijkste directe controles:

• Is WebAdmin bereikbaar vanuit de WAN-zone?
• Is SSH alleen toegestaan vanuit vertrouwde beheernetwerken?
• Is MFA actief voor administrators, VPN Portal en Remote Access?
• Zijn firmware, hotfixes en pattern updates actueel?
• Zijn er DNAT-, WAF- of VPN-toegangen die niet meer nodig zijn?
• Hebben gepubliceerde diensten IPS, WAF, Threat Feeds, logging en een duidelijke eigenaar?
• Worden beveiligingsrelevante logs onafhankelijk van de firewall bewaard en bewaakt, met een vastgelegde eigenaar en bewaartermijn?
• Is er een actuele, geteste backup inclusief Secure Storage Master Key?

Beheerstoegang beveiligen

Het belangrijkste hardening-gebied is toegang tot de firewall zelf. WebAdmin, SSH, User Portal, VPN Portal, Captive Portal en lokale diensten zijn geen normale firewallregels, maar lokale diensten van de firewall. Ze moeten bewust worden beperkt via Device Access en Local Service ACL.

Device Access en Local Service ACL

Onder Administration > Device access wordt per zone bepaald welke lokale diensten bereikbaar zijn. Voor de WAN-zone hoort alleen actief te zijn wat echt nodig is. Admin-toegang en SSH horen normaal niet breed op internet te staan.

Als remote beheer nodig is, zijn deze varianten netter:

• Beheer via Sophos Fusion (voorheen Sophos Central).
• Toegang via een apart beheernetwerk.
• Toegang via VPN of ZTNA.
• Strakke Local Service ACL Exception Rules voor vaste admin-bron-IP-adressen.

De concrete uitvoering staat in Sophos Firewall toegang beveiligen: Device Access correct configureren. Als SSH nodig is, helpt ook Sophos Firewall via SSH verbinden.

Voorkom dat je jezelf buitensluit bij het maken van een WAN-uitzondering. Meld je eerst aan via een onafhankelijke herstelroute, zoals de console, het management-LAN, een admin-VPN of Sophos Fusion, en test deze route. Klik daarna onder Administration > Device access op Add bij Local service ACL exception rule. Een aanpasbaar voorbeeld is WAN-Admin-203.0.113.10 met Rule position Top, IP version IPv4, Source zone WAN, het vaste publieke admin-IP als Source network / host, de WAN-interface van de firewall als Destination host, Services HTTPS en alleen indien nodig SSH, en Action Accept. 203.0.113.10 is een documentatieadres en moet worden vervangen door het werkelijke vaste admin-IP. Laat de bestaande sessie open, test toegang in een tweede sessie vanaf die bron en verwijder pas daarna de bredere WAN-toestemming voor HTTPS of SSH in Local service ACL. Mislukt de test, dan blijft de eerdere toegang ongewijzigd; corrigeer de uitzondering voordat je de zonetoestemming aanpast.

MFA, rollen en login security

VPN Portal is niet alleen voor downloads: VPN-clients en gewijzigde configuraties worden via VPN Portal verspreid. Ook SSO vereist blijvende noodzakelijke WAN-bereikbaarheid: Microsoft Entra ID SSO in SFOS 22 en OpenID Connect SSO in SFOS 23. Sluit na downloads geen SSO-pad dat nog nodig is. User Portal blijft op WAN uitgeschakeld; externe toegang verloopt via VPN. Bescherm VPN Portal met passende, zo beperkt mogelijke ACLs, een geldig certificaat en bewaking van brute-force-aanvallen. Dwing bij OIDC MFA af in de IdP, niet via aanvullende firewall-OTP. De lokale OTP-stappen hieronder gelden voor klassieke authenticatie, niet voor OIDC. De inrichting staat in Entra VPN SSO en Google Workspace OIDC. Test na ACL- of authenticatiewijzigingen een nieuwe aanmelding en de werkelijke VPN-tunnel vanaf het beoogde externe netwerk; controleer bij fouten ACLs, certificaat en redirecttoewijzing in plaats van WAN breed open te zetten.

MFA hoort verplicht te zijn voor administrators en Remote Access-gebruikers. Vooral lokale adminaccounts, VPN Portal, User Portal en Remote Access VPN zijn kritisch. MFA is echter maar één onderdeel van login-hardening. Net zo belangrijk zijn named admin accounts, duidelijke rollen, sterke wachtwoordregels, beperkte loginpogingen en korte session timeouts.

In SFOS 22 staat de gebruikersconfiguratie onder Authentication > Multi-factor authentication (MFA). Kies onder One-time password (OTP) All users of Specific users and groups, schakel voor app-tokens Generate OTP token with next sign-in in en selecteer onder Require MFA for elke werkelijk gebruikte dienst. Bescherm het ingebouwde account admin apart onder Administration > Device access > MFA for default admin. Voordat MFA wordt afgedwongen, moet minstens één persoonlijk administratoraccount zijn token hebben geregistreerd; controleer de uitgifte onder Issued tokens. Test vervolgens een nieuwe aanmelding terwijl een bestaande adminsessie als terugweg open blijft.

De praktische inrichting staat in MFA voor Sophos Firewall WebAdmin, VPN Portal en Remote Access activeren. Hoe persoonlijke lokale accounts, Device Access-profielen, loginbronnen en offboarding samenwerken, staat in Sophos Firewall-beheerders en profielen veilig instellen. Voor WAF-scenario’s met gebruikerslogin past Sophos Firewall WAF met MFA beveiligen.

Autorisatie voor Remote Access VPN controleren

Verleen VPN-toegang alleen aan de gebruikers en groepen die deze nodig hebben en alleen tot de vereiste resources. Selecteer hiervoor niet de standaardfallbackgroep Open group. Gebruikers zonder passende groepstoewijzing kunnen daarin terechtkomen, bijvoorbeeld bij AD-synchronisatie. Controleer leden regelmatig en wijs ze aan de juiste groepen toe. Deze standaardgroep is geen fallback-firewallregel en ook niet de bewust beperkte IdP-fallbackgroep uit de gekoppelde SSO-handleiding. Providerspecifieke toewijzing blijft daar beschreven. Test voor acceptatie een toegestane gebruiker, een fallback/niet-toegewezen gebruiker en een geweigerde resource: alleen de bedoelde toegang mag werken. Corrigeer bij onverwacht succes groepstoewijzing en VPN/firewallrechten en herhaal de test.

Firmware, hotfixes en recovery

Een firewall is een edge-systeem. Uitgestelde updates zijn daarom geen klein detail, maar een echt aanvalsvenster. Tegelijk mogen updates niet blind worden uitgevoerd, omdat remote locaties, HA-clusters, VPNs en productieve NAT-regels geraakt kunnen worden.

Updates planbaar maken

Firmware-updates moeten worden voorbereid met backup, onderhoudsvenster, release-notescontrole, HA-planning en rollbackcriteria. Controleer beschikbare maintenance releases regelmatig en installeer ze na goedkeuring tijdig. In actuele SFOS 22-versies toont de WebAdmin-pagina Backup & Firmware > Firmware geen aparte Hotfix-sectie meer. De hotfixfunctie bestaat nog steeds: Sophos installeert hotfixes standaard automatisch en raadt aan deze instelling niet te wijzigen. Als de status moet worden gecontroleerd, gebruik dan system hotfix show in de Device Console. Hotfixes vervangen geen regulier updateproces. Het proces staat in Sophos Firewall firmware update: voorbereiding en best practices.

De pagina bewaart maximaal twee firmwareversies. Een rollback start de vorige versie met de bijbehorende eerdere configuratie; wijzigingen sinds de versiewissel gaan verloren. Vanaf SFOS 19.0 MR1 vereisen firmwarewissels na drie gratis upgrades Enhanced Support of Enhanced Plus; hotfixes vereisen dit supportabonnement niet. Controleer daarom verwachte firmware, beheerbereikbaarheid, VPNs en kritieke publicaties voordat je na de update verdere configuratiewijzigingen uitvoert.

Bij grotere versiesprongen moeten ook upgradepad, licentie, platform en bekende beperkingen worden gecontroleerd. Sophos Firewall vóór SFOS 22 upgrade controleren past hierbij.

Backup en restore controleren

Hardening stopt niet bij preventie. Een geharde firewall moet ook herstelbaar zijn. Daarvoor zijn een actuele backup, het backupwachtwoord, de Secure Storage Master Key, een gedocumenteerd toegangspad na restore en een acceptatietest nodig.

De details staan in Sophos Firewall backup maken of herstellen. Vooral vóór firmware-updates, migraties, reimage en hardwarevervanging is een compleet recoverypakket verplicht.

Een bijzondere compliancemigratie is de FIPS 140-3-modus op Sophos Firewall: Activering voert een factory reset uit en vereist een volledig geplande heropbouw met FIPS-conforme VPN- en certificaatinstellingen.

Aanvalsvlakte in de regels verminderen

Veel risico’s ontstaan niet door exotische aanvallen, maar door te brede regels, oude uitzonderingen en gepubliceerde diensten waar niemand nog echt eigenaar van is.

NAT, WAF en gepubliceerde diensten

Elke dienst die via DNAT of WAF wordt gepubliceerd, is een bewust geopende ingang. Dat kan nodig zijn, maar moet strak worden gepland: source, destination, service, NAT-volgorde, firewallregel, IPS/WAF-policy, logging, test en eigenaar horen bij elkaar.

Voor gepubliceerde servers helpen Server met DNAT op Sophos Firewall publiceren en NAT op Sophos Firewall begrijpen. Als webservers worden gepubliceerd, is Sophos Firewall WAF: webservers veilig publiceren de betere basis.

Firewallregels en segmentatie

Regels met Any bij source, destination of service zijn niet automatisch fout, maar moeten altijd verklaarbaar zijn. Voor hardening zijn deze vragen belangrijk:

• Is de regel nog nodig?
• Is logging actief?
• Is er een duidelijkere source of destination?
• Staat de regel correct vóór bredere regels?
• Zijn admin-, server-, client-, IoT-, gast- en backupnetwerken netjes gescheiden?

De basis staat in Sophos Firewall-regels begrijpen en veilig configureren. Voor het controleren van een concrete regel past Sophos Firewall-regel netjes testen.

Beveiligingsfuncties bewust activeren

Beveiligingsfuncties helpen alleen wanneer ze passen bij regel, verkeer en beheerproces. Blind ingeschakelde functies veroorzaken false positives, performanceproblemen of supportcases. Uitgeschakelde functies laten juist onnodige aanvalsvlakte open.

IPS, Spoof Protection en DoS

IPS hoort te worden gebruikt op inkomend onbetrouwbaar verkeer en op relevante interne overgangen. Belangrijk zijn passende IPS Policies, logging, een false-positive-proces en aandacht voor performance. De uitvoering staat in Sophos Firewall IPS instellen en veilig testen.

Spoof Protection en DoS Settings verminderen onwaarschijnlijke bronnen en eenvoudige floodingpatronen. Ze moeten voorzichtig worden getest, vooral bij VoIP, VPN, hoge pakketbelasting of speciale routingdesigns. Het passende artikel is Sophos Firewall Spoof Protection en DoS Settings controleren.

Threat Feeds voor WAF en DNAT

Threat Feeds vullen bescherming alleen aan voor een vastgesteld module- en verkeerspad. Vanaf SFOS 22 is matching van de bron-IPv4 van inkomend doorgestuurd DNAT/WAF-verkeer met MDR, NDR en Third-Party Threat Feeds gedocumenteerd. Voor lokale diensten zoals VPN Portal is de vastgestelde aanvullende bescherming bron-IPv4-matching met ondersteunde Third-Party Feeds; dit pad loopt niet door een transit-firewallregel. Domein-/URL-indicatoren betreffen passende uitgaande bestemmingsmatching, niet de bron-IP van een inkomende aanmelding. Het DNS/IPS/Application Classification- of web/TLS-inspectiepad moet passend zijn; volledige HTTPS-URL-paden vereisen ontsleuteling. IPv6-bronnen vallen niet onder deze feedbescherming.

Onopgeloste X-Ops-grens: De ATR-tekst en SVG-verkeersmatrix spreken elkaar tegen over bepaalde X-Ops-matchrichtingen, vooral bestemmingsmatching en lokale bronmatching voor uitgaand verkeer. Trek uit MDR, NDR of Third-Party Feeds geen conclusies over Sophos X-Ops, ook niet voor DNAT/WAF of lokale portals. Vertrouw tot gezaghebbende verduidelijking niet op betwiste feedeffecten: beperkende ACLs, firewall/WAF-regels, patching en MFA blijven onafhankelijk nodig. Controleer module, richting, logs en werkelijke werking alleen met goedgekeurde, gecontroleerde tests. MDR Threat Feeds en de hieronder gekoppelde NDR-handleiding lichten deze grens verder toe.

Monitor detecteert en logt treffers, maar blokkeert niet; Block moet voor het geverifieerde pad ingesteld zijn. Een treffer alleen bewijst geen blokkering of volledige logging. Controleer het relevante ATR/firewall/WAF-log samen met de werkelijke verbinding; allowlisting, false-positive-afhandeling en eigenaarschap blijven nodig. De voorbeelden hieronder gelden alleen binnen deze module-/padgrenzen.

Ze zijn vooral waardevol voor:

• publieke webservers achter WAF of DNAT,
• RDP-, SSH- of admin-toegang die nog niet volledig door ZTNA is vervangen,
• VPN- en portaltoegang met veel internetruis,
• omgevingen waarin landenblokkering te grof is,
• klanten die naast Sophos X-Ops ook gecureerde third-party feeds willen gebruiken.

De operatie is doorslaggevend: feedkwaliteit, actie Monitor of Block, allowlist, false positives, logging en eigenaarschap moeten helder zijn. De configuratie staat in Sophos Firewall Threat Feeds instellen en veilig beheren. Voor gecureerde feeds kan Cybora een zinvolle bouwsteen zijn, vooral wanneer gepubliceerde diensten consequent tegen bekende slechte bronnen moeten worden beschermd.

Web, DNS, TLS en Zero-Day Protection

Web Protection, DNS Protection, TLS Inspection en Zero-Day Protection verhogen zichtbaarheid en blokkeerwerking, maar vragen om nette planning. TLS Inspection mag geen alles-of-niets-project zijn. DNS Protection moet passen bij de gebruikte DNS-paden. Zero-Day Protection helpt alleen wanneer relevante bestandstypen en policies zinvol zijn geïntegreerd.

Passende detailartikelen zijn Sophos Firewall Web Protection met Web Policies maken, Sophos DNS Protection met Sophos Firewall instellen, Sophos Firewall TLS Inspection correct introduceren en Sophos Firewall Zero-Day Protection begrijpen en beheren.

Detectie, logging en review

Hardening is geen eenmalige projecttaak. Regels, gebruikers, portals, NAT-uitzonderingen en firmwareversies veranderen. Daarom zijn regelmatige reviews nodig en logs die niet pas na een incident gezocht hoeven te worden.

Health Check als startpunt

De Sophos Firewall Health Check is een goed startpunt omdat hij risicovolle configuraties zichtbaar maakt. Findings moeten niet blind worden toegepast, maar beoordeeld op risico, operationele impact en lokale architectuur.

Open in SFOS 22 de widget Firewall health check in het Control Center of ga naar Monitor & analyze > Firewall health check. De gegevens worden bijgewerkt zodra een bewaakte configuratie verandert. Let op: een finding kan handmatig als compliant worden gemarkeerd zonder de oorzaak te herstellen. Validatie moet daarom bevestigen dat aan de policy-eis is voldaan, niet alleen dat de getoonde status is veranderd.

Goede momenten voor een Health Check:

• na de eerste setup,
• na migraties,
• vóór en na firmware-upgrades,
• na grotere regelwijzigingen,
• vóór audits,
• elk kwartaal tijdens beheer.

Telemetrie en Sophos Assistant afzonderlijk beoordelen

Onder Administration > Admin and user settings bepaalt Sophos Adaptive Learning welke gebruiks- en bedreigingsgegevens de firewall naar Sophos verzendt. Daaronder vallen niet-geclassificeerde toepassingen en gegevens over IPS-alerts, gedetecteerde virussen, spam en bevindingen van Active Threat Response. Daarnaast is de basisrapportage over configuratie en gebruik standaard ingeschakeld: het apparaat verzendt periodiek via HTTPS gegevens over configuratie, functies, fouten en resourcegebruik. Sophos geeft aan daarbij geen gebruikersspecifieke of gepersonaliseerde informatie te verzamelen. Documenteer de keuze toch bewust volgens de privacyvereisten en het beheermodel, in plaats van deze optie te behandelen als een beschermingsfunctie voor lokaal verkeer.

Turn on Sophos Assistant heeft daarentegen alleen invloed op helpteksten, smart tips en configuratiehandleidingen in WebAdmin. Na een wijziging moet men zich afmelden en opnieuw aanmelden. Het uitschakelen van de assistent verkleint het netwerkaanvalsoppervlak niet en stopt telemetrie niet automatisch; beoordeel beide instellingen afzonderlijk.

Logging, alerts en SIEM

Firewallregels zonder logging zijn vaak waardeloos voor troubleshooting en incident response. De gedocumenteerde baseline is centrale rapportage in Sophos Fusion (voorheen Sophos Central) plus een gekozen SIEM-oplossing. Leg gebeurtenisklassen, ontvangers, verantwoordelijke eigenaar, bewaartermijn en bewaking met reactiepad vast. Documenteer elke architectuurafwijking expliciet: deze moet een gelijkwaardig pad bieden dat onafhankelijk van de firewall wordt bewaard en bewaakt; niet elke architectuur vereist dubbele bestemmingen. Alleen regelmatig de lokale Log Viewer controleren is onvoldoende. MDR, XDR en NDR zijn geen uitwisselbare logarchieven. Controleer met een goedgekeurde, onschadelijke testgebeurtenis de levering aan elke beoogde bestemming, het terugvinden in opgeslagen logs en het bewakings-/alarmpad. Corrigeer bij ontbrekende levering gebeurteniskeuze, verbinding en ontvangers en test opnieuw. Controleer ook bewaartermijn en rechten op de bestemming.

Selecteer daarnaast onder System services > Notification list de vereiste systeemgebeurtenissen voor e-mail of SNMP. Configureer eerst het e-maildoel onder Administration > Notification settings, of de SNMP-agent en community of gebruiker onder Administration > SNMP. Na Save moet een veilig, gecontroleerd gebeurtenis de bedoelde ontvanger bereiken; zo niet, controleer dan eerst e-mail- of SNMP-doel, bereikbaarheid en geselecteerde gebeurtenisklasse.

De technische Syslog-inrichting staat in Sophos Firewall Syslog veilig naar SIEM sturen. Voor centrale rapporten past Sophos Firewall Central Reporting activeren en beheren. Als NDR en Active Threat Response relevant zijn, helpt Sophos Firewall NDR en Active Threat Response beheren.

Wijzigingen valideren en veilig terugdraaien

Voer hardening uit in kleine, traceerbare stappen. Noteer vóór elke wijzigingsgroep de huidige waarde, eigenaar en geplande terugweg. Wijzig daarna slechts één gebied, bijvoorbeeld Device Access, een firewallregel of de actie van een Threat Feed. Test zowel het verwachte toegestane pad als een bewust geweigerd pad en controleer de relevante logs. Ga pas daarna verder met het volgende gebied.

Zet voor rollback alleen de laatst gewijzigde instelling terug naar de gedocumenteerde beginwaarde. Houd bij Device Access zowel de bestaande adminsessie als een vooraf geteste, onafhankelijke beheerroute beschikbaar. Verwijder de vorige regel niet voordat de smallere vervanging met succes is gevalideerd. Start Threat Feeds met Monitor, beoordeel treffers en mogelijke false positives en schakel pas daarna over naar Block; veroorzaakt blokkeren problemen, ga dan terug naar Monitor en voeg alleen geverifieerde uitzonderingen toe. Een volledige backuprestore is geen handige Undo-knop, maar het recoverypad voor grotere storingen.

Compacte hardening-checklist

Gebruik voor een eerste review deze volgorde:

1. WAN-toegang tot WebAdmin en SSH beperken, User Portal uitgeschakeld houden en vereiste VPN Portal-bereikbaarheid voor downloads en SSO behouden en testen.
2. MFA voor admins en Remote Access activeren.
3. Lokale adminaccounts, rollen en wachtwoordregels opschonen.
4. Firmware, hotfixes, pattern updates en supportstatus controleren.
5. Backup, SSMK, restore-pad en recoverytest documenteren.
6. DNAT-, WAF- en VPN-publicaties op noodzaak beoordelen; VPN-groepen/resources beperken, Open group niet autoriseren en toegestane en geweigerde toegang testen.
7. Regels met Any, ontbrekende logging of onduidelijke eigenaar opschonen.
8. IPS, Spoof Protection, DoS Settings en Threat Feeds gericht activeren.
9. Web-, DNS-, TLS- en Zero-Day Policies gefaseerd invoeren.
10. Health Check, onafhankelijk bewaarde en bewaakte logs, leveringstests, alerts en regelmatige reviews met eigenaar en bewaartermijn vastleggen.

Veelvoorkomende fouten

WAN-toegang blijft open uit gemak

WebAdmin- of SSH-toegang wordt geopend voor een supportcase en daarna vergeten. Juist zulke tijdelijke uitzonderingen moeten met einddatum, eigenaar en nacontrole worden gedocumenteerd.

Threat Feeds worden zonder beheerconcept geactiveerd

Threat Feeds zijn sterk, maar niet onderhoudsvrij. Zonder monitoring, allowlist en false-positive-proces kan een legitieme partner, dienstverlener of clouddienst worden geblokkeerd. Daarom eerst met Monitor of beperkte scope testen en daarna netjes naar Block overschakelen.

Logging ontbreekt bij kritieke regels

Als een publieke DNAT-regel, WAF-regel of VPN-regel niet logt, is er tijdens een incident te weinig zichtbaarheid. Minstens security-relevante ingangen, admin-toegang, deny-regels en kritieke segmentovergangen moeten traceerbaar zijn.

Health Check wordt als eenmalige taak gezien

Een goede score na setup is geen permanente toestand. Nieuwe regels, nieuwe VPN-gebruikers, tijdelijke uitzonderingen en firmwarewijzigingen kunnen de situatie veranderen. Hardening heeft een reviewritme nodig.

FAQ