Sophos Firewall WAF: Webserver veilig publiceren

Met Web Server Protection of Web Application Firewall (WAF) publiceert men interne of cloudgebaseerde webapplicaties via de Sophos Firewall. De firewall fungeert als reverse proxy: clients verbinden zich met het openbare adres van de firewall, de firewall controleert HTTP- of HTTPS-verkeer en stuurt het verzoek door naar de beveiligde webserver.

Voor de bredere hardening-context past de hub Sophos Firewall Hardening: best practices voor een veilige configuratie.

Een WAF-regel vervangt niet automatisch veilige applicatieontwikkeling, patching, sterke authenticatie of serverhardening. In vergelijking met eenvoudige poortdoorschakeling vermindert deze echter aanzienlijk het aanvalsoppervlak, omdat HTTP(S)-verkeer gerichter kan worden gecontroleerd, beperkt en gelogd.

WAF is echter niet automatisch de juiste oplossing voor elke publicatie. Het is cruciaal of de applicatie daadwerkelijk goed functioneert via HTTP of HTTPS, of de firewall hostnamen en paden moet evalueren en of de extra reverse-proxylaag bij de applicatie past.

PHP2Shell – stand van 24 oktober 2026: Voor CVE-2026-109618 en CVE-2026-109619 vermeldt Sophos in het advisory van 22 oktober, versie 4 geen specifieke bescherming door Sophos Firewall WAF. Getroffen PHP-runtimes op de backend moeten worden bijgewerkt; publicatie via WAF vervangt deze update niet. De IPS-signatures die sinds 22 oktober beschikbaar zijn, dienen om aanvalspogingen te detecteren. Controleer afzonderlijk of een passend IPS-beleid het werkelijke gegevenspad inspecteert en welke actie het uitvoert; de IPS-handleiding helpt daarbij. Het ontbreken van een alarm bewijst niet dat de patches op orde zijn.

Beslissing vóór publicatie

Voordat men een WAF-regel maakt, moet duidelijk zijn of WAF, DNAT, VPN of ZTNA bij de applicatie past. Deze beslissing is belangrijker dan het configuratiescherm in de firewall zelf, omdat ze het aanvalsoppervlak, het beheer en de troubleshooting bepaalt.

Wanneer WAF in plaats van DNAT zinvol is

Voor eenvoudige TCP- of UDP-diensten gebruikt men nog steeds NAT en firewallregels. Voor webapplicaties is WAF vaak de betere keuze.

DNAT past voor niet-HTTP-diensten, eenvoudige poortdoorschakelingen en speciale protocollen. De firewall vertaalt dan primair het verkeer en staat het toe.
WAF / Web Server Protection past voor HTTP- en HTTPS-toepassingen wanneer hostnaam, certificaat, paden, beschermingsprofielen, authenticatie of landregels relevant zijn.
Reverse proxy of ZTNA past voor complexe webplatforms, identiteitsintegratie en privétoepassingen wanneer toegang sterk gecontroleerd of helemaal niet openbaar moet zijn.

Als alleen snel een interne webserver via poortdoorschakeling toegankelijk moet worden gemaakt, helpt de handleiding Server publiceren via DNAT op Sophos Firewall. Voor openbare webapplicaties moet men eerst WAF beoordelen.

⚠️ WebDAV wordt niet ondersteund door Sophos WAF. Applicaties zoals Nextcloud moeten daarom niet blindelings via WAF worden gepubliceerd, maar via passende firewall- en NAT-regels of een andere publicatiearchitectuur worden gepland.

Beslissing: WAF, DNAT of privétoegang

De belangrijkste vraag is niet hoe snel een publicatie is opgezet, maar of deze later veilig kan worden beheerd, getest en teruggedraaid. Deze indeling helpt vóór de technische implementatie:

Openbare website of eenvoudige HTTPS-toepassing: WAF is meestal het passende startpunt. DNS, certificaat, hostnaam, beschermingsprofiel, logging en backend-bereikbaarheid moeten worden getest.
Klantenportaal, partnerportaal of beheerdersinterface: WAF met bronbeperking en optioneel MFA kan zinvol zijn. Vooraf moet worden nagegaan of WAF-MFA, landregels of vaste bronnetwerken mogelijk zijn.
Pure TCP- of UDP-dienst: DNAT is meestal passender. Firewallregel, NAT-regel, doelserver, retourroute en logging moeten gezamenlijk worden gecontroleerd.
Webapplicatie met WebDAV of speciaal protocol: WAF niet automatisch gebruiken. Ondersteunde functies, clientgedrag en alternatieve publicatie testen.
Applicatie alleen voor interne gebruikers: VPN, ZTNA of sterk beperkte WAF beoordelen. Openbare bereikbaarheid moet kritisch worden beoordeeld.

Voor privétoepassingen biedt een wereldwijd bereikbare WAF-regel vaak een te groot aanvalsoppervlak. Als slechts enkele personen toegang nodig hebben, zijn vaste bronnetwerken, VPN, ZTNA of een andere privétoegangsarchitectuur vaak een zuiverdere oplossing dan een openbare webpublicatie.

Planning en vereisten

Een stabiele WAF-publicatie vereist DNS, een certificaat, backend-bereikbaarheid, logging en een rollback-plan. Deze punten moeten vóór de configuratie vaststaan.

Vereisten

Voor de eerste WAF-regel moet men deze punten verduidelijken:

Openbare DNS-naam, bijvoorbeeld portal.example.com
Openbaar IP-adres of alias op de WAN-interface
Certificaat voor de gepubliceerde hostnaam
Intern IP-adres of FQDN van de webserver
Interne doelpoort van de webserver
Beslissing of HTTP naar HTTPS wordt omgeleid
Toegestane bronnetwerken, landen of gebruikersgroepen
Passend beschermingsprofiel en optioneel IPS-beleid
Geactiveerde logging voor latere analyse
Externe testtoegang buiten het eigen LAN

De openbare DNS-naam moet wijzen naar het adres dat in de WAF-regel als Hosted address wordt gebruikt. Bij HTTPS moet het certificaat overeenkomen met de gepubliceerde hostnaam.

Daarnaast heeft de firewall een webserver-object nodig onder Web server > Web servers. Daar wordt de interne of externe doelserver beschreven met host, protocol en poort. De host is een IP- of FQDN-hostobject. Voor backends zijn HTTP of HTTPS mogelijk; standaardpoorten zijn 80 en 443. Als de backend-webserver lange antwoorden levert of keep-alive nodig heeft, moeten Keep alive en Timeout bewust worden gecontroleerd in plaats van zomaar overgenomen.

De backend-Timeout kan tussen 1 en 65,535 seconden liggen; standaard is 300 seconden. Na het verstrijken stuurt de WAF de client 502. Disable backend connection pooling forceert voor elke toegang een nieuwe backendverbinding en kan de prestaties verlagen. Gebruik deze optie daarom alleen voor gerichte foutanalyse en zet deze daarna terug naar de gedocumenteerde eerdere instelling.

Daarnaast moet men de grenzen van Web Server Protection vroeg meenemen. Sophos noemt onder meer een limiet van 60 WAF-regels per firewall. Dat is voor veel omgevingen voldoende, maar kan bij veel klantenportalen, tenants, testsystemen of gescheiden hostnamen sneller relevant worden dan verwacht. Dan moet men niet blind extra losse regels bouwen, maar naamconcept, paden, virtuele webservers en alternatieve publicatieroutes controleren.

SFOS 22 ondersteunt geen WAF-regels via IPv6. Een applicatie mag daarom met deze functie niet als IPv6-publicatie worden gepland; het overzicht IPv6-ondersteuning en beperkingen in Sophos Firewall met SFOS 22 onderscheidt WAF van de ondersteunde IPv6-regel- en beveiligingsfuncties. Ook de Exchange-sjablonen zijn geen vrijbrief voor moderne Exchange-omgevingen: Sophos documenteert dat WAF-regels momenteel geen Exchange-versies na 2013 ondersteunen.

De vooraf geconfigureerde sjablonen komen uit een ouder Microsoft-applicatielandschap: Exchange Autodiscover, Outlook Anywhere en Exchange General stoppen bij deze Exchange 2013-grens; de overige Sophos-handleidingen noemen Microsoft Lync, Remote Desktop Gateway of RD Web 2008/R2 en SharePoint 2010/2013. Ze vormen daarom geen actuele basis voor Microsoft 365, moderne Exchange-versies, Teams of huidige RDS-implementaties. Vergelijk vóór gebruik de daadwerkelijk benodigde paden, authenticatiemethoden en beschermingsprofielen met de actuele Microsoft-architectuur; laat voor een moderne applicatie Preconfigured template bij twijfel op None staan.

Backend-object aanmaken met een duidelijk voorbeeld

De openbare naam en de backend-naam vervullen verschillende taken. In het volgende voorbeeld openen gebruikers portal.example.com; de firewall bereikt de server via backend.example.com. Beide namen zijn placeholders en moeten worden vervangen door de eigen DNS-namen. De backend-naam moet vanuit het perspectief van de firewall naar de daadwerkelijke server verwijzen, niet opnieuw naar het eigen openbare WAF-adres: anders ontstaat er geen bruikbare route naar de backend.

Maak onder Hosts and services > FQDN host > Add een object met de naam WAF_Backend_Portal en FQDN backend.example.com aan en sla het op. Gebruik als alternatief een IP-hostobject voor een vaste backend-server. Volgens de productdocumentatie bieden FQDN-hosts een bredere servercompatibiliteit; DNS-resolutie en doelserver moeten desondanks worden gecontroleerd.
Maak onder Web server > Web servers > Add een webserver-object WAF_Portal_Server aan en selecteer onder Host het backend-object.
Stel Type en Port in op basis van de daadwerkelijke backend-listener: in het HTTPS-voorbeeld HTTPS en 443, bij een HTTP-backend HTTP en bijvoorbeeld 80. De externe luisterpoort wordt pas in de WAF-regel ingesteld en hoeft niet gelijk te zijn aan de backend-poort. Beveilig bij een HTTP-backend het onversleutelde segment bewust; een HTTPS-frontend alleen versleutelt dit segment niet.
Activeer Keep alive alleen als de webserver hergebruikte verbindingen ondersteunt. Beoordeel Timeout eerst met de standaardwaarde van 300 seconden. Hiermee wordt de wachttijd op gegevens naar of van de backend bedoeld, niet een algemene maximale totale duur van elk verzoek: zolang gegevens op tijd binnenkomen, kan een antwoord langer duren. Controleer bij 502 daarom backend-logs en onderbrekingen in de gegevensoverdracht in plaats van de waarde direct te verhogen.
Activeer Disable backend connection pooling tijdens normaal gebruik niet als prestatieoptimalisatie. Sla het object op, controleer de toewijzing aan de WAF-regel of aan het SFOS-23-Protect-pad en controleer een representatieve toegang tot de backend.

WAF-publicatie plannen vóór configuratie

Een WAF-regel moet niet pas in het configuratiescherm worden gepland. Van tevoren moet duidelijk zijn of de Sophos Firewall alleen moet publiceren of dat deze ook authenticatie, beschermingsprofielen, landregels en logging moet overnemen.

Deze vragen zijn belangrijk vóór een publicatie in productie:

