Objectif : diagnostic immédiat d’un problème réseau ou applicatif en regardant uniquement les flags TCP.

Tout le TCP :

tcpdump -nn -i eth0 tcp 

Voir les erreurs (RST) :

tcpdump -nn 'tcp[tcpflags] & tcp-rst != 0' 

Voir les tentatives de connexion :

tcpdump -nn 'tcp[tcpflags] & tcp-syn != 0' 

• SYN sans SYN-ACK → réseau ou filtrage
• RST → refus ou coupure
• Handshake OK sans trafic → applicatif

À utiliser comme fiche réflexe lors d’une analyse tcpdump en production.

lea-linux

blog.stephane-robert

#tcpdump --version
#apt update
#apt install tcpdump
ou
#yum install tcpdump
ou
#dnf install tcpdump

#tcpdump -D
#tcpdump -i eth0

Plusieurs options permettent de contrôler la quantité de détails affichés :

• v : augmente la verbosité et affiche plus d’informations sur les paquets, comme le Time-to-Live (TTL) et le type de service.
• vv : niveau de verbosité encore plus élevé, montrant par exemple les noms de domaine pour les adresses IP.
• vvv : verbosité maximale pour une capture encore plus détaillée.

exemple:

#tcpdump -i eth0 -v

#tcpdump host IP and port 389 -vvv -A

-A ⇒ pour entête (Attention mdp en clair pour non LDAPS)

#tcpdump -i ens33 -nn -s0 -v port 443

• -i : Sélectionnez l’interface sur laquelle la capture doit avoir lieu,
       ce sera souvent une carte Ethernet ou un adaptateur sans fil,
       mais pourrait également être un vlan ou quelque chose de plus inhabituel.
       Pas toujours nécessaire s’il n’y a qu’une seule carte réseau.
• -nn : un seul (n) ne résoudra pas les noms d’hôte.
        Un double (nn) ne résoudra pas les noms d’hôte ou les ports.
        Ceci est pratique non seulement pour visualiser les numéros IP / port,
        mais également lors de la capture d’une grande quantité de données, car la résolution du nom ralentira la capture.
• -s0 : longueur de capture, est la taille du paquet à capturer.
        -s0 définira la taille sur illimité – utilisez ceci si vous voulez capturer tout le trafic.
        Nécessaire si vous souhaitez extraire des binaires / fichiers du trafic réseau.
• -v: Verbose, l’utilisation de (-v) ou (-vv) augmente la quantité de détails affichés dans la sortie,
      affichant souvent des informations plus spécifiques au protocole.
• port 443 : il s’agit d’un filtre de port commun pour capturer uniquement le trafic sur le port 80,
             c’est bien sûr généralement HTTPS.

#tcpdump -i eth0 -c 10

#tcpdump -i eth0 -X

#tcpdump src 192.168.1.1

#tcpdump src net 192.168.1.0/24

#tcpdump dst 192.168.1.100

#tcpdump port 80

#tcpdump tcp

#tcpdump src 192.168.1.1 and tcp port 80

Ce fichier peut ensuite être lu par TCPDump ou par d’autres logiciels de capture et d’analyse comme Wireshark.

#tcpdump -i eth0 -w capture.pcap

#tcpdump -r capture.pcap

Ce filtre affiche uniquement les paquets du fichier de capture qui utilisent le port 80.

#tcpdump -r capture.pcap port 80

Écouter tout le trafic entre l'hôte 1 et l'hôte 2 ou 3 (les antislashs devant les parenthèses servent à ne pas faire interpréter ses dernières par un shell) :

#tcpdump host hote1 and \( hote2 or hote3 \)

Tous les paquets IP entre l'hôte 1 et le reste du réseau, sauf l'hôte 2 :

#tcpdump ip host hote1 and not hote2

Pour afficher les paquets SYN et le paquets FIN de chaque session TCP d'un hôte qui n'est pas sur notre réseau :

#tcpdump 'tcp[tcpflags] & (tcp-syn|tcp-fin) != 0 and not src and dst net ladresse_du_reseau_local'

