Come cancellare lo spazio libero su disco in Linux?

Avviso: L'hardware disco/SSD moderno e i file system moderni possono eliminare i dati in punti in cui non è possibile eliminarli, quindi questo processo potrebbe comunque lasciare i dati sul disco. Gli unici modi sicuri per cancellare i dati sono il comando ATA Secure Erase (se implementato correttamente), o distruzione fisica. Vedi anche Come posso cancellare in modo affidabile tutte le informazioni su un disco rigido?

Puoi utilizzare una suite di strumenti chiamata eliminazione sicura.

sudo apt-get install secure-delete

Questo ha quattro strumenti:

srm - eliminare in modo sicuro un file esistente
smem - eliminare in modo sicuro le tracce di un file dalla ram
sfill - cancellare tutto lo spazio contrassegnato come vuoto sul disco rigido
sswap - cancella tutti i dati dal tuo spazio di swap.

Dalla pagina man di srm

srm è progettato per eliminare i dati sui supporti in modo sicuro che non possono essere recuperati da ladri, forze dell'ordine o altre minacce. L'algoritmo di cancellazione si basa sull'articolo "Secure Deletion of Data from Magnetic and Solid-State Memory" presentato al 6th Usenix Security Symposium da Peter Gutmann, uno dei principali crittografi civili.

Il processo di cancellazione sicura dei dati di srm funziona così:

• 1 passaggio con 0xff
• 5 passaggi casuali. /dev/urandom viene utilizzato per un RNG sicuro, se disponibile.
• 27 passaggi con valori speciali definiti da Peter Gutmann.
• 5 passaggi casuali. /dev/urandom viene utilizzato per un RNG sicuro, se disponibile.
• Rinomina il file con un valore casuale
• Tronca il file

Come ulteriore misura di sicurezza, il file viene aperto in modalità O_SYNC e dopo ogni passaggio viene visualizzato un fsync() chiamata è fatta. srm scrive 32k blocchi per motivi di velocità, riempiendo i buffer delle cache del disco per costringerli a svuotare e sovrascrivendo i vecchi dati che appartenevano al file.

Il modo più rapido, se hai bisogno di un solo passaggio e vuoi solo sostituire tutto con zeri, è:

cat /dev/zero > zero.file
sync
rm zero.file

(esegui da una directory sul filesystem che vuoi cancellare)
_{(il sync command è una misura paranoica che garantisce che tutti i dati vengano scritti su disco:un gestore di cache intelligente potrebbe capire che può annullare le scritture per eventuali blocchi in sospeso quando il file è scollegato)}

Ci sarà un momento durante questa operazione in cui non ci sarà spazio libero sul filesystem, che può essere di decine di secondi se il file risultante è grande e frammentato, quindi ci vuole un po' di tempo per eliminarlo. Per ridurre il tempo in cui lo spazio libero è completamente zero:

dd if=/dev/zero of=zero.small.file bs=1024 count=102400
cat /dev/zero > zero.file
sync
rm zero.small.file
rm zero.file

Questo dovrebbe essere sufficiente per impedire a qualcuno di leggere il vecchio contenuto del file senza una costosa operazione forense. Per una variante leggermente più sicura, ma più lenta, sostituire /dev/zero con /dev/urandom . Per più paranoia esegui più passaggi con /dev/urandom , anche se se hai bisogno di così tanto sforzo il shred utility dal pacchetto coreutils è la strada da percorrere:

dd if=/dev/zero of=zero.small.file bs=1024 count=102400
shred -z zero.small.file
cat /dev/zero > zero.file
sync
rm zero.small.file
shred -z zero.file
sync
rm zero.file

Si noti che in quanto sopra il file piccolo viene distrutto prima di creare quello più grande, quindi può essere rimosso non appena il più grande è completo invece di dover attendere che venga distrutto lasciando il filesystem con zero spazio libero per il tempo necessario. Il processo di distruzione richiederà un lungo tempo su un file di grandi dimensioni e, a meno che tu non stia cercando di nascondere qualcosa alla NSA, non è davvero necessario IMO.

