I comandi killer di Linux che distruggono il sistema: ecco come evitarli (davvero!)

L’amministrazione dei sistemi Linux richiede attenzione, competenza e una buona dose di prudenza. Esistono infatti comandi distruttivi che, se eseguiti con privilegi elevati, possono compromettere in modo irreversibile l’intero sistema operativo.

Negli ultimi anni, le distribuzioni Linux immutabili hanno guadagnato popolarità per la loro promessa di maggiore stabilità, sicurezza e ripristinabilità. Sistemi come Fedora Silverblue, openSUSE MicroOS, Vanilla OS e NixOS introducono un nuovo modus operandi nel quale il filesystem di base è “read-only” e aggiornabile in modo atomico, riducendo drasticamente il rischio di corruzione del sistema.

Gli aggiornamenti atomici sono un meccanismo con cui le distro applicano modifiche (come aggiornamenti di sistema) in modo “tutto-o-niente“: o l’aggiornamento va a buon fine in ogni sua parte, oppure viene completamente annullato senza alterare lo stato precedente.

La domanda, però, sorge spontanea: un sistema immutabile è davvero in grado di resistere a comandi distruttivi? La risposta, seppur sfumata, è: no, non completamente. Analizziamo il perché.

Il mito della “invulnerabilità” delle distribuzioni Linux immutabili

Molti utenti credono che l’immutabilità protegga il sistema da qualsiasi comando distruttivo. In realtà, le aree più sensibili del sistema sono montate in modalità scrivibile, e questo lascia spazio ad attacchi o errori umani anche gravi. Sebbene un sistema immutabile possa bloccare la cancellazione di alcune aree, altre sono vulnerabili: quindi, anche se in alcuni casi il sistema resta avviabile, può presentarsi un’ampia corruzione dei dati memorizzati.

Il comando più pericoloso in assoluto: sudo rm -rf /

Di seguito alcuni comandi noti per la loro capacità di distruggere un sistema operativo se eseguiti con sudo o come root:

sudo rm -rf / --no-preserve-root Cancella ricorsivamente tutto il contenuto del filesystem a partire dalla root /, ignorando la protezione normalmente applicata da rm per impedire danni accidentali. È il “classico” comando autodistruttivo di Linux. Anche directory critiche come /etc, /bin, /boot, /home, /dev, /proc e /sys sono generalmente eliminate, con conseguenze catastrofiche.

Il comando sudo può essere eventualmente sostituito con pkexec, parte del pacchetto PolicyKit (polkit), a seconda dell’ambiente in cui ci si trova. Può essere utilizzato per bypassare eventuali restrizioni in essere su sudo: risulta quindi potenzialmente ancora più distruttivo.

Esiste una versione più “blanda” del comando, ovvero sudo rm -rf /* (si noti l’asterisco finale) che evita la comparsa della conferma di cancellazione ed elimina tutto all’interno della root /, cioè tutte le directory come /bin, /etc, /home, ecc. Non tenta però di rimuovere la root / stessa, né tocca file “nascosti” come /.bashrc. Non date quindi credito a chi dice che i due comandi sono equivalenti, perché non lo sono affatto.

Formattazione del disco e scrittura di zeri

Il comando mkfs.ext4 /dev/sda porta alla formattazione dell’intera partizione o disco specificati, cancellando file system, dati, partizioni e strutture di boot. Un errore o un abuso di questo comando può rendere inaccessibile non solo il sistema operativo ma anche eventuali backup locali.

Nel novero dei comandi Linux più pericolosi non è possibile non citare il seguente:

dd if=/dev/zero of=/dev/sda bs=1M

Pone in essere una cancellazione irreversibile dei dati, scrivendo automaticamente zeri su tutto il disco e sovrascrivendo completamente il suo contenuto. Nessun tool di recupero può ripristinare dati sovrascritti con zeri.

Revoca di tutti i permessi a livello di file system

Il sistema di gestione dei permessi è essenziale per qualunque sistema operativo. L’apparentemente semplice comando chmod -R 000 / revoca tutti i permessi di accesso dalla directory root in giù. Nessun processo, utente o sistema sarà più in grado di leggere o eseguire file.

Il sistema diventa così del tutto inutilizzabile. Anche un ripristino dei permessi potrebbe non essere banale senza accesso da un’installazione live della distribuzione Linux.

Come un malintenzionato può causare danni

Ovviamente non è affatto facile che sul sistema Linux vada in esecuzione uno dei comandi descritti in precedenza. Come abbiamo accennato in precedenza, previa creazione di un backup o di uno snapshot della macchina virtuale all’interno di una soluzione per la virtualizzazione, si può utilizzarli ad esempio per verificare la “solidità” di una distribuzione immutabile.

Nella totalità dei casi (ne parliamo più avanti), almeno ad oggi, resterete delusi perché la distribuzione immutabile offrirà soltanto una protezione parziale rispetto ai comandi più distruttivi.

Attenzione comunque perché un utente malevolo o uno script compromesso possono sfruttare tecniche di social engineering per convincere le vittime a eseguire comandi dannosi mascherati da soluzioni utili. Non esegue mai comandi che abbinano l’uso di curl con l’esecuzione di uno script da bash. Esempio: curl URL_REMOTO/script.sh | bash O almeno non fatelo mai prima di esservi accertati dell’identità e del contenuto dello script (basta aprire l’URL facente riferimento al file .sh con un browser Web).

Ancora, un file .desktop, .deb, o .AppImage contenente codice distruttivo, se eseguito con fiducia dall’utente, può ottenere privilegi elevati tramite pkexec, sudo o vulnerabilità nei file .policy.

Infine, un attaccante che ottiene accesso root può configurare un’attività programmata (cron, systemd timer, at) che cancella o danneggia il sistema a distanza di ore o giorni, rendendo difficile risalire alla causa.

Limitare l’uso di sudo e pkexec: controlli granulari e riduzione della superficie d’attacco

L’elevazione dei privilegi tramite sudo e pkexec rappresenta uno dei vettori principali per l’esecuzione di comandi potenzialmente distruttivi su Linux. È quindi fondamentale implementare politiche rigorose di controllo degli accessi per limitare le possibilità di abuso, riducendo così la superficie d’attacco e minimizzando il rischio di incidenti accidentali o malevoli.

L’assegnazione indiscriminata di privilegi tramite direttive come ALL=(ALL:ALL) ALL nel file /etc/sudoers o similari, espone il sistema a rischi elevati e deve essere sempre evitata. Questa configurazione consente all’utente di eseguire qualsiasi comando come root senza limitazioni, favorendo potenziali abusi.

Applicare il principio del minimo privilegio: utilizzare la directory /etc/sudoers.d/ per definire policy granulari, limitando gli utenti o gruppi a un insieme ristretto di comandi necessari al loro ruolo operativo.

È inoltre preferibile abilitare il logging dettagliato degli accessi sudo con strumenti come sudo_logsrvd o integrare i log con sistemi SIEM (Security Information and Event Management) per individuare comportamenti anomali tempestivamente.

Se il sistema o le applicazioni non richiedono pkexec, è buona pratica limitarne l’accesso o disabilitarlo temporaneamente. Un modo semplice è modificare i permessi dell’eseguibile:

chmod 750 /usr/bin/pkexec
chown root:admin /usr/bin/pkexec

In questo modo, ad esempio, solo gli utenti del gruppo admin possono eseguire pkexec. Alternativamente, se non serve, si può rinominare temporaneamente o rimuovere l’eseguibile:

mv /usr/bin/pkexec /usr/bin/pkexec.disabled

Ci sono poi anche altri modi per procedere, ad esempio modificando o aggiungendo policy “ad hoc” in modo da richiedere l’autenticazione o negare l’accesso a utenti o gruppi specifici per determinate azioni.

I container sono ideali per le distro immutabili ma non offrono protezione totale

Molte distribuzioni Linux immutabili integrano o incoraggiano l’uso di tecnologie di containerizzazione per l’installazione e l’esecuzione delle applicazioni. L’approccio è parte integrante della filosofia “immutabile”: mantenere il sistema base pulito, stabile e aggiornabile, mentre le app sono isolate in ambienti controllati e modificabili.

L’uso di container contribuisce a evitare la “deriva di sistema” dovuta a pacchetti installati direttamente sulla root, aiuta a separare applicazioni e sistema operativo, permette rollback sicuri (il sistema può essere riportato a uno snapshot, senza interferenze da pacchetti applicativi).

Alcune distribuzioni immutabili offrono comandi interni per aprire una shell sul sistema host da un ambiente containerizzato: in questo caso, se si eseguono i comandi distruttivi riportati in precedenza, l’effetto sarà generalmente devastante e si riverbererà sull’intero sistema (di solito anche sulla partizione di boot/partizione di sistema EFI, Extensible Firmware Interface).