Is het echt een HTTP- of HTTPS-toepassing? Voor andere protocollen is DNAT meestal passender.
Moet de applicatie openbaar toegankelijk zijn? Privébeheerportalen passen vaak beter bij VPN, ZTNA of beperkte bronnetwerken.
Welke hostnaam en welk certificaat worden gebruikt? DNS, SNI, certificaat en WAF-domeinen moeten overeenkomen.
Hoeveel publicaties zijn gepland? De WAF-regellimiet en de latere beheerbaarheid beïnvloeden het ontwerp.
Moet de firewall gebruikers authenticeren? Voor portalen kan WAF-MFA zinvol zijn.
Welke beschermingsprofielen zijn actief? Te brede uitzonderingen verzwakken de WAF, te strenge profielen kunnen de werking van applicaties verstoren.
Hoe wordt er gelogd en getest? Log Viewer, reverseproxy.log en backend-logs moeten vóór de livegang bekend zijn.

Voor certificaten moet vroegtijdig worden verduidelijkt of een bestaand certificaat met privésleutel en CA-keten wordt geïmporteerd, of de firewall zelf een Let’s-Encrypt-certificaat aanmaakt en vernieuwt of dat een extern gegenereerd certificaat nodig is. Voor wildcard-certificaten is er een aparte handleiding: Let’s Encrypt Wildcard Certificaat aanmaken.

WAF-regel configureren

De WAF-regel zelf bestaat uit een openbaar adres, hostnamen, een certificaat, een doelserver, toegestane bronnen en een beschermingsprofiel. Deze velden moeten in samenhang worden bekeken, niet als geïsoleerde opties.

Basisstructuur van een WAF-regel

Een WAF-publicatie bestaat uit meerdere bouwstenen:

Hosted address: openbaar IP-adres of alias waarop clients de applicatie bereiken.
Listening port: openbare poort, meestal 80 of 443.
Domains: hostnamen die bij de WAF-regel moeten passen.
HTTPS certificate: certificaat voor de gepubliceerde hostnaam.
Web server: vooraf aangemaakt webserver-object met host, protocol, poort en verbindingsinstellingen.
Allowed client networks: bronnetwerken die toegang mogen hebben.
Blocked client networks / countries: bronnen of landen die worden geblokkeerd.
Protection policy: WAF-bescherming tegen typische webaanvallen.
Authentication: optionele voorafgaande aanmelding via de firewall.

Sophos maakt WAF-regels in het gedeelte voor firewallregels. De actie heet Protect with web server protection.

Belangrijk: een WAF-regel is geen normale firewallregel met NAT erachter. Er ontstaat een reverse-proxypublicatie. Daarom moeten Hosted address, Listening port, Domains, certificaat, Protected server en Allowed client networks bij elkaar passen. Als een van deze velden niet klopt, lijkt de fout vaak op een certificaat-, DNS- of backendprobleem.

WAF-regel maken

Het menupad is:

Rules and policies > Firewall

Stappen:

Nieuwe regels zijn standaard ingeschakeld. Controleer daarom voor een voorbereide, nog niet vrijgegeven publicatie expliciet de regelstatus en laat de regel uitgeschakeld tot de geplande go-live. Rule position biedt Top of Bottom; Rule group wijst de regel toe aan een bestaande groep of aan een groep die via Create new is aangemaakt. Automatic gebruikt de eerste passende groep op basis van regeltype en bron-/doelzones. Groepering is een hulpmiddel voor beheer, geen vervanging voor de controle van de toegang.

De volgende genummerde procedure met Protected servers geldt alleen voor SFOS 22 en blijft voor deze versie ongewijzigd. WAF-regels ondersteunen alleen IPv4. De regelactie Protect with web server protection is niet gelijk aan de padspecifieke Action > Protect onder Traffic routing in SFOS 23; voor SFOS 23 geldt de afzonderlijke handleiding direct na deze procedure.

Selecteer IPv4.
Open Add firewall rule.
Kies New firewall rule.
Geef een duidelijke regelnaam.
Stel Rule position bewust in, vooral als er al algemenere WAF-regels of oude publicaties bestaan.
Kies bij Action de optie Protect with web server protection.
Laat Preconfigured template op None als er geen speciale sjabloon nodig is.
Definieer onder Hosted server details het openbare adres, de luisterpoort, HTTPS, certificaat en domeinen.
Selecteer onder Protected servers het passende webserver-object of maak dit eerst aan onder Web server > Web servers.
Stel Allowed client networks bewust in. Voor openbare websites kan Any IPv4 nodig zijn; voor portalen is een beperking meestal beter.
Stel indien nodig Blocked client networks of Blocked countries in.
Controleer onder de geavanceerde beleidsregels bewust Protection, Intrusion prevention en Traffic shaping.
Sla de regel op en test extern.

SFOS 23: Paden publiceren onder Traffic routing

Maak of bewerk onder Rules and policies > Firewall een IPv4-regel. Kies als regelactie Action nog steeds Protect with web server protection en configureer het openbare adres, de poort, het HTTPS-certificaat en de domeinen passend. Een nieuwe regel bevat standaard / met Block: zonder aanvullende routingconfiguratie worden verzoeken afgewezen, niet gepubliceerd.
Bewerk of voeg onder Traffic routing met Edit of Add new path het specifiek bedoelde pad toe. Kies bij Action expliciet Protect en wijs de benodigde backend-objecten uit Web server > Web servers toe. Een sjabloon maakt wel paden met Protect aan, maar vereist nog steeds de backend-toewijzing.
Wijs voor elk beschermd pad het bedoelde authenticatiebeleid toe in het veld Authentication en stel Allowed client networks bewust in; laat dit niet leeg. Controleer Blocked client networks, Blocked countries en Block IP addresses of unknown country-origin gericht; houd bij onbekende landenherkomst ook rekening met het risico van een eigen lockout.
Als alleen bepaalde paden moeten worden gepubliceerd, behoud / dan bewust met Block als opvangroute. Zet / alleen op Protect als de volledige applicatie moet worden gepubliceerd; controleer expliciet de backend, authenticatie, toegangsbeperkingen en de applicatiedelen die daardoor bereikbaar worden. Langere, specifiekere paden worden eerst geëvalueerd, niet de tabelvolgorde.
Maak onderscheid tussen de acties: Block wijst verzoeken voor het gekozen pad af en stuurt ze niet door naar de backend. Protect past de beschermingspolicy van de regel en de geconfigureerde authenticatie- en toegangsinstellingen toe. Redirect stuurt de client een omleiding naar het geconfigureerde doel, in plaats van een backend te publiceren. Passthrough maakt een tunnel naar de backend zonder WAF-inspectie en zonder toepassing van de beschermingspolicy. Protection geldt alleen voor paden met Protect.
Test na het opslaan extern een bedoeld toegestaan pad, een bewust geblokkeerd pad en een pad zonder specifieke overeenkomst. Controleer, indien gebruikt, ook Redirect en Passthrough afzonderlijk. Correleer het clientresultaat, Log Viewer, reverseproxy.log en backend-logs aan de hand van hetzelfde verzoek en hetzelfde tijdstip.

Het standaardpad kan worden bewerkt, gekloond of verwijderd. Een kloon neemt geen inhoudelijke vrijgave over: controleer de actie, backend, authenticatie en bronnen opnieuw voor de nieuwe toewijzing. Verwijder / niet per ongeluk als dit de bewust blokkerende opvangroute vormt.

Bestaande regels na de upgrade: Volgens de Sophos-documentatie worden bestaande WAF-regels bij de upgrade naar SFOS 23 automatisch omgezet naar Protect; bestaande padspecifieke routes blijven behouden. Dit verschilt van de standaardinstelling / met Block bij nieuwe regels en van de oudere SFOS 18-migratie van ModSecurity Protection Policies. Controleer na de upgrade toch voor elk pad de actie, backend, authenticatie, toegangsbeperkingen en daadwerkelijke route en voer een externe acceptatietest uit; automatische migratie vervangt geen acceptatie.

Duiding van de handleiding: De Sophos-handleiding over het beschermen van een webserver tegen aanvallen gebruikt nog steeds de procedure met Protected servers en noemt IPv4 or IPv6, hoewel de WAF-regelreferentie WAF tot IPv4 beperkt. Deze handleiding is daarom geen volledige SFOS 23-routinghandleiding. Voor de actuele configuratie gelden IPv4 en de expliciete padacties hierboven.

Wanneer de regel wordt opgeslagen, start Sophos de Web Server Protection-regels opnieuw. Bestaande liveverbindingen via deze regels kunnen daardoor worden onderbroken. Wijzigingen aan productieve WAF-regels moeten daarom in een onderhoudsvenster of op zijn minst bewust worden uitgevoerd.

Als Allowed client networks leeg blijft, werkt de WAF-regel niet correct; de browser kan dan een 400 Bad Request krijgen. Voor een openbare applicatie is Any IPv4 wel mogelijk, maar niet automatisch juist. Voor beheerportalen, partnerportalen of interne tools moet men eerst vaste bronnetwerken, landenbeperking, WAF-MFA, VPN of ZTNA beoordelen.

Poortconflicten moeten vóór het opslaan worden opgehelderd. WebAdmin en User Portal hebben elk een unieke poort nodig. WAF en VPN Portal gebruiken beide TCP; als ze dezelfde poort gebruiken, moeten hun Hosted address of WAN-IP-adressen daarom verschillen. WAF kan van SSL VPN verschillen door het WAN-IP-adres, de poort of het protocol, omdat SSL VPN TCP of UDP ondersteunt. Alleen een andere FQDN- of SNI-naam is niet voldoende om deze listeners van elkaar te scheiden. Als een andere dienst of een oude DNAT-publicatie al op een openbaar IP-adres luistert, moet de toewijzing vóór de go-live per IP-adres, poort en protocol worden getest.

De standaardpoort van het User Portal is 4443; portal-listeners en hun beperkingen worden toegelicht in het portaloverzicht.

SFOS 23: Block- en Redirect-antwoorden concreet instellen

Een routingactie kan meerdere vermeldingen onder Paths combineren als ze allemaal dezelfde afhandeling nodig hebben. Selecteer onder Traffic routing > Add new path de paden en de actie, vul de actieafhankelijke velden in en sla de padvermelding op. Gebruik afzonderlijke vermeldingen bij verschillende backends, toegangsregels of omleidingsdoelen.

Voor Block bepaalt Response code het antwoord. Een voorbeeld is /admin/ met Forbidden (403), terwijl / als opvangroute op Block blijft staan. De gedocumenteerde selectie omvat 400 tot 417 en daarnaast 422, 423, 424 en 426. Kies de code op basis van de bedoelde boodschap: 403 staat voor geweigerde toegang, 404 voor niet gevonden inhoud. Een gekozen 401-code stelt geen authenticatiebeleid in; de statuscode alleen biedt geen bescherming via aanmelding. Controleer bij de acceptatietest de geconfigureerde status en het uitblijven van een overeenkomstig backend-verzoek.

Voor Redirect behoren naast Paths en Action de velden Response code, Protocol, Host, Path en Port tot de configuratie. Voorbeeld: /old-portal/ met Temporary Redirection (307), Protocol HTTPS, een FQDN-host voor portal.example.com, Path /portal/ en Port 443. Vervang namen en paden door die van de eigen doelapplicatie. 307 duidt op een tijdelijke omleiding met behoud van de requestmethode; dit is geschikt voor een gecontroleerde pilot als het doel dezelfde methode verwerkt. Test browser en API-client toch afzonderlijk, met name POST-verzoeken. Het doel /portal/ moet zelf bereikbaar en beschermd zijn, bijvoorbeeld via een passend Protect-pad; een omleiding alleen maakt daar geen backend- of toegangsconfiguratie aan.

