---
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:35
type:
  - article
category:
  - "[[Guide]]"
status: terminé
---

# Maîtriser TCP par l'Analyse Wireshark : Flux, Pertes et Congestion

Le protocole **TCP (Transmission Control Protocol)** est le pilier de la fiabilité sur Internet (Web, SSH, Bases de données). Contrairement aux idées reçues, TCP ne compte pas des paquets, mais des **octets**. Comprendre cette nuance est la clé pour interpréter les comportements complexes : retransmissions, fenêtres de réception et fermetures de connexion.

## La Fiabilité de TCP — Séquençage et Acquittement

Le protocole **TCP (Transmission Control Protocol)** est souvent comparé à une conversation téléphonique polie : on ne se contente pas de parler, on s'assure que l'autre a bien entendu et compris chaque segment avant de poursuivre. Contrairement à UDP, TCP garantit que les données arrivent dans l'ordre et sans erreurs.

---

### 1. Les Fondations : SEQ et ACK

TCP ne voit pas les données comme des fichiers distincts, mais comme un **flux continu d'octets**. Pour s'y retrouver dans ce flux, il utilise deux compteurs essentiels logés dans l'en-tête du segment :

#### **A. Le Numéro de Séquence (SEQ)**

Le champ **SEQ** indique la position du premier octet de données du segment actuel dans le flux global.

- **Logique :** Si vous envoyez un segment contenant 500 octets et que votre SEQ actuel est $1000$, le segment couvre les octets $1000$ à $1499$.
    
- **Calcul du prochain SEQ :** $SEQ_{suivant} = SEQ_{actuel} + \text{Taille des données}$. Dans notre exemple, le prochain envoi commencera au SEQ $1500$.
    

#### **B. Le Numéro d'Acquittement (ACK)**

Le champ **ACK** est une confirmation, mais surtout une **requête pour la suite**.

- **Logique :** Il indique le numéro du _prochain_ octet attendu par le récepteur.
    
- **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)

Pourquoi ne pas commencer systématiquement à zéro ? Pour des raisons de sécurité et de robustesse, TCP utilise l'**ISN**.

- **Définition :** Lors de la phase de connexion (_Three-Way Handshake_), chaque hôte choisit un numéro de départ **aléatoire** sur 32 bits.
    
- **Pourquoi l'aléatoire ?**
    
    1. **Éviter les collisions :** Si une ancienne connexion sur le même port traîne encore sur le réseau (paquets retardés), un numéro aléatoire évite que ces vieux paquets ne soient acceptés par erreur dans la nouvelle session.
        
    2. **Sécurité :** Si les numéros étaient prévisibles, un attaquant pourrait injecter de faux paquets dans une session en devinant le prochain SEQ.
        

---

### 3. Application Pratique : L'Analyse Wireshark

Lorsque vous capturez du trafic avec Wireshark, vous remarquerez que les numéros commencent souvent à $0$. Ce sont des **numéros relatifs**, simplifiés par le logiciel pour faciliter la lecture humaine.

> **Manipulation Étudiante : Voir la réalité du réseau**
> 
> Pour observer les véritables numéros de 32 bits (les ISN réels) :
> 
> 1. Faites un clic droit sur un paquet TCP.
>     
> 2. Allez dans **Protocol Preferences** > **Transmission Control Protocol**.
>     
> 3. Décochez **"Relative sequence numbers"**.
>     
>     _Observez alors les chiffres massifs (ex: 3824910542) qui circulent réellement sur vos câbles._
>     

---

### 4. Résumé du mécanisme

| **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.      |

---

## 2. L'Établissement de la Connexion et la Négociation des Paramètres

Dans l'architecture TCP/IP, une application ne peut pas simplement "jeter" des données sur le réseau. Avant tout échange, les deux hôtes doivent s'accorder sur un état commun. C'est le rôle du **Three-Way Handshake** (la poignée de main en trois temps), une procédure de synchronisation qui transforme un canal physique non fiable en une liaison logique robuste.

---

### 1. Le "Three-Way Handshake" (3WHS)

L'établissement d'une session TCP suit un rituel immuable en trois étapes, permettant d'échanger les numéros de séquence initiaux (**ISN**) et de confirmer la disponibilité des ressources.

1. **SYN (Synchronize) :** Le client envoie un segment avec le flag `SYN` activé. Il y insère son **ISN** (Initial Sequence Number) généré aléatoirement. C'est une déclaration d'intention : _"Je souhaite ouvrir une connexion et voici mon point de départ numérique."_
    
