E se il blocco di Facebook accadesse agli SPID...?

Due giorni fa Facebook, Instagram, Whatsapp sono diventati inaccessibili per molte ore. Ho trovato questo evento interessante perché proprio in questi giorni:

1. Sto trattando la tecnologia coinvolta nel problema (il DNS) nel mio corso del terzo anno (Reti di Calcolatori).
2. E' stato pubblicato un mio lavoro scientifico in cui mi sono chiesto varie cose tra le quali: cosa accadrebbe ai siti web della pubblica amministrazione se si verificasse proprio un problema del genere. Ad esempio, è possibile che un guasto blocchi centinaia o migliaia di siti web della pubblica amministrazione?
3. Domani sarà discussa una tesi di laurea magistrale di cui sono relatore in cui viene studiato cosa accadrebbe al "Sistema Pubblico di Identità Digitale (SPID)" se si verificasse quel problema.

Quindi, timing perfetto.

Nota bene: il problema che si è verificato a Facebook è dovuto ad un guasto. Gli studi 2 e 3 considerano guasti ed attacchi. Un attacco può avere un effetto analogo ad un guasto: rendere il sistema attaccato irraggiungibile. Può però avere anche un effetto enormemente più dannoso: un attaccante che prende il controllo di un nameserver può portare i client a collegarsi con un server controllato dall'attaccante ed indistinguibile dal server legittimo. Lo stesso effetto può essere ottenuto da un attaccante che prende il controllo di un dispositivo di rete. L'articolo 2 contiene numerosi riferimenti ad eventi di questa natura realmente accaduti (alcuni dei quali hanno comportato furti di grandi quantità di denaro in bitcoin, ad esempio).

• Un riassunto di 1 è stato fornito da Facebook stessa: More details about the October 4 outage. Attenzione: è un documento scritto per persone che hanno una conoscenza di base delle reti di calcolatori; inoltre, contiene almeno un elemento che potrebbe confondere le idee (fa riferimento a server che si auto-dichiarano irraggiungibili se rilevano problemi di connettività; ciò non è indispensabile e neanche comune). (update 13/10/2021: altra descrizione molto più dettagliata: Understanding How Facebook Disappeared from the Internet )
• Per 2 riporto titolo, abstract e paper qui sotto. Ho analizzato varie decine di migliaia di siti web delle pubbliche amministrazioni in Italia, Germania, UK, US.
  
  Robustness analysis of DNS paths and web access paths in public administration websites
  
  Attacks at the naming or the routing infrastructure of the Internet have long become a reality and one single such attack has the potential of affecting access to Internet-facing services in many organizations. An important question to address is assessing the potential impact of attacks of this sort on the web infrastructure of an entire nation.
  
  In this work we examine the dependence of a large set of public administration websites on DNS entities and autonomous systems of four different countries: Italy, Germany, UK and US. We collected the dependencies of those websites from DNS zones, nameservers, networks, autonomous systems, and assessed the potential global impact of localized attacks on those entities.
  
  We also analyzed the prevalence of such defensive technologies as BGP Route Origin Authorization, DNSSEC and HTTPS Strict Transport Security. Our analysis highlights the structural interdependencies within the web infrastructures of public interest and illustrates the corresponding open problems, issues whose relevance can only grow.
  
  https://authors.elsevier.com/a/1dsnBVwcQgOqQ (valido fino al 25/11/2021, se qualcuno fosse interessato dopo questa data mi scriva).
• La tesi 3 consiste di un piccolo sottoinsieme delle analisi fatte in 2, effettuate sugli identity provider SPID e su altri identity provider scelti come riferimento (equivalenti SPID in Spagna e UK, Google, Facebook, Twitter ed altro).

Il problema che si è verificato a Facebook, spiegato in maggiore dettaglio più sotto, ha evidenziato un grosso problema di fondo per il quale è molto difficile trovare una soluzione universalmente accettabile.

Le specifiche DNS richiedono che ogni "zona DNS" sia replicata su più name server e che tali name server siano distribuiti in locazioni geografiche distinte. Ciò dovrebbe rendere estremamente improbabili situazioni nelle quali un guasto rende tutti i name server della zona inaccessibili. Nella realtà, molto spesso i name server non sono distribuiti geograficamente o, anche se lo sono, da un punto di vista logico sono centralizzati. Pertanto, in pratica, la probabilità che un guasto blocchi tutto può non essere trascurabile. E' esattamente ciò che è accaduto a Facebook.

Perché molte organizzazioni tendono a mantenere la propria infrastruttura DNS logicamente e/o fisicamente centralizzata anche se ciò potrebbe renderla meno tollerante ai guasti? Per renderne più semplice la difesa da attacchi. Un perimetro "piccolo e noto" è più facilmente difendibile da attacchi rispetto ad un perimetro "grande, che coinvolge molte organizzazioni, distribuito, non definito con precisione".

Pertanto ci troviamo di fronte ad un dilemma fondamentale: per avere robustezza ai guasti dovrei avere alta ridondanza con replicazione organizzativa e geografica; per avere perimetro facilmente difendibile dovrei invece avere esattamente l'opposto: poca ridondanza, poca o nessuna replicazione organizzativa e geografica. Cosa fare in pratica? Nessuno lo sa, più precisamente, ogni scelta è un compromesso tra queste due esigenze opposte e non è possibile affermare quale sia la scelta migliore in assoluto.

Nello studio 2 ho analizzato tematiche di questo genere (e molte altre) in Italia, Germania, US, UK. In alcuni casi si ha l'impressione di anarchia quasi completa: ognuno fa quel caspita che vuole, con esiti a volte discutibili ed a volte decisamente negativi. In altri casi emergono invece scelte architetturali pianificate e realizzate con cura e competenza.

