Comandi pericolosi del terminale Linux da evitare

Perché alcuni comandi Linux sono pericolosi

Nel terminale Linux il problema non è quasi mai il comando in sé, ma il contesto in cui viene eseguito. Un singolo carattere sbagliato, una variabile vuota, un percorso invertito o un comando lanciato con privilegi elevati possono cancellare dati, bloccare servizi o compromettere un server intero. Per questo i comandi davvero pericolosi non sono solo quelli “distruttivi” per definizione: spesso sono quelli che sembrano innocui, ma diventano devastanti se usati con distrazione.

La regola pratica è semplice: prima verifica, poi agisci. Se un comando scrive, cancella, sovrascrive o modifica in massa, chiediti sempre cosa succede se il percorso è sbagliato, se la variabile è vuota o se il file di destinazione esiste già. Su un server di produzione, questo controllo vale più di qualsiasi automatismo.

I comandi più rischiosi da evitare o usare solo con cautela

rm -rf

È il simbolo classico del pericolo, ma anche uno strumento legittimo se usato con attenzione. Il rischio è enorme perché cancella directory e contenuti senza chiedere conferma. Un errore come rm -rf /var/www al posto di rm -rf /var/www/site-old può distruggere un sito in pochi secondi.

Il pericolo aumenta quando si usano variabili non controllate:

rm -rf "$DIR"

Se $DIR è vuota o contiene un valore inatteso, il comando può colpire il posto sbagliato. Prima di cancellare, fai sempre un controllo visivo del percorso con:

printf '%s
' "$DIR"

e, se possibile, esegui prima una simulazione con ls o find.

dd

dd è uno dei comandi più pericolosi in assoluto perché scrive a basso livello su dischi e dispositivi. Un solo parametro invertito può sovrascrivere un disco intero, rendendo il recupero difficile o impossibile. Il classico errore è confondere input e output:

dd if=/dev/sda of=backup.img

Se inverti i valori o selezioni il device sbagliato, perdi i dati in modo irreversibile. Prima di usarlo, identifica sempre il disco con strumenti come lsblk o blkid e verifica tre volte il nome del device. Se hai un’alternativa più sicura, usala.

mkfs e comandi di formattazione

I comandi come mkfs.ext4, mkfs.xfs e simili formattano una partizione. Sono utili solo quando sai esattamente quale volume stai preparando. Se lanciato sul disco sbagliato, il comando cancella la struttura del filesystem e rende i dati non accessibili.

Prima di formattare, controlla il mapping dei dischi e smonta eventuali mount point. Non fidarti mai del nome “simile” o del fatto che il device sia “quello giusto quasi sicuramente”.

> e >> usati male

La redirezione di output sembra banale, ma può svuotare file importanti in un attimo. Un esempio classico è:

> /etc/hosts

Questo comando crea o svuota il file, lasciandolo vuoto. Anche un refuso in un comando più lungo può distruggere un file di configurazione o un log fondamentale. Quando devi modificare file di sistema, usa editor o strumenti che mostrino chiaramente cosa stai cambiando.

chmod -R 777

Non cancella dati, ma può compromettere seriamente la sicurezza. Dare permessi troppo ampi in modo ricorsivo espone file e directory a modifiche non previste, esecuzione di script malevoli e escalation di problemi. Su server web è un errore frequente, spesso fatto per “far funzionare tutto subito”.

È una soluzione sbagliata quasi sempre. Meglio individuare il proprietario corretto, il gruppo corretto e i permessi minimi necessari. In molti casi bastano 755 per directory e 644 per file, ma dipende dal caso d’uso.

chown -R su percorsi ampi

Il cambio proprietario ricorsivo è utile, ma se applicato alla radice sbagliata può alterare ownership di migliaia di file, rompere servizi e impedire l’avvio di applicazioni. Per esempio, un chown -R www-data:www-data / è disastroso. Anche un percorso troppo ampio può rendere inutilizzabili home directory, maildir o cache.

Prima di applicarlo, restringi il target al minimo indispensabile e controlla con find quali file verranno toccati.

curl | bash e wget | sh

Questa è una delle abitudini più rischiose nel mondo Linux. Scaricare uno script e pipearlo direttamente a una shell significa eseguirlo senza verifica reale. Se il repository è compromesso, se il contenuto è cambiato o se il download viene intercettato, stai lanciando codice esterno con i tuoi privilegi.

La procedura più sicura è separare download e controllo:

1. scarica lo script;
2. leggilo;
3. verifica firma o checksum;
4. eseguilo solo se è attendibile.

Se non puoi verificare il contenuto, non eseguirlo in produzione.

sudo su e sessioni root prolungate

Passare a root per comodità aumenta il rischio di errori distruttivi. Quando tutto il terminale gira come amministratore, un comando sbagliato colpisce subito il sistema. È meglio usare sudo solo per i singoli comandi necessari, così limiti il raggio d’azione degli errori.

