DDoS aanval voorkomen met checklist en noodplan

Een ddos aanval voorkomen is het vooraf beperken van verkeer, afhankelijkheden en reactietijd, zodat een website of online dienst bereikbaar blijft wanneer aanvallers massaal verzoeken sturen.

Een kleine webshop kan binnen enkele minuten omzet verliezen als betaalpagina’s niet laden. Ook een ledenportaal, reserveringssysteem of API kan stilvallen; toch zijn de eigen servers dan technisch niet “gehackt”. Bij een DDoS draait de aanval vaak om uitputting: bandbreedte, CPU, geheugen, sessies of applicatielogica raken vol.

Deze gids laat zien welke risico’s je vooraf in kaart brengt, welke technische maatregelen helpen en welke afspraken je met leveranciers vastlegt. Daarnaast krijg je een praktisch noodplan met rollen, escalatie en communicatie. Zo kun je voorbereiding omzetten in concrete acties, zonder te verdwalen in jargon.

Welke risico’s moet je in kaart brengen om een DDoS-aanval te voorkomen?

Een goede DDoS-voorbereiding begint echter met het benoemen van de diensten die echt bereikbaar moeten blijven. Breng per website, API, DNS-zone en klantportaal in kaart hoeveel uitval je kunt verdragen en wie geraakt wordt. Een betaalpagina heeft vaak een andere prioriteit dan een marketingpagina.

Gebruik een eenvoudige indeling met 3 niveaus: kritiek, belangrijk en ondersteunend. Daarbij krijgen kritieke diensten monitoring per minuut, noodcontacten en vooraf ingestelde beschermingsregels. Ondersteunende pagina’s mogen soms tijdelijk statisch of vertraagd beschikbaar zijn.

Maak ook onderscheid tussen DoS en DDoS. Bij DoS komt de overlast uit één bron of een klein aantal bronnen, terwijl DDoS-aanvallen vaak veel apparaten tegelijk gebruiken. Wie de bredere basis wil begrijpen, kan eerst het verschil tussen DoS en DDoS bekijken.

Bedrijfskritische onderdelen tellen zwaarder dan techniek

Een DDoS-risico is niet alleen een netwerkprobleem. Een klantenservice kan vastlopen als het statusbericht ontbreekt, terwijl de technische storing al wordt opgelost. Daarom hoort een risicokaart ook bedrijfsprocessen te tonen.

Noteer per dienst de eigenaar, het normale verkeer, de piekuren en de afhankelijkheden. Een webshop ziet bijvoorbeeld tussen 19.00 en 22.00 uur vaak meer verkeer dan om 03.00 uur. Monitoring moet die normale pieken herkennen, anders lijkt elke campagne op een aanval.

Let op: een “onbeperkt” hostingpakket betekent niet dat een server onbeperkt verzoeken aankan. Vraag altijd naar concrete limieten voor bandbreedte, verbindingen per seconde en noodsupport buiten kantooruren.

Van botnet tot downtime: de aanvalsstroom in stappen

Een DDoS-aanval kan volgens een herkenbare stroom verlopen. Een aanvaller kan bijvoorbeeld opdrachten naar besmette apparaten sturen, waarna die apparaten verkeer naar het doel sturen. Zulke netwerken van besmette systemen worden vaak een groep overgenomen apparaten genoemd.

Daarom helpt een statische aanvalsstroom teams sneller praten over dezelfde feiten:

• Aansturing: de aanvaller kiest doel, tijdstip en aanvalstype.
• Verkeer: veel apparaten sturen verzoeken of pakketten tegelijk.
• Netwerklaag: routers, verbindingen of firewalls raken verzadigd.
• Applicatielaag: webserver, database of loginfunctie krijgt te veel werk.
• Gebruiker: pagina’s laden traag, tonen foutcodes of worden onbereikbaar.

Een voorbeeld: een lokale ticketwebsite kan normaal 80 verzoeken per seconde verwerken. Tijdens een populaire verkoop stijgt dat tijdelijk naar 300. Als een aanval 5.000 verzoeken per seconde veroorzaakt, moet bescherming al vóór de webserver ingrijpen.

Preventieve maatregelen om een DDoS-aanval te voorkomen

Preventieve DDoS-maatregelen met doel, toepassingsmoment en verantwoordelijke partij