Pour afficher tous les paquets HTTP sur IPv4 qui viennent ou arrivent sur le port 80 et qui ne contiennent que des données (pas de SYN, pas de FIN, pas de paquet ne contenant qu'un ACK):

#tcpdump 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)'

Les scans de port sont souvent utilisés par des attaquants pour identifier les services actifs sur une machine. Avec TCPDump, vous pouvez capturer et surveiller les tentatives de connexion suspectes sur différents ports.

Pour capturer toutes les connexions TCP entrantes sur des ports communs (par exemple, de 1 à 1024), utilisez la commande suivante :

#tcpdump 'tcp[13] == 2' and portrange 1-1024

Ici, tcp[13] == 2 filtre les paquets SYN, qui sont souvent utilisés lors d’un scan de port. En surveillant ces paquets, vous pouvez identifier des activités de scan sur des ports critiques (SSH, HTTP, etc.).

Le port 22 est fréquemment ciblé par des attaques de force brute visant à accéder aux services SSH. En utilisant TCPDump, vous pouvez capturer les tentatives de connexion à ce port pour identifier des activités suspectes.

#tcpdump -i eth0 port 22 and 'tcp[13] == 2'

Ce filtre capture uniquement les paquets SYN vers le port 22, ce qui indique une tentative de connexion initiale. En analysant la fréquence de ces paquets, vous pouvez identifier une tentative de brute force si vous observez un grand nombre de paquets SYN depuis la même adresse IP ou des adresses IP différentes dans un court laps de temps.

Le DNS est souvent utilisé dans des attaques, comme pour des exfiltrations de données ou des attaques DDoS basées sur des requêtes amplifiées. Vous pouvez surveiller le trafic DNS en filtrant le port 53 pour capturer toutes les requêtes et réponses DNS.

#tcpdump -i eth0 port 53

En analysant les paquets DNS, vous pouvez détecter des comportements suspects, comme un nombre inhabituel de requêtes de la part d’un hôte ou des requêtes vers des domaines inconnus. Cela peut indiquer une activité malveillante, comme l’utilisation de DNS pour des communications de commande et contrôle (C2).

Les attaques par DoS saturent les ressources réseau pour rendre un service indisponible. En capturant les paquets à grande fréquence sur un même port ou protocole, TCPDump peut aider à détecter des flux de trafic anormalement élevés.

Pour capturer uniquement les paquets ICMP, souvent utilisés dans les attaques de type ping flood, utilisez :

#tcpdump -i eth0 icmp

L’analyse des paquets ICMP vous permet de voir si un volume anormal de requêtes ping est envoyé à une machine, ce qui pourrait être le signe d’un DoS basé sur ICMP.

Pour surveiller toutes les tentatives de connexion à des ports non utilisés ou bloqués (ce qui peut signaler une exploration par un attaquant), vous pouvez capturer le trafic à destination de ports spécifiques en dehors des ports de service habituels.

Par exemple, pour capturer les connexions tentées sur des ports non standard (au-delà de 1024) :

#tcpdump 'tcp[13] == 2' and portrange 1025-65535

Ce type de capture peut révéler des tentatives d’accès à des services non autorisés ou des ports peu communs, souvent associés à des activités de reconnaissance.

Les attaques par amplification UDP, qui exploitent des services comme DNS ou NTP, utilisent des paquets UDP pour générer un volume important de trafic. Vous pouvez surveiller les paquets UDP pour détecter des pics inhabituels de trafic.

Par exemple, pour capturer le trafic UDP sur le port 123 (NTP) :

#tcpdump -i eth0 udp port 123

Cela permet d’observer si le serveur reçoit un nombre inhabituel de paquets NTP, ce qui pourrait indiquer une tentative d’amplification UDP par DoS.

TCPDump peut être insuffiisant pour détecter certaines attaques avancées, comme les attaques de type DNS tunneling ou les attaques de type SYN flood. C’est là que des outils de détection d’intrusion (IDS) ou de prévention d’intrusion (IPS) plus avancés peuvent être nécessaires, comme Suricata ou Snort.

Voici quelques indices pour vous aider à trouver le problème dans un cas général :

• Vous n'écoutez pas la bonne interface réseau, bête, mais ça peut arriver, surtout si vous ne précisez pas à tcpdump l'interface réseau à écouter alors que vous en avez plusieurs ;

• Vous êtes sur un switch, celui-ci n'est sensé diriger que votre trafic sur le réseau, donc si vous avez une machine qui agit comme une sonde (c'est à dire sans adresse IP, qui se contente d'écouter) il se peut que le switch n'ait pas de paquets pour vous. Certains switchs d'assez haut niveau ont des options de configurations afin de mettre certains ports en recopie de tout le trafic (afin justement de pouvoir l'analyser). Il existe certaines techniques pour faire passer un switch en hub (c'est à dire répéter les paquets sur tous les ports) mais comme ceci constitue une forme d'attaque, cela ne sera pas développé ici (de plus, les nouveaux switchs sont de moins en moins vulnérables à ces attaques) ;

• Vous n'avez pas mis votre interface réseau en mode “promiscous”. Le mode “promiscous” est le mode où la carte peut lire tous les paquets du réseau, même ceux qui ne lui sont pas destiné (avec une adresse MAC différente de la sienne par exemple pour une carte Ethernet). Normalement, tcpdump passe automatiquement les interfaces en mode “promiscous”, si ce n'est pas le cas chez vous, c'est probablement qu'il n'a pas réussi, dans ce cas c'est que votre carte réseau ne supporte pas le mode “promiscous”.

Si c'est le cas, comme explicité plus haut, vous êtes surement dans une des deux configurations suivantes:

• Vous n'êtes pas en mode “promiscous”, à moins que vous ayez expressément spécifié à tcpdump de ne pas s'y mettre, c'est sûrement un problème de carte réseau ;

• Vous êtes sur un switch.

Il est fortement probable que vous soyez alors sur un switch que ne vous recopie pas tous les paquets sur votre interface. Vous recevez alors les paquets ARP de l'annonce de nouvelles machines ou autre (en fait, il suffit que l'adresse MAC soit celle de broadcast). Cela doit vous conforter dans l'idée d'être sur un switch si vous ne recevez que ces paquets.

