trinadh465/external_tcpdump_cve-2018-14469Analyseur de paquets en ligne de commande pour la surveillance réseau et l'acquisition de données, capturant et affichant le trafic réseau pour le dépannage et l'analyse de sécurité.
Pour signaler un problème de sécurité, veuillez envoyer un e-mail à [email protected].
Pour signaler des bogues et autres problèmes, apporter des correctifs, demander une fonctionnalité, fournir un retour général, etc., veuillez consulter le fichier CONTRIBUTING à la racine de l'arborescence des sources de tcpdump.
TCPDUMP 4.x.y Désormais maintenu par « The Tcpdump Group » Voir www.tcpdump.org
Un dépôt Git anonyme est disponible via :
git clone git://bpf.tcpdump.org/tcpdump
auparavant du Lawrence Berkeley National Laboratory
Network Research Group [email protected]
ftp://ftp.ee.lbl.gov/old/tcpdump.tar.Z (3.4)
Ce répertoire contient le code source de tcpdump, un outil de surveillance réseau et d'acquisition de données. Ce logiciel a été initialement développé par le Network Research Group du Lawrence Berkeley National Laboratory. La distribution originale est disponible par ftp anonyme sur ftp.ee.lbl.gov, dans tcpdump.tar.Z. Le développement plus récent est effectué sur tcpdump.org, http://www.tcpdump.org/
Tcpdump utilise libpcap, une interface indépendante du système pour la capture de paquets au niveau utilisateur. Avant de construire tcpdump, vous devez d'abord récupérer et construire libpcap, également issu à l'origine de LBL et désormais maintenu par tcpdump.org ; voir http://www.tcpdump.org/ .
Une fois libpcap construit (installez-le ou assurez-vous qu'il se trouve dans ../libpcap), vous pouvez construire tcpdump en suivant la procédure décrite dans le fichier INSTALL.txt.
Le programme est vaguement basé sur « etherfind » de SMI, bien qu'il ne reste aucun code d'etherfind. Il a été écrit à l'origine par Van Jacobson dans le cadre d'un projet de recherche en cours visant à étudier et à améliorer les performances des passerelles tcp et Internet. Les parties du programme initialement tirées d'etherfind de Sun ont ensuite été réécrites par Steven McCanne de LBL. Pour garantir qu'il ne subsiste aucune trace de code propriétaire dans tcpdump, Steve a écrit ces morceaux à partir de la spécification donnée par la page de manuel, sans accès au code source de tcpdump ni d'etherfind.
Au cours des dernières années, tcpdump a été continuellement amélioré grâce aux excellentes contributions de la communauté Internet (il suffit de parcourir le fichier CHANGES). Nous sommes reconnaissants pour toutes ces contributions.
Richard Stevens offre un excellent traitement des protocoles Internet dans son livre « TCP/IP Illustrated, Volume 1 ». Si vous voulez en apprendre davantage sur tcpdump et sur la façon d'interpréter sa sortie, procurez-vous ce livre.
Quelques outils pour visualiser et analyser les fichiers de trace tcpdump sont disponibles auprès de l'Internet Traffic Archive :
Un autre outil que les utilisateurs de tcpdump pourraient trouver utile est tcpslice :
C'est un programme qui peut être utilisé pour extraire des portions de fichiers de trace binaires tcpdump. Consultez la distribution ci-dessus pour plus de détails et de documentation.
Les versions actuelles peuvent être trouvées sur www.tcpdump.org.
texte original par : Steve McCanne, Craig Leres, Van Jacobson
Ce répertoire contient également quelques programmes awk courts destinés à
servir d'exemples de méthodes pour réduire les données tcpdump lorsque vous
suivez des problèmes réseau particuliers :
send-ack.awk
Simplifie la trace tcpdump d'un ftp (ou d'un autre transfert tcp
unidirectionnel). Comme nous supposons qu'un hôte se contente
d'envoyer et que l'autre se contente d'acquitter, toutes les
informations d'adresse sont omises et nous notons simplement si
le paquet est un « send » ou un « ack ».
Il y a une ligne de sortie par ligne de la trace originale.
Le champ 1 est l'heure du paquet en secondes décimales, relative
au début de la conversation. Le champ 2 est le temps delta depuis
le dernier paquet. Le champ 3 est le type/direction du paquet.
« Send » signifie que des données vont de l'émetteur vers le
récepteur, « ack » signifie qu'un accusé de réception va du
récepteur vers l'émetteur. Un « * » précédent indique que les
données sont une retransmission. Un « - » précédent indique un
trou dans l'espace de séquence (c'est-à-dire un ou des paquets
manquants), un « # » signifie un paquet de taille impaire (pas la
taille maximale de segment). Le champ 4 contient les indicateurs
du paquet (même format que la trace brute). Le champ 5 est le
numéro de séquence (numéro de séquence de départ pour l'émetteur,
prochain numéro de séquence attendu pour les ack). Le nombre entre
parenthèses suivant un ack est le temps delta entre le premier envoi
du paquet et l'ack. Un nombre entre parenthèses suivant un send est
le temps delta entre le premier envoi du paquet et l'envoi courant
(uniquement pour les paquets en double). Les send ou ack en double
ont un nombre entre crochets indiquant le nombre de doublons
jusqu'à présent.
Voici un court exemple tiré du début d'un ftp :
3.00 0.20 send . 512
3.20 0.20 ack . 1024 (0.20)
3.20 0.00 send P 1024
3.40 0.20 ack . 1536 (0.20)
3.80 0.40 * send . 0 (3.80) [2]
3.82 0.02 * ack . 1536 (0.62) [2]
Trois secondes après le début de la conversation, les octets 512 à
1023 ont été envoyés. Ils ont été acquittés 200 ms plus tard. Peu
après, les octets 1024-1535 ont été envoyés et de nouveau acquittés
après 200 ms. Ensuite, sans raison apparente, 0-511 est retransmis,
3,8 secondes après son envoi initial (le temps d'aller-retour pour
ce ftp était de 1 s, ±500 ms). Comme le récepteur attend 1536,
1536 est de nouveau acquitté lorsque 0 arrive.
packetdat.awk
Calcule des données récapitulatives de chunks pour un ftp (ou un
transfert tcp unidirectionnel similaire). [Un « chunk » fait
référence à un bloc de l'espace de séquence -- essentiellement le
numéro de séquence du paquet divisé par la taille maximale de
segment.]
Une ligne récapitulative est imprimée, montrant le nombre de chunks,
le nombre de paquets nécessaires pour envoyer ce nombre de chunks
(s'il n'y a pas de paquets perdus ou dupliqués, le nombre de paquets
doit être égal au nombre de chunks) et le nombre d'ack.
Après la ligne récapitulative vient une ligne d'information par
chunk. La ligne contient huit champs :
1 - le numéro du chunk
2 - le numéro de séquence de départ pour ce chunk
3 - l'heure du premier envoi
4 - l'heure du dernier envoi
5 - l'heure du premier ack
6 - l'heure du dernier ack
7 - le nombre de fois où le chunk a été envoyé
8 - le nombre de fois où le chunk a été acquitté
(toutes les heures sont en secondes décimales, relatives au début
de la conversation.)
À titre d'exemple, voici la première partie de la sortie d'une
trace ftp :
# 134 chunks. 536 packets sent. 508 acks.
1 1 0.00 5.80 0.20 0.20 4 1
2 513 0.28 6.20 0.40 0.40 4 1
3 1025 1.16 6.32 1.20 1.20 4 1
4 1561 1.86 15.00 2.00 2.00 6 1
5 2049 2.16 15.44 2.20 2.20 5 1
6 2585 2.64 16.44 2.80 2.80 5 1
7 3073 3.00 16.66 3.20 3.20 4 1
8 3609 3.20 17.24 3.40 5.82 4 11
9 4097 6.02 6.58 6.20 6.80 2 5