2. **SYN-ACK (Synchronize-Acknowledgment) :** Le serveur répond avec les deux flags activés.
    
    - Il choisit son propre **ISN**.
        
    - Il acquitte celui du client en envoyant un **ACK** égal à $ISN_{client} + 1$. Cela signifie : _"J'ai reçu ton SYN, j'attends l'octet suivant."_
        
3. **ACK (Acknowledgment) :** Le client finalise la boucle en acquittant l'ISN du serveur ($ACK = ISN_{serveur} + 1$). La connexion est alors déclarée **ESTABLISHED**.
    

---

### 2. Négociation des Paramètres Critiques

Le handshake n'est pas qu'une simple politesse ; c'est une phase de **négociation contractuelle**. Les hôtes y annoncent leurs limites techniques pour optimiser le transfert.

#### **A. Le MSS (Maximum Segment Size)**

Le MSS définit la quantité maximale de données utiles (le "payload") qu'un hôte peut accepter dans un seul segment TCP.

- **Calcul :** Sur un réseau Ethernet standard, le MTU (Maximum Transmission Unit) est de 1500 octets. Si l'on retire l'en-tête IP (20 octets) et l'en-tête TCP (20 octets), il reste un **MSS de 1460 octets**.
    
- **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 (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 :** 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 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 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.
    

---

### Résumé

|**Paramètre**|**Phase de négociation**|**Utilité majeure**|
|---|---|---|
|**SYN / ACK**|Handshake|Synchronisation des ISN et état de la session.|
|**MSS**|Handshake|Éviter la fragmentation en s'adaptant à la MTU.|
|**Window Scale**|Handshake|Permettre des transferts haute performance (> 64 Ko).|
|**SACK**|Handshake|Retransmission intelligente des segments perdus.|

---

Pour bien comprendre, rien ne vaut l'observation des "entrailles" d'un paquet. Nous allons simuler une analyse de trame comme si vous étiez devant votre écran, en nous concentrant sur le premier paquet d'une connexion (le **SYN**).

### Travaux Dirigés : Analyse d'un segment SYN sous Wireshark

Lorsqu'un client (PC) contacte un serveur (Web), le premier paquet envoyé contient toutes les "négociations" que nous avons vues. Voici comment les interpréter dans les couches protocolaires.

---

#### 1. L'anatomie du premier échange (Le SYN)

Dans l'en-tête TCP de ce premier paquet, vous trouverez les champs suivants :

- **Flags : 0x002 (SYN)** : Seul le bit de synchronisation est levé.
    
- **Sequence Number : 0** (Relatif) ou un nombre aléatoire comme `3824910542` (Réel).
    
- **Window Size : 64240** : La mémoire tampon initiale proposée par le client.
    

---

#### 2. Le bloc "Options" : Le cœur de la négociation

C'est ici que se joue la performance de la future connexion. Dans Wireshark, déployez l'arborescence **"Options"** sous l'en-tête TCP :

##### **A. Maximum Segment Size (MSS)**

- **Valeur type :** `1460 bytes`.
    
- **Interprétation :** Le client informe le serveur : _"Mes trames Ethernet font 1500 octets, donc ne m'envoie pas de segments de données brutes dépassant 1460 octets."_
    

##### **B. Window Scale (WS)**

- **Valeur type :** `Shift count 7 (multiplier 128)`.
    
- **Interprétation :** Sans cette option, le débit serait bridé à cause de la latence. Ici, la fenêtre réelle sera calculée en multipliant la `Window Size` annoncée par 128. C'est l'accélérateur pour la fibre optique.
    

##### **C. SACK Permitted**

- **Valeur :** `True`.
    
- **Interprétation :** Le client dit au serveur : _"Je supporte les acquittements sélectifs. Si tu perds un paquet au milieu de l'envoi, je te dirai exactement lequel, ne renvoie pas tout !"_
    

---

#### 3. Le "Three-Way Handshake" complet en chiffres

Imaginons un client (C) et un serveur (S) :

1. **C → S [SYN]** : `SEQ = 1000`, `Options: MSS=1460, SACK=OK, WS=128`
    
2. **S → C [SYN, ACK]** : `SEQ = 5000`, `ACK = 1001`, `Options: MSS=1400, SACK=OK, WS=64`
    
    > _Note : Le serveur a un MSS plus petit (1400). Les deux utiliseront 1400 pour toute la session._
    
3. **C → S [ACK]** : `SEQ = 1001`, `ACK = 5001`.
    

---

#### Synthèse : Pourquoi est-ce crucial pour un administrateur ?

Si vous diagnostiquez une lenteur réseau ("Le réseau est lent"), vérifiez toujours ces options :

- Un **MSS mal négocié** provoque de la fragmentation et fait chuter les performances.
    
- Un **Window Scale absent** (multiplicateur à 1) empêche d'utiliser la pleine bande passante sur des liens longue distance.
    

---

## 3. La Gestion des Pertes — Résilience et Réactivité de TCP

Dans un monde idéal, chaque paquet arrive à destination. Dans la réalité des réseaux (WiFi instable, encombrement des routeurs, câbles défectueux), des segments se perdent. TCP ne panique pas : il dispose de deux stratégies complémentaires pour boucher les "trous" dans le flux de données.

---

### 1. La Retransmission sur Timeout (RTO) : La roue de secours

Le **RTO (Retransmission Time-Out)** est le mécanisme de base, fondé sur la patience. Lorsqu'un émetteur envoie un segment, il déclenche un chronomètre. S'il n'a reçu aucun acquittement (`ACK`) à l'expiration de ce délai, il considère le segment comme perdu et le renvoie.

#### **Le concept du Backoff Exponentiel**

Si le réseau est saturé, renvoyer frénétiquement des paquets ne ferait qu'aggraver la congestion (c'est l'analogie d'un bouchon sur l'autoroute : ajouter des voitures n'aide pas).

