Proactieve bescherming tegen zero-day bedreigingen op WordPress

Inleiding: je beschermt je niet tegen een onbekend lek, je verkleint wat het kan raken

Een zero-day is per definitie een kwetsbaarheid die wordt misbruikt vóórdat er een patch bestaat. Dat heeft een gevolg dat de meeste beveiligingsaanbiedingen omzeilen in plaats van benoemen: geen enkel product kan via een signature iets herkennen dat nog niemand heeft beschreven. Een signaturedatabase herkent al geziene aanvallen; hij komt per constructie te laat.

Je «proactief» beschermen betekent dus niet het volgende lek raden. Het betekent drie meetbare dingen:

1. het oppervlak verkleinen — minder blootgestelde code, minder kans dat een onbekend lek u raakt;
2. het bereik beperken — komt de aanval binnen, laat hem dan zo weinig mogelijk raken;
3. de vertraging verkorten — tussen het uitkomen van de patch en het toepassen bij u.

Deze gids behandelt die drie assen. Hij belooft geen onaantastbaarheid, en wantrouwt elk product dat dat wel doet.

1. De echte toegangsdeur is bijna nooit WordPress zelf

De WordPress-kern wordt door zeer veel mensen doorgelicht en snel gepatcht. Het cijfer dat telt voor wie een bestand beheert, ligt elders: de grote meerderheid van de inbreuken komt via een extensie of een thema, niet via de kern.

Drie praktische gevolgen, waarvan het eerste het minst aangename is:

• Een extensie die «voor het geval dat» is geïnstalleerd, is een permanent aanvalsoppervlak voor een incidenteel nut. Deactiveren is niet genoeg: de code blijft op de schijf en blijft soms bereikbaar. Hij moet weg.
• Een verlaten extensie is gevaarlijker dan een kwetsbare, omdat er geen patch meer komt. Het criterium is niet de beoordeling of het aantal installaties: het is de datum van de laatste commit en de reactiesnelheid op meldingen.
• Het aantal extensies is zelf een risico-indicator. Van dertig naar vijftien halveert het oppervlak, zonder enige extra beveiligingstool. Het meest rendabele punt van deze hele lijst, en het enige gratis punt.

Die vraag beantwoordt u met een inventarisatie, niet met intuïtie: onze WordPress-beveiligingsaudit in 10 minuten geeft de werkwijze.

2. De zes lagen, op afnemend rendement

Laag 1 — Verminderen (gratis, direct)

Verwijder wat niet gebruikt wordt. Extensies, inactieve thema's, slapende beheerdersaccounts, ongebruikte toegangspunten. Elke verwijdering haalt een toekomstige mogelijkheid weg, niet alleen een huidig risico.

Laag 2 — De configuratie verstevigen (gratis, een uur)

• bestandsbewerking vanuit het beheer verbieden (DISALLOW_FILE_EDIT);
• PHP-uitvoering in de uploadmap verbieden — de maatregel die de grootste exploitfamilie met één regel serverconfiguratie neutraliseert;
• schrijfrechten weghalen waar ze niets doen;
• rechten beperken: een redacteur hoeft geen extensies te installeren;
• tweefactorauthenticatie op accounts met rechten, en beperking van inlogpogingen.

Geen van deze maatregelen kent het volgende lek. Alle verkleinen wat het zou kunnen doen.

Laag 3 — Patches snel toepassen, en het meten

Hier zit het grootste deel van het werkelijke risico. Een lek is geen zero-day meer op het moment dat er een patch is: vanaf dan is het risico niet meer het lek, maar uw vertraging. En die vertraging wordt zelden gemeten.

De vraag is niet «werk ik bij?» maar «hoeveel tijd zit er gemiddeld tussen het uitkomen van een beveiligingspatch en het toepassen op mijn bestand?». Zonder dat cijfer weet u niet waar u staat. Een bestand op drie dagen en een op drie weken hebben niet hetzelfde profiel, met precies dezelfde tools.

⚠ En automatisch bijwerken is alleen een oplossing als de controle daarna dat ook is. Een update die een afrekenpagina sloopt, kost meer dan een niet-misbruikt lek. De controle kost tijd, niet de update — zie onze gids over procesautomatisering voor bureaus.

Laag 4 — Virtual patching (nuttig, en vaak verkeerd begrepen)

