j'ai créé un petit programme qui envoie des paquets IP par les socket
raw, et j'ai un souci avec la connection :
J'essaye d'ouvrir une connection, manuellement en faisant moi-même le
"handshake". J'envoie donc un paquet avec sendto:
SYN, seq=0, ack=0
je m'attends à recevoir :
SYN, ACK, seq=0, ack=1
Et c'est bien ce qui se passe, je reçois effectivement cette confirmation.
Je veux alors terminer l'établissement de la connection, mais un paquet
RST est envoyé par ma machine, avec un numéro de séquence égal à 1. J'ai
l'impression que le système (Linux), en recevant cet ACK, ne comprend
pas ce paquet non sollicité, et envoie alors RST.
Pourtant, la socket qui envoie les paquets a bien été 'attachée' avec
succès à l'aide de bind() sur l'ip et le port source.
Comment faire pour éviter ce RST vers l'hôte distant ?
"Cedric Blancher" a écrit dans le message de news:
Par contre, tu vas de voir configurer ton OS pour qu'il réponde aux requêtes ARP de cette IP sous peine de ne pas voir les réponses revenir, donc d'une manière ou d'une autre mettre en place un proxy ARP.
Exacte, tu as raison.
--
_SebF
http://www.frameip.com Un site pour les spécialistes IP
"Cedric Blancher" <blancher@cartel-securite.fr> a écrit dans le message de
news: pan.2004.07.26.23.00.50.426916@cartel-securite.fr...
Par contre, tu vas de voir configurer ton OS pour qu'il réponde aux
requêtes ARP de cette IP sous peine de ne pas voir les réponses
revenir, donc d'une manière ou d'une autre mettre en place un proxy ARP.
Exacte, tu as raison.
--
_SebF
http://www.frameip.com
Un site pour les spécialistes IP
"Cedric Blancher" a écrit dans le message de news:
Par contre, tu vas de voir configurer ton OS pour qu'il réponde aux requêtes ARP de cette IP sous peine de ne pas voir les réponses revenir, donc d'une manière ou d'une autre mettre en place un proxy ARP.
Exacte, tu as raison.
--
_SebF
http://www.frameip.com Un site pour les spécialistes IP
Voici une autre idée que l'on ma transmise sur un autre forum : Utiliser une adresse IP spoofé de ton Lan qui n'est bien sur pas utilisé. Puis, en couche 2 via Libcap par exemple, tu effectues une capture afin de réceptionner le retour. L'intérêt est d'intercepter la réponse sans que l'Os la considère pour lui. Ainsi, ton Os n'aura aucune raison d'envoyer un Rst.
C'est exactement la même chose que ce que je proposais juste au dessus :-) Mais ça oblige donc à implémenter non seulement ARP comme Cédric l'a précisé, mais aussi IP (et ICMP) et finalement TCP. Evidemment, suivant les besoins précis, l'implémentation d'IP pourra être minimaliste (pas de gestion du réassemblage, du routage, etc.), et IP n'est probablement pas très difficile à implémenter (moins que TCP en tous cas), mais ça fait quand même un peu de boulot...
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Voici une autre idée que l'on ma transmise sur un autre forum :
Utiliser une adresse IP spoofé de ton Lan qui n'est bien sur pas utilisé.
Puis, en couche 2 via Libcap par exemple, tu effectues une capture afin
de réceptionner le retour. L'intérêt est d'intercepter la réponse sans
que l'Os la considère pour lui. Ainsi, ton Os n'aura aucune raison
d'envoyer un Rst.
C'est exactement la même chose que ce que je proposais juste au dessus :-)
Mais ça oblige donc à implémenter non seulement ARP comme Cédric l'a
précisé, mais aussi IP (et ICMP) et finalement TCP. Evidemment, suivant
les besoins précis, l'implémentation d'IP pourra être minimaliste (pas de
gestion du réassemblage, du routage, etc.), et IP n'est probablement pas
très difficile à implémenter (moins que TCP en tous cas), mais ça fait
quand même un peu de boulot...
Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/
Voici une autre idée que l'on ma transmise sur un autre forum : Utiliser une adresse IP spoofé de ton Lan qui n'est bien sur pas utilisé. Puis, en couche 2 via Libcap par exemple, tu effectues une capture afin de réceptionner le retour. L'intérêt est d'intercepter la réponse sans que l'Os la considère pour lui. Ainsi, ton Os n'aura aucune raison d'envoyer un Rst.
C'est exactement la même chose que ce que je proposais juste au dessus :-) Mais ça oblige donc à implémenter non seulement ARP comme Cédric l'a précisé, mais aussi IP (et ICMP) et finalement TCP. Evidemment, suivant les besoins précis, l'implémentation d'IP pourra être minimaliste (pas de gestion du réassemblage, du routage, etc.), et IP n'est probablement pas très difficile à implémenter (moins que TCP en tous cas), mais ça fait quand même un peu de boulot...
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
_SebF - www.frameip.com
"Jacques Caron" a écrit dans le message de news:
C'est exactement la même chose que ce que je proposais juste au dessus :-)
:)
Mais ça oblige donc à implémenter non seulement ARP comme Cédric l'a précisé,
Oui
mais aussi IP (et ICMP) et finalement TCP. Evidemment, suivant les besoins précis, l'implémentation d'IP pourra être minimaliste (pas de gestion du réassemblage, du routage, etc.), et IP n'est probablement pas très difficile à implémenter (moins que TCP en tous cas), mais ça fait quand même un peu de boulot...
Je ne vois pas pourquoi il y a besoin de tout ça. Car tu peux très bien utiliser les Socket en mode Raw associé à l'option IP_HDRINCL permettant de spécifier l'entête Ip. Alors, tu génères ton datagramme en changeant l'Ip source tout en t'appuyant sur les Socket qui laisse l'entière gestion de la pile Ip à ton Os. Donc pas besoin (dans ce cas) de s'appuyer sur une couche Tcp ou Ip autre.
Je trouvais cette solution plus simple, mais l'histoire de Arp l'a renvoi plus du tout portable.
Cordialement,
--
_SebF
http://www.frameip.com Un site pour les spécialistes IP
"Jacques Caron" <jc@imfeurope.com> a écrit dans le message de news:
opsbshnlqnzscttn@news.free.fr...
C'est exactement la même chose que ce que je proposais juste au dessus :-)
:)
Mais ça oblige donc à implémenter non seulement ARP comme Cédric l'a
précisé,
Oui
mais aussi IP (et ICMP) et finalement TCP. Evidemment, suivant
les besoins précis, l'implémentation d'IP pourra être minimaliste (pas de
gestion du réassemblage, du routage, etc.), et IP n'est probablement pas
très difficile à implémenter (moins que TCP en tous cas), mais ça fait
quand même un peu de boulot...
Je ne vois pas pourquoi il y a besoin de tout ça. Car tu peux très bien
utiliser les Socket en mode Raw associé à l'option IP_HDRINCL permettant de
spécifier l'entête Ip. Alors, tu génères ton datagramme en changeant l'Ip
source tout en t'appuyant sur les Socket qui laisse l'entière gestion de la
pile Ip à ton Os. Donc pas besoin (dans ce cas) de s'appuyer sur une couche
Tcp ou Ip autre.
Je trouvais cette solution plus simple, mais l'histoire de Arp l'a renvoi
plus du tout portable.
Cordialement,
--
_SebF
http://www.frameip.com
Un site pour les spécialistes IP
C'est exactement la même chose que ce que je proposais juste au dessus :-)
:)
Mais ça oblige donc à implémenter non seulement ARP comme Cédric l'a précisé,
Oui
mais aussi IP (et ICMP) et finalement TCP. Evidemment, suivant les besoins précis, l'implémentation d'IP pourra être minimaliste (pas de gestion du réassemblage, du routage, etc.), et IP n'est probablement pas très difficile à implémenter (moins que TCP en tous cas), mais ça fait quand même un peu de boulot...
Je ne vois pas pourquoi il y a besoin de tout ça. Car tu peux très bien utiliser les Socket en mode Raw associé à l'option IP_HDRINCL permettant de spécifier l'entête Ip. Alors, tu génères ton datagramme en changeant l'Ip source tout en t'appuyant sur les Socket qui laisse l'entière gestion de la pile Ip à ton Os. Donc pas besoin (dans ce cas) de s'appuyer sur une couche Tcp ou Ip autre.
Je trouvais cette solution plus simple, mais l'histoire de Arp l'a renvoi plus du tout portable.
Cordialement,
--
_SebF
http://www.frameip.com Un site pour les spécialistes IP
Je ne vois pas pourquoi il y a besoin de tout ça. Car tu peux très bien utiliser les Socket en mode Raw associé à l'option IP_HDRINCL permettant de spécifier l'entête Ip.
Ca s'appelle gérer IP en émission. Pas bien compliqué, il est vrai, il suffit de remplir le header dans ce cas. Note que les raw sockets sont plus ou moins souples (voire disponibles) d'une plateforme à une autre, il vaut donc mieux utiliser une abstraction plus portable comme libinet pour ça.
Alors, tu génères ton datagramme en changeant l'Ip source tout en t'appuyant sur les Socket qui laisse l'entière gestion de la pile Ip à ton Os. Donc pas besoin (dans ce cas) de s'appuyer sur une couche Tcp ou Ip autre.
Ca c'est pour l'émission. Mais il faut aussi recevoir les paquets IP en réponse. On part d'une trame Ethernet brute attrapée avec libpcap, puis il faut repérer les trames ARP et IP, répondre aux requêtes ARP, décoder les trames IP (avec les éventuelles options), gérer la fragmentation, vérifier le checksum, envoyer des ICMP quand il faut, etc. Evidemment, suivant le besoin, on pourra se passer de tout ou partie de tout ça.
Je trouvais cette solution plus simple, mais l'histoire de Arp l'a renvoi plus du tout portable.
Si si. A partir du moment ou est capable d'émettre n'importe quelle trame Ethernet (libinet) et de capturer des trames Ethernet (libpcap), ça devrait l'être sur tout OS supporté par ces librairies.
Evidemment, on part du postulat qu'on utilise des interfaces Ethernet, sinon ça complique un tantinet plus les choses :-(
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Je ne vois pas pourquoi il y a besoin de tout ça. Car tu peux très bien
utiliser les Socket en mode Raw associé à l'option IP_HDRINCL permettant
de spécifier l'entête Ip.
Ca s'appelle gérer IP en émission. Pas bien compliqué, il est vrai, il
suffit de remplir le header dans ce cas. Note que les raw sockets sont
plus ou moins souples (voire disponibles) d'une plateforme à une autre, il
vaut donc mieux utiliser une abstraction plus portable comme libinet pour
ça.
Alors, tu génères ton datagramme en changeant
l'Ip source tout en t'appuyant sur les Socket qui laisse l'entière
gestion
de la pile Ip à ton Os. Donc pas besoin (dans ce cas) de s'appuyer sur
une couche Tcp ou Ip autre.
Ca c'est pour l'émission. Mais il faut aussi recevoir les paquets IP en
réponse. On part d'une trame Ethernet brute attrapée avec libpcap, puis il
faut repérer les trames ARP et IP, répondre aux requêtes ARP, décoder les
trames IP (avec les éventuelles options), gérer la fragmentation, vérifier
le checksum, envoyer des ICMP quand il faut, etc. Evidemment, suivant le
besoin, on pourra se passer de tout ou partie de tout ça.
Je trouvais cette solution plus simple, mais l'histoire de Arp l'a renvoi
plus du tout portable.
Si si. A partir du moment ou est capable d'émettre n'importe quelle trame
Ethernet (libinet) et de capturer des trames Ethernet (libpcap), ça
devrait l'être sur tout OS supporté par ces librairies.
Evidemment, on part du postulat qu'on utilise des interfaces Ethernet,
sinon ça complique un tantinet plus les choses :-(
Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/
Je ne vois pas pourquoi il y a besoin de tout ça. Car tu peux très bien utiliser les Socket en mode Raw associé à l'option IP_HDRINCL permettant de spécifier l'entête Ip.
Ca s'appelle gérer IP en émission. Pas bien compliqué, il est vrai, il suffit de remplir le header dans ce cas. Note que les raw sockets sont plus ou moins souples (voire disponibles) d'une plateforme à une autre, il vaut donc mieux utiliser une abstraction plus portable comme libinet pour ça.
Alors, tu génères ton datagramme en changeant l'Ip source tout en t'appuyant sur les Socket qui laisse l'entière gestion de la pile Ip à ton Os. Donc pas besoin (dans ce cas) de s'appuyer sur une couche Tcp ou Ip autre.
Ca c'est pour l'émission. Mais il faut aussi recevoir les paquets IP en réponse. On part d'une trame Ethernet brute attrapée avec libpcap, puis il faut repérer les trames ARP et IP, répondre aux requêtes ARP, décoder les trames IP (avec les éventuelles options), gérer la fragmentation, vérifier le checksum, envoyer des ICMP quand il faut, etc. Evidemment, suivant le besoin, on pourra se passer de tout ou partie de tout ça.
Je trouvais cette solution plus simple, mais l'histoire de Arp l'a renvoi plus du tout portable.
Si si. A partir du moment ou est capable d'émettre n'importe quelle trame Ethernet (libinet) et de capturer des trames Ethernet (libpcap), ça devrait l'être sur tout OS supporté par ces librairies.
Evidemment, on part du postulat qu'on utilise des interfaces Ethernet, sinon ça complique un tantinet plus les choses :-(
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
_SebF - www.frameip.com
"Jacques Caron" a écrit dans le message de news:
Salut,
Salut Jacques,
Ca s'appelle gérer IP en émission. Pas bien compliqué, il est vrai, il suffit de remplir le header dans ce cas. Note que les raw sockets sont plus ou moins souples (voire disponibles) d'une plateforme à une autre, il vaut donc mieux utiliser une abstraction plus portable comme libinet pour ça.
Je ne connaissais pas Libnet et ça à l'aire très intérréssant. Merci pour l'info.
Cependant, ce n'est pas la même solution. L'utilisation du mode Raw des sockets ne necessite aucune installation du fait que c'est natif à l'Os. C'est pour cela que je penses que le mode Raw est plus "portable" et plus "souple".
Ca c'est pour l'émission. Mais il faut aussi recevoir les paquets IP en réponse. On part d'une trame Ethernet brute attrapée avec libpcap, puis il faut repérer les trames ARP et IP, répondre aux requêtes ARP, décoder les trames IP (avec les éventuelles options), gérer la fragmentation, vérifier le checksum, envoyer des ICMP quand il faut, etc. Evidemment, suivant le besoin, on pourra se passer de tout ou partie de tout ça.
Ca c'est parceque tu gères cela au niveau 2, alors qu'avec le mode Raw, tu t'appuis sur la gestion de la pile Ip de l'Os. Ca porte aussi le defaut de ses avantages, si l'on veux maitriser entièrement la pile IP :)
Si si. A partir du moment ou est capable d'émettre n'importe quelle trame Ethernet (libinet) et de capturer des trames Ethernet (libpcap), ça devrait l'être sur tout OS supporté par ces librairies.
Oui dans ta solution c'est entièrement vrai.
Evidemment, on part du postulat qu'on utilise des interfaces Ethernet, sinon ça complique un tantinet plus les choses :-(
:)
En finale, je défend la solution du mode Raw, mais je suis convaincu par la solution Libpcap qui est moins portable, mais qui offre beaucoup plus.
--
_SebF
http://www.frameip.com Un site pour les spécialistes IP
"Jacques Caron" <jc@imfeurope.com> a écrit dans le message de news:
opsbsw1ve4zscttn@news.free.fr...
Salut,
Salut Jacques,
Ca s'appelle gérer IP en émission. Pas bien compliqué, il est vrai, il
suffit de remplir le header dans ce cas. Note que les raw sockets sont
plus ou moins souples (voire disponibles) d'une plateforme à une autre, il
vaut donc mieux utiliser une abstraction plus portable comme libinet pour
ça.
Je ne connaissais pas Libnet et ça à l'aire très intérréssant. Merci pour
l'info.
Cependant, ce n'est pas la même solution. L'utilisation du mode Raw des
sockets ne necessite aucune installation du fait que c'est natif à l'Os.
C'est pour cela que je penses que le mode Raw est plus "portable" et plus
"souple".
Ca c'est pour l'émission. Mais il faut aussi recevoir les paquets IP en
réponse. On part d'une trame Ethernet brute attrapée avec libpcap, puis il
faut repérer les trames ARP et IP, répondre aux requêtes ARP, décoder les
trames IP (avec les éventuelles options), gérer la fragmentation, vérifier
le checksum, envoyer des ICMP quand il faut, etc. Evidemment, suivant le
besoin, on pourra se passer de tout ou partie de tout ça.
Ca c'est parceque tu gères cela au niveau 2, alors qu'avec le mode Raw, tu
t'appuis sur la gestion de la pile Ip de l'Os.
Ca porte aussi le defaut de ses avantages, si l'on veux maitriser
entièrement la pile IP :)
Si si. A partir du moment ou est capable d'émettre n'importe quelle trame
Ethernet (libinet) et de capturer des trames Ethernet (libpcap), ça
devrait l'être sur tout OS supporté par ces librairies.
Oui dans ta solution c'est entièrement vrai.
Evidemment, on part du postulat qu'on utilise des interfaces Ethernet,
sinon ça complique un tantinet plus les choses :-(
:)
En finale, je défend la solution du mode Raw, mais je suis convaincu par la
solution Libpcap qui est moins portable, mais qui offre beaucoup plus.
--
_SebF
http://www.frameip.com
Un site pour les spécialistes IP
Ca s'appelle gérer IP en émission. Pas bien compliqué, il est vrai, il suffit de remplir le header dans ce cas. Note que les raw sockets sont plus ou moins souples (voire disponibles) d'une plateforme à une autre, il vaut donc mieux utiliser une abstraction plus portable comme libinet pour ça.
Je ne connaissais pas Libnet et ça à l'aire très intérréssant. Merci pour l'info.
Cependant, ce n'est pas la même solution. L'utilisation du mode Raw des sockets ne necessite aucune installation du fait que c'est natif à l'Os. C'est pour cela que je penses que le mode Raw est plus "portable" et plus "souple".
Ca c'est pour l'émission. Mais il faut aussi recevoir les paquets IP en réponse. On part d'une trame Ethernet brute attrapée avec libpcap, puis il faut repérer les trames ARP et IP, répondre aux requêtes ARP, décoder les trames IP (avec les éventuelles options), gérer la fragmentation, vérifier le checksum, envoyer des ICMP quand il faut, etc. Evidemment, suivant le besoin, on pourra se passer de tout ou partie de tout ça.
Ca c'est parceque tu gères cela au niveau 2, alors qu'avec le mode Raw, tu t'appuis sur la gestion de la pile Ip de l'Os. Ca porte aussi le defaut de ses avantages, si l'on veux maitriser entièrement la pile IP :)
Si si. A partir du moment ou est capable d'émettre n'importe quelle trame Ethernet (libinet) et de capturer des trames Ethernet (libpcap), ça devrait l'être sur tout OS supporté par ces librairies.
Oui dans ta solution c'est entièrement vrai.
Evidemment, on part du postulat qu'on utilise des interfaces Ethernet, sinon ça complique un tantinet plus les choses :-(
:)
En finale, je défend la solution du mode Raw, mais je suis convaincu par la solution Libpcap qui est moins portable, mais qui offre beaucoup plus.
--
_SebF
http://www.frameip.com Un site pour les spécialistes IP
Cependant, ce n'est pas la même solution. L'utilisation du mode Raw des sockets ne necessite aucune installation du fait que c'est natif à l'Os. C'est pour cela que je penses que le mode Raw est plus "portable" et plus "souple".
Il y a des subtilités qui font que tous les OS ne supportent pas les raw sockets de la même façon. Libnet (et pas libinet comme je disais auparavant) permet de masquer ces différences.
Ca c'est parceque tu gères cela au niveau 2, alors qu'avec le mode Raw, tu t'appuis sur la gestion de la pile Ip de l'Os.
Oui, mais dans ce cas tu ne peux pas construire ta propre implémentation de TCP en parallèle de l'existante.
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Cependant, ce n'est pas la même solution. L'utilisation du mode Raw des
sockets ne necessite aucune installation du fait que c'est natif à l'Os.
C'est pour cela que je penses que le mode Raw est plus "portable" et plus
"souple".
Il y a des subtilités qui font que tous les OS ne supportent pas les raw
sockets de la même façon. Libnet (et pas libinet comme je disais
auparavant) permet de masquer ces différences.
Ca c'est parceque tu gères cela au niveau 2, alors qu'avec le mode Raw,
tu t'appuis sur la gestion de la pile Ip de l'Os.
Oui, mais dans ce cas tu ne peux pas construire ta propre implémentation
de TCP en parallèle de l'existante.
Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/
Cependant, ce n'est pas la même solution. L'utilisation du mode Raw des sockets ne necessite aucune installation du fait que c'est natif à l'Os. C'est pour cela que je penses que le mode Raw est plus "portable" et plus "souple".
Il y a des subtilités qui font que tous les OS ne supportent pas les raw sockets de la même façon. Libnet (et pas libinet comme je disais auparavant) permet de masquer ces différences.
Ca c'est parceque tu gères cela au niveau 2, alors qu'avec le mode Raw, tu t'appuis sur la gestion de la pile Ip de l'Os.
Oui, mais dans ce cas tu ne peux pas construire ta propre implémentation de TCP en parallèle de l'existante.
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
