Recensioni, Sicurezza Informatica

Tre semplici regole per una posta sicura

Oggi continuo a battere la lingua dove dolgono i denti di moltissimi Sistemisti o Consulenti Informatici, per lo più aziendali : la corrispondenza malevola.

Si, lo so, ho già parlato dei ransomware, dei virus, degli exploit. Ma questo tema ce l’ho da un po sulla punta della lingua e mi sento di ribadire il concetto.

Quando si tratta di infezioni, exploit o violazioni che si subiscono dall’esterno, nel 90% dei casi questi provengono da una e-mail, ora vi proporrò 3 semplici regole che, se seguite, possono mettervi al sicuro in buona parte dei casi a rischio:

1 – 9 volte su 10 è colpa Tua quindi attento : Quando ricevete delle mail solitamente queste portano con sé degli allegati o dei link esterni, e proprio lì si nascondono le infezioni. Ora, potete lavorare nell’azienda più protetta e all’avanguardia di questo mondo, ma l’ultimo click rimane sempre il vostro e di conseguenza anche la responsabilità per le conseguenze. Quando aprite degli allegati o dei link che ricevete da mittenti esterni voi state consentendo a questi di fare ingresso nella vostra Azienda, vi state quindi assumendo la responsabilità per loro. E’ come se riceveste la visita di un fornitore o consulente che di persona viene a trovarvi , voi garantite per lui, perché siete voi che lo state portato in azienda, se questo entra e si mette a rubare o a fare danni, prima o poi anche voi ne risponderete, e non il Responsabile della sicurezza o della sorveglianza (quelli eventualmente risponderanno nella misura in cui non hanno funzionato eventuali procedure di difesa) . Quindi quando aprite allegati di terzi, se uno di questi conterrà qualcosa di malevolo, a prescindere dall’Ufficio Informatico : la colpa sarà vostra! Che poi a livello aziendale veniate puniti o meno non è dato saperlo, ma il concetto è quello. Esempio sensibile da portafoglio : caso limite, un ransomware che attacca il server in cui giacciono i Data Base del gestionale. Il restore dal back-up del server richiede dalle 2 alle 4 ore. Stiamo su numeri da piccola azienda. 25 persone ferme per 4 ore ( una media di 17,00 € costo azienda/orario a persona) = danno all’azienda pari a 1700,00 € questo è quanto vi potrebbe costare una svista del genere.

2 – Leggete i mittenti : E’ importante sapere chi manda una mail, perché si è a conoscenza dell’interlocutore con cui sta parlando. Se due persone si conoscono non è di prassi verificare l’identità, ma se due persone non si conoscono forse è il caso di porsi la fatidica domandina : “Ma questo chi è?”.  Se non altro perché in ambito aziendale vige la riservatezza delle informazioni, e sarebbe poco simpatico che a seguito di un problema emergesse che un utente facesse scambio di informazioni aziendali con mittenti sconosciuti.
Poniamo sempre un caso limite, stiamo passeggiando per la città e ad un certo punto uno sconosciuto ci ferma, ci dice “Ciao sono Tizio Caio, tieni questa scatola è per te, mi raccomando aprila e guardaci dentro”. e senza aggiungere altro se ne va. Ora, voi cosa fareste? Ve la porreste la fatidica domandina no? Secondo me sì, e  col cavolo che ficchereste il naso dentro, coi tempi che corrono potrebbe contenere una bomba! Ma allora perché, quando ricevete una mail da mittenti tipo dfiour839kd@loi98imx.pl con contenuto “Ehi ciao, amico. Ti meto in allegato la tua conto corrente mensile” (l’ortografia è voluta) voi aprite l’allegato? Se ogni allegato avesse contenuto una bomba oggi saremmo sterminati. O nel migliore dei casi… senza soldi (vedi punto 1).

3 – Allegati – NO OFFICE!!! : Questa regola è la più violata in assoluto. “Driiin! Ciao Daniele, ascolta ho il desktop che si sta smaterializzando, c’è una enorme scritta “VIRUS” che si sta espandendo, ma io NON SONO ANDATA SU SITI PORNO, ho solo aperto una fattura dell’Enel”!
Vai a verificare i log di sistema e vedi che la “Fattura dell’Enel” è un file Excel con tanto di macro che all’apertura va a chiamare un BOT e  a scaricarsi codice malevolo che successivamente installa sulla macchina target. Lasciamo perdere quest’ultima parte e lasciamo perdere il fatto che l’Enel non manda le fatture via mail, ma bensì manda la mail per scaricarle dal sito, ma nel 2017 chi caspita manda le fatture in Excel? Risposta NESSUNO!Ne in Excel ne in Word, ne in altri formati che non siano il .pdf o il .tif in casi remoti. La motivazione è anche abbastanza logica, mandare una fattura in Excel è come scrivere il conto del ristorante a matita e poi consegnarlo al tavolo con tanto di gomma per cancellare, sono file che possono essere aperti, modificati, manipolati con facilità. Per carità anche i .pdf possono essere modificati (con meno facilità) infatti per quello che hanno inventato le PEC, ma oltre all’inopportuno utilizzo di questi file per quello scopo specifico, c’è anche il fatto che file del genere sono, per loro natura, utilizzati per occultare Macro e codice malevolo eseguibile. Non aprite allegati di Office da mittenti esterni se non siete sicuri al 100%, e non apriteli MAI se vengono presentati come preventivi o fatture, anche se arrivano da mittenti conosciuti, spesso infatti vengono diffusi virus che spediscono e-mail dalle caselle di posta di vostri contatti, in modo da ingannarvi sfruttando la “fiducia” riportata nei mittenti noti. Non basta, valutate sempre il contenuto delle conversazioni, e se non vi aspettate una allegato non apritelo. A volte è meglio pagare in ritardo una fattura piuttosto che aprirne una falsa e generare un danno economico.

Come vi avevo preannunciato non sono 3 regole da professionisti, non serve avere una laurea per poterle mettere in pratica e quindi non occorre essere utenti esperti per potersi riparare da questo genere di “attacco”.

Sopratutto non costa nulla fare attenzione, o se vogliamo essere pignoli, costa poco tempo, magari gestiremo una mail in 11 secondi anziché 10… ma in prospettiva il risparmio economico sarà notevole in caso di “scampato pericolo”.

Recensioni, Sicurezza Informatica

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.