Technische analyse DDoS aanval

Tussen vrijdag 1 februari en maandag 4 februari detecteerden we zeven DDoS aanvallen op ons netwerk. In deze post beschrijf ik de analyse en tegenmaatregelen die we met de techniek afdeling van Byte hebben genomen.

Hoe werkt een DDoS?

De meeste denial of service (DoS) aanvallen zijn erop gericht om bronnen van een systeem of dienst uit te putten, bijvoorbeeld door een groot aantal transacties te starten. De amplitude van de aanval wordt versterkt door meerdere systemen in te zetten, een zogenaamde distributed DoS. Daarnaast is het bij een DDoS lastiger om malafide verzoeken te herkennen en te scheiden van legitieme verzoeken.

Er zijn in de praktijk drie methoden om DDoS tegen te gaan:

1. Het malafide verkeer filteren
2. Capaciteit van de dienst in kwestie vergroten
3. De target continue verhuizen om de aanvaller uit te putten

Wat zagen we gebeuren?

Zie ook de grafiek bovenaan. De aanvaller stuurde in eerste instantie grote hoeveelheden TCP SYN packets naar het primaire IP van cluster 1, met een snelheid van 120K tot 200K packets per seconde (pps). Onze loadbalancers bleken hieronder te bezwijken. Toen we dat hadden opgelost, werden de aanvallen gestuurd op het IP van www.hypernode.nl. Dat konden we relatief snel isoleren. De aanvaller stapte tenslotte over op een UDP flood, dat sowieso geblokkeerd wordt aan de rand van ons netwerk. Daarmee leken de malafide initiatieven voorlopig tot een einde gekomen en konden we even rustig ademhalen.

Welke acties hebben we ondernomen?

Eerste symptoom van de aanval was slechte performance van ons netwerk. Normaal grijpen we naar onze Network Weather Map (grafische weergave van alle backbone links van ons netwerk, zie rechts) om de bottleneck te bepalen. Daarop zagen we echter geen uitzonderlijke patronen. Nummer twee in onze gereedschapskist is Observium (gedetailleerde grafieken van het type verkeer) en daarmee konden we vaststellen dat er een piek was op het aantal binnenkomende TCP packets. Deze packets waren enkel 40 bytes per stuk, samen slechts 30 mbps, een fractie van ons normale verkeer. Niet het volume in bytes, maar enkel het aantal packets was dus genoeg om een van onze loadbalancers op zijn knietjes te krijgen.

Volgende stap was het analyseren van de flood, op zoek naar een bron of patroon. Dit bleek lastig, want de loadbalancer in kwestie was niet meer bereikbaar. Het hoge aantal interrupts had er blijkbaar ook voor gezorgd dat IPMI (onze out of band interface) niet meer functioneerde. Er was reeds een collega onderweg naar het datacentrum om daar kabels te prikken en op de console mee te kunnen kijken. Daarop zijn we naar de secundaire loadbalancer geswitched en zaten we klaar om samples van de binnenkomende verkeersstromen te nemen. Voorzichtigheid is geboden, want het samplen van verkeer kost ook servercapaciteit. Teveel samplen zou de machine direct laten crashen. Het volgende tcpdump commando bood soelaas om 500 packets op te slaan voor latere analyse.

tcpdump -ni bond1 -c 500 -w pcap-`date "+%Y%m%d%H%M"`

Dit bestand konden we afspelen met tcpdump -r of met wireshark en leverde een lijst van SYN packets op van verschillende afzenders. Op deze afzenderlijst programmeerden we snel twee checks: is het IP bereikbaar (geen enkele) en uit welk land komt het vandaan (de hele wereld). Dit deed vermoeden dat het om gespoofde packets ging. Dat is vreemd, want eerdere SYN floods met gespoofde packets konden we eenvoudig afwimpelen met Syn Cookies.

Op dit moment splitsten we ons team, om de volgende doelen te bereiken:

1. Team Capacity, om te kijken waar de bottleneck op ons platform zat en hoe we deze zouden kunnen vergroten
2. Team Evasion, om te impact van de aanval te verkleinen

Team Capacity

Het was duidelijk dat de bottleneck zich ergens op de IPVS loadbalancer bevond. Verschillende netwerkleveranciers (oa. Falco Networks en Quanza) werden ingeschakeld in de zoektocht naar dedicated hardware die onze capaciteit zou kunnen vergroten. Deze apparatuur (oa. van Juniper en Riorey) bleek echter niet tijdig voorhanden of was erg risicovol om te zetten (ivm complexiteit van het netwerk). We wilden dus eerst verder speuren naar manieren om de capaciteit van ons bestaande platform te vergroten.

