En configurant un Postfix hier, je me suis posé la question suivante : dans
quel mesure est-il possible, de nos jours, sur le grand nain Ternet,
d'usurper l'IP d'une machine, afin par exemple d'abuser de la confiance
accordée par Postfix à certaines IP pour relayer du courrier ?
En fait, il me semble que si les IP concernées appartiennent toutes au
réseau local, et qu'en bordure de réseau le firewall fait bien son travail
en rejetant les paquets arrivant sur l'interface extérieure avec une IP
source du réseau local, on est a priori tranquilles. Déjà, ai-je raison sur
ce point ?
Par contre, dans le cas où mynetworks contient une IP n'appartenant pas à un
réseau local contrôlé, est-il possible pour un attaquant de se faire passer
pour la machine de confiance ? En clair, la machine devient-elle un relais
ouvert, du moins ouvert à tout attaquant suffisamment motivé et compétent ?
Bref, faut-il absolument utiliser un protocole d'authentification crypto
comme TLS pour éviter de relayer involontairement du courrier non autorisé,
ou l'IP est-elle un moyen d'authentification suffisant ?
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
Fabien LE LEZ
On 16 Dec 2008 18:50:52 GMT, mpg :
dans quel mesure est-il possible, de nos jours, sur le grand nain Ternet, d'usurper l'IP d'une machine,
Je peux facilement envoyer un paquet IP avec une fausse adresse source. Par contre, normalement (cf plus bas), si tu envoies une réponse, tu l'enverras vers cette fausse adresse-source, pas vers mois -- et donc, je ne pourrai pas la recevoir.
SMTP fonctionne avec une connexion TCP, qui s'établit par un échange de paquets. Je t'envoie un paquet, tu m'envoies une réponse, et si je la reçoit, on peut commencer à causer. Si je ne la reçois pas (pour quelque raison que ce soit), la connexion échoue, et on s'arrête là (quitte à re-tenter une nouvelle connexion).
Toutefois, je peux mentir sur mon adresse IP, si j'ai un moyen de recevoir quand même les paquets envoyés en réponse. Pour cela, il faut corrompre soit le routeur, soit le switch sur lequel ta machine est connectée.
Si la machine du pirate est branchée sur le même switch que ta machine, et si l'hébergeur est un guignol, ça peut être possible. Mais a priori, les hébergeurs sont plutôt vigilants sur ce point.
Par ailleurs, il faut aussi regarder à qui l'adresse IP "de confiance" appartient. Par exemple, l'adresse IP de ta connexion ADSL t'est fournie par ton FAI, qui peut très bien décider de la reprendre pour la filer à quelqu'un d'autre. C'est techniquement de l'usurpation (puisqu'un autre abonné utilise maintenant "ton" adresse IP), mais c'est parfaitement légal.
On 16 Dec 2008 18:50:52 GMT, mpg <mpg-news@elzevir.fr>:
dans
quel mesure est-il possible, de nos jours, sur le grand nain Ternet,
d'usurper l'IP d'une machine,
Je peux facilement envoyer un paquet IP avec une fausse adresse
source. Par contre, normalement (cf plus bas), si tu envoies une
réponse, tu l'enverras vers cette fausse adresse-source, pas vers mois
-- et donc, je ne pourrai pas la recevoir.
SMTP fonctionne avec une connexion TCP, qui s'établit par un échange
de paquets. Je t'envoie un paquet, tu m'envoies une réponse, et si je
la reçoit, on peut commencer à causer. Si je ne la reçois pas (pour
quelque raison que ce soit), la connexion échoue, et on s'arrête là
(quitte à re-tenter une nouvelle connexion).
Toutefois, je peux mentir sur mon adresse IP, si j'ai un moyen de
recevoir quand même les paquets envoyés en réponse. Pour cela, il faut
corrompre soit le routeur, soit le switch sur lequel ta machine est
connectée.
Si la machine du pirate est branchée sur le même switch que ta
machine, et si l'hébergeur est un guignol, ça peut être possible. Mais
a priori, les hébergeurs sont plutôt vigilants sur ce point.
Par ailleurs, il faut aussi regarder à qui l'adresse IP "de confiance"
appartient. Par exemple, l'adresse IP de ta connexion ADSL t'est
fournie par ton FAI, qui peut très bien décider de la reprendre pour
la filer à quelqu'un d'autre. C'est techniquement de l'usurpation
(puisqu'un autre abonné utilise maintenant "ton" adresse IP), mais
c'est parfaitement légal.
dans quel mesure est-il possible, de nos jours, sur le grand nain Ternet, d'usurper l'IP d'une machine,
Je peux facilement envoyer un paquet IP avec une fausse adresse source. Par contre, normalement (cf plus bas), si tu envoies une réponse, tu l'enverras vers cette fausse adresse-source, pas vers mois -- et donc, je ne pourrai pas la recevoir.
SMTP fonctionne avec une connexion TCP, qui s'établit par un échange de paquets. Je t'envoie un paquet, tu m'envoies une réponse, et si je la reçoit, on peut commencer à causer. Si je ne la reçois pas (pour quelque raison que ce soit), la connexion échoue, et on s'arrête là (quitte à re-tenter une nouvelle connexion).
Toutefois, je peux mentir sur mon adresse IP, si j'ai un moyen de recevoir quand même les paquets envoyés en réponse. Pour cela, il faut corrompre soit le routeur, soit le switch sur lequel ta machine est connectée.
Si la machine du pirate est branchée sur le même switch que ta machine, et si l'hébergeur est un guignol, ça peut être possible. Mais a priori, les hébergeurs sont plutôt vigilants sur ce point.
Par ailleurs, il faut aussi regarder à qui l'adresse IP "de confiance" appartient. Par exemple, l'adresse IP de ta connexion ADSL t'est fournie par ton FAI, qui peut très bien décider de la reprendre pour la filer à quelqu'un d'autre. C'est techniquement de l'usurpation (puisqu'un autre abonné utilise maintenant "ton" adresse IP), mais c'est parfaitement légal.
Bruno Ducrot
Bonjour,
On 2008-12-16, mpg wrote:
Par contre, dans le cas où mynetworks contient une IP n'appartenant pas à un réseau local contrôlé, est-il possible pour un attaquant de se faire passer pour la machine de confiance ? En clair, la machine devient-elle un relais ouvert, du moins ouvert à tout attaquant suffisamment motivé et compétent ? Bref, faut-il absolument utiliser un protocole d'authentification crypto comme TLS pour éviter de relayer involontairement du courrier non autorisé, ou l'IP est-elle un moyen d'authentification suffisant ?
Une IP n'a jamais ete un moyen d'authentification suffisant.
Un type d'attaque sur le protocole BGP[1], par exemple, peut tout-a-fait etre envisage par une personne *tres* motivee.
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
Bonjour,
On 2008-12-16, mpg wrote:
Par contre, dans le cas où mynetworks contient une IP n'appartenant pas à un
réseau local contrôlé, est-il possible pour un attaquant de se faire passer
pour la machine de confiance ? En clair, la machine devient-elle un relais
ouvert, du moins ouvert à tout attaquant suffisamment motivé et compétent ?
Bref, faut-il absolument utiliser un protocole d'authentification crypto
comme TLS pour éviter de relayer involontairement du courrier non autorisé,
ou l'IP est-elle un moyen d'authentification suffisant ?
Une IP n'a jamais ete un moyen d'authentification suffisant.
Un type d'attaque sur le protocole BGP[1], par exemple, peut tout-a-fait
etre envisage par une personne *tres* motivee.
Par contre, dans le cas où mynetworks contient une IP n'appartenant pas à un réseau local contrôlé, est-il possible pour un attaquant de se faire passer pour la machine de confiance ? En clair, la machine devient-elle un relais ouvert, du moins ouvert à tout attaquant suffisamment motivé et compétent ? Bref, faut-il absolument utiliser un protocole d'authentification crypto comme TLS pour éviter de relayer involontairement du courrier non autorisé, ou l'IP est-elle un moyen d'authentification suffisant ?
Une IP n'a jamais ete un moyen d'authentification suffisant.
Un type d'attaque sur le protocole BGP[1], par exemple, peut tout-a-fait etre envisage par une personne *tres* motivee.
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
Fabien LE LEZ
On 17 Dec 2008 12:25:28 GMT, Bruno Ducrot :
Une IP n'a jamais ete un moyen d'authentification suffisant.
Ce n'est pas un moyen d'authentification forte. Toutefois, s'il s'agit juste d'éviter d'avoir un relais SMTP ouvert, ça me paraît suffisant. Quelqu'un de suffisamment motivé se créera plutôt son réseau de zombies, c'est bien plus efficace.
On 17 Dec 2008 12:25:28 GMT, Bruno Ducrot <ducrot@echo.fr>:
Une IP n'a jamais ete un moyen d'authentification suffisant.
Ce n'est pas un moyen d'authentification forte.
Toutefois, s'il s'agit juste d'éviter d'avoir un relais SMTP ouvert,
ça me paraît suffisant. Quelqu'un de suffisamment motivé se créera
plutôt son réseau de zombies, c'est bien plus efficace.
Une IP n'a jamais ete un moyen d'authentification suffisant.
Ce n'est pas un moyen d'authentification forte. Toutefois, s'il s'agit juste d'éviter d'avoir un relais SMTP ouvert, ça me paraît suffisant. Quelqu'un de suffisamment motivé se créera plutôt son réseau de zombies, c'est bien plus efficace.
Pascal Hambourg
Salut,
Fabien LE LEZ a écrit :
SMTP fonctionne avec une connexion TCP, qui s'établit par un échange de paquets. Je t'envoie un paquet, tu m'envoies une réponse, et si je la reçoit, on peut commencer à causer. Si je ne la reçois pas (pour quelque raison que ce soit), la connexion échoue, et on s'arrête là (quitte à re-tenter une nouvelle connexion).
Toutefois, je peux mentir sur mon adresse IP, si j'ai un moyen de recevoir quand même les paquets envoyés en réponse.
Autre possibilité : se contenter de deviner les réponses du serveur, et agir comme si on les avait reçues. En ce qui concerne la communication SMTP, ce n'est pas très difficile. En revanche pour la connexion TCP il y a un os : le numéro de séquence initial (ISN) choisi par le serveur et transmis au client lors de l'établissement de la connexion. Dans le temps l'ISN choisi par certains vieux OS était assez prévisible, de sorte qu'il était assez facile de le deviner. Aujourd'hui, c'est beaucoup plus difficile. Autre difficulté : il faut s'assurer que la machine propriétaire légitime de l'adresse usurpée ne reçoive pas les paquets du serveur ou n'y réponde pas, sans quoi elle va envoyer un RST (reset) au routeur et ainsi couper la connexion.
Salut,
Fabien LE LEZ a écrit :
SMTP fonctionne avec une connexion TCP, qui s'établit par un échange
de paquets. Je t'envoie un paquet, tu m'envoies une réponse, et si je
la reçoit, on peut commencer à causer. Si je ne la reçois pas (pour
quelque raison que ce soit), la connexion échoue, et on s'arrête là
(quitte à re-tenter une nouvelle connexion).
Toutefois, je peux mentir sur mon adresse IP, si j'ai un moyen de
recevoir quand même les paquets envoyés en réponse.
Autre possibilité : se contenter de deviner les réponses du serveur, et
agir comme si on les avait reçues. En ce qui concerne la communication
SMTP, ce n'est pas très difficile. En revanche pour la connexion TCP il
y a un os : le numéro de séquence initial (ISN) choisi par le serveur et
transmis au client lors de l'établissement de la connexion. Dans le
temps l'ISN choisi par certains vieux OS était assez prévisible, de
sorte qu'il était assez facile de le deviner. Aujourd'hui, c'est
beaucoup plus difficile. Autre difficulté : il faut s'assurer que la
machine propriétaire légitime de l'adresse usurpée ne reçoive pas les
paquets du serveur ou n'y réponde pas, sans quoi elle va envoyer un RST
(reset) au routeur et ainsi couper la connexion.
SMTP fonctionne avec une connexion TCP, qui s'établit par un échange de paquets. Je t'envoie un paquet, tu m'envoies une réponse, et si je la reçoit, on peut commencer à causer. Si je ne la reçois pas (pour quelque raison que ce soit), la connexion échoue, et on s'arrête là (quitte à re-tenter une nouvelle connexion).
Toutefois, je peux mentir sur mon adresse IP, si j'ai un moyen de recevoir quand même les paquets envoyés en réponse.
Autre possibilité : se contenter de deviner les réponses du serveur, et agir comme si on les avait reçues. En ce qui concerne la communication SMTP, ce n'est pas très difficile. En revanche pour la connexion TCP il y a un os : le numéro de séquence initial (ISN) choisi par le serveur et transmis au client lors de l'établissement de la connexion. Dans le temps l'ISN choisi par certains vieux OS était assez prévisible, de sorte qu'il était assez facile de le deviner. Aujourd'hui, c'est beaucoup plus difficile. Autre difficulté : il faut s'assurer que la machine propriétaire légitime de l'adresse usurpée ne reçoive pas les paquets du serveur ou n'y réponde pas, sans quoi elle va envoyer un RST (reset) au routeur et ainsi couper la connexion.
Eric Razny
Bonjour.
Le Wed, 17 Dec 2008 13:20:14 +0000, Fabien LE LEZ a écrit :
Une IP n'a jamais ete un moyen d'authentification suffisant.
Ce n'est pas un moyen d'authentification forte. Toutefois, s'il s'agit juste d'éviter d'avoir un relais SMTP ouvert,
SMTP-AUTH est dans ce cas assez simple à mettre en place (tant qu'à faire avec du TLS) et permet en plus à un utilisateur nomade d'envoyer ses emails même avec du spf.
Eric.
Bonjour.
Le Wed, 17 Dec 2008 13:20:14 +0000, Fabien LE LEZ a écrit :
Une IP n'a jamais ete un moyen d'authentification suffisant.
Ce n'est pas un moyen d'authentification forte.
Toutefois, s'il s'agit juste d'éviter d'avoir un relais SMTP ouvert,
SMTP-AUTH est dans ce cas assez simple à mettre en place (tant qu'à
faire avec du TLS) et permet en plus à un utilisateur nomade d'envoyer
ses emails même avec du spf.
Le Wed, 17 Dec 2008 13:20:14 +0000, Fabien LE LEZ a écrit :
Une IP n'a jamais ete un moyen d'authentification suffisant.
Ce n'est pas un moyen d'authentification forte. Toutefois, s'il s'agit juste d'éviter d'avoir un relais SMTP ouvert,
SMTP-AUTH est dans ce cas assez simple à mettre en place (tant qu'à faire avec du TLS) et permet en plus à un utilisateur nomade d'envoyer ses emails même avec du spf.
Eric.
mpg
Le (on) mercredi 17 décembre 2008 23:21, Eric Razny a écrit (wrote) :
Ce n'est pas un moyen d'authentification forte. Toutefois, s'il s'agit juste d'éviter d'avoir un relais SMTP ouvert,
C'était mon but en effet. Clairement je ne me fierai pas à une IP seule pour la plupart des trucs, mais la question était de savoir si dans ce contexte c'était suffisant.
SMTP-AUTH est dans ce cas assez simple à mettre en place (tant qu'à faire avec du TLS) et permet en plus à un utilisateur nomade d'envoyer ses emails même avec du spf.
Tiens, je connaissais pas SMTP-AUTH sans TLS. Je voulais regarder de toutes façons comment mettre en place du SMTP+TLS pour pouvoir envoyer mes mails depuis mon portable justement, et à ce moment là sans doute que je ferai pareil pour mon serveur domestique, mais en attendant d'avoir le temps, je voulais savoir se fier à l'IP seul ferait de moi un danger public.
Manuel.
Le (on) mercredi 17 décembre 2008 23:21, Eric Razny a écrit (wrote) :
Ce n'est pas un moyen d'authentification forte.
Toutefois, s'il s'agit juste d'éviter d'avoir un relais SMTP ouvert,
C'était mon but en effet. Clairement je ne me fierai pas à une IP seule pour
la plupart des trucs, mais la question était de savoir si dans ce contexte
c'était suffisant.
SMTP-AUTH est dans ce cas assez simple à mettre en place (tant qu'à
faire avec du TLS) et permet en plus à un utilisateur nomade d'envoyer
ses emails même avec du spf.
Tiens, je connaissais pas SMTP-AUTH sans TLS. Je voulais regarder de toutes
façons comment mettre en place du SMTP+TLS pour pouvoir envoyer mes mails
depuis mon portable justement, et à ce moment là sans doute que je ferai
pareil pour mon serveur domestique, mais en attendant d'avoir le temps, je
voulais savoir se fier à l'IP seul ferait de moi un danger public.
Le (on) mercredi 17 décembre 2008 23:21, Eric Razny a écrit (wrote) :
Ce n'est pas un moyen d'authentification forte. Toutefois, s'il s'agit juste d'éviter d'avoir un relais SMTP ouvert,
C'était mon but en effet. Clairement je ne me fierai pas à une IP seule pour la plupart des trucs, mais la question était de savoir si dans ce contexte c'était suffisant.
SMTP-AUTH est dans ce cas assez simple à mettre en place (tant qu'à faire avec du TLS) et permet en plus à un utilisateur nomade d'envoyer ses emails même avec du spf.
Tiens, je connaissais pas SMTP-AUTH sans TLS. Je voulais regarder de toutes façons comment mettre en place du SMTP+TLS pour pouvoir envoyer mes mails depuis mon portable justement, et à ce moment là sans doute que je ferai pareil pour mon serveur domestique, mais en attendant d'avoir le temps, je voulais savoir se fier à l'IP seul ferait de moi un danger public.
Manuel.
mpg
Le (on) mercredi 17 décembre 2008 19:26, Pascal Hambourg a écrit (wrote) :
Toutefois, je peux mentir sur mon adresse IP, si j'ai un moyen de recevoir quand même les paquets envoyés en réponse.
Autre possibilité : se contenter de deviner les réponses du serveur, et agir comme si on les avait reçues. En ce qui concerne la communication SMTP, ce n'est pas très difficile. En revanche pour la connexion TCP il y a un os : le numéro de séquence initial (ISN) choisi par le serveur et transmis au client lors de l'établissement de la connexion. Dans le temps l'ISN choisi par certains vieux OS était assez prévisible, de sorte qu'il était assez facile de le deviner. Aujourd'hui, c'est beaucoup plus difficile. Autre difficulté : il faut s'assurer que la machine propriétaire légitime de l'adresse usurpée ne reçoive pas les paquets du serveur ou n'y réponde pas, sans quoi elle va envoyer un RST (reset) au routeur et ainsi couper la connexion.
En fait, justement j'avais essayé de me documenter un peu avant de poster, et j'avais notament lu
http://fr.wikipedia.org/wiki/Attaque_de_Mitnick
qui m'a paru extrêmement clair sur la description du principe et de la technique de l'attaque, par contre je n'arrivais pas trop à comprendre à quel point elle était encore réalisable (ou en tout cas facile ou difficile) de nos jours.
Concernant l'ISN, est-ce que les piles TCP/IP modernes utilisent un générateur pseudo-aléatoire pour le générer ? Ce n'est pas quand même gourmand en ressources, ce genre de choses ?
Manuel.
Le (on) mercredi 17 décembre 2008 19:26, Pascal Hambourg a écrit (wrote) :
Toutefois, je peux mentir sur mon adresse IP, si j'ai un moyen de
recevoir quand même les paquets envoyés en réponse.
Autre possibilité : se contenter de deviner les réponses du serveur, et
agir comme si on les avait reçues. En ce qui concerne la communication
SMTP, ce n'est pas très difficile. En revanche pour la connexion TCP il
y a un os : le numéro de séquence initial (ISN) choisi par le serveur et
transmis au client lors de l'établissement de la connexion. Dans le
temps l'ISN choisi par certains vieux OS était assez prévisible, de
sorte qu'il était assez facile de le deviner. Aujourd'hui, c'est
beaucoup plus difficile. Autre difficulté : il faut s'assurer que la
machine propriétaire légitime de l'adresse usurpée ne reçoive pas les
paquets du serveur ou n'y réponde pas, sans quoi elle va envoyer un RST
(reset) au routeur et ainsi couper la connexion.
En fait, justement j'avais essayé de me documenter un peu avant de poster,
et j'avais notament lu
http://fr.wikipedia.org/wiki/Attaque_de_Mitnick
qui m'a paru extrêmement clair sur la description du principe et de la
technique de l'attaque, par contre je n'arrivais pas trop à comprendre à
quel point elle était encore réalisable (ou en tout cas facile ou
difficile) de nos jours.
Concernant l'ISN, est-ce que les piles TCP/IP modernes utilisent un
générateur pseudo-aléatoire pour le générer ? Ce n'est pas quand même
gourmand en ressources, ce genre de choses ?
Le (on) mercredi 17 décembre 2008 19:26, Pascal Hambourg a écrit (wrote) :
Toutefois, je peux mentir sur mon adresse IP, si j'ai un moyen de recevoir quand même les paquets envoyés en réponse.
Autre possibilité : se contenter de deviner les réponses du serveur, et agir comme si on les avait reçues. En ce qui concerne la communication SMTP, ce n'est pas très difficile. En revanche pour la connexion TCP il y a un os : le numéro de séquence initial (ISN) choisi par le serveur et transmis au client lors de l'établissement de la connexion. Dans le temps l'ISN choisi par certains vieux OS était assez prévisible, de sorte qu'il était assez facile de le deviner. Aujourd'hui, c'est beaucoup plus difficile. Autre difficulté : il faut s'assurer que la machine propriétaire légitime de l'adresse usurpée ne reçoive pas les paquets du serveur ou n'y réponde pas, sans quoi elle va envoyer un RST (reset) au routeur et ainsi couper la connexion.
En fait, justement j'avais essayé de me documenter un peu avant de poster, et j'avais notament lu
http://fr.wikipedia.org/wiki/Attaque_de_Mitnick
qui m'a paru extrêmement clair sur la description du principe et de la technique de l'attaque, par contre je n'arrivais pas trop à comprendre à quel point elle était encore réalisable (ou en tout cas facile ou difficile) de nos jours.
Concernant l'ISN, est-ce que les piles TCP/IP modernes utilisent un générateur pseudo-aléatoire pour le générer ? Ce n'est pas quand même gourmand en ressources, ce genre de choses ?
Manuel.
mpg
Le (on) mardi 16 décembre 2008 20:48, Fabien LE LEZ a écrit (wrote) :
Si la machine du pirate est branchée sur le même switch que ta machine, et si l'hébergeur est un guignol, ça peut être possible. Mais a priori, les hébergeurs sont plutôt vigilants sur ce point.
Ouf.
Par ailleurs, il faut aussi regarder à qui l'adresse IP "de confiance" appartient. Par exemple, l'adresse IP de ta connexion ADSL t'est fournie par ton FAI, qui peut très bien décider de la reprendre pour la filer à quelqu'un d'autre. C'est techniquement de l'usurpation (puisqu'un autre abonné utilise maintenant "ton" adresse IP), mais c'est parfaitement légal.
Ouaip. En même temps, je pense que je m'en rendrais compte assez rapidement si ça arrivait, c'est déjà ça.
Manuel.
Le (on) mardi 16 décembre 2008 20:48, Fabien LE LEZ a écrit (wrote) :
Si la machine du pirate est branchée sur le même switch que ta
machine, et si l'hébergeur est un guignol, ça peut être possible. Mais
a priori, les hébergeurs sont plutôt vigilants sur ce point.
Ouf.
Par ailleurs, il faut aussi regarder à qui l'adresse IP "de confiance"
appartient. Par exemple, l'adresse IP de ta connexion ADSL t'est
fournie par ton FAI, qui peut très bien décider de la reprendre pour
la filer à quelqu'un d'autre. C'est techniquement de l'usurpation
(puisqu'un autre abonné utilise maintenant "ton" adresse IP), mais
c'est parfaitement légal.
Ouaip. En même temps, je pense que je m'en rendrais compte assez rapidement
si ça arrivait, c'est déjà ça.
Le (on) mardi 16 décembre 2008 20:48, Fabien LE LEZ a écrit (wrote) :
Si la machine du pirate est branchée sur le même switch que ta machine, et si l'hébergeur est un guignol, ça peut être possible. Mais a priori, les hébergeurs sont plutôt vigilants sur ce point.
Ouf.
Par ailleurs, il faut aussi regarder à qui l'adresse IP "de confiance" appartient. Par exemple, l'adresse IP de ta connexion ADSL t'est fournie par ton FAI, qui peut très bien décider de la reprendre pour la filer à quelqu'un d'autre. C'est techniquement de l'usurpation (puisqu'un autre abonné utilise maintenant "ton" adresse IP), mais c'est parfaitement légal.
Ouaip. En même temps, je pense que je m'en rendrais compte assez rapidement si ça arrivait, c'est déjà ça.
Manuel.
Pascal Hambourg
mpg a écrit :
Concernant l'ISN, est-ce que les piles TCP/IP modernes utilisent un générateur pseudo-aléatoire pour le générer ?
C'est ce que j'ai cru comprendre, sans être un grand connaisseur de la chose. Côté pratique, la fonction de détection d'OS (-O) de nmap évalue la prédictibilité du générateur d'ISN et l'affiche si l'option -v est spécifiée. Par exemple, vite fait avec ce que j'ai sous la main :
- Windows 2000 SP4 TCP Sequence Prediction: Class=truly random Difficulty99999 (Good luck!)
- un équipement réseau datant de 2000 environ dont je tairai le nom et la marque par pudeur : TCP Sequence Prediction: ClassdK rule Difficulty=1 (Trivial joke)
Ce n'est pas quand même gourmand en ressources, ce genre de choses ?
Aucune idée.
mpg a écrit :
Concernant l'ISN, est-ce que les piles TCP/IP modernes utilisent un
générateur pseudo-aléatoire pour le générer ?
C'est ce que j'ai cru comprendre, sans être un grand connaisseur de la
chose. Côté pratique, la fonction de détection d'OS (-O) de nmap évalue
la prédictibilité du générateur d'ISN et l'affiche si l'option -v est
spécifiée. Par exemple, vite fait avec ce que j'ai sous la main :
- Windows 2000 SP4
TCP Sequence Prediction: Class=truly random
Difficulty99999 (Good luck!)
- un équipement réseau datant de 2000 environ dont je tairai le nom et
la marque par pudeur :
TCP Sequence Prediction: ClassdK rule
Difficulty=1 (Trivial joke)
Ce n'est pas quand même gourmand en ressources, ce genre de choses ?
Concernant l'ISN, est-ce que les piles TCP/IP modernes utilisent un générateur pseudo-aléatoire pour le générer ?
C'est ce que j'ai cru comprendre, sans être un grand connaisseur de la chose. Côté pratique, la fonction de détection d'OS (-O) de nmap évalue la prédictibilité du générateur d'ISN et l'affiche si l'option -v est spécifiée. Par exemple, vite fait avec ce que j'ai sous la main :
- Windows 2000 SP4 TCP Sequence Prediction: Class=truly random Difficulty99999 (Good luck!)
- un équipement réseau datant de 2000 environ dont je tairai le nom et la marque par pudeur : TCP Sequence Prediction: ClassdK rule Difficulty=1 (Trivial joke)
Ce n'est pas quand même gourmand en ressources, ce genre de choses ?
