diff --git a/articles/2026/Maîtriser TCP par l'Analyse Wireshark Flux, Pertes et Congestion.md b/articles/2026/maitriser_tcp_analyse_wireshark_flux_pertes_congestion_securite.md similarity index 71% rename from articles/2026/Maîtriser TCP par l'Analyse Wireshark Flux, Pertes et Congestion.md rename to articles/2026/maitriser_tcp_analyse_wireshark_flux_pertes_congestion_securite.md index 6c7125c..e4bc2f1 100644 --- a/articles/2026/Maîtriser TCP par l'Analyse Wireshark Flux, Pertes et Congestion.md +++ b/articles/2026/maitriser_tcp_analyse_wireshark_flux_pertes_congestion_securite.md @@ -1,12 +1,14 @@ --- title: "Maîtriser TCP par l'Analyse Wireshark : Flux, Pertes et Congestion" -description: +description: tags: [] date: 2026-03-08 13:35 -lastmod: 2026-03-08 14:01 -type: -category: -status: +lastmod: 2026-03-08 14:33 +type: + - article +category: + - "[[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**| -|---|---|---| -|**SEQ**|Identifie l'envoi|"Voici la page n°10."| -|**ACK**|Confirme la réception|"Bien reçu, donne-moi la page n°11."| -|**ISN**|Sécurise le départ|Choisir un numéro de page au hasard pour commencer le livre.| +| **Concept** | **Rôle principal** | **Analogie** | +| ----------- | --------------------- | ------------------------------------------------ | +| **SEQ** | Identifie l'envoi | "Voici les caractères n'°1000 à 1500" | +| **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 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) + +À 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 :** Cela permet d'étendre virtuellement la fenêtre jusqu'à **1 Go**, crucial pour saturer les liens à haute latence (LFN - Long Fat Networks). +- **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. + +- **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 :** L'émetteur ne retransmet que le "trou" manquant, économisant ainsi une bande passante précieuse. +- **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**| -|---|---|---| -|**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."| -|**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 ?"| +| **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 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." | +| **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 ? \ No newline at end of file diff --git a/static/Pasted image 20260308142720.png b/static/Pasted image 20260308142720.png new file mode 100644 index 0000000..21508f8 Binary files /dev/null and b/static/Pasted image 20260308142720.png differ diff --git a/static/Pasted image 20260308142917.png b/static/Pasted image 20260308142917.png new file mode 100644 index 0000000..c101a0c Binary files /dev/null and b/static/Pasted image 20260308142917.png differ diff --git a/static/Pasted image 20260308143044.png b/static/Pasted image 20260308143044.png new file mode 100644 index 0000000..c101a0c Binary files /dev/null and b/static/Pasted image 20260308143044.png differ