vault backup: 2026-03-08 14:35:16

articles/2026/maitriser_tcp_analyse_wireshark_flux_pertes_congestion_securite.md

@@ -3,10 +3,12 @@ title: "Maîtriser TCP par l'Analyse Wireshark : Flux, Pertes et Congestion"
 description:
 tags: []
 date: 2026-03-08 13:35
-lastmod: 2026-03-08 14:01
+lastmod: 2026-03-08 14:33
 type:
+  - article
 category:
-status: 
+  - "[[Guide]]"
+status: terminé
 ---
 
 # Maîtriser TCP par l'Analyse Wireshark : Flux, Pertes et Congestion
@@ -41,6 +43,8 @@ Le champ **ACK** est une confirmation, mais surtout une **requête pour la suite
 - **Exemple :** Si le récepteur renvoie un `ACK 1501`, il signifie explicitement : _"J'ai bien reçu tout ce qui précède l'octet 1501. Envoie-moi maintenant la suite à partir de 1501."_
     
 
+Les flags `SYN` et `FIN` consomment virtuellement **1 unité de numéro de séquence**, même s'ils ne transportent pas de données réelles
+
 ---
 
 ### 2. L'Initialisation : L'ISN (Initial Sequence Number)
@@ -79,11 +83,11 @@ Lorsque vous capturez du trafic avec Wireshark, vous remarquerez que les numéro
 
 ### 4. Résumé du mécanisme
 
-|**Concept**|**Rôle principal**|**Analogie**|
+| **Concept** | **Rôle principal**    | **Analogie**                                     |
-|---|---|---|
+| ----------- | --------------------- | ------------------------------------------------ |
-|**SEQ**|Identifie l'envoi|"Voici la page n°10."|
+| **SEQ**     | Identifie l'envoi     | "Voici les caractères n'°1000 à 1500"            |
-|**ACK**|Confirme la réception|"Bien reçu, donne-moi la page n°11."|
+| **ACK**     | Confirme la réception | "Bien reçu, donne-moi la suite à partir de 1501" |
-|**ISN**|Sécurise le départ|Choisir un numéro de page au hasard pour commencer le livre.|
+| **ISN**     | Sécurise le départ    | Choisir un numéro au hasard pour commencer.      |
 
 ---
 
@@ -123,22 +127,27 @@ Le MSS définit la quantité maximale de données utiles (le "payload") qu'un h
 - **Impact :** Si les deux hôtes ont des MSS différents, c'est la valeur la plus **petite** qui est retenue pour éviter la fragmentation IP, coûteuse en ressources.
     
 
-#### **B. Le Window Scale (Échelle de fenêtre)**
 
-À l'origine, le champ "Window Size" dans l'en-tête TCP était codé sur 16 bits, limitant la mémoire tampon à **64 Ko**. Avec l'augmentation des débits (Fibre, 10GbE), cette limite est devenue un goulot d'étranglement.
+---
 
-- **Le multiplicateur :** L'option Window Scale définit un exposant de puissance de 2 (ex: $x7$ signifie $2^7 = 128$).
+### B. Le Window Scale (L'extension de fenêtre)
 
-- **Résultat :** Cela permet d'étendre virtuellement la fenêtre jusqu'à **1 Go**, crucial pour saturer les liens à haute latence (LFN - Long Fat Networks).
+À l'origine, le champ **Window Size** dans l'en-tête TCP était codé sur 16 bits, limitant la fenêtre de réception à un maximum de **64 Ko** ($2^{16}$). Sur les réseaux modernes à très haut débit (Fibre, 10GbE), cette limite s'est transformée en goulot d'étranglement : l'émetteur passait plus de temps à attendre des acquittements qu'à envoyer des données.
+
+- **Le mécanisme du Bit Shift :** Pour dépasser cette limite sans modifier la structure de l'en-tête, on utilise l'option **Window Scale**. Elle définit un "facteur de décalage" (Shift Count). Par exemple, si le facteur est de **7**, chaque valeur de fenêtre annoncée est décalée de 7 bits vers la gauche, ce qui revient à multiplier la valeur par **128** ($2^7$).
+    
+- **Résultat :** Ce multiplicateur permet d'étendre virtuellement la fenêtre jusqu'à **1 Go**, une capacité indispensable pour saturer les liens à haut débit et forte latence, appelés **LFN** (_Long Fat Networks_).
     
 
-#### **C. Le SACK (Selective Acknowledgment)**
+---
 
-Dans le TCP standard, si le segment n°3 est perdu mais que les n°4 et n°5 arrivent, le récepteur ne peut dire que _"J'attends le n°3"_. L'émetteur doit alors souvent tout renvoyer à partir du n°3.
+### C. Le SACK (Selective Acknowledgment)
 
-- **L'optimisation :** Le **SACK** permet au récepteur de dire : _"Il me manque le n°3, MAIS j'ai bien reçu les blocs n°4 et n°5"_.
+Dans le fonctionnement TCP standard (dit "Cumulative ACK"), si le segment n°3 est perdu mais que les n°4 et n°5 arrivent, le récepteur est incapable de signaler qu'il possède déjà la suite. Il ne peut que répéter : _"J'attends toujours le n°3"_. Par prudence, l'émetteur finit souvent par retransmettre inutilement tout le flux à partir du n°3.
 
-- **Gain :** L'émetteur ne retransmet que le "trou" manquant, économisant ainsi une bande passante précieuse.
+- **L'optimisation SACK :** Négocié via l'option _SACK Permitted_ lors du handshake, ce mécanisme permet au récepteur d'envoyer des informations précises sur les blocs de données déjà stockés en mémoire. Il dit explicitement : _"Il me manque l'octet n°3, MAIS j'ai déjà bien reçu et mis de côté les blocs allant du n°4 au n°6"_.
+    
+- **Gain de performance :** L'émetteur identifie immédiatement les "trous" dans le flux. Il ne retransmet que les segments manquants, préservant ainsi la bande passante et évitant de congestionner inutilement le réseau.
     
 
 ---
@@ -333,19 +342,19 @@ Une connexion ne peut pas rester indéfiniment à l'arrêt. TCP utilise deux mé
 
 - **Window Update :** Dès que l'application a libéré de l'espace dans le buffer, le récepteur envoie spontanément un segment (souvent sans données) avec une nouvelle valeur de fenêtre positive. C'est le signal de reprise : _"C'est bon, j'ai à nouveau 16 Ko de place !"_
     
-- **TCP Keep-Alive (et Zero Window Probe) :** Si le message "Window Update" est perdu en chemin, la connexion resterait bloquée à jamais. Pour éviter cela, l'émetteur envoie régulièrement de petits segments de test (Keep-Alive) pour forcer le récepteur à répondre et à renvoyer son état de fenêtre actuel.
+- **TCP Keep-Alive (et Zero Window Probe) :** Si le message "Window Update" est perdu en chemin, la connexion resterait bloquée à jamais. Pour éviter cela, l'émetteur envoie régulièrement de petits segments de test (Keep-Alive) pour forcer le récepteur à répondre et à renvoyer son état de fenêtre actuel. Il est utile de préciser que c'est l'**émetteur** qui prend l'initiative du "Probe" (sonde) pour éviter un interblocage (_deadlock_) si le paquet "Window Update" du récepteur est perdu. Sans cela, les deux resteraient à attendre indéfiniment.
     
 
 ---
 
 ### 3. Synthèse des états de saturation
 
-|**Message Wireshark**|**Qui parle ?**|**Signification**|
+| **Message Wireshark** | **Qui parle ?** | **Signification**                                        |
-|---|---|---|
+| --------------------- | --------------- | -------------------------------------------------------- |
-|**TCP Window Full**|L'Émetteur|"J'ai atteint la limite que tu m'as fixée, je m'arrête."|
+| **TCP Window Full**   | L'Émetteur      | "J'ai atteint la limite que tu m'as fixée, je m'arrête." |
-|**TCP Zero Window**|Le Récepteur|"Je suis saturé, ne m'envoie plus rien."|
+| **TCP Zero Window**   | Le Récepteur    | "Je suis saturé, ne m'envoie plus rien."                 |
-|**Window Update**|Le Récepteur|"J'ai vidé mon buffer, tu peux reprendre l'envoi."|
+| **Window Update**     | Le Récepteur    | "J'ai vidé mon buffer, tu peux reprendre l'envoi."       |
-|**TCP Keep-Alive**|L'Émetteur|"Es-tu toujours là ? Ta fenêtre est-elle toujours à 0 ?"|
+| **TCP Keep-Alive**    | L'Émetteur      | "Es-tu toujours là ? Ta fenêtre est-elle toujours à 0 ?" |
 
 ---
 