Bon, en fait, je ne sais pas si c'est un problème connu ou non, mais quand il y a un trafic trop important de paquets, il arrive que la machine n'arrive pas à traiter assez rapidement les paquets et finisse par les “dropper” (rejeter). Vous pouvez faire gagner du temps CPU en ne faisant pas traiter les paquets en live et en écrivant dans un fichier, ou vous pouvez vous attaquer au corps du problème. Le problème vient de la taille de la socket de récéption qui en général est trop petite. Voici chez moi, la taille de la socket d'écoute par défaut et la taille maximale :

#sysctl net.core.rmem_default
net.core.rmem_default = 506880

#sysctl net.core.rmem_max
net.core.rmem_max = 506880

C'est parfois un peu trop petit pour un trafic important, pour régler ce problème, il suffit d'augmenter la taille de la socket, on peut faire comme il suit:

# sysctl net.core.rmem_max=1013760
net.core.rmem_max = 1013760
# sysctl net.core.rmem_default=1013760
net.core.rmem_default = 1013760

Ici, je me suis contenté de doubler ces valeurs. Vous pouvez bien entendu encore les augmenter. Mais sachez que cette méthode va allouer un buffer de la taille que vous fixerez pour chaque socket d'écoute. Donc sur une machine qui n'est pas dédiée à l'écoute, vous ne pourrez pas trop monter cette valeur (la machine risque d'avoir beaucoup de socket d'ouverte, donc un besoin d'allouer beaucoup de mémoire).

Il existe un patch non officiel pour la libpcap (sur laquelle se base tcpdump) pour pouvoir changer la taille de la socket d'écoute (ce qui reviendrait ici à modifier net.core.rmem_max pour l'augmenter et modifier la socket de la libpcap afin d'augmenter sa taille, mais ne pas augmenter cette taille pour tous les programmes).

Pour interpréter un tcpdump en analysant les drapeaux TCP (flags), il faut comprendre à la fois leur signification individuelle et leur enchaînement logique dans une session TCP. Voici une méthodologie claire et opérationnelle.

Lecture des flags TCP dans tcpdump – résumé

1. Connexion

[S] → tentative de connexion
[S.] → serveur OK
[.] → connexion établie

✔ [S] → [S.] → [.] = connexion normale

2. Données

[P.] → données envoyées
[.] → données reçues (ACK)

✔ Échange fluide = fonctionnement normal

3. Fermeture

[F.] → fermeture propre
[.] → ACK de fermeture

✔ Fermeture propre = fin normale

4. Erreurs / anomalies

[R] / [R.] → connexion refusée ou coupée
[S] répétés → service inaccessible / filtrage
[S.] sans [.] → problème côté client ou retour bloqué
ACK répétés ([.]) → perte de paquets / MTU / congestion

5. Règle d’or

SYN sans réponse → problème réseau ou service absent

RST → refus ou coupure brutale

Handshake OK mais pas de données → problème applicatif

6. Diagnostic express

|  Ce que vous voyez  |  Conclusion probable  |
|  SYN → pas de réponse  |  Filtrage / service down  |
|  SYN → RST  |  Port fermé  |
|  Connexion OK puis RST  |  Timeout / crash applicatif  |
|  ACK en boucle  |  Perte réseau / MTU  |

1. Rappel des principaux drapeaux TCP

Dans tcpdump, les flags sont affichés entre crochets [].

2. Lecture d’une ligne tcpdump typique

Exemple :

IP 10.0.0.5.443 > 10.0.0.10.51432: Flags [S.], seq 123456, ack 654321, win 64240

Interprétation :

S. → SYN + ACK
Le serveur accepte la demande de connexion

seq = numéro de séquence du serveur
ack = confirmation du SYN client
win = taille de la fenêtre TCP

3. Scénarios TCP courants et leur interprétation

3.1 Établissement de connexion normal (3-way handshake)

Client → Serveur : Flags [S]
Serveur → Client : Flags [S.]
Client → Serveur : Flags [.]

Interprétation :

Connexion TCP établie correctement
Aucun problème réseau apparent

