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

srm está diseñado para eliminar datos en medios de una manera segura que no pueden recuperar los ladrones, las fuerzas del orden 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 6º 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 pasada con 0xff
• 5 pases aleatorios. /dev/urandom se utiliza para un RNG seguro si está disponible.
• 27 pases con valores especiales definidos por Peter Gutmann.
• 5 pases aleatorios. /dev/urandom se utiliza para un RNG seguro si está disponible.
• Cambie el nombre del 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 un fsync() la llamada está hecha. srm escribe bloques de 32k con el propósito de aumentar la velocidad, llenando búferes de cachés de disco para obligarlos a vaciar y sobrescribir 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

(ejecutar desde un directorio en el sistema de archivos que desea borrar)
_{(el sync El comando 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 de 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 de decenas de segundos si el archivo resultante es grande y está fragmentado, por lo que tarda un tiempo en eliminarse. 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 antiguo sin una costosa operación forense. Para una variante un poco más segura, pero más lenta, reemplace /dev/zero con /dev/urandom . Para más paranoia, ejecute varios pasos con /dev/urandom , aunque si necesita tanto esfuerzo, el shred La utilidad 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 tritura antes de crear el más grande, por lo que se puede eliminar tan pronto como se complete el más grande en lugar de tener que esperar a que se destruya, dejando el sistema de archivos sin espacio libre durante el tiempo que lleva. El proceso de trituración tarda mucho tiempo sobre un archivo grande y, a menos que esté tratando de ocultar algo de la NSA, no es realmente necesario en mi opinión.

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

Límites de tamaño de archivo:

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

Para FAT32 sería definitivamente ser una preocupación debido al límite de archivo 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 el cat /dev/zero grande salida salida 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 4K predeterminado/común, el límite de tamaño de archivo es de 2 TiB, por lo que tendría que tener un enorme volumen para que esto sea un problema (el tamaño de volumen máximo en estas condiciones es de 16 TiB).

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

En NTFS, la longitud máxima del archivo es 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ó recientemente en los comentarios, existen consideraciones adicionales para los dispositivos virtuales:

• Para discos virtuales escasamente asignados, otros métodos como los utilizados por zerofree será más rápido (aunque a diferencia de cat y dd esta no es una herramienta estándar en la que pueda confiar que esté disponible en prácticamente cualquier sistema operativo similar a Unix).

• Tenga en cuenta que poner a cero un bloque en un dispositivo virtual disperso puede no borrar el bloque en el físico subyacente. dispositivo, 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 para que pueda asignarse a otra cosa más adelante.

• Incluso en el caso de dispositivos virtuales de tamaño fijo, es posible que no tenga control sobre dónde reside físicamente el dispositivo, por lo que podría moverse a 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 cualquier ubicación anterior en la que el bloque haya residido en el pasado.

• Para los problemas anteriores en dispositivos virtuales:a menos que controle los hosts y pueda realizar un borrado seguro de su espacio no asignado después de borrar los discos en la VM o mover el dispositivo virtual, no hay nada que pueda hacer al respecto después de la hecho. El único recurso es utilizar el cifrado de disco completo desde el principio por lo tanto, nada sin cifrar se escribe en los medios físicos en primer lugar. Por supuesto, todavía puede haber una llamada para borrar el espacio libre dentro de la máquina virtual. Tenga en cuenta también que FDE puede hacer que los dispositivos virtuales escasos 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 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 conozco ninguna circunstancia en la que esto realmente suceda y un mayor la discusión de eso es un asunto para otro lugar (ya nos estamos acercando a estar fuera del tema de la pregunta original, por lo que si esto ha despertado su interés, es posible que se requieran algunas preguntas de experimentación y/o seguimiento).

ADVERTENCIA

Me sorprendió la cantidad de archivos que Photorec pudo 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 artículo seminal de 1996 sobre trituración escribió un epílogo diciendo que esto es obsoleto e innecesario para el hardware moderno. No hay ningún caso documentado de datos que hayan sido reemplazados físicamente por ceros y recuperados después.

El verdadero vínculo 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 allí . Eso incluye fotos, correos electrónicos personales de texto sin formato, lo que sea. Acabo de buscar en Google reservado+espacio+ext4 y descubrí que el 5 % de mi home la partición 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 de varias pasadas deja 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 desmontarlo).

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.

Vía rápida (recomendado)

Ejecutar 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 las personas.

Manera lenta (paranoico)

No hay ningún caso documentado de recuperación de datos después de la limpieza anterior. Sería costoso y requeriría muchos recursos, si es que 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 todavía querrá hacer el borrado rápido, y eso no es paranoia. La presencia de datos puramente aleatorios es fácil y barata de detectar y genera la sospecha de que en realidad se trata de datos cifrados. Puede morir bajo tortura por no revelar la clave de descifrado.

Manera muy lenta (loco paranoico)

Incluso el autor del artículo seminal de 1996 sobre 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 desperdiciar tu disco con muchas sobreescrituras, 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 fue una reescritura de la de David Spillett. El comando "gato" genera un mensaje de error, pero no puedo escribir comentarios en las publicaciones de otras personas.