¿Cómo borrar el espacio libre en disco en Linux?

Cuando se elimina un archivo, su contenido aún se puede dejar en el sistema de archivos, a menos que se sobrescriba explícitamente con otra cosa. El wipecomando puede borrar archivos de forma segura, pero no parece permitir borrar el espacio libre en el disco que ningún archivo utiliza.

¿Qué debo usar para lograr esto?

Advertencia: el hardware moderno de disco / SSD y los sistemas de archivos modernos pueden guardar datos en lugares donde no puede eliminarlos, por lo que este proceso aún puede dejar datos en el disco. Las únicas formas seguras de borrar datos son el comando ATA Secure Erase (si se implementa correctamente) o la destrucción física. Consulte también ¿Cómo puedo borrar de manera confiable toda la información en un disco duro?

Puede usar un conjunto de herramientas llamado Secure-Delete.

sudo apt-get install secure-delete

Esto tiene cuatro herramientas:

srm- elimine de forma segura un archivo existente
smem- elimine de forma segura los rastros de un archivo de la memoria ram
sfill- borre todo el espacio marcado como vacío en su disco duro
sswap- borre todos los datos de su espacio de intercambio.

Desde la página del manual de srm

srm está diseñado para eliminar datos en medios de manera segura que no pueden ser recuperados por ladrones, agentes de la ley u otras amenazas. El algoritmo de borrado se basa en el documento "Eliminación segura de datos de la memoria magnética y de estado sólido" presentado en el sexto Simposio de seguridad de Usenix por Peter Gutmann, uno de los principales criptógrafos civiles.

El proceso de eliminación segura de datos de srm es así:

• 1 pase con 0xff
• 5 pases al azar. /dev/urandomse usa para un RNG seguro si está disponible.
• 27 pases con valores especiales definidos por Peter Gutmann.
• 5 pases al azar. /dev/urandomse usa para un RNG seguro si está disponible.
• Cambiar el nombre del archivo a un valor aleatorio
• Truncar el archivo

Como medida adicional de seguridad, el archivo se abre en modo O_SYNC y después de cada pasada fsync()se realiza una llamada. srmescribe 32k bloques con fines de velocidad, llenando buffers de cachés de disco para obligarlos a vaciar y sobrescribiendo datos antiguos que pertenecían al archivo.

La forma más rápida, si solo necesita una sola pasada y solo desea reemplazar todo con ceros, es:

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

(ejecutado desde un directorio en el sistema de archivos que desea borrar)
_{(el synccomando es una medida de paranoia que garantiza que todos los datos se escriban en el disco; un administrador de caché inteligente podría resolver que puede cancelar las escrituras para cualquier bloque pendiente cuando el archivo está desvinculado )}

Habrá un momento durante esta operación en el que no habrá espacio libre en absoluto en el sistema de archivos, que puede ser decenas de segundos si el archivo resultante es grande y está fragmentado, por lo que lleva un tiempo eliminarlo. Para reducir el tiempo cuando el espacio libre es completamente cero:

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

Esto debería ser suficiente para evitar que alguien lea el contenido del archivo anterior sin una operación forense costosa. Para una variante un poco más segura, pero más lenta, reemplace /dev/zerocon /dev/urandom. Para más paranoia, ejecute varios pasos /dev/urandom, aunque si necesita tanto esfuerzo, la shredutilidad del paquete coreutils es el camino a seguir:

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

Tenga en cuenta que en lo anterior, el archivo pequeño se destruye antes de crear el archivo más grande, por lo que se puede eliminar tan pronto como se complete el archivo más grande en lugar de tener que esperar a que se destruya dejando el sistema de archivos con cero espacio libre durante el tiempo que tome. El proceso de trituración tarda mucho tiempo en un archivo grande y, a menos que esté tratando de ocultar algo de la NSA, no es realmente necesario IMO.

Todo lo anterior debería funcionar en cualquier sistema de archivos.

Límites de tamaño de archivo:

Como DanMoulding señala en un comentario a continuación, esto puede tener problemas con el límite de tamaño de archivo en algunos sistemas de archivos.

Para FAT32 definitivamente sería una preocupación debido al límite de archivos de 2GiB: la mayoría de los volúmenes son más grandes que esto en estos días (8TiB es el límite de tamaño de volumen IIRC). Puede solucionar este problema canalizando la cat /dev/zerosalida de salida grande splitpara generar múltiples archivos más pequeños y ajustar la trituración y eliminar las etapas en consecuencia.