De selectie biedt 300, 301, 302, 303, 304, 305, 307 en 308. Niet elke aangeboden code is een gewone omleiding naar een nieuwe pagina: 304 beschrijft cachevalidatie. 305 is vanwege beveiligingsbezwaren verouderd en wordt niet aanbevolen voor openbare applicaties. Gebruik 301 of 308 pas als een permanente omschakeling is bedoeld en houd bij het terugdraaien rekening met het client- en cachegedrag. De standaardpoorten van het doel zijn 80 voor HTTP en 443 voor HTTPS. Redirect voert geen WAF-inspectie uit en stuurt het verzoek niet naar een backend van deze route; controleer daarom op de client de status en het omleidingsdoel en vervolgens de bescherming van de doelapplicatie.

Host Header, HTML en compressie gericht aanpassen

De Advanced settings van een WAF-regel helpen bij concrete reverse-proxyproblemen. Het zijn geen opties die standaard allemaal moeten worden ingeschakeld:

Pass host header geeft de door de client aangevraagde Host Header door aan de backend. Bij meerdere websites op één server kan daardoor de juiste virtuele host worden gekozen. Configureer de backend-vHost passend bij de gepubliceerde naam en controleer in het toegangslog dat er geen andere website antwoordt.
Rewrite HTML past links in geretourneerde pagina’s aan. Als bijvoorbeeld een absolute link naar http://backend.example.com/ verwijst, terwijl de applicatie via de openbare naam wordt gepubliceerd, kan herschrijven nodig zijn. Bij al passende openbare hostnamen of uitsluitend relatieve links is dit doorgaans niet nodig. De verwerking betreft Content-Types text/* en *xml*; binaire downloads moeten met het juiste Content-Type worden geleverd, anders kunnen ze beschadigd raken. Test daarna openbare links, downloads en applicatiefuncties afzonderlijk.
Rewrite cookies herschrijft cookies in de geretourneerde pagina’s. Onderzoek bij sessieproblemen de daadwerkelijk ingestelde cookies en het in- en uitloggen, in plaats van cookieherschrijving te verwarren met Cookie signing: herschrijving en bescherming tegen manipulatie hebben verschillende functies.
Disable compression support is een gericht hulpmiddel bij verkeerd weergegeven pagina’s of Content-Encoding-fouten. De firewall vraagt dan ongecomprimeerde gegevens op bij de backend en levert ze ongecomprimeerd, ongeacht de aangevraagde encoding. Documenteer de eerdere toestand, herhaal hetzelfde paginaverzoek en schakel de optie weer uit als deze de fout niet verhelpt.

Sommige poorten zijn gereserveerd voor systeemdiensten, ook als de betreffende dienst niet wordt gebruikt. Een vrije listener alleen maakt zo’n poort niet beschikbaar voor WAF; het overzicht Gereserveerde poorten van de Sophos Firewall helpt bij de planning. Traffic shaping wijst bandbreedte en tijdsafhankelijke prioritering toe aan de publicatie. Dat is een beheerbeslissing, geen aanvullende applicatiebescherming; controleer uploads en downloads bij een ingeschakelde policy ook onder representatieve belasting.

Go-live en acceptatie

Na het opslaan van de regel is de publicatie nog niet voltooid. Pas externe tests, passende logs en een duidelijke rollback maken de wijziging gereed voor productie.

Go-live en rollback plannen

Een WAF-publicatie moet niet als voltooid worden beschouwd zodra de regel is opgeslagen. Het is cruciaal of DNS, certificaat, Hosted address, backend, beschermingsprofiel en logging samen functioneren. Vooral bij bestaande poortdoorschakelingen moet men de overgang als een kleine publicatie behandelen.

Voor de go-live controleren:

Documenteer de huidige firewallconfiguratie of op zijn minst de betrokken regel- en certificaatinstellingen.
Identificeer eerdere DNAT- of firewallregels die dezelfde poort, hetzelfde openbare IP of dezelfde hostnaam betreffen.
Deactiveer oude DNAT-regels of documenteer duidelijk waarom ze niet concurreren met de WAF-regel.
Verlaag de DNS-TTL vóór een overgang als de openbare hostnaam van een oude publicatie naar de WAF verandert.
Zorg voor externe testtoegang, test niet alleen vanuit het interne LAN.
Definieer testgevallen: startpagina, inloggen, uploaden, downloaden, API-pad, WebSocket, uitloggen en foutmelding.
Stel verwachte loglocaties vast: Log Viewer, reverseproxy.log, backend-toegangslog en backend-foutenlog.
Stel een rollback-criterium vast, bijvoorbeeld inloggen niet mogelijk, backend niet bereikbaar, verkeerd certificaat, hoog foutenpercentage of kritieke applicatiedelen defect.

Bij de overgang moet telkens slechts één publicatie actief zijn. Als een oude DNAT-regel en een nieuwe WAF-regel hetzelfde openbare IP en dezelfde poort gebruiken, is het gedrag moeilijk te doorgronden. Vóór de productieve omschakeling moet duidelijk zijn welke regel het verkeer daadwerkelijk verwerkt.

Een eenvoudige rollback bestaat vaak uit het deactiveren van de nieuwe WAF-regel en het opnieuw activeren van de vorige publicatie. Als daarnaast DNS is gewijzigd, moet rekening worden gehouden met de DNS-TTL. Bij certificaat- of hostnaamproblemen is een rollback via DNS alleen vaak te traag; in dergelijke gevallen moet de oude regel op hetzelfde Hosted address weer kunnen worden geactiveerd of moet er een alternatieve toegang beschikbaar zijn.

Na de go-live moeten de eerste toegangen actief worden bewaakt. Belangrijk zijn niet alleen succesvolle HTTP-statuscodes, maar ook WAF-blokkeringen, backend-fouten, onverwachte omleidingen, sessieproblemen en ontbrekende client-IP-informatie in de backend-logs.

Acceptatietest na de go-live

Een WAF-test is pas compleet als hetzelfde verzoek vanuit drie perspectieven kan worden nagevolgd: client, firewall en backend. Hierdoor herkent men sneller of een probleem bij DNS, certificaat, WAF-matching, beschermingsprofiel of applicatie ligt.

Externe client: DNS-resolutie, certificaat, HTTP-status, login en belangrijke paden controleren. De applicatie moet via de openbare hostnaam zonder certificaatwaarschuwing openen.
Sophos Firewall: Log Viewer, WAF-regel, reverseproxy.log en geblokkeerde signatures controleren. De juiste WAF-regel moet de toegang verwerken en logs moeten toegestane of gerechtvaardigd geblokkeerde requests tonen.
Backend-webserver: toegangslog, foutenlog, applicatiesessie en X-Forwarded-For controleren. Het request moet de juiste vHost of het juiste pad bereiken en de client-IP-logica moet duidelijk zijn.

Voor productieve applicaties moeten ten minste deze gevallen worden getest:

Oproep via de juiste hostnaam en via een niet-passend domein.
Inloggen met een geldige en ongeldige gebruiker, als de applicatie of WAF authenticatie uitvoert.
Upload, download, API- of WebSocket-functie, als de applicatie dergelijke functies gebruikt.
Toegang vanuit een toegestane bron en, indien mogelijk, vanuit een bewust niet-toegestane bron.
Gedrag van een bekende onschadelijke WAF-testaanvraag, zodat logging en blokkeerpad zichtbaar zijn.

Als de applicatie na de go-live ogenschijnlijk werkt, maar er geen passende logs zichtbaar zijn, is de test nog niet voltooid. Dan kan het zijn dat een andere publicatie overeenkomt, logging ontbreekt of de toegang niet via het verwachte pad verloopt.

Bescherming en toegang beveiligen

Bij openbare webapplicaties is de WAF slechts één beschermingslaag. Certificaten, bronbeperkingen, Threat Feeds, beschermingsprofielen en backend-logging moeten gezamenlijk worden gepland.

Certificaten en hostnamen

Voor HTTPS moet de WAF-regel een certificaat gebruiken dat overeenkomt met de openbare hostnaam. Het certificaat wordt geïmporteerd of aangemaakt onder Certificates > Certificates en vervolgens geselecteerd in de WAF-regel.

Belangrijke punten:

De DNS-naam moet overeenkomen met het certificaat.
Het geselecteerde HTTPS-certificaat kan de domeinlijst in de WAF-regel automatisch vullen of bestaande domeinvermeldingen overschrijven.
Bij meerdere hostnamen op hetzelfde IP gebruikt de firewall SNI.
Wildcard-certificaten zijn mogelijk, maar moeten goed worden gedocumenteerd.
Wildcard-domeinen worden pas gebruikt na specifiekere domeinregels. *. is alleen aan het begin toegestaan, bijvoorbeeld *.example.com; meerdere wildcard-domeinen in één regel zijn mogelijk.
Underscores in het linker domeinlabel zijn geen nette DNS-naam en moeten voor WAF-domeinen worden vermeden.
De backend kan een andere interne naam gebruiken, mits Host Header en applicatie daarmee kunnen omgaan.
Bij problemen met absolute links kan Rewrite HTML relevant worden.

Als meerdere virtuele webservers via hetzelfde IP en dezelfde poort draaien, beslist de firewall bij HTTPS op basis van SNI en hostnaam welke WAF-regel past.

De Domains in de WAF-regel moeten daarom exact passen bij DNS en certificaat. Wildcards kunnen nuttig zijn, maar mogen geen vervanging zijn voor een schoon publicatieconcept. Als meerdere applicaties onder vergelijkbare hostnamen draaien, is duidelijke regel- en certificaatdocumentatie nodig; anders wordt later moeilijk te achterhalen welke WAF-regel werkelijk matcht. Een test met een bewust niet-passend subdomein is zinvol: dan ziet men of de specifieke regel, een wildcard-regel of geen passende virtuele webserver antwoordt.

De naam van het certificaatobject mag alleen alfanumerieke tekens uit de US-ASCII-tekenset bevatten; dit is niet hetzelfde als de DNS-naam in het certificaat. Controleer na de selectie de automatisch overgenomen Domains en bewerk, vul aan of verwijder ze indien nodig. HTTPS maakt de listener bereikbaar via HTTPS, niet daarnaast ook via HTTP. Redirect HTTP leidt toegangen afzonderlijk om van poort 80 naar poort 443; plan daarom ook deze listeners en mogelijke poortconflicten.

Bij een niet-passende subdomeinnaam hoeft geen grafische blokkeerpagina te verschijnen. De documentatie toont bijvoorbeeld 403 bij een aanvraag via een ander subdomein. Controleer daarom de HTTP-status en reverseproxy.log, niet alleen het uiterlijk van de browserpagina.

Client-IP en backend-logs plannen

Bij WAF-publicaties ziet de interne webserver vaak niet het echte client-IP als direct bronadres. De Sophos Firewall werkt als een reverse proxy en bouwt zelf de verbinding met de backend op. Voor de applicatie en de webserver-logs kan daarom eerst het firewall-adres zichtbaar zijn.

Als de applicatie of de backend het oorspronkelijke client-IP nodig heeft, moet vroegtijdig worden gecontroleerd of X-Forwarded-For of een vergelijkbare header wordt geëvalueerd. Dit is belangrijk voor:

