Ultimamente si sente sempre più spesso parlare di CryptoLocker et simila. La modalità è sempre la stessa: un malware crittografa i dati dell'utente rendendoli inservibili salvo corrispondere un contributo e ricevere la chiave di sblocco. Si tratta, sostanzialmente, di una forma di estorsione informatica purtroppo estremamente comune.
Come possiamo proteggerci o limitare i danni?
Partiamo con il dire che le nostre azioni non possono che essere preventive perchè, una volta crittografati i file, la questione si complica e diventa molto difficile uscirne illesi.
Prendiamo uno scenario tipico: azienda con N utenti in Dominio AD, percorsi di rete con dischi mappati e file in comune.
In uno scenario di questo tipo, valgono le regole generali di buon senso:
1. Un utente è un utente, non un amministratore (anche della sua macchina).
L'ABC della sicurezza informatica detta, in testa, la regola base per cui un utente è solo un utente, non un amministratore di sistema. Sarà più scomodo, ma è così che funziona. Il metodo più rapido per farsi male è lasciare agli utenti la possibilità di installarsi ogni tipo di programma in maniera anarchica ed incontrollata. In questo specifico caso, tuttavia, è bene precisare che CryptoLocker agisce sulla possibilità o meno dell'utente di accedere ai file, anche senza alcuna permission escalation. Quindi questa regola rimane in testa, ma la sua efficacia in questo scenario è abbastanza marginale.
2. Limitare l'accesso alle risorse strettamente indispensabili
Se non vi sono motivi specifici affinchè il magazziniere debba accedere ai dati amministrativi, questa possibilità deve essere inibita. Se un utente, facente parte di un'Unità Organizzativa o di un Gruppo, non ha necessità di scrivere (ma solo di leggere) in un percorso solitamente utilizzato da altri utenti, limitarne i permessi. Questi accorgimenti ci consentiranno di limitare i danni ad aree relativamente circoscritte.
3. Limitare l'esecuzione dei file non necessari
File eseguibili, script e file pericolosi spesso vengono erroneamente accettati dai sistemi di frontend. Nel caso delle varianti di CryptoLocker, ho assistito principalmente alla diffusione di file .scr. E' opportuno che i MailServer impediscano la ricezione di email contenenti allegati di questo tipo (anche all'interno di file compressi).
Un altro ottimo modo per gestire l'esecuzione di file è dotare la struttura di EndPoint Protection in grado di inibire l'esecuzione di allegati pericolosi, a prescindere dal contenuto malevolo o meno, direttamente sui client. Valutare l'investimento di un Antivirus che abbia anche funzionalità di EndPoint Protection non è mai una cattiva idea.
Ecco un esempio di blocco di allegati pericolosi su un mailserver Linux Postfix con controllo dei file compressi tramite ClamAV:
Aggiungere il Reject per gli allegati con estensione specifica:
/etc/postfix/mime_header_checks (aggiungere il riferimento a main.cf)
/name=[^>]*\.(bat|com|exe|dll|vbs|scr)/ REJECT tipo di allegato eseguibile non consentito
Aggiungere il blocco per gli allegati contenuti in file compressi, anche crittografati (ma con nome in chiaro):
/var/lib/clamav/extfile.rmd
Allegato.con.Estensione.non.consentita.1a:0:.*\.(bat|com|exe|dll|vbs|scr)$:*:*:*:*:*:*
Allegato.con.Estensione.non.consentita.1b:1:.*\.(bat|com|exe|dll|vbs|scr)$:*:*:*:*:*:*
copiare extfile.rmd in extfile.zmd e riavviare clamd e postfix
4. Centralizzare i dati su FileServer
Ovviamente, gli utenti devono lavorare su FileServer e mai in locale. Per svariati motivi che spaziano dalla maggiore ridondanza hardware che un Server possiede ad una facilità di gestione dei dati stessi. Sembra scontato, ma non lo è. In caso di utenti recidivi, è sempre possibile mappare le cartelle di profilo direttamente sul proprio Server.
4. Backup, backup e backup
Inutile soffermarsi oltre, un backup salva la situazione. Sempre. E' necessario, tuttavia, ricordarsi che CryptoLocker può cercare dischi connessi, quindi i backup devono essere fatti correttamente, ovvero su supporti non accessibili dagli utenti (ma solo dai sistemi di backup). Possibilmente devono andare offline, su supporti a scrittura sequenziale e locati altrove. A volte questo è l'unico modo per recuperare un file crittografato. Perderemo qualche ora di lavoro, ma nessuno si lamenterà conoscendo l'alternativa: perdere definitivamente il file.
Ad oggi le varianti in grado di leggere i dati dai dischi di rete mappati e crittografarne il contenuto sono abbastanza poco diffuse, ma esistono ed è necessario tenerne conto. Molto più frequente, invece, è la possibilità che Desktop, Documenti e cartelle legate al profilo utente vengano crittografate a prescindere dalla locazione fisica (se sul disco locale o su un FileServer in rete).
5. ShadowCopy
Questo è indubbiamente il metodo più rapido per ripristinare il contenuto delle directory compromesse. Abilitando l'utilizzo delle ShadowCopy sui FileServer (ma anche sui client, se volete), avremo la possibilità di ripristinare una directory in una condizione precedente.
Durante la fase di configurazione delle copie Shadow, visto anche il basso impatto computazionale anche su FileServer relativamente carichi, potrebbe essere opportuno incrementare il numero di SnapShot giornalieri. Normalmente io ne pianifico due o tre, in base al contenuto del volume.
6. Una macchina compromessa, è una macchina compromessa
Non perdete tempo a recuperare la situazione, una macchina compromessa può essere solo formattata. Punto. Ogni altra operazione crea l'illusione di offrire una strada più rapida verso il ripristino delle funzionalità della macchina stessa, ma il più delle volte si dimostra essere una lotta del tutto inutile e "donchishiottesca".
In bocca al lupo, e ricordatevi la premessa: queste sono azioni preventive. Se siete giunti qui perchè avete già il problema, questa pagina non vi sarà d'aiuto. Se siete giunti qui, invece, per un approfondimento, allora questo è il momento giusto (se necessario) per sistemare qualche aspetto dell'infrastruttura IT. Non dopo.