Con ext2 / 3/4 es menos preocupante: con el bloque 4K predeterminado / común, el límite de tamaño de archivo es 2TiB, por lo que tendría que tener un gran volumen para que esto sea un problema (el tamaño de volumen máximo en estas condiciones es 16TiB).

Con los btrfs (todavía experimentales), tanto el tamaño máximo de archivo como el de volumen son enormes 16EiB.

Bajo NTFS, la longitud máxima del archivo es incluso mayor que la longitud máxima del volumen, incluso en algunos casos.

Puntos de partida para más información:
http://en.wikipedia.org/wiki/Ext3#Size_limits
http://en.wikipedia.org/wiki/Btrfs
http://en.wikipedia.org/wiki/Ntfs#Scalability

Dispositivos virtuales

Como se mencionó en los comentarios recientemente, hay consideraciones adicionales para los dispositivos virtuales:

• Para los discos virtuales asignados escasamente otros métodos, como los utilizados por zerofreeserán más rápidas (aunque a diferencia caty ddesto no es una herramienta estándar que usted puede confiar en que está disponible en casi cualquier sistema operativo UNIX-uno-como).

• Tenga en cuenta que poner a cero un bloque en un dispositivo virtual disperso puede no borrar el bloque en el dispositivo físico subyacente , de hecho, iría tan lejos como para decir que es poco probable: el administrador de disco virtual simplemente hará que el bloque ya no se use entonces puede ser asignado a otra cosa más tarde.

• Incluso para dispositivos virtuales de tamaño fijo, es posible que no tenga control de dónde vive físicamente el dispositivo, por lo que podría moverse alrededor de su ubicación actual o en un nuevo conjunto de discos físicos en cualquier momento y lo máximo que puede borrar es la ubicación actual, no cualquier ubicación previa que el bloque haya residido en el pasado.

• Para los problemas anteriores en dispositivos virtuales: a menos que controle los hosts y pueda borrar de forma segura su espacio no asignado después de limpiar los discos en la VM o mover el dispositivo virtual, no hay nada que pueda hacer al respecto después de hecho. El único recurso es utilizar el cifrado de disco completo desde el principio.así que nada sin encriptar se escribe en los medios físicos en primer lugar. Todavía puede haber una llamada para una limpieza de espacio libre dentro de la VM, por supuesto. Tenga en cuenta también que FDE puede hacer que los dispositivos virtuales dispersos sean mucho menos útiles, ya que la capa de virtualización realmente no puede ver qué bloques no se utilizan. Si la capa del sistema de archivos del sistema operativo envía comandos de recorte al dispositivo virtual (como si fuera un SSD), y el controlador virtual los interpreta, entonces eso puede resolver esto, pero no sé de ninguna circunstancia en la que esto realmente suceda y la discusión de eso es un asunto para otra parte (ya nos estamos acercando a estar fuera del tema de la pregunta original, por lo que si esto ha despertado su interés, puede ser necesario realizar algunas preguntas de experimentación y / o seguimiento).

ADVERTENCIA

Me sorprendió la cantidad de archivos que Photorec podía recuperar de mi disco, incluso después de borrarlos.

Si hay más seguridad en llenar el "espacio libre" solo 1 vez con 0x00 o 38 veces con diferentes estándares cabalísticos es más una discusión académica. El autor del documento seminal de 1996 sobre trituración se escribió un epílogo diciendo que esto es obsoleto e innecesario para el hardware moderno. No hay ningún caso documentado de datos que sean reemplazados físicamente por ceros y recuperados después.

El verdadero enlace frágil en este procedimiento es el sistema de archivos . Algunos sistemas de archivos reservan espacio para uso especial, y no está disponible como "espacio libre". Pero sus datos pueden estar allí . Eso incluye fotos, correos electrónicos personales de texto sin formato, lo que sea. Acabo de buscar en Google reservado + espacio + ext4 y aprendí que el 5% de mi homepartición estaba reservada. Supongo que aquí es donde se photorecencuentran muchas de mis cosas. Conclusión: el método de trituración no es el más importante, incluso el método de múltiples pasadas todavía deja los datos en su lugar .