Applicatielogs en beveiligingsevaluatie
Rate limits of inlogbeveiliging op applicatieniveau
Foutanalyse met gebruikers- of bron-IP-referentie
SIEM- of monitoringcorrelatie
Forensische evaluatie na een incident

Belangrijk is de vertrouwensgrens: een backend moet dergelijke headers alleen als betrouwbaar beschouwen als het verzoek echt van de Sophos Firewall of een gedefinieerde reverse proxy komt. Openbare clients mogen X-Forwarded-For niet direct als beveiligingsbewijs kunnen instellen. In de praktijk moet de webserver daarom alleen het firewall-IP vertrouwen en headers uit andere bronnen negeren of overschrijven.

Voor troubleshooting betekent dit: Log Viewer, reverseproxy.log en backend-log moeten hetzelfde testtijdstip dekken. Als in de backend alleen het firewall-IP zichtbaar is, is dat niet automatisch een WAF-fout, maar vaak normaal reverse-proxygedrag.

Clienttoegang beperken

Niet elke webapplicatie hoeft wereldwijd bereikbaar te zijn. Al in de WAF-regel kan de toegang worden beperkt.

Zinvolle beperkingen:

Alleen bekende bron-IP-adressen of partnernetwerken toestaan.
Niet benodigde landen blokkeren.
IP-adressen van onbekende landenherkomst alleen blokkeren als het risico van een eigen lockout is beoordeeld.
Voor portalen daarnaast WAF-MFA of voorafgaande authenticatie gebruiken.
Bekende kwaadaardige bronnen via Threat Feeds blokkeren.

Voor landen- en kwaadaardige-IP-blokkering helpt Sophos Firewall: Landen en kwaadaardige IP’s blokkeren. Voor dynamische dreigingslijsten is Sophos Firewall Threat Feeds relevant.

Threat Feeds en Active Threat Response inplannen

Bij openbaar toegankelijke webapplicaties moet men niet alleen de WAF-regel zelf bekijken. Sinds SFOS 22 worden Threat Feeds ook voor inkomend, doorgestuurd verkeer zoals WAF- en DNAT-publicaties relevanter. De firewall kan dergelijke treffers met MDR Threat Feeds, NDR Essentials en Third-Party Threat Feeds vergelijken.

Voor beheerders betekent dit: WAF is de publicatielaag, Threat Feeds en Active Threat Response kunnen extra bekende kwaadaardige bronnen blokkeren of zichtbaar maken. Dit vervangt echter geen patchbeheer, geen deugdelijke authenticatie en geen applicatiehardening.

Praktisch moet worden gecontroleerd:

Is Active Threat Response in de omgeving zinvol geconfigureerd?
Worden relevante Threat Feeds ingezet en regelmatig gecontroleerd?
Zijn WAF-events, Active-Threat-Response-logs en backend-logs tijdens het beheer zichtbaar?
Is er een proces voor false positives, allowlisting en noodtoestemmingen?
Is het duidelijk wie op treffers reageert en of alleen wordt gelogd of actief wordt geblokkeerd?

Vooral bij klantenportalen, beheerdersinterfaces of partnertoegangen moet deze controle vóór de go-live plaatsvinden. Als een feed later productief verkeer blokkeert, moet het beheerteam weten waar de treffer zichtbaar is en hoe men zorgvuldig beslist: echte aanval, vals alarm of verkeerd gepubliceerde applicatie.

Beschermingsprofielen en uitzonderingen

Een WAF-regel moet niet alleen publiceren, maar ook beschermen. Hiervoor gebruikt men Protection Policies, optionele IPS-policies en uitzonderingen.

Typische beschermingsgebieden:

Cookiemanipulatie
URL-hardening
Formulierhardening
Cross-site scripting
Applicatie-aanvallen
Antiviruscontrole
Clients met een slechte reputatie

Onder Web server > General settings staan aanvullende globale instellingen voor Web Server Protection, waaronder TLS-versiebeheer en bescherming tegen langzame HTTP-DoS-patronen. Deze instellingen gelden niet alleen voor één regel. Wijzigingen moeten daarom bewust worden gepland en met bestaande WAF-publicaties worden afgestemd.

SFOS 23: Worker-profiel gericht aanpassen

Onder Web server > General settings > Worker customization berekent de firewall de standaardwaarden op basis van de beschikbare CPU- en RAM-resources; deze zijn geschikt voor de meeste installaties. Hogere waarden kunnen de WAF-prestaties en systeemresources negatief beïnvloeden. Activeer Use custom worker profile daarom alleen nadat de noodzaak is gecontroleerd en de gevolgen zijn beoordeeld. Documenteer vooraf de huidige waarden en of het profiel berekend of aangepast is, maak een configuratieback-up en plan een onderhoudsvenster en een rollback naar precies die eerdere toestand. Deze aanpassing is geen wijziging van Maximum sessions.

Start servers: Aantal worker-processen dat bij het starten van de webserver wordt gestart.
Server limit: Maximumaantal worker-processen dat gelijktijdig kan worden uitgevoerd.
Minimum spare threads: Minimumaantal inactieve threads dat beschikbaar wordt gehouden voor nieuwe verzoeken.
Maximum spare threads: Maximumaantal inactieve threads voordat overtollige threads worden verwijderd.
Threads per child: Maximumaantal worker-threads per worker-proces.
Asynchronous request worker factor: Regelt de schaling van worker-processen voor asynchrone verbindingen en verzoeken.

Bij formuliergebaseerde reverse-proxyauthenticatie begrenst het globale veld Maximum sessions de gelijktijdige gebruikerssessies van alle WAF-regels die deze authenticatiemethode gebruiken. De standaardwaarde is 25,000; het toegestane bereik loopt van 100 tot 100,000. Zodra de limiet is bereikt, sluit de firewall oude of verlopen sessies om nieuwe toe te laten. Dit is dus geen capaciteit per regel: stem de waarde af op gelijktijdige aanmeldingen van de betrokken toepassingen en controleer na een wijziging aanmelden, afmelden en sessiewisseling.

Bij Slow HTTP protection is Soft limit het aanvankelijk toegestane tijdvenster voor het ontvangen van de requestheader. Hard limit bepaalt de absolute bovengrens. Extension rate legt vast hoeveel extra ontvangen bytes het soft limit met één seconde verlengen. Test deze drie waarden samen en met werkelijk trage clients; één te ruime waarde kan de bescherming onnodig verzwakken.

Beperk uitzonderingen bij Slow HTTP protection tot het kleinst noodzakelijke IP-adres of netwerk. Sophos ondersteunt hier IP- en netwerkhostobjecten, maar geen IP-bereiken of hostlijsten. De Minimum TLS version is eveneens globaal; test oudere clients en alle gepubliceerde applicaties via een echte externe verbinding voordat deze instelling wordt aangescherpt.

Als globale TLS-instellingen biedt SFOS onder meer TLS v1.2 (wide compatibility), TLS v1.2 (strict) en TLS v1.3. Wijzig Custom protocol configuration en Custom cipher configuration alleen met gedocumenteerde en geteste OpenSSL-waarden; cipher suites voor TLS 1.3 worden afzonderlijk beheerd. Ongeldige waarden kunnen voorkomen dat de door SFOS beheerde Apache-service en daarmee Web Server Protection starten. Het wijzigingsplan moet daarom de vorige waarden, een configuratieback-up, een onderhoudsvenster en alternatieve beheerstoegang bevatten. Test daarna alle WAF-publicaties en controleer reverseproxy.log; als de service niet start, draai dan de laatste aangepaste waarden terug naar de vorige waarden in plaats van meer varianten in productie te proberen.

Bij Protection Policies is de modus belangrijk. Reject blokkeert en genereert zichtbare Log Viewer-events voor WAF-regels. Monitor logt alleen, maar deze WAF-meldingen verschijnen niet noodzakelijk in Log Viewer; dan moet reverseproxy.log worden gecontroleerd. Voor een pilot kan Monitor zinvol zijn, maar voor productieve bescherming moet duidelijk zijn of aanvallen alleen worden bekeken of echt worden geweigerd.

Het Common threat filter werkt met vier Filtering Strengths. Level 1 is het tolerantst en wordt niet gelogd; vanaf Level 2 staan treffers in /log/reverseproxy.log, terwijl ook het risico op false positives stijgt. Individuele regels worden alleen uitgezonderd aan de hand van de in het log aangetoonde Rule ID onder Skip filter rules. Een volledige categorie of een hoger level zonder onderscheid uitschakelen is geen deugdelijk alternatief voor deze analyse.

Static URL hardening is hoofdlettergevoelig, accepteert geen wildcards en helpt niet bij URL’s die dynamisch door JavaScript worden gemaakt. Form hardening vergelijkt de formulierstructuur en ondersteunt formulieren tot 8,000 bytes. Als binaire inhoud ten onrechte als HTML of XML wordt geleverd, kunnen beide functies die inhoud beschadigen; corrigeer daarom eerst het Content-Type van de backend in plaats van de beveiligingsfunctie breed uit te schakelen.

Bij de antivirusscan geldt een groottelimiet voor het totale uploadvolume van een request, niet voor elk afzonderlijk bestand. De extra Request size limit voor de HTTP-body loopt van 1 tot 1,024 MB en staat standaard op 10 MB. HTTP Strict Transport Security voegt de HSTS-header alleen toe wanneer de WAF-regel Redirect HTTP gebruikt; MIME-type sniffing protection zet X-Content-Type-Options: nosniff. Test uploads, downloads en headers daarom met de echte applicatie.

IPS in een WAF-regel moet apart worden beoordeeld. Sophos past IPS voor WAF alleen toe wanneer de communicatie tussen firewall en webserver via HTTP loopt. Als de backend via HTTPS is aangesloten, mag men dus niet automatisch verwachten dat een geselecteerde IPS-policy hetzelfde effect heeft.

Uitzonderingen moeten nauw worden ingesteld. Als een applicatie vanwege een enkel pad of een bepaalde bron niet werkt, moet niet het hele beschermingsprofiel worden uitgeschakeld. Beter is een gerichte uitzondering met pad, bron en duidelijke reden.

⚠️ Elke uitzondering vermindert de beschermingswerking. Pad, bron, reden, datum en herzieningstermijn moeten worden gedocumenteerd, zodat tijdelijke workarounds niet permanent blijven bestaan.

Een Protection Policy maken en de beschermingswerking begrijpen

Geef onder Web server > Protection policies > Add een duidelijke naam op, bijvoorbeeld WAF_Portal_Protection, configureer de benodigde beschermingsfuncties en kies Save. Selecteer daarna de policy in het veld Protection van de WAF-regel; onder SFOS 23 geldt deze alleen voor Protect-paden. Een bestaande standaardpolicy, bijvoorbeeld voor Exchange Autodiscover, mag alleen voor de bijbehorende toepassing worden gebruikt.

Maak voor een pilot van de eigen applicatie eerst een duidelijke keuze tussen Monitor en Reject. Monitor blokkeert niet en toont de betreffende WAF-meldingen niet in Log Viewer; daarvoor is reverseproxy.log nodig. De betere zichtbaarheid van Reject mag niet worden verward met reeds geteste applicatiecompatibiliteit. Pass Outlook anywhere staat externe Outlook-clients toe om de webserverbescherming voor Exchange-toegang te omzeilen. Deze optie is geen algemene compatibiliteitsoplossing voor moderne portalen en blijft uitgeschakeld zonder een onderbouwde legacytoepassing.

