Een klassieke netwerkfirewall beslist op basis van IP-adressen en poorten: hij leest de inhoud van een webverzoek niet en laat dus alles door wat op poort 443 binnenkomt. Een WAF werkt een niveau hoger, op de laag van de applicatie. OWASP omschrijft hem als een firewall voor HTTP-applicaties, die een set regels toepast op elke uitwisseling en als reverse proxy kan werken. De regels zijn in de eerste plaats gericht op veelvoorkomende webaanvallen, zoals SQL-injectie of cross-site scripting.
Hoe een WAF werkt
De WAF bekijkt het opgevraagde adres, de parameters, de headers, de cookies en de body van het verzoek, en past daarop zijn regels toe. Er bestaan twee benaderingen naast elkaar:
- Het negatieve model (blocklist): herkent bekende aanvallen, bijvoorbeeld een parameter die op SQL of op een script-tag lijkt. Makkelijk in te zetten, maar een nieuwe variant kan erdoor glippen.
- Het positieve model (allowlist): beschrijft wat een parameter mag bevatten en weigert al het andere. Steviger, maar meer werk om op te stellen en bij te houden.
Met een WAF kun je ook een virtuele patch toepassen: een gerichte regel blokkeert het misbruik van een bekende kwetsbaarheid in een plugin totdat er een update is. OWASP benadrukt dat het lek daarmee niet verdwijnt: de echte patch blijft nodig.
Waar je een WAF plaatst
- In de cloud: een dienst die vóór de site staat, zoals Cloudflare of Sucuri, filtert het verkeer voordat het je server bereikt en vangt een deel van de aanvalsgolven op, tot en met een DDoS-aanval. Het echte IP-adres van de server moet dan wel onbekend blijven, anders richt de aanvaller zich er rechtstreeks op.
- Op de webserver: ModSecurity, samen met de OWASP Core Rule Set, werkt binnen Apache of Nginx. De WordPress-documentatie noemt het als een veelgebruikte opensource-optie. Op shared hosting is het meestal de hostingprovider die het inschakelt en de regels kiest.
- In WordPress: een firewallplugin kent de gebruikers, de rollen en de geïnstalleerde plugins, maar draait in PHP, dus nadat de server al aan het werk is gegaan.
Onze vergelijking van firewalls voor WordPress zet de sterke punten en blinde vlekken van Wordfence, Cloudflare, ModSecurity en Patchstack op een rij.
De grenzen van een WAF
- Hij repareert geen code: een logische fout, zoals een ontbrekende rechtencontrole, ziet eruit als een normaal verzoek.
- Hij geeft valse positieven: het opslaan van een bericht met code erin, of bepaalde plugininstellingen, kan worden geblokkeerd.
- Hij vraagt onderhoud: OWASP wijst erop dat het afstemmen op een applicatie moeite kost, en dat je dat opnieuw moet doen als de applicatie verandert.
- Hij vervangt geen updates, geen unieke wachtwoorden en geen tweefactorauthenticatie.
WP Masquerade en firewalls
WP Masquerade is geen WAF: het inspecteert de inhoud van verzoeken niet om aanvallen te blokkeren. Het verkleint het zichtbare aanvalsoppervlak (WordPress verborgen, inlogpagina verplaatst, XML-RPC geblokkeerd) en werkt samen met een firewall. Onze configuratiegidsen met Wordfence en met de cloudfirewall van Sucuri laten zien hoe je de taken verdeelt, en dankzij de ondersteuning voor Cloudflare ziet de Pro-versie het echte IP-adres van bezoekers achter de proxy.
Veelgemaakte fouten
- Een update uitstellen omdat "er toch een firewall is".
- De hele WAF uitschakelen na één vals positief, in plaats van een gerichte uitzondering toe te voegen.
- Meerdere firewallplugins in WordPress stapelen: ze zitten elkaar in de weg zonder je beter te beschermen.