- **Logique :** À chaque échec consécutif, TCP **double** le délai d'attente.
    
- **Exemple :** Si le premier timeout est de 1s, le suivant sera de 2s, puis 4s, 8s... jusqu'à abandonner la connexion si le lien est totalement coupé.
    

---

### 2. La Fast Retransmission : La réactivité par les "Duplicate ACKs"

Attendre un timeout est lent et pénalise les performances. TCP utilise donc une astuce basée sur les retours du récepteur : la **Fast Retransmission**.

#### **Le mécanisme des "Acks en double"**

Imaginons que l'émetteur envoie les segments 1, 2, 3, 4 et 5. Le segment **n°2 est perdu**.

1. Le récepteur reçoit le n°1 : il renvoie `ACK 2` (J'attends le 2).
    
2. Le récepteur reçoit le n°3 (au lieu du 2) : il ne peut pas acquitter le 3. Il renvoie donc à nouveau **`ACK 2`**.
    
3. Le récepteur reçoit le n°4 : il renvoie encore **`ACK 2`**.
    

#### **La règle des 3 Duplicate ACKs**

Dès que l'émetteur reçoit **3 acquittements identiques supplémentaires** (soit 4 fois le même ACK au total), il n'attend pas la fin de son chronomètre (RTO). Il comprend immédiatement que le segment n°2 est manquant et le renvoie sur-le-champ. C'est ce qu'on appelle la "Retransmission Rapide".

---

### 3. Comparaison des deux mécanismes

|Caractéristique|Retransmission par Timeout (RTO)|Fast Retransmission|
|---|---|---|
|**Déclencheur**|Absence totale de réponse (Silence)|Réception de 3 Duplicate ACKs|
|**Vitesse**|Lente (attend l'expiration du timer)|Très rapide (réaction immédiate)|
|**Scénario type**|Coupure réseau ou perte massive|Perte isolée d'un segment dans un flux|
|**Impact Débit**|Chute brutale du débit (Backoff)|Impact modéré sur la performance|

Exporter vers Sheets

---

### Analyse Wireshark : Repérer les problèmes

Dans Wireshark, ces événements sont mis en évidence par des couleurs spécifiques (souvent texte noir sur fond rouge ou inversement) :

- **[TCP Retransmission]** : Indique un renvoi après un timeout.
    
- **[TCP Fast Retransmission]** : Indique un renvoi suite à des Duplicate ACKs.
    
- **[TCP Dup ACK]** : Les messages du récepteur signalant qu'il lui manque quelque chose.
    

> **Note d'expert :** Si vous voyez beaucoup de _Fast Retransmissions_, le réseau fonctionne mais "saigne" un peu (quelques pertes). Si vous voyez des _Timeouts_, la connexion est probablement en train de s'effondrer.
    

## 4. Le Contrôle de Flux — La Fenêtre Glissante (Sliding Window)

La vitesse d'un transfert TCP ne dépend pas seulement de la puissance du processeur, mais de la capacité du récepteur à "digérer" les données. Le **Contrôle de Flux** empêche un émetteur rapide de submerger un récepteur lent ou occupé.

---

### 1. Le mécanisme de la Fenêtre de Réception (Win)

Chaque segment TCP contient un champ **Window Size**. C'est une annonce faite par le récepteur : _"Voici l'espace (en octets) qu'il me reste dans mon buffer de réception"_.

L'émetteur a le droit d'envoyer des données tant que la somme des octets non acquittés est inférieure à cette valeur. C'est ce qu'on appelle la **Fenêtre Glissante**.

#### **A. TCP Window Full (Côté Émetteur)**

C'est une alerte Wireshark qui indique que l'émetteur a épuisé le quota autorisé par le récepteur.

- **Conséquence :** L'émetteur s'arrête net et attend un acquittement avant de renvoyer quoi que ce soit.
    
- **Diagnostic :** C'est souvent le signe que le réseau est très rapide, mais que le récepteur (ou l'application) ne suit pas la cadence.
    

#### **B. TCP Zero Window (Côté Récepteur)**

Le récepteur envoie un segment avec une **Window Size = 0**.

- **Signification :** _"Stop ! Mon buffer est totalement plein. Ne m'envoie plus un seul octet."_ * **Cause :** L'application (ex: un serveur de base de données ou un navigateur) est figée ou traite les données moins vite que le système d'exploitation ne les reçoit.
    

---

### 2. Le déblocage : Window Update et Keep-Alive

Une connexion ne peut pas rester indéfiniment à l'arrêt. TCP utilise deux mécanismes pour relancer la machine :

- **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. 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 ?" |

---

### Analyse de performance : Le "BDP" (Bandwidth-Delay Product)

Pour un administrateur, la taille de la fenêtre est vitale. Si votre fenêtre est trop petite par rapport à la latence (ping) du réseau, vous ne pourrez jamais atteindre le débit maximal de votre fibre, même si le lien est vide. C'est ici que l'option **Window Scale** (vue au chapitre précédent) devient indispensable pour "gonfler" artificiellement la fenêtre au-delà de 64 Ko.

## 5. La Terminaison de Connexion — Dire au revoir (ou raccrocher au nez)

Une fois les données transférées, TCP doit libérer les ressources (mémoire, ports, sockets) utilisées par la session. Contrairement à l'ouverture qui se fait en 3 étapes, la fermeture "propre" nécessite généralement **4 étapes**, car TCP est un protocole **Full-Duplex** : chaque sens de communication doit être fermé indépendamment.

---

### 1. La Fermeture Propre : Le "Four-Way Handshake" (FIN)

Lorsque l'une des applications (souvent le client) a fini d'envoyer ses données, elle initie une procédure de fermeture élégante en utilisant le flag **FIN** (_Finish_).

1. **FIN (Client → Serveur) :** "J'ai fini d'envoyer mes données, je souhaite fermer mon sens de communication."
    
2. **ACK (Serveur → Client) :** "Bien reçu, je prends note que tu ne m'enverras plus rien."
    
    > _À ce stade, la connexion est dans un état "Semi-fermé". Le serveur peut encore envoyer des données s'il en a en attente._
    
3. **FIN (Serveur → Client) :** "De mon côté aussi, j'ai terminé."
    
4. **ACK (Client → Serveur) :** "Parfait, nous sommes d'accord. Adieu."
    

---

### 2. La Fermeture Brutale : Le Reset (RST)

Parfois, la politesse n'est plus de mise. Le flag **RST** (_Reset_) est utilisé pour interrompre immédiatement une connexion sans attendre d'acquittement. C'est l'équivalent de raccrocher le téléphone brusquement.

#### **Les causes d'un paquet RST :**

- **Port fermé :** Vous tentez de vous connecter à un port (ex: 8080) où aucun service n'écoute. Le serveur répond par un `RST`.
    
- **Crash applicatif :** L'application qui gérait la connexion a planté. Le système d'exploitation envoie un `RST` pour nettoyer la session devenue orpheline.
    
- **Action d'un Pare-feu (Firewall) :** Un équipement de sécurité décide de couper une connexion jugée suspecte ou interdite.
    
- **Incohérence de séquence :** TCP reçoit un paquet qui ne correspond à aucune session active ou dont le numéro de séquence est totalement aberrant.
    

---

### 3. Comparaison : FIN vs RST

|Caractéristique|FIN (Fermeture Propre)|RST (Fermeture Brutale)|
|---|---|---|
|**Analogie**|"Au revoir, à la prochaine."|"Erreur fatale, on coupe tout !"|
|**Données en transit**|Sont transmises et acquittées avant l'arrêt.|Sont perdues immédiatement.|
|**État Wireshark**|Suite logique de `FIN`, `ACK`, `FIN`, `ACK`.|Un seul paquet rouge marqué `[RST]`.|
|**Utilisation**|Fin normale d'un transfert HTTP, FTP, etc.|Rejet de connexion, timeout sévère, sécurité.|

Exporter vers Sheets

---

### 4. L'état critique : TIME_WAIT

Après avoir envoyé le dernier `ACK`, l'initiateur de la fermeture ne libère pas son port immédiatement. Il entre dans l'état **TIME_WAIT**.

- **Pourquoi ?** Pour s'assurer que le dernier `ACK` est bien arrivé au destinataire et pour éviter qu'un paquet "égaré" d'une ancienne session ne vienne perturber une nouvelle connexion qui réutiliserait le même port.

---

## Synthèse : Le Code de Communication TCP (Les Flags)

Les flags sont des bits de 1 (activé) ou 0 (désactivé) situés dans l'en-tête TCP. Ils dictent la nature du segment envoyé.

### 1. Les "Bâtisseurs" (Ouverture)

- **SYN (Synchronize) :** Utilisé uniquement lors de l'établissement de la connexion. Il indique l'intention de synchroniser les numéros de séquence (**ISN**).
    
- **ACK (Acknowledgment) :** Le flag le plus courant. Une fois la connexion établie, presque tous les paquets l'ont activé pour confirmer la réception des données précédentes.
    

### 2. Les "Transporteurs" (Transfert)

- **PSH (Push) :** Demande à la pile TCP du récepteur de transmettre immédiatement les données à l'application sans attendre que le buffer de réception soit plein. Très utilisé en SSH ou Telnet pour l'interactivité.
    
- **URG (Urgent) :** Indique que certaines données dans le segment sont prioritaires (rarement utilisé aujourd'hui).
    

### 3. Les "Démolisseurs" (Fermeture)

- **FIN (Finish) :** Fermeture polie. L'émetteur n'a plus rien à dire mais attend que l'autre côté confirme et ferme aussi.
    
- **RST (Reset) :** Fermeture brutale. On coupe tout sans préavis suite à une erreur ou un rejet de sécurité.
    

---

### Tableau Récapitulatif : Diagnostic Rapide

|**Flag(s) visible(s)**|**Interprétation Wireshark**|**Scénario probable**|
|---|---|---|
|**SYN**|Tentative de connexion|Début d'un chargement de page Web.|
|**SYN, ACK**|Acceptation du serveur|Le serveur est prêt à parler.|
|**ACK**|Confirmation simple|Le transfert se passe bien.|
|**PSH, ACK**|Envoi de données|L'application envoie un morceau de fichier.|
|**FIN, ACK**|Demande de fermeture|L'utilisateur ferme l'onglet du navigateur.|
|**RST**|Rejet / Erreur|Tentative sur un port fermé ou coupure pare-feu.|

---

### 💡 Le Conseil de l'Expert

Lorsqu'on vous donne une suite de paquets à analyser, regardez toujours le **premier flag** :

1. Si c'est un **SYN**, c'est une nouvelle session.
    
2. Si vous voyez **RST** dès le début, le service est inaccessible.
    
3. Si vous voyez des **Dup ACK** (souvent marqués en noir/rouge dans Wireshark), il y a de la congestion ou des pertes de paquets sur le lien.
    

---

## É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.

![](Pasted%20image%2020260308135822.png)
Ce que vous voyez est une **violation flagrante de la RFC 793** (la spécification officielle de TCP).

### 1. L'Anomalie des Flags (Le "Sapin de Noël")

Regardez le cadre rouge dans les détails du paquet 2 :

- **Flags : 0x03b (FIN, SYN, PSH, ACK, URG)**.
    
- **Le problème :** Dans une communication normale, ces flags ne sont **jamais** activés tous ensemble. Activer `SYN` (ouverture) et `FIN` (fermeture) simultanément est une contradiction logique pure.
    
- **Pourquoi ce nom ?** On l'appelle "Christmas Tree" car, comme un arbre de Noël, le paquet est "éclairé" par tous les flags possibles.

- **Caractériser l'attaque :** C'est un _Xmas Scan_. L'attaquant cherche à contourner les pare-feu qui ne filtrent que les paquets `SYN`. Comme ce paquet n'a pas que le flag `SYN`, certains vieux équipements pourraient le laisser passer.
    

### 2. Le Comportement du Serveur (Le Reset)

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". 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é

Ce que vous voyez ici n'est pas un transfert de données, mais une tentative de **Fingerprinting (Reconnaissance)** :

- Un attaquant envoie ces paquets bizarres pour voir comment le système d'exploitation du serveur réagit.
    
- 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)**

La meilleure réaction n'est pas de répondre `RST`, mais de devenir **invisible**.

- **Passer en mode "Drop" (ou Deny) :** Configurez votre pare-feu pour qu'il jette silencieusement ces paquets invalides au lieu de laisser le serveur répondre.
    
- **Règle de filtrage :** Bloquer toute combinaison de flags TCP qui ne respecte pas la machine à états (ex: `SYN` et `FIN` ensemble, ou aucun flag du tout).

#### **B. Au niveau du Système d'Exploitation (Hardening)**

- **Limitation de débit (Rate Limiting) :** Si vous recevez trop de paquets `RST` ou de tentatives de connexion invalides en une seconde, bannissez temporairement l'IP source (via un outil comme _Fail2Ban_ ou une règle d'IPS).
    
