¿Qué sucede cuando uso 'dd' para sobrescribir el disco desde el que se ejecuta Ubuntu?

¿Qué pasaría si uso

sudo dd if=/dev/zero of=/dev/sda

desde una instalación de Ubuntu que se ejecuta desde /dev/sda ?

Lo probé en una máquina virtual y parece haber limpiado correctamente el disco. ¿Será este el caso cada vez? ¿Es esta una forma segura de "borrar" una instalación de Ubuntu y todos los datos?

Mi pregunta está algo inspirada por:

1. ¿Cómo desinstalo Ubuntu de una computadora?
2. ¿Cómo es 'rm -rf /' capaz de eliminar todos los archivos en el sistema? .

En realidad, el sistema de archivos aún está montado, y algunas escrituras están almacenadas en búfer, lo que significa que todavía están en la RAM esperando ser escritas en el disco. Digamos que ddsobrescribe correctamente todo, y justo detrás de él, los buffers se vuelven vacíos y algunos datos potencialmente confidenciales se vuelven a escribir en el disco. Entonces no, esta no es una forma segura de limpiar un disco.

Puede evitar este problema volviendo a montar en modo de solo lectura el sistema de archivos raíz y cualquier otro sistema de archivos que esté en el disco (o desmontándolos por completo, pero no podrá hacerlo con el sistema de archivos raíz), y luego, no Se deben permitir más escrituras en los sistemas de archivos (para que no haya búferes que vaciar), por lo que su comando debe estar seguro ahora, aunque todavía es una mala idea en caso de pánico porque lleva mucho tiempo.

Si desea tener algún tipo de función de eliminación de pánico, sugiero cifrar su disco con LUKS (el instalador de Ubuntu puede hacerlo) y luego seguir mi respuesta en Security Stack Exchange . Esto implica limpiar el cryptheader que tiene solo 2 MB de tamaño y que lleva menos de un segundo sobrescribir. Luego, reinicie el sistema y las claves de cifrado del disco desaparecerán de la memoria, sin formas de restaurarlas, ya que el encriptador en sí también desapareció.

Sacrifiqué una VM usando un uso un poco más avanzado de ddprestado y ligeramente modificado de las páginas de Arch Wiki .

Primero instale un buen medidor de progreso:

sudo apt-get install pv

Y luego ejecute el ddcomando 'mejorado'

sudo openssl enc -aes-256-ctr -pass pass:"$(dd if=/dev/urandom bs=128 count=1 2>/dev/null \
| base64)" -nosalt </dev/zero \
| pv -bartpes "$(sudo blockdev --getsize64 /dev/sda)" \
| sudo dd bs=64K of=/dev/sda

Esto dejará el disco lleno de texto cifrado AES. ¿Un borrado de disco completo y seguro? Probablemente mejor que su propio ddejemplo, pero nada es completamente seguro o garantizado ...

Y me debes una VM :)

Referencias

• Arco: Limpie de forma segura el disco
• Arch: dd - Ejemplo avanzado

Respuesta corta: hará aproximadamente lo que quieras y luego nada funcionará. Usar ddestá operando a un nivel por debajo del sistema de archivos, lo que significa que las restricciones que se aplicarían allí ya no son relevantes (esto no significa que el núcleo no pueda evitar que lo haga, pero no lo hace). Parte del contenido del sistema de archivos ya está en la memoria, por ejemplo, el núcleo y el ddprograma en sí, y algunos estarán en caché. Existe la posibilidad de que si el sistema está en modo multiusuario, algunos archivos se pueden volver a escribir mientras ddestá en progreso, suponiendo que realmente hayan cambiado, y si está bajo presión de memoria, algunas páginas de allí también pueden intercambiarse (deben estar encriptados y, por lo tanto, inutilizables después del reinicio).

La mayoría de los comandos que emitiría después de esto, incluido reboot, no estarían en la caché y, por lo tanto, no funcionarían. Entonces, si está en modo de usuario único, lo hará extremadamente bien, si está en modo multiusuario, borrará la gran mayoría de los datos. Idealmente, debe hacerlo arrancado desde otro medio (incluso deteniéndose en el initrd tal vez) para que pueda estar seguro de dónde provienen todas las escrituras.

Si desea un borrado seguro, esto no hará el trabajo porque aún quedarán algunos rastros de los datos originales si simplemente lo pone a cero. Por lo general, desearía hasta tres escrituras aleatorias, lo que significaría copiar desde en /dev/urandomlugar de /dev/zero- mucho más lento pero más seguro. Algunos pueden sugerir que utilice /dev/randomcuál es el dispositivo para datos aleatorios "puros", no pseudoaleatorios, pero para este propósito, la posibilidad de que alguien logre descifrar la semilla PRNG y enmascarar con éxito los datos es esencialmente insignificante.

Si eres realmente paranoico, debes tirar el dispositivo de almacenamiento en un horno para que se desmagnetice / descargue.

Como lo hizo en su VM, borrará el disco e inutilizará su sistema.

Sin embargo, si tiene una especie de "eliminación de pánico" en mente, ddpuede que no sea lo suficientemente rápido para eso y no estoy seguro de si hay comandos o programas más rápidos que lo proporcionen en ese caso.

Debería funcionar, el proceso de ejecución se lleva a cabo en Ram y no necesita el disco. Usaría un sistema en vivo que se ejecute desde cd o usb de todos modos. Incluso hay dban, un Linux en vivo especializado para limpiar discos.

Sobrescribir su disco con ceros es un ahorro, pero si es lo suficientemente paranoico o tiene reglas legales, puede sobrescribir con datos aleatorios varias veces.

Tenga cuidado al usar la sobrescritura de ssd no garantiza la eliminación de todos los datos debido a la nivelación del desgaste.

Si utiliza el cifrado de disco completo (luks), no es necesario que elimine el disco completo, basta con eliminar el encabezado de luks.