Puedes probar # tune2fs -m 0 /dev/sdn0antes de montarlo. (Si esta será la partición raíz después de reiniciar, asegúrese de ejecutarla -m 5o de -m 1desmontarla).

Pero aún así, de una forma u otra, puede quedar algo de espacio.

La única forma verdaderamente segura es borrar toda la partición, crear un sistema de archivos nuevamente y luego restaurar sus archivos desde una copia de seguridad.

Manera rápida (recomendado)

Ejecute desde un directorio en el sistema de archivos que desea borrar:

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

Notas: el propósito del archivo pequeño es reducir el tiempo cuando el espacio libre es completamente cero; El propósito de la sincronización es asegurarse de que los datos estén realmente escritos.

Esto debería ser lo suficientemente bueno para la mayoría de las personas.

Camino lento (paranoico)

No hay ningún caso documentado de recuperación de datos después de la limpieza anterior. Sería costoso y requeriría recursos, si es posible.

Sin embargo, si tiene una razón para pensar que las agencias secretas gastarían muchos recursos para recuperar sus archivos, esto debería ser suficiente:

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

Lleva mucho más tiempo.

Advertencia. Si ha elegido la forma paranoica, después de esto aún querría hacer el borrado rápido, y eso no es paranoia. La presencia de datos puramente aleatorios es fácil y barata de detectar, y levanta la sospecha de que en realidad son datos cifrados. Puede morir bajo tortura por no revelar la clave de descifrado.

Camino muy lento (paranoico loco)

Incluso el autor del documento seminal de 1996 sobre trituración escribió un epílogo diciendo que esto es obsoleto e innecesario para el hardware moderno.

Pero si aún tiene mucho tiempo libre y no le importa desperdiciar su disco con demasiada sobrescritura, ahí va:

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: esto es esencialmente equivalente a usar la herramienta de eliminación segura.

Antes de la edición, esta publicación era una reescritura de David Spillett. El comando "cat" produce un mensaje de error, pero no puedo escribir comentarios en las publicaciones de otras personas.

Hay una utilidad zerofree al menos en 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.

Consulte también este enlace sobre zerofree: Mantener escasas las imágenes del sistema de archivos : es de su autor, Ron Yorston (9 de agosto de 2012)

Aquí se explica cómo hacerlo con una GUI.

1. Instalar BleachBit
2. Ejecute como root haciendo clic en Aplicaciones - Herramientas del sistema - BleachBit como administrador.
3. En las preferencias, dígale qué caminos desea. Generalmente los adivina bien. Desea incluir una ruta de escritura para cada partición. En general, es / home / username y / tmp, a menos que sean la misma partición, en cuyo caso solo elija una.
4. Marque la casilla Sistema - Limpie el espacio libre en disco.
5. Haz clic en Eliminar.

El avance de BleachBit sobre dd (que de lo contrario es muy bueno) es cuando el disco está finalmente lleno, BleachBit crea pequeños archivos para borrar los inodos (que contienen metadatos como nombres de archivos, etc.).

Utilizo ddpara asignar uno o más archivos grandes para llenar el espacio libre, luego uso una utilidad de eliminación segura.

Para asignar archivos con dd intente:

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

Esto generará un archivo llamado delete_meque tiene un tamaño de 100 MB. (Aquí bsestá el "tamaño de bloque" establecido en 1k, y countes el número de bloques para asignar).

Luego use su utilidad de eliminación segura favorita (que he estado usando shred) en los archivos así creados.

Pero TENGA EN CUENTA ESTO: el almacenamiento en búfer significa que incluso si hace todo el disco, ¡puede que no obtenga absolutamente todo!

Este enlace recomienda scrubpara limpiar el espacio libre. No lo he intentado.

Limpie una unidad a la máxima velocidad.

Las instrucciones típicas para cifrar una unidad hoy en día le indicarán que primero LIMPIE la unidad.

El siguiente comando llenará su unidad con texto cifrado AES.

Use un CD en vivo si necesita limpiar su unidad de arranque principal.

Abra una terminal y eleve sus privilegios:

sudo bash

Hagamos una lista de todas las unidades del sistema para que sean seguras:

cat /proc/partitions

NOTA: Reemplace /dev/sd{x}con el dispositivo que desea borrar.

ADVERTENCIA: ¡Esto no es para aficionados! ¡Podría hacer que su sistema no se pueda iniciar!

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}