Cookie signing vult een door de server ingesteld cookie aan met een tweede cookie met een hash van de naam, de waarde en een geheim dat alleen de firewall kent. Als de client niet het bijbehorende paar aanlevert, wordt het cookie verworpen. Dit beschermt tegen manipulatie, maar vervangt noch veilige applicatiesessies, noch de juiste cookieconfiguratie van de backend. Test na activering het inloggen, het winkelmandje en andere cookieafhankelijke processen.

Bij Static URL hardening ondertekent de firewall statische links en bepaalt deze op basis van het serverantwoord welke vervolglinks toegestaan zijn. Entry URLs definieert instap-URL’s die zonder hardening-handtekening bereikbaar mogen zijn; voor een eenvoudige website kan / het instappunt zijn. Deze lijst is geen algemene routinglijst. Houd rekening met hoofdletters en kleine letters en voer geen wildcards in. Applicaties met door JavaScript gegenereerde URL’s of legitieme deeplinks vereisen een afzonderlijke controle. Form hardening ondertekent de oorspronkelijke formulierstructuur en wijst gemanipuleerde formulieren af. De bestaande limiet van 8,000 bytes en het juiste HTML-/XML-Content-Type blijven essentieel.

Het gedocumenteerde eenvoudige voorbeeld voor aanvalsbeveiliging gebruikt Reject, Static URL hardening met instappunt /, Form hardening, Antivirus, Block clients with bad reputation en Common threat filter. Cookie signing, Pass Outlook anywhere en Skip remote lookups for clients with bad reputation zijn daarin uitgeschakeld. Dit is een testprofiel voor dit specifieke proces, geen universele aanbeveling en geen bewijs dat de standaardinstellingen voor elke applicatie geschikt zijn. Beoordeel voor een modern portaal elk van deze opties aan de hand van het echte applicatieverkeer. Ook het daar genoemde Basic with passthrough is geen MFA-aanbeveling; de clientmodus, het doorgeven van aanmeldgegevens en de sjablonen worden uitgelegd in het gekoppelde artikel over WAF-authenticatie en MFA.

Antivirus en reputatie bewust configureren

Bij Antivirus bepaalt Mode of één of twee scan-engines worden gebruikt; selecteer bij een enkele scan de engine. Direction bepaalt of uploads, downloads of beide richtingen worden gescand. Block unscannable content blokkeert bijvoorbeeld versleutelde of beschadigde bestanden die niet kunnen worden gecontroleerd. Dit maakt de handhaving strenger, maar kan ook legitieme versleutelde documenten treffen; leg daarom vooraf de toegestane bedrijfsprocessen en het supporttraject vast.

Limit scan size begrenst het te scannen volume; 0 of een leeg veld betekent dat er geen groottelimiet voor de scan geldt. Voorbeeld: bij een scanlimiet van 50 MB en bestanden van 45, 5 en 10 MB in één upload wordt het laatste bestand niet gescand. Een geslaagde upload bewijst dus niet dat elk opgenomen bestand is gecontroleerd. Deze scanlimiet moet worden onderscheiden van de Request size limit voor de volledige HTTP-body: een hogere bodylimiet maakt niet automatisch meer inhoud scanbaar. Kies limieten op basis van de daadwerkelijk benodigde uploads, resources en beveiligingseisen en test uploads met meerdere bestanden en niet-scanbare inhoud in een vrijgegeven testomgeving.

Block clients with bad reputation gebruikt RBL- en GeoIP-informatie: Sophos SXL voor RBL’s en MaxMind voor GeoIP. Ook blokkeringen voor de classificaties A1 (anonieme proxy’s of VPN-diensten) en A2 (satelliet-ISP) zijn gedocumenteerd. Dit kan legitieme partnertoegang treffen. Skip remote lookups for clients with bad reputation kan de prestaties verbeteren, maar verandert de beoordeling via externe opvragingen; activeer deze optie niet ongemerkt en stel deze niet gelijk aan een allowlist voor bronnen.

Common threat filter beoordelen op categorie en sterkte

De categorieën beantwoorden verschillende vragen en worden bewust voor de applicatie gekozen:

Application attacks: Detecteert onder meer ongeoorloofde toegang tot paden en typische pogingen om opdrachten uit te voeren, ook na een mogelijke inbraak.
SQL injection attacks: Controleert requestargumenten op ingesloten SQL-opdrachten en escape-tekens.
XSS attacks: Controleert invoer op ingesloten scripttags en code.
Protocol enforcement: Controleert protocolconformiteit, gebruikelijke headers zoals Host en User-Agent, argumentlimieten en toegestaan HTTP-gebruik. Een ongebruikelijke legitieme client kan daardoor ook opvallen.
Scanner detection: Detecteert typische bot-, crawler- en scanpatronen; gewenste toegang door zoekmachines of monitoring moet desondanks worden getest.
Data leakage: Voorkomt dat gevoelige informatie, bijvoorbeeld via serverfoutmeldingen, bij de client terechtkomt. Als Application attacks of SQL injection attacks actief is, moet ook deze categorie worden gecontroleerd, omdat de detectiegebieden elkaar overlappen.

Filter strength staat standaard op Level 1 en veroorzaakt de minste false positives. Level 2 voegt bijvoorbeeld reguliere expressies voor SQL-/XSS-injectie en extra trefwoorden voor code-injectie toe; Level 3 voegt regels, trefwoordenlijsten en limieten voor speciale tekens toe; Level 4 beperkt speciale tekens nog sterker en vereist bijzonder grondige tests op false positives vóór de go-live. De eerder beschreven logbeperkingen blijven gelden: Level 1 wordt niet gelogd, Level 2 en hoger verschijnen in /log/reverseproxy.log. Beschouw een hogere sterkte niet als veilig gevalideerd alleen omdat een startpagina opent.

HSTS en MIME-bescherming controleren vóór activering

Bij HTTP Strict Transport Security en ingeschakelde Redirect HTTP voegt de firewall deze header toe:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

31536000 komt overeen met één jaar. Dit heeft niet alleen betrekking op het geteste instappunt: includeSubDomains omvat subdomeinen en browsers kunnen de instelling opslaan. Vóór activering moeten HTTPS, certificaten en alle betrokken subdomeinen blijvend functioneren; het later uitschakelen van het selectievakje is geen onmiddellijke terugweg voor reeds opgeslagen browserinstellingen. preload in de header alleen bewijst geen opname in een browser-preloadlijst. MIME-type sniffing protection voegt X-Content-Type-Options: nosniff toe; corrigeer onjuiste MIME-typen daarom op de backend in plaats van de header zonder onderscheid te verwijderen. Controleer beide headers op de externe client.

Uitzonderingen zo nauw als nodig instellen

