filtrer une capture tcpdump pour trouver les paquets manquants

Le
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?

Merci
--
Kevin
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Vincent Bernat
Le #23148421
OoO En cette matinée pluvieuse du mardi 22 février 2011, vers 10:45,
Kevin Denis
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 : po ur
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.
--
I WILL NOT USE ABBREV.
I WILL NOT USE ABBREV.
I WILL NOT USE ABBREV.
-+- Bart Simpson on chalkboard in episode 2F33
Bruno Tréguier
Le #23151771
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...

Cordialement,

Bruno Tréguier
Pascal Hambourg
Le #23152071
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.
Bruno Tréguier
Le #23152241
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
Kevin Denis
Le #23153931
Le 22-02-2011, Vincent Bernat
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
Publicité
Poster une réponse
Anonyme