Note di Matteo

L'architettura anti-DDoS di Cloudflare:

Here is what actually happens when an attack hits our network. Packets arrive at the network interface card (NIC) and immediately enter an eXpress Data Path (XDP) program chain managed by xdpd, running in driver mode. Among the first programs in that chain is l4drop, which evaluates each packet against mitigation rules in extended Berkeley Packet Filter (eBPF). Those rules are generated by dosd, our denial of service daemon, which runs on every server in our fleet. Each dosd instance samples incoming traffic, builds a table of the heaviest hitters it sees, and broadcasts that table to every other instance in the colo. The result is a shared colo-wide view of traffic, and because every server works from the same data, they reach the same mitigation decision.

When dosd detects an attack pattern, the resulting rule is applied locally via l4drop and propagates globally via Quicksilver, our distributed key-value (KV) store, reaching every server in every data center within seconds. Only after surviving l4drop do packets reach Unimog, our Layer 4 (L4) load balancer, which distributes them across healthy servers in the data center. For Magic Transit customers routing enterprise network traffic through our edge, flowtrackd adds a further layer of stateful TCP inspection, tracking connection state and dropping packets that don't belong to legitimate flows.

The 31.4 Tbps attack we mitigated followed exactly this path. No traffic was backhauled to a centralized scrubbing center. No human intervened. Every server in the targeted data centers independently recognized the attack and began dropping malicious packets at line rate, before those packets consumed a single CPU cycle of application processing. The software is only half the story: none of it works if the ports aren't there to absorb the traffic in the first place.

La chiave alla fine è l'ultima frase: devi prima avere la capacità di rete, motivo per cui è ormai estremamente difficile che nascano nuove aziende nel settore che facciano il percorso di startup che ha fatto Cloudflare (il traffico Internet di oggi non è quello del 2010).

TIL il dominio one.one appartiene a one.com, un provider di hosting (diverso da 1&1). Il dominio one.one.one.one è stato però delegato a Cloudflare per il servizio DNS 1.1.1.1, dice il CEO @eastdakota.

Un altro outage di Cloudflare causato ancora dall'applicazione di un cambio di configurazione globalmente. In questo caso sono stati rimossi per errore molti prefissi BYOIP dagli annunci BGP della rete edge, per via di un bug nel codice che elenca i prefissi da rimuovere:

Because the client is passing pending_delete with no value, the result of Query().Get(“pending_delete”) here will be an empty string (“”), so the API server interprets this as a request for all BYOIP prefixes instead of just those prefixes that were supposed to be removed.

Certo è che se uno progetta un endpoint di un'API mission critical dandogli un formato così strambo e fuori da ogni best practice (/v1/prefixes?pending_delete) un po' se le cerca.

TIL Cloudflare sovrascrive il record CAA aprendo ad attacchi MiTM in caso di BGP hijacking, e anche se a conoscenza del problema l'ha sempre ignorato:

When a BGP leak occurs (malicious or accidental), an attacker can intercept traffic to satisfy an ACME http-01 challenge. This allows them to issue a valid SSL certificate for a victim’s domain.

The IETF standard RFC 8657 was created specifically to stop this by using accounturi in CAA records to bind issuance to a specific account.

Issue: But Cloudflare’s Universal SSL automatically injects permissive CAA records that override user-defined accounturi bindings.

Ignoring, Cloudflare is saying like: “We know BGP leaks happen constantly, but we will force a configuration that allows those leaks to be used for valid certificate issuance by malicious attackers.”

Qua la spiegazione completa.

Ancora sulla questione Cloudflare-AGCOM: nella delibera c'è scritto che il punto non era Piracy Shield (cioè i blocchi entro 30 minuti), ma ordini di blocco decisi da un tribunale. A quanto pare Cloudflare si è rifiutata di eseguirli, e quindi è evidentemente nel torto.

AGCOM specifica poi questo dato: "Cloudflare appare come fornitore di servizi del 70% dei siti illeciti degli ultimi anni".

TIL ci sono router Cisco che crashano se una risposta DNS contenente CNAME ha i record CNAME nell'ordine sbagliato. Cioè anziché:

;; QUESTION SECTION:
;; www.example.com.        IN    A

;; ANSWER SECTION:
www.example.com.    3600   IN    CNAME  cdn.example.com.
cdn.example.com.    300    IN    A      198.51.100.1

Così:

;; QUESTION SECTION:
;; www.example.com.	       IN    A

;; ANSWER SECTION:
cdn.example.com.    300    IN    A      198.51.100.1
www.example.com.    3600   IN    CNAME  cdn.example.com.

