Hoe GitHub een DDoS-aanval succesvol afsloeg

Hoe GitHub de gevolgen van een DDoS-aanval succesvol wist te verzachten

GitHub – de populaire hostingservice voor softwareontwikkeling – werd afgelopen februari getroffen door een krachtige DDoS-aanval. Deze Distributed Denial of Service aanval raakte het wereldwijde bestand van 20 miljoen gebruikers, waarbij een piek van 1,3 Tbps in aanvalsverkeer werd gehaald.

Diverse gebruikers, waren bezig met een code-checkin en zochten naar de oorzaak van de problemen, waarbij zij tevens hun bezorgdheid op Twitter uitte met betrekking tot de problemen welke zij ondervonden.

Helaas voor GitHub werd hun statuspagina ook geraakt, waardoor de problemen niet gedeeld konden worden met de gebruikers. Enkele minuten na de aanval traden de DDoS protectie systemen van GitHub in werking, waardoor de impact van de aanval tot een minimum beperkt bleef en de DDoS succesvol geëlimineerd werd.

ThousandEyes analyseerde GitHub’s DDoS-aanval en hoe deze werd opgevangen; Lees er hier alles over.

Update (1 maart 2018): GitHub werd in maart 2018 getroffen door een tweede DDoS-aanval. De beschikbaarheid van de dienst daalde met 61 procent (tweemaal zo ernstig als de vorige aanval), maar alle diensten werden binnen vijftien minuten hersteld. De impact van deze aanval lijkt krachtiger en breder te zijn ten opzichte die van de vorige aanval.

Afbeelding 1: Bezorgde gebruikers van GitHub gebruikten Twitter om hun ervaringen te delen en informatie te vinden.

Eerste tekenen van een aanval

’s Ochtends werden wij vanuit ons platform geattendeerd op een wereldwijde vermindering van de beschikbaarheid van GitHub-services geconstateerd door een paar van onze Cloud Agents. De beschikbaarheid van de HTTP-server voor www.github.com daalde met 26 procent (afbeelding 2), dit voornamelijk als gevolg van verbindingsfouten in de TCP-signaleringsfase. Verbindingsfouten duiden meestal op een dieper probleem in de netwerklaag. Wij konden onze theorie bevestigen door het de toename van z.g.n. packetloss binnen de netwerklaag.

Afbeelding 2: HTTP-beschikbaarheid van GitHub daalde met 26 procent wereldwijd, gecombineerd met een netwerk packetloss van 24 procent.

Het doel van een DDoS-aanval is om een website of dienst dusdanig te bombarderen met ‘’verkeer’’ waardoor de site of de dienst tijdelijk onbereikbaar is. In deze specieke aanval zagen wij met ons platform in sommige netwerkpaden bijna 100 procent packetloss (afbeelding 3), hetgeen sterk wees op een DDoS aanval.

Afbeelding 3: Hoge niveaus van pakketverlies in het netwerk zijn een goede indicator voor beperkte resources als gevolg van een DDoS-aanval.

Prolexic in BGP-pad bevestigt DDoS-aanval

De bevestiging van een aanval werd verder gevalideerd door de BGP-gegevens. ThousandEyes verzamelt meerdere datasets over verschillende netwerklagen, om daarmee de prestaties van de applicatie en de gebruikerservaring te vergelijken met de inconsistenties van het netwerk. Binnen enkele minuten na de aanval constateerden wij dat de Prolexic werd geïntroduceerd in het BGP AS-pad voor bereikbaarheid tot tenminste vijf van de GitHub-prefixes. Afbeelding 4 hieronder is een ruimtelijke weergave van BGP-bereikbaarheid naar GitHub-prefixen vanuit meerdere gezichtspunten, ook bekend als BGP-routemonitors.

100 procent van onze BGP-monitoren observeerden padveranderingen. Vóór de aanval gebruikte GitHub (AS 36459) vier verschillende upstream-ISP's, waaronder Telia, Level 3 en NTT.

Met DDoS-beperking in werking trok GitHub zijn BGP-routes (aangegeven met rode stippellijnen) van zijn primaire ISP's in en vestigde nieuwe BGP-peering met Prolexic (AS 32787).

Prolexic is een dochteronderneming van Akamai en een populair DDoS-mitigatieplatform. Deze verandering in het BGP-pad dwong al het verkeer dat naar GitHub was gestuurd door de beveiliging van Prolexic, dat in staat was de DDoS-aanval te absorberen en af te zwakken. Binnen vijftien minuten werden de GitHub-services hersteld (afbeelding 1), waardoor de impact van de DDoS-aanval tot een minimum werd beperkt.

Afbeelding 4: GitHub (AS 36459) trekt routes van primaire providers en vestigt nieuwe peering met Prolexic (AS 32787), een DDoS-beperkingsplatform.

Een succesvolle en efficiënte DDoS-beperking

GitHub was vrij efficiënt in het afzwakken van de DDoS-aanval. Binnen enkele minuten werd de aanval geïdentificeerd en DDoS-verdedigingsmechanismen ingezet. Gezien de snelheid waarmee de DDoS-mitigatie werd opgezet, is het zeer waarschijnlijk dat het gehele detectie- en beperkingsproces geautomatiseerd was (hetgeen behoorlijk indrukwekkend is, moet ik zeggen!). Hoewel de impact van de aanval niet langer dan vijftien minuten duurde, bleef verkeer bestemd voor GitHub door de Prolexic-beveiliging gestuurd tot zes uur na de aanval. De twee pieken in het BGP-pad in de tijdlijn hieronder (afbeelding 5) vertegenwoordigen het verschil in tijdstip waarop Prolexic werd geïntroduceerd in het AS-pad en vervolgens werd verwijderd.

Afbeelding 5: Verkeer bestemd voor GitHub werd tot zes uur na de DDoS-aanval verzonden naar Prolexic-beveiliging.

Twee aanvallen in twee dagen

De eerste aanval was uitzonderlijk in de geschiedenis van DDoS-aanvallen. Met 1,3 Tbps aan aanvalsverkeer was dit de krachtigste DDoS-aanval die ooit werd geregistreerd. Binnen 24 uur werd GitHub echter getroffen door een tweede aanval. Deze leek heftiger qua impact. GitHub's beschikbaarheid daalde met 61 procent, vergeleken met 26 procent tijdens de eerste aanval.

In afbeelding 6 en afbeelding 7 vergelijken wij de twee DDoS-aanvallen vanuit het perspectief van beschikbaarheid van services en globale scope. Net als tijdens de eerste aanval reageerde de Prolexic heel snel om de gevolgen van de aanval te minimaliseren.

Afbeelding 6: 28 februari 2018, DDoS-aanval op GitHub. Beschikbaarheid daalde met 26 procent.
Afbeelding 7: 1 maart 2018 DDoS-aanval op GitHub. Beschikbaarheid daalde met 61 procent. En de impact lijkt veel breder in vergelijking met de eerste aanval.

DDoS-mitigatie monitoren

DDoS-aanvallen worden steeds frequenter en ook steeds krachtiger. Hoewel de GitHub-aanval tot een minimale onderbreking van de service leidde en een goed uitgevoerd mitigatieproces liet zien, worden niet alle DDoS-aanvallen op dezelfde manier gemaakt. Het is altijd handig om een beeld te krijgen, van hoe uw mitigatieservice werkt en hoe uw gebruikerservaring wordt bedreigd. Zonder inzicht in al uw serviceafhankelijkheden, kunt u uw online bedrijf niet effectief beheren. Wilt u dit type netwerkintelligentie zelf ervaren? Vraag dan een demo aan of start een gratis proefversie van ThousandEyes.