Waarom lag het internet weer uren plat?
Dinsdag 18 november was het plots heel stil op het internet. Heel wat websites waren niet of moeilijk bereikbaar. De ene was helemaal offline, de andere laadde traag of kon geen afbeeldingen weergeven. Je kon er in elk geval niet naast kijken. Ook X en ChatGPT waren getroffen, dus wie daar naar de reden voor de problemen wou zoeken, was er ook aan voor de moeite. Een cyberaanval lag alvast niet aan de oorsprong van de heikele kwestie.
Kettingreactie legt internet plat
De CEO van Cloudflare, Matthew Prince, gaf in een blogpost uitleg waarom de diensten offline waren gegaan. Het probleem was niet veroorzaakt door een cyberaanval of door een overvloed aan AI-crawlers, maar door een interne wijziging in de database-instellingen. Een interne configuratiefout creëerde een te zwaar bestand, wat een kettingreactie veroorzaakte in het netwerkbeheer. Nochtans dachten ze bij Cloudflare zelf meteen aan een hack, waardoor de oplossing van het ware probleem waarschijnlijk wat vertraging opliep.
Een wijziging in de ClickHouse-database-toelatingen zorgde ervoor dat er te veel gegevens in een zogenoemd feature file terechtkwamen. Het Bot Management-systeem gebruikt dat bestand om te bepalen wat legitiem verkeer is en wat niet. Zo vermijdt Cloudflare dat AI-crawlers toch informatie van websites halen die dat eigenlijk niet toelaten. Het bestand werd echter dubbel zo groot als normaal én werd naar alle servers in het netwerk verspreid. Om het helemaal af te maken had de software die het netwerkverkeer regelt een limiet op de bestandsgrootte. Toen die software de feature file wou lezen, crashte die, omdat dat bestand te groot was. Daardoor kon het netwerkverkeer niet goed gerouteerd worden.
Websites die de ‘no-crawl’-bescherming van Cloudflare gebruiken, kwamen zo in de problemen. Normaal beschermt Cloudflare zijn klanten tegen aanvallen terwijl het alle webverkeer voor hen beheert, maar nu resulteerde dat dus in het platleggen van die sites.
Verkeerde diagnose
De symptomen wezen in de richting van een massale DDoS-aanval. Toen ze bij Cloudflare uiteindelijk het ware probleem ontdekten, stopten ze de verspreiding van het grote bestand en vervingen het door een oudere, kleinere versie. Daarna stabiliseerde het systeem. Na meer dan drie uur kon het internetverkeer terug min of meer normaal verlopen. Daarna moest Cloudflare zorgen dat het extra verkeer dat erbij kwam doordat iedereen massaal terug online kwam, de systemen niet opnieuw overbelastte. Nog eens tweeënhalf uur later functioneerden alle systemen opnieuw helemaal zoals het hoorde.
Om te voorkomen dat dit opnieuw gebeurt, neemt Cloudflare vier maatregelen. Het wil bijvoorbeeld eigen configuratiebestanden behandelen alsof ze van externe gebruikers komen. Met andere woorden: ook daarop komen extra controles voordat de systemen ze inlezen, zodat ze niet door het hele netwerk heen worden verspreid. Daarnaast bouwt het extra ‘noodknoppen’ in. Daarmee kunnen ze functies meteen uitschakelen als er iets misloopt, zonder dat alles als een kaartenhuisje in elkaar valt. Ten derde wil het verhinderen dat grote bestanden met foutmeldingen andere processen verstoren. Als laatste wil het nog eens alle noodscenario’s opnieuw onder de loep nemen, zodat Cloudflare beter voorbereid is op allerlei situaties.
Zijn er nu meer storingen?
Aangezien zowat één vijfde van alle internetverkeer via het cloudplatform van Cloudflare loopt, kun je je inbeelden dat allerlei websites zijn getroffen. Qua omvang was het daardoor vergelijkbaar met het uitvallen van Google Cloud en Amazon Web Services eerder dit jaar. De reden waarom we dat als gewone gebruikers veel sneller merken, is dat een groot deel van het internet gebruikmaakt van dezelfde, weinige servers. Deze problemen leggen sowieso bloot hoe onze belangrijkste internetdiensten steunen op die paar grote beheerders. Er zijn niet noodzakelijk meer storingen dan vroeger, maar door het centraliseren van het internetverkeer merken we dat gewoonweg duidelijker.
