Nederland merkt inmiddels voor de zoveelste week achtereen de impact die DDoS-aanvallen kunnen hebben op de samenleving. Nieuwssites die niet meer te bereiken zijn of een ontregeling van het online betalingsverkeer. De bezorgdheid loopt op tot hoog niveau, wanneer minister Dijsselbloem vaststelt dat de aanval is geslaagd omdat het betalingsverkeer was ontregeld, maar hackers niet in de systemen van banken zijn gekomen.
De genomen maatregelen om DDoS-aanvallen tegen te kunnen gaan hebben niet kunnen verhinderen dat diensten volledig ontoegankelijk waren. Valt er dan niets tegen DDoS te doen? Zeker wel. De aanval zelf stoppen is onmogelijk, wel zijn er maatregelen te nemen die het effect van een DDoS-aanval kunnen beperken.
Verschillende effecten van DDoS
De aard van een DDoS-aanval ligt natuurlijk in het belasten van het netwerk of serverpark van een doelwit, waardoor deze onbereikbaar wordt voor het legitieme verkeer. Een dergelijke aanval wordt met gebruik van botnets direct op het doelwit gericht of indirect via amplitude of reflector methodes, zodat het gewenste DDoS-effect nog sneller wordt bereikt.
Daarnaast zijn er tientallen verschillende vormen van DDoS-aanvallen (bijvoorbeeld SynFlood-attacks, Smurf-attacks, Slowloris-attacks, SSL renegotiating-attacks) en deze worden tegenwoordig vaak tegelijkertijd uitgevoerd. Sommige hiervan richten zich op het belasten van het netwerk, andere zijn bedoeld om de server-resources in beslag te nemen, terwijl weer andere zich op de applicatielaag richten.
De complexiteit van deze aanvallen vraagt om een andere aanpak dan de traditionele netwerkbeveiliging kan bieden.Traditionele netwerkbeveiliging heeft het over firewalls, IPS of IDS en een gelaagd beveiligingsmodel waarin allerlei deeloplossingen gezamenlijk een complex geheel moeten vormen om de effecten van DDoS tegen te kunnen gaan. Deze setup levert eenvoudigweg niet meer de middelen om internetbedreigingen gericht op applicaties tegen te kunnen gaan.
Twee stappen voor betere beveiliging
De eerste stap naar een adequaat model is it-beveiliging inrichten op de te beschermen applicaties. Hiervoor kan worden gekozen voor een application delivery full proxy architectuur die in staat is om een hoog volume aan verkeer af te kunnen handelen en bovendien in staat is om communicatie te stoppen wanneer deze niet van een reguliere gebruiker afkomstig is. Een application delivery full proxy firewall is daarnaast in staat om veel meer capaciteit te bieden als het gaat om het aantal concurrent verbindingen per seconde en heeft 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 het beschermen van applicaties op het juiste niveau. Inderdaad, op applicatieniveau. Hier wordt vaak over het hoofd gezien dat een dns-query de eerste stap is naar het gebruik van de applicatie. We hebben allemaal de recente berichtgeving rondom Spamhaus gezien waarin dns-DDoS werd ingezet om een verschil van mening duidelijk te maken. Het beschermen van dns dient te beginnen met het kunnen distribueren van dns-queries over verschillende datacenters om zodoende het effect per datacenter te beperken. Een protocolfilter kan UDP-verkeer onderscheiden van daadwerkelijk dns-verkeer. En om dns cache poisoning tegen te gaan, moet er in samenwerking met de externe dns-servers on-the-fly DNSsec signing worden uitgevoerd.
Nu we de bereikbaarheid van de applicatie zeker hebben gesteld, wordt het hoog tijd om de applicatie zelf te beschermen door vast te stellen welke requests wel en niet zijn toegestaan, als mede te bepalen wat de server terug mag communiceren naar de gebruiker. Hierdoor kan het lekken van gevoelige data worden tegengegaan. Applicaties worden zodoende beschermd tegen gevolgen van bedreigingen 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 juridische conflicten en wellicht (financiële) penalties tot gevolg. Wellicht het allerbelangrijkste is het geschonden vertrouwen.
Helaas, anno 2013 is beveiliging van een applicatie geen commodity meer die op netwerkniveau generiek kan worden geregeld. Het wordt hoog tijd dat beveiliging begint op applicatieniveau en applicatiespecifiek wordt ontworpen. Hierdoor kunnen aanvallen zoals DDoS beter worden opgevangen en de negatieve effecten gereduceerd. Een application delivery full proxy firewall is hierbij een essentiële bouwsteen in het beschermen van applicaties en data.
DDoS is voor velen een lastig te begrijpen onderdeel, zeker als je ook nog eens naar varianten gaat kijken. Ik heb mijn dochters uitgelegd dat je het mag vergelijken met dat een hele school bij ons thuis aan de voordeur staat aan te bellen. Alle kinderen willen je spreken. Je kent die lui niet en hebt er geen zin in.
Je vrienden staan helemaal achteraan in de rij. Die wil je wel spreken, maar dat lukt dus niet.
Ik weet ik stel het een beetje simpel voor, maar wellicht heeft iemand er iets aan. Of heeft iemand een mooier verhaal?
Kern van het verhaal is dat je er weinig aan kunt doen als de massa zich op je stort. Je zult altijd een mechanisme met voldoende capaciteit in het netwerk moeten hebben om de filtering te doen. En ook dat mechanisme kan onderuit als de aanval groot genoeg is.
Hallo Gert Jan en Luuk,
Goed stukje, geeft toch weer inzicht in wat een DDoS is tot gevolg kan hebben. De parallel met de deur is geen slechte, het helpt om dit soort dingen inzichtelijk te maken voor mensen die er nooit mee te maken hebben.
Het is nu iets wat erg in het nieuws is met betrekking tot banken, maar dit kan net zo goed gebeuren op andere momenten bij stakingen bijvoorbeeld. Als alle boeren met tractor op het Malieveld gaan staan, is het er ook ‘even’ niet bereikbaar. Het is ook het doel, net als bij DDoS.
Zoals in veel gevallen is de exploit er eerder dan de oplossing, maar dat hoeft niet te betekenen dat dit onoplosbaar is. Dat is ook de reden dat sites/applicaties aan onder andere OWASP-tests kunnen worden onderworpen. Daarnaast is het natuurlijk van belang om ervoor te zorgen dat naast de DDoS aanval er geen data op straat ligt. Onbereikbaar is één, maar dat de data dan op straat ligt is nog weer een stap verder.
My 2 cents 😉
De oplossingen die je beschrijft zouden zeker kunnen helpen. Maar een zaligmakende oplossing is inderdaad ook niet.
Hoewel er juridisch wat haken en ogen aan zitten, zou het een oplossing kunnen zijn om een tegenaanval te lanceren. Oftewel: zelf een DDos aanval uitvoeren richting de aanvallende partij. Op die manier kan de aanval zelf afgezwakt worden omdat de lijnen van de aanvallende partij vol lopen.
Op dit moment nog lastig, omdat de aanvallende partij gebruik maakt van een groot netwerk van PC’s van onwetende eigenaren. Maar mogelijk wel een oplossing die overwogen zou kunnen worden. Op die manier kan de verdediging die jij beschrijf de impact van de aanval beperken, en kan de aanval zelf ook ingeperkt worden. Defensieve en offensieve security.
Preventie cq. reactie op een DDoS Attack dient op meerder fronten te gebeuren, dit ben ik het volledig met Gert eens. We hebben er al een mooi nodel voor. Het OSI model dat de Netwerklagen definieert, kan ook prima de beschermingslagen definieren. Als elke laag er voor zorgt dat zijn zaakjes in orde zijn, en tevens de interface naar de hogere (en waar van toepassing de lagere) laag geregeld hebben, is het voor alle partijen makkelijker om de aanval het hoofd te bieden.
Daarnaast is er ook een rol weggelegd voor de grote ISP’s. Enorme hoeveelheden data, ook die van DDoS Attacks, worden via de Amsterdam Internet Exchange gerouteerd. Daar zou je al een deel van de aanvallen kunnen blokkeren, zeker voor systemen van buiten Nederland (in geval van een aanval op nationale infrastructuur)Patroonherkenning in het netwerkverkeer kan je daarbij helpen. Dan iemand in China dan effe niet op Fleurop.nl een bloemetje kan bestellen is dan erg jammer.
Vaak is het ook al een goed plan om bepaalde time-outs op Servers wat kritischer te bekijken. Veel systemen hebben nog bestaande time-outs voor het sluiten van geopende, maar niet actieve poorten, ZOlang diepoort nog open staat, kan een andere sessie deze niet gebruiken. In de huidige wereld van Breedband en Glasvezel is een time-out van 30 seconden tijdens een DDoS Atatck een eeuwigheid. Er is daaarbij wel een verschil tussen Network Timeout en Applicatie Timeout.