Cloudflare racconta che ha invertito l'ordine dei record nelle risposte DNS come mostrato qui sopra per rendere più efficiente il codice, e i router Cisco hanno iniziato ad andare in crash loop fino al rollback della modifica. Anche la risoluzione DNS nel kernel Linux ha un problema simile, anche se in quel caso la risposta veniva considerata vuota.

La risposta della Lega Serie A a Cloudflare sulla questione antipirateria è parziale ma contiene del vero, specialmente sul fatto che Cloudflare fa orecchie da mercante offrendo consapevolmente servizi a organizzazioni illegali e si rifiuta di rispondere a qualsiasi richiesta in nome della libertà di espressione (che ben poco c'entra col copyright):

Cloudflare was sanctioned because it is the only major global company that, by choice of its CEO, systematically refuses any and all cooperation with authorities, law enforcement, rights holders, and even courts. For this reason, it has become the first and most common choice of criminal organizations for operating their illegal services, precisely because of its determined stance in enabling acts of piracy.

This happens not only in Italy but across the world, as demonstrated by numerous legal rulings against Cloudflare in France, Spain, Belgium, and of course, in Italy as well.

Ma il commento che racchiude tutti i punti di vista e che condivido di più l'ho trovato nella sezione commenti del Post:

Non so dove cominciare con le cose che non vanno in tutta questa storia... Un'azienda monopolistica che ha il potere di bloccare internet in quasi tutto il mondo (anche il FT ne parlava qualche giorno fa); la lega serie A che deve difendere interessi economici da corporazione medievale; il governo vassallo della suddetta corporazione che fa una legge estremamente problematica con grossi rischi di abusi (da censura delle partite a censura delle news è un attimo)... C'è molto di sbagliato nell'agire di tutti gli attori, e di mezzo ci vanno i cittadini

Ognuno con i propri interessi parziali e non indirizzati al buonsenso o al bene comune e nessuno vuole arretrare di un centimetro.

(Qualcuno potrebbe avere da ridire sul fatto che Cloudflare sia monopolista: in termini stretti non lo è, ma tende a esserlo se consideriamo che nessun altro è in grado di offrire servizi simili gratuitamente a una platea così ampia di persone e aziende, rendendolo molto spesso insostituibile.)

Notevole risposta del CEO di Cloudflare alla sanzione di 14 milioni di euro per mancata adesione a Piracy Shield (di cui ho scritto qui):

[...] In addition, we are considering the following actions: 1) discontinuing the millions of dollars in pro bono cyber security services we are providing the upcoming Milano-Cortina Olympics; 2) discontinuing Cloudflare’s Free cyber security services for any Italy-based users; 3) removing all servers from Italian cities; and 4) terminating all plans to build an Italian Cloudflare office or make any investments in the country.

Play stupid games, win stupid prizes. [...]

Strana e rara frecciatina di Akamai a Cloudflare:

As I write this, another cloud provider is experiencing their third outage this quarter. While frequently lauded for innovation, today’s IT teams responsible for mission-critical applications for their customers are learning yet another painful lesson about the true cost of unreliability.

In un articolo sull'affidabilità, in cui effettivamente Akamai è essenzialmente leader (o forse la scarsa trasparenza rinforza quell'idea).

Il postmortem del nuovo disservizio di Cloudflare, durato 25 minuti: la causa è di nuovo una configurazione distribuita globalmente senza rollout progressivo:

This second change of turning off our WAF testing tool was implemented using our global configuration system. This system does not perform gradual rollouts, but rather propagates changes within seconds to the entire fleet of servers in our network and is under review following the outage we experienced on November 18.

Unfortunately, in our FL1 version of our proxy, under certain circumstances, the second change of turning off our WAF rule testing tool caused an error state that resulted in 500 HTTP error codes to be served from our network.

Almeno stanno lavorando a una soluzione definitiva che non tiri giù tutto con un click:

Before the end of next week we will publish a detailed breakdown of all the resiliency projects underway, including the ones listed above. While that work is underway, we are locking down all changes to our network in order to ensure we have better mitigation and rollback systems before we begin again.

Cloudflare down again:

Dal postmortem di Cloudflare:

Il motivo delle fluttuazioni iniziali di errori 5xx è dovuto al deployment di un file di configurazione errato del "bot score" della Bot Protection:

As a result, every five minutes there was a chance of either a good or a bad set of configuration files being generated and rapidly propagated across the network.

E infine veniva sempre deployato il file errato, globalmente e istantaneamente (la stessa causa di altri precedenti outage globali di Cloudflare):

The model takes as input a “feature” configuration file. A feature, in this context, is an individual trait used by the machine learning model to make a prediction about whether the request was automated or not. The feature configuration file is a collection of individual features.