Maatregel	Doel	Wanneer toepassen	Wie is verantwoordelijk
CDN	Verkeer spreiden	Publieke websites	Websitebeheerder
Rate limiting	Verzoeken begrenzen	Login, API, zoeken	Applicatiebeheerder
DDoS-filtering	Kwaad verkeer blokkeren	Altijd bij kritieke diensten	Hostingpartij
Monitoring	Afwijkingen zien	24/7 of kantooruren	IT-beheer
Statische noodpagina	Communicatie behouden	Bij traagheid of uitval	Communicatieteam
DNS-redundantie	Naamomzetting beschermen	Bij meerdere domeinen	Domeinbeheerder

Preventieve maatregelen verlagen vooral de kans dat kwaadaardig verkeer je eigen server bereikt. Een CDN vangt veel statische verzoeken af, rate limiting remt misbruik per IP of account, en monitoring toont afwijkingen binnen minuten. Daardoor helpt deze basis als je een ddos aanval voorkomen wilt voordat de verbinding volloopt. DDoS-bescherming bij netwerk of hosting filtert verkeer voordat de verbinding volloopt.

Niet elke maatregel past bij elke organisatie. Een interne applicatie met 40 gebruikers heeft meer aan toegangsbeperking en monitoring dan aan zware publieke filtering. Daarentegen heeft een webshop met landelijke campagnes bescherming nodig vóór de piek begint.

Vuistregel: bescherm de laag die als eerste volloopt; bij bandbreedte kies je netwerkfiltering, bij loginmisbruik kies je rate limiting en applicatieregels.

CDN, rate limiting en monitoring in samenhang

Een CDN slaat kopieën van statische bestanden op dichter bij bezoekers. Daardoor hoeven afbeeldingen, scripts en stijlpagina’s niet steeds van je eigen server te komen. Bij een aanval kan dat merkbaar serverwerk schelen, afhankelijk van hoeveel statische inhoud je site gebruikt.

Rate limiting stelt grenzen in, zoals maximaal 10 loginpogingen per minuut per IP-adres. Bovendien kun je voor API’s ook limieten per token, account of route gebruiken. Hierdoor blijft een zoekfunctie of loginpagina bruikbaar voor echte bezoekers.

Monitoring moet drie soorten signalen tonen: verkeer, foutcodes en responstijd. Een stijging van 5xx-foutcodes boven 5 procent kan bijvoorbeeld een duidelijk alarmsignaal zijn. Combineer dat met p95-responstijd, zodat je niet alleen gemiddelden ziet.

Een DDoS-plan werkt pas als techniek, leveranciers en communicatie elkaar versterken. Losse tools kopen tijd; afspraken bepalen wat er met die tijd gebeurt.

Bescherming op applicatielaag en netwerklaag

DDoS-verkeer komt niet altijd als ruwe pakketstorm binnen. Een HTTP flood lijkt soms op normaal webverkeer, maar vraagt dezelfde pagina of zoekfunctie duizenden keren op. Meer uitleg over dit type applicatieaanval staat in onze gids over overbelasting via webverzoeken.

Netwerkgerichte aanvallen proberen juist verbindingen of routers te vullen. Denk aan grote hoeveelheden ICMP-verkeer of misbruik van slecht ingestelde diensten. Niettemin werkt bescherming dichter bij de internetverbinding meestal beter dan regels op de webserver.

Veelgemaakte fout: alleen de webserver vergroten lost een DDoS-aanval niet op als de uplink eerder volloopt. Meet daarom bandbreedte, verbindingen per seconde en applicatiebelasting apart.

Welke afspraken helpen een DDoS-aanval te voorkomen?

Leveranciersafspraken bepalen hoe snel bescherming actief wordt wanneer een DDoS-aanval begint. Leg vooraf vast wie mag escaleren, welke gegevens nodig zijn en binnen welke tijd iemand reageert. Een afspraak die pas tijdens uitval wordt besproken, kost vaak kostbare tijd.

Vraag je hostingpartij naar limieten voor verkeer, CPU, geheugen en netwerkpoorten. Vraag ook of DDoS-filtering standaard aanstaat of handmatig moet worden geactiveerd. Desondanks blijft een ddos aanval voorkomen lastig als niemand buiten kantooruren mag escaleren. Noteer daarbij het verschil tussen kantooruren, avond, weekend en feestdagen.

