¿Cómo se borra el espacio libre del disco en Linux?

Advertencia: El hardware de los discos y los sistemas de archivos modernos pueden arrastrar datos a lugares donde no se pueden borrar, por lo que este proceso 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 toda la información de un disco duro de forma fiable?

Puede utilizar un conjunto de herramientas llamado secure-delete.

sudo apt-get install secure-delete

Esto tiene cuatro herramientas:

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

Desde la página de inicio de srm

srm está diseñado para borrar datos en soportes de forma segura que no pueden ser recuperados por ladrones, fuerzas de seguridad u otras amenazas. El algoritmo de borrado se basa en el documento “Borrado seguro de datos de la memoria magnética y de estado sólido” presentado en el 6º Simposio de Seguridad de Usenix por Peter Gutmann, uno de los principales criptógrafos civiles.

El proceso de borrado seguro de datos del srm va así:

• 1 pasada con 0xff
• 5 pasadas aleatorias. /dev/urandom se utiliza para un RNG seguro si está disponible.
• 27 pasadas con valores especiales definidos por Peter Gutmann.
• 5 pases aleatorios. /dev/urandom se utiliza para un RNG seguro si está disponible.
• Renombra el archivo a un valor aleatorio
• Trunca el archivo

Como medida adicional de seguridad, el archivo se abre en modo O_SYNC y después de cada paso se hace una llamada a fsync(). srm escribe bloques de 32k con el propósito de velocidad, llenando los buffers de las cachés de disco para forzarlos a limpiar y sobreescribir los datos antiguos que pertenecían al archivo.

La forma más rápida, si sólo necesitas un pase y quieres reemplazar todo con ceros, es:

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

(se ejecuta desde un directorio en el sistema de archivos que se desea borrar) (el comando sync es una medida de paranoia que asegura que todos los datos se escriban en el disco - un administrador de caché inteligente podría resolver que puede cancelar las escrituras de cualquier bloque pendiente cuando el archivo se desvincula)

Habrá un momento durante esta operación en que no habrá ningún espacio libre en el sistema de archivos, que puede ser de decenas de segundos si el archivo resultante es grande y está fragmentado, por lo que toma un tiempo para eliminarlo. Para reducir el tiempo en que 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 de un archivo antiguo sin una costosa operación forense. Para una variante un poco más segura, pero más lenta, reemplace /dev/zero por /dev/urandom. Para más paranoia, ejecute varios pasos con /dev/urandom, aunque si necesita tanto esfuerzo, la utilidad shred del paquete de 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 tritura antes de crear el más grande, por lo que puede ser eliminado tan pronto como el más grande esté completo en lugar de tener que esperar a que se triture dejando el sistema de archivos con cero espacio libre durante el tiempo que esto lleve. El proceso de trituración con tomar un tiempo largo sobre un archivo grande y a menos que esté tratando de ocultar algo a la NSA no es realmente necesario IMO.

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

Límites de tamaño de los archivos:

Como señala DanMoulding en un comentario más abajo, esto puede tener problemas con los límites de tamaño de los archivos en algunos sistemas de archivos.

Para FAT32 sería definidamente 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 esto canalizando la salida de cat /dev/zero grande a través de split para generar varios archivos más pequeños y ajustar las etapas de trituración y eliminación en consecuencia.

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

Con los btrfs (aún experimentales) tanto el tamaño máximo del archivo como el del volumen son un masivo 16EiB.

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

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

Dispositivos Virtuales

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

• Para los discos virtuales escasamente asignados, otros métodos como los usados por zerofree serán más rápidos (aunque a diferencia de cat y dd, esta no es una herramienta estándar en la que se pueda confiar al estar disponible en casi cualquier sistema operativo unix-a-like).

• Tenga en cuenta que poner a cero un bloque en un dispositivo virtual escaso puede no borrar el bloque en el dispositivo físico subyacente, de hecho me atrevería a decir que es poco probable que lo haga - el gestor de discos virtuales sólo hará que el bloque deje de utilizarse para que pueda ser asignado a otra cosa más tarde.

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

• Para los problemas anteriores en los dispositivos virtuales: a menos que usted controle el anfitrión (es) y pueda hacer un borrado seguro de su espacio no asignado después de borrar los discos en el VM o mover el dispositivo virtual, no hay nada que pueda hacer al respecto después del hecho. El único recurso es usar la encriptación completa del disco desde el principio para que nada sin encriptar sea escrito en el medio físico en primer lugar. Puede que todavía se requiera un borrado del espacio libre dentro del VM, por supuesto. Tenga en cuenta también que el FDE puede hacer que los dispositivos virtuales dispersos sean mucho menos útiles, ya que la capa de virtualización no puede ver realmente qué bloques no se utilizan. Si la capa del sistema de archivos del SO envía comandos de recorte al dispositivo virtual (como si se tratara de una SSD), y el controlador virtual los interpreta, entonces esto puede resolverlo, pero no conozco ninguna circunstancia en la que esto suceda realmente y una discusión más amplia sobre ello es un asunto para otro lugar (ya estamos cerca de estar fuera de tema para la pregunta original, así que si esto ha despertado su interés, puede que algunas preguntas de experimentación y/o de seguimiento estén en orden).

ADVERTENCIA

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

