Ripararsi solo da fuori, o anche da dentro?

Chi mi conosce o ha avuto occasione di leggere qualche post su questo sito, sa bene la crociata che combatto ogni giorno in favore della sicurezza informatica, strumento fondamentale per la difesa del dato sensibile aziendale (e non solo aziendale).

Quotidianamente mi misuro con nuove sfide andando a scoprire nuovi modi di attacco e loro mitigazione. Fino a qui tutto bene.  E allora questo titolo?
Beh, ovviamente non è una menzione casuale, oggi vi voglio raccontare una storia, forse accaduta o forse mai esistita, Voi prendetela come una proiezione virtuale di un disastro… reale!

C’era una volta una Azienda, di mestiere non fanno gli informatici ma hanno un IT interno molto attivo e una infrastruttura discretamente complessa a livello tecnologico. Nella fattispecie un headquarter con 3 CED attivi, due ridondati e uno per il Backup ed una ulteriore replica in Datacenter lontano 50 km (come da buona prassi per il Disaster Recovery).

L’infrastruttura virutale è basata su vmWare, con 5 nodi Esxi stretchati sui 2 CED, due storage condivisi e con HA attivo (per i meno avvezzi, l’HA consiste nello spostare automaticamente le vm residenti in un Nodo che si guasta su uno (o piu) nodi superstiti).
Parrebbe una situazione iper-protetta, ma sono sempre i dettagli a fare la differenza. Infatti il tecnicismo e le best-practice crollano su loro stessi quando c’è un fail di basso livello.

Ma torniamo alla storiella, un bel giorno nell’Azienda succede che un elettricista deve fare dei test di sopravvivenza su un gruppo di continuità che ha alcuni problemi. Sulla carta questo gruppo dovrebbe alimentare, in caso di mancanza di corrente, solo un piccolo armadio contenente i devices della videosorveglianza, impatto sulla business continuity pari a zero, sempre sulla carta. Per fare questo test deve togliere alimentazione alla linea interessata e … niente, il gruppo come si sospettava non era funzionante, viene ridata corrente alla linea.

Test finito. Sarebbe bello? Non è così.

Iniziano i primi sintomi di un problema, i PC perdono connettività alla rete LAN e a quella Internet. La posta elettronica e i server applicativi non funzionano (ma la manca la rete quindi sembra normale). L ‘IT inizia ad indagare su un possibile problema di rete, brancola un pò nel buio, per ora l’unica certezza è che qualche dispositivo critico (uno switch ?) è stato “toccato” dallo sbalzo elettrico necessario per effettuare il test. Ma come è possibile questa cosa?
Alcune ipotesi :
1 – Assenza totale di documentazione attendibile –  nessuno infatti è stato un grado di mostrare un pezzo di carta “autorevole” a documentare il reale stato dell’arte dell’impianto elettrico. Cosa fosse realmente connesso a quale linea elettrica e sotto quale Gruppo di Continuità;
2 – Errore nel cablare le alimentazioni – l’errore nella fattispecie sembra doppio, oltre al clamoroso sbaglio di collegare l’alimentazione di uno o più dispositivi delicati su una linea errata, o comunque su una linea non “coperta” dalla normale politica di protezione, c’è anche il madornale errore di aver collegato entrambe le alimentazioni sulla stessa linea. I dispositivi di rete di fascia medio-alta o comunque di uso “corporate” hanno tutti appositamente 2 alimentazioni in modo che in caso di guasto di una delle due, l’altra possa continuare a mantenere in vita il device. Questo significa che, per ulteriore sicurezza, è bene collegarle su due linee differenti, in questo caso avrebbe evitato il problema.

Ritorniamo al disastro.

Si indaga su un problema di rete, a questo punto pare evidente che uno dei dispositivi si è riavviato, lo acclarano anche entrando nei vari device e consultando l’uptime, pochi minuti di uptime può significare solo una cosa.

Ora si aprono vari scenari :
– Lo switch potrebbe aver  perso le configurazioni tornando al default (sarebbe un disastro colossale in quanto non viene estratto il backup della configurazione del device (altro sbaglio) ;
– Le modifiche più recenti sullo switch non erano state salvate (wr mem) e quindi sono andate perse, la coppia di switch è disallineata o mancano rotte fondamentali. In questo caso il problema potrebbe essere meno grave ma richiederebbe un lavoro devastante per riallineare tutto senza documentazione.

Dalle verifiche approfondite però emerge che il network non ha subito “danni” a livello di configurazione. Tutto è allineato gli up-link sono su, ma ancora non funziona nulla.
Nella fattispecie non funzionano le risoluzioni dei nomi (DNS), non ci si autentica sui server in RDP, non c’è responsività nello sfogliare i DB.
Di peggio c’è che non ci si riesce a collegare nemmeno al vCenter di vmWare per verificare lo stato delle macchine virtuali e dei nodi.

La motivazione  ve la riassumo brevemente:

La perdita di corrente ha causato il riavvio crudo degli switch che compongono lo stack di core e degli switch in fibra che interconnettono i nodi vm-ware con gli storage. La fibra caduta ha reso “indisponibile” lo storage ai nodi del CED1 attivando il processo di HA verso i nodi del CED 2. Il fatto però che la fibra sia caduta ha provocato anche che lo storage presente nel CED1 non abbia più potuto dialogare con il suo alter-ego nel CED2, i due storage si parlano via fibra e in backup su rame per capire come procedere se uno si spegne o ha dei problemi, essendo indisponibili entrambe le connessioni lo storage si è trovato in una situazione di “inconsapevolezza” sul come procedere, nel gergo split-brain.

Questo split-brain si è manifestato quando però il processo di HA era già partito e quindi si era creata una situazione in cui alcune macchine erano presenti su entrambe i sites, su nodi diversi che non sapevano chi fosse quella giusta da accendere. E anche se lo avessero saputo gli storage, in split-brain non rilasciavano le risorse necessarie alle VM per funzionare.

Un freeze totale. Il caos.
Questa la punta dell’Iceberg di una giornata di non-ordinaria follia. Che ha portato un fermo dei sistemi di 10 ore. 5 delle quali passate ad indagare su di una problematica totalmente fuorviante.
Dieci ore di fermo sistemi che si sarebbero potute evitare semplicemente posizionando correttamente le alimentazioni o quantomeno avendo una documentazione coerente con la realtà tale da indurre gli addetti ai lavori a prendere determinate precauzioni prima di procedere con test elettrici.

L’articolo si è fatto lungo quindi rimando a un futuro post i dettagli sulla mitigazione e risoluzione del problema.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *