Quando qualcosa va storto

Modulo 10: Restare al sicuro · Tempo di lettura: 11 minuti

Obiettivo della lezione: Dopo questa lezione Lei riconosce i segnali di un server compromesso, compie i primi passi senza distruggere prove o backup, sceglie tra ripulire e reinstallare, e sa quando deve notificare una violazione dei dati.

Concetti chiave: incidente, segnali, isolare, snapshot come prova, registro dell'incidente, reinstallazione, sostituire chiavi e password, backup pulito, obbligo di notifica delle violazioni dei dati (72 ore), Garante per la protezione dei dati personali, piano di emergenza

Riconoscere un incidente

Un'intrusione raramente si annuncia. Di solito si nota qualcosa di "strano". Segnali da prendere sul serio:

• Carico elevato senza motivo: il processore è costantemente al 100%, ad esempio a causa di un cryptominer. Con top o htop verifichi di quale processo si tratta e con quale utente gira.
• Processi o servizi sconosciuti: un programma con un nome strano, spesso in /tmp, /dev/shm o /var/tmp, oppure un servizio o un timer systemd che non ha creato Lei.
• Traffico in uscita anomalo: il Suo provider segnala che il Suo server invia spam o attacca altri server, oppure i grafici di rete nel pannello mostrano dei picchi.
• Nuovi utenti o nuove chiavi: una riga in ~/.ssh/authorized_keys che non conosce, un utente in /etc/passwd con UID 0, una nuova riga in /etc/sudoers.d/.
• File modificati: file PHP sconosciuti nel Suo sito web, una crontab modificata.
• Log scomparsi o vuoti: gli aggressori amano cancellare le proprie tracce.

Alcuni comandi per dare un'occhiata rapida:

