Come cancellare lo spazio libero su disco in Linux?

Attenzione: L'hardware moderno del disco/SSD e i moderni filesystem possono far sparire i dati in luoghi dove non è possibile cancellarli, quindi questo processo può comunque lasciare dei dati sul disco. Gli unici modi sicuri per cancellare i dati sono il comando ATA Secure Erase (se implementato correttamente), o la distruzione fisica. Vedere anche Come posso cancellare in modo affidabile tutte le informazioni su un disco rigido?

È possibile utilizzare una suite di strumenti chiamata secure-delete.

sudo apt-get install secure-delete

Questo ha quattro strumenti:

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

Dalla pagina man di srm

srm è progettato per cancellare i dati su supporti in modo sicuro che non possono essere recuperati da ladri, forze dell'ordine o altre minacce. L'algoritmo di cancellazione si basa sul documento “Secure Deletion of Data from Magnetic and Solid-State Memory” presentato al 6° Simposio sulla sicurezza di Usenix da Peter Gutmann, uno dei principali crittografi civili.

Il processo di cancellazione sicura dei dati di srm va in questo modo:

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

• Tronca il file

• Tronca il file

Come ulteriore misura di sicurezza, il file viene aperto in modalità O_SYNC e dopo ogni passaggio viene fatta una chiamata fsync(). srm scrive blocchi di 32k per la velocità, riempie i buffer delle cache dei dischi per forzarli a risciacquare e sovrascrive i vecchi dati che appartenevano al file.

Il modo più veloce, se si ha bisogno di un solo passaggio e si vuole sostituire tutto con degli zeri, è quello di farlo:

cat /dev/zero > zero.file
sync
rm zero.file
``` ```
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

(eseguito da una directory sul filesystem che si vuole cancellare) (il comando sync è una misura di paranoia che assicura che tutti i dati siano scritti su disco - un gestore di cache intelligente potrebbe capire che può cancellare le scritture per qualsiasi blocco in sospeso quando il file è scollegato)

Ci sarà un tempo durante questa operazione in cui non ci sarà più 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 cancellare. Per ridurre il tempo in cui lo spazio libero è completamente nullo:

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

Questo dovrebbe essere sufficiente per impedire a qualcuno di leggere il contenuto del vecchio file senza una costosa operazione forense. Per una variante leggermente più sicura, ma più lenta, sostituire /dev/zero con /dev/urandom. Per una maggiore paranoia eseguire più passaggi con /dev/urandom, anche se se avete bisogno di tanto sforzo l'utilità shred del pacchetto coreutils è la strada da seguire:

&001 &001

Si noti che nella parte superiore il piccolo file viene triturato prima di creare il più grande, in modo che possa essere rimosso non appena il più grande è completo, invece di dover aspettare che venga triturato lasciando il filesystem con zero spazio libero per il tempo necessario. Il processo di sminuzzamento con richiede un lungo tempo su un file grande e a meno che non si stia cercando di nascondere qualcosa all'NSA non è veramente necessario IMO.

Tutto quanto sopra dovrebbe funzionare su qualsiasi filesystem.

** Limiti di dimensione dei file:**

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

Per FAT32 sarebbe definitamente una preoccupazione dovuta al limite di 2GiB file: la maggior parte dei volumi sono più grandi di questo in questi giorni (8TiB è il limite di dimensione del volume IIRC). Si può ovviare a questo problema facendo passare il grande output di cat /dev/zero attraverso split per generare più file più piccoli e regolare gli stadi di shred e cancellare di conseguenza.

Con ext2/3/4 è meno problematico: con il blocco 4K di default/comune il limite di dimensione del file è di 2TiB quindi si dovrebbe avere un volume huge perché questo sia un problema (la dimensione massima del volume in queste condizioni è di 16TiB).

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

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

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 nei commenti di recente, ci sono considerazioni extra per i dispositivi virtuali:

• Per i dischi virtuali scarsamente allocati altri metodi come quelli usati da zerofree saranno più veloci (anche se a differenza di cat e dd questo non è uno strumento standard che si può contare sul fatto di essere disponibile praticamente in qualsiasi sistema operativo unix-a-like).

• Siate consapevoli che l'azzeramento di un blocco su un dispositivo virtuale rado potrebbe non cancellare il blocco sul dispositivo fisico sottostante, infatti mi spingerei fino a dire che è improbabile - il gestore di dischi virtuali si limiterà a rendere il blocco come non più utilizzato in modo che possa essere assegnato a qualcos'altro in seguito.