Su server condivisi o in ambienti di produzione, mantenere il minimo privilegio è una misura tecnica e operativa, non solo una buona pratica.

kill -9 usato come prima scelta

kill -9 forza la chiusura immediata di un processo senza lasciargli il tempo di pulire file temporanei, liberare lock o scrivere dati in coda. È una soluzione estrema, non il primo tentativo. Usarlo su database, server web o processi di backup può lasciare dati incoerenti o file corrotti.

Prima prova un segnale più gentile, come kill o kill -TERM, e controlla se il processo termina correttamente.

find ... -delete

Molto utile, molto pericoloso. Un filtro sbagliato può eliminare file critici in massa. Il problema è che find agisce esattamente su ciò che gli dici, non su ciò che intendi. Se il pattern è troppo largo, il danno è immediato.

Prima esegui sempre la stessa ricerca senza -delete, per vedere cosa verrebbe toccato. Solo dopo, e con il risultato verificato, valuta la cancellazione.

tar con percorsi errati

tar è sicuro solo se sai dove stai estraendo. Un archivio malevolo o un comando lanciato nella directory sbagliata può sovrascrivere file esistenti. Anche l’estrazione con percorsi assoluti o con .. può portare a scritture fuori dalla directory prevista.

Controlla sempre il contenuto dell’archivio prima dell’estrazione e usa una directory temporanea quando possibile. Se devi ripristinare un backup, meglio estrarre in un path isolato e verificare prima di sostituire i file in produzione.

crontab -r

È un comando piccolo, ma il suo effetto è immediato: cancella tutti i cron dell’utente. Se il sistema dipende da job periodici per backup, pulizia log, sincronizzazioni o task applicativi, puoi causare un blocco operativo senza accorgertene subito.

Prima di rimuovere un cron, esporta il contenuto con crontab -l e salvalo in un file. Così hai un rollback semplice e rapido.

Errori comuni che trasformano un comando normale in un disastro

Molti incidenti non nascono da un comando “malvagio”, ma da errori di contesto. I casi più tipici sono questi:

• variabili vuote o non inizializzate;
• percorsi copiati male con slash mancanti o di troppo;
• uso di wildcard troppo ampi come *;
• esecuzione con privilegi elevati senza controllo;
• confusione tra ambiente di test e produzione;
• comandi lanciati in directory diverse da quelle previste.

Per esempio, rm -rf * in una directory sbagliata è una delle cause più frequenti di perdita dati. Anche mv * /destinazione può creare problemi se la destinazione non è quella attesa o se include file già esistenti. La regola migliore è lavorare sempre con percorsi espliciti e verificabili.

Abitudini sicure da adottare ogni volta

Ci sono alcune pratiche semplici che riducono drasticamente il rischio:

1. controlla il percorso con pwd prima di operazioni distruttive;
2. usa ls o find per vedere cosa toccherà il comando;
3. preferisci comandi che chiedono conferma o modalità interattiva quando disponibili;
4. fai backup prima di modifiche ampie;
5. lavora con privilegi minimi e usa sudo solo quando serve;
6. se un comando agisce su più file, prova prima su un campione ristretto.

Un’abitudine molto utile è l’uso di alias protettivi per alcuni comandi, ad esempio per evitare cancellazioni accidentali. Non è una difesa assoluta, ma aiuta a fermare l’errore impulsivo. In ambienti di produzione, però, l’alias non sostituisce la disciplina operativa.

Alternative più sicure ai comandi pericolosi

Quando possibile, scegli strumenti meno aggressivi o modalità più controllate:

• al posto di cancellare subito, verifica con ls, find o du;
• al posto di rm -rf, valuta spostamento in una cartella di quarantena o cestino operativo;
• al posto di curl | bash, scarica e ispeziona il file;
• al posto di kill -9, prova prima un arresto pulito;
• al posto di chmod -R 777, correggi proprietario e permessi minimi necessari.

In molti casi la soluzione corretta non è “fare più in fretta”, ma fare un controllo in più prima di premere Invio. Questo vale soprattutto su VPS, server web, database e macchine con dati non replicati.

Una regola pratica per non sbagliare

Se un comando può cancellare, sovrascrivere o cambiare massa di file, eseguilo solo dopo aver verificato il target, fatto un backup e capito come tornare indietro.

Questa regola sembra banale, ma è quella che salva più server di qualsiasi script. Il terminale premia precisione, non velocità cieca. Un sysadmin esperto non è quello che digita più comandi, ma quello che sa fermarsi un secondo prima del danno.

Checklist finale

• Ho verificato il percorso e l’oggetto del comando.
• Ho capito se il comando scrive, cancella o modifica in massa.
• Ho una copia di backup o un piano di rollback.
• Ho provato prima su un percorso limitato o in test.
• Non sto eseguendo codice esterno senza averlo letto o verificato.

Un terminale sicuro non nasce da divieti assoluti, ma da controlli ripetibili. I comandi pericolosi esistono, ma il vero rischio è usarli senza metodo.