Le protocole TCP/IP est la fondation même des échanges réseaux... et
on vient de se rendre compte qu'il comportait depuis toujours une
faille structurelle ! Il serait beaucoup plus simple qu'on ne le
pensait jusqu'alors de neutraliser une connexion TCP/IP. Cette
perspective ouvre la voie à de nombreux dénis de service.
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
Sebastien Varrette
Patrice wrote:
Le protocole TCP/IP est la fondation même des échanges réseaux... et on vient de se rendre compte qu'il comportait depuis toujours une faille structurelle ! Il serait beaucoup plus simple qu'on ne le pensait jusqu'alors de neutraliser une connexion TCP/IP. Cette perspective ouvre la voie à de nombreux dénis de service.
En fait, cette faille est connue depuis longtemps. C'est sa publicité (notamment aus Etats Unis) qui est récente... Et qui va poser problème car de nombreuses personnes (pas forcément bien intentionnées) vont s'y interessé.
Wait and see....
Patrice wrote:
Le protocole TCP/IP est la fondation même des échanges réseaux... et
on vient de se rendre compte qu'il comportait depuis toujours une
faille structurelle ! Il serait beaucoup plus simple qu'on ne le
pensait jusqu'alors de neutraliser une connexion TCP/IP. Cette
perspective ouvre la voie à de nombreux dénis de service.
En fait, cette faille est connue depuis longtemps.
C'est sa publicité (notamment aus Etats Unis) qui est récente... Et qui
va poser problème car de nombreuses personnes (pas forcément bien
intentionnées) vont s'y interessé.
Le protocole TCP/IP est la fondation même des échanges réseaux... et on vient de se rendre compte qu'il comportait depuis toujours une faille structurelle ! Il serait beaucoup plus simple qu'on ne le pensait jusqu'alors de neutraliser une connexion TCP/IP. Cette perspective ouvre la voie à de nombreux dénis de service.
En fait, cette faille est connue depuis longtemps. C'est sa publicité (notamment aus Etats Unis) qui est récente... Et qui va poser problème car de nombreuses personnes (pas forcément bien intentionnées) vont s'y interessé.
Wait and see....
Nicob
On Thu, 22 Apr 2004 10:17:56 +0000, Sebastien Varrette wrote:
C'est sa publicité (notamment aus Etats Unis) qui est récente... Et qui va poser problème car de nombreuses personnes (pas forcément bien intentionnées) vont s'y interessé.
Pour moi, une faille publiée est toujours moins dangereuse qu'une faille non publiée, car on peut entreprendre (si on est informé) des actions de mitigation du risque, comme l'application d'un patch "home made", une modification de la configuration, une restriction accentuée des accès ou même une désactivation du service.
Nicob
On Thu, 22 Apr 2004 10:17:56 +0000, Sebastien Varrette wrote:
C'est sa publicité (notamment aus Etats Unis) qui est récente... Et
qui va poser problème car de nombreuses personnes (pas forcément bien
intentionnées) vont s'y interessé.
Pour moi, une faille publiée est toujours moins dangereuse qu'une faille
non publiée, car on peut entreprendre (si on est informé) des actions de
mitigation du risque, comme l'application d'un patch "home made", une
modification de la configuration, une restriction accentuée des accès ou
même une désactivation du service.
On Thu, 22 Apr 2004 10:17:56 +0000, Sebastien Varrette wrote:
C'est sa publicité (notamment aus Etats Unis) qui est récente... Et qui va poser problème car de nombreuses personnes (pas forcément bien intentionnées) vont s'y interessé.
Pour moi, une faille publiée est toujours moins dangereuse qu'une faille non publiée, car on peut entreprendre (si on est informé) des actions de mitigation du risque, comme l'application d'un patch "home made", une modification de la configuration, une restriction accentuée des accès ou même une désactivation du service.
Nicob
totoy81
Le protocole TCP/IP est la fondation même des échanges réseaux... et on vient de se rendre compte qu'il comportait depuis toujours une faille structurelle ! Il serait beaucoup plus simple qu'on ne le pensait jusqu'alors de neutraliser une connexion TCP/IP. Cette perspective ouvre la voie à de nombreux dénis de service.
Cette faille est connue depuis la création même de la RFC 793 (TCP). En théorie, à condition de trouver les couples {IP,port} source et destination d'une connexion établie (le port source peut être plus difficile à deviner comme avec l'utilisation de patchs comme grSecurity par exemple, mais bon c pas légion), le seul paramètre manquant à rendre un paquet RST (ou SYN avec ISN différent) spoofé "légitime" est un numéro de séquence correct, soit à choisir parmi 2^32 possibilités. Ce qu'il y a de nouveau et qui rend l'attaque faisable _en pratique_ c'est qu'on se rend compte qu'il n'est pas nécessaire de choisir le numéro de séquence exact, mais un numéro choisi dans une plage, qui correspond à la fenêtre "TCP Window" (annoncée sur le 3-way handshake). Les facteurs aggravants sont la predictabilité importante des ports sources "clients" et les valeurs par défaut de fenêtre utilisées par les différents OS.
Ce n'est ni plus ni moins qu'un problème d'authentification (aka IPSec est une solution au problème...), puisqu'on considère que la connaissance du numéro de séquence exact relativement à la durée de l'établissement de la connexion est "suffisamment difficilement" (;)) devinable.
Ce qui a fait "flipper" dès l'annonce c'est la mise en cause de la disponibilité des infrastructures de routage (BGP est transporté par TCP) vis à vis de ce type d'attaque. Néanmoins on s'est aperçu rapidement qu'avec un filtrage correct des flux ingress/egress (aka les bonnes pratiques BGP qui permettent pour l'instant de se passer de {s-,so}BGP et consorts PKIstiques) et l'utilisation de l'authentification par l'option TCP MD5 est un facteur mitigeant.
La solution apportée par plusieurs vendeurs a été de générer un acquittement lors de la réception d'un RST ou SYN (avec ISN différent, ce qui, cf.RFC, permet également de réinitialiser la connexion) dans la fenêtre, ce qui permet de s'assurer que la pile légitime soit l'émettrice (à moins que la connexion soit hijackée ou que le pirate ait accès aux trames destinées à la machine cliente légitime).
Le protocole TCP/IP est la fondation même des échanges réseaux... et
on vient de se rendre compte qu'il comportait depuis toujours une
faille structurelle ! Il serait beaucoup plus simple qu'on ne le
pensait jusqu'alors de neutraliser une connexion TCP/IP. Cette
perspective ouvre la voie à de nombreux dénis de service.
Cette faille est connue depuis la création même de la RFC 793 (TCP).
En théorie, à condition de trouver les couples {IP,port} source et
destination d'une connexion établie (le port source peut être plus
difficile à deviner comme avec l'utilisation de patchs comme
grSecurity par exemple, mais bon c pas légion), le seul paramètre
manquant à rendre un paquet RST (ou SYN avec ISN différent) spoofé
"légitime" est un numéro de séquence correct, soit à choisir parmi
2^32 possibilités. Ce qu'il y a de nouveau et qui rend l'attaque
faisable _en pratique_ c'est qu'on se rend compte qu'il n'est pas
nécessaire de choisir le numéro de séquence exact, mais un numéro
choisi dans une plage, qui correspond à la fenêtre "TCP Window"
(annoncée sur le 3-way handshake). Les facteurs aggravants sont la
predictabilité importante des ports sources "clients" et les valeurs
par défaut de fenêtre utilisées par les différents OS.
Ce n'est ni plus ni moins qu'un problème d'authentification (aka IPSec
est une solution au problème...), puisqu'on considère que la
connaissance du numéro de séquence exact relativement à la durée de
l'établissement de la connexion est "suffisamment difficilement" (;))
devinable.
Ce qui a fait "flipper" dès l'annonce c'est la mise en cause de la
disponibilité des infrastructures de routage (BGP est transporté par
TCP) vis à vis de ce type d'attaque. Néanmoins on s'est aperçu
rapidement qu'avec un filtrage correct des flux ingress/egress (aka
les bonnes pratiques BGP qui permettent pour l'instant de se passer de
{s-,so}BGP et consorts PKIstiques) et l'utilisation de
l'authentification par l'option TCP MD5 est un facteur mitigeant.
La solution apportée par plusieurs vendeurs a été de générer un
acquittement lors de la réception d'un RST ou SYN (avec ISN différent,
ce qui, cf.RFC, permet également de réinitialiser la connexion) dans
la fenêtre, ce qui permet de s'assurer que la pile légitime soit
l'émettrice (à moins que la connexion soit hijackée ou que le pirate
ait accès aux trames destinées à la machine cliente légitime).
Le protocole TCP/IP est la fondation même des échanges réseaux... et on vient de se rendre compte qu'il comportait depuis toujours une faille structurelle ! Il serait beaucoup plus simple qu'on ne le pensait jusqu'alors de neutraliser une connexion TCP/IP. Cette perspective ouvre la voie à de nombreux dénis de service.
Cette faille est connue depuis la création même de la RFC 793 (TCP). En théorie, à condition de trouver les couples {IP,port} source et destination d'une connexion établie (le port source peut être plus difficile à deviner comme avec l'utilisation de patchs comme grSecurity par exemple, mais bon c pas légion), le seul paramètre manquant à rendre un paquet RST (ou SYN avec ISN différent) spoofé "légitime" est un numéro de séquence correct, soit à choisir parmi 2^32 possibilités. Ce qu'il y a de nouveau et qui rend l'attaque faisable _en pratique_ c'est qu'on se rend compte qu'il n'est pas nécessaire de choisir le numéro de séquence exact, mais un numéro choisi dans une plage, qui correspond à la fenêtre "TCP Window" (annoncée sur le 3-way handshake). Les facteurs aggravants sont la predictabilité importante des ports sources "clients" et les valeurs par défaut de fenêtre utilisées par les différents OS.
Ce n'est ni plus ni moins qu'un problème d'authentification (aka IPSec est une solution au problème...), puisqu'on considère que la connaissance du numéro de séquence exact relativement à la durée de l'établissement de la connexion est "suffisamment difficilement" (;)) devinable.
Ce qui a fait "flipper" dès l'annonce c'est la mise en cause de la disponibilité des infrastructures de routage (BGP est transporté par TCP) vis à vis de ce type d'attaque. Néanmoins on s'est aperçu rapidement qu'avec un filtrage correct des flux ingress/egress (aka les bonnes pratiques BGP qui permettent pour l'instant de se passer de {s-,so}BGP et consorts PKIstiques) et l'utilisation de l'authentification par l'option TCP MD5 est un facteur mitigeant.
La solution apportée par plusieurs vendeurs a été de générer un acquittement lors de la réception d'un RST ou SYN (avec ISN différent, ce qui, cf.RFC, permet également de réinitialiser la connexion) dans la fenêtre, ce qui permet de s'assurer que la pile légitime soit l'émettrice (à moins que la connexion soit hijackée ou que le pirate ait accès aux trames destinées à la machine cliente légitime).
Jerome T
"anth0" wrote in message news:
Cette faille est connue depuis la création même de la RFC 793 (TCP).
Est-ce que vous ou quelqu'un d'autre aurait des sources sur cette information ?
"anth0" <totoy81@caramail.com> wrote in message
news:aa6c6d5b.0404220526.622eece2@posting.google.com...
Cette faille est connue depuis la création même de la RFC 793 (TCP).
Est-ce que vous ou quelqu'un d'autre aurait des sources sur cette
information ?
