DDoS-bescherming voor websites: wat echt helpt

Goede DDoS-bescherming voor een website is niet één product, maar een paar lagen die elk een ander soort aanval tegenhouden: netwerkfiltering tegen pure floods, een reverse proxy vóór de site, regels tegen aanvallen op applicatieniveau en een originserver die alleen met die proxy praat. Timing is het belangrijkst, want bescherming die al klaarstaat werkt vanaf het eerste verzoek, terwijl bescherming die je midden in een aanval toevoegt je uren kost. Wordt je site nu aangevallen, ga dan naar de pagina voor sites onder aanval of lees onze gids over wat je doet bij een DDoS-aanval op je website.

Waarom bescherming vóór je server hoort

Een server die druk bezig is met het beantwoorden van nepverzoeken, kan niet ook nog uitzoeken welke verzoeken nep zijn. Tegen de tijd dat een firewallregel of beveiligingsplug-in op je server een verzoek bekijkt, is de bandbreedte al verbruikt en is PHP vaak al gestart. Effectieve bescherming filtert zo ver mogelijk van de origin vandaan.

Voor preventie is de nuttige vraag welke laag welk type aanval tegenhoudt:

Geen enkele laag dekt alles af: een proxy zonder afgeschermde origin kan worden omzeild, en een afgeschermde origin zonder proxy staat er bij elke HTTP-flood alleen voor.

De vier lagen in detail

1. Netwerkniveau: volumetrische en protocolfloods

Volumetrische aanvallen vullen de verbinding naar je server met meer verkeer dan die aankan. Niets wat je op de server instelt helpt, want de verbinding zit vol voordat je firewall ook maar één pakket ziet. Deze laag wordt eerder in de keten afgehandeld, door het netwerk van je hoster of een gespecialiseerde scrubbingdienst. Jouw taak is weten wat je hoster hier doet, en je origin-IP achter een proxy verbergen, zodat aanvallers het netwerk van de proxy moeten overspoelen in plaats van de verbinding van je server.

2. Een reverse proxy vóór de hele site

Een full-site reverse proxy ontvangt elk verzoek voor je domein, beantwoordt wat hij kan uit zijn cache en stuurt de rest door naar je origin. Twee effecten tellen:

• Gecachete pagina's zijn goedkoop. Een flood op je homepage is onschadelijk als de homepage vanaf de edge wordt geleverd en je server nooit bereikt.
• Er wordt gefilterd vóór de origin. Regels, rate limits en challenges draaien aan de edge, dus geblokkeerde verzoeken kosten je server niets.

Zorg dat de proxy ook je HTML afdekt. Een asset-CDN dat alleen afbeeldingen en scripts via een aparte hostnaam levert, maakt je site sneller, maar paginaverzoeken gaan nog steeds rechtstreeks naar je server, en aanvallen dus ook. De gids over wat een CDN is legt het verschil uit.

3. WAF, rate limiting en botregels voor Layer 7

Floods op applicatieniveau zijn de meest voorkomende aanvallen op kleine en middelgrote sites, en ze zijn het moeilijkst te herkennen, want elk afzonderlijk verzoek ziet er legitiem uit. Ze richten zich op de URL's die je server het meeste werk bezorgen, dus stem je regels daarop af:

Een web application firewall (WAF) met beheerde regelsets blokkeert daarnaast pogingen tot misbruik zoals SQL-injectie en cross-site scripting, en botregels houden scrapers buiten. Landenregels helpen als je maar een paar markten bedient, maar kies liever voor een challenge dan voor een harde blokkade, zodat klanten met een VPN er nog doorheen komen.

4. De origin afschermen

Een proxy beschermt je alleen als aanvallers er niet omheen kunnen. Staat je site er eenmaal achter, scherm dan de origin af:

