Tussen de publicatie van een lek en de installatie van de patch op je site zit altijd tijd: de maker heeft nog geen gepatchte versie uitgebracht, de update breekt een functie, of niemand heeft tijd gehad om hem te testen. Een virtuele patch (ook wel virtual patching, of "vPatch" bij sommige leveranciers) overbrugt die periode. OWASP beschrijft het als een laag met regels die pogingen om een bekende kwetsbaarheid te misbruiken herkent en blokkeert, zonder het lek zelf weg te nemen.
Hoe een virtuele patch werkt
Als het lek is geanalyseerd (kwetsbare parameter, getroffen versies, voorwaarden voor misbruik), schrijf je een regel die de gevaarlijke verzoeken voor precies dat geval herkent. Er zijn twee benaderingen:
- Positief model (allowlist): je legt vast wat een geldige waarde is voor de betreffende parameter, bijvoorbeeld een geheel getal, en weigert al het andere. Dat is het robuustst, maar vergt handwerk.
- Negatief model (blocklist): je blokkeert bekende aanvalspatronen. Sneller uit te rollen, maar makkelijker te omzeilen met een andere codering.
OWASP raadt aan de regel eerst in logmodus te testen voordat je gaat blokkeren, regels te vermijden die alleen de exacte payload uit de waarschuwing herkennen, en de virtuele patch te verwijderen zodra de code is gerepareerd.
Waar hij wordt toegepast
Een virtuele patch kan op verschillende punten in het pad van een verzoek werken: via een online web application firewall, via de webserver (ModSecurity op Apache of Nginx), of via een agent die in de applicatie draait. Voor WordPress zet Patchstack zijn regels alleen in voor kwetsbare onderdelen die echt op de site staan, dankzij een inventaris van de versies, en voert ze uit in de applicatie of, afhankelijk van het lek, al op het niveau van Apache of Nginx.
Wanneer het nuttig is
- Een lek is gepubliceerd zonder gepatchte versie, of de maker treuzelt.
- Een plugin wordt niet meer onderhouden, maar de site is er nog van afhankelijk: iets om op te lossen, zoals ons artikel over verlaten plugins uitlegt, maar dat los je niet in één dag op.
- Je beheert veel sites en updates gaan eerst via een testomgeving.
- Een lek wordt een paar uur na publicatie al massaal misbruikt, sneller dan je onderhoudscyclus.
Voor WordPress: tools en beperkingen
Patchstack (in de betaalde abonnementen), Wordfence en online firewalls zoals Cloudflare publiceren regels voor bekende WordPress-lekken, elk met eigen doorlooptijden en modellen; onze vergelijking van firewalls zet die verschillen op een rij. Een paar beperkingen om in gedachten te houden:
- Een regel bestaat pas als het lek bekend is: tegen een zero-day valt er niets uit te rollen.
- De dekking hangt af van de database van de leverancier, vaak zwakker voor premium plugins die buiten wordpress.org worden verkocht.
- Een verzoek dat niet wordt geïnspecteerd (bijvoorbeeld een aanval die niet langs de firewall gaat), is niet beschermd.
WP Masquerade is geen firewall en past geen virtuele patches toe. Het werkt ervoor en ernaast: het maakt je plugins van buitenaf moeilijker te inventariseren, en de kwetsbaarheidsmeldingen vertellen je welke geïnstalleerde plugin door een CVE wordt getroffen en in welke versie die is opgelost. De combinatie met Patchstack laat zien hoe je de taken tussen beide verdeelt.