Een klant belde me op een dinsdagochtend: zijn site deed het niet meer. Geen foutmelding, gewoon niets. De hosting-provider had de server tijdelijk offline gehaald vanwege ongewoon veel verkeer. Een DDoS-aanval, bleek later. Zijn webshop stond uren plat. Geen orders, geen contactformulieren, geen bereikbaarheid. En het ergste: hij had geen idee hoe zoiets kon gebeuren en wat hij er de volgende keer aan kon doen.
Dat is het moment waarop ik altijd denk: dit hadden we kunnen voorbereiden.
Wat een DDoS-aanval eigenlijk doet met een WordPress-site
Een DDoS-aanval — Distributed Denial of Service — is geen hack in de klassieke zin. Er wordt geen wachtwoord gestolen en er wordt geen malware geïnstalleerd. In plaats daarvan stuurt een netwerk van gecompromitteerde computers zoveel verzoeken naar jouw server dat die het opgeeft. De server raakt overbelast, reageert niet meer, en jouw site gaat offline.
Voor WordPress-sites is dat extra pijnlijk, omdat WordPress bij elk verzoek de database aanroept. Een gewone HTML-pagina overleeft veel meer gelijktijdige bezoekers dan een WordPress-installatie zonder caching. Als er duizenden nepverzoeken per seconde binnenkomen, is het snel over.
Wat veel mkb-eigenaren niet weten: je hoeft geen grote naam te zijn om doelwit te worden. Aanvallers gebruiken geautomatiseerde tools die willekeurig IP-adressen scannen en aanvallen. Jouw site is niet persoonlijk uitgekozen. Dat maakt het niet minder vervelend, maar het verklaart wel waarom een lokale klusjesman of een kleine accountant ineens midden in een aanval zit. Berichten hierover verschijnen regelmatig op nieuwssites zoals de NOS, zeker wanneer grotere golven van aanvallen meerdere sectoren tegelijk raken.
Wat je vooraf kunt regelen zonder een fortuin uit te geven
De meeste schade bij dit soort aanvallen komt niet door de aanval zelf, maar door het gebrek aan voorbereiding. Hier is wat ik bij elke WordPress-site sowieso instel:
Caching op serverniveau
Een goede cachingoplossing zorgt ervoor dat WordPress niet bij elk verzoek de database hoeft te raadplegen. Statische HTML-bestanden worden geserveerd in plaats van dynamisch gegenereerde pagina’s. Tools als WP Super Cache of W3 Total Cache doen dit op pluginniveau, maar het beste resultaat krijg je als de hostingpartij ook serversijdige caching aanbiedt. Vraag daar expliciet naar.
Rate limiting via de webserver of firewall
Dit is een instelling die bepaalt hoeveel verzoeken één IP-adres per seconde mag sturen. Overschrijdt iemand die limiet, dan wordt de verbinding geweigerd. Op Apache stel je dit in via .htaccess, op Nginx via limit_req_zone. Veel managed WordPress-hosters bieden dit als schakelaar in hun dashboard. Zet het aan.
Een WAF — Web Application Firewall
Cloudflare heeft een gratis laag die al het verkeer naar jouw site filtert voordat het jouw server bereikt. Dat betekent dat een groot deel van het aanvalsverkeer al geblokkeerd wordt voordat het jouw WordPress-installatie ook maar raakt. De instelling “I’m Under Attack Mode” in Cloudflare is letterlijk een knop die je kunt indrukken als er een aanval gaande is. Die knop heeft mij al meerdere keren gered.
Back-ups die écht werken
Een aanval zelf beschadigt zelden je bestanden, maar de paniek erna wel. Als een hostingprovider de server offline haalt en jij in je haast verkeerde dingen doet, wil je een recente back-up hebben. Zorg dat die back-up op een andere locatie staat dan de server zelf. Ik gebruik UpdraftPlus met opslag naar een externe cloudlocatie. Niet omdat het sexy is, maar omdat het werkt.
Wat je doet op het moment dat het misgaat
Je site is plat. Je hosting-provider meldt ongewoon verkeer. Wat nu?
Stap één: niet zelf gaan klikken in het WordPress-dashboard. Als de server overbelast is, maak je het alleen maar erger door extra verzoeken te sturen.
Stap twee: neem contact op met je hosting-provider. De meeste providers zien een DDoS-aanval in hun eigen monitoring en hebben al actie ondernomen. Vraag wat ze zien en of er een tijdelijke IP-blokkade mogelijk is.
Stap drie: schakel Cloudflare in als je dat nog niet hebt gedaan, of activeer de aanvalsmodus als je het al gebruikt. Dit vereist dat je de DNS van je domein naar Cloudflare hebt verplaatst. Als dat nog niet zo is, duurt het even voordat de wijziging wereldwijd is doorgevoerd — DNS-propagatie kost tijd. Doe dit dus bij voorkeur ruim vóór een aanval.
Stap vier: documenteer wat er gebeurt. Tijdstippen, foutmeldingen, wat de provider zegt. Als je later wil uitzoeken waar het verkeer vandaan kwam of een claim wil indienen, heb je die informatie nodig.
Stap vijf: check na het herstellen je WordPress-logs op ongewone activiteit. Een DDoS-aanval wordt soms gecombineerd met een inlogpoging op wp-login.php. Terwijl jij afgeleid bent door de aanval, probeert iemand anders binnen te komen via de achterdeur. Beperk toegang tot het inlogscherm via IP-whitelisting of een tweefactorauthenticatie-plugin.
Tot slot
Een DDoS-aanval is vervelend, maar het is ook een van de weinige problemen waartegen je je redelijk goed kunt wapenen zonder een groot budget. Caching, een firewall, rate limiting en een back-up op een externe locatie — dat is geen luxe, dat is onderhoud. Hetzelfde onderhoud dat ik elke maand doe voor de sites die ik beheer.
De klant van die dinsdagochtend heeft nu Cloudflare actief, een caching-plugin ingesteld en een wekelijkse back-up naar externe opslag. Zijn site staat er nog. En de volgende keer dat er iets langskomt, staat hij er minder verbaasd bij.