• Accepteer webverkeer alleen van de proxy. Stel de firewall van je server of hoster zo in dat poort 80 en 443 alleen verbindingen accepteren van de gepubliceerde IP-reeksen van je proxyaanbieder.
• Ga ervan uit dat oude DNS-records bekend zijn. Wees je domein vroeger rechtstreeks naar je server, dan maken diensten die historische DNS-gegevens archiveren dat IP-adres gemakkelijk te vinden. Vraag je hoster of je na de overstap een nieuw IP-adres kunt krijgen.
• Controleer subdomeinen. Records zoals staging, dev, ftp, cpanel of mail wijzen vaak direct naar dezelfde server en verraden zo de origin.
• Scheid e-mail van de webserver. Wijst je MX-record naar de webserver, of verstuurt de server zelf de mails van je contactformulier, dan staat het IP-adres in de DNS en in de Received-headers van elke e-mail. Controleer ook je SPF-record op ip4:-vermeldingen die de server verraden.

Met een snelle controle zie je welke records naar je origin-IP verwijzen:

dig +short example.com A
dig +short mail.example.com A
dig +short example.com MX
dig +short example.com TXT

Elk antwoord met het IP-adres van je server is een route om je proxy heen.

Wat je hoster afdekt, en wat niet

Veel hosters filteren grote volumetrische aanvallen aan de rand van hun netwerk. Dat beschermt hun infrastructuur en alle klanten daarop, maar dat is niet hetzelfde als jouw site beschermen. Typische gaten:

• Layer 7-floods komen erdoor. Een paar honderd HTTP-verzoeken per seconde zijn niets voor een datacenternetwerk, maar genoeg om een gemiddeld CMS of een webshop te overbelasten.
• Null routing haalt je offline. Bedreigt een aanval het netwerk, dan stoppen sommige hosters met het routeren van verkeer naar het aangevallen IP-adres. Andere klanten zijn veilig, jouw site ligt plat.
• Resourcelimieten slaan toe. Bij shared of managed hosting kan een aanval je account tegen de CPU- of proceslimieten aan duwen, en dan wordt je site afgeknepen.
• Geen regels per site. Op netwerkniveau van de hoster kun je meestal geen eigen rate limits of challenges instellen.

Stel je hoster deze vragen en bewaar de antwoorden:

1. Welke soorten aanvallen filteren jullie, en zit filtering van HTTP-floods (Layer 7) in mijn pakket?
2. Wat gebeurt er met mijn site bij een grote aanval: afknijpen, null routing, opschorting?
3. Kan ik mijn server zo instellen dat hij alleen webverkeer van de IP-reeksen van een proxy accepteert?
4. Hoe bereik ik support tijdens een aanval?

Zo kies je een beschermingsdienst

Dekt je hoster het netwerkniveau af maar niet je applicatie, dan vult een dienst op basis van een proxy dat gat. Vergelijk op criteria, niet op marketinglabels:

• Dekking van de hele site. De dienst proxyt je HTML, niet alleen statische assets.
• Altijd actief. Permanente filtering vraagt geen omschakeling tijdens een aanval. Bij diensten die je pas op afroep inschakelt, is juist die omschakeltijd het probleem.
• Layer 7-tools die je zelf beheert. Automatische detectie plus je eigen IP-blokkades, landenregels, challenges en rate limits.
• Veilige caching en inzicht. De dienst respecteert je Cache-Control-headers, cachet nooit winkelwagens of ingelogde pagina's en toont verzoeken en fouten, met meldingen.
• Goede bots blijven werken. Zoekmachinecrawlers en callbacks van betaalproviders komen er nog door als je regels strenger worden.
• Volledige DNS. Of je nu de nameservers wijzigt of één record, MX-, TXT- en SRV-records moeten blijven werken. Onze checklist voor nameservers wijzigen zonder downtime behandelt dat.
• Facturering tijdens aanvallen. Vraag hoe aanvalsverkeer meetelt voor het inbegrepen verkeer.
• Support. Hoe je tijdens een aanval een mens te spreken krijgt.

De richtlijnen over denial of service (Engelstalig) van het Britse National Cyber Security Centre zijn goed, leveranciersonafhankelijk leesvoer voor je planning.

Een checklist om je voor te bereiden

Werk deze lijst één keer door en bekijk hem daarna om de paar maanden opnieuw:

