DDoS-aanval op je website? Dit moet je nu doen

Is je site plotseling traag of onbereikbaar en ziet je server veel meer verzoeken dan normaal, dan is er misschien sprake van een DDoS-aanval. Het meest effectieve wat je nu kunt doen, is filtering vóór je server zetten, want een server die al overbelast is, kan zichzelf niet meer verdedigen. Deze gids helpt je een aanval te herkennen, het eerste uur goed door te komen en je opstelling zo in te richten dat de volgende aanval veel minder pijn doet.

Zo herken je een DDoS-aanval

Bij een distributed denial-of-service-aanval (DDoS) wordt je site vanuit veel bronnen tegelijk overspoeld met verkeer, zodat echte bezoekers er niet meer doorheen komen. Niet elke verkeerspiek is een aanval. Een nieuwsbrief, een vermelding op tv of een uitverkoop kan er op het eerste gezicht hetzelfde uitzien. Let op deze patronen:

• De piek heeft geen zakelijke reden. Geen campagne, geen pers, geen lancering, en toch schieten de verzoeken omhoog.
• Verzoeken gaan naar steeds dezelfde paar URL's. Vaak de homepage, een zoekpagina, een loginpagina of een URL met willekeurige querystrings (/?x=83729) die bedoeld zijn om caches te omzeilen.
• Vreemde verkeersbronnen. Veel verzoeken uit landen waar je geen klanten hebt, uit IP-reeksen van hostingproviders, of met identieke of lege user agents.
• Geen conversies. Het verkeer stijgt, maar verkopen, aanmeldingen en tijd op de pagina bewegen totaal niet.
• Je server zit aan zijn max. CPU, PHP-workers of databaseverbindingen zitten aan hun limiet, en het foutlog loopt vol met time-outs en 502-, 503- en 504-fouten.

Bekijk je access log

Heb je shelltoegang, dan vertelt een snelle blik in het access log je al veel. Deze commando's tonen de IP's met de meeste verzoeken en de vaakst opgevraagde paden (pas het pad naar het log aan voor jouw server):

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

Een handvol IP's die duizenden verzoeken sturen, wijst op een kleine aanval die je direct kunt blokkeren. Duizenden IP's die elk een gemiddelde hoeveelheid sturen, wijzen op een botnet, en dat is op serverniveau veel lastiger te stoppen.

Soorten aanvallen die je kunt tegenkomen

Als je ongeveer weet om welk type het gaat, kies je makkelijker de juiste aanpak.

De meeste aanvallen op websites van kleine en middelgrote bedrijven zijn HTTP-floods op Layer 7. Die hebben geen enorme bandbreedte nodig, want elk verzoek laat je server duur werk doen: een pagina renderen, een zoekopdracht uitvoeren, de database bevragen. Een paar honderd ongecachete verzoeken per seconde kunnen genoeg zijn om een doorsnee webshop of CMS plat te leggen.

Wat je in het eerste uur doet

Blijf rustig en werk dit op volgorde af. Schrijf op wat je doet en wanneer, want dat heb je later nodig.

1. Bevestig en communiceer

Zorg dat het geen mislukte deploy, een haperende plug-in of een legitieme piek is. Informeer daarna de mensen die het moeten weten: je team, je bureau en je hostingprovider. Hosts zien de aanval vaak in hun netwerkmonitoring en filteren misschien al, of routeren in sommige gevallen je IP naar nergens (null-routing) om andere klanten te beschermen.

2. Neem contact op met je host

Vraag je host rechtstreeks: wat zien jullie, welke bescherming hebben jullie en kunnen jullie op netwerkniveau filteren? Sommige hosts bieden basisbescherming tegen DDoS, andere niet. Wordt je server via null-routing afgesloten, dan heb je een filterlaag ervoor nodig voordat hij weer online komt.

3. Blokkeer wat je kunt identificeren

Komt de aanval van een klein aantal IP's of reeksen, blokkeer die dan in je firewall of de configuratie van je webserver. Richt hij zich op één dure URL, zoals een zoekendpoint, beperk die dan tijdelijk met rate limiting of schakel hem uit. Komt het verkeer vooral uit landen die je niet bedient, dan kan een tijdelijke geoblokkade of challenge je tijd opleveren. Dit zijn noodoplossingen, geen strategie.

4. Zet een filterlaag vóór je server

De echte oplossing is om schadelijk verkeer tegen te houden voordat het je origin bereikt. Een reverse proxy of CDN met DDoS-bescherming vangt verzoeken aan de edge op en filtert ze, en je server ziet alleen wat erdoor komt. Aansluiten betekent meestal dat je de nameservers van je domein omzet, en dat wordt actief zodra DNS-caches verlopen. Doe je dit midden in een aanval, volg dan een checklist zodat je geen e-mail of andere records kwijtraakt. Onze gids over nameservers wijzigen zonder downtime behandelt precies dat.

5. Beperk het werk per verzoek

Maak elk verzoek goedkoper zolang de aanval loopt. Lever waar mogelijk gecachete pagina's, schakel zware functies uit die je een dag kunt missen (live zoeken, widgets met gerelateerde producten, externe API-aanroepen) en zorg dat willekeurige querystrings je caching niet omzeilen.

Fouten die je tijdens een aanval moet vermijden