3.2 Échange de données normal

Flags [P.]
Flags [.]

P. : données envoyées
. : ACK de réception

Flux sain, application active.

3.3 Fermeture propre d’une connexion

Flags [F.]
Flags [.]
Flags [F.]
Flags [.]

*   Fermeture TCP ordonnée
*   Comportement attendu en fin de session

3.4 Réinitialisation (RST)

Flags [R]
ou
Flags [R.]

Interprétation possible :

• Port fermé
• Service non à l’écoute
• Timeout applicatif
• Pare-feu ou IPS qui coupe la connexion

Très fréquent lors de problèmes applicatifs ou de filtrage.

3.5 SYN sans réponse (connexion impossible)

Flags [S]
Flags [S]
Flags [S]

*   SYN retransmis
*   Pas de SYN-ACK

Causes possibles :

• Liste à puceService indisponible
• Filtrage réseau
• Problème de routage

3.6 SYN-ACK sans ACK final

Flags [S.]
Flags [S.]

* Liste à puceLe serveur répond
* Liste à puceLe client ne confirme pas

Causes :

• Liste à puceProblème côté client
• Liste à puceFiltrage retour
• Liste à puceMTU / asymétrie réseau

4. Analyse des problèmes fréquents via les flags

4.1 Boucle de retransmission ACK

Flags [.]
Flags [.]
Flags [.]

ACK répétés

• Liste à puceIndique souvent une perte de paquets
• Liste à pucePossiblement congestion ou MTU incorrect

4.2 Retransmissions SYN + RST

Flags [S]
Flags [R.]

• Liste à puceConnexion refusée immédiatement
• Liste à pucePort fermé ou refus explicite

4.3 FIN suivi d’un RST

Flags [F.]
Flags [R.]

• Liste à puceFermeture anormale
• Liste à puceSouvent applicatif (crash, timeout)

5. Indices complémentaires à regarder avec les flags

Les flags seuls ne suffisent pas toujours. À corréler avec :

• Liste à puceNuméros de séquence (seq, ack)
• Liste à puceFenêtre TCP (win)
• Liste à puceOptions TCP (MSS, SACK, WS)
• Liste à puceRetransmissions (tcpdump -vv)
• Liste à puceTemps entre paquets

6. Commandes tcpdump utiles pour l’analyse des flags

Afficher uniquement les flags :

tcpdump -nn -tt -i eth0 'tcp'

Voir le détail TCP :

tcpdump -nn -vvv -i eth0 tcp

Filtrer les RST :

tcpdump -nn 'tcp[tcpflags] & tcp-rst != 0'

Filtrer les SYN :

tcpdump -nn 'tcp[tcpflags] & tcp-syn != 0'

7. Méthode d’analyse recommandée

Identifier le handshake
Vérifier la continuité des ACK
Repérer les RST / retransmissions
Vérifier la fermeture
Corréler avec le contexte applicatif

Cette page fournit une méthode synthétique et opérationnelle pour interpréter les résultats d’un `tcpdump` en se basant sur les drapeaux TCP (flags), dans un objectif de diagnostic réseau rapide.

—

—

Client  → Serveur : [S]
Serveur → Client  : [S.]
Client  → Serveur : [.]

Interprétation :

Connexion TCP établie correctement Aucun problème réseau apparent

—

[P.]
[.]

[P.] : données envoyées

[.] : accusé de réception

Interprétation :

flux normal, application fonctionnelle.

—

[F.]
[.]
[F.]
[.]

Interprétation :

Fermeture TCP propre et ordonnée

Comportement attendu en fin de session

—

[R]
[R.]

Causes possibles :

* Port fermé * Service arrêté * Timeout applicatif * Coupure par pare-feu / IPS

—

[S]
[S]
[S]

Interprétation :

* Service indisponible * Filtrage réseau * Problème de routage

—

[S.]
[S.]

Interprétation :

* Le serveur répond * Le client ne confirme pas * Problème côté client ou trafic retour bloqué

—

[.]
[.]
[.]

Interprétation :

* Perte de paquets * Problème de congestion * MTU incorrect

—

—

Afficher tout le trafic TCP :

tcpdump -nn -tt -i eth0 tcp 

Mode verbeux (analyse fine) :

tcpdump -nn -vvv -i eth0 tcp 

Filtrer les RST :

tcpdump -nn 'tcp[tcpflags] & tcp-rst != 0' 

Filtrer les SYN :

tcpdump -nn 'tcp[tcpflags] & tcp-syn != 0' 

—

• SYN sans réponse → problème réseau ou service absent
• RST → refus ou coupure brutale
• Handshake OK mais pas de données → problème applicatif

—

Objectif : identifier rapidement si l’anomalie est réseau, système ou applicative à partir des seuls flags TCP.