Storing Cloudflare veroorzaakt door aanpassing netwerkconfiguratie
Een aanpassing in de netwerkconfiguratie was verantwoordelijk voor de omvangrijke storing bij Cloudflare vandaag waardoor allerlei populaire websites en diensten meer dan een uur offline waren, zo laat het internetbedrijf zelf weten. De aanpassing was onderdeel van een project om de drukste locaties van het bedrijf, dat ddos-bescherming biedt en als content delivery network fungeert, veerkrachtiger te maken. Het ging in totaal om datacenters in negentien locaties die door de storing werden getroffen. In totaal duurde de storing ruim een uur.
Om toegankelijk op internet te zijn maken netwerken zoals Cloudflare gebruik van het BGP-protocol. Het border gateway protocol (BGP) wordt gebruikt om verkeer tussen autonomous systems (AS) te routeren en essentieel is voor de werking van het internet. Als onderdeel van dit protocol stellen operators policies op die bepalen welke prefixes, een verzameling aangrenzende ip-adressen, aan andere operators worden aangekondigd of van hen worden geaccepteerd.
Deze policies zorgen ervoor dat een prefix wordt geadverteerd aan andere operators of dat dit niet het geval is. Een aanpassing in een policy kan ervoor zorgen dat een eerder geadverteerde prefix wordt ingetrokken, waardoor die ip-adressen niet langer meer bereikbaar zijn vanaf het internet. Vandaag voerde Cloudflare een aanpassing aan verschillende policies door, waardoor een verzameling van belangrijke prefixes werd ingetrokken.
Het intrekken zorgde ervoor dat de negentien datacenters offline gingen. Doordat de prefixes werden ingetrokken was het lastig voor Cloudflare-engineers om de betreffende locaties te bereiken en de aanpassing ongedaan te maken. Daarbij werden alleen de datacenters geraakt waar Cloudflare aan een" veerkrachtigere en flexibelere architectuur" werkt. Dit zijn echter ook de datacenters die het grootste deel van het Cloudflare-verkeer verwerken.
Het internetbedrijf zegt voor deze gevallen over back-upprocedures te beschikken en kon zo alsnog de betreffende locaties benaderen. Tijdens de hersteloperatie bleek dat verschillende netwerk-engineers elkaars aanpassingen ongedaan maakten, waardoor het probleem zich weer sporadisch voordeed. Na een uur en een kwartier waren alle datacenters weer online. Verder maakt Cloudflare excuses en stelt dat de storing grote gevolgen had en er op verschillende vlakken verbeteringen mogelijk zijn om herhaling te voorkomen.
Die hebben daar nog een heel verhaal over gepubliceerd maar van elkaars fouten leren doet niemand.
Die hebben daar nog een heel verhaal over gepubliceerd maar van elkaars fouten leren doet niemand.
Omdat Facebook een outage had door een routing error en Cloudflare dat nu ook heeft, is je conclusie dat “niemand van elkaars fouten leert”. Come on now… accepteer dat fouten onvermijdelijk zijn in een dynamisch en competitive bedrijf. Het is knap om te zien hoe ze met deze fouten handelen en dit communiceren. Het is altijd de comment section die weet hoe je zo een fout had kunnen voorkomen, de beste stuurlui staan aan wal.
Die hebben daar nog een heel verhaal over gepubliceerd maar van elkaars fouten leren doet niemand.
Omdat Facebook een outage had door een routing error en Cloudflare dat nu ook heeft, is je conclusie dat “niemand van elkaars fouten leert”. Come on now… accepteer dat fouten onvermijdelijk zijn in een dynamisch en competitive bedrijf.
Fouten kunnen voorkomen, maar het zinnetje "Doordat de prefixes werden ingetrokken was het lastig voor Cloudflare-engineers om de betreffende locaties te bereiken en de aanpassing ongedaan te maken" geeft duidelijk aan dat er niet van andermans fouten geleerd is!
Immers daar had iemand kunnen bedenken "het is wel handig om een apart management netwerk te hebben wat niet gerelateerd is aan onze normale BGP advertisements". En dat hebben ze kennelijk (nog) niet geinstalleerd.
Dit was ook bij de Facebook case het probleem, en eerlijk gezegd verbaasde het me toen ook al dat er niet een of ander overlay netwerk was voor dit soort router beheer. Al was het maar om management interfaces van het internet af te houden.
Ik denk dat heel weinig diensten - inclusief je eigen server - de uptime van Cloudflare halen .
Je kent Cloudflare blijkbaar alleen als open DNS ?
Als je een dienst runt waar DDoS een risico is Cloudflare één van de twee of drie keuzes om heel goed DDoS bestendig te worden. Dat zelf doen is voor vrijwel niemand een opptie.
Die hebben daar nog een heel verhaal over gepubliceerd maar van elkaars fouten leren doet niemand.
Omdat Facebook een outage had door een routing error en Cloudflare dat nu ook heeft, is je conclusie dat “niemand van elkaars fouten leert”. Come on now… accepteer dat fouten onvermijdelijk zijn in een dynamisch en competitive bedrijf.
Fouten kunnen voorkomen, maar het zinnetje "Doordat de prefixes werden ingetrokken was het lastig voor Cloudflare-engineers om de betreffende locaties te bereiken en de aanpassing ongedaan te maken" geeft duidelijk aan dat er niet van andermans fouten geleerd is!
Immers daar had iemand kunnen bedenken "het is wel handig om een apart management netwerk te hebben wat niet gerelateerd is aan onze normale BGP advertisements". En dat hebben ze kennelijk (nog) niet geinstalleerd.
Je wist zo zeker dat je gelijk had dat een alinea verder lezen niet meer nodig was, is het niet ?
Ik zal 'm maar even citeren , zodat je ziet hoe voorbarig je was :
Het internetbedrijf zegt voor deze gevallen over back-upprocedures te beschikken en kon zo alsnog de betreffende locaties benaderen. Tijdens de hersteloperatie bleek dat verschillende netwerk-engineers elkaars aanpassingen ongedaan maakten, waardoor het probleem zich weer sporadisch voordeed.
Dus ja - ze hadden wel degelijk een out-of-band optie.
Daarna zijn blijkbaar een paar separate NOCs allemaal op de "major outage" gedoken, en hebben deels elkaar in de weg gezeten.
(Je gokt dat de normale intra--bedrijfs-communicatie ook verstoord was, en iedereen even te druk was met zoeken om te coordineren).
Dit was ook bij de Facebook case het probleem, en eerlijk gezegd verbaasde het me toen ook al dat er niet een of ander overlay netwerk was voor dit soort router beheer. Al was het maar om management interfaces van het internet af te houden.
Hint : een overlay netwerk zit op een underlay drager. En als _die_ verstoord is heb je dus een fors probleem.
Gewoon - beter lezen. Ze hadden wat nodig was om de storing op te lossen.
Als je onverwacht een heel erg dikke storing voor je kiezen krijgt kan het - ook voor erg goede engineers - even duren om dooir te krijgen wat de werkelijke oorzaak is en welke problemen en alarmen (slechts) gevolg zijn.
Daarna zoeken naar hoe de out-of-band access ook al weer ging, oplossen , en deels in de weg gezeten worden door andere engineers die ook bezig zijn. (natuurlijk heb je niet slechts één noc locatie ).
Dat uur is niet zo heel vreemd.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Specialiseer je in Forensisch ICT
Online informatieavond 19 november
Wil jij je specialiseren in digitaal forensisch onderzoek? Je kennis verbreden en tech-nische vaardigheden ontwikkelen? Ontdek de cursus- en opleidingsmogelijkheden van Hogeschool Leiden:
- Bachelor Informatica Forensisch ICT (deeltijd)
- Master Digital Forensics (vol- en deeltijd)
- Module Mobile Forensics
- Module Data Analytics
Interesse? Meld je aan!
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
