Seguridad de la utilidad Linux shred

2

Si estoy intentando destruir un solo archivo, ¿cuál es el mejor método?

shred -uvz -n500 file
dd if=/dev/null of=file
dd if=/dev/zero of=file

Heché un archivo que estaba en el medio de la trituración, y fue apropiadamente destrozado con lo que shred dijo que estaba escribiendo, pero ¿es seguro?

Por el bien de este experimento, supongamos que todas las versiones en caché de este archivo y cualquier otra cosa que pueda conectarse a este archivo han desaparecido por completo. La única traza restante del archivo es el comando ejecutado desde mi historial ...

    
pregunta user50625 10.07.2014 - 00:52
fuente

1 respuesta

4

Dependiendo del sistema de archivos, dispositivo físico, etc., tendrán diferentes niveles de efectividad. Echaré un vistazo a cada uno y, en general, estoy asumiendo que ext4 en el disco duro magnético, ya que es el Linux FS predeterminado más común en este momento. También asumo que la recuperación comienza inmediatamente después de que se completa el comando: es decir, no hay escrituras intermedias en este sistema de archivos.

  

shred -uvz -n500 file

500 pases es una exageración. En general, se cree que una sola pasada es suficiente en las unidades modernas ( Source 1 , Source 2 , Source 3 ), por lo que las 3 ofertas de trituración de pases por defecto deberían ser suficientes. Por supuesto, esto supone que se está sobrescribiendo en el lugar (los mismos bloques de disco), lo cual es cierto para las configuraciones predeterminadas de ext4. Si tienes opciones de montaje impares (como journal=data ), verás que esto ya no es cierto y que cualquier forma de sobrescritura no será suficiente a menos que sobrescribas toda la partición.

  

dd if=/dev/null of=file

/ dev / null da EOF al leer. En consecuencia, esto solo trunca el archivo, que es equivalente a echo -n ''>file . Todos los bloques de datos permanecerán en el disco y se podrán recuperar. Si el archivo no está fragmentado (todos los bloques de datos son consecutivos) esto es trivial, si está fragmentado, puede tomar mucho más trabajo reconstruir el archivo.

  

dd if=/dev/zero of=file

De forma predeterminada (a menos que se pase conv=notrunc ), dd abre el archivo de salida con O_TRUNC , lo que hace que el sistema de archivos desasigne inmediatamente los bloques existentes del archivo, luego comienza a escribir, lo que desencadena nuevas asignaciones. ¿Serán los mismos bloques liberados por el truncamiento? Tal vez tal vez no. Depende de la cantidad de espacio libre, si el archivo se fragmentó y las opciones de montaje ahora y en el momento en que se creó el archivo. (La activación / desactivación de las extensiones sería una gran diferencia). Además, este comando, como se indica, no especifica ningún punto para detenerlo: seguirá escribiendo hasta que la partición esté llena. (Lo que realmente te da una buena oportunidad de sobrescribir tus bloques de datos, pero probablemente tomará mucho más tiempo del que es conveniente).

Finalmente, no especificaste en qué medios estás haciendo esto. Asumí un disco magnético arriba porque la respuesta es mucho más directa. En un SSD, es un mundo completamente diferente. La nivelación de desgaste significa que nunca va a sobrescribir los mismos bloques, y hay muchos bloques que existen pero que no son visibles desde el sistema operativo. Incluso las características de seguridad integradas de los SSD no necesariamente borrarán sus datos. En el caso de un SSD, mi mejor recomendación es cifrar con una contraseña segura, y cuando esté listo para reciclar la unidad, péguela con una sobrescritura de ceros y un borrado seguro de ATA. Entre los dos, hay muchas posibilidades de que hayas destruido la llave maestra, e incluso si no lo has hecho, la recuperación forense será muy dudosa.

    
respondido por el David 10.07.2014 - 01:46
fuente

Lea otras preguntas en las etiquetas