This feature file is refreshed every few minutes and published to our entire network and allows us to react to variations in traffic flows across the Internet. It allows us to react to new types of bots and new bot attacks. So it’s critical that it is rolled out frequently and rapidly as bad actors change their tactics quickly.

Il motivo per cui alcuni siti non erano affetti:

Customers deployed on the new FL2 proxy engine, observed HTTP 5xx errors. Customers on our old proxy engine, known as FL, did not see errors, but bot scores were not generated correctly, resulting in all traffic receiving a bot score of zero. Customers that had rules deployed to block bots would have seen large numbers of false positives.

Il file di configurazione conteneva dei dati errati perché per via di un cambio di configurazione la query ClickHouse estraeva più dati del dovuto. Il proxy edge lanciava un'eccezione perché non si aspettava quella quantità di dati:

Cosa c'era quindi che non andava:

• La query era errata (ok, può capitare).
• Non c'era validazione dell'output della query (feature duplicate), che finiva quindi direttamente deployato globalmente, a quanto pare.
• Sull'edge c'era un limite fisso di 200 feature attese, ma non c'era nessuna validazione che il file ne avesse effettivamente di meno.
• Non c'era nemmeno "fail safe" nel caso in cui succedesse.

EDIT: su Hacker News osservazioni molto simili:

They failed on so many levels here.

How can you write the proxy without handling the config containing more than the maximum features limit you set yourself?

How can the database export query not have a limit set if there is a hard limit on number of features?

Why do they do non-critical changes in production before testing in a stage environment?

Why did they think this was a cyberattack and only after two hours realize it was the config file?

Why are they that afraid of a botnet? Does not leave me confident that they will handle the next Aisuru attack.

Anche Resend durante l'outage Cloudflare ha iniziato a lavorare per sostituire Cloudflare con AWS CloudFront, ma alla fine non l'ha fatto e preferisce avere l'edge AWS (dove c'è il resto dell'infrastruttura) solo come failover.

The CloudFront solution was not deployed, but the runbook was created. If the incident were to recur, we could switch to the fallback within 60 seconds. We continued to monitor and then closed the status page.

Altra testimonianza di come il routing Cloudflare sia pessimo sui piani più economici (producendo 150+ ms di latenza evitabile scegliendo nodi a migliaia di km di distanza), un problema che essenzialmente non esiste con le altre CDN:

A dimostrazione di #164, ho notato che diversi siti hanno disattivato Cloudflare visto il prolungarsi dei problemi: Mailtrap, Instatus, X. E allora cosa era lì a fare?

Cloudflare KO da quasi due ore e la differenza rispetto a quando us-east-1 di AWS è down è che i disservizi Cloudflare tendono ad essere globali e quindi più impattanti.

La quantità di siti impattati che sto osservando mi sembra maggiore rispetto all'outage AWS del mese scorso. A questo giro noto cloud provider con i siti in crisi (Netsons), servizi di status page (Instatus), di rilevamento errori (Bugsnag), di invio email (Mailtrap, Resend) che usano Cloudflare magari senza nemmeno averne bisogno, magari perché "lo usano tutti", "costa poco", e senza un'adeguata valutazione di cosa comporta far passare l'intero traffico non cifrato attraverso un'azienda che non ha una reputazione di affidabilità. A questo giro anche ChatGPT, X e N26.

Magari anche con l'illusione che Cloudflare serva a qualcosa out of the box nel gestire gli attacchi DDoS. Non lo è: gli attacchi L3/L4 li gestisce tipicamente ogni provider di rilievo (almeno fino a una certa scala) e non è per questo necessario Cloudflare, mentre è noto a chi ci è passato che Cloudflare ha l'abitudine di passare alla origin gli attacchi L7 anche significativi (decine di migliaia di richieste al secondo), fuori pattern e con origin palesemente in crisi. Di certo è un utile, flessibile e soprattutto accessibile firewall edge a scalabilità infinita che avrebbe bisogno di più competizione.

TIL il firewall di Cloudflare era inizialmente fatto con nginx + PHP (!):

[...] the first version of FL was implemented based on the NGINX webserver, with product logic implemented in PHP. After 3 years, the system became too complex to manage effectively, and too slow to respond, and an almost complete rewrite of the running system was performed.

E poi fino al 2024 nginx (openresty) con scripting Lua:

From this point on, FL was implemented using NGINX, the OpenResty framework, and LuaJIT. While this was great for a long time, over the last few years it started to show its age. We had to spend increasing amounts of time fixing or working around obscure bugs in LuaJIT. The highly dynamic and unstructured nature of our Lua code, which was a blessing when first trying to implement logic quickly, became a source of errors and delay when trying to integrate large amounts of complex product logic.

Da quest'anno è in rollout la nuova versione scritta in Rust.