Een internetprovider kan anderzijds helpen bij volumetrische aanvallen die de verbinding verzadigen. Een hostingpartij ziet juist vaak applicatielogs, serverbelasting en foutcodes. Tegelijk moeten beide partijen elkaar kunnen bereiken, anders blijft elk team naar een ander dashboard kijken.

Minimale afspraken vóór de eerste aanval

Maak afspraken kort, concreet en meetbaar. Een bruikbare afspraak zegt bijvoorbeeld: “noodnummer 24/7 bereikbaar” of “eerste technische reactie binnen 15 minuten bij kritieke uitval”. Vermijd vage termen zoals “zo snel mogelijk”.

Neem deze punten op in contract, beheerafspraak of intern document:

• 24/7-noodcontact voor kritieke diensten.
• Minimaal 2 bevoegde contactpersonen aan jouw kant.
• Criteria voor het activeren van DDoS-filtering.
• Maximale responstijd per prioriteitsniveau.
• Beschikbare logging tijdens en na een incident.
• Afspraak over tijdelijke blokkades per land, route of protocol.
• Evaluatie binnen 5 werkdagen na herstel.

Let ook op bevoegdheden. Een servicedesk kan soms geen filtering inschakelen zonder toestemming van een contractbeheerder. Geef daarom vooraf aan wie namens de organisatie mag beslissen tijdens een incident.

Praktische tip: test noodnummers elk kwartaal met een korte bereikbaarheidstest. Een telefoonnummer dat na 6 maanden niet meer klopt, maakt elk noodplan zwakker.

Wat zet je in een DDoS-noodplan om een aanval te voorkomen?

Een DDoS-noodplan voor kleine organisaties moet kort genoeg zijn om onder druk te gebruiken. Eén document van 2 tot 4 pagina’s werkt beter dan een lang handboek. Het plan moet contactpersonen, drempels, taken, communicatie en herstelcontrole bevatten.

Gebruik duidelijke actieniveaus. Niveau 1 betekent verhoogde traagheid, niveau 2 betekent gedeeltelijke uitval en niveau 3 betekent volledige onbereikbaarheid van een kritieke dienst. Koppel elk niveau aan taken en verantwoordelijken.

Toch heeft een klein team vaak geen aparte securityafdeling. Daarom moet het noodplan rollen gebruiken in plaats van functietitels. Denk aan technisch coördinator, leveranciercontact, besluitvormer en communicatieverantwoordelijke.

Kort voorbereidingssjabloon voor contact en escalatie

Onderstaand sjabloon kun je als tekst opnemen in je interne beheerpagina of incidentdocument. Vul het vóór een aanval in en bewaar een kopie buiten de getroffen omgeving. Een noodplan op dezelfde server als de website helpt niet bij volledige uitval.

• Dienst: naam van website, webshop, API of portaal.
• Prioriteit: kritiek, belangrijk of ondersteunend.
• Technisch contact: naam, mobiel nummer en alternatief kanaal.
• Leveranciercontact: hostingpartij, internetprovider en contractnummer.
• Besluitvormer: persoon die blokkades of noodpagina’s mag goedkeuren.
• Escalatieroute: niveau 1 na 10 minuten, niveau 2 na 20 minuten, niveau 3 na 30 minuten.
• Noodcommunicatie: statuspagina, e-mailtekst en socialemediakanaal.
• Herstelcheck: foutcodes, responstijd, bestellingen, formulieren en logins.

Maak noodcommunicatie feitelijk en rustig. Zeg welke dienst hinder ondervindt, wat gebruikers kunnen doen en wanneer de volgende update komt. Een update elke 30 minuten voorkomt losse berichten van meerdere medewerkers.

Wat moet er minimaal in de eerste 60 minuten gebeuren?

De eerste 60 minuten bepalen vaak de schade. Een team moet niet discussiëren over definities, maar bewijs verzamelen en leveranciers inschakelen. Houd daarom de eerste acties klein en herhaalbaar.

Een werkbaar eerste-uurbeeld ziet er zo uit: binnen 5 minuten bevestigt monitoring de afwijking, binnen 10 minuten kijkt iemand naar foutcodes en bandbreedte, binnen 15 minuten meldt de leverancier het incident. Na 30 minuten staat een intern besluit klaar over noodpagina’s of tijdelijke blokkades. Na 60 minuten volgt een statusupdate en een keuze voor opschalen of afbouwen.