• Anche per i dispositivi virtuali di dimensioni fisse, si può non avere il controllo di dove il dispositivo vive fisicamente in modo che possa essere spostato nella sua posizione attuale o su un nuovo set di dischi fisici in qualsiasi momento e il massimo che si può cancellare è la posizione attuale, non qualsiasi posizione precedente il blocco può aver risieduto in passato.

• Per i problemi di cui sopra sui dispositivi virtuali: a meno che non si controlli l'host o gli host e non si possa effettuare una cancellazione sicura del loro spazio non allocato dopo aver cancellato i dischi nella VM o aver spostato il dispositivo virtuale, non c'è nulla che si possa fare dopo il fatto. L'unico ricorso è quello di utilizzare la crittografia completa del disco dall'inizio in modo che nulla di non crittografato sia scritto sul supporto fisico in primo luogo. Ci può ancora essere la richiesta di una pulizia dello spazio libero all'interno della VM, naturalmente. Si noti anche che FDE può rendere i dispositivi virtuali scarsi molto meno utili in quanto il livello di virtualizzazione non può vedere quali blocchi sono inutilizzati. Se il livello del filesystem del sistema operativo invia comandi di trim al dispositivo virtuale (come se fosse un SSD), e il controllore virtuale li interpreta, allora questo potrebbe risolvere il problema, ma non conosco nessuna circostanza in cui questo avvenga effettivamente e una più ampia discussione di questo è una questione che riguarda altrove (ci stiamo già avvicinando ad essere fuori tema per la domanda originale, quindi se questo ha suscitato il vostro interesse alcune sperimentazioni e/o domande di follow-up potrebbero essere in ordine).

ATTENZIONE

Sono rimasto scioccato da quanti file photorec potevano essere recuperati dal mio disco, anche dopo averli puliti.

Se ci sia più sicurezza nel riempire lo “spazio libero” solo 1 volta con 0x00 o 38 volte con diversi standard cabalistici è più che altro una discussione accademica. L'autore del fondamentale articolo del 1996 sulla triturazione si è scritto un epilogo dicendo che questo è obsoleto e non necessario per l'hardware moderno. Non c'è nessun caso documentato di dati che vengono fisicamente sostituiti con zeri e recuperati in seguito.

Il vero collegamento fragile in questa procedura è il file system. Alcuni filesystem riservano spazio per un uso speciale e non sono resi disponibili come “spazio libero”. Ma i vostri dati potrebbero essere lì. Questo include foto, email personali in chiaro, qualsiasi cosa. Ho appena cercato su Google riservato+spazio+ext4 e ho saputo che il 5% della mia partizione home è stato riservato. Immagino che sia qui che photorec ha trovato così tanta 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, assicuratevi di eseguire -m 5 o -m 1 dopo averla smontata).

Ma comunque, in un modo o nell'altro, potrebbe esserci ancora un po’ di spazio.

L'unico modo veramente sicuro è quello di cancellare l'intera partizione, creare di nuovo un filesystem e poi ripristinare i file da un backup.

** Modo rapido (consigliato)**

Esegui da una directory del 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 piccolo file è quello di ridurre il tempo quando lo spazio libero è completamente nullo; lo scopo della sincronizzazione è quello di assicurarsi che i dati siano effettivamente scritti. _

Questo dovrebbe essere sufficiente per la maggior parte delle persone.

Lentamente (paranoico)

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

Eppure, se avete una ragione per pensare che le agenzie segrete spenderebbero molte risorse per recuperare i vostri 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
``` ```
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

Ci vuole molto più tempo.

Attenzione. Se avete scelto la via della paranoia, dopo di che vorreste comunque fare la pulizia veloce, e non è paranoia. La presenza di dati puramente casuali è facile ed economica da rilevare, e fa sorgere il sospetto che si tratti di dati effettivamente criptati. Si può morire sotto tortura per non aver rivelato la chiave di decrittazione.

Molto lento (pazzo paranoico)

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

Ma se avete ancora molto tempo libero e non vi dispiace sprecare il vostro disco con un sacco di sovrascritture, ecco fatto:

&001 &001

Nota: questo è essenzialmente equivalente all'uso dello strumento di cancellazione sicura.

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

C'è un'utilità zerofree almeno in Ubuntu: http://manpages.ubuntu.com/manpages/natty/man8/zerofree.8.html