Tutto quanto sopra dovrebbe funzionare su qualsiasi filesystem.

Limiti dimensione file:

Come sottolinea DanMoulding in un commento qui sotto, questo potrebbe avere problemi con i limiti di dimensione del file su alcuni filesystem.

Per FAT32 sarebbe sicuramente essere una preoccupazione a causa del limite di file 2GiB:la maggior parte dei volumi sono più grandi di questi giorni (8TiB è il limite di dimensione del volume IIRC). Puoi aggirare questo problema inviando in pipe il grande cat /dev/zero output output tramite split per generare più file più piccoli e regolare di conseguenza le fasi di distruzione ed eliminazione.

Con ext2/3/4 è meno preoccupante:con il blocco 4K predefinito/comune il limite della dimensione del file è 2TiB, quindi dovresti avere un enorme volume perché questo sia un problema (la dimensione massima del volume in queste condizioni è 16TiB).

Con il (ancora sperimentale) btrfs sia la dimensione massima del file che quella del volume sono di ben 16EiB.

Sotto NTFS la lunghezza massima del file è addirittura maggiore della lunghezza massima del volume in alcuni casi.

Punti di partenza per maggiori informazioni:
http://en.wikipedia.org/wiki/Ext3#Size_limits
http://en.wikipedia.org/wiki/Btrfs
http://en.wikipedia.org/wiki/Ntfs#Scalability

Dispositivi virtuali

Come menzionato di recente nei commenti, ci sono ulteriori considerazioni per i dispositivi virtuali:

• Per dischi virtuali scarsamente allocati altri metodi come quelli usati da zerofree sarà più veloce (sebbene diversamente da cat e dd questo non è uno strumento standard su cui puoi fare affidamento per essere disponibile praticamente in qualsiasi sistema operativo unix-a-like).

• Tieni presente che l'azzeramento di un blocco su un dispositivo virtuale sparso potrebbe non cancellare il blocco sul fisico sottostante dispositivo, in effetti direi che è improbabile che lo faccia:il gestore del disco virtuale si limiterà a rendere il blocco non più utilizzato in modo che possa essere assegnato a qualcos'altro in seguito.

• Anche per i dispositivi virtuali di dimensioni fisse, potresti non avere alcun controllo su dove risiede fisicamente il dispositivo, quindi potrebbe essere spostato nella sua posizione corrente o su un nuovo set di dischi fisici in qualsiasi momento e il massimo che puoi cancellare è la posizione corrente, non eventuali posizioni precedenti in cui il blocco potrebbe aver risieduto in passato.