Stel onder Add new exception de Paths, Sources, Operation en de specifiek over te slaan controles in. Uitzonderingspaden zijn hoofdlettergevoelig en staan wildcards toe, bijvoorbeeld /products/*/images/*. Dit onderscheidt ze van de wildcardvrije Entry URLs van de Static URL Hardening Policy. Bij Operation is de booleaanse combinatie bepalend: een pad en een bron samen vormen een nauwere overeenkomst dan een pad of een bron. Controleer vóór het opslaan de gewenste doorsnede, zodat een partnerbron niet onbedoeld voor alle paden van de bescherming wordt uitgezonderd.

Voor Sources van een uitzondering zijn IP-adressen, bereiken, lijsten en netwerken gedocumenteerd. Dit mag niet worden doorgetrokken naar andere velden: bij Path-specific routing in SFOS 22 en bij de SFOS-23-Passthrough-velden Allowed client networks en Blocked client networks zijn alleen de hosttypen IP en Network gedocumenteerd, geen IP ranges of IP lists. Gebruik daar afzonderlijke IP- of netwerkobjecten voor een voorspelbare toegangsbeperking.

De opties van een uitzondering slaan onder meer Cookie signing, Static URL hardening, Form hardening, Antivirus, Block clients with bad reputation en geselecteerde Common-Threat-categorieën over. Twee opties vereisen extra voorzichtigheid:

Never change HTML during static URL hardening or form hardening voorkomt dat de HTML-pagina wordt herschreven, bijvoorbeeld wanneer de applicatie afhankelijk is van ongewijzigde links. Dit betekent niet automatisch dat de niet-ondertekende links worden geaccepteerd; daarvoor kan een gerichte hardening-uitzondering nodig zijn.
Accept unhardened form data accepteert formuliergegevens zonder hardening-handtekening. Een Form hardening-uitzondering alleen doet dat niet. Deze extra toestemming verwijdert nog een controle en is alleen geschikt voor een nauw afgebakend, onderbouwd proces.

Leg vooraf het mislukte legitieme request, het tijdstip en de aangetoonde Rule ID vast. Herhaal daarna hetzelfde request en voer een tegencontrole uit met een niet-uitgezonderde bron of een niet-uitgezonderd pad. De uitzondering is pas zinvol afgebakend wanneer het noodzakelijke proces werkt en de overige bescherming behouden blijft; zonder bij twijfel liever één aangetoonde Rule ID onder Skip filter rules uit dan een volledig beschermingsgebied.

Gemigreerde Protection Policies opnieuw valideren

Sinds SFOS 18 gebruikt Web Server Protection het OWASP ModSecurity Core Rule Set 3.0. Bij de migratie van oudere Protection Policies zijn eerdere categorieën samengevoegd, Rule IDs opnieuw toegewezen en Filtering Strengths ingevoerd. Als één van de samengevoegde categorieën eerder actief was, kan de nieuwe gezamenlijke categorie daarom actief zijn, ook wanneer een ander deel eerder uitgeschakeld was.

Na zo’n upgrade volstaat het niet om alleen de naam van de policy te vergelijken. Controleer de actieve categorieën, uitzonderingen en Filtering Strengths aan de hand van de vorige documentatie. Voer daarna gecontroleerde positieve en negatieve tests met echt applicatieverkeer uit en controleer Log Viewer en reverseproxy.log. De gemigreerde policy is pas gevalideerd wanneer legitieme requests blijven werken en de verwachte testaanvallen worden gedetecteerd.

Voor de oude SFOS-18-migratie zijn de volgende toewijzingen belangrijk: Protocol violations, Protocol anomalies, Request limits en HTTP policy zijn samengevoegd tot Protocol enforcement; Generic attacks en Tight security tot Application attacks; Bad robots is omgezet naar Scanner detection; Outbound naar Data leakage. Rigid filtering migreert naar Level 1 en moet bewust opnieuw worden beoordeeld. De categorie Trojans is vervallen; Antivirus neemt de bijbehorende bescherming over. Reeds uitgezonderde regels waaraan een nieuwe Rule ID is toegewezen, blijven uitgezonderd, terwijl niet-toegewezen, verwijderde of in een nieuwe regel samengevoegde IDs uit de Skip-lijst worden verwijderd. Kopieer de oude uitzonderingslijst daarom niet zonder controle, maar vergelijk deze met de actuele policy en actuele logs.

Pad-specifieke routering, WebSocket en Load Balancing

WAF kan verzoeken afhankelijk van het pad naar verschillende backend-servers doorsturen. Dit is nuttig als een applicatie meerdere componenten heeft of een enkele hostnaam over meerdere interne diensten moet worden verdeeld.

Voorbeelden:

/api/ gaat naar een API-server.
/shop/ gaat naar een shopsysteem.
/ gaat naar de standaardwebserver.

De firewall beoordeelt paden niet op basis van de tabelvolgorde, maar geeft langere en daarmee specifiekere paden voorrang op de opvangroute. Deze toewijzing moet gericht worden getest. Alleen voor SFOS 22: Voor het benodigde websitepad kan het selectievakje WebSocket passthrough worden geactiveerd; WebSocket-verkeer wordt daarbij zonder WAF-bescherming doorgestuurd, omdat WebSocket-gegevens niet zoals normaal HTTP-verkeer kunnen worden gecontroleerd. Voor SFOS 23: Configureer onder Traffic routing uitsluitend het benodigde WebSocket-pad met Action > Passthrough en de bedoelde backend. Deze tunnel werkt zonder WAF-inspectie en zonder beschermingspolicy; de overige applicatiepaden blijven op Protect staan. Zet nooit het volledige portaal als workaround op Passthrough. Test verbindingsupgrade, gegevensoverdracht en opnieuw verbinden afzonderlijk. Hieruit kan geen uitspraak over MFA-afdwinging bij Passthrough worden afgeleid; stem bij vereiste authenticatie de verantwoordelijkheid af met de verantwoordelijke voor authenticatie.

Alleen voor SFOS 22: Bij de procedure met Protected servers stuurt het standaardpad / verzoeken zonder specifiekere overeenkomst door naar de toegewezen standaardserver. Als deze standaardroute wordt verwijderd, wijst de firewall dergelijke verzoeken af met 404 Not Found. Voor SFOS 23: Verzoeken zonder specifiekere overeenkomst gebruiken de actie van /; bij nieuwe regels is dat standaard Block. Behoud deze opvangroute bewust als alleen afzonderlijke paden moeten worden gepubliceerd. Protect voor / is alleen zinvol als publicatie van de volledige applicatie is bedoeld en vereist een controle van de extra bereikbaarheid. Voor SFOS 23 wordt geen vaste 404-status gegarandeerd: het antwoord van Block wordt via Response code geconfigureerd.

Bij meerdere backend-servers zijn Sticky Sessions of Hot-standby mogelijk. Dit helpt bij eenvoudige hoogbeschikbaarheids- of lastverdelingsgevallen, maar vervangt geen volledig applicatie-load-balancingconcept.

Zonder aanvullende binding worden verzoeken over meerdere geselecteerde webservers verdeeld. Sticky session cookie bindt de browser aan één backend-server; als deze uitvalt, wordt de cookie bijgewerkt en wordt de sessie naar een andere server overgezet. Dit garandeert niet dat de applicatiestatus wordt overgedragen: een winkelwagen kan bijvoorbeeld een gedeelde sessieopslag nodig hebben.

Hot-standby mode stuurt aanvankelijk alle verzoeken naar de eerste geselecteerde server en gebruikt de overige als back-up. Wanneer de primaire server terugkeert, schakelen sessies in principe terug; als Sticky session cookie is geactiveerd, blijft de bestaande sessie op de back-upserver. Voer daarom afzonderlijke acceptatietests uit voor de primaire server, de back-upvolgorde, uitval, terugkeer en een daadwerkelijk toestandafhankelijke inlog- of winkelwagenhandeling.

Het veld Authentication wordt ook in de SFOS-23-tabel voor Passthrough vermeld, terwijl het functieoverzicht authenticatie aan Protect toewijst. Deze tegenstrijdigheid in de documentatie wordt niet met aannames opgelost. Als WAF-MFA vereist is, baseer het beschermde deel dan op Protect en een expliciete policy; de afbakening en tests staan onder WAF-authenticatie met MFA.

Externe WAF-backends via SD-WAN bereiken

Als de beschermde webserver niet in het lokale netwerk van de firewall staat, moeten routing en SD-WAN bijzonder bewust worden gecontroleerd. Voor backends via locatieverbindingen, MPLS of route-based IPsec kan een passende SD-WAN Route nodig zijn, zodat de firewall de Protected Server betrouwbaar bereikt en de terugweg klopt. Bij route-based IPsec is bovendien belangrijk: WAF over route-based IPsec met Traffic Selectors voor subnetten wordt door Sophos niet ondersteund; Any-to-Any-verbindingen zijn het gedocumenteerde alternatief.

Het door Sophos gedocumenteerde ontwerp begint met een werkende WAF-regel en een bereikbare route-based tunnel. Maak onder Routing > Gateways voor het externe pad een gateway-object met het IP-adres van de peer, de geadresseerde XFRM-interface en een betrouwbare monitoringhost achter de peer. Pas daarna wordt onder Routing > SD-WAN routes de gerichte route voor WAF-proxyverkeer gemaakt:

Maak onder Routing > Gateways > IPv4 gateway > Add de gateway aan en sla deze op. In het voorbeeld heet deze gw6 en gebruikt deze Gateway IP 10.12.13.2 en Interface xfrm1-10.12.13.1. Gebruik onder Monitoring condition een host achter de gateway die betrouwbaar antwoordt; het gedocumenteerde voorbeeld gebruikt 10.12.13.2. Vervang deze privéadressen en de interface door de daadwerkelijke tunneladressering en een passende monitoringhost.
Kies onder Routing > SD-WAN routes IPv4 en Add, bijvoorbeeld met de naam SD-WAN_WAF_Portal. Verwijder bij Destination networks Any en kies de openbare WAN-interface of Hosted address waarmee de client de WAF-regel bereikt; in het voorbeeld #Port1. Bij deze gedocumenteerde WAF-route is dit niet simpelweg het privé-IP-adres van de backend.
Verwijder bij Services Any en selecteer de externe Listening Port van de WAF-regel, in het voorbeeld TCP 8080. Als deze afwijkt van de interne backendpoort, hoort hier uitdrukkelijk de externe poort te staan. Houd ook bij het externe testverzoek rekening met deze niet-standaardpoort.
Selecteer onder Link selection settings Primary and Backup gateways en stel bij Primary gateway de eerder aangemaakte XFRM-gateway gw6 in. Sla de route op. Als meerdere publicaties dezelfde gateway gebruiken, kan dezelfde SD-WAN Route meerdere openbare WAN-adressen en Listening Ports bevatten. Voor verschillende gateways zijn afzonderlijke routes nodig.

De SD-WAN-procedure verwijst naar een handleiding voor route-based VPN met Traffic Selectors; de WAF-regelreferentie sluit subnetgebaseerde Traffic Selectors echter expliciet uit. Plan voor deze WAF-use-case daarom een Any-to-Any-verbinding en beschouw de titel van de verwijzing niet als toestemming voor configuraties met subnetselectors.

De acceptatie scheidt vervolgens de lagen: de externe test moet de verwachte WAF-regel treffen; correleer in de Log Viewer de WAF-regel, reverse-proxyfouten en het tijdstip; op de firewall moeten XFRM-interface, gatewaymonitor en SD-WAN Route actief zijn; de backendserver moet het verzoek ontvangen en via het bedoelde pad antwoorden. Alleen een groene tunnel bewijst noch de SD-WAN-match noch de bereikbaarheid van de backend.

Beheer en troubleshooting

Tijdens het beheer is het belangrijk dat de publicatie traceerbaar blijft: welke regel overeenkomt, welke logs relevant zijn, welke uitzonderingen bestaan en hoe men bij storingen te werk gaat.

Typische fouten

Openbare DNS-naam wijst naar het verkeerde IP: de WAF-regel wordt nooit bereikt.
Certificaat komt niet overeen met de hostnaam: browsers tonen certificaatfouten of SNI-matching komt niet overeen.
Verkeerde Hosted address gekozen: de firewall matcht een andere regel of geen WAF-verkeer.
Allowed client networks leeg: de regel werkt niet zoals verwacht.
WAF-regellimiet niet meegenomen: extra publicaties kunnen niet meer op een overzichtelijke manier worden ingericht.
Exchange-versie na 2013 met WAF-template gepland: de template past niet bij de ondersteunde WAF-grens.
Poortconflict met User Portal, VPN Portal of andere dienst: de applicatie is niet bereikbaar of een firewall-dienst reageert.
Backend is intern niet bereikbaar: externe clients krijgen fouten, hoewel DNS en certificaat kloppen.
Backend-timeout verkeerd ingesteld: lange antwoorden eindigen met fouten, hoewel de applicatie in principe bereikbaar is.
Backend ligt via VPN of SD-WAN zonder passende route: de WAF-regel matcht, maar de Protected Server wordt niet betrouwbaar bereikt.
Route-based IPsec met Traffic Selectors naar de backend: WAF over dit pad wordt niet ondersteund.
WAF-uitzondering te breed ingesteld: de beschermingswerking neemt onnodig af.
WebDAV-applicatie via WAF gepubliceerd: de applicatie werkt niet betrouwbaar of wordt niet ondersteund.
URL-pad bevat %2F: WAF antwoordt met 404 Not Found, hoewel de resource rechtstreeks op de backend bereikbaar is. %2F is de URL-gecodeerde vorm van een slash / en moet worden onderscheiden van een normale backend-404.
Regelwijziging zonder onderhoudsvenster: bestaande verbindingen kunnen bij het herstarten van de WAF-regels worden verbroken.
Oude DNAT-regel en nieuwe WAF-regel concurreren: het is onduidelijk welke publicatie het verkeer verwerkt.

Troubleshooting

Als een WAF-publicatie niet werkt, moet men systematisch controleren:

Wijst de openbare DNS-naam naar het juiste openbare IP?
Is het juiste Hosted address in de WAF-regel geselecteerd?
Is de Listening Port vrij en niet bezet door WebAdmin, User Portal, VPN Portal of een andere publicatie?
Komt het certificaat overeen met de opgeroepen hostnaam?
Is de interne webserver vanaf de firewall bereikbaar?
Zijn Allowed client networks, Blocked client networks en Blocked countries correct ingesteld?
Ligt de Protected Server via een route, SD-WAN Route of VPN-verbinding die vanuit firewallperspectief echt klopt?
Is er een algemenere WAF-regel die eerder matcht?
Wordt de toegang in de Log Viewer als toegestaan, geblokkeerd of verworpen weergegeven?
Zijn er aanwijzingen in /log/reverseproxy.log?
Staat de Protection Policy op Monitor of Reject?
Past de timeout van het webserver-object bij de applicatie?

Voor de eerste analyse is de Log Viewer nuttig. Voor diepere troubleshooting helpen de Web Server Protection Logs op de firewall. Een overzicht van logbestanden en diensten staat in Sophos Firewall Troubleshooting: Services en Logs.

WAF antwoordt met 404 bij `%2F` in het pad

Een specifiek foutbeeld treedt op bij URL’s met een gecodeerde slash. Een verzoek zoals https://portal.example.com/api/files/project%2Freport.pdf kan via Sophos WAF 404 Not Found opleveren, hoewel de resource bij rechtstreekse toegang op de backend bestaat. Sophos houdt dit gedrag bij onder NC-159041 en noemt momenteel noch een specifieke getroffen of gecorrigeerde SFOS-versie, noch een ondersteunde workaround.

Om de oorzaak af te bakenen, moet hetzelfde verzoek gecontroleerd via WAF en rechtstreeks op de backend worden vergeleken. De exacte URL en het testtijdstip zijn daarbij belangrijk:

Controleer of het pad werkelijk %2F bevat. Een normale slash / of een ontbrekend standaardpad is een ander foutbeeld.
Vergelijk het tijdstip in Log Viewer, /log/reverseproxy.log en het toegangslog van de webserver.
Als op de backend geen passende vermelding voor het verzoek verschijnt, is het waarschijnlijk al vóór de webserver afgewezen. Met een rechtstreekse backendtest kan tegelijk worden uitgesloten dat de resource zelf ontbreekt.

Een brede WAF-uitzondering verhelpt dit probleem niet gericht en zou de bescherming onnodig verminderen. Ook de door SFOS beheerde Apache-configuratie mag niet worden gewijzigd: de restrictieve behandeling van gecodeerde slashes helpt voorkomen dat pad- of toegangscontroles worden omzeild.

Het is het schoonst wanneer de applicatie of leverancier URL’s zonder gecodeerde slashes genereert. Als dat niet mogelijk is, moet een andere publicatiemethode zoals DNAT, een geschikte reverse proxy of privétoegang bewust worden afgewogen tegen het wegvallen van de WAF-bescherming. Voor niet-aanpasbare applicaties moet Sophos Support de concrete SFOS-build en use case beoordelen. De vormen project%2Freport.pdf en project/report.pdf zijn hierbij alleen een herkenningspatroon en zijn niet automatisch functioneel gelijkwaardig.

Checklist voor productieve WAF-regels

Regelnaam beschrijft applicatie, hostnaam en omgeving.
Verantwoordelijke persoon of systeemeigenaar is gedocumenteerd.
DNS, certificaat en Hosted address zijn gecontroleerd.
Backend-bereikbaarheid is vanaf de firewall getest.
Eerdere publicatie en rollback zijn gedocumenteerd.
Oude DNAT- of firewallregels concurreren niet met de WAF-regel.
Externe go-live-tests zijn gedefinieerd.
Toegang is beperkt tot noodzakelijke bronnen of landen.
Threat Feeds en Active Threat Response zijn voor openbare applicaties geëvalueerd.
Logging is actief.
Beschermingsprofiel is niet onnodig gedeactiveerd.
Uitzonderingen zijn nauw, gerechtvaardigd en tijdelijk.
Wijziging is extern getest.
Vervaldatum of herzieningstermijn is gedocumenteerd.

WAF-objecten via de XML API duiden

Voor automatisering horen publicatie, backend en beveiligingspolicy bij elkaar, maar blijven het verschillende objecten. FirewallRule met PolicyType HTTPBased bevat HTTPBasedPolicy; RealServers beschrijft de backend-webserver en ProtocolSecurity de Protection Policy. De WAF-regel verwijst naar deze objecten en vervangt hun configuratie niet. Toegang, TLS-controle, secrets, expliciete schrijfbewerkingen en de beoordeling van de XML-status worden uitgelegd in Toegang tot de XML API veilig beperken.

De onderstaande toewijzingen verduidelijken de SFOS-22-/23-referenties, maar zijn geen uitvoerbare requestsjablonen. Vergelijk vóór elke schrijfbewerking de API help van de geïnstalleerde build met het bestaande object, bereid een back-up en een terugvalprocedure voor en controleer eerst een ongevaarlijke leesquery. Schrijf niet bij onduidelijkheid over syntaxis, eenheid of actietoewijzing, maar laat dit door Support verduidelijken. Dit geldt vooral na een versiewijziging.

Publicatie en toegangspaden niet verwarren

Name identificeert de FirewallRule; de referentie staat maximaal 60 tekens toe, geen komma’s, en UTF-8. Position is verplicht en vermeldt Bottom, Top, After of Before; bij de laatste twee varianten hoort ook de bij naam genoemde referentieregel. Voor Status noemt de tabel de standaardwaarde ON en de schrijfwaarden Disable en Enable: weglaten is geen veilige voorbereiding voor een uitgeschakelde publicatie. LogTraffic staat volgens de tabel standaard op Disable; controleer logging expliciet. IPFamily biedt in het gemeenschappelijke FirewallRule-contract ook IPv6, maar HTTPBasedPolicy is uitdrukkelijk beperkt tot IPv4. Netwerk- en gebruikersregels worden behandeld onder Firewallregels en worden niet als WAF-payload overgenomen.

In het WAF-gedeelte komen HostedAddress, ListenPort, HTTPS, HTTPSCertificate en Domains/Domain overeen met de publieke listener. De tabel vermeldt HostedAddress, ListenPort, HTTPS en Domains als verplichte velden. ListenPort is een integer van 1 tot 65535; gedocumenteerd zijn 80 bij uitgeschakeld HTTPS en 443 bij ingeschakeld HTTPS. Dit is niet de backendpoort. RedirectHTTP is de afzonderlijke HTTP-omleiding. Controleer de publieke naam, het certificaat en de listener na elke wijziging samen.

Padtoewijzingen staan onder HTTPBasedPolicy/AccessPaths/AccessPath. Daarin verwijst backend naar de webserverobjecten; allowed_networks, denied_networks, blocked_countries en block_unknown_country beschrijven de clienttoegang. stickysession_status en hot_standby horen bij sessiebinding en backendselectie. Een Authentication Policy waarnaar wordt verwezen, wordt toegelicht in het artikel over WAF-authenticatie; controleer MFA-afdwinging afzonderlijk voor de gekozen actie.

Versieverschil: De SFOS-22-tabel beschrijft path als één string en backend als een verplichte array. In SFOS 23 is path een array met meerdere waarden, terwijl backend als optioneel wordt vermeld. De padwaarden zijn volgens de tabel beperkt tot 63 tekens en mogen geen komma’s bevatten. Optioneel betekent hier niet dat een Protect- of Passthrough-pad zonder toegewezen backend zinvol kan worden gepubliceerd: de huidige UI vereist voor deze acties de selectie van een backend, terwijl Block en Redirect geen backend publiceren.

SFOS 23 voegt het met kleine letters geschreven action toe met de toegestane waarden 0, 1, 2, 3, en daarnaast response_code, redirect_protocol, redirect_host, redirect_port en redirect_path. De referentie wijst de vier getallen niet toe aan de UI-acties. Maak geen toewijzing op basis van volgorde of aannames; een bevestigde toewijzing voor de geïnstalleerde build is een voorwaarde voor elke geautomatiseerde wijziging. Het met een hoofdletter geschreven Action met Accept, Drop, Reject staat in het voorbeeld onder UserPolicy respectievelijk NetworkPolicy, niet in het WAF-blok. Het vervangt noch de buitenste WAF-actie in de UI, noch AccessPath/action. Voor redirect_protocol staan letterlijk http en https, voor redirect_port 1 tot 65535 en voor redirect_path maximaal 8192 tekens in de tabel. response_code wordt daar alleen als integer beschreven; de UI-selectie hierboven blijft bepalend voor de concrete configuratie.

Ook het voorbeeld bewijst het schema niet: het gebruikt path en Path door elkaar, bevat lege verwijzingen en placeholders en toont HTTPSCertificate en LogTraffic niet volledig in het WAF-blok. SFOS 22 toont nog websocket_passthrough; SFOS 23 gebruikt het actiemodel. Bevestig daarom schrijfwijze, nesting, benodigde velden en logging in het buildspecifieke contract en vul het voorbeeld niet mechanisch aan. ProtocolSecurity in het WAF-blok verwijst naar de beveiligingspolicy. De uitgebreide schakelaars PassHostHeader, RewriteHTML, RewriteCookies en CompressionSupport horen bij de hierboven uitgelegde reverse-proxy-aanpassingen; voeg tegenstrijdige waarden uit voorbeelden en tabellen niet samen tot eigen enums.

Het voorbeeld toont bovendien SourceNetworks/Network en ExceptionNetworks/Network, terwijl het bijbehorende commentaar als alternatief Authentication, AllowFrom, BlockFrom of AccessPaths noemt. Leid daaruit geen gelijkwaardigheid van aliassen, toegestane combinatie of voorrangsregel af. Verduidelijk bij bestaande objecten met deze toegangsweergave de structuur en werking in de geïnstalleerde build; blijven die onduidelijk, voer dan geen geautomatiseerde schrijfbewerkingen uit.

Voor uitzonderingen is er een afzonderlijk blok Exceptions/Exception. Daar verbinden path, source en op de voorwaarden; de tabel noemt voor op letterlijk and, or, AND, OR. skipcookie, skipurl, skipform, skipav en skipbadclients slaan de betreffende controles over. Daarentegen voorkomt skiphtmlrewrite dat overeenkomende inhoud wordt gewijzigd, en staat skipform_missingtoken naast de formulieruitzondering ook formuliergegevens zonder hardening-handtekening toe. De betreffende tabelrij verwisselt beschrijving en standaardwaarde; leid daaruit geen betrouwbare standaardwaarde af. De hierboven beschreven beveiligingsgevolgen van beide opties blijven doorslaggevend. skip_threats_filter_categories gebruikt andere tokens dan de beveiligingspolicy, bijvoorbeeld application_attacks en data_leakages. Verwissel deze uitzonderingstokens niet met de weergavenamen van de policy. De verouderde beschrijving van eerdere categorieën geeft evenmin toestemming om oude tokens te gebruiken. Controleer na een wijziging het toegestane pad, het geblokkeerde pad, de vangnetroute en een request dat niet onder een uitzondering valt afzonderlijk.

De tabel beschrijft path voor Site-Path-routes; het uitzonderingsvoorbeeld toont daarentegen meerdere path-elementen binnen een Exception, zonder een eenduidig eigen tabelcontract. Pas de cardinaliteit en grenzen van routingpaden daarom niet toe op uitzonderingen. Bevestig vóór geautomatiseerde wijzigingen aan uitzonderingen de structuur, het aantal en de toegestane waarden in de geïnstalleerde build; schrijf niets zolang het contract onduidelijk is.

Backend-contract en timeout veilig controleren

Bij RealServers zijn Name, Host, Port en TimeOut als verplichte velden gedocumenteerd. Name staat maximaal 60 UTF-8-tekens zonder komma toe. Host is de verwijzing naar een IP- of FQDN-hostobject, geen vrij uitwisselbare publieke WAF-naam. Port loopt van 1 tot 65535, met API-standaardwaarde 80; Type noemt letterlijk Plaintext (HTTP) of Encrypted (HTTPS). Controleer voor een HTTPS-backend daarom expliciet de werkelijke listener en poort, in plaats van de API-standaardpoort over te nemen.

De API beschrijft TimeOut met standaardwaarde 300, bereik 1 tot 65535 en de opmerking dat deze alleen geldt wanneer Keep alive is ingeschakeld. De GUI legt Timeout daarentegen uit als de wachttijd op gegevens naar of van de backend en noemt na het verstrijken daarvan een HTTP-502. Dat is een andere beschrijving, geen bewijs van identiek gedrag bij uitgeschakelde keep-alive. Gebruik voor UI-configuraties de hierboven beschreven test met een pauze in de gegevensoverdracht; verduidelijk vóór automatisering de afhankelijkheid en de opgeslagen waarde in de geïnstalleerde build. Leid hieruit geen algemene verhoging van de timeout af.

Bij KeepAlive toont het voorbeeld Enable/Disable, maar de tabel alleen 0 en Enable, met standaardwaarde ON. Corrigeer deze afwijking niet stilzwijgend met een veronderstelde Disable. DisableReuse noemt Disable en Enable en komt overeen met Disable backend connection pooling. Leg de oorspronkelijke toestand vast, lees het gewijzigde object terug en controleer pas daarna representatieve gegevensoverdracht en backendlogs. Een API-antwoord alleen bewijst noch de bereikbaarheid van de backend, noch passende verbindingsinstellingen.

Beveiligingspolicy en afhankelijke opties

ProtocolSecurity vereist volgens de tabel Name, Mode en RequestSizeLimit. Voor Name gelden maximaal 60 UTF-8-tekens zonder komma; Mode noemt Monitor en Reject. De schakelaars CookieSigning, StaticUrlHardening en FormHardening komen overeen met de cookie-, URL- en formulierbeveiliging hierboven. PassOutlookAnywhere staat volgens de tabel standaard op OFF: de API beschrijft de Exchange-toegang slechts beknopt, terwijl de GUI expliciet het omzeilen van Web Server Protection noemt. Laat dit daarom uitgeschakeld zonder een onderbouwde legacy-toepassing en behandel het niet als een gewone compatibiliteitsschakelaar. Bij ingeschakelde StaticUrlHardening beschrijft de referentie EntryURLType met Manual, SitemapFile, SitemapURL; voor het handmatige geval toont het voorbeeld EntryURLList/EntryURL, met meerdere Entry URLs van elk maximaal 255 tekens. Leid daaruit niet af dat de GUI alle API-varianten op identieke wijze aanbiedt.

De API-tabel vermeldt CookieSigning, StaticUrlHardening, FormHardening, AntiVirus, BlockClientsWithBadReputation en ThreatsFilter elk met Default OFF, en ParanoiaLevel met Default 1. Een nieuwe of gerefereerde Policy bewijst daarom nog niet dat beschermingscontroles zijn ingeschakeld. Stel bij het aanmaken de beoogde schakelaars expliciet in en lees ze terug. Ga bij Edit zonder bevestigd updatecontract niet uit van behoud van weggelaten velden of van terugzetten naar Defaults.

Bij ingeschakelde AntiVirus worden AVMode (Avira, Sophos, DualScan), Direction (Uploads, Downloads, UploadsAndDownloads), BlockUnscannableContent en LimitScanSize relevant. De integer Megabytes is bovendien afhankelijk van ingeschakelde LimitScanSize. Dit blijft gescheiden van de bodylimiet. SkipRemoteLookups is afhankelijk van BlockClientsWithBadReputation; leid de werking van de reputatiecontrole niet uitsluitend af uit de beknopte API-beschrijving.

ThreatsFilter activeert het Common threat filter. Daarbij horen ThreatFilters/Filter, ParanoiaLevel met 1 tot 4 en SkipFilterRules/FilterRules als lijst met gehele Rule IDs. De toegestane filtertokens luiden letterlijk Application attacks, SQL injection attacks, XSS attacks, Protocol enforcement, Scanner detection, Data leakages. Het laatste token verschilt van de GUI-naam Data leakage. Maak alleen gerichte uitzonderingen voor aangetoonde fout-positieven en controleer daarna de overige beveiliging; niveau, categorie en uitzondering zijn verschillende beslissingen.

RequestSizeLimit blijft een conflict tussen bronnen: De API-tabel vermeldt dat het veld verplicht is, standaardwaarde 10, de beschrijving «Megabytes» en een integerbereik van 1 tot 1073741824. De huidige GUI documenteert daarentegen 1 tot 1024 MB, met standaardwaarde 10 MB. In het API-voorbeeld ontbreekt RequestSizeLimit volledig. Leid daaruit noch een byte-/MB-omrekening, noch een verruimde grenswaarde voor productiegebruik, noch veilige optionaliteit af. Gebruik voor de GUI het gedocumenteerde MB-bereik; gebruik een API-schrijfwaarde pas nadat eenheid, bereik en gedrag van het verplichte veld in de geïnstalleerde build zijn bevestigd. Hetzelfde geldt voor de tabelbenaming HSTS Enforcement, die in het voorbeeld ontbreekt: verzin geen XML-tag op basis van de naam. XContentTypeOptions beschrijft de MIME-beveiliging; controleer de opgeslagen policytoewijzing en de werkelijke headers extern.

XML-antwoorden per bewerking onderscheiden

De volgende getallen zijn XML-objectstatussen, geen HTTP-statuscodes. Message.* duidt hier een niet-opgeloste symbolische naam uit de referentie aan, geen vertaalde foutmelding en geen bewijs voor een exacte oorzaak. Controleer antwoord, bewerking en opgeslagen objecttoestand samen; schrijf bij fouten, waarschuwingen of een mogelijke gedeeltelijke wijziging nooit blind opnieuw. De centrale API-beveiligingshandleiding legt de veilige controle- en escalatieprocedure uit.

Voor de WAF-relevante antwoorden van FirewallRule zijn met name deze verschillen belangrijk:

Add firewall rule: 200 → Message.FWRuleAddSuccess, 500 → Message.FWRuleAddFail, 502 → Message.FWRuleRecordExists. Edit firewall rule: 200 → Message.FWRuleEditSuccess, 202 → Message.FirewallRuleUpdateWithRename, 500 → Message.FWRuleEditFail, 502 → Message.FWRuleUpdateRecordExist. Lees bij 202 ook de objectnaam en verwijzingen terug en gebruik niet alleen opnieuw de oude naam.
Add firewall rule 541 → Message.VHIPRangeConflict. Edit firewall rule 541 heeft daarentegen Message.FWRuleFailMaxUser; dezelfde code mag niet tot dezelfde diagnose leiden.
Add firewall rule 543 en Edit firewall rule 544 → Message.CannotSetupRedirectionFromHTTP. Add firewall rule 544 en Edit firewall rule 543 → Message.CannotUseDefaultPort. De toewijzing is tussen Add en Edit omgewisseld: controleer listener, poort en omleiding en classificeer niet uitsluitend op basis van het getal.
Bij Add firewall rule en Edit firewall rule: 542 → Message.CannotUseTypeHTTP, 545 → Message.PortAlreadyExists, 546 → Message.CannotConfigureDomainWithAddrTypePort, 550 → Message.PortUsedInUserPortal, 553 → Message.CannotConfigureDomainWithHTTPSRedirection. Vergelijk de bestaande listener-/domeinconfiguratie; wijzig poortvrijgaven niet op basis van vermoedens.
Bij beide bewerkingen: 547 → Message.warn_update_business_policy; 548 en 549 gebruiken beide Message.MaxIPv4ForAppServerAllowed. De dubbele symbooltoewijzing bewijst geen verschillende, zelfbedachte limieten. Controleer de waarschuwing en de daadwerkelijk opgeslagen WAF-toestand.
Add firewall rule 554 → Message.CannotUseFQDNWildCardAsProtectedServer; Edit firewall rule 554 → Message.CannotUpdateFQDNWildCardAsProtectedServer. Verwar publieke wildcarddomeinen niet met een geschikte backendhost. Edit firewall rule 552 → Message.CannotImportDiffPolicytypeWithSameName: controleer naam en policytype en overschrijf geen ander object.
Bij Add, Edit en Delete firewall rule: 596 → Message.CMLOCALOperationrestriction. Voor Delete staan daarnaast 200 → Message.FWDelSuccess en 500 → Message.FWRuleDeleteFail. Verduidelijk beheerbevoegdheid en verwijzingen vóór een nieuwe poging. De Delete-pagina duidt Name aan als optioneel en gebruikt een niet-passende beschrijving over Before/After; dat is geen veilig verwijderingssjabloon. Bevestig het exacte doel en het buildspecifieke Remove-contract; verwijder anders niets.

Ook backend en beveiligingspolicy hebben eigen antwoordreeksen: Add Web Server 200/500/502 staan voor Message.RealServerAddSuccess/Message.RealServerAddFail/Message.RealServerRecodExist; Update Web Server 200/500 voor Message.RealServerUpdateSuccess/Message.RealServerUpdateFail. Add Protection Policy 200/500/502 staan voor Message.ProtocolSecurityAddSuccess/Message.ProtocolSecurityAddFail/Message.ProtocolSecurityRecodExist; Edit Protection Policy 200/500 voor Message.ProtocolSecurityUpdateSuccess/Message.ProtocolSecurityUpdateFail. De schrijfwijzen RecodExist zijn letterlijk behouden, niet gecorrigeerde symboolnamen. Lees bij naamconflicten eerst het bestaande object; verwijderen en opnieuw aanmaken is geen veilige standaardprocedure voor een herhaalde poging.

Voor het globale object WAFSlowHTTP komen RequestHeaderTimeoutEnabled, RequestHeaderTimeoutSoftLimit, RequestHeaderTimeoutHardLimit en RequestHeaderTimeoutExtensionRate overeen met de schakelaar en de drie hierboven uitgelegde limieten. Alle vier zijn als verplichte velden gedocumenteerd; de schakelaar noemt Disable en Enable, de overige waarden zijn integers zonder opgegeven bereik. NetworkExceptions/Host is een optionele lijst met hostverwijzingen. De voorbeeldwaarden 10, 30, 5000 zijn geen aangetoonde standaardwaarden. SlowHTTP Protection noemt 200 met Operation Successful. en 500 met Operation Fail.. Wijzigingen blijven globaal: controleer opgeslagen waarden en nauw afgebakende uitzonderingen en voer voor alle betrokken publicaties acceptatietests uit met trage legitieme clients.

Veelgestelde vragen

Vervangt WAF het patchen van de webserver?

Nee. WAF kan aanvallen detecteren of blokkeren, maar geen onveilige applicatie permanent compenseren. Besturingssysteem, webserver, frameworks, plugins en applicatiecode moeten nog steeds worden onderhouden.

Is daarnaast DNAT nodig?

Voor dezelfde webpublicatie normaal gesproken niet. De WAF-regel neemt de publicatie over via de Hosted address en leidt door naar de beveiligde webserver. DNAT blijft relevant voor andere protocollen of niet-ondersteunde webapplicaties.

Waarom ziet de webserver niet het echte client-IP?

De firewall werkt als een reverse proxy. De webserver ziet daarom vaak de firewall als bronadres. Het oorspronkelijke client-IP staat in de header X-Forwarded-For, mits de applicatie of de webserver deze header evalueert.

Kan men meerdere websites via hetzelfde openbare IP publiceren?

Ja, bij HTTPS gebruikt de firewall SNI en de hostnaam om de juiste WAF-regel of de juiste virtuele webserver te kiezen. DNS, certificaat en Domains in de WAF-regel moeten daarvoor goed op elkaar aansluiten.

Moet men WAF voor Nextcloud gebruiken?

Niet zonder zorgvuldige evaluatie. WebDAV is gedocumenteerd als een niet-ondersteund WAF-geval. Omdat Nextcloud WebDAV intensief gebruikt, is een publicatie via WAF in veel omgevingen niet passend.

Beschermen Threat Feeds ook WAF-regels?

Onder SFOS 22 kunnen Threat Feeds ook relevant zijn voor inkomend, doorgestuurd verkeer zoals WAF- en DNAT-publicaties. Om daar echte bescherming uit te halen, moeten feeds, logging, alarmen, verantwoordelijkheid en het proces voor false positives echter goed worden beheerd.