[opensuse-es] Destructora de documentos
Hola, César me ha enviado un pantallazo de su nuevo escritorio con suse 11.1. Le ha quedado muy chulo ;-) He visto que tenía un icono que me ha llamado la atención. Se llama (o le ha llamado él) "destructora de documentos". Me ha parecido interesante y he buscado más datos sobre esta aplicación (kgpg-shred) que me han llevado al que creo que es el backend "shred", pero al leer el manual (man shred) indica que con los sistemas de archivos actuales (con journaling) o sistemas con raid, ha perdido su eficacia (entiendo que porque los datos aún permanecen y pueden ser accesibles). ¿Alguien puede aportar más datos sobre esta utilidad, cómo funciona y si sigue siendo útil? :-? Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Me ha parecido interesante y he buscado más datos sobre esta aplicación (kgpg-shred) que me han llevado al que creo que es el backend "shred", pero al leer el manual (man shred) indica que con los sistemas de archivos actuales (con journaling) o sistemas con raid, ha perdido su eficacia (entiendo que porque los datos aún permanecen y pueden ser accesibles).
¿Alguien puede aportar más datos sobre esta utilidad, cómo funciona y si sigue siendo útil? :-? Segun tenia entendido yo,los sistemas ext eran mas dificiles de recuperar los datos que los ntfs
-- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 10/01/09, xevi escribió:
Segun tenia entendido yo,los sistemas ext eran mas dificiles de recuperar los datos que los ntfs
Pues no sé... creo que el ntfs también tiene journaling de transacciones :-? Pero me refería a un borrado a conciencia, no a un borrado circunstancial. Y en ese caso, sí, afortunadamente, del ntfs es más sencillo recuperar datos :-) Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-01-10 a las 16:00 +0100, xevi escribió:
Segun tenia entendido yo,los sistemas ext eran mas dificiles de recuperar los datos que los ntfs
Puede, cuando tratas de recuperar algo borrado por accidente. Pero es relativamente fácil cuando quien trata de recuperar los datos es otra persona que te los quiere robar y tiene mucho interés - que es por lo que se usa "shred". - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklozLMACgkQtTMYHG2NR9V5nwCePzIzt476VgtFhwSXm6GDVMYQ DCIAnjH7rA8CyBiAsAEB+DvokaFXMtsz =+h0r -----END PGP SIGNATURE-----
Tengo entendido, que en laboratorios (supongo que los de la NSA y similares), se puede recuperar la información que estaba escrita en el disco duro después de haberlo sobreescrito uno o dos veces, por este motivo la destructora de documentos escribe varias veces 0 y 1 en los sectores que ocupaba el fichero que se pretende destruir.
Saludos
--- El sáb, 10/1/09, Carlos E. R.
De: Carlos E. R.
Asunto: Re: [opensuse-es] Destructora de documentos Para: "OS-es" Fecha: sábado, 10 enero, 2009 5:28 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-01-10 a las 16:00 +0100, xevi escribió:
Segun tenia entendido yo,los sistemas ext eran mas dificiles de recuperar los datos que los ntfs
Puede, cuando tratas de recuperar algo borrado por accidente. Pero es relativamente fácil cuando quien trata de recuperar los datos es otra persona que te los quiere robar y tiene mucho interés - que es por lo que se usa "shred".
- -- Saludos Carlos E.R.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAklozLMACgkQtTMYHG2NR9V5nwCePzIzt476VgtFhwSXm6GDVMYQ DCIAnjH7rA8CyBiAsAEB+DvokaFXMtsz =+h0r -----END PGP SIGNATURE-----
-- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
2009/1/10, A C:
Tengo entendido, que en laboratorios (supongo que los de la NSA y similares), se puede recuperar la información que estaba escrita en el disco duro después de haberlo sobreescrito uno o dos veces, por este motivo la destructora de documentos escribe varias veces 0 y 1 en los sectores que ocupaba el fichero que se pretende destruir.
El problema es que (según el manual de shred) los datos no están sólo en un sector concreto, sino que están "replicados" o "duplicados" por el sistema de archivos (cuando se usa raid 1 o 5 o sistemas de archivos con registro -journaling- como ext3 o reiserfs). Es decir, entiendo que sí, que borras el archivo de un sector, pero no los del resto, que aún pueden ser accesibles o recuperables :-? Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Hola :) El Saturday 10 January 2009, Camaleón escribió:
2009/1/10, A C:
Tengo entendido, que en laboratorios (supongo que los de la NSA y similares), se puede recuperar la informaci�n que estaba escrita en el disco duro despu�s de haberlo sobreescrito uno o dos veces, por este motivo la destructora de documentos escribe varias veces 0 y 1 en los sectores que ocupaba el fichero que se pretende destruir.
El problema es que (seg�n el manual de shred) los datos no est�n s�lo en un sector concreto, sino que est�n "replicados" o "duplicados" por el sistema de archivos (cuando se usa raid 1 o 5 o sistemas de archivos con registro -journaling- como ext3 o reiserfs).
El principal problema es que los sistemas de fichero con journal "mienten", bueno, realmente no es culpa suya, es culpa del disco duro. "Mesplico". Los discos duros tienen una caché para acelerar el proceso de lectura/escritura entonces, el sistema de ficheros envía una petición de excritura a disco, ese dato queda en la caché del disco duro (realmente no escribe al disco físicamente), pero le dice al sistema de ficheros que sí. A esto sumamos que los sistemas de ficheros con journal suelen hacer un delayed write (puede tener otros nombres). En resumen: cuando le dices al OOo "Save" o "Guardar", no es verdad, ni el sistema de ficheros lo ha guardado ni el disco lo ha guardado realmente. ¿Cómo afecta esto a shred o wipe? Pues que shred o wipe escriben un montón de 0s, 1s y basura y luego resulta que el fichero que habías guardado se escribe encima de toda esa basura porque se ha escrito después. ¿Cómo se evita esto? Reiniciando la máquina y, sin hacer nada más, ejecutas shred y/o wipe (o similar). No se garantiza porque recordad que wipe y shred se ven afectados por el delayed write, es decir, crees que el shred/wipe ha escrito basura al disco, pero en realidad no lo ha hecho (no le ha dado tiempo). Puedes desactivar las cachés del disco ... ah no, que esto es por firmware y lo tiene que hacer el fabricante ... Bueno, puedes ir a una fundición y derretir el disco ;) Otra forma de evitar esto es: no tener backups, que sea un documento super importante de tu jefe (o las fotos del bautizo de la hermana de tu novia o similar, las fotos de tu boda también valen) y lo guardes con un nombre como: "No_borrar" y permisos 0000 y atributo +i. Misteriosamente ... el documento desaparece cuando tu jefe (novia y/o esposa) te piden el documento.
Es decir, entiendo que s�, que borras el archivo de un sector, pero no los del resto, que a�n pueden ser accesibles o recuperables :-?
En el caso del RAID, además tienes que sumar que tienes el bit de paridad también (si es RAID 3, 4, 5, 6, 50) que, en el caso de RAID 5, se reparte por todos los discos y las cachés que puedan tener las controladoras RAID y que también hacen un delayed write. En cuanto a recuperar los datos, hay un par de empresas en España que te recuperan datos de cualquier disco duro. Hace muchos años (antes del Euro) pedí presupuesto por curiosidad, sólo por enviárles el disco y hacerte un presupuesto de lo qu ecostaría estudiar el disco, te cobraban 35 000 pesetas (unos 200 Euros) y aún no se habían puesto manos a la obra, eso era sólo por recibir el disco en sus instalaciones. Eso sí, te recuperaban todo. No sé cuánto costará ahora. Algunas técnicas que usan son: - microscopía electrónica - copia exacta mediante una especie de "espuma" que se imanta y lo pasa a otro disco - mediciones del grado de imantación de la superficie del disco y posterior estadística para determinar si el bloque está a 1 o a 0 (esto les permite obtener incluso ficheros sobre escritos) - desmontar el disco en lugares completamente estancos e impolutos También se pueden recuperar datos de DIMMs de memoria hasta 1 hora después de haber apagado el sistema. Es bastante curioso. Si alguien es muy paranóico, que se vaya a vivir a una isla desierta. HTH Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Lunes, 12 de Enero de 2009, Rafa Grimán escribió:
En cuanto a recuperar los datos, hay un par de empresas en España que te recuperan datos de cualquier disco duro. Hace muchos años (antes del Euro) pedí presupuesto por curiosidad, sólo por enviárles el disco y hacerte un presupuesto de lo qu ecostaría estudiar el disco, te cobraban 35 000 pesetas (unos 200 Euros) y aún no se habían puesto manos a la obra, eso era sólo por recibir el disco en sus instalaciones. Eso sí, te recuperaban todo. No sé cuánto costará ahora.
Pues no se si sera a la que mande un disco de Novell 4.11 con la fat borrada, eso si, era una de las mejores de España. Si recuperaban cobraban un paston. Fueron incapaces de recuperar nada. Con el tiempo e investigando consegui recuperar casi la mitad. En otra ocasion lo mande a otra empresa que si que se podia que te lo recupero todo. Me manda un listado con los directorios a recuperar, mas de 1 millon de ficheros (cuando en realidad no pasaban de los 50mil). Nos mando unas pruebas y no funcionaba ninguno, como el jefe no le pago no nos devolvio el disco, asi que no pude hacer pruebas Menos mal que en esa ocasion se recupero la informacion por otro lado. Lo digo por eso de mucha tecnologia de recuperacion, pero a la hora de la verdad se te encoje el corazon cuando te dicen que na de na. Y piensas ¿ para eso tanta propaganda?, cuando de verdad lo necesitas no funcionan -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On Mon, Jan 12, 2009 at 7:54 AM, Rafa Grimán
Hola :)
El Saturday 10 January 2009, Camaleón escribió:
2009/1/10, A C:
Tengo entendido, que en laboratorios (supongo que los de la NSA y similares), se puede recuperar la información que estaba escrita en el disco duro después de haberlo sobreescrito uno o dos veces, por este motivo la destructora de documentos escribe varias veces 0 y 1 en los sectores que ocupaba el fichero que se pretende destruir.
El problema es que (según el manual de shred) los datos no están sólo en un sector concreto, sino que están "replicados" o "duplicados" por el sistema de archivos (cuando se usa raid 1 o 5 o sistemas de archivos con registro -journaling- como ext3 o reiserfs).
El principal problema es que los sistemas de fichero con journal "mienten", bueno, realmente no es culpa suya, es culpa del disco duro.
"Mesplico". Los discos duros tienen una caché para acelerar el proceso de lectura/escritura entonces, el sistema de ficheros envía una petición de excritura a disco, ese dato queda en la caché del disco duro (realmente no escribe al disco físicamente), pero le dice al sistema de ficheros que sí. A esto sumamos que los sistemas de ficheros con journal suelen hacer un delayed write (puede tener otros nombres).
En resumen: cuando le dices al OOo "Save" o "Guardar", no es verdad, ni el sistema de ficheros lo ha guardado ni el disco lo ha guardado realmente.
¿Cómo afecta esto a shred o wipe? Pues que shred o wipe escriben un montón de 0s, 1s y basura y luego resulta que el fichero que habías guardado se escribe encima de toda esa basura porque se ha escrito después.
no hay mucho sentido en lo que hablas... se tengo algun dato en la cache (sea del SO o de la controladora) y envio otro dato para sobrescribirlo.. esto queda encolado.. no va el segundo comando escribir en el disco antes que el primero comando !!! :(
¿Cómo se evita esto? Reiniciando la máquina y, sin hacer nada más, ejecutas shred y/o wipe (o similar). No se garantiza porque recordad que wipe y shred se ven afectados por el delayed write, es decir, crees que el shred/wipe ha escrito basura al disco, pero en realidad no lo ha hecho (no le ha dado tiempo).
esto es cierto... se debe de rellenar la cache de la controladora y/o forzala a escribir en el disco !!! en este caso, un reinicio no garantiza que los datos seran "escritos/borrados" en el disco, ya que algunas controladoras tienen cache muy grandes. salu2 -- -- Victor Hugo dos Santos Linux Counter #224399 -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Monday 12 January 2009, Victor Hugo dos Santos escribió:
On Mon, Jan 12, 2009 at 7:54 AM, Rafa Grim�n
wrote: Hola :)
El Saturday 10 January 2009, Camale�n escribi�:
2009/1/10, A C:
Tengo entendido, que en laboratorios (supongo que los de la NSA y similares), se puede recuperar la informaci�n que estaba escrita en el disco duro despu�s de haberlo sobreescrito uno o dos veces, por este motivo la destructora de documentos escribe varias veces 0 y 1 en los sectores que ocupaba el fichero que se pretende destruir.
El problema es que (seg�n el manual de shred) los datos no est�n s�lo en un sector concreto, sino que est�n "replicados" o "duplicados" por el sistema de archivos (cuando se usa raid 1 o 5 o sistemas de archivos con registro -journaling- como ext3 o reiserfs).
El principal problema es que los sistemas de fichero con journal "mienten", bueno, realmente no es culpa suya, es culpa del disco duro.
"Mesplico". Los discos duros tienen una cach� para acelerar el proceso de lectura/escritura entonces, el sistema de ficheros env�a una petici�n de excritura a disco, ese dato queda en la cach� del disco duro (realmente no escribe al disco f�sicamente), pero le dice al sistema de ficheros que s�. A esto sumamos que los sistemas de ficheros con journal suelen hacer un delayed write (puede tener otros nombres).
En resumen: cuando le dices al OOo "Save" o "Guardar", no es verdad, ni el sistema de ficheros lo ha guardado ni el disco lo ha guardado realmente.
�C�mo afecta esto a shred o wipe? Pues que shred o wipe escriben un mont�n de 0s, 1s y basura y luego resulta que el fichero que hab�as guardado se escribe encima de toda esa basura porque se ha escrito despu�s.
no hay mucho sentido en lo que hablas... se tengo algun dato en la cache (sea del SO o de la controladora) y envio otro dato para sobrescribirlo.. esto queda encolado.. no va el segundo comando escribir en el disco antes que el primero comando !!!
:(
Se pueden reordenar las escrituras a disco de forma que las que tienen prioridad se escriban antes. Algunas controladoras que hacen copias síncronas entre discos permiten esto, los sistemas de ficheros también. Esto, por ejemplo es útil para que un sistema disaster recovery o business continuance de BBDD escriba lo mismo al mismo tiempo y en la misma secuencia.
�C�mo se evita esto? Reiniciando la m�quina y, sin hacer nada m�s, ejecutas shred y/o wipe (o similar). No se garantiza porque recordad que wipe y shred se ven afectados por el delayed write, es decir, crees que el shred/wipe ha escrito basura al disco, pero en realidad no lo ha hecho (no le ha dado tiempo).
esto es cierto... se debe de rellenar la cache de la controladora y/o forzala a escribir en el disco !!! en este caso, un reinicio no garantiza que los datos seran "escritos/borrados" en el disco, ya que algunas controladoras tienen cache muy grandes.
HTH Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-01-10 a las 15:50 +0100, Camaleón escribió:
¿Alguien puede aportar más datos sobre esta utilidad, cómo funciona y si sigue siendo útil? :-?
Yo tengo la versión casera: lata de 8 litros de aceite de oliva, con agujero grande de ventilación a 5 cm del fondo, rejilla de alambre por encima, y tapa quitada. Se meten los papeles por encima y se les prende fuego. Úsese en local ventilado, preferiblemente al exterior. Precaución: genera calor poco controlado y potencialmente peligroso. También puede generar protestas airadas de los vecinos. Al terminar, agítense los subproductos para garantizar que el resultado sea óptimo (es a prueba de CSIs y mirones). La versión profesional cuesta una pastita, y requiere obra para la evacuación de subproductos gaseosos, pero sirve para calefacción de locales. Precaución: observar su funcionamiento es adictivo. :-P Vale, ya, si ya se de lo que hablas. Lo que dices es de utilidad limitada porque puede haber archivos temporales que escapan a la destrucción (tanto /tmp como las copias anteriores del documento, y borradas automáticamente), y porque si usas un sistema de archivos con diario de no sólo "metadatos", este contendrá los datos por un tiempo relativamente corto pero impredecible. Para completar la seguridad tendrías que usar, al menos, directorios encriptados de trabajo y temporal. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklozDAACgkQtTMYHG2NR9XSjQCfWyELiA39l3TtSaJHBp8+GO8+ nRMAni+TtA8TqYUgzRDWbd8cNezPbwAr =LUMc -----END PGP SIGNATURE-----
El 10/01/09, Carlos E. R. escribió:
Yo tengo la versión casera: lata de 8 litros de aceite de oliva, con agujero grande de ventilación a 5 cm del fondo, rejilla de alambre por encima, y tapa quitada. Se meten los papeles por encima y se les prende fuego. Úsese en local ventilado, preferiblemente al exterior. Precaución: genera calor poco controlado y potencialmente peligroso. También puede generar protestas airadas de los vecinos. Al terminar, agítense los subproductos para garantizar que el resultado sea óptimo (es a prueba de CSIs y mirones).
¿Papel...? ¿Papel digital? >:-P
La versión profesional cuesta una pastita, y requiere obra para la evacuación de subproductos gaseosos, pero sirve para calefacción de locales. Precaución: observar su funcionamiento es adictivo.
Pamplinas :-P Ahora la moda es gritarle a los discos para aumentar la latencia y aumentar así las transacciones de I/O... Unusual disk latency http://blogs.sun.com/brendan/entry/unusual_disk_latency Eso con un gritito de nada... si les pones un "chumba-chumba", con el reiserfs y el beagle los dejas lentorros de cuidado >:-)
Vale, ya, si ya se de lo que hablas. Lo que dices es de utilidad limitada porque puede haber archivos temporales que escapan a la destrucción (tanto /tmp como las copias anteriores del documento, y borradas automáticamente), y porque si usas un sistema de archivos con diario de no sólo "metadatos", este contendrá los datos por un tiempo relativamente corto pero impredecible.
Para completar la seguridad tendrías que usar, al menos, directorios encriptados de trabajo y temporal.
Okis :-) Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
participants (7)
-
A C
-
Camaleón
-
Carlos E. R.
-
francisco f
-
Rafa Grimán
-
Victor Hugo dos Santos
-
xevi