Benvenuti nel primo talk VUG meeting italiano
Veniamo adesso a noi con la prima track di oggi, quattro chiacchiere a tema cybersecurity. Non credo che ci sia bisogno di parlare di quanto siano importanti i backup nella vita di una infrastruttura anzi, mi piace pensare che siano quasi più importanti i backup dei dati stessi.
Ransomware.
Lo sapete, non possiamo parlare di cybersecurity senza toccare questo argomento. Non starò qui a spiegare cosa sia un ransomware, né di quale sia il vettore d’attacco più diffuso (via mail, remote access exploitation o assenza di patching).
Ho raccolto in questa slide tutti gli attacchi ransomware riportati nelle prime due settimane di febbraio: come vedete sono tutte aziende di un certo calibro che hanno fatto notizia, e come grandi realtà dispongono anche quasi certamente di una layered defense migliore rispetto a quella che può presentare una piccola o media impresa.
Perché dico questo?
Perché se è capitato a loro, può capitare a chiunque.
Perché non importa che tipo di azienda sei o quanto fatturi, sei comunque potenzialmente un bersaglio.
E questa è solo la punta dell’iceberg degli attacchi, ciò che ha fatto notizia.
E in caso di ransomware o comunque di una penetrazione nella rete da parte di thread actor, quali possono essere le soluzioni?
L’unica strada veramente sicura è il restore dal backup.
Come possiamo essere sicuri dell’affidabilità dei dati dopo aver subito un data breach? Come possiamo essere sicuri che non sia stato nascosto del codice latente pronto per una seconda encryption, oppure perché no, l’attacco invece che cancellare i nostri dati o criptarli e chiederci un riscatto dopo una exfiltration va a modificare i dati stessi? Cambiando i valori delle fatture, gli IBAN dei fornitori, o se siamo una struttura medica pensate quanti danni può fare se i dati dei pazienti vengono modificati. Anche semplicemente il solo gruppo sanguigno.
Ecco, in questi casi l’unica strada percorribile, possibile e sicura è quella di fare un ripristino del backup.
Fantascienza? Catastrofico?
No. In modo molto semplicistico, tutto questo può svolgersi in questo ordine.
Vediamo un esempio.
Arriva la classica mail con link malevolo: il dipendente che sta facendo altre mille cose insieme si distrae e ci clicca sopra ignorando l’avviso dell’antivirus. Si apre così una reverse remote shell sull’attaccante che adesso si presenta nella rete con quell’utente. Fa girare un Mimikatz che inizia a grabbare le credenziali in uso su quella postazione, avvia un ARP poisoning e fa partire un Responder per grabbare anche le credenziali che circolano nella rete e trova una multifunzione con accesso lasciato in default. Sfoglia la rubrica e qui dentro ci sono alcune credenziali per accedere a uno storage SMB, probabilmente ad uso scansioni. Magari il sistema non è patchato e sfruttando una vulnerabilità riesce a fare privilege escalation ottenendo utente System, nel caso di Windows, e da lì sfoglia su quel server tutto ciò che vuole. E nel frattempo l’attaccante ha stilato una lista degli user e password che sono girati sulla rete e magari qualcuna di queste è stata usata più volte per diversi servizi. Prova quindi a fare un bruteforce sul NAS e trova un utente che ha accesso alla cartella dei backup. E magari quell’utente è replicato e ha accesso per comodità anche al repository secondario dei backup. Game over.
Ripeto. Molto semplicistico, ma totalmente fattibile.
E cosa c’è di peggio di non avere un backup? Avere un backup a cui non puoi accedere. Tutto questo come si combatte? In vari modi, e alcuni di questi li andiamo a vedere.
Separazione dei ruoli.
Vige da sempre il principio del privilegio minimo: ossia ogni utente o processo quale sia, abbia solamente i privilegi minimi necessari per poter svolgere la sua mansione o la sua funzione. Non è pensabile, infatti, che l’utente utilizzato per l’accesso alla folder del backup repository sia anche amministratore dello stesso. Questo perché se è corretto che l’utente abbia i permessi di accesso alla folder, così non può valere per l’accesso alla console management.
O ancora peggio, che le credenziali per l’accesso al repository principale siano, per comodità, le stesse di quello secondario.
Altra cosa ancora, ricordiamoci sempre che stiamo parlando di PMI e quindi di strutture relativamente non troppo complesse. La macchina di Veeam va agganciata in dominio oppure no? Lo vediamo con la prossima track insieme a Marco.
Il mio consiglio, a meno di reali necessità, è quello di tenere la macchina Veeam fuori dominio, con credenziali complesse ovviamente differenti rispetto a quelle del resto della struttura. Così se per un malaugurato motivo vi forano un domain admin della struttura, non riescono ad accedere anche alla macchina Veeam.
Update policy
Vi chiedo, quando è stata l’ultima volta che avete verificato di essere allineati con gli aggiornamenti sui vostri backup repository, essi siano Windows o Linux o NAS?
Senza fare nomi, il mese scorso è uscita una vulnerabilità molto importante per un grosso produttore di NAS e molti device pubblicati sono risultati criptati. Questo nel caso di una zero day non avrebbe cambiato nulla, ma nel caso di una vulnerabilità già chiusa dal produttore avrebbe fatto la differenza.
È molto importante quindi avere una policy ben definita per gli aggiornamenti, che vanno pianificati ed eseguiti con le dovute attenzioni. Non sarebbe la prima volta che un update va rompere qualcosa.
Third party
Ho visto spesso macchine dedicate a Veeam che vengono pensate come un calderone su cui si possono installare applicativi di terze parti per i più disparati usi, da quelli di gestione licenze a quelli per il controllo della termoregolazione, visto che sono macchine generalmente scariche quando non stanno operando su un backup o su una replica.
Anche qui, bisogna fare attenzione perché ogni applicativo che andiamo a installare ha i suoi servizi con relative porte aperte in ascolto, e anche questi possono avere delle vulnerabilità. Ecco, è molto importante limitare questa pratica e disporre, e parliamo ancora una volta della suddivisione dei ruoli, di più VM dedicate ognuna al suo lavoro.
32110
Probabilmente la conoscevate diversa, come 3-2-1.
Veeam ha rivisto quella regola e da qualche anno consiglia invece un approccio 3-2-1-1-0, ovvero tre copie differenti di dati di backup, in due diversi tipi di storage, una copia di backup offsite e una copia offline o immutabile. Dopo parleremo anche di immutabile. Lo zero sta invece per zero errori in fase di reale ripristino con gli strumenti di test automatico presenti nella suite di Veeam Backup and Replication.
So che non tutte le PMI in Italia hanno a disposizione una banda in uscita capace di sostenere il backup in cloud di svariati tera, ma il cloud è sempre più importante e anche questo va valutato, soprattutto come soluzione di disaster recovery. Ovviamente i più conosciuti sono AWS e Microsoft, ma ricordo che nella community qualcuno aveva parlato anche di un’altra opzione, che se non ricordo male si chiama Wasabi, e ovviamente anche questa partner di Veeam. Interessante perché si parlava di 6$ a Tera al mese. Personalmente non l’ho ancora provato, anche perché l’ho letto giusto questo mese.
Encryption
E qui mi collego. Backup in cloud, ok. Ma li criptiamo? Sembra ovvio da dire, ma troppo spesso ci si dimentica di questo fattore. Salvare in cloud significa portare tutti i dati dell’azienda fuori dall’azienda. E se bucano il cloud o il vostro account e quindi hanno accesso ai backup?
L’encryption del backup è fondamentale così solo chi ha la password può accedere al contenuto. E anche qua, è fondamentale scegliere una password casuale molto strong per evitare che provino con brute force o trovare l’hash corrispondente tramite rainbow tables. Con questo secondo metodo una password di 14 caratteri può essere craccata in circa 3 minuti.
Ed è altrettanto importante salvare la password usata per l’encryption e magari non solo sul file server o sul PC, perché se vi beccate un ransomware e vi criptano il txt contenete la password, poi nemmeno voi accedete più ai vostri backup. Questo è molto importante. Ovvio, ma davvero importante.
Secure restore
Cosa è il secure restore?
È una funzionalità in fase di ripristino di Veeam che permette di scansionare la VM prima di ripristinarla, montando su un Windows Server, su cui è installato un motore di antivirus, lo storage come disco e facendo partire una scansione al fine di individuare codice malevolo, virus dormienti, timebomb. Insomma, si va a evitare che il rispristino di un server vada anche a ripristinare un virus già deployato,
Immutable backup
E parliamo adesso di immutable backup. Che cosa è?
Non è altro che avere un repository linux, primario o secondario che sia, che è formattato in XFS, così da avere a disposizione la deduplica e il fast clone, e questo ci permette di sfruttare una caratteristica nativa del sistema che è l’attributo “-i”, che fa sì che i “.vbk” e “.vib” presenti con quell’attributo non possano essere modificati o cancellati fino alla relativa data di scadenza.
Questo vuol dire che sia in caso di ransomware, sia per un’accidentale cancellazione di manutenzione, viene restituito un errore e quei file non vengono toccati. Ovviamente vale anche per le catene di backup, i full rimangono immutabili fino a che esistono dipendenze.
Generalmente si imposta una data di immutable backup inferiore rispetto a quella di retention, così da evitare che la pulizia dei backup non si blocchi.
Se non ricordo male è presente anche nella versione community.
Molto importante l’immutable come soluzione di backup secondario.
Harden repository
Restiamo in ambiente Linux: utilizzare un harden repository a differenza di un normale Linux repository è che non vengono salvate le credenziali all’interno della macchina Veeam, ma queste vengono usate solamente al primo accesso al repository.
Molto utile perché così non possono fare grab delle credenziali.
Veeam One
Una chicca magari a molti sconosciuta. In Veeam One è presente una funzionalità che va a fare detection di possibile attività ransomware in base all’utilizzo delle risorse della vm.
Accesso fisico
Abbiamo parlato di molti modi per proteggere la sicurezza dei backup, ma tutto questo cade se non proteggiamo anche l’aspetto fisico. Capita troppo spesso che macchine server o NAS sono posizionati dentro armadi rack con le chiavi dimenticate attaccate.
O anche semplicemente lasciare l’accesso alla ILO nel caso di HPE o alla iDRAC di Dell con le default password, o ancora peggio al controller raid. Basta entrare sul server per fare un wipe del raid.
Piano di recovery
È fondamentale avere un piano di recovery. Molto spesso mi capita di andare a fare incident response esterno in realtà che hanno subito un attacco e queste non hanno un piano per procedere con il ripristino, non sanno cosa gira sulla loro struttura, quanti server e dove.