Si hay más seguridad en llenar el “espacio libre” sólo 1 vez con 0x00 o 38 veces con diferentes estándares cabalísticos es más una discusión académica. El autor del trabajo seminal de 1996 sobre la trituración se escribió a sí mismo un epílogo diciendo que esto es obsoleto e innecesario para el hardware moderno. No hay ningún caso documentado de datos que sean físicamente reemplazados 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 un uso especial, y no está disponible como “espacio libre”. Pero sus datos pueden estar ahí. Eso incluye fotos, correos electrónicos personales de texto plano, lo que sea. Acabo de buscar en google reservado+espacio+ext4 y me he enterado de que el 5% de mi partición home estaba reservada. Supongo que aquí es donde photorec encontró muchas de mis cosas. Conclusión: el método de trituración no es el más importante, incluso el método multi-pass sigue dejando los datos en su lugar.

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

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 de nuevo y luego restaurar sus archivos desde una copia de seguridad.

Vía 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 se escriban realmente.

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

Camino lento (paranoico)

No hay ningún caso documentado de datos recuperados después de la limpieza anterior. Sería costoso y exigente en cuanto 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

Toma mucho más tiempo.

Advertencia. Si has elegido el camino de la paranoia, después de esto todavía querrías 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 encriptados. Usted puede morir bajo tortura por no revelar la clave de desencriptación.

Muy lento (paranoico loco)

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

Pero si todavía tienes mucho tiempo libre y no te importa perder tu disco con mucha sobreescritura, 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 borrado seguro.

Antes de la edición, este post fue una reescritura de David Spillett. El comando “gato” produce un mensaje de error, pero no puedo escribir comentarios en los posts 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.

También comprueba este enlace sobre zerofree: Manteniendo las imágenes del sistema de archivos escasas - es de su autor - Ron Yorston (9 de agosto de 2012)

Borre una unidad a máxima velocidad.

Las instrucciones típicas para encriptar una unidad hoy en día le dirán que primero BORRE la unidad.

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

Use un live CD si necesita borrar su unidad de arranque principal.

Abra una terminal y aumente sus privilegios:

sudo bash

Listaremos 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ías hacer que tu sistema se desbloqueara!!

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.

Uso dd para asignar uno o más archivos grandes para llenar el espacio libre, luego uso una utilidad de borrado seguro.

Para asignar archivos con dd intenta:

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

Esto generará un archivo llamado delete_me que tiene un tamaño de 100 MB. (Aquí bs es el “tamaño de bloque” establecido en 1k, y count es el número de bloques a asignar).

Entonces usa tu utilidad favorita de borrado seguro (he estado usando shred ) en los archivos así creados.

Pero ten en cuenta que este: buffering significa que incluso si haces el disco total, ¡puede que no lo consigas absolutamente todo!

• *

Este enlace recomienda scrub para limpiar el espacio libre. No lo he probado.

Puedes borrar tu espacio libre usando el paquete de borrado seguro.

En ese paquete puedes encontrar la herramienta sfill, que está diseñada para borrar datos que se encuentran en el espacio disponible del disco en soportes de forma segura que no pueden ser recuperados por ladrones, fuerzas de seguridad u otras amenazas.

Para instalar el paquete de borrado seguro en Linux (Ubuntu), instálelo mediante el siguiente comando:

$ sudo apt-get install secure-delete

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

sfill -f -v -ll /YOUR_MOUNTPOINT/OR_DIRECTORY

Donde /TUPUNTO DE MONTAJE/ORDIRECTORIO 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

Probablemente ya tienes el paquete de coreutils GNU instalado en tu sistema. Proporciona el comando shred .

Más fácil es usar scrub :

scrub -X dump

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

No es fácil instalar Scrub ver los foros de Ubuntu sobre esto ), pero una vez que la instalación está hecha, tiene una herramienta realmente SENCILLA y eficiente en su mano.

Aquí está el guión “sdelete.sh” que uso. Vea los 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 en 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.

Es un mito que los datos tengan que ser sobreescritos varias veces (pregúntele a Peter Guntmann) y que los datos aleatorios, a diferencia de los 1 y luego los 0, impliquen una actividad antinatural. El resultado final es un disco limpio con mucho menos tiempo de escritura. Además, los programas de borrado seguro no pueden garantizar que se sobreescriba el archivo real en los sistemas de archivos modernos (journaled). Hágase un favor y consiga Photorec, escanee su disco para ver el desorden, límpielo 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 cuidadosamente de nuevo con el usuario root.

recuerde, la CIA/FBI/NSA no tiene una máquina elegante que pueda leer el estado real de los bits de su medio magnético. todo eso fue sólo un papel escrito hace mucho tiempo. un “qué pasaría si”. sólo tiene que borrar 1 vez.

Esto no es una respuesta! Sólo un comentario para aquellos que deseen usar pv… así que no se molesten en votar.

En Linux Mint 17.3 pueden usar pv (pipe view) para obtener el progreso de 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 tasa de datos continuamente actualizada. La desventaja es que esto se escribe en una línea y cuando el disco está lleno (devolviendo un error) desaparece. Esto sucede porque el tamaño completo es aproximado ya que el sistema operativo probablemente usará el disco mientras se realiza esta operación tan larga, especialmente en el volumen del sistema operativo.

En un disco duro muy antiguo, obtengo una velocidad de datos de unos 13 MB/s al usar /dev/urandom, y de unos 70 MB/s , al usar /dev/zero. Esto probablemente mejoraría aún más cuando se usa un dd crudo o cat, y no pv.

A veces uso este bash de una línea:

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

Cuando empiece a decir que el disco está lleno, sólo presiona Ctrl+C y elimina los archivos zero.* creados.

Funciona en cualquier sistema, sin importar los límites de tamaño de los archivos. Ignora cualquier error del cat: write error: File too large.

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 quieres reemplazar esa secuencia sin sentido por otra secuencia sin sentido, puedo aconsejar algunos productos comerciales para borrar discos con seguridad, como arconis.