Sintesi
Il 14 ottobre 2020, tra le 02:41 e le 02:52 UTC, ogni istanza presso AMS-01 non era raggiungibile. Un attacco volumetrico mirato a un singolo indirizzo cliente ha raggiunto un picco di 340 Gbit/s e ha saturato gli uplink del sito. Lo abbiamo risolto chiedendo all'upstream di scartare tutto il traffico verso l'indirizzo bersaglio, ripristinando il sito e lasciando quel singolo cliente offline per altri cinquanta minuti. Nessun dato è andato perso e nessuna istanza è stata danneggiata. Il sito non aveva capacità di scrubbing all'epoca, e questa è stata una decisione di acquisto, non un incidente.
Cronologia
Tutti gli orari in UTC, 14 ottobre 2020.
| Ora | Evento |
|---|---|
| 02:41:04 | Il traffico verso un singolo indirizzo cliente sale da circa 200 Mbit/s a 90 Gbit/s in meno di venti secondi. |
| 02:41:30 | Entrambi gli uplink del sito si saturano. La perdita di pacchetti diventa totale su ogni prefisso del sito, non solo sul bersaglio. |
| 02:42 | L'allarme automatico scatta sulla raggiungibilità da tre sonde esterne. |
| 02:44 | L'ingegnere di turno si collega. L'attacco è visibile sui grafici delle porte e da nessun'altra parte, perché la nostra raccolta di flussi era campionata a una frequenza che non riusciva a starci dietro. |
| 02:46 | Picco misurato a 340 Gbit/s. La composizione è UDP riflesso, per lo più DNS e NTP, proveniente da decine di migliaia di sorgenti. |
| 02:47 | Decisione di richiedere uno scarto upstream di tutto il traffico verso l'indirizzo bersaglio. Questo era l'unico strumento a nostra disposizione. |
| 02:49 | Lo scarto si propaga al primo upstream. |
| 02:51 | Il secondo upstream lo applica. L'utilizzo dell'uplink scende sotto la capacità. |
| 02:52:10 | Sito completamente raggiungibile. Interruzione totale visibile al cliente: undici minuti e sei secondi. |
| 03:20 | Il cliente interessato viene contattato e gli viene offerto un nuovo indirizzo. |
| 03:42 | Il cliente si sposta su un nuovo indirizzo; il suo servizio torna operativo. |
Causa principale
La causa prossima è stata un attacco che non siamo riusciti ad assorbire. Ciò che lo ha realmente causato è che vendevamo hosting in una città dove attacchi di queste dimensioni erano all'ordine del giorno, con duecento gigabit di uplink e nessun filtraggio, e trattavamo un accordo di scarto upstream come un piano.
Non è sfortuna. È stata una decisione, presa nel 2019 a favore di spendere i soldi in hardware, ed è stata sbagliata.
Due guasti secondari hanno peggiorato la situazione. La nostra raccolta di flussi campionava a una frequenza che non forniva dettagli utili durante un evento reale, quindi i primi quattro minuti sono stati spesi a leggere i contatori delle interfacce. E lo scarto era manuale, richiedendo un essere umano sveglio, autenticato e sicuro di sé, che sono tre requisiti di troppo alle tre del mattino.
Cosa è costato questo al cliente
Per essere franchi: abbiamo risolto il nostro problema spegnendo il loro servizio. Una rotta di scarto è una decisione che un cliente sarà irraggiungibile così che tutti gli altri non lo siano. Era la chiamata corretta con gli strumenti che avevamo, ma è comunque stata la loro interruzione, non la nostra, e non avevano acquistato da noi alcun prodotto che promettesse diversamente.
Sono rimasti. Non li abbiamo fatti pagare per ottobre.
Cosa abbiamo cambiato
- Scrubbing sempre attivo al perimetro, acquistato entro tre settimane, con una capacità iniziale di 1.2 Tbit/s. Il filtraggio è permanentemente nel percorso, quindi non c'è ritardo di rilevamento e nessun pulsante da premere alle 02:47. Questa è ora la norma in ogni sito, fino a 12 Tbit/s nel più grande.
- Uplink presso AMS-01 aumentato, prima a 200 Gbit/s di capacità aggiuntiva e poi ai 400 Gbit/s con cui il sito opera oggi.
- Telemetria dei flussi non campionata su ogni perimetro di sito, conservata per scopi operativi per sette giorni. Questi sono metadati di traffico per le nostre porte; non sono traffico delle istanze né contenuti di nulla.
- La rotta di scarto è diventata automatica, con una soglia documentata, una politica annunciata e una mail al cliente interessato entro sessanta secondi invece che trentanove minuti.
- Gli attacchi sono pubblicati sulla pagina di stato, con dimensione e durata, che qualcuno se ne sia accorto o meno.
Cosa non abbiamo cambiato, e perché
Non abbiamo iniziato a far pagare il filtraggio. Lo scrubbing di base è incluso in ogni piano in ogni sito e lo è sempre stato da quando lo abbiamo acquistato. Un attacco non è un servizio richiesto dalla vittima. Il filtraggio di livello 7 con regole personalizzate esiste come componente aggiuntivo perché richiede un umano dalla nostra parte, e questo è diverso da un'inondazione volumetrica.
Non abbiamo rimosso la rotta di scarto. Dodici terabit al secondo è un numero, non l'infinito, e fingere che non avremo mai più bisogno dello strumento grossolano sarebbe disonesto. Ciò che è cambiato è che ora è l'ultima risorsa documentata, non l'unico passo.
Non abbiamo imposto tetti di traffico per cliente. Limitare la velocità di ogni cliente a una frazione sicura dell'uplink avrebbe impedito questo, ma avrebbe anche limitato ogni legittima impennata. Il filtraggio appartiene al perimetro, sull'attacco, non sul cliente.
Non abbiamo spostato il cliente su un prodotto diverso. Stavano eseguendo ciò per cui avevano pagato, sul piano che si addiceva a loro, e non era colpa loro se qualcuno ha puntato una botnet contro di loro.