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 ?
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 ?
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 ?
Salut,
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.
Ben non. Un port est un concept UDP ou TCP, pas un concept IP. Donc le
kernel n'a aucune idée que ce port est utilisé par quelqu'un d'autre (il
n'y a normalement qu'une seule implémenttion de TCP ou d'UDP au dessus
d'IP, le multiplexage n'est pas prévu à ce niveau-là, mais uniquement en
dessous (au niveau du protocole, entre IP et TCP ou UDP par exemple) ou au
dessus (entre TCP ou UDP et des connexions sur des ports donnés).
Comment faire pour éviter ce RST vers l'hôte distant ?
Sous FreeBSD je mettrais un divert dans ipfw pour que les paquets soient
envoyés vers l'appli mais que TCP ne le voie pas, mais sous Linux je ne
sais pas trop. D'une façon ou d'une autre il faut filtrer mais il faut
quand même que l'appli les reçoive, pas trivial en userland...
Salut,
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.
Ben non. Un port est un concept UDP ou TCP, pas un concept IP. Donc le
kernel n'a aucune idée que ce port est utilisé par quelqu'un d'autre (il
n'y a normalement qu'une seule implémenttion de TCP ou d'UDP au dessus
d'IP, le multiplexage n'est pas prévu à ce niveau-là, mais uniquement en
dessous (au niveau du protocole, entre IP et TCP ou UDP par exemple) ou au
dessus (entre TCP ou UDP et des connexions sur des ports donnés).
Comment faire pour éviter ce RST vers l'hôte distant ?
Sous FreeBSD je mettrais un divert dans ipfw pour que les paquets soient
envoyés vers l'appli mais que TCP ne le voie pas, mais sous Linux je ne
sais pas trop. D'une façon ou d'une autre il faut filtrer mais il faut
quand même que l'appli les reçoive, pas trivial en userland...
Salut,
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.
Ben non. Un port est un concept UDP ou TCP, pas un concept IP. Donc le
kernel n'a aucune idée que ce port est utilisé par quelqu'un d'autre (il
n'y a normalement qu'une seule implémenttion de TCP ou d'UDP au dessus
d'IP, le multiplexage n'est pas prévu à ce niveau-là, mais uniquement en
dessous (au niveau du protocole, entre IP et TCP ou UDP par exemple) ou au
dessus (entre TCP ou UDP et des connexions sur des ports donnés).
Comment faire pour éviter ce RST vers l'hôte distant ?
Sous FreeBSD je mettrais un divert dans ipfw pour que les paquets soient
envoyés vers l'appli mais que TCP ne le voie pas, mais sous Linux je ne
sais pas trop. D'une façon ou d'une autre il faut filtrer mais il faut
quand même que l'appli les reçoive, pas trivial en userland...
"Jacques Caron" a écrit dans le message de news:
Salut
Le mode Raw des Socket permet de ne pas utiliser la gestion Tcp par l'Os et
de faire ce que tu veux en brut (raw). Imagine toi que tu travail avec le
numméro de protocole 255 et non 17. Donc l'Os n'a pas pris en compte ton
Syn.
De plus, as-tu spécifié l'entête IP en plus du mode Raw ?
Comment faire pour éviter ce RST vers l'hôte distant ?
Pourquoi ne pas utiliser les Socket en mode Tcp ? Puis tu ouvre ta session
avec la commande Connect().
http://www.frameip.com/c_mode_connecte/
"Jacques Caron" <jc@imfeurope.com> a écrit dans le message de news:
opsbnxcar1zscttn@news.free.fr...
Salut
Le mode Raw des Socket permet de ne pas utiliser la gestion Tcp par l'Os et
de faire ce que tu veux en brut (raw). Imagine toi que tu travail avec le
numméro de protocole 255 et non 17. Donc l'Os n'a pas pris en compte ton
Syn.
De plus, as-tu spécifié l'entête IP en plus du mode Raw ?
Comment faire pour éviter ce RST vers l'hôte distant ?
Pourquoi ne pas utiliser les Socket en mode Tcp ? Puis tu ouvre ta session
avec la commande Connect().
http://www.frameip.com/c_mode_connecte/
"Jacques Caron" a écrit dans le message de news:
Salut
Le mode Raw des Socket permet de ne pas utiliser la gestion Tcp par l'Os et
de faire ce que tu veux en brut (raw). Imagine toi que tu travail avec le
numméro de protocole 255 et non 17. Donc l'Os n'a pas pris en compte ton
Syn.
De plus, as-tu spécifié l'entête IP en plus du mode Raw ?
Comment faire pour éviter ce RST vers l'hôte distant ?
Pourquoi ne pas utiliser les Socket en mode Tcp ? Puis tu ouvre ta session
avec la commande Connect().
http://www.frameip.com/c_mode_connecte/
Le mode Raw des Socket permet de ne pas utiliser la gestion Tcp par l'Os
et
de faire ce que tu veux en brut (raw). Imagine toi que tu travail avec
le
numméro de protocole 255 et non 17. Donc l'Os n'a pas pris en compte ton
Syn.
Comment est-il possible qu'il le prenne en compte sans créer une
connection complète ?
Oui, c'est bien le but de l'opération
Bien sûr, avec une socket créée avec SOCK_STREAM (tcp), puis un
connect() et des send(), mais mon but est de pouvoir justement contrôler
toutes ces étapes. Je ne me limite d'ailleurs pas à tcp, ni même à ip,
mais le problème ne se pose que dans ce cas. je suis capable d'envoyer
tous le paquets que je veux, mais les retours posent parfois problème.
J'ai lancé un SYN scan avec nmap, et, lorsqu'un port est ouvert, un SYN,
ACK revient, mais un RST est également envoyé. Je ne sais pas trop
comment il est possible de faire autrement, peut-être qu'au niveau noyau
(LKM), il est possible de filtrer ce paquet, ou de "prévenir" le système
de cette connection.
Le mode Raw des Socket permet de ne pas utiliser la gestion Tcp par l'Os
et
de faire ce que tu veux en brut (raw). Imagine toi que tu travail avec
le
numméro de protocole 255 et non 17. Donc l'Os n'a pas pris en compte ton
Syn.
Comment est-il possible qu'il le prenne en compte sans créer une
connection complète ?
Oui, c'est bien le but de l'opération
Bien sûr, avec une socket créée avec SOCK_STREAM (tcp), puis un
connect() et des send(), mais mon but est de pouvoir justement contrôler
toutes ces étapes. Je ne me limite d'ailleurs pas à tcp, ni même à ip,
mais le problème ne se pose que dans ce cas. je suis capable d'envoyer
tous le paquets que je veux, mais les retours posent parfois problème.
J'ai lancé un SYN scan avec nmap, et, lorsqu'un port est ouvert, un SYN,
ACK revient, mais un RST est également envoyé. Je ne sais pas trop
comment il est possible de faire autrement, peut-être qu'au niveau noyau
(LKM), il est possible de filtrer ce paquet, ou de "prévenir" le système
de cette connection.
Le mode Raw des Socket permet de ne pas utiliser la gestion Tcp par l'Os
et
de faire ce que tu veux en brut (raw). Imagine toi que tu travail avec
le
numméro de protocole 255 et non 17. Donc l'Os n'a pas pris en compte ton
Syn.
Comment est-il possible qu'il le prenne en compte sans créer une
connection complète ?
Oui, c'est bien le but de l'opération
Bien sûr, avec une socket créée avec SOCK_STREAM (tcp), puis un
connect() et des send(), mais mon but est de pouvoir justement contrôler
toutes ces étapes. Je ne me limite d'ailleurs pas à tcp, ni même à ip,
mais le problème ne se pose que dans ce cas. je suis capable d'envoyer
tous le paquets que je veux, mais les retours posent parfois problème.
J'ai lancé un SYN scan avec nmap, et, lorsqu'un port est ouvert, un SYN,
ACK revient, mais un RST est également envoyé. Je ne sais pas trop
comment il est possible de faire autrement, peut-être qu'au niveau noyau
(LKM), il est possible de filtrer ce paquet, ou de "prévenir" le système
de cette connection.
C'est en fait une bonne question. J'ai pas la réponse, mais je vais
planché
dessus. Laisse moi du temps et je reviendrais sur ce Post. Sauf si
quelqu'un
nous apportait la solution avant :)
C'est en fait une bonne question. J'ai pas la réponse, mais je vais
planché
dessus. Laisse moi du temps et je reviendrais sur ce Post. Sauf si
quelqu'un
nous apportait la solution avant :)
C'est en fait une bonne question. J'ai pas la réponse, mais je vais
planché
dessus. Laisse moi du temps et je reviendrais sur ce Post. Sauf si
quelqu'un
nous apportait la solution avant :)
"_SebF - www.frameip.com" a écrit dans le
message de news: ce0jtv$fk5$C'est en fait une bonne question. J'ai pas la réponse, mais je vais
planchédessus. Laisse moi du temps et je reviendrais sur ce Post. Sauf si
quelqu'unnous apportait la solution avant :)
J'ai testé mon générateur de datagramme qui s'appui uniquement sur les
Socket raw et l'option IP_HDRINCL.
http://www.frameip.com/frameip/
Il fait exactement ce que tu décris. Envoi un datagramme Syn puis réception
d'un Syn Ack et enfin l'Os (Win32) renvoi un Rst
J'ai essayé de :
- Spécifier un port source non écouté
- Spécifier un port source écouté par un process Windows
- Spécifier un port source écouté par un de mes process. Qui écoute ce
port Tcp avec les commandes Bind()-Listen().
Ca n'a rien changé, le rst est envoyé dans tous les cas. Ce qui est normale
en soit.
Mais la question est comment l'évité. Et l'a, à priori, deux idées :
- La première, comme l'a dit Jacques, un filtre évitant que le
datagramme Rst se diffuse sur le média physique.
- Le second, serait un driver au niveau 2 qui intercepterait les paquets
entrant sur un port spécifique afin de ne pas donner le paquet Syn, Ack à
Windows. Je n'ai pas testé.
J'ai posé la question aussi sur d'autre forum et si j'ai des nouvelles, je
te tiendrais au courrant.
@+
"_SebF - www.frameip.com" <onsespam@encore.et.encore.com> a écrit dans le
message de news: ce0jtv$fk5$1@news.tiscali.fr...
C'est en fait une bonne question. J'ai pas la réponse, mais je vais
planché
dessus. Laisse moi du temps et je reviendrais sur ce Post. Sauf si
quelqu'un
nous apportait la solution avant :)
J'ai testé mon générateur de datagramme qui s'appui uniquement sur les
Socket raw et l'option IP_HDRINCL.
http://www.frameip.com/frameip/
Il fait exactement ce que tu décris. Envoi un datagramme Syn puis réception
d'un Syn Ack et enfin l'Os (Win32) renvoi un Rst
J'ai essayé de :
- Spécifier un port source non écouté
- Spécifier un port source écouté par un process Windows
- Spécifier un port source écouté par un de mes process. Qui écoute ce
port Tcp avec les commandes Bind()-Listen().
Ca n'a rien changé, le rst est envoyé dans tous les cas. Ce qui est normale
en soit.
Mais la question est comment l'évité. Et l'a, à priori, deux idées :
- La première, comme l'a dit Jacques, un filtre évitant que le
datagramme Rst se diffuse sur le média physique.
- Le second, serait un driver au niveau 2 qui intercepterait les paquets
entrant sur un port spécifique afin de ne pas donner le paquet Syn, Ack à
Windows. Je n'ai pas testé.
J'ai posé la question aussi sur d'autre forum et si j'ai des nouvelles, je
te tiendrais au courrant.
@+
"_SebF - www.frameip.com" a écrit dans le
message de news: ce0jtv$fk5$C'est en fait une bonne question. J'ai pas la réponse, mais je vais
planchédessus. Laisse moi du temps et je reviendrais sur ce Post. Sauf si
quelqu'unnous apportait la solution avant :)
J'ai testé mon générateur de datagramme qui s'appui uniquement sur les
Socket raw et l'option IP_HDRINCL.
http://www.frameip.com/frameip/
Il fait exactement ce que tu décris. Envoi un datagramme Syn puis réception
d'un Syn Ack et enfin l'Os (Win32) renvoi un Rst
J'ai essayé de :
- Spécifier un port source non écouté
- Spécifier un port source écouté par un process Windows
- Spécifier un port source écouté par un de mes process. Qui écoute ce
port Tcp avec les commandes Bind()-Listen().
Ca n'a rien changé, le rst est envoyé dans tous les cas. Ce qui est normale
en soit.
Mais la question est comment l'évité. Et l'a, à priori, deux idées :
- La première, comme l'a dit Jacques, un filtre évitant que le
datagramme Rst se diffuse sur le média physique.
- Le second, serait un driver au niveau 2 qui intercepterait les paquets
entrant sur un port spécifique afin de ne pas donner le paquet Syn, Ack à
Windows. Je n'ai pas testé.
J'ai posé la question aussi sur d'autre forum et si j'ai des nouvelles, je
te tiendrais au courrant.
@+
Le problème de la portabilité se poserait alors. Mon code compile sous
un unix-like, et est assez facilement portable vers Windows. Mais s'il
faut toucher aux modules noyau, que ce soit sous linux ou windows, la
portablilité est bien plus difficile.
Le problème de la portabilité se poserait alors. Mon code compile sous
un unix-like, et est assez facilement portable vers Windows. Mais s'il
faut toucher aux modules noyau, que ce soit sous linux ou windows, la
portablilité est bien plus difficile.
Le problème de la portabilité se poserait alors. Mon code compile sous
un unix-like, et est assez facilement portable vers Windows. Mais s'il
faut toucher aux modules noyau, que ce soit sous linux ou windows, la
portablilité est bien plus difficile.
On Mon, 26 Jul 2004 01:55:37 +0200, Nicolas Favre-Félix
wrote:Le problème de la portabilité se poserait alors. Mon code compile sous
un unix-like, et est assez facilement portable vers Windows. Mais s'il
faut toucher aux modules noyau, que ce soit sous linux ou windows, la
portablilité est bien plus difficile.
Il va donc falloir trouver des ruses, et celles-ci ne seront clairement
pas portables (mais elles peuvent rester limitées en nombre de variantes
et en importance). Dans certains cas de figure, tu pourras peut-être faire
appel à une librairie comme libinet qui présente une interface standard
pour des implémentations diverses adaptées à l'environnement.
Tu pourrais ainsi utiliser une autre adresse IP que celle configurée sur
la machine, ce qui t'oblige à ensuite capturer le trafic reçu au niveau
Ethernet (et gérer ARP, IP, ICMP et TCP toi-même).
Dans tous les cas, il va bien entendu aussi falloir faire la différence,
justement, entre tes connexions et celles du noyau (et empêcher aussi le
noyau de lancer des connexions qui entrent en conflit avec les tiennes, et
vice-versa).
On Mon, 26 Jul 2004 01:55:37 +0200, Nicolas Favre-Félix
<n_point_favrefelix@free_point_fr> wrote:
Le problème de la portabilité se poserait alors. Mon code compile sous
un unix-like, et est assez facilement portable vers Windows. Mais s'il
faut toucher aux modules noyau, que ce soit sous linux ou windows, la
portablilité est bien plus difficile.
Il va donc falloir trouver des ruses, et celles-ci ne seront clairement
pas portables (mais elles peuvent rester limitées en nombre de variantes
et en importance). Dans certains cas de figure, tu pourras peut-être faire
appel à une librairie comme libinet qui présente une interface standard
pour des implémentations diverses adaptées à l'environnement.
Tu pourrais ainsi utiliser une autre adresse IP que celle configurée sur
la machine, ce qui t'oblige à ensuite capturer le trafic reçu au niveau
Ethernet (et gérer ARP, IP, ICMP et TCP toi-même).
Dans tous les cas, il va bien entendu aussi falloir faire la différence,
justement, entre tes connexions et celles du noyau (et empêcher aussi le
noyau de lancer des connexions qui entrent en conflit avec les tiennes, et
vice-versa).
On Mon, 26 Jul 2004 01:55:37 +0200, Nicolas Favre-Félix
wrote:Le problème de la portabilité se poserait alors. Mon code compile sous
un unix-like, et est assez facilement portable vers Windows. Mais s'il
faut toucher aux modules noyau, que ce soit sous linux ou windows, la
portablilité est bien plus difficile.
Il va donc falloir trouver des ruses, et celles-ci ne seront clairement
pas portables (mais elles peuvent rester limitées en nombre de variantes
et en importance). Dans certains cas de figure, tu pourras peut-être faire
appel à une librairie comme libinet qui présente une interface standard
pour des implémentations diverses adaptées à l'environnement.
Tu pourrais ainsi utiliser une autre adresse IP que celle configurée sur
la machine, ce qui t'oblige à ensuite capturer le trafic reçu au niveau
Ethernet (et gérer ARP, IP, ICMP et TCP toi-même).
Dans tous les cas, il va bien entendu aussi falloir faire la différence,
justement, entre tes connexions et celles du noyau (et empêcher aussi le
noyau de lancer des connexions qui entrent en conflit avec les tiennes, et
vice-versa).
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.
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.
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.