• Contacten. Support van je hoster met je klantnummer, je bureau of ontwikkelaar, je beschermingsaanbieder, en wie beslist over het uitschakelen van functies of het informeren van klanten.
• Toegang. Minstens twee mensen kunnen inloggen bij de registrar, de DNS en het dashboard van de proxy, elk met een eigen account en tweestapsverificatie.
• DNS. Houd een actuele export van je zone bij en weet welke records bereikbaar moeten blijven.
• Monitoring. Een externe uptimecheck, meldingen bij pieken in het verkeer en bij oplopende 5xx-fouten, en zicht op de CPU van je origin.
• Draaiboek. Eén pagina met de strengere regels die je inschakelt, de zware functies die je een dag kunt uitzetten (live zoeken, aanbevelingswidgets, externe API-aanroepen) en een korte tekst voor klanten.
• Origintest. Controleer met het IP-adres van je server of je origin direct verkeer weigert:

curl -sI --max-time 10 --resolve www.example.com:443:203.0.113.10 https://www.example.com/

Krijg je een antwoord terug in plaats van een time-out of een geweigerde verbinding, dan accepteert je origin nog verkeer dat de proxy omzeilt.

Zo helpt fast.site je

fast.site is een full-site reverse proxy vóór je bestaande hosting. Je houdt je hoster en zet de nameservers van je domein over naar fast.site. Vanaf dat moment komt elk verzoek eerst bij het edge-netwerk aan en wordt het daar gefilterd voordat er iets naar je origin gaat. fast.site beheert je DNS-zone, inclusief MX-, TXT- en SRV-records, zoals beschreven in de DNS-documentatie.

Layer 7-DDoS-detectie draait automatisch op alle domeinen, zonder dat je iets hoeft in te stellen. Daarnaast kun je IP-adressen en CIDR-reeksen blokkeren, landen blokkeren of naar een CAPTCHA-challenge sturen, eigen challengeregels aanmaken en rate limits per IP instellen. Beheerde regelsets filteren SQL-injectie, XSS en schadelijke bots. De beveiligingsdocumentatie somt alle opties op.

Caching haalt ook belasting van je server: openbare pagina's tonen fs-cache: HIT en komen van de edge, terwijl winkelwagens, checkouts en ingelogde sessies BYPASS tonen. Analytics laat verzoeken, foutpercentages en de bandbreedte van je origin zien, en meldingen bij afwijkingen waarschuwen je voor pieken in het verkeer. Bescherming op netwerkniveau voor de eigen verbinding van je origin blijft bij je hoster, dus scherm je origin af zodat hij alleen de proxy toelaat.

Richt het in alle rust in en meet het resultaat op je eigen site. Je kunt het uitproberen met een gratis proefperiode van 7 dagen, zonder creditcard. De abonnementen vind je op de prijzenpagina.

Veelgestelde vragen

Hebben kleine websites DDoS-bescherming nodig?

Klein zijn beschermt je niet. Kleine sites gaan al plat bij een bescheiden HTTP-flood, en bij shared hosting kan een aanval op een buursite ook jouw site raken. Kost downtime je bestellingen, leads of reputatie, dan loont het om bescherming vóór je site in te richten.

Zit DDoS-bescherming bij mijn webhosting inbegrepen?

Vaak gedeeltelijk. Veel hosters filteren grote netwerkfloods om hun infrastructuur te beschermen, maar floods op applicatieniveau tegen je site komen meestal gewoon door, en sommige hosters passen null routing toe op een aangevallen IP-adres. Vraag precies welke soorten aanvallen worden afgedekt.

Beschermt een CDN tegen DDoS-aanvallen?

Alleen als het je hele site proxyt en verkeer filtert voordat het je server bereikt. Een asset-CDN op een aparte hostnaam beschermt je pagina's niet, want HTML-verzoeken gaan nog steeds rechtstreeks naar je origin.

Maakt DDoS-bescherming mijn website trager?

Een proxy voegt een tussenstop toe tussen bezoeker en server, maar gecachete pagina's van een edge in de buurt komen vaak juist sneller aan. Het hangt af van je site en je bezoekers, dus maak een voor-en-navergelijking zoals beschreven in onze gids over websitesnelheid meten.