• Per i problemi di cui sopra sui dispositivi virtuali:a meno che tu non controlli gli host e non sia possibile eseguire una cancellazione sicura del loro spazio non allocato dopo aver cancellato i dischi nella VM o spostato il dispositivo virtuale, non c'è nulla che tu possa fare al riguardo dopo il fatto. L'unica soluzione è utilizzare la crittografia completa del disco dall'inizio quindi, in primo luogo, nulla di non crittografato viene scritto sul supporto fisico. Ovviamente potrebbe essere ancora necessaria una cancellazione dello spazio libero all'interno della VM. Si noti inoltre che FDE può rendere i dispositivi virtuali sparsi molto meno utili poiché il livello di virtualizzazione non può realmente vedere quali blocchi sono inutilizzati. Se il livello del file system del sistema operativo invia comandi trim al dispositivo virtuale (come se fosse un SSD) e il controller virtuale li interpreta, ciò potrebbe risolvere questo problema, ma non conosco alcuna circostanza in cui ciò accada effettivamente e un più ampio la discussione è una questione per altrove (ci stiamo già avvicinando all'essere fuori tema per la domanda originale, quindi se questo ha suscitato il tuo interesse, potrebbero essere necessarie alcune sperimentazioni e/o domande di follow-up).

ATTENZIONE

Sono rimasto scioccato dal numero di file che photorec è riuscito a recuperare dal mio disco, anche dopo la cancellazione.

Se ci sia più sicurezza nel riempire lo "spazio libero" solo 1 volta con 0x00 o 38 volte con diversi standard cabalistici è più una discussione accademica. L'autore dell'articolo seminale del 1996 sulla triturazione ha scritto lui stesso un epilogo dicendo che questo è obsoleto e non necessario per l'hardware moderno. Non esiste alcun caso documentato di dati sostituiti fisicamente con zeri e successivamente recuperati.

Il vero anello fragile in questa procedura c'è il filesystem . Alcuni filesystem riservano spazio per usi speciali e non viene reso disponibile come "spazio libero". Ma i tuoi dati potrebbero essere lì . Ciò include foto, e-mail personali in testo semplice, qualunque cosa. Ho appena cercato su Google riservato+spazio+ext4 e ho scoperto che il 5% del mio home la partizione era riservata. Immagino sia qui dove photorec trovato così tanto della mia roba. Conclusione:il metodo di triturazione non è il più importante, anche il metodo multi-pass lascia ancora i dati al loro posto .

Puoi provare # tune2fs -m 0 /dev/sdn0 prima di montarlo. (Se questa sarà la partizione root dopo il riavvio, assicurati di eseguire -m 5 o -m 1 dopo averlo smontato).

Tuttavia, in un modo o nell'altro, potrebbe esserci ancora spazio.

L'unico modo veramente sicuro è cancellare l'intera partizione, creare nuovamente un filesystem e quindi ripristinare i file da un backup.

Percorso veloce (consigliato)

Esegui da una directory sul filesystem che vuoi cancellare:

dd if=/dev/zero of=zero.small.file bs=1024 count=102400
dd if=/dev/zero of=zero.file bs=1024
sync ; sleep 60 ; sync
rm zero.small.file
rm zero.file

Note:lo scopo del file piccolo è di ridurre il tempo in cui lo spazio libero è completamente zero; lo scopo della sincronizzazione è assicurarsi che i dati vengano effettivamente scritti.

Questo dovrebbe essere abbastanza buono per la maggior parte delle persone.

Modo lento (paranoico)

Non esiste alcun caso documentato di ripristino dei dati dopo la pulizia di cui sopra. Sarebbe costoso e richiederebbe risorse, se possibile.

Tuttavia, se hai motivo di pensare che le agenzie segrete spenderebbero molte risorse per recuperare i tuoi file, questo dovrebbe essere sufficiente:

dd if=/dev/urandom of=random.small.file bs=1024 count=102400
dd if=/dev/urandom of=random.file bs=1024
sync ; sleep 60 ; sync
rm random.small.file
rm random.file

Ci vuole molto più tempo.

Avvertimento. Se hai scelto il modo paranoico, dopo questo vorresti comunque eseguire la cancellazione rapida, e questa non è paranoia. La presenza di dati puramente casuali è facile ed economica da rilevare e fa sorgere il sospetto che si tratti effettivamente di dati crittografati. Potresti morire sotto tortura per non aver rivelato la chiave di decrittazione.

Modo molto lento (pazzo paranoico)

Anche l'autore del fondamentale articolo del 1996 sulla triturazione ha scritto un epilogo dicendo che questo è obsoleto e non necessario per l'hardware moderno.

Ma se hai ancora molto tempo libero e non ti dispiace sprecare il tuo disco con un sacco di sovrascritture, ecco fatto:

dd if=/dev/zero of=zero.small.file bs=1024 count=102400
sync ; sleep 60 ; sync
shred -z zero.small.file
dd if=/dev/zero of=zero.file bs=1024
sync ; sleep 60 ; sync
rm zero.small.file
shred -z zero.file
sync ; sleep 60 ; sync
rm zero.file

Nota:questo è essenzialmente equivalente all'utilizzo dello strumento di eliminazione sicura.

Prima della modifica, questo post era una riscrittura di quello di David Spillett. Il comando "cat" produce un messaggio di errore, ma non posso scrivere commenti sui post di altre persone.