cedricAbonnel/s-informer-sur-la-tech-www

Fork 0

Files

Cédrix a9f7dac640 vault backup: 2026-03-08 14:05:16

2026-03-08 14:05:16 +01:00

29 KiB

Raw Blame History

title, description, tags, date, lastmod, type, category, status

title

description

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

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) :

Faites un clic droit sur un paquet TCP.

Allez dans Protocol Preferences > Transmission Control Protocol.

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

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.

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."
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."
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 (É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).
Résultat : Cela permet d'étendre virtuellement la fenêtre jusqu'à 1 Go, crucial pour saturer les liens à haute latence (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.

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".
Gain : L'émetteur ne retransmet que le "trou" manquant, économisant ainsi une bande passante précieuse.

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) :

C → S [SYN] : SEQ = 1000, Options: MSS=1460, SACK=OK, WS=128
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.
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.

Le récepteur reçoit le n°1 : il renvoie ACK 2 (J'attends le 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.
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.

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

FIN (Client → Serveur) : "J'ai fini d'envoyer mes données, je souhaite fermer mon sens de communication."
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.
FIN (Serveur → Client) : "De mon côté aussi, j'ai terminé."
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 :

Si c'est un SYN, c'est une nouvelle session.
Si vous voyez RST dès le début, le service est inaccessible.
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 : 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.

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". Fidèle à sa logique de protection, il coupe court à la discussion en envoyant un Reset brutale.

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.

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

Bash

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

Ini, 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).

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

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 ?

29 KiB Raw Blame History