Eenvoudige DDoS Bescherming voor je Extern Gehoste Website
Een van de grootste ongemakken waarmee websites te maken krijgen, zijn Distributed Denial-of-Service (DDoS)aanvallen. Dit zijn aanvallen waarbij een overweldigende hoeveelheid verkeer naar een website wordt gestuurd met als doel de service onbereikbaar te maken, wat kan leiden tot financiële en imagoschade. Binnen het SURF-netwerk biedt SURFcert geavanceerde DDoS-bescherming, die netwerkverkeer analyseert en verdachte patronen identificeert en aanpakt. Hierdoor wordt een stabiele werking van de aangesloten diensten gewaarborgd.
Echter, veel instellingen hebben voor hun primaire website uitbesteed aan een externe leverancier, die meteen ook de hosting doet. Daardoor vallen juist deze high profile doelwitten buiten de directe bescherming van SURF. Leveranciers brengen zelf vaak extra kosten in rekening voor DDoS-bescherming. Ook voor www.surf.nl was dit het geval, en daar hebben we toen wat op bedacht. In dit artikel leggen we uit hoe je externe gehoste websites effectief en gratis* kunt beschermen tegen DDoS-aanvallen, gebruikmakend van de tooling en kennis van SURF.
Stap 1: Installatie van een Reverse Proxy
De eerste stap in deze aanpak is het configureren van een reverse proxy. Dit is als het hebben van een deur met een uitsmijter voor je website. We raden populaire open-source opties zoals NGINX of Apache aan vanwege hun bewezen betrouwbaarheid en veelzijdigheid in het omgaan met websiteverkeer. De truc is om de proxy op een server bínnen het SURF-netwerk te plaatsen. Deze proxy fungeert als een stap tussen de website bij de externe hostingprovider en bezoekers. De capaciteit van deze server is afhankelijk van de hoeveelheid verkeer naar je website, maar gezien het alleen maar doorstuurt gaat het hier niet om een hele grote schaal. Licht wel je leverancier in dat je dit gaat doen, omdat ze veel verkeer vanuit één proxyserver natuurlijk juist als DoS-aanval kunnen zien. Ook is het goed om even te controleren of je DDoS-bescherming aan hebt staan in het SURF netwerkdashboard.
Stap 2: Doorverwijzing
De reverse proxy stuurt al het verkeer door naar je leverancier, zowel via IPv4 als IPv6**. Het slimme deel is dat het IP-adres van je leverancier alleen bekend is bij de proxy, niet in de openbare DNS-instellingen. Dit betekent dat je daadwerkelijke website niet snel het doelwit zal worden van een DDoS-aanval, omdat aanvallers het IP-adres van de leverancier niet direct bereiken. Een eventuele aanval neemt dus de proxyserver als doelwit, die veilig binnen het SURF netwerk staat.
Hieronder vind je een standaardconfiguratievoorbeeld voor NGINX. Pas dit aan naar de specificaties van je website en leverancier. Als je meerdere (sub)domeinen hebt kan je dit herhalen voor elk (sub)domein:
server {
listen 443 ssl http2;
server_name jouwwebsite.nl www.jouwwebsite.nl;
location / {
proxy_pass https://domein-of-ip-van-leverancier;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Host $host;
}
}
Stap 3: TLS/SSL
Vervolgens installeer je op de proxy een TLS/SSL certificaat voor je website, bijvoorbeeld via SURFcertificaten. Met een tool als certbot kan je dit makkelijk automatiseren door via ACME certificaten aan te vragen en te hernieuwen. De eindgebruiker heeft nu een versleutelde en geverifieerde verbinding met de proxy, die op zijn beurt weer verbindt met de ‘echte’ website. De bezoeker van je website ziet verder niks anders. Hieronder geven we een voorbeeld, maar het is beter om de laatste aanbevolen configuratie zelf op te zoeken, bijvoorbeeld op https://ssl-config.mozilla.org/. De SSL-configuratie bestaat uit een paar extra regels die je toevoegt onder server:
ssl_certificate /pad/naar/certificaat_met_intermediates.pem;
ssl_certificate_key /pad/naar/privésleutel.key;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ecdh_curve secp521r1:secp384r1:sect283k1:sect283r1:sect409k1:sect409r1:sect571k1:sect571r1;
ssl_ciphers 'ECDHE:!CAMELLIA:!AES128:!SHA1:!SHA256:!SHA384’;
ssl_prefer_server_ciphers on;
ssl_stapling on;
ssl_stapling_verify on;
server_tokens off;
Stap 4: Hardening
Nog een groot voordeel van een eigen proxy is dat je voor het afdwingen van essentiële beveiligingsmaatregelen niet afhankelijk bent van de leverancier van je website. Om het ‘af’ te maken neem je dus nog enkele beveiligingsmaatregelen, zoals het toevoegen van de aanbevolen security headers, het configureren van HSTS, en het doorsturen van onversleuteld HTTP-verkeer naar HTTPS of SSL afdwingen tussen de proxy en de website met proxy_ssl_verify. Afhankelijk van je risicoafwegingen kan je zelfs TLSv1.3 afdwingen voor perfect forward secrecy. We geven daar expres geen voorbeeld van omdat de gelinkte bronnen, voornamelijk Mozilla's SSL Configuration Generator, het duidelijker uitleggen, en je dit soort configuratie niet klakkeloos moet overnemen van een willekeurige SURF-pagina 😉 . Over het veilig configureren van TLS en HSTS schreven we eerder ook een uitgebreide handleiding 'Beveilig digitale communicatie met TLS'.
Het beschermen van je externe gehoste website tegen DDoS-aanvallen hoeft geen extra geld te kosten, en met een simpele reverse proxy maak je ook voor je extern gehoste websites gebruik van de DDoS-beveiliging van SURF en voldoe je tegelijkertijd aan de laatste beveiligingsstandaarden. Heb je nog vragen? Stuur ons een berichtje op sec@surf.nl.
*natuurlijk gaat alleen de zon voor niks op, maar DDoS-bescherming is wel een standaard-onderdeel van de dienstverlening van SURF, dus je betaalt er niet extra voor.
**bijkomend voordeel is dat als de leverancier andere problemen heeft op IPv4 of IPv6, je website via de proxy gewoon op beide bereikbaar blijft. Dit is bij SURF een keer voorgekomen: de leverancier had IPv4 uitgezet, maar door onze proxy bleef de website gewoon voor iedereen bereikbaar.
Tekst: Joost Gadellaa, technisch productmanager Security Techniek