- **Mise à jour de la pile TCP :** Les systèmes modernes ignorent ou bloquent mieux ces anomalies, mais une pile réseau mal configurée peut révéler trop d'informations sur sa version via ses réponses.

## Configurer Fail2Ban contre les Scans Anormaux

Pour que Fail2Ban réagisse, il faut d'abord que votre pare-feu (ici `iptables`) enregistre les paquets suspects dans un fichier log (généralement `/var/log/messages` ou `/var/log/syslog`).

### 1. La règle de log (Préalable)

Avant Fail2Ban, on demande au pare-feu de marquer les scans "Christmas Tree" :

```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: "
```

### 2. Le filtre Fail2Ban (`/etc/fail2ban/filter.d/tcp-scans.conf`)

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éé.

```toml
[Definition]
# On cherche l'IP source (SRC=...) associée à notre préfixe de log
failregex = TCP-XMAS-SCAN: .* SRC=<HOST>
ignoreregex =
```

### 3. La "Jail" Fail2Ban (`/etc/fail2ban/jail.local`)

C'est ici que l'on définit la punition (le bannissement).

```toml
[tcp-xmas-protection]
enabled  = true
filter   = tcp-scans
logpath  = /var/log/messages
port     = all
# Si on détecte 3 tentatives (maxretry) en 1 minute (findtime)
findtime  = 60
maxretry  = 3
# On bannit l'IP pendant 1 heure
bantime   = 3600
action    = iptables-multiport[name=TCP-XMAS, port="all", protocol=tcp]
```