Estoy sorprendido de lo rápido que es esto.

Probablemente ya tenga instalado el paquete GNU coreutils en su sistema. Proporciona el comando triturar .

Puede borrar su espacio libre utilizando un paquete de eliminación seguro.

En ese paquete puede encontrar una sfillherramienta, que está diseñada para eliminar datos que se encuentran en el espacio disponible en disco en medios de manera segura que no pueden ser recuperados por ladrones, agentes de la ley u otras amenazas.

Para instalar el paquete de eliminación segura en Linux (Ubuntu), instálelo con el siguiente comando:

$ sudo apt-get install secure-delete

Luego, para borrar sus datos sin espacio libre, pruebe el siguiente comando:

sfill -f -v -ll /YOUR_MOUNTPOINT/OR_DIRECTORY

Donde / YOUR_MOUNTPOINT / OR_DIRECTORY es su punto de montaje ( df -h, mount) o directorio para borrar el espacio libre.

Lea el manual en http://manpages.ubuntu.com/manpages/hardy/man1/sfill.1.html

use dd y simplemente cero el espacio libre. Es un mito que los datos deben sobrescribirse varias veces (solo pregunte a Peter Guntmann) y los datos aleatorios, a diferencia de 1 y luego 0, implica actividad no natural. entonces el resultado final es una unidad limpia con mucho menos tiempo dedicado a escribir. Además, los programas de eliminación segura no pueden garantizar que incluso sobrescriban el archivo real en los sistemas de archivos modernos (registrados). hazte un favor y obtén photorec, escanea tu disco para ver el desorden, límpialo con 1 y opcionalmente con ceros para que parezca intacto. si photorec todavía encuentra cosas, recuerde que está escaneando todo lo disponible, así que hágalo con cuidado nuevamente con el usuario root.

recuerde, cia / fbi / nsa no tiene una máquina elegante que pueda leer el estado real de sus bits de medios magnéticos. todo eso fue solo un artículo escrito hace mucho tiempo. un "que tal si". solo necesitas limpiar 1 vez.

Más fácil es usar scrub :

scrub -X dump

Esto creará una dumpcarpeta en la ubicación actual y creará el archivo hasta que el disco esté lleno. Puede elegir un patrón con la -popción ( nnsa|dod|bsi|old|fastold|gutmann).

No es fácil instalar Scrub ( ver los foros de Ubuntu sobre esto ), pero una vez que se realiza la instalación, tienes una herramienta realmente SIMPLE y eficiente en tu mano.

Aquí está el script "sdelete.sh" que uso. Ver comentarios para más detalles.

# 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'

Encontré una solución simple que funciona en Linux y MacOS. Muévase en la carpeta raíz de su disco y ejecute este comando:

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

donde // DISKSPACE // es el tamaño en GB de su disco duro.

A veces uso este bash one-liner:

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

Cuando comience a decir que el disco está lleno, simplemente presione Ctrl+ Cy elimine los zero.*archivos creados .

Funciona en cualquier sistema, independientemente de los límites de tamaño del archivo.
Ignora cualquier cat: write error: File too largeerror.

¡Esta no es una respuesta! Solo un comentario para aquellos que deseen usar pv... así que no se molesten en votar.

En Linux Mint 17.3 puede usar pv( vista de tubería ) para avanzar en la escritura. Por ejemplo:

# 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

La ventaja aquí es que obtienes una barra de progreso, ETA y una velocidad de datos continuamente actualizada. La desventaja es que esto está escrito en una línea y cuando el disco está lleno (devuelve un error) desaparece. Esto sucede porque el tamaño completo es aproximado ya que el sistema operativo probablemente usará el disco mientras se lleva a cabo esta operación muy larga, especialmente en el volumen del sistema operativo.

En un HD muy antiguo, obtengo una velocidad de datos de aproximadamente 13 MB / s usando /dev/urandom, y aproximadamente 70 MB / s , cuando lo uso /dev/zero. Esto probablemente mejoraría aún más cuando se usa un raw ddo cat, y no pv.

Una vez que el archivo desaparece del registro del sistema de archivos, los datos que quedan en el disco duro son una secuencia sin sentido de 1 y 0. Si está buscando reemplazar esa secuencia sin sentido con otra secuencia sin sentido, puedo aconsejar algunos productos comerciales para borrar unidades de forma segura, como arconis.