Een voorbeeldscenario maakt dit concreet. Een reserveringssysteem verwerkt normaal 120 verzoeken per minuut, ziet plots 8.000 verzoeken per minuut, toont 12 procent 5xx-fouten en heeft een p95-responstijd van 9 seconden. De uitkomst is niveau 2: DDoS-filtering activeren, zoekroutes beperken en elke 30 minuten communiceren.

Welke maatregelen kun je nemen voordat er een aanval plaatsvindt?

Vooraf kun je technische, organisatorische en communicatieve maatregelen nemen die samen de impact beperken. Werk eerst de kritieke diensten af, stel daarna drempels in en spreek met leveranciers af wie welke actie uitvoert. Een ddos aanval voorkomen lukt vooral door keuzes vóór stress vast te leggen.

Vervolgens kun je onderstaande checklist gebruiken als basis voor kleine en middelgrote organisaties. De lijst combineert serverbeheer, webapplicatiebeheer en besluitvorming. Gebruik “ddos aanval voorkomen” daarbij als korte projectnaam voor voorbereiding, afspraken en tests. Kruis alleen af wat ook getest of schriftelijk vastgelegd is.

• Inventariseer alle publieke domeinen, IP-adressen, API’s en DNS-records.
• Bepaal per dienst de maximale acceptabele uitval, bijvoorbeeld 15, 30 of 60 minuten.
• Schakel caching in voor statische bestanden zoals afbeeldingen, scripts en stijlpagina’s.
• Stel rate limits in voor login, zoeken, formulieren en API-routes.
• Maak een statische noodpagina die buiten de hoofdserver beschikbaar blijft.
• Bewaar minimaal 30 dagen aan relevante logs voor verkeer, foutcodes en serverbelasting.
• Leg 2 interne en 2 externe noodcontacten vast.
• Controleer of DNS, hosting en domeinbeheer niet van één kwetsbaar account afhangen.
• Gebruik meerfactorauthenticatie voor beheerpanelen en domeinaccounts.
• Plan elk kwartaal een korte oefening van 30 tot 60 minuten.

Deze checklist past binnen bredere maatregelen voor digitale weerbaarheid. DDoS-preventie staat namelijk niet los van accountbeveiliging, logging en incidentbeheer. Een aanvaller kan druk zetten met verkeer en tegelijk phishing gebruiken tegen medewerkers.

Hoe test je voorbereiding om een DDoS-aanval te voorkomen?

Testen hoeft geen zware aanvalssimulatie te zijn. Een veilige oefening controleert echter vooral of mensen, nummers, dashboards en besluiten werken. Gebruik geen ongecontroleerde verkeerstoetsen op productie, want daarmee veroorzaak je mogelijk zelf uitval.

Begin met een tafeloefening van 45 minuten. Eén persoon leest een scenario voor, de rest volgt het noodplan en noteert gaten. Zo ontdek je snel of contactgegevens ontbreken, wie mag escaleren en welke informatie de leverancier nodig heeft.

Meet tijdens gewone piekmomenten wat normaal is. Noteer verzoeken per minuut, gemiddelde responstijd, p95-responstijd, foutcodes en CPU-belasting. Zonder normale waarden herken je afwijkingen later minder snel.

Gebruik één verbetercyclus na elke oefening

Een oefening levert pas waarde op als iemand verbeteringen afrondt. Kies maximaal 5 acties per ronde, anders blijft de lijst liggen. Geef elke actie een eigenaar en een datum binnen 30 dagen.

Een nuttige verbetercyclus bestaat uit observeren, besluiten, aanpassen en opnieuw testen. Bijvoorbeeld: monitoring meldt geen API-fouten, dus het team voegt een aparte API-check toe. Bijgevolg kan het team bij de volgende oefening controleren of de melding binnen 5 minuten binnenkomt.

Vermijd schijnzekerheid. Een groen dashboard zegt weinig als niemand het alarm hoort. Test daarom ook meldingen via e-mail, telefoon of chatkanaal, inclusief avonduren als je dienst dan omzet of klantcontact verwerkt.

Wat moet je doen als je vermoedt dat een aanval begint?

Bij een vermoedelijke DDoS-aanval moet je snel bevestigen, beperken en communiceren. Gebruik daarom één vaste volgorde, zodat het team niet tegelijk losse acties uitvoert. De stappen hieronder passen bij een klein team met hostingpartij of beheerpartner.