@@ -467,6 +476,154 @@ Lorsqu'on vous donne une suite de paquets à analyser, regardez toujours le **pr
 
 ---
 
+## Étude de cas : datagramme IPv4
+
+![](Pasted%20image%2020260308142720.png)
+
+Cette image est une représentation classique de l'**en-tête d'un datagramme IPv4**. C'est un document fondamental pour comprendre comment les données circulent sur Internet.
+
+### 1. Structure Générale
+
+L'image montre comment un paquet IP est organisé au niveau binaire.
+
+- **Les Lignes (Words) :** Chaque ligne numérotée de 1 à 6 représente un "mot" de **32 bits** (soit 4 octets).
+    
+- **La Largeur (Bits) :** L'échelle en haut indique la position des bits, de 0 à 31.
+    
+- **Le Header (En-tête) :** Les 5 premières lignes sont obligatoires (20 octets). La 6ème ligne (Options) est facultative.
+    
+- **Data :** Tout ce qui se trouve après l'en-tête est la charge utile (le message réel, souvent un segment TCP ou UDP).
+    
+
+---
+
+## 2. Analyse ligne par ligne
+
+#### Ligne 1 : Contrôle de base
+
+- **Version (4 bits) :** Indique la version du protocole (ici, `4` pour IPv4).
+    
+- **IHL (4 bits) :** _Internet Header Length_. Indique la longueur de l'en-tête. C’est crucial car la zone "Options" peut varier en taille.
+    
+- **Type of Service (8 bits) :** Utilisé pour la qualité de service (QoS), par exemple pour prioriser la voix sur IP (VoIP) par rapport à un email.
+    
+- **Total Length (16 bits) :** La taille totale du paquet (en-tête + données).
+    
+
+#### Ligne 2 : Fragmentation
+
+_C'est ici que l'IP gère les paquets trop gros pour certains réseaux._
+
+- **Identification (16 bits) :** Un numéro unique pour identifier tous les fragments d'un même paquet initial.
+    
+- **Flags (3 bits) :** Permettent de dire "ne pas fragmenter" ou "il y a d'autres fragments après celui-ci".
+    
+- **Fragmentation Offset (13 bits) :** Indique la position exacte de ce fragment dans le message d'origine.
+    
+
+#### Ligne 3 : Durée de vie et Protocole
+
+- **Time to Live (TTL - 8 bits) :** Un compteur de "sauts" (hops) entre routeurs. À chaque routeur, on retire 1. Si ça tombe à 0, le paquet est détruit. Cela évite que des paquets tournent en boucle indéfiniment.
+    
+- **Protocol (8 bits) :** Indique quel protocole de couche supérieure se trouve dans les données (ex: 6 pour TCP, 17 pour UDP, 1 pour ICMP).
+    
+- **Header Checksum (16 bits) :** Un code de vérification pour s'assurer que l'en-tête n'a pas été corrompu pendant le transport.
+    
+
+### Lignes 4 & 5 : L'adressage
+
+- **Source Address (32 bits) :** L'adresse IP de l'expéditeur.
+    
+- **Destination Address (32 bits) :** L'adresse IP du destinataire.
+    
+
+### Ligne 6 : Options et Bourrage
+
+- **Options :** Utilisé très rarement pour des tests ou de la sécurité.
+    
+- **Padding (Padding) :** Comme l'en-tête doit toujours se terminer sur un multiple de 32 bits, on ajoute des zéros si les options sont trop courtes.
+    
+
+---
+
+## 3. Pourquoi est-ce important en Cybersécurité ?
+
+Comprendre ce schéma vous permet de :
+
+1. **Analyser les logs :** Comprendre ce que vous voyez dans un outil comme **Wireshark**.
+    
+2. **Détecter des anomalies :** Un TTL anormalement bas peut indiquer une tentative de cartographie réseau (Traceroute).
+    
+3. **Comprendre l'IP Spoofing :** L'usurpation d'adresse consiste à modifier manuellement le champ _Source Address_.
+    
+
+> **Note aux débutants :** Retenez bien que l'IP ne garantit pas que le message arrive (c'est le rôle de TCP). L'IP s'occupe uniquement de l'adressage et de l'acheminement "au mieux" (_Best Effort_).
+
+## Étude de cas : datagramme TCP
+
+![](Pasted%20image%2020260308143044.png)
+
+On monte d'un étage dans le modèle OSI : après la couche Réseau (IP), voici l'en-tête du segment **TCP (Transmission Control Protocol)**, situé au niveau de la couche **Transport**.
+
+Si l'IP est l'enveloppe avec l'adresse de la maison, le TCP est la lettre recommandée avec accusé de réception qui s'assure que le contenu arrive intact et dans le bon ordre.
+
+---
+
+### 1. Les Ports : L'aiguillage des applications
+
+Contrairement à l'IP qui identifie une machine, le TCP utilise des **ports** pour identifier une application spécifique sur cette machine.
+
+- **Source Port (16 bits) :** Le port utilisé par l'application qui envoie les données (souvent un port aléatoire au-dessus de 1024).
+    
+- **Destination Port (16 bits) :** Le port de l'application réceptrice (ex: 80 pour HTTP, 443 pour HTTPS, 22 pour SSH).
+    
+
+### 2. La Fiabilité : Séquençage et Accusés
+
+C'est ici que réside la "magie" du TCP.
+
+- **Sequence Number (32 bits) :** Chaque octet envoyé reçoit un numéro. Cela permet au destinataire de reconstruire le message dans l'ordre, même si les paquets arrivent dans le désordre.
+    
+- **Acknowledgement Number (32 bits) :** C'est l'accusé de réception. Le récepteur dit : "J'ai bien reçu jusqu'à l'octet X, j'attends maintenant le X+1".
+    
+
+### 3. Gestion et Flux
+
+- **Header Length (4 bits) :** Comme pour l'IP, indique où s'arrête l'en-tête et où commencent les données.
+    
+- **Code Bits / Flags (6 bits) :** Ce sont les "interrupteurs" du TCP. Les plus connus en cyber sont :
+    
+    - **SYN :** Pour établir la connexion.
+        
+    - **ACK :** Pour accuser réception.
+        
+    - **FIN :** Pour terminer proprement la connexion.
+        
+    - **RST :** Pour réinitialiser brutalement une connexion (souvent vu lors d'un scan de port).
+        
+- **Window (16 bits) :** C'est le contrôle de flux. Le récepteur dit : "Ne m'envoie pas plus de X octets à la fois car ma mémoire tampon est pleine".
+    
+
+### 4. Intégrité et Urgence
+
+- **Checksum (16 bits) :** Vérifie que l'en-tête **et** les données n'ont pas été modifiés.
+    
+- **Urgent Pointer (16 bits) :** Très peu utilisé aujourd'hui, il servait à indiquer que certaines données dans le segment devaient être traitées prioritairement.
+    
+
+---
+
+### Le point de vue Cybersécurité 🛡️
+
+Le TCP est au cœur de nombreuses analyses :
+
+- **TCP Connect Scan :** Un attaquant tente d'ouvrir une connexion complète (SYN -> SYN/ACK -> ACK) pour voir si un port est ouvert.
+    
+- **SYN Flood :** Une attaque DoS (Déni de Service) consistant à envoyer des milliers de segments SYN sans jamais répondre au SYN/ACK, saturant ainsi les ressources du serveur.
+    
+- **Détournement de session (Hijacking) :** Si un attaquant arrive à deviner le prochain **Sequence Number**, il peut injecter des données malveillantes dans une connexion existante.
+    
+
 ## Étude de cas : Anomalie et Sécurité (Le Scan "Christmas Tree")
 
 Sur cette capture, nous observons un comportement qui contredit tout ce que nous avons vu sur le cycle de vie normal de TCP.
@@ -493,7 +650,7 @@ Observez les lignes sur fond rouge (paquets 1, 3, 5, etc.) :
 
 - **Source : 10.0.0.2** (Le serveur) répond systématiquement par un flag **[RST]**.
     
-- **Interprétation :** Le serveur reçoit un paquet totalement incohérent. Sa pile TCP ne sait pas comment traiter une demande qui veut à la fois "commencer", "pousser des données" et "finir". Fidèle à sa logique de protection, il coupe court à la discussion en envoyant un **Reset brutale**.
+- **Interprétation :** Le serveur reçoit un paquet totalement incohérent. Sa pile TCP ne sait pas comment traiter une demande qui veut à la fois "commencer", "pousser des données" et "finir". La plupart des piles TCP répondent `RST` à un paquet invalide non pas par "sécurité", mais par **conformité à la norme**. La RFC 793 stipule qu'un segment arrivant sur une connexion inexistante ou fermée doit générer un `RST`. C'est précisément cette "obéissance" à la norme que l'attaquant exploite pour le fingerprinting.
     
 
 ### 3. Diagnostic de Cybersécurité
@@ -504,6 +661,8 @@ Ce que vous voyez ici n'est pas un transfert de données, mais une tentative de
     
 - Selon que le serveur répond par un `RST` ou qu'il ignore le paquet (Drop), l'attaquant peut deviner s'il s'agit d'un système Windows, Linux ou d'un pare-feu spécifique.
     
+Notez que dans un vrai scan de type "Xmas", ce sont généralement les flags `FIN`, `URG` et `PSH` qui sont utilisés (les "lumières" de l'arbre). Le flag `SYN` est souvent **exclu** du scan Xmas classique, car un paquet avec `SYN` est traité différemment par les pare-feu. Si `SYN` est présent avec `FIN`, c'est une variante encore plus agressive.
+
 ### 4. Actions Techniques (La Réponse)
 
 #### **A. Au niveau du Pare-feu (Firewall/IPS)**
@@ -528,9 +687,7 @@ Pour que Fail2Ban réagisse, il faut d'abord que votre pare-feu (ici `iptables`)
 
 Avant Fail2Ban, on demande au pare-feu de marquer les scans "Christmas Tree" :
 
-Bash
+```toml
-
-```
 # Log les paquets avec des combinaisons de flags invalides
 iptables -A INPUT -p tcp --tcp-flags ALL FIN,SYN,PSH,ACK,URG -j LOG --log-prefix "TCP-XMAS-SCAN: "
 ```
@@ -539,8 +696,6 @@ iptables -A INPUT -p tcp --tcp-flags ALL FIN,SYN,PSH,ACK,URG -j LOG --log-prefix
 
 Ce fichier définit ce que Fail2Ban doit chercher dans les logs. On utilise une expression régulière (regex) pour repérer le préfixe que nous avons créé.
 
-Ini, TOML
-
 ```toml
 [Definition]
 # On cherche l'IP source (SRC=...) associée à notre préfixe de log
@@ -590,16 +745,3 @@ action    = iptables-multiport[name=TCP-XMAS, port="all", protocol=tcp]
 
 ---
 
-### Résumé pour l'étudiant
-
-| **Élément**              | **Observation sur l'image** | **Conclusion**                                                                   |
-| ------------------------ | --------------------------- | -------------------------------------------------------------------------------- |
-| **Combinaison de Flags** | `FIN, SYN, PSH, ACK, URG`   | **Anomalie majeure.** Violation du protocole TCP standard.                       |
-| **Réponse du Serveur**   | `[RST]`                     | **Fermeture brutale.** Le serveur rejette un paquet non conforme ou malveillant. |
-| **Verdict**              | Scan de ports agressif      | Ce n'est pas une connexion légitime, c'est une sonde de sécurité.                |
-
----
-
-**Ce cas pratique montre bien que TCP est un protocole d'état : si les étapes (SYN -> ACK -> DATA -> FIN) ne sont pas respectées, le protocole s'autodéfend par un RST.**
-
-Souhaitez-vous que je rédige une fiche de révision finale regroupant les 5 chapitres et cette étude de cas pour vos étudiants ?