Ce n'est pas un appel à voter. Ne pas voter pour le moment.
Tous les messages de discussion doivent être postés exclusivement dans
fr.usenet.forums.evolution, forum dédié à la discussion de propositions de
nouveaux forums de discussions.
NOM : fr.comp.securite.divers
STATUT : non modéré
DESCRIPTION : Informations et idées sur la sécurité informatique.
LANGUE : français
OBJET :
Ce groupe de discussion, dont le statut non modéré définit la nature, a pour
thème la sécurité informatique.
RAISON :
La sécurité informatique comprend une dimension qui implique qu'un grand
nombre d'acteurs et de penseurs de ce domaine refusent de participer à des
groupes contrôlés par un modérateur. En ce sens, fr.comp.securite peut ne
pas répondre à tous les besoins de s'exprimer sur le sujet. De même, un
groupe non modéré présente plus de spontanéité et de dynamisme.
Le vide est d'autant marquant qu'on constate que les langues anglaises et
allemandes disposent d'espaces non modérés sur le sujet, vers lesquels se
dirigent des francophones.
fr.comp.securite.divers se propose de combler ce vide et offrir un espace
alternatif où chacun pourra s'exprimer sur ce sujet passionnant dans un
cadre souple, simple et spontané.
QUELQUES RAPPELS DE BON USAGE :
Les règles en usage sur usenet et relatives à la hiérarchie fr s'appliquent
à ce forum.
Il convient de garder à l'esprit que :
- ce forum est francophone; il est possible de doubler une contribution dans
une autre langue, mais l'usage exclusif de celle-ci est inconvenant.
- les attachements de tous types et les formats HTML sont à proscrire.
- les annonces commerciales et les spams sont indésirables.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Stephane Catteau
n'était pas loin de dire :
Je me permet de faire suivre sur fcs, car voilà bien un débat qu'il est intéressant...
[...] Il est à ce sujet à noter qu'en sécurité informatique, on peut aimer le bruit - car des données sont bien gardées dans le bruit.
En quoi le bruit peut-il apporter quoi que ce soit de positif en matière de sécurité informatique ? Le bruit, ce sont des centaines de "BONK" dans les logs du filtre IP, dans les logs de SSH, dans les logs de l'IDS, dans... partout en fait. Le bruit, c'est tout ce qui parasite les systèmes de détection et permet donc à un pirate de tromper la vigilance de l'admin qu'il a en face de lui. Evidement, et fort heureusement, il est possible de filtrer ce bruit, mais dieu qu'il est facile de trop filtrer par mégarde. il suffit d'avoir eu à faire face aux piques que furent CodeRed ou SQL Slammer, pour comprendre que l'on fini très vite par craquer face à une saturation de bruit, et comprendre combien il est facile alors à un pirate de se glisser au milieu de la mélée et d'y passer plus inaperçu que d'habitude.
Fu2 fcs
lgr_joly@yahoo.com n'était pas loin de dire :
Je me permet de faire suivre sur fcs, car voilà bien un débat qu'il
est intéressant...
[...] Il est à ce sujet à noter qu'en sécurité informatique,
on peut aimer le bruit - car des données sont bien gardées dans le
bruit.
En quoi le bruit peut-il apporter quoi que ce soit de positif en
matière de sécurité informatique ? Le bruit, ce sont des centaines de
"BONK" dans les logs du filtre IP, dans les logs de SSH, dans les logs
de l'IDS, dans... partout en fait. Le bruit, c'est tout ce qui parasite
les systèmes de détection et permet donc à un pirate de tromper la
vigilance de l'admin qu'il a en face de lui.
Evidement, et fort heureusement, il est possible de filtrer ce bruit,
mais dieu qu'il est facile de trop filtrer par mégarde. il suffit
d'avoir eu à faire face aux piques que furent CodeRed ou SQL Slammer,
pour comprendre que l'on fini très vite par craquer face à une
saturation de bruit, et comprendre combien il est facile alors à un
pirate de se glisser au milieu de la mélée et d'y passer plus inaperçu
que d'habitude.
Je me permet de faire suivre sur fcs, car voilà bien un débat qu'il est intéressant...
[...] Il est à ce sujet à noter qu'en sécurité informatique, on peut aimer le bruit - car des données sont bien gardées dans le bruit.
En quoi le bruit peut-il apporter quoi que ce soit de positif en matière de sécurité informatique ? Le bruit, ce sont des centaines de "BONK" dans les logs du filtre IP, dans les logs de SSH, dans les logs de l'IDS, dans... partout en fait. Le bruit, c'est tout ce qui parasite les systèmes de détection et permet donc à un pirate de tromper la vigilance de l'admin qu'il a en face de lui. Evidement, et fort heureusement, il est possible de filtrer ce bruit, mais dieu qu'il est facile de trop filtrer par mégarde. il suffit d'avoir eu à faire face aux piques que furent CodeRed ou SQL Slammer, pour comprendre que l'on fini très vite par craquer face à une saturation de bruit, et comprendre combien il est facile alors à un pirate de se glisser au milieu de la mélée et d'y passer plus inaperçu que d'habitude.
Fu2 fcs
Cedric Blancher
Le Mon, 13 Mar 2006 15:19:38 +0000, Stephane Catteau a écrit :
En quoi le bruit peut-il apporter quoi que ce soit de positif en matière de sécurité informatique ?
Imagine un tunnel IPSEC par lequel transitent des données, comme des ordres dont le contenu peut influencer... disons des cours de bourse. L'observation du trafic généré par l'envoi de données dans le tube peut donc renseigner sur la future évolution du cours d'un action, en le croisant avec l'actualité et autres rumeurs. Si par contre, on force la circulation de bruit dans le tunnel, on linéarise les mouvements de trafic et on rend plus difficile ce genre d'attaque.
Maintenant, application plus proche de notre quotidien, les systèmes de remailing anonymes. Les remailers de type I sont vulnérables à l'observation temporelle. Ça permet à un (super)observateur de tracer le trajet des données en regardant quand des paquets de données entrent et sortent de noeuds. Pour palier ce type d'attaque, les remailers de type II essayent de masquer le trafic en produisant une sortie proche du bruit. On introduit des délais, on linéarise le débit, on regroupe les fragments, etc. Ici, on copie le bruit.
Donc oui, dans certaines conditions, le bruit est utile. Ici pour dissimuler un envoi de données, là parce que le trafic réel ressemble à du bruit. En fait, ça vient du fait que même si on n'a pas accès directement à l'information observée, le fait d'observer les conditions dans lesquelles elle existe permet de déduire pleins de choses souvent très intéressantes. D'ailleurs, même sa non-existence est intéressante :)
-- BOFH excuse #391:
We already sent around a notice about that.
Le Mon, 13 Mar 2006 15:19:38 +0000, Stephane Catteau a écrit :
En quoi le bruit peut-il apporter quoi que ce soit de positif en
matière de sécurité informatique ?
Imagine un tunnel IPSEC par lequel transitent des données, comme des
ordres dont le contenu peut influencer... disons des cours de bourse.
L'observation du trafic généré par l'envoi de données dans le tube
peut donc renseigner sur la future évolution du cours d'un action, en le
croisant avec l'actualité et autres rumeurs.
Si par contre, on force la circulation de bruit dans le tunnel, on
linéarise les mouvements de trafic et on rend plus difficile ce genre
d'attaque.
Maintenant, application plus proche de notre quotidien, les systèmes de
remailing anonymes. Les remailers de type I sont vulnérables à
l'observation temporelle. Ça permet à un (super)observateur de tracer le
trajet des données en regardant quand des paquets de données entrent et
sortent de noeuds. Pour palier ce type d'attaque, les remailers de type II
essayent de masquer le trafic en produisant une sortie proche du bruit. On
introduit des délais, on linéarise le débit, on regroupe les fragments,
etc. Ici, on copie le bruit.
Donc oui, dans certaines conditions, le bruit est utile. Ici pour
dissimuler un envoi de données, là parce que le trafic réel ressemble
à du bruit. En fait, ça vient du fait que même si on n'a pas accès
directement à l'information observée, le fait d'observer les conditions
dans lesquelles elle existe permet de déduire pleins de choses souvent
très intéressantes. D'ailleurs, même sa non-existence est intéressante :)
Le Mon, 13 Mar 2006 15:19:38 +0000, Stephane Catteau a écrit :
En quoi le bruit peut-il apporter quoi que ce soit de positif en matière de sécurité informatique ?
Imagine un tunnel IPSEC par lequel transitent des données, comme des ordres dont le contenu peut influencer... disons des cours de bourse. L'observation du trafic généré par l'envoi de données dans le tube peut donc renseigner sur la future évolution du cours d'un action, en le croisant avec l'actualité et autres rumeurs. Si par contre, on force la circulation de bruit dans le tunnel, on linéarise les mouvements de trafic et on rend plus difficile ce genre d'attaque.
Maintenant, application plus proche de notre quotidien, les systèmes de remailing anonymes. Les remailers de type I sont vulnérables à l'observation temporelle. Ça permet à un (super)observateur de tracer le trajet des données en regardant quand des paquets de données entrent et sortent de noeuds. Pour palier ce type d'attaque, les remailers de type II essayent de masquer le trafic en produisant une sortie proche du bruit. On introduit des délais, on linéarise le débit, on regroupe les fragments, etc. Ici, on copie le bruit.
Donc oui, dans certaines conditions, le bruit est utile. Ici pour dissimuler un envoi de données, là parce que le trafic réel ressemble à du bruit. En fait, ça vient du fait que même si on n'a pas accès directement à l'information observée, le fait d'observer les conditions dans lesquelles elle existe permet de déduire pleins de choses souvent très intéressantes. D'ailleurs, même sa non-existence est intéressante :)
-- BOFH excuse #391:
We already sent around a notice about that.
Fabien LE LEZ
On 13 Mar 2006 23:05:09 GMT, Cedric Blancher :
Donc oui, dans certaines conditions, le bruit est utile.
Encore faut-il avoir, à l'arrivée, la possibilité de filtrer automatiquement ce bruit.
On 13 Mar 2006 23:05:09 GMT, Cedric Blancher
<blancher@cartel-securite.fr>:
Donc oui, dans certaines conditions, le bruit est utile.
Encore faut-il avoir, à l'arrivée, la possibilité de filtrer
automatiquement ce bruit.
Donc oui, dans certaines conditions, le bruit est utile.
Encore faut-il avoir, à l'arrivée, la possibilité de filtrer automatiquement ce bruit.
Stephane Catteau
Cedric Blancher devait dire quelque chose comme ceci :
[Snip]
Si par contre, on force la circulation de bruit dans le tunnel, on linéarise les mouvements de trafic et on rend plus difficile ce genre d'attaque.
En mettant volontairement de côté le fait qu'une répétition d'un motif unique fragiliserait fortement le tunnel, ce qui force le "bruit" à avoir un fort caractère aléatoire, je me pose quand même la question, est-ce vraiment du bruit ? Après tout, et si j'ai bien compris, le but est de garantir qu'il y aura toujours X bps qui circuleront par ce tunnel. Donc, le-dit tunnel peut être assimilé à une structure de données utilisant des enregistrement de taille fixe, comme il y en a encore beaucoup en informatique. Un enregistrement correspondrait à une seconde de temps, les données envoyées aux données stockées dans l'enregistrement, et le bruit aux 0 qui complètent le champ dans les formats de données plus traditionnels. Une suite de zéro peut-elle être considérée comme du bruit, qui plus est lorsqu'elle est générée volontairement et restreinte à un espace clairement défini ?
Donc oui, dans certaines conditions, le bruit est utile. Ici pour dissimuler un envoi de données, là parce que le trafic réel ressemble à du bruit. En fait, ça vient du fait que même si on n'a pas accès directement à l'information observée, le fait d'observer les conditions dans lesquelles elle existe permet de déduire pleins de choses souvent très intéressantes.
J'ai un autre exemple, plus proche encore de la sécurité informatique. Le bruit de fond de plus en plus sonore que l'on trouve sur internet permet de réduire le nombre de machines dont la pile IP n'a qu'une faible activité. Du coup, il est plus difficile de faire un scanne de port en envoyant des paquets spoofés et en observant les réactions de la pile IP de la machine à qui appartient l'adresse IP (désolé, le nom du scan m'échappe).
Cela dit, j'avais plutôt l'impression que l'intervenant initial assimilait le bruit à l'obscurité. A savoir que plus il y a de bruit autour de nous, moins les méchants peuvent savoir ce que l'on fait. Or, cela me semble un brin casse-gueule. Benoit Leraillez prenait l'exemple d'un concert qui couvrirait parfaitement les propos que l'on pourrait vouloir garder secret, mais il y a une contre-partie, l'on ne peut pas être sûr que l'autre a compris ce que l'on a dit. A titre d'exemple, lorsque l'on dispose de tout son temps, pourquoi ne pas placer quelques zombies, de préférence sur des machines ayant des adresses IP dynamique, et les laisser scanner la cible, voir lancer de mini attaques baclées, pendant un mois. A force de voir ses logs transformés en sapin un soir de noël, il y a des chances pour que l'admin ne prête pas suffisement attention aux alertes lorsque l'attaque sera vraiment lancée. De même, imagine qu'Apache ait eu une faille unicode en même temps qu'IIS. Si l'on ajoute la chaîne clé qui a été diffusée pour permettre de filtrer CodeRed dans ses logs, à la chaîne utilisée pour exploiter la faille d'Apache, combien d'admin se seraient-ils retrouvés aveugles ? Evidement, ce n'est pas forcément quelque chose de trivial à faire, et il y a plein de "si", mais n'est-ce pas aussi cela le rôle de l'admin sécu, tenir compte de l'impossible ? En fait, c'est le côté pervers, du moins à mes yeux, du bruit. D'une part il lasse très vite, et d'autre part à force de l'entendre on fini par ne plus y faire attention.
D'ailleurs, même sa non-existence est intéressante :)
Comme en forêt, lorsqu'il n'y a plus de bruit, c'est que tout le monde a fuit le grand méchant ;-)
-- Je sais, à peine de retour et déjà chiant ;-)
Cedric Blancher devait dire quelque chose comme ceci :
[Snip]
Si par contre, on force la circulation de bruit dans le tunnel, on
linéarise les mouvements de trafic et on rend plus difficile ce genre
d'attaque.
En mettant volontairement de côté le fait qu'une répétition d'un motif
unique fragiliserait fortement le tunnel, ce qui force le "bruit" à
avoir un fort caractère aléatoire, je me pose quand même la question,
est-ce vraiment du bruit ?
Après tout, et si j'ai bien compris, le but est de garantir qu'il y
aura toujours X bps qui circuleront par ce tunnel. Donc, le-dit tunnel
peut être assimilé à une structure de données utilisant des
enregistrement de taille fixe, comme il y en a encore beaucoup en
informatique. Un enregistrement correspondrait à une seconde de temps,
les données envoyées aux données stockées dans l'enregistrement, et le
bruit aux 0 qui complètent le champ dans les formats de données plus
traditionnels. Une suite de zéro peut-elle être considérée comme du
bruit, qui plus est lorsqu'elle est générée volontairement et
restreinte à un espace clairement défini ?
Donc oui, dans certaines conditions, le bruit est utile. Ici pour
dissimuler un envoi de données, là parce que le trafic réel ressemble
à du bruit. En fait, ça vient du fait que même si on n'a pas accès
directement à l'information observée, le fait d'observer les conditions
dans lesquelles elle existe permet de déduire pleins de choses souvent
très intéressantes.
J'ai un autre exemple, plus proche encore de la sécurité informatique.
Le bruit de fond de plus en plus sonore que l'on trouve sur internet
permet de réduire le nombre de machines dont la pile IP n'a qu'une
faible activité. Du coup, il est plus difficile de faire un scanne de
port en envoyant des paquets spoofés et en observant les réactions de
la pile IP de la machine à qui appartient l'adresse IP (désolé, le nom
du scan m'échappe).
Cela dit, j'avais plutôt l'impression que l'intervenant initial
assimilait le bruit à l'obscurité. A savoir que plus il y a de bruit
autour de nous, moins les méchants peuvent savoir ce que l'on fait. Or,
cela me semble un brin casse-gueule. Benoit Leraillez prenait l'exemple
d'un concert qui couvrirait parfaitement les propos que l'on pourrait
vouloir garder secret, mais il y a une contre-partie, l'on ne peut pas
être sûr que l'autre a compris ce que l'on a dit.
A titre d'exemple, lorsque l'on dispose de tout son temps, pourquoi ne
pas placer quelques zombies, de préférence sur des machines ayant des
adresses IP dynamique, et les laisser scanner la cible, voir lancer de
mini attaques baclées, pendant un mois. A force de voir ses logs
transformés en sapin un soir de noël, il y a des chances pour que
l'admin ne prête pas suffisement attention aux alertes lorsque
l'attaque sera vraiment lancée.
De même, imagine qu'Apache ait eu une faille unicode en même temps
qu'IIS. Si l'on ajoute la chaîne clé qui a été diffusée pour permettre
de filtrer CodeRed dans ses logs, à la chaîne utilisée pour exploiter
la faille d'Apache, combien d'admin se seraient-ils retrouvés aveugles
? Evidement, ce n'est pas forcément quelque chose de trivial à faire,
et il y a plein de "si", mais n'est-ce pas aussi cela le rôle de
l'admin sécu, tenir compte de l'impossible ?
En fait, c'est le côté pervers, du moins à mes yeux, du bruit. D'une
part il lasse très vite, et d'autre part à force de l'entendre on fini
par ne plus y faire attention.
D'ailleurs, même sa non-existence est intéressante :)
Comme en forêt, lorsqu'il n'y a plus de bruit, c'est que tout le monde
a fuit le grand méchant ;-)
Cedric Blancher devait dire quelque chose comme ceci :
[Snip]
Si par contre, on force la circulation de bruit dans le tunnel, on linéarise les mouvements de trafic et on rend plus difficile ce genre d'attaque.
En mettant volontairement de côté le fait qu'une répétition d'un motif unique fragiliserait fortement le tunnel, ce qui force le "bruit" à avoir un fort caractère aléatoire, je me pose quand même la question, est-ce vraiment du bruit ? Après tout, et si j'ai bien compris, le but est de garantir qu'il y aura toujours X bps qui circuleront par ce tunnel. Donc, le-dit tunnel peut être assimilé à une structure de données utilisant des enregistrement de taille fixe, comme il y en a encore beaucoup en informatique. Un enregistrement correspondrait à une seconde de temps, les données envoyées aux données stockées dans l'enregistrement, et le bruit aux 0 qui complètent le champ dans les formats de données plus traditionnels. Une suite de zéro peut-elle être considérée comme du bruit, qui plus est lorsqu'elle est générée volontairement et restreinte à un espace clairement défini ?
Donc oui, dans certaines conditions, le bruit est utile. Ici pour dissimuler un envoi de données, là parce que le trafic réel ressemble à du bruit. En fait, ça vient du fait que même si on n'a pas accès directement à l'information observée, le fait d'observer les conditions dans lesquelles elle existe permet de déduire pleins de choses souvent très intéressantes.
J'ai un autre exemple, plus proche encore de la sécurité informatique. Le bruit de fond de plus en plus sonore que l'on trouve sur internet permet de réduire le nombre de machines dont la pile IP n'a qu'une faible activité. Du coup, il est plus difficile de faire un scanne de port en envoyant des paquets spoofés et en observant les réactions de la pile IP de la machine à qui appartient l'adresse IP (désolé, le nom du scan m'échappe).
Cela dit, j'avais plutôt l'impression que l'intervenant initial assimilait le bruit à l'obscurité. A savoir que plus il y a de bruit autour de nous, moins les méchants peuvent savoir ce que l'on fait. Or, cela me semble un brin casse-gueule. Benoit Leraillez prenait l'exemple d'un concert qui couvrirait parfaitement les propos que l'on pourrait vouloir garder secret, mais il y a une contre-partie, l'on ne peut pas être sûr que l'autre a compris ce que l'on a dit. A titre d'exemple, lorsque l'on dispose de tout son temps, pourquoi ne pas placer quelques zombies, de préférence sur des machines ayant des adresses IP dynamique, et les laisser scanner la cible, voir lancer de mini attaques baclées, pendant un mois. A force de voir ses logs transformés en sapin un soir de noël, il y a des chances pour que l'admin ne prête pas suffisement attention aux alertes lorsque l'attaque sera vraiment lancée. De même, imagine qu'Apache ait eu une faille unicode en même temps qu'IIS. Si l'on ajoute la chaîne clé qui a été diffusée pour permettre de filtrer CodeRed dans ses logs, à la chaîne utilisée pour exploiter la faille d'Apache, combien d'admin se seraient-ils retrouvés aveugles ? Evidement, ce n'est pas forcément quelque chose de trivial à faire, et il y a plein de "si", mais n'est-ce pas aussi cela le rôle de l'admin sécu, tenir compte de l'impossible ? En fait, c'est le côté pervers, du moins à mes yeux, du bruit. D'une part il lasse très vite, et d'autre part à force de l'entendre on fini par ne plus y faire attention.
D'ailleurs, même sa non-existence est intéressante :)
Comme en forêt, lorsqu'il n'y a plus de bruit, c'est que tout le monde a fuit le grand méchant ;-)