zerofree — zero free blocks from ext2/3 file-systems

   zerofree finds the unallocated, non-zeroed blocks in an ext2 or ext3
   filesystem (e.g. /dev/hda1) and fills them with zeroes. This is useful
   if the device on which this file-system resides is a disk image. In
   this case, depending on the type of disk image, a secondary utility may
   be able to reduce the size of the disk image after zerofree has been
   run.

   The usual way to achieve the same result (zeroing the unallocated
   blocks) is to run dd (1) to create a file full of zeroes that takes up
   the entire free space on the drive, and then delete this file. This has
   many disadvantages, which zerofree alleviates:

      · it is slow;

      · it makes the disk image (temporarily) grow to its maximal extent;

      · it (temporarily) uses all free space on the disk, so other
         concurrent write actions may fail.

   filesystem has to be unmounted or mounted read-only for zerofree to
   work. It will exit with an error message if the filesystem is mounted
   writable. To remount the root file-system readonly, you can first
   switch to single user runlevel (telinit 1) then use mount -o remount,ro
   filesystem.

Anche controllare questo link su zerofree: Mantenere scarse le immagini del filesystem - è del suo autore - Ron Yorston (9 Agosto 2012)

Cancellare un disco alla massima velocità.

Le istruzioni tipiche per la cifratura di un disco al giorno d'oggi vi diranno di cancellare prima il disco.

Il comando qui sotto riempirà il vostro disco con il testo cifrato AES.

Usate un CD live se avete bisogno di cancellare il vostro disco di avvio principale.

Aprire un terminale ed elevare i vostri privilegi:

sudo bash

Elenchiamo tutti i drive del sistema per essere sicuri:

cat /proc/partitions
``` ```
sudo openssl enc -aes-256-ctr -pass pass:"$(dd if=/dev/urandom bs=128 count=1 2>/dev/null | base64)" -nosalt < /dev/zero > /dev/sd{x}

NOTA: Sostituire /dev/sd{x} con il dispositivo che si desidera cancellare.

ATTENZIONE: Questo non è per dilettanti! Potreste rendere il vostro sistema non avviabile!

&001 &001

Sono sbalordito da quanto sia veloce.

Uso dd per allocare uno o più file di grandi dimensioni per riempire lo spazio libero, poi uso un'utilità di cancellazione sicura.

Per allocare i file con dd provare:

dd if=/dev/zero of=delete_me bs=1024 count=102400

Questo genererà un file chiamato delete_me che ha una dimensione di 100 MB. (Qui bs è la “dimensione del blocco” impostata a 1k, e count è il numero di blocchi da allocare.)

Poi usate la vostra utilità di cancellazione sicura preferita (ho usato shred ) sui file così creati.

Ma NOTA QUESTO: buffering significa che anche se si fa il _disco intero, si potrebbe non ottenere assolutamente tutto!

Questo link raccomanda scrub per pulire lo spazio libero. Non l'ho provato.

È possibile cancellare lo spazio libero utilizzando il pacchetto di cancellazione sicura.

In questo pacchetto è possibile trovare lo strumento sfill, che è stato progettato per cancellare i dati che si trovano sullo spazio disponibile su supporti in modo sicuro che non possono essere recuperati da ladri, forze dell'ordine o altre minacce.

Per installare il pacchetto di cancellazione sicura in Linux (Ubuntu), installatelo con il seguente comando:

$ sudo apt-get install secure-delete

Poi per cancellare i vostri dati senza spazio libero, provate il seguente comando:

sfill -f -v -ll /YOUR_MOUNTPOINT/OR_DIRECTORY

Dove /YOUR_MOUNTPOINT/OR_DIRECTORY è il vostro punto di montaggio (df -h, mount) o la directory per cancellare lo spazio libero.

Leggete il manuale su http://manpages.ubuntu.com/manpages/hardy/man1/sfill.1 .html

Probabilmente avete già installato il pacchetto GNU coreutils sul vostro sistema. Esso fornisce il comando shred .

Più facile è usare scrub :