Een applicatiefirewall kan de vorm van een exploitverzoek blokkeren vóórdat de officiële patch bestaat. Dat is nuttig, en het is het enige mechanisme dat echt werkt tijdens het zero-day-venster.

Twee grenzen om te kennen, want ze worden zelden genoemd:

• hij blokkeert patronen, dus een onbekende variant komt erdoor. Virtual patching verlaagt de kans, het sluit de deur niet;
• op extensieniveau loopt hij ná WordPress, dus na een deel van de mogelijk kwetsbare code. Op serverniveau of ervoor onderschept hij eerder en beschermt hij beter.

Laag 5 — De verandering detecteren, niet de aanval

Een onbekende aanval kunt u niet herkennen. Wat u uitstekend kunt herkennen, is dat een bestand veranderde zonder dat u het wist. Integriteitscontrole — vingerafdrukken van kern, extensies en thema's, op vaste intervallen vergeleken — detecteert het gevolg in plaats van de oorzaak. Dit is de laag die een stille inbreuk van zes maanden verandert in een melding van dezelfde dag.

Wat de integriteitscontrole eerst moet dekken: PHP-bestanden die buiten de installatie opduiken, wijzigingen aan de kern, geplande taken die zonder ingrijpen zijn aangemaakt, nieuwe accounts met rechten, en bestanden die in de uploadmap zijn gezet.

Laag 6 — Het herstel, dat een beveiligingsmaatregel is

Een back-up is geen back-upmaatregel: het is de laatste beveiligingsmaatregel. En hij is alleen iets waard als hij bewezen is. Nagaan dat een back-up bestaat zegt niets over of hij terugzet — dezelfde fout als een redirect valideren op zijn statuscode in plaats van zijn bestemming.

Drie eigenschappen om te eisen: een bewaartermijn langer dan uw detectietijd (een back-up van zeven dagen helpt niet tegen een inbreuk die na drie weken wordt ontdekt), een kopie buiten de aangetaste server, en een herstel dat echt getest is, minstens één keer.

3. Wat niet beschermt, ondanks de schijn

• De WordPress-versie verbergen. Het hindert geen geautomatiseerde scanner, die het lek test in plaats van een nummer te lezen.
• De inlogpagina verplaatsen. Nuttig tegen achtergrondruis, waardeloos tegen een lek in een extensie: het misbruik loopt niet via het inlogformulier.
• Een beveiligingsscore in een dashboard. Een indicator die nooit daalt, meet niets. De vraag is niet «wat is mijn score» maar «wat is er sinds gisteren op deze site veranderd».
• Een signaturedatabase alleen. Die behandelt het bekende — precies wat een zero-day niet is.

4. Het protocol, op één pagina

• Volledige inventarisatie van extensies en thema's, met per stuk de datum van de laatste commit
• Verwijderen — niet deactiveren — van alles wat niet gebruikt wordt
• DISALLOW_FILE_EDIT actief, PHP-uitvoering verboden in uploads
• Tweede factor op accounts met rechten, inlogpogingen beperkt
• Gemiddelde vertraging patch → toepassing gemeten, en in de tijd gevolgd
• Automatische controle na de update (minimaal: de pagina's die geld innen)
• Virtual patching aanwezig, in de wetenschap wat het niet dekt
• Integriteitscontrole actief, met een melding die binnen de dag een mens bereikt
• Back-upbewaartermijn langer dan de detectietijd, kopie buiten de server
• Herstel echt getest, minstens één keer, op een aparte omgeving

Conclusie

Proactieve bescherming is geen detectiebelofte: het is oppervlak verkleinen, bereik beperken, en een korte vertraging. De twee effectiefste lagen — verwijderen wat niet gebruikt wordt, en snel patchen — kosten geen extra software. De andere vier vullen aan, ze vervangen niet.

En de enige maatstaf die een werkelijk beschermd bestand onderscheidt van een goed uitgerust bestand blijft deze: hoeveel tijd tussen de patch en u. Kent niemand dat cijfer, dan begint u daar.

Voor het gereedschap, zie AIFORYA AI-beveiliging; voor de details van de aanvalsvectoren onze gids over het beveiligen van WordPress tegen AI-ondersteunde aanvallen; en als het incident al heeft plaatsgevonden, wat te doen als een WordPress is gehackt. Onze premium-extensies komen met volledige terugbetaling binnen 14 dagen.