1. Controleer binnen 5 minuten verkeer, foutcodes en responstijd in je monitoring.
2. Vergelijk de piek met bekende campagnes, releases of normale drukke uren.
3. Schakel de afgesproken hostingpartij of internetprovider in met tijdstip, domein en symptomen.
4. Activeer vooraf goedgekeurde rate limits, noodpagina’s of tijdelijke blokkades.
5. Wijs één persoon aan voor interne updates en één persoon voor externe communicatie.
6. Bewaar logs, tijdlijn en genomen beslissingen voor de evaluatie achteraf.

Een DDoS-incident vraagt vaak om tijdelijke keuzes. Je kunt bijvoorbeeld een zoekfunctie beperken om betalingen bereikbaar te houden. Leg zulke keuzes vooraf vast, zodat een beheerder niet alleen hoeft te beslissen tijdens druk.

We hebben geleerd dat een kort, getest plan meestal meer waarde heeft dan een dik document dat niemand opent. Onze voorkeur gaat uit naar duidelijke drempels, twee bereikbare contactpersonen en een oefening die ook communicatie raakt. Die nuchtere aanpak past bij hoe Virus.NL naar digitale weerbaarheid kijkt — het team van Virus.NL.

Veelgestelde vragen

De vragen hieronder helpen je de belangrijkste keuzes rond ddos aanval voorkomen snel te controleren.

Welke maatregelen kun je nemen voordat er een aanval plaatsvindt?

Breng eerst kritieke diensten, normale verkeerspieken en leveranciers in kaart. Stel daarna caching, rate limiting, monitoring en noodcontacten in. Leg ook vast wie mag beslissen over tijdelijke blokkades of noodpagina’s. Test deze afspraken minimaal elk kwartaal met een korte oefening van 30 tot 60 minuten.

Welke rol spelen CDN, rate limiting, monitoring en DDoS-bescherming?

Een CDN vermindert serverbelasting door statische inhoud op te vangen. Rate limiting begrenst misbruik bij login, formulieren en API’s. Monitoring toont afwijkingen zoals hoge foutpercentages of trage responstijd. DDoS-bescherming filtert verkeer vaak vóórdat het de eigen server of verbinding bereikt.

Welke afspraken moeten vooraf met leveranciers worden gemaakt?

Leg noodcontacten, responstijden, escalatierechten en activeringscriteria vast. Vraag of DDoS-filtering standaard actief is of handmatig moet worden aangezet. Noteer ook welke logs beschikbaar blijven tijdens een incident. Spreek af dat evaluatie binnen 5 werkdagen na herstel plaatsvindt.

Wat moet er minimaal in een DDoS-noodplan staan?

Een DDoS-noodplan bevat de kritieke diensten, prioriteiten, contactpersonen, escalatieroute, technische drempels en noodcommunicatie. Voeg ook herstelchecks toe voor foutcodes, responstijd, formulieren, betalingen en logins. Bewaar het plan buiten de getroffen omgeving, bijvoorbeeld in een apart intern document.

Kun je een ddos aanval voorkomen met alleen meer servercapaciteit?

Meer servercapaciteit helpt alleen als de server zelf de zwakke plek is. Bij verzadigde bandbreedte, DNS-problemen of applicatielogica lost extra CPU weinig op. Combineer capaciteit daarom met filtering, caching, rate limits en afspraken met hostingpartij en internetprovider.

Conclusie: ddos aanval voorkomen vraagt om techniek én regie

Een ddos aanval voorkomen begint niet bij paniek tijdens uitval, maar bij keuzes die al vastliggen. Wie kritieke diensten kent, normale verkeerswaarden meet en leveranciersafspraken heeft, wint kostbare minuten. CDN, rate limiting, monitoring en DDoS-bescherming werken vooral goed als iemand weet wanneer ze worden ingezet.

De sterkste voorbereiding combineert technische remmen met bestuurlijke duidelijkheid. Een klein team heeft geen groot securitycentrum nodig om beter voorbereid te zijn. Het heeft wel bereikbare contactpersonen, meetbare drempels, een kort noodplan en regelmatige oefening nodig.

Wil je de basis rond aanvalstypen, risico’s en bredere bescherming verder aanscherpen, lees dan ook onze uitleg over netwerkaanvallen die diensten overbelasten. Gebruik daarna de checklist uit dit artikel om je eigen afspraken, monitoring en noodcommunicatie stap voor stap vast te leggen.