• Upgrade niet alleen de server. Meer CPU helpt even, maar aanvallers kunnen meestal sneller opschalen dan jouw hostingbudget. Tegen floods op bandbreedte helpt het ook niet.
• Betaal geen losgeld. Sommige aanvallen gaan gepaard met een eis. Betalen garandeert niets en maakt je tot een gewillig doelwit. Doe aangifte van afpersing bij de politie.
• Blokkeer niet te breed. Hele landen of alle bots blokkeren kan klanten en crawlers van zoekmachines buitensluiten. Kies bij twijfel liever een challenge dan een harde blokkade, en verwijder tijdelijke regels zodra de aanval voorbij is.
• Vergeet andere aanvalsvlakken niet. Een DDoS is soms een afleidingsmanoeuvre. Controleer achteraf logins, beheerdersaccounts en recente wijzigingen. Ook het overzicht van CISA over denial-of-service-aanvallen (Engelstalig) wijst hierop.

Na de aanval: maak je opstelling robuuster

Is het weer rustig, gebruik dan wat je hebt geleerd. Het doel: de volgende aanval stuit op een filter, niet op je server.

Houd blijvend een proxy ervoor

Filtering aan de edge werkt het best als die er al staat. Voeg je hem midden in een aanval toe, dan verlies je tijd terwijl de DNS-wijzigingen zich verspreiden. Weet je niet precies wat een CDN naast snelheid voor je doet, lees dan wat een CDN is en of je website er een nodig heeft.

Cache zoveel als veilig kan

Elke pagina die uit een cache komt, is een verzoek dat je server nooit ziet. Openbare pagina's zoals de homepage, categorieën, productpagina's en blogposts horen gecachet te worden. Persoonlijke pagina's zoals winkelwagen, checkout en account moeten dynamisch blijven. Een hoge cache hit ratio betekent ook dat je server meer ruimte overhoudt voor echte bezoekers, en een snelle origin helpt ook: zie TTFB verlagen.

Scherm de origin af

Laat HTTP- en HTTPS-verkeer naar je server alleen toe vanuit de IP-reeksen van je proxy. Houd het origin-IP uit openbare DNS-records, e-mailheaders en oude subdomeinen, want langs die weg vinden aanvallers het meestal.

Stel rate limits en meldingen in

Rate limits op logins, zoekfuncties en API's stoppen zowel floods als brute-forcepogingen. Met meldingen bij verkeerspieken en foutpercentages hoor je van de volgende aanval via een notificatie, niet via een klant.

Schrijf een kort draaiboek

Eén pagina is genoeg: wie je belt bij je host, wie toegang heeft tot DNS en het dashboard van de proxy, welke regels je aanzet en hoe je klanten informeert. Midden in een aanval wil niemand naar wachtwoorden zoeken.

Zo helpt fast.site je

fast.site zit vóór je bestaande hosting. Je houdt je host en laat de nameservers van je domein naar fast.site wijzen. Vanaf dat moment komt het verkeer eerst bij het edge-netwerk binnen en wordt het daar gefilterd, voordat er iets naar je origin wordt doorgestuurd.

DDoS-detectie op Layer 7 draait automatisch op alle domeinen, zonder dat je iets hoeft in te stellen. Daarnaast kun je IP's en CIDR-reeksen blokkeren, hele landen blokkeren of met een CAPTCHA uitdagen, eigen challengeregels maken en rate limits per IP instellen. Beheerde regelsets beschermen tegen SQL-injectie, XSS en kwaadaardige bots. Zie de beveiligingsdocumentatie voor de details.

Caching verlaagt de belasting nog verder. Openbare pagina's die vanaf de edge komen, tonen fs-cache: HIT en raken je server nooit, terwijl winkelwagens, checkouts en ingelogde sessies BYPASS tonen en zoals gewoonlijk naar je origin gaan. De analytics tonen verzoeken, foutpercentages en bandbreedte vanaf de origin, en anomaliemeldingen waarschuwen je bij verkeerspieken.

Word je op dit moment aangevallen, ga dan naar de pagina voor acute aanvallen voor de snelste route. Anders richt je de bescherming in alle rust in en controleer je het resultaat op je eigen site. Je kunt starten met een gratis proefperiode van 7 dagen, zonder creditcard. Abonnementen en inbegrepen verkeer vind je op de prijspagina.

Veelgestelde vragen

Hoe lang duurt een DDoS-aanval?

Dat verschilt sterk. Sommige aanvallen duren minuten, andere komen in golven over meerdere dagen. Korte uitbarstingen zijn gebruikelijk, vaak als test voor een grotere aanval of samen met een losgeldeis. Daarom heb je meer aan bescherming die altijd aanstaat dan aan iets wat je tijdens een aanval inschakelt.

Kan een DDoS-aanval mijn SEO schaden?

Een korte storing heeft meestal geen blijvend effect. Blijft je site langere tijd onbereikbaar of geeft hij fouten, dan kunnen zoekmachines hem minder vaak crawlen en pagina's tijdelijk laten vallen. Door de site snel weer online te krijgen en correcte statuscodes terug te geven, beperk je de schade.

Is een DDoS-aanval strafbaar?

Ja, in de meeste landen is het uitvoeren van een DDoS-aanval een strafbaar feit. Bewaar logs, tijdstippen en eventuele losgeldberichten, en doe aangifte bij de politie of de nationale eenheid voor cybercrime. Dat is extra belangrijk als er geld wordt geëist.

Kan een beveiligingsplug-in voor WordPress een DDoS-aanval stoppen?

Niet echt. Een plug-in draait binnen WordPress, dus elk verzoek bereikt nog steeds je server, start PHP en bevraagt vaak de database voordat de plug-in kan blokkeren. Dat is precies de belasting waar een DDoS op leunt. Plug-ins zijn nuttig tegen loginaanvallen en malware, maar DDoS-filtering moet vóór de server gebeuren.

Waarom is mijn site traag terwijl het verkeer normaal lijkt?

Dan is het waarschijnlijk geen DDoS. Veelvoorkomende oorzaken zijn trage hosting, zware plug-ins, ongecachete pagina's of grote afbeeldingen. Het supportartikel over een trage site is een goed startpunt.