filtrer une capture tcpdump pour trouver les paquets manquants
5 réponses
Kevin Denis
Bonjour,
j'ai lancé une capture sur une machine linux ayant deux interfaces
qui route des paquets:
tcpdump -n -i any -s0 -X -e -w /tmp/capture.cap
J'ai un échantillon assez large, 100Mo.
Je veux désormais prouver que le routeur qui perd des paquets.
C'est simple, il suffit de checker tous les paquets entrants et
vérifier s'ils sont bien tous transmis à l'interface de sortie.
(des paquets sont routés/nattés dans les deux sens).
Comme je n'ai pas envie de le faire à la main, connaissez vous un
moyen automatique de traiter ce cas?
Via tshark, ou wireshark, ou autre?
Perso, je le ferai avec scapy. Mais comme c'est assez gros, ça va peut-être prendre un peu de temps. Un algo assez simple du style : pour chaque paquet dans la capture d'entrée, rechercher le paquet (même port source, même port destination, même numéro de séquence par exemple) dans la capture de sortie. Éventuellement, parser en une seule fois la capture de sortie pour la transformer en un dictionnaire associant les éléments essentiels du paquet au paquet.
Bonsoir,
Attention cependant: pour les paquets sujets à du "SNAT" (source NAT), comme il y a un changement d'adresse source, le port source dans le flux d'entrée et le flux de sortie sont différents dans l'immense majorité des cas...
Cordialement,
Bruno Tréguier
Le 22/02/2011 à 19:29, Vincent Bernat a écrit :
Perso, je le ferai avec scapy. Mais comme c'est assez gros, ça va
peut-être prendre un peu de temps. Un algo assez simple du style : pour
chaque paquet dans la capture d'entrée, rechercher le paquet (même port
source, même port destination, même numéro de séquence par exemple) dans
la capture de sortie. Éventuellement, parser en une seule fois la
capture de sortie pour la transformer en un dictionnaire associant les
éléments essentiels du paquet au paquet.
Bonsoir,
Attention cependant: pour les paquets sujets à du "SNAT" (source NAT),
comme il y a un changement d'adresse source, le port source dans le flux
d'entrée et le flux de sortie sont différents dans l'immense majorité
des cas...
Perso, je le ferai avec scapy. Mais comme c'est assez gros, ça va peut-être prendre un peu de temps. Un algo assez simple du style : pour chaque paquet dans la capture d'entrée, rechercher le paquet (même port source, même port destination, même numéro de séquence par exemple) dans la capture de sortie. Éventuellement, parser en une seule fois la capture de sortie pour la transformer en un dictionnaire associant les éléments essentiels du paquet au paquet.
Bonsoir,
Attention cependant: pour les paquets sujets à du "SNAT" (source NAT), comme il y a un changement d'adresse source, le port source dans le flux d'entrée et le flux de sortie sont différents dans l'immense majorité des cas...
Cordialement,
Bruno Tréguier
Pascal Hambourg
Salut,
Bruno Tréguier a écrit :
Attention cependant: pour les paquets sujets à du "SNAT" (source NAT), comme il y a un changement d'adresse source, le port source dans le flux d'entrée et le flux de sortie sont différents dans l'immense majorité des cas...
L'immense majorité ? Par défaut, la cible SNAT d'iptables essaie de ne pas modifier le port source si possible.
Salut,
Bruno Tréguier a écrit :
Attention cependant: pour les paquets sujets à du "SNAT" (source NAT),
comme il y a un changement d'adresse source, le port source dans le flux
d'entrée et le flux de sortie sont différents dans l'immense majorité
des cas...
L'immense majorité ?
Par défaut, la cible SNAT d'iptables essaie de ne pas modifier le port
source si possible.
Attention cependant: pour les paquets sujets à du "SNAT" (source NAT), comme il y a un changement d'adresse source, le port source dans le flux d'entrée et le flux de sortie sont différents dans l'immense majorité des cas...
L'immense majorité ? Par défaut, la cible SNAT d'iptables essaie de ne pas modifier le port source si possible.
Bruno Tréguier
Le 24/02/2011 à 0:35, Pascal Hambourg a écrit :
Salut,
Bonjour,
L'immense majorité ? Par défaut, la cible SNAT d'iptables essaie de ne pas modifier le port source si possible.
Oups. Oui, vous avez raison. En supprimant la question initiale de Kévin Denis de mon message, j'avais effectivement perdu de vue qu'il s'agissait d'un environnement Linux. Cela dit, même si la probabilité d'occurrence est plus faible que je ne le pensais, il n'en reste pas moins que le port source peut varier dans certains cas, et qu'il est donc hasardeux de le prendre en compte dans les comparaisons.
Cordialement,
Bruno Tréguier
Le 24/02/2011 à 0:35, Pascal Hambourg a écrit :
Salut,
Bonjour,
L'immense majorité ?
Par défaut, la cible SNAT d'iptables essaie de ne pas modifier le port
source si possible.
Oups. Oui, vous avez raison. En supprimant la question initiale de Kévin
Denis de mon message, j'avais effectivement perdu de vue qu'il
s'agissait d'un environnement Linux. Cela dit, même si la probabilité
d'occurrence est plus faible que je ne le pensais, il n'en reste pas
moins que le port source peut varier dans certains cas, et qu'il est
donc hasardeux de le prendre en compte dans les comparaisons.
L'immense majorité ? Par défaut, la cible SNAT d'iptables essaie de ne pas modifier le port source si possible.
Oups. Oui, vous avez raison. En supprimant la question initiale de Kévin Denis de mon message, j'avais effectivement perdu de vue qu'il s'agissait d'un environnement Linux. Cela dit, même si la probabilité d'occurrence est plus faible que je ne le pensais, il n'en reste pas moins que le port source peut varier dans certains cas, et qu'il est donc hasardeux de le prendre en compte dans les comparaisons.
Cordialement,
Bruno Tréguier
Kevin Denis
Le 22-02-2011, Vincent Bernat a écrit :
j'ai lancé une capture sur une machine linux ayant deux interfaces qui route des paquets: tcpdump -n -i any -s0 -X -e -w /tmp/capture.cap J'ai un échantillon assez large, 100Mo.
Je veux désormais prouver que le routeur qui perd des paquets. C'est simple, il suffit de checker tous les paquets entrants et vérifier s'ils sont bien tous transmis à l'interface de sortie. (des paquets sont routés/nattés dans les deux sens).
Comme je n'ai pas envie de le faire à la main, connaissez vous un moyen automatique de traiter ce cas? Via tshark, ou wireshark, ou autre?
Perso, je le ferai avec scapy. Mais comme c'est assez gros, ça va peut-être prendre un peu de temps. Un algo assez simple du style : pour chaque paquet dans la capture d'entrée, rechercher le paquet (même port source, même port destination, même numéro de séquence par exemple) dans la capture de sortie. Éventuellement, parser en une seule fois la capture de sortie pour la transformer en un dictionnaire associant les éléments essentiels du paquet au paquet.
J'ai résolu le problème assez basiquement en fait en m'inspirant de l'idée. Tout d'abord un filtre, pipée dans un compteur tshark -r /tmp/capture.cap -R "(..)" -Tfields -e "ip.src" -e "ip.dst" -e "udp.srcport" -e "udp.dstport" -e "frame.number" | uniq -c -w 38 | grep ^" 1"
Ceci me permet de filtrer les paquets selon certaines caractéristiques, (là, des flux UDP non natés). Le uniq -c compte les paquets, donc si j'ai une paire, il y en a 2. Le grep ne m'affiche que les lignes uniques. Il y a un peu d'artefacts, mais c'est convenable (traitable à la main) pour les flux. Le frame.number me permet de remonter tout de suite dans la capture wireshark. -- Kevin
Le 22-02-2011, Vincent Bernat <bernat@luffy.cx> a écrit :
j'ai lancé une capture sur une machine linux ayant deux interfaces
qui route des paquets:
tcpdump -n -i any -s0 -X -e -w /tmp/capture.cap
J'ai un échantillon assez large, 100Mo.
Je veux désormais prouver que le routeur qui perd des paquets.
C'est simple, il suffit de checker tous les paquets entrants et
vérifier s'ils sont bien tous transmis à l'interface de sortie.
(des paquets sont routés/nattés dans les deux sens).
Comme je n'ai pas envie de le faire à la main, connaissez vous un
moyen automatique de traiter ce cas?
Via tshark, ou wireshark, ou autre?
Perso, je le ferai avec scapy. Mais comme c'est assez gros, ça va
peut-être prendre un peu de temps. Un algo assez simple du style : pour
chaque paquet dans la capture d'entrée, rechercher le paquet (même port
source, même port destination, même numéro de séquence par exemple) dans
la capture de sortie. Éventuellement, parser en une seule fois la
capture de sortie pour la transformer en un dictionnaire associant les
éléments essentiels du paquet au paquet.
J'ai résolu le problème assez basiquement en fait en m'inspirant de
l'idée. Tout d'abord un filtre, pipée dans un compteur
tshark -r /tmp/capture.cap -R "(..)" -Tfields -e "ip.src" -e "ip.dst"
-e "udp.srcport" -e "udp.dstport" -e "frame.number"
| uniq -c -w 38 | grep ^" 1"
Ceci me permet de filtrer les paquets selon certaines caractéristiques,
(là, des flux UDP non natés). Le uniq -c compte les paquets, donc
si j'ai une paire, il y en a 2. Le grep ne m'affiche que les lignes
uniques. Il y a un peu d'artefacts, mais c'est convenable (traitable
à la main) pour les flux. Le frame.number me permet de
remonter tout de suite dans la capture wireshark.
--
Kevin
j'ai lancé une capture sur une machine linux ayant deux interfaces qui route des paquets: tcpdump -n -i any -s0 -X -e -w /tmp/capture.cap J'ai un échantillon assez large, 100Mo.
Je veux désormais prouver que le routeur qui perd des paquets. C'est simple, il suffit de checker tous les paquets entrants et vérifier s'ils sont bien tous transmis à l'interface de sortie. (des paquets sont routés/nattés dans les deux sens).
Comme je n'ai pas envie de le faire à la main, connaissez vous un moyen automatique de traiter ce cas? Via tshark, ou wireshark, ou autre?
Perso, je le ferai avec scapy. Mais comme c'est assez gros, ça va peut-être prendre un peu de temps. Un algo assez simple du style : pour chaque paquet dans la capture d'entrée, rechercher le paquet (même port source, même port destination, même numéro de séquence par exemple) dans la capture de sortie. Éventuellement, parser en une seule fois la capture de sortie pour la transformer en un dictionnaire associant les éléments essentiels du paquet au paquet.
J'ai résolu le problème assez basiquement en fait en m'inspirant de l'idée. Tout d'abord un filtre, pipée dans un compteur tshark -r /tmp/capture.cap -R "(..)" -Tfields -e "ip.src" -e "ip.dst" -e "udp.srcport" -e "udp.dstport" -e "frame.number" | uniq -c -w 38 | grep ^" 1"
Ceci me permet de filtrer les paquets selon certaines caractéristiques, (là, des flux UDP non natés). Le uniq -c compte les paquets, donc si j'ai une paire, il y en a 2. Le grep ne m'affiche que les lignes uniques. Il y a un peu d'artefacts, mais c'est convenable (traitable à la main) pour les flux. Le frame.number me permet de remonter tout de suite dans la capture wireshark. -- Kevin
