Wat veroorzaakte de downtime bij Facebook, Slack en Twitch?

De afgelopen weken zijn zwaar geweest voor enkele van de grootste communicatieplatformen in onze digitale wereld. Op 30 September kampte communicatieplatform Slack met een storing. Een paar dagen later stond gigant Facebook met al zijn diensten lange tijd op zwart. Het rijtje sluiten we, voorlopig, af met een datalek van meer dan 100 gigabyte bij streaming site Twitch.

Shit happens. Klinkt raar, niet? De realiteit is spijtig genoeg wel zo. Ooit loopt het wel eens fout. Het maakt soms niet uit hoe groot of klein je applicatie is, of hoeveel geld je extra in redundantie steekt. Af en toe kan een heel kleine aanpassing simpelweg grote gevolgen hebben.

Is het dan allemaal zo hopeloos? Nee, er zijn wel enkele lessen die je als onderneming kan trekken uit de fouten van anderen. Laat ons afgelopen weken even stap voor stap doorlopen.

DNS, languit Domain Name System, is een van de belangrijkste protocollen van het internet. Het werkt zoals een telefoonboek. Je kent een naam, bijvoorbeeld slack.com, en DNS zal je laptop vertellen met welk IP-adres, een soort telefoonnummer, je moet verbinden. Nadat je dit IP hebt, kan je praten met de servers bij Slack en is de DNS niet meer relevant tijdens de verbinding.

Bij Slack hadden ze een plan, een plan om hun DNS-zones veiliger te maken: DNSSEC. De introductie van DNSSEC op je domain gaat de zone met het zogenaamde telefoonboek cryptografisch ondertekenen. Indien de DNS-server een antwoord naar de eindgebruiker stuurt, kan die valideren of het antwoord dat hij ontvangen heeft onderweg niet is aangepast. Dit is iets wat bij een MITM (Man In The Middle) aanval nogal eens gebeurt om credentials te onderscheppen. 

Het idee was goed, maar toch liep de uitvoering fout. Na enkele kleine problemen heeft Slack waarschijnlijk in een paniekreactie de ondertekende zone weggegooid. Gevolg? Een onoplosbare situatie. Hoezo? Wel, binnen de DNS-architectuur van het internet praat je nooit onmiddellijk met de DNS-server van Slack. Je communiceert met eentje van je service provider of een interne resolver binnen je werkgever. 

Door de paniekreactie is net datgene gebeurd wat ze wilden voorkomen met het ondertekenen van de zones: ieder van deze resolvers en hun clients verwachtten op dat moment een cryptografische validatie die er niet was. Voor hen maakte het dus geen verschil of deze antwoorden van een kwaadaardige server kwamen of van slack zelf. Alle antwoorden verdwenen als foutief in de prullenbak en de applicatie lag op zijn gat. 

Waarom zo lang? Iedere DNS-zone heeft een time to live (TTL). De resolver zal deze zone bijhouden tot de time to live tijd verstreken is. Een standaard keuze hier is 8h tot 24h, wat heel lang is voor een kleine fout.

Een paar dagen later is het dan de beurt aan Facebook samen met al hun andere diensten zoals Whatsapp, Instagram en Messenger. 

Ook hier speelde DNS een rol. De oorzaak van de outage begon bij BGP. Dit is zowat de GPS van het internet, meer info lees je hier.

Een routing aanpassing binnen BGP haalde Facebook zijn DNS platform onderuit. Een internetbedrijf van deze grootteorde heeft zijn zaakjes uiteraard goed op orde. Met anycast stuurt Facebook het verkeer naar verschillende redundante locaties. Zo blijven de performantie alsook de beschikbaarheid gewaarborgd.

Tot die ene dag, door een ongelukkige fout, de GPS stopt met werken en heel het DNS-platform onbeschikbaar is. Ze kunnen niet meer antwoorden op eender welke aanvraag van buitenaf. De gevolgen zijn niet te overzien, een enorme cascade van problemen. Elk van hun diensten, intern en extern, maakt gebruik van DNS. Alle communicatie valt stil.

Ook hier valt de enorme lange tijdsduur van downtime op, een kleine aanpassing zou toch snel teruggedraaid moeten zijn, niet?

Berichten op Twitter en Reddit leren ons dat het grootste probleem eerder van praktische aard was, letterlijk niets werkte nog. De tool waar het personeel mee communiceerde was offline, men kon nergens meer op inloggen en zelfs de fysieke toegangspoortjes van de gebouwen en datacenters waren buiten dienst.

Facebook raakte zelfs niet meer binnen in hun eigen datacenter. Een foutenanalyse maken op deze manier is enorm lastig. De mensen die dan uiteindelijk toegang hadden tot de plaats delict, waren dan ook vooral de remote hands met beperkte kennis van het product. Een bijzonder moeizame manier van werken, maar wel de realiteit van een lights out datacenter. 

Over Twitch kunnen we kort zijn: een configuratiefout zorgde voor een ongezien datalek. De broncode alsook een hoop financiële documenten kwamen op straat te liggen. In tegenstelling tot Slack en Facebook was er dus geen downtime, maar wel een breuk in confidentialiteit. Zoals bij de meeste security incidenten werd het lek pas achteraf gedicht.

Los van de technische aard van al deze incidenten kan je wel concluderen dat de oorzaak vooral menselijk is. Mensen maken fouten, zeker in complexe systemen. Hier valt weinig aan te doen en bestraffen is hier nooit de oplossing. Goede voorbereiding voor, maar ook na een aanpassing maken het echte verschil. Hope for the best plan for the worst.

Achteraf is het makkelijk praten, de beste stuurlui staan aan wal. Maar concreet is de les in dit geval:

• Had Slack de TTL van zijn zone verlaagd voor de omschakeling naar DNSSEC tot een waarde van enkele minuten, was het terugschakelen vlotter verlopen. 
• Had Facebook de afhankelijkheid van zijn systemen goed doordacht, denk aan een out of band management, gebruik van externe communicatie tools, enzovoort…,  was een rollback waarschijnlijk sneller uitgerold. 
• Had Twitch een peer review op zijn server architectuur en configuraties gedaan, of een externe security scan gebruikt, was dit lek misschien veel eerder intern opgevangen.

Je mag er zeker van zijn dat er voldoende dagen binnen deze bedrijven gevuld zullen worden met root cause analyses en meetings over hoe dit had voorkomen kunnen worden. Laat deze visible incidenten zelf ook niet zomaar voorbij gaan. Gebruik ze als een waarschuwing en denk na hoe je hier als onderneming zelf wat uit kan leren.