Onze broadcom gigabit netwerkkaarten zouden in productieopstellingen 500K pps aan moeten kunnen. De huidige 200K pps is dus – in theorie – een eitje. Wat zat er dan mis? De load schoot omhoog, de kworker en ksoftirqd processen snoepten een hele core (van de acht) op. Eerste poging was om de netwerk interrupts beter te verdelen over de verschillende cpu’s met behulp van irqbalancer. Dat hielp een beetje, maar niet voldoende. Als tweede maatregel wilden we RX polling invoeren om te besparen op het aantal interrupts. In de tussentijd vonden we echter uit dat hoog CPU gebruik door ksoftirqd ook kan wijzen op een drukke kernel, bijvoorbeeld door NAT, connection tracking en iptables regels (en daar hebben we er veel van). Ondertussen hadden we de testsetup klaar, op basis van een identieke loadbalancer en een aantal servers dat gezamenlijk een DDoS aanval kon simuleren. Hiermee konden we snel onze iptables ruleset optimaliseren. Met name de u32 module bleek een enorme efficiency winst op te leveren. Met een aantal u32 bitmasks aan het begin van onze iptables chain konden we de meeste packets efficiënt afhandelen. Daarmee schroefden we pps capaciteit van onze loadbalancers voldoende op om de lopende aanvallen zonder vertragingen te doorstaan. Hoera!

Twee collega’s waren ondertussen gestart met het bouwen van een dedicated systeem waarop we het aangevallen IP zouden kunnen isoleren. Dit systeem gebruikte Intel e1000 netwerk kaarten (die in theorie 1000K pps zouden moeten kunnen verwerken) en werd ingericht als bridge/filter. Doordat het systeem geen andere taak had dan het filteren van malafide verkeer (en het doorsturen van legitiem verkeer) zou het een nog grotere verwerkingscapaciteit hebben. Deze superbridge staat inmiddels klaar om te worden ingezet voor een eventuele volgende aanval.

Team Evasion

Doel: zorgen dat zoveel mogelijk sites, zo snel mogelijk weer online zijn. De DDoS aanvallen waren gericht op een IP waar meerdere sites van onze klanten aan zijn gekoppeld. We konden niet zien tegen welke site, enkel het (gedeelde) IP. Waarom niet dit IP nullrouten (zodat alle verkeer op routing niveau wordt weggekieperd) en alle diensten (via de DNS) verhuizen naar een nieuw IP? Deze techniek wordt meestal toegepast wanneer grote sites (CNN, banken) worden aangevallen. Twee nadelen:

1. Als de aanval wordt uitgevoerd op basis van DNS naam, verhuist de aanval gewoon mee.
2. Wij hebben niet voor alle sites controle over de DNS (omdat de domeinnaam elders geregistreerd is) dus een deel (5%) zouden we niet kunnen “redden”.

Mocht de aanval meeverhuizen, dan zouden we te werk gaan volgens de “verdeel en heers” methode: telkens de helft van de sites verhuizen naar een nieuw IP, net zo lang tot we hadden gededuceerd op welke specifieke site de aanval gericht was. Dit bleek gelukkig niet nodig. Omdat we DNS in een MySQL db beheren (PowerDNS) en we een lage TTL hanteren (juist voor dit soort situaties) konden we met 1 query alle sites verhuizen naar een nieuw veilig onderkomen. De aanval bleek gelukkig gehandhaafd op het oude IP en daarmee hadden we 95% van de sites van cluster 1 veilig gesteld.

Een tweede maatregel die in overweging werd genomen, is het bouwen van een knop waarmee we in één keer al het verkeer uit het buitenland kunnen blokkeren. Mochten de andere oplossingsroutes niet tot voldoende resultaat leiden, dan zouden we hiermee in ieder geval het verkeer uit Nederland en Belgie veilig kunnen stellen (zo’n 90% van het “normale” verkeer). Deze maatregel is natuurlijk verre van optimaal. Gelukkig hebben we hem niet nodig gehad.

Conclusie

DDoS aanvallen zijn lastig te bestrijden. Om de succeskansen te vergroten hebben we verschillende parallelle oplossingsroutes ingezet om a) de capaciteit te vergroten, b) sites snel te verhuizen c) slim te filteren op malafide verkeer. Dit heeft uiteindelijk geleid tot een afdoende oplossing (en flink wat slaapgebrek ;-))

Wat kunnen we verder nog verbeteren?

1. Traffic analyse volgens het Netflow protocol (dedicated monitoring servers die rechstreeks aan onze routers gekoppeld zijn) zodat we op meta niveau kunnen meekijken met verkeersstromen. Dan zijn we niet meer afhankelijk van een toch al drukke machine voor de analyse. Dit hebben we gisteren en vandaag uitgerold.
2. Met de tweaks in de network stack hebben we de pps capaciteit van de loadbalancers flink verhoogd. Om toekomstige grotere DDoS aanvallen te kunnen doorstaan, speuren we verder naar mogelijkheden om nog meer pps af te kunnen handelen. Naast onderzoek naar dedicated anti-DDoS systemen, doen we onderzoek naar slimmere netwerk componenten, zoals de intel e1000 netwerkkaarten. Hoe meer pps we kunnen verwerken, hoe groter de aanvallen die we succesvol af kunnen slaan.
3. We verbeteren onze tools, zodat we bij aanvallen nog sneller sites kunnen verhuizen naar reserve IPs. We sturen al maandelijkse mailings naar onze klanten over het risico van externe DNS, daar zullen we deze case nog extra onder de aandacht brengen.

[widget id=”magereport_widget-4″ /]