- **Réactivité :** Dès que l'attaquant dépasse le seuil de 3 paquets suspects (comme on le voit sur votre capture où il y a plus de 10 échanges en 0.1 seconde), il est coupé.
    
- **Dissuasion :** Le `bantime` de 1 heure décourage les outils de scan automatisés qui cherchent des cibles faciles.
    
- **Protection des ressources :** En bannissant au niveau du pare-feu, le serveur ne perd plus de temps à générer des paquets `RST`, ce qui économise du CPU et de la bande passante.
    

| Étape         | Outil      | Rôle                                                        |
| ------------- | ---------- | ----------------------------------------------------------- |
| **Détection** | `iptables` | Identifie les flags anormaux et écrit dans le log.          |
| **Analyse**   | `Fail2Ban` | Compte le nombre d'alertes par IP dans le temps.            |
| **Sanction**  | `iptables` | Ajoute une règle de blocage automatique pour l'IP coupable. |

### Synthèse de la posture de sécurité

|Type de Réponse|Effet sur l'Attaquant|Recommandation|
|---|---|---|
|**Le serveur répond RST** (ce qu'on voit sur l'image)|L'attaquant sait que le serveur est **actif** mais que le port est peut-être fermé ou protégé.|**Moyen.** On donne trop d'infos.|
|**Le Firewall "Drop" (silence)**|L'attaquant ne reçoit rien. Il ne sait pas si le serveur existe ou si le paquet a été perdu.|**Excellent.** C'est la posture de "discrétion".|
|**Bannissement (Blacklist)**|L'IP de l'attaquant est bloquée pour 24h sur tous les services.|**Idéal.** Pour stopper la reconnaissance.|

---

