DDoS: nucleus ddos ebook

Er bestaat niet zoiets als dé DDoS-aanval. Aanvallen zijn er in allerlei soorten en maten. In deze blogpost bespreken we de aanvallen op de server. In een eerdere blogpost hadden we het al over de netwerkaanval, in latere blogposts volgt meer uitleg over aanvallen op applicaties en SSL-protocollen.

DDoS aanvallen gericht op de server

Serveraanvallen verschillen van netwerkaanvallen: ze hebben vaak minder volume nodig en daardoor is het eenvoudiger om ze onder de radar te houden.

Waar het bij netwerkaanvallen de bedoeling is om de ‘snelweg’ te verzadigen, is dit soort aanvallen erop gericht om het slachtoffer zelf te overbelasten. Je geeft een server zoveel werk dat hij niet meer op alle (legitieme) aanvragen kan antwoorden.

Het slachtoffer bij dit soort aanvallen is vaak een webserver, maar het kan evengoed een firewall of eender welke applicatieserver zijn.

Om een vergelijking te geven: je bouwt een parkeergarage voor 100 gasten, maar iemand verstuurt 1.000 parkeertickets in jouw naam. Die mensen duiken achteraf allemaal op om een gratis parkeerplaats te claimen. Pech dus voor je 100 legitieme gasten, want zelfs al zien jouw parkeerwachters het verschil tussen een echte uitnodiging en een valse, ze zijn toch een pak tijd kwijt en hebben handen te kort om alles te controleren.

Een serveraanval maakt vaak misbruik van zwakheden die in het TCP/IP protocol zitten. Het gaat hier om de zes ‘vlaggen’ (flags) van het TCP protocol: SYN, ACK, RST, PSH, FIN en URG.

TCP SYN Flood

Een TCP SYN aanval of kortweg SYN flood maakt misbruik van de drievoudige handshake. Die gaat als volgt: eerst gaat er een aanvraag uit door middel van een SYN pakket. Vervolgens moet er een vraag voor bevestiging komen (SYN-ACK) en tenslotte de bevestiging zelf (ACK).

Een SYN flood zorgt ervoor dat een botnet SYN requests stuurt naar de server die het doelwit is van de aanval. Deze SYN-pakketten maken al dan niet gebruik van een spoof IP-adres.

De server opent dus een connectie, wijst daar buffers en resources aan toe en zendt vervolgens een SYN-ACK-pakket terug naar de aanvrager. Maar die geeft geen ACK-bevestiging. De server wacht een tijdje op het antwoord en zal nog een aantal keren proberen een SYN-ACK te sturen voor er een time-out optreedt en de server de connectie opgeeft. Als de aanvaller dit met voldoende computers en connecties doet, zal de server geen vrije resources meer over hebben en legitieme connecties afblokken.

TCP RST aanval

TCP RST is een reset-commando. Het geeft de ontvanger de opdracht de lopende connectie tussen zichzelf en de ontvanger onmiddellijk te resetten. Een TCP RST aanval gebeurt ook via een botnet dat RST-commando’s zendt met spoof IP adressen (in dit geval de IP-adressen van legitieme gebruikers wiens computer besmet is en onwetend deel uitmaken van een botnet). Het RST-commando moet normaliter een correct sequentienummer gebruiken, maar door de hoeveelheid vragen die een botnet kan verzenden, vinden ze altijd wel per toeval het juiste nummer. Daardoor reset de host de connectie en kan er dus geen legitieme data meer verzonden worden.

TCP PSH+ACK aanval

TCP gebruikt de PUSH-vlag om de zender de opdracht te geven alle data meteen te pushen en te verzenden, gevolgd door een ACK-bevestiging. Dit zorgt ervoor dat de verzender zijn TCP-buffer leegmaakt en alles verstuurt. De aanvaller gebruikt een botnet en veroorzaakt veel PSH-aanvragen om ervoor te zorgen dat de TCP-stack van de aangevallen server het begeeft.

Low & slow aanval

In tegenstelling tot flood-aanvallen, gaan deze aanvallen eerder uit van heel kleine hoeveelheden data, die gebruikt worden om een server bezig te houden. Op deze manier proberen aanvallers minder op te vallen omdat ze ervoor zorgen dat er wel degelijk data wordt verzonden maar heel traag.

Sockstress is de meest gekende variant van low en slow attacks. Bij zo’n aanval zet de aanvaller een connectie op en bij het verzenden van de ACK geeft hij ook een window 0-instructie mee. Die geeft aan de andere partij aan hoeveel plaats er nog is om data te ontvangen in de TCP-buffer. Als die op 0 staat, zegt de client tegen de server dus om te wachten met zenden, maar de connectie blijft open. De server blijft regelmatig vragen om een nieuwe window, maar als het antwoord 0 blijft, blijft de connectie open en neemt het dus de plaats in van een legitieme connectie. Met beperkte trafiek kan een aanvaller op die manier alle vrije connecties innemen van een server en ervoor zorgen dat niemand anders de server nog kan bereiken.

Omdat er naar dit gedrag gescand kan worden, worden er ook andere waardes gebruikt voor de window-instructie. 8 bijvoorbeeld, waardoor alle data die verzonden wordt, opgedeeld wordt in stukjes van 8 bytes. Op die manier blijven de connecties wel degelijk data versturen, maar zo traag dat de server uiteindelijk crasht door overbelasting.

###

Deze blogpost maakt deel uit van een reeks blogposts over DDos en hoe je ertegen te beschermen. Lees ook onze andere blogposts:

 

  1. Waarom een DDos-aanval geen hacking is…
  2. Het economisch model achter een DDoS-aanval
  3. De belangrijkste kenmerken van een DDoS-aanval
  4. De geschiedenis van DDoS-aanvallen
  5. Soorten DDoS-aanvallen: de netwerk-aanval
  6. Soorten DDoS-aanvallen: de applicatie-aanval
  7. Soorten DDoS-aanvallen: de SSL-aanval
  8. Wat zijn botnets en hoe werken ze?
  9. Hoe bescherm je jezelf tegen DDoS-aanvallen?
  10. Hoe kies je de geschikte DDoS-beveiling?
  11. Checklist: Word jij slachtoffer van een DDoS-aanval?

 

Al deze blogposts zijn verzameld in een eBook dat gratis te downloaden is. Bovendien vind je ook een checklist zodat je kan nagaan hoe groot de kans is dat je slachtoffer wordt van een DDoS-aanval en hoe het met je bescherming gesteld is. Download hier het ebook.
 

Gerelateerde berichten
Problemen oplossen in Varnish

Problemen oplossen in Varnish

In onze laatste ChalkTalk video uit de reeks bekijken we “ Problemen oplossen in Varnish ”. Hoe weet je of een pagina juist gecached wordt of niet? Wat zijn de meest voorkomende problemen na een implementatie van Varnish? En hoe los je die problemen op?

Lees meer

Netneutraliteit

Waarom onze overheid netneutraliteit moet garanderen

Een recent artikel van freelance journalist Jan Jacobs over netneutraliteit op Doorbraak.be deed ons steigeren. Zo erg zelfs dat we ons bijna afvragen op hij betaald werd door Proximus of Telenet om zo’n stuk neer te poten.

Lees meer

Meet the Hackers

Meet the hackers: drie visies op IT security

Better safe than sorry. Dat was de boodschap achter Meet the hackers, onze workshop rond ethical hacking. In het gezellig kader van de schuur […]

Lees meer