Et l'utilisation d'un OS comme un Knoppix sur un CD bootable qui permet de travailler en "virtuel" sans d'installation sur le DD permet-elle de se protéger contrece type d'outil ou reste-t-il toujours des traces dans la mémoire tampon du lecteur CD, dans un dump ou un swap quelconque ?
Un Konoppix MIB permet-il d'accroître la protection ?
Et enfin les nouvelles mémoires non volatiles qu'on nous annonce ne vont certainement pas améliorer la non traçabilité de nos actions informatiques non ?
Merci à vous
SB
Bonjour à tous
Et l'utilisation d'un OS comme un Knoppix sur un CD bootable qui permet de
travailler en "virtuel" sans d'installation sur le DD permet-elle de se
protéger contrece type d'outil ou reste-t-il toujours des traces dans la
mémoire tampon du lecteur CD, dans un dump ou un swap quelconque ?
Un Konoppix MIB permet-il d'accroître la protection ?
Et enfin les nouvelles mémoires non volatiles qu'on nous annonce ne vont
certainement pas améliorer la non traçabilité de nos actions informatiques
non ?
Et l'utilisation d'un OS comme un Knoppix sur un CD bootable qui permet de travailler en "virtuel" sans d'installation sur le DD permet-elle de se protéger contrece type d'outil ou reste-t-il toujours des traces dans la mémoire tampon du lecteur CD, dans un dump ou un swap quelconque ?
Un Konoppix MIB permet-il d'accroître la protection ?
Et enfin les nouvelles mémoires non volatiles qu'on nous annonce ne vont certainement pas améliorer la non traçabilité de nos actions informatiques non ?
Merci à vous
SB
Jeremy JUST
On 30 Jun 2005 13:24:18 GMT "Stephane_Bremant" wrote:
Et l'utilisation d'un OS comme un Knoppix sur un CD bootable qui permet de travailler en "virtuel" sans d'installation sur le DD permet-elle de se protéger contrece type d'outil ou reste-t-il toujours des traces dans la mémoire tampon du lecteur CD, dans un dump ou un swap quelconque ?
Knoppix crée un fichier de swap sur une partition disponible. Ce fichier n'est pas effacé lors de l'arrêt de la machine.
-- Jérémy JUST
On 30 Jun 2005 13:24:18 GMT
"Stephane_Bremant" <Stephane.Bremant@club-internet.fr> wrote:
Et l'utilisation d'un OS comme un Knoppix sur un CD bootable qui
permet de travailler en "virtuel" sans d'installation sur le DD
permet-elle de se protéger contrece type d'outil ou reste-t-il
toujours des traces dans la mémoire tampon du lecteur CD, dans un dump
ou un swap quelconque ?
Knoppix crée un fichier de swap sur une partition disponible. Ce
fichier n'est pas effacé lors de l'arrêt de la machine.
On 30 Jun 2005 13:24:18 GMT "Stephane_Bremant" wrote:
Et l'utilisation d'un OS comme un Knoppix sur un CD bootable qui permet de travailler en "virtuel" sans d'installation sur le DD permet-elle de se protéger contrece type d'outil ou reste-t-il toujours des traces dans la mémoire tampon du lecteur CD, dans un dump ou un swap quelconque ?
Knoppix crée un fichier de swap sur une partition disponible. Ce fichier n'est pas effacé lors de l'arrêt de la machine.
-- Jérémy JUST
Stephane_Bremant
Bonjour et merci pour votre réponse. J'en profite pour quelques éclaircissements supplémentaires SVP ;-)
Knoppix créé ce fichier swap quelle que soit la taille de la RAM ? Peut-on limiter la taille de ce fichier ? Peut-on l'effacer ou le "wiper" à la fin de la session ?
Merci à vous
SB
Knoppix crée un fichier de swap sur une partition disponible. Ce fichier n'est pas effacé lors de l'arrêt de la machine.
Bonjour et merci pour votre réponse. J'en profite pour quelques
éclaircissements supplémentaires SVP ;-)
Knoppix créé ce fichier swap quelle que soit la taille de la RAM ?
Peut-on limiter la taille de ce fichier ?
Peut-on l'effacer ou le "wiper" à la fin de la session ?
Merci à vous
SB
Knoppix crée un fichier de swap sur une partition disponible. Ce
fichier n'est pas effacé lors de l'arrêt de la machine.
Bonjour et merci pour votre réponse. J'en profite pour quelques éclaircissements supplémentaires SVP ;-)
Knoppix créé ce fichier swap quelle que soit la taille de la RAM ? Peut-on limiter la taille de ce fichier ? Peut-on l'effacer ou le "wiper" à la fin de la session ?
Merci à vous
SB
Knoppix crée un fichier de swap sur une partition disponible. Ce fichier n'est pas effacé lors de l'arrêt de la machine.
Cedric Blancher
Le Thu, 30 Jun 2005 19:04:57 +0000, Jeremy JUST a écrit :
Knoppix crée un fichier de swap sur une partition disponible. Ce fichier n'est pas effacé lors de l'arrêt de la machine.
Je ne me souviens pas que Knoppix n'ai jamais modifié une seule partition d'un disque dur de machine sur laquelle je la lançait. D'ailleurs, elle aurait bien été ennuyée sur les stations diskless...
-- M: Ne soyez donc pas inquiets. CEGETEL est en train de revoir en globalité les réseaux et les services. Ca va booster ! TR: Ben voyons! Et nos paupières deviendront lourdes ? -+- in: Guide du Cabaliste Usenet - La Cabale booste (lourdement) -+-
Le Thu, 30 Jun 2005 19:04:57 +0000, Jeremy JUST a écrit :
Knoppix crée un fichier de swap sur une partition disponible. Ce
fichier n'est pas effacé lors de l'arrêt de la machine.
Je ne me souviens pas que Knoppix n'ai jamais modifié une seule partition
d'un disque dur de machine sur laquelle je la lançait. D'ailleurs, elle
aurait bien été ennuyée sur les stations diskless...
--
M: Ne soyez donc pas inquiets. CEGETEL est en train de revoir en
globalité les réseaux et les services. Ca va booster !
TR: Ben voyons! Et nos paupières deviendront lourdes ?
-+- in: Guide du Cabaliste Usenet - La Cabale booste (lourdement) -+-
Le Thu, 30 Jun 2005 19:04:57 +0000, Jeremy JUST a écrit :
Knoppix crée un fichier de swap sur une partition disponible. Ce fichier n'est pas effacé lors de l'arrêt de la machine.
Je ne me souviens pas que Knoppix n'ai jamais modifié une seule partition d'un disque dur de machine sur laquelle je la lançait. D'ailleurs, elle aurait bien été ennuyée sur les stations diskless...
-- M: Ne soyez donc pas inquiets. CEGETEL est en train de revoir en globalité les réseaux et les services. Ca va booster ! TR: Ben voyons! Et nos paupières deviendront lourdes ? -+- in: Guide du Cabaliste Usenet - La Cabale booste (lourdement) -+-
Jeremy JUST
On 01 Jul 2005 18:40:35 GMT Cedric Blancher wrote:
Knoppix crée un fichier de swap sur une partition disponible. Ce fichier n'est pas effacé lors de l'arrêt de la machine. Je ne me souviens pas que Knoppix n'ai jamais modifié une seule
partition d'un disque dur de machine sur laquelle je la lançait.
C'est une Knoppix 3.4, et une partition FAT32 (en hda1). Le fichier créé s'appelle « C:knoppix.swp » et il fait 128 000 Ko (pour 192 Mo de RAM). Je n'ai pas d'informations en plus (en tous cas, je n'ai pas explicitement demandé la création de ce fichier).
Je vois une option de boot « noswap », mais je ne suis pas sûr qu'elle interdise la création d'un fichier de swap.
D'ailleurs, elle aurait bien été ennuyée sur les stations diskless...
Ceci explique peut-être cela... :}
-- Jérémy JUST
On 01 Jul 2005 18:40:35 GMT
Cedric Blancher <blancher@cartel-securite.fr> wrote:
Knoppix crée un fichier de swap sur une partition disponible. Ce
fichier n'est pas effacé lors de l'arrêt de la machine.
Je ne me souviens pas que Knoppix n'ai jamais modifié une seule
partition d'un disque dur de machine sur laquelle je la lançait.
C'est une Knoppix 3.4, et une partition FAT32 (en hda1). Le fichier
créé s'appelle « C:knoppix.swp » et il fait 128 000 Ko (pour 192 Mo de
RAM).
Je n'ai pas d'informations en plus (en tous cas, je n'ai pas
explicitement demandé la création de ce fichier).
Je vois une option de boot « noswap », mais je ne suis pas sûr qu'elle
interdise la création d'un fichier de swap.
D'ailleurs, elle aurait bien été ennuyée sur les stations diskless...
On 01 Jul 2005 18:40:35 GMT Cedric Blancher wrote:
Knoppix crée un fichier de swap sur une partition disponible. Ce fichier n'est pas effacé lors de l'arrêt de la machine. Je ne me souviens pas que Knoppix n'ai jamais modifié une seule
partition d'un disque dur de machine sur laquelle je la lançait.
C'est une Knoppix 3.4, et une partition FAT32 (en hda1). Le fichier créé s'appelle « C:knoppix.swp » et il fait 128 000 Ko (pour 192 Mo de RAM). Je n'ai pas d'informations en plus (en tous cas, je n'ai pas explicitement demandé la création de ce fichier).
Je vois une option de boot « noswap », mais je ne suis pas sûr qu'elle interdise la création d'un fichier de swap.
D'ailleurs, elle aurait bien été ennuyée sur les stations diskless...
Ceci explique peut-être cela... :}
-- Jérémy JUST
Laurent Blume
Cedric Blancher wrote:
Je ne me souviens pas que Knoppix n'ai jamais modifié une seule partition d'un disque dur de machine sur laquelle je la lançait. D'ailleurs, elle aurait bien été ennuyée sur les stations diskless...
J'ai utilisé une démo du JDS/2 de Sun, basé sur une Knoppix, et elle sauvegardait bien des données si elle trouvait une partition qu'elle comprenait. Ce n'était pas seulement du swap, si je me rappelle bien, mais aussi des informations sur la configuration du système, pour ne pas les redemander au boot suivant.
Si elle ne trouvait pas de disque (ou pas de type de partition connu), elle se débrouillait sans.
Laurent
Cedric Blancher wrote:
Je ne me souviens pas que Knoppix n'ai jamais modifié une seule partition
d'un disque dur de machine sur laquelle je la lançait. D'ailleurs, elle
aurait bien été ennuyée sur les stations diskless...
J'ai utilisé une démo du JDS/2 de Sun, basé sur une Knoppix, et elle
sauvegardait bien des données si elle trouvait une partition qu'elle comprenait.
Ce n'était pas seulement du swap, si je me rappelle bien, mais aussi des
informations sur la configuration du système, pour ne pas les redemander au boot
suivant.
Si elle ne trouvait pas de disque (ou pas de type de partition connu), elle se
débrouillait sans.
Je ne me souviens pas que Knoppix n'ai jamais modifié une seule partition d'un disque dur de machine sur laquelle je la lançait. D'ailleurs, elle aurait bien été ennuyée sur les stations diskless...
J'ai utilisé une démo du JDS/2 de Sun, basé sur une Knoppix, et elle sauvegardait bien des données si elle trouvait une partition qu'elle comprenait. Ce n'était pas seulement du swap, si je me rappelle bien, mais aussi des informations sur la configuration du système, pour ne pas les redemander au boot suivant.
Si elle ne trouvait pas de disque (ou pas de type de partition connu), elle se débrouillait sans.
Laurent
Kevin Denis
Le 29-06-2005, Michel Arboi a écrit :
wipe /dev/hda3
Je reste convaincu que dd if=/dev/zero of=/dev/hda3 bsdk sera tout aussi efficace et bien plus rapide.
Une question. Imaginons que je dispose du materiel adequat (tetes de
lectures tres sensibles, salle blanche, etc..)
Cette methode m'apparait comme tres peu fiable: Si je lis un 0 -> 0 Si je lis un zero et des traces de 1 autour -> 1
Maintenant, dd if=/dev/random of=/dev/hda3 est il plus ingenieux?
Et non pas un truc du genre : wipe /home/mon_rep/
Le premier écrase tout, alors que le second va typiquement oublier les entrées du journal
C'est plus vicieux que ça. On retrouve des données après plusieurs cycles de création / effacement, alors que le journal aurait dû être écrasé depuis longtemps. D'ailleurs, les données ne sont pas journalisées sauf avec data=journal, non ? Je suppose que les FS journalisés ont plutôt tendance à réallouer systématiquement les blocs qui composent un fichier quand on le réécrit.
De mémoire, on retrouvait des bouts de vieilles données même après un remplissage de la partition à 100% (sous root, évidemment).
le comportement est assez capricieux et je n'ai pas été fichu de le reproduire rapidement :
# shred /boot/toto.txt
mais shred dit egalement:
CAUTION: Note that shred relies on a very important assumption: that the filesystem overwrites data in place. This is the traditional way to do things, but many modern filesystem designs do not satisfy this assumption. The following are examples of filesystems on which shred is not effective:
* log-structured or journaled filesystems, such as those supplied with AIX and Solaris (and JFS, ReiserFS, XFS, etc.)
(etc..)
-- Kevin
Le 29-06-2005, Michel Arboi <arboi@alussinan.org> a écrit :
wipe /dev/hda3
Je reste convaincu que
dd if=/dev/zero of=/dev/hda3 bsdk
sera tout aussi efficace et bien plus rapide.
Une question. Imaginons que je dispose du materiel adequat (tetes de
lectures tres sensibles, salle blanche, etc..)
Cette methode m'apparait comme tres peu fiable:
Si je lis un 0 -> 0
Si je lis un zero et des traces de 1 autour -> 1
Maintenant, dd if=/dev/random of=/dev/hda3 est il plus ingenieux?
Et non pas un truc du genre :
wipe /home/mon_rep/
Le premier écrase tout, alors que le second va typiquement oublier les
entrées du journal
C'est plus vicieux que ça. On retrouve des données après plusieurs
cycles de création / effacement, alors que le journal aurait dû être
écrasé depuis longtemps. D'ailleurs, les données ne sont pas
journalisées sauf avec data=journal, non ?
Je suppose que les FS journalisés ont plutôt tendance à réallouer
systématiquement les blocs qui composent un fichier quand on le
réécrit.
De mémoire, on retrouvait des bouts de vieilles données même après un
remplissage de la partition à 100% (sous root, évidemment).
le comportement est assez capricieux et je n'ai pas été fichu de le
reproduire rapidement :
# shred /boot/toto.txt
mais shred dit egalement:
CAUTION: Note that shred relies on a very important assumption:
that the filesystem overwrites data in place. This is the traditional
way to do things, but many modern filesystem designs do not satisfy this
assumption. The following are examples of filesystems on which shred is
not effective:
* log-structured or journaled filesystems, such as those supplied with
AIX and Solaris (and JFS, ReiserFS, XFS, etc.)
Je reste convaincu que dd if=/dev/zero of=/dev/hda3 bsdk sera tout aussi efficace et bien plus rapide.
Une question. Imaginons que je dispose du materiel adequat (tetes de
lectures tres sensibles, salle blanche, etc..)
Cette methode m'apparait comme tres peu fiable: Si je lis un 0 -> 0 Si je lis un zero et des traces de 1 autour -> 1
Maintenant, dd if=/dev/random of=/dev/hda3 est il plus ingenieux?
Et non pas un truc du genre : wipe /home/mon_rep/
Le premier écrase tout, alors que le second va typiquement oublier les entrées du journal
C'est plus vicieux que ça. On retrouve des données après plusieurs cycles de création / effacement, alors que le journal aurait dû être écrasé depuis longtemps. D'ailleurs, les données ne sont pas journalisées sauf avec data=journal, non ? Je suppose que les FS journalisés ont plutôt tendance à réallouer systématiquement les blocs qui composent un fichier quand on le réécrit.
De mémoire, on retrouvait des bouts de vieilles données même après un remplissage de la partition à 100% (sous root, évidemment).
le comportement est assez capricieux et je n'ai pas été fichu de le reproduire rapidement :
# shred /boot/toto.txt
mais shred dit egalement:
CAUTION: Note that shred relies on a very important assumption: that the filesystem overwrites data in place. This is the traditional way to do things, but many modern filesystem designs do not satisfy this assumption. The following are examples of filesystems on which shred is not effective:
* log-structured or journaled filesystems, such as those supplied with AIX and Solaris (and JFS, ReiserFS, XFS, etc.)
(etc..)
-- Kevin
Michel Arboi
On Thu Jul 07 2005 at 18:30, Kevin Denis wrote:
Une question. Imaginons que je dispose du materiel adequat (tetes de lectures tres sensibles, salle blanche, etc..)
On peut toujours imaginer n'importe quoi. Tout ce que je vois est qu'une passe avec /dev/zero me protège contre le clampin lambda qui veut relire les données. Ça me suffit. Si l'on croit le fameux papier que tout le monde cite, le coût de recouvrement des données cachées derrière les zéros risque d'être très élevé, donc dissuasif même pour un attaquant qui aurait les moyens techniques. À moins que les données vaillent une fortune, bien sûr... Je ne possède rien de tel sur mes disques durs.
Maintenant, dd if=/dev/random of=/dev/hda3 est il plus ingenieux?
(Il faut lire urandom et pas random, à moins de ne pas être pressé) Une passe avec /dev/urandom ne paraît pas plus efficace qu'une passe avec /dev/zero. Les paranos feront donc plusieurs passes avec plusieurs passes avec urandom, ou utiliseront wipe avec les options qui vont bien.
On Thu Jul 07 2005 at 18:30, Kevin Denis wrote:
Une question. Imaginons que je dispose du materiel adequat (tetes de
lectures tres sensibles, salle blanche, etc..)
On peut toujours imaginer n'importe quoi. Tout ce que je vois est
qu'une passe avec /dev/zero me protège contre le clampin lambda qui
veut relire les données. Ça me suffit.
Si l'on croit le fameux papier que tout le monde cite, le coût
de recouvrement des données cachées derrière les zéros risque d'être
très élevé, donc dissuasif même pour un attaquant qui aurait les
moyens techniques. À moins que les données vaillent une fortune, bien
sûr...
Je ne possède rien de tel sur mes disques durs.
Maintenant, dd if=/dev/random of=/dev/hda3 est il plus ingenieux?
(Il faut lire urandom et pas random, à moins de ne pas être pressé)
Une passe avec /dev/urandom ne paraît pas plus efficace qu'une passe avec
/dev/zero. Les paranos feront donc plusieurs passes avec plusieurs
passes avec urandom, ou utiliseront wipe avec les options qui vont
bien.
Une question. Imaginons que je dispose du materiel adequat (tetes de lectures tres sensibles, salle blanche, etc..)
On peut toujours imaginer n'importe quoi. Tout ce que je vois est qu'une passe avec /dev/zero me protège contre le clampin lambda qui veut relire les données. Ça me suffit. Si l'on croit le fameux papier que tout le monde cite, le coût de recouvrement des données cachées derrière les zéros risque d'être très élevé, donc dissuasif même pour un attaquant qui aurait les moyens techniques. À moins que les données vaillent une fortune, bien sûr... Je ne possède rien de tel sur mes disques durs.
Maintenant, dd if=/dev/random of=/dev/hda3 est il plus ingenieux?
(Il faut lire urandom et pas random, à moins de ne pas être pressé) Une passe avec /dev/urandom ne paraît pas plus efficace qu'une passe avec /dev/zero. Les paranos feront donc plusieurs passes avec plusieurs passes avec urandom, ou utiliseront wipe avec les options qui vont bien.
Thierry Boudet
On 2005-07-10, Michel Arboi wrote:
Une question. Imaginons que je dispose du materiel adequat (tetes de lectures tres sensibles, salle blanche, etc..)
On peut toujours imaginer n'importe quoi. Tout ce que je vois est qu'une passe avec /dev/zero me protège contre le clampin lambda qui veut relire les données. Ça me suffit.
Ne peut-on imaginer que dans certains cas/fs, une écriture de zéros ne provoque que la création d'un 'trou' dans le fichier et que les données ne soient pas effacées physiquement de la surface du disque ?
--
Peer-to-peer, c'est le sujet de ma thèse :) Donc c'est utile, et ca rapporte des diplômes. Et des sous. Ca rapporte une thèse ?
On 2005-07-10, Michel Arboi <arboi@alussinan.org> wrote:
Une question. Imaginons que je dispose du materiel adequat (tetes de
lectures tres sensibles, salle blanche, etc..)
On peut toujours imaginer n'importe quoi. Tout ce que je vois est
qu'une passe avec /dev/zero me protège contre le clampin lambda qui
veut relire les données. Ça me suffit.
Ne peut-on imaginer que dans certains cas/fs, une écriture de
zéros ne provoque que la création d'un 'trou' dans le fichier
et que les données ne soient pas effacées physiquement de la
surface du disque ?
--
Peer-to-peer, c'est le sujet de ma thèse :) Donc c'est utile, et ca
rapporte des diplômes. Et des sous.
Ca rapporte une thèse ?
Une question. Imaginons que je dispose du materiel adequat (tetes de lectures tres sensibles, salle blanche, etc..)
On peut toujours imaginer n'importe quoi. Tout ce que je vois est qu'une passe avec /dev/zero me protège contre le clampin lambda qui veut relire les données. Ça me suffit.
Ne peut-on imaginer que dans certains cas/fs, une écriture de zéros ne provoque que la création d'un 'trou' dans le fichier et que les données ne soient pas effacées physiquement de la surface du disque ?
--
Peer-to-peer, c'est le sujet de ma thèse :) Donc c'est utile, et ca rapporte des diplômes. Et des sous. Ca rapporte une thèse ?
Cedric Blancher
Le Sun, 10 Jul 2005 18:41:38 +0000, Thierry Boudet a écrit :
Ne peut-on imaginer que dans certains cas/fs, une écriture de zéros ne provoque que la création d'un 'trou' dans le fichier et que les données ne soient pas effacées physiquement de la surface du disque ?
Écrire sur le FS pour effacer les données n'est pas forcément une bonne idée, dans la mesure où on n'a pas la garantie à 100% que ce dernier fasse tout ce qu'il faut pour détruire toutes les données. C'est en particulier le cas des FS journalisés qui gardent des informations dans le journal.
Dans le cas présent, Kevin et Michel parlent d'écrire directement sur le device, donc en dessous du FS. Ce qui règle le problème.
--
- Bientot==> Une rubrique membre avec photos - Bientot==> "Un chat on line" pour discuter Si j'amène la photo de mon membre, je pourai caresser le chat ?
-+- FF in Guide du Neuneu Usenet - Cha chanonchait bien pourtant -+-
Le Sun, 10 Jul 2005 18:41:38 +0000, Thierry Boudet a écrit :
Ne peut-on imaginer que dans certains cas/fs, une écriture de
zéros ne provoque que la création d'un 'trou' dans le fichier
et que les données ne soient pas effacées physiquement de la
surface du disque ?
Écrire sur le FS pour effacer les données n'est pas forcément une bonne
idée, dans la mesure où on n'a pas la garantie à 100% que ce dernier
fasse tout ce qu'il faut pour détruire toutes les données. C'est en
particulier le cas des FS journalisés qui gardent des informations dans
le journal.
Dans le cas présent, Kevin et Michel parlent d'écrire directement sur le
device, donc en dessous du FS. Ce qui règle le problème.
--
- Bientot==> Une rubrique membre avec photos
- Bientot==> "Un chat on line" pour discuter
Si j'amène la photo de mon membre, je pourai caresser le chat ?
-+- FF in Guide du Neuneu Usenet - Cha chanonchait bien pourtant -+-
Le Sun, 10 Jul 2005 18:41:38 +0000, Thierry Boudet a écrit :
Ne peut-on imaginer que dans certains cas/fs, une écriture de zéros ne provoque que la création d'un 'trou' dans le fichier et que les données ne soient pas effacées physiquement de la surface du disque ?
Écrire sur le FS pour effacer les données n'est pas forcément une bonne idée, dans la mesure où on n'a pas la garantie à 100% que ce dernier fasse tout ce qu'il faut pour détruire toutes les données. C'est en particulier le cas des FS journalisés qui gardent des informations dans le journal.
Dans le cas présent, Kevin et Michel parlent d'écrire directement sur le device, donc en dessous du FS. Ce qui règle le problème.
--
- Bientot==> Une rubrique membre avec photos - Bientot==> "Un chat on line" pour discuter Si j'amène la photo de mon membre, je pourai caresser le chat ?
-+- FF in Guide du Neuneu Usenet - Cha chanonchait bien pourtant -+-