scrub -X dump
``` &001 


Questo creerà una cartella `dump` nella posizione corrente e creerà il file fino a quando il disco sarà pieno. Si può scegliere un modello con l'opzione `-p` (`nnsa|dod|bsi|old|fastold|gutmann`). 


Non è facile far installare scrub [ vedere i forum di Ubuntu su questo ](http://ubuntuforums.org/showthread.php?t=333309)), ma una volta fatta l'installazione, si ha in mano uno strumento davvero SEMPLICE ed efficiente.

Ecco lo script “sdelete.sh” che uso. Vedi i commenti per i dettagli.

# Install the secure-delete package (sfill command).

# To see progress type in new terminal:
# watch -n 1 df -hm

# Assuming that there is one partition (/dev/sda1). sfill writes to /.
# The second pass writes in current directory and synchronizes data.
# If you have a swap partition then disable it by editing /etc/fstab
# and use "sswap" or similar to wipe it out.

# Some filesystems such as ext4 reserve 5% of disk space
# for special use, for example for the /home directory.
# In such case sfill won't wipe out that free space. You
# can remove that reserved space with the tune2fs command.
# See http://superuser.com/a/150757
# and https://www.google.com/search?q=reserved+space+ext4+sfill

sudo tune2fs -m 0 /dev/sda1
sudo tune2fs -l /dev/sda1 | grep 'Reserved block count'

sudo sfill -vfllz /

# sfill with the -f (fast) option won't synchronize the data to
# make sure that all was actually written. Without the fast option
# it is way too slow, so doing another pass in some other way with
# synchronization. Unfortunately this does not seem to be perfect,
# as I've watched free space by running the "watch -n 1 df -hm"
# command and I could see that there was still some available space
# left (tested on a SSD drive).

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

sudo tune2fs -m 5 /dev/sda1
sudo tune2fs -l /dev/sda1 | grep 'Reserved block count'

Ho trovato una soluzione semplice che funziona su Linux e su MacOS. Spostatevi nella cartella principale del vostro disco e lanciate questo comando:

for i in $(seq 1 //DISKSPACE//); do dd if=/dev/zero of=emptyfile${i} bs=1024 count=1048576; done; rm emptyfile*;

dove //DISKSPACE// è la dimensione in GB del vostro disco fisso.

utilizzare dd e azzerare lo spazio libero. è un mito i dati devono essere sovrascritti più volte (basta chiedere a peter guntmann) e i dati casuali, in contrasto con 1 e poi 0 implica un'attività innaturale. poi il risultato finale è un disco pulito con molto meno tempo speso a scrivere. inoltre, i programmi di cancellazione sicura non possono garantire che sovrascrivono anche il file reale sui moderni file system (journaled). fatevi un favore e ottenere photorec, eseguire la scansione del disco per vedere il disordine, pulire con 1 e opzionalmente con zeri per farlo sembrare intatto. se photorec trova ancora roba, ricordate che è la scansione di tutto ciò che è disponibile in modo da fare questo con attenzione di nuovo con l'utente root.

ricordare, il cia/fbi/nsa non ha una macchina di fantasia in grado di leggere lo stato effettivo dei vostri bit di supporti magnetici. che era tutto solo un foglio di carta scritto molto tempo fa. un “what-if”. è sufficiente pulire solo 1 volta.

Questa non è una risposta!_ Solo un commento per coloro che desiderano utilizzare pv…quindi non disturbatevi a votare.

Su Linux Mint 17.3 è possibile utilizzare pv (pipe view) per ottenere il progresso della scrittura. Per esempio:

# Install pv (pipe view)
sudo apt-get install pv

# Write huge file of approximate size of /dev/sdb, using urandom data:
pv --timer --average-rate --progress --numeric --eta --interval 5 --size "$(blockdev --getsize64 /dev/sda )" /dev/urandom >rand.file
``` &001 

Il vantaggio è che si ottiene una barra di avanzamento, l'ETA e la velocità dei dati continuamente aggiornata. Lo svantaggio è che questa viene scritta su una sola riga e quando il disco è pieno (restituendo un errore) scompare. Questo accade perché la dimensione completa è approssimativa poiché il sistema operativo utilizzerà probabilmente il disco mentre questa operazione molto lunga si sta svolgendo, specialmente sul volume del sistema operativo. 


Su un HD molto vecchio, ottengo una velocità di trasferimento dati di circa **13 MB/s** utilizzando `/dev/urandom`, e di circa **70 MB/s** , quando utilizzo `/dev/zero`. Questo probabilmente migliorerebbe ulteriormente quando si usa un `dd` o `cat` grezzo, e non `pv`.

A volte uso questo bash one-liner:

while :; do cat /dev/zero > zero.$RANDOM; done

Quando inizia a dire che il disco è pieno, basta premere Ctrl+C e rimuovere i file zero.* creati.

Funziona su qualsiasi sistema, qualunque siano i limiti di dimensione del file. Ignora gli errori cat: write error: File too large.

Una volta che il file è andato fuori dal record del file system, i dati che vengono lasciati sul disco rigido sono sequenza senza senso di 1 e 0. Se state cercando di sostituire quella sequenza senza senso con un'altra sequenza senza senso, posso consigliare alcuni prodotti commerciali per la cancellazione sicura delle unità, come arconis.