DDoS-aanvallen vragen om andere beveiligingsstrategie

Nederland ligt onder vuur in de vorm van DDoS-aanvallen. Een term die inmiddels ook niet IT-mensen gebruiken alsof het de gewoonste zaak van de wereld is. Helaas is dat het ook, maar is het aantal slachtoffers de laatste tijd wel erg groot. Hoe voorkomen we dit in de toekomst?

Waarschijnlijk zijn DDoS-aanvallen niet te voorkomen, maar we kunnen wel twee stappen zetten die het effect beperken.
Dé DDoS-aanval bestaat niet; er zijn vele verschillende varianten (bijvoorbeeld SynFlood attacks, Smurf attacks, Slowloris attacks, SSL renegotiating attacks). De een zorgt voor een overbelasting van een netwerk, de ander richt zich op server-resources terwijl een derde de applicaties dwarsboomt. De complexiteit van deze aanvallen vraagt om een andere aanpak dan de traditionele netwerkbeveiliging kan bieden. Volgens die methode bouw je beveiliging op als gelaagd beveiligingsmodel, met firewalls, IPS of IDS en allerlei deeloplossingen. Dit is voor nu niet voldoende meer om appliacties te beschermen.
De IT-beveiliging moet ten eerste ingericht worden rondom de te beschermen applicaties, bijvoorbeeld middels een Application Delivery full proxy architectuur die een hoog volume aan verkeer kan afhandelen en bovendien in staat is om ongewenste communicatie te stoppen. Ook kun je dan meer concurrent verbindingen per seconde verwerken, en krijg je inzicht in zowel netwerk- als applicatieverkeer. Zelfs is het mogelijk om DDoS-aanvallen die plaatsvinden in encrypted SSL-verkeer tegen te gaan. Dit is juist de bottleneck bij traditionele firewall-oplossingen en de reden waarom sites volledig onbereikbaar raken.
De tweede stap is de beveiliging op applicatieniveau. Een DNS-query is de eerste stap naar het gebruik van de applicatie. Om DNS-bescherming door te voeren, moeten deze DNS-queries over verschillende datacenters gedistribueerd worden om de gevolgen van een aanval te beperken. Een protocolfilter kan UDP-verkeer onderscheiden van daadwerkelijk DNS-verkeer.
Op die manier vergroot je de bereikbaarheid van de applicatie, maar bescherm je de applicatie zelf nog niet. Hiervoor moet je vaststellen welke requests wel en niet zijn toegestaan en je moet bepalen wat de server terug mag communiceren naar de gebruiker. Dit biedt bescherming tegen de gevolgen van andere narigheid als SQL injectie, cross site scripting en cross site request forgery. Juist deze bedreigingen zorgen ervoor dat bijvoorbeeld gegevens uit een organisatiedatabase worden gelekt en op straat komen te liggen, met alle financiele en zakelijke ellende tot gevolg.
Beveiliging op netwerkniveau is niet meer voldoende tegenwoordig. We moeten applicatiespecifiek te werk gaan en op dat niveau werken. Hiermee voorkom je niet dat je aangevallen wordt, maar de negatieve effecten zullen aanzienlijk minder zijn.

Een versie van dit artikel verscheen eerder op Computerworld.nl op 25 April 2013.