Live OS: eliminación segura de archivos

La ejecución de shred en un archivo en la memoria no tiene sentido. También es probable que los datos del archivo estén presentes en la memoria de la aplicación, en los cachés, etc. La memoria que perteneció a un proceso que no se borró cuando el proceso muere: Linux, como la mayoría de los kernels, borra la memoria antes de otorgarla a un proceso, no en el lanzamiento, porque eso es más rápido.

Por supuesto, no hay garantía de que el archivo pueda ser recuperado. Pero tampoco hay garantía de que no pueda. Si su modelo de atacante es que el atacante puede ver el contenido de su RAM, hay muchas cosas que debe cuidar. Como mínimo, debe borrar las páginas de la RAM tan pronto como el proceso las libere. Puede aplicar los parches Grsecurity al kernel de Linux, al menos los PAX_MEMORY_SANITIZE option . Y debe tener cuidado con los procesos que se están ejecutando y puede almacenar información confidencial. Y tenga en cuenta que el kernel también almacena información confidencial, como el estado RNG y las claves de cifrado del disco. El parche TRESOR para el kernel de Linux protege las claves de cifrado del disco durante el funcionamiento normal, pero no es una defensa perfecta. No sé de un parche similar para el estado RNG.

El peligro que está tratando de mitigar es el diario del sistema de archivos, es decir, shred no es efectivo en los sistemas de archivos que tienen un diario (por ejemplo, ext3, ext4, reiserfs).

Suponiendo que no estés usando unionfs para la persistencia (al parecer, puedes hacerlo en Tails, aunque nunca lo intenté), todo se almacena en un tmpfs .

La documentación de linux en tmpfs no detalla si se realiza el registro en diario. Sin embargo, tmpfs se basa en ramfs , el mismo sistema de archivos que se usa en initramfs , y ese sistema de archivos no tiene un diario. Por lo tanto, es (más o menos) seguro asumir que tmpfs no tiene una revista también.

En un sistema de archivos sin un diario, shred realizará la sobrescritura del archivo, lo que dificultará la recuperación con herramientas analíticas (prácticamente imposible recuperarlo de un volcado de RAM). Como todo sucede en las páginas de memoria, y los inodos de tmpfs simplemente apuntan a páginas de memoria, usar shred es mucho mejor porque podrá escribir en estas páginas de memoria.

Advertencia

Lo anterior ciertamente funciona de esta manera en Tails , y en Knoppix . Es probable que funcione de manera similar en casi todas las distribuciones de Linux en LiveCD, incluyendo Kali Linux pero hay una advertencia .

Esto funciona para archivos! La memoria también contendrá la memoria de la aplicación, vea la respuesta de Gilles en la memoria de la aplicación. En serio, mira esa respuesta, abre un punto importante.

También una distro basada en Ubuntu Linux (que puede o no incluir Kali Linux * desde que su predecesora, Backtrack, se basó en Ubuntu) monta cualquier intercambio que encuentre en la máquina que arranca , ¡lo que puede dejar un vector de ataque mucho peor! Datos persistentes en el propio dispositivo!

Otra advertencia con Kali Linux, es que viene con metasploit y arranca la base de datos postgres para usar con metasploit . Postgres tiene su propio registro diario (que se basa en archivos y no en sistemas de archivos), que también puede destruir (es decir, eliminar los archivos de Postgres, no solo eliminar los datos a través de psql ).

_{* Kali no se basa en Ubuntu, se basa en Debian, pero no estoy seguro de si eliminó todos sus scripts de configuración desde el momento en que se llamó Backtrack y se basó en Ubuntu}

Use "shred", elimina a cero los inodos involucrados para que ya no haya datos reales en la RAM. Esto evita los ataques de arranque en frío y los ataques DMA en línea.