anna@web1:~$ top -o %CPU
anna@web1:~$ sudo ss -tunap | grep ESTAB
anna@web1:~$ sudo last -n 20
anna@web1:~$ awk -F: '$3 == 0 {print $1}' /etc/passwd
anna@web1:~$ sudo find /etc/systemd/system /etc/cron* -newer /etc/hostname -type f
anna@web1:~$ for u in /root /home/*; do sudo cat $u/.ssh/authorized_keys 2>/dev/null; done

last mostra chi ha effettuato l'accesso e quando, la riga con awk elenca tutti gli account con UID 0 (dovrebbe esserci solo root), e la riga con find cerca unit e file cron più recenti di un file creato al momento dell'installazione.

Attenzione: su un server realmente compromesso anche questi comandi possono essere stati falsificati. La aiutano a sospettare qualcosa, non a dimostrare che è tutto pulito.

I primi passi: calma, isolare, documentare

La cosa più importante nei primi minuti è non cancellare nulla in preda al panico. Proceda in questo ordine.

1. Inizi un registro. Annoti su carta o sul Suo portatile (non sul server) che cosa vede, quando e che cosa fa. Le servirà in seguito per trovare la causa, per una notifica, una denuncia o la Sua assicurazione. Lo raccomanda anche il NCSC olandese.

2. Isoli il server. Impedisca che continui a fare danni (spam, attacchi, invio di dati all'esterno) senza spegnerlo:

• nel firewall del Suo provider (se presente) chiuda tutto tranne SSH dal Suo indirizzo; oppure
• faccia lo stesso sul server stesso, tramite la console;
• se non c'è altra soluzione: spenga il server dal pannello. In questo caso però perde il contenuto della memoria.

3. Crei uno snapshot. Uno snapshot nel pannello fissa lo stato attuale del server. È la Sua prova e la Sua fonte per scoprire in seguito come è entrato l'aggressore, anche se poi reinstalla il server.

4. Metta al sicuro i Suoi backup. Verifichi che i Suoi backup esterni al server siano ancora integri e faccia in modo che il server compromesso non possa più accedervi (ad esempio revocando la chiave di accesso del server allo spazio di backup). Gli aggressori cercano anche di cancellare o cifrare i backup.

Ripulire o reinstallare?

La risposta allettante è: eliminare il file sospetto, fermare il cryptominer, fatto. Ma Lei non sa che cos'altro abbia fatto un aggressore: una seconda backdoor, un programma modificato, una chiave aggiuntiva, un timer che ripristina tutto. Di un server su cui qualcuno ha avuto i privilegi di root non ci si può più fidare.

Il consiglio degli amministratori di sistema e anche del NCSC olandese è quindi: reinstallare i sistemi colpiti e ripristinare i dati da un backup che non sia a sua volta infetto. In concreto:

1. Una nuova installazione (reinstallazione dal pannello o un nuovo server).
2. Subito le basi di questo corso: aggiornamenti, utente normale con sudo, SSH con chiavi nuove, firewall (dal modulo 2 al modulo 5).
3. Reinstallare le Sue applicazioni da fonti ufficiali, preferibilmente con i Suoi file compose o i Suoi appunti (lezione 10.4).
4. Ripristinare i dati (database, upload) da un backup precedente all'incidente. Non ripristini alla cieca codice o configurazione: potrebbero contenere la backdoor. Esamini con occhio critico anche i dati ripristinati; un aggressore potrebbe essere stato dentro più a lungo di quanto pensi.
5. Chiudere la falla attraverso cui è entrato l'aggressore. Altrimenti succederà di nuovo. Lo snapshot del passo 3 aiuta nell'indagine.

Sostituire tutto ciò che può essere trapelato

Parta dal presupposto che tutto ciò che si trovava sul server sia nelle mani dell'aggressore:

• Chiavi SSH: rimuova ovunque le chiavi pubbliche che si trovavano sul server e crei nuove coppie di chiavi se sul server c'erano chiavi private.
• Password di database, pannelli di amministrazione e utenti della Sua applicazione.
• Chiavi API e token (posta, pagamenti, cloud storage, spazio di backup) presenti nei file .env e nella configurazione: revocarli presso il servizio e sostituirli.
• Certificati: la chiave privata del Suo certificato era sul server. Faccia revocare il certificato e ne richieda uno nuovo (con Let's Encrypt è rapido, lezione 7.3).

Notificare: il GDPR e altri

Se sul server c'erano dati personali (dati dei clienti, account, indirizzi email), potrebbe trattarsi di una violazione dei dati. Il GDPR (articolo 33) stabilisce che il titolare del trattamento notifica una violazione dei dati all'autorità di controllo senza ingiustificato ritardo e, ove possibile, entro 72 ore dal momento in cui ne è venuto a conoscenza. In Italia si tratta del Garante per la protezione dei dati personali, a cui la notifica si effettua tramite la procedura online. Alcuni punti importanti:

• la notifica non è necessaria se è improbabile che la violazione comporti un rischio per gli interessati; nel dubbio, notifichi;
• se non dispone ancora di tutte le informazioni, notifichi comunque entro 72 ore e integri in seguito;
• le persone i cui dati sono trapelati vanno informate se per loro c'è un rischio elevato;
• ogni violazione dei dati va documentata in un registro apposito, anche se non deve notificarla.

Se gestisce il server per conto di un cliente, di solito Lei è responsabile del trattamento: in tal caso deve informare il cliente (il titolare del trattamento) senza ingiustificato ritardo, affinché possa effettuare la notifica. Questa lezione non costituisce consulenza legale; in caso di dubbio consulti il sito del Garante.

Inoltre: segnali al Suo provider gli abusi commessi dal Suo server (spesso li ha già notati) e, in caso di attacco grave, sporga denuncia alla Polizia Postale. Se la Sua organizzazione rientra nell'ambito del decreto legislativo 4 settembre 2024, n. 138 (decreto NIS, recepimento della NIS2), valgono termini di notifica specifici e più brevi.

Prepararsi: il piano di emergenza

Un incidente capita sempre nel momento meno opportuno. Ciò che ha predisposto in anticipo Le fa risparmiare ore:

• Sappia come raggiungere la console e il pulsante degli snapshot del Suo provider, e conservi le credenziali del pannello (con verifica in due passaggi) in un luogo esterno al server.
• Sappia dove si trovano i Suoi backup, come ripristinarli e che funzionano (lezione 8.2).
• Tenga un elenco di tutti i segreti presenti sul server, così sa che cosa deve sostituire.
• Tenga un elenco di contatti: il Suo provider, chi altro deve essere informato sul server (cliente, collega) e i recapiti per una notifica di violazione dei dati.

Nella pratica

Nella schermata VPS di WebOké trova la console, gli snapshot, i backup e il pulsante per reinstallare; presso altri provider hanno nomi simili (console o VNC, snapshot, rescue, reinstall). Questo corso è un percorso di autoapprendimento: nessuno controlla il Suo server e nessuno risolve un incidente al posto Suo. Proprio per questo un piano di emergenza che può eseguire da solo è così importante.

Riepilogo

• Segnali: carico inspiegabile, processi, servizi o chiavi sconosciuti, traffico in uscita anomalo, file e log modificati o scomparsi.
• Primi passi: tenere un registro, isolare il server, creare uno snapshot come prova, mettere al sicuro i backup.
• Un server su cui qualcuno ha avuto root non si ripulisce, si reinstalla; si ripristinano i dati da un backup pulito e si chiude la falla.
• Sostituisca tutte le chiavi, le password, i token e i certificati che si trovavano sul server.
• Dati personali coinvolti? Una violazione dei dati va notificata al Garante, ove possibile entro 72 ore, e ogni violazione va documentata.

Quiz

Esercizio

Esercizio O10.3: Il Suo piano di emergenza su una sola pagina. Scriva per il Suo server un piano di emergenza di al massimo un foglio A4: come accede al pannello, alla console e agli snapshot; dove si trovano i Suoi backup e come li ripristina; quali segreti si trovano sul server; chi deve informare (e se in caso di violazione dei dati deve effettuare una notifica); e quali sono i primi cinque passi che compie se sospetta un'intrusione. Conservi il piano al di fuori del server.

Per approfondire

• Nessun accesso alla sua VPS: cosa fare?
• Snapshot e backup del suo VPS
• Collegare una ISO propria o reinstallare la sua VPS
• NCSC olandese, Gehackt, wat nu? (fonte olandese, in lingua olandese): https://www.ncsc.nl/incidenten-en-herstellen/gehackt-wat-nu
• Garante per la protezione dei dati personali, violazioni dei dati personali (data breach): https://www.garanteprivacy.it/