Gisteren (dinsdag 17 februari) hadden we een vervelende DDoS aanval op de server ams117. In plaats van een standaard ‘botte’ aanval, werden we geconfronteerd met een heel gericht scenario waar onze standaard beveiliging niet direct een antwoord op had.

Inmiddels is alles weer terug naar normaal, en is de server weer volledig operationeel. We bieden onze excuses aan voor de eventuele overlast die je van dit incident hebt ervaren.

Ik wil jullie graag meenemen in wat er precies gebeurde, hoe we het hebben opgelost en wat we ervan hebben geleerd om dit een volgende keer te voorkomen.

Waarom de aanval niet snel geblokkeerd kon worden

Normaal gesproken vangt onze netwerkbeveiliging grote pieken in verkeer direct op die normaal voorkomen bij een DDoS aanval. Deze aanval was gewoon heel slim gedaan, door telkens gebruik te maken van andere IP adressen. Hij was klein genoeg om niet weggefilterd te worden door de netwerkbeveiliging, en groot genoeg om de server op z’n knieën te krijgen.

De aanvallers gebruikten een enorme poule aan IP-adressen (uiteindelijk hebben we er 5500 moeten blokkeren). Ze lieten telkens maar een handjevol IP’s tegelijkertijd verbinding maken. Zodra we die blokkeerden, schakelden de aanvallers direct over naar de volgende set. Omdat de IP-adressen uit alle hoeken van de wereld kwamen en nog niet op zwarte lijsten stonden, konden we niet simpelweg een heel land of een bekend botnet blokkeren.

Dit is erg opvallend; aangezien IPv4 adressen relatief schaars zijn. Dit geeft ook aan dat het voor de aanvallers een dure aanval geweest moet zijn.

Uitputtingsslag van IPv4

De aanval richtte zich op het bezet houden van de netwerkinterface van de server. Per seconde kwamen er talloze requests binnen die de verbinding ‘open’ lieten staan. Hierdoor raakte de capaciteit voor nieuwe IPv4-verbindingen simpelweg op; de server zat qua verbindingen ‘vol’, waardoor legitieme bezoekers er niet meer doorheen kwamen.

Naast IPv4, waren de aanvallers ons ook aan het bestoken vanaf IPv6 adressen. Omdat daar bijna oneindig veel IP-adressen beschikbaar zijn, was handmatig blokkeren onbegonnen werk. We hebben daarom besloten om IPv6 tijdelijk volledig uit te schakelen om de rust te herstellen.

Hoe we het hebben opgelost

Om de boel weer online te krijgen, hebben we een paar noodzakelijke stappen ondernomen;

1. Blokkades: We hebben alle IPv4-adressen die die dag de specifieke aangevallen site bezochten geblokkeerd. Uiteindelijk waren dat ongeveer 5500 unieke IP adressen.
2. Server-tweaks: We hebben de serverinstellingen aangepast zodat er meer gelijktijdige connecties open mogen staan en ‘hangende’ verbindingen veel sneller worden verbroken.
3. Domein-isolatie: Het doelwit van de aanval is tijdelijk van de server verwijderd. Zelfs daarna bleven de aanvallers het directe IP-adres van de server bestoken (ze kwamen toen uit op een ‘account bestaat niet’ pagina), maar de druk op de webserver en PHP nam hierdoor gelukkig wel af. Inmiddels is het domein via CloudFlare weer online gebracht.

Hoe nu verder?

Dit incident laat zien dat we ons beter moeten en kunnen voorbereiden op zulke kleine maar gerichte aanvallen. We gaan dit incident verder intern evalueren, en alle ‘lessons learned’ op een rijtje zetten zodat we een volgende keer sneller en effectiever kunnen handelen.

Naast een snellere reactie om van een aanval te herstellen, willen we het liefst zulke situaties voortaan kunnen voorkomen. Ook daar gaan we mee aan de slag om maatregelen te bedenken en implementeren. Hierbij kun je denken aan:

• Het op bredere schaal inzetten van een CDN-netwerk, waarmee kwaadaardig verkeer “on the edge” kan worden geblokkeerd.
• Monitoring op domeinnamen die ineens veel requests in korte tijd krijgen, zodat we snel en gericht actie kunnen ondernemen nog voordat een DDoS-aanval begint.
• Een soort ‘under attack’ modus, waarbij we snel bepaalde configuratie aanpassingen kunnen doorvoeren op serverniveau om normaal verkeer zo veel mogelijk de ruimte geven.