Un dato che mi pare interessante:

• Tre paesi su quattro hanno per le proprie zone DNS più importanti almeno 3 name server diversi distribuiti su 3 network diverse, gestite da 2-4 autonomous systems diversi (quindi alta ridondanza e perimetro non piccolissimo ma piccolo e ben definito).
• Il quarto paese ha per la propria zona DNS più importante solo 2 (due) nameserver, localizzati nella stessa network. Qui abbiamo ridondanza quasi nulla. Sarà la scelta appropriata? Speriamo. Io spero che sia stata almeno una scelta e non qualcosa che "just happened" senza che nessuno ci abbia riflettuto in maniera appropriata.

Altro dato che mi pare interessante. Per come funziona il routing in Internet, un attaccante che opera a livello di routing può facilmente cercare di mettersi in mezzo nel traffico da/verso un intervallo di indirizzi IP scelto dall'attaccante stesso. Non è detto che ci riesca (dipende da molti fattori) ma provarci è facilissimo. Se ci riesce, allora l'attaccante ha il controllo completo del traffico che gli transita sotto il naso e può quindi fare tante cose interessanti (ad esempio rubare bitcoin alterando la traduzione da nome a indirizzo IP, cosa accaduta veramente, vedi i riferimenti in 2). Esiste una certa tecnologia difensiva che si chiama ROA ed è opzionale. Se una organizzazione attiva la ROA per le proprie network, allora gli attacchi sopra descritti sono impossibili (semplifico moltissimo). Bene:

• Tre paesi su quattro hanno ROA in tutte le 3 rispettive network più importanti; se consideriamo le 5 network più importanti, ROA è attiva in 4 o 5 di esse, a seconda del paese.
• Il quarto paese ha la ROA in solo una delle 3 network più importanti; il risultato non cambia se consideriamo le 5 network più importanti.

Quale sarà il quarto paese di questi esempi? Indovinate.

Cosa è accaduto esattamente

Quello che è successo due giorni fa, in estrema sintesi e semplificando un pò, è questo:

1. Premessa. Un calcolatore collegato a Internet è identificato dal proprio indirizzo IP. I servizi Internet si identificano per nome. Una infrastruttura chiamata DNS traduce da nome ad indirizzo IP. Il DNS è una vera meraviglia dell'ingegno umano: centinaia di migliaia di name server sparsi in giro per il mondo e gestiti ognuno da una organizzazione diversa dall'altra; progettata alla fine degli anni ottanta, quando il numero di nomi ed il numero di calcolatori che devono tradurre nomi era di 6 ordini di grandezza inferiore a quello di oggi.
   
   Non credo che esista nessun altro settore tecnologico in cui un artefatto continui a funzionare aumentandone il carico non di 6 volte, ma di 6 ordini di grandezza.
   
   Ci sono molti motivi per i quali in Internet è stato scelto di identificare i servizi per nome:
• gli indirizzi IP sono difficili da ricordare, a differenza dei nomi;
• un servizio potrebbe dovere cambiare il proprio indirizzo IP nel tempo (ad esempio perché deve cambiare il server che lo realizza);
• uno stesso servizio potrebbe essere disponibile su tanti indirizzi IP diversi (ad esempio, chi si collega a Facebook dall'Italia riceve una certa traduzione, cioè un certo indirizzo IP, per il nome facebook.com; chi si collega dalla Turchia o dalla Nuova Zelanda quasi certamente ne riceve una diversa);
• e altro.
2. Due giorni fa, i gestori delle network interne a Facebook hanno commesso un errore nella configurazione interna. A causa di questo errore, alcuni name server sono diventati irraggiungibili: erano fisicamente collegati a Internet ma comunicare con questi name server è diventato impossibile. Questi name server erano quelli utilizzati da tutto il resto del mondo per tradurre in indirizzo IP tutti i nomi della forma:
• qualcosa.facebook.com
• qualcosa.instagram.com
• qualcosa.whatsapp.com.
3. Tutti i calcolatori del mondo che dovevano usare i servizi di Facebook, Instagram o Whatsapp, cercavano di ottenere l'indirizzo IP corrispondente a nomi delle forme sopra elencate, come fanno sempre. Solo che nessuno otteneva risposta, proprio perché i name server che fanno questa traduzione erano diventati irraggiungibili. Quindi nessuno poteva usare Facebook, Instagram, Whatsapp, "semplicemente" perché nessuno era in grado di trovare l'indirizzo IP da usare.

Uno potrebbe chiedersi "vabbè, ma perché chi si doveva collegare non ha usato l'indirizzo IP che usa sempre?". La risposta non è semplicissima. I software che accedono ai servizi sono predisposti per usare il DNS, quindi sono predisposti per attendersi un nome e poi tradurlo in indirizzo IP. Quando si riceve una traduzione, nella traduzione stessa è specificato per quanto tempo la si può usare: da pochi secondi a qualche giorno. Tipicamente per qualche ora. Una volta scaduto l'intervallo di validità della traduzione, quella traduzione non è più utilizzabile ed occorre contattare il DNS nuovamente.

Adesso uno potrebbe chiedersi "ho capito, ma allora perché nelle traduzioni dei nomi di facebook&C hanno specificato solo poche ore?". Supponiamo che una traduzione sia valida una settimana. Se per caso quella traduzione diventasse inadatta per qualche motivo (esempio: si guasta il server con l'indirizzo IP specificato nella traduzione) allora per una settimana sarebbe impossibile utilizzare una traduzione migliore (per una settimana nessuno si collega più a Facebook!). Quindi, in parole povere e salvo casi particolari, le traduzioni sono impostate in modo da essere considerate valide "per poco tempo".