TCP et UDP
Les deux protocoles de transport d'Internet : la poignée de main en trois temps, les flags TCP, et ce qu'ils révèlent d'un scan ou d'une attaque.
Elouan
Série Les fondations du réseau · article 4 sur 7
TCP et UDP sont les deux protocoles de la couche transport. Ils portent les numéros de port et décident de la manière dont les données voyagent. Le sujet paraît simple, mais c’est lui qui permet de comprendre vraiment ce que l’on voit dans Wireshark ou dans un journal de pare-feu.
Deux philosophies
TCP (Transmission Control Protocol), c’est la lettre recommandée : on établit d’abord un contact, chaque morceau est numéroté, le destinataire accuse réception, et ce qui se perd est renvoyé.
UDP (User Datagram Protocol), c’est la carte postale : on l’envoie et on n’a aucune nouvelle. Pas de connexion, pas d’accusé de réception, pas de remise en ordre. Mais c’est beaucoup plus léger et plus rapide.
| TCP | UDP | |
|---|---|---|
| Connexion | Oui, poignée de main préalable | Non |
| Fiabilité | Accusés de réception, retransmission | Aucune garantie |
| Ordre | Données remises dans l’ordre | Pas garanti |
| En-tête | 20 octets minimum | 8 octets |
| Vitesse | Plus lent | Plus rapide |
| Usages | Web, mail, SSH, SMB, RDP, bases de données | DNS, DHCP, NTP, SNMP, VoIP, jeux, QUIC |
La poignée de main en trois temps
Avant d’échanger la moindre donnée, TCP établit la connexion :
Client Serveur
│ ── SYN (seq = x) ─────────────────► │ « Je veux te parler »
│ ◄──────────── SYN-ACK (seq = y, ack = x+1) │ « D'accord, moi aussi »
│ ── ACK (ack = y+1) ───────────────► │ « Bien reçu, on y va »
│ ═══════════ données ═════════════ │Les numéros de séquence permettent ensuite de remettre les données dans l’ordre et de savoir ce qui manque.
La fermeture se fait proprement avec des FIN, un dans chaque sens, chacun accusé par un ACK. Un RST coupe la connexion brutalement, sans politesse.
Les flags TCP
L’en-tête TCP contient des bits, appelés flags, qui donnent le sens de chaque segment.
| Flag | Signification | Quand on le voit |
|---|---|---|
| SYN | Synchroniser, ouvrir une connexion | Premier paquet de toute connexion |
| ACK | Accusé de réception | Presque tous les paquets après le premier |
| FIN | Fin, fermeture propre | Fin d’une connexion |
| RST | Reset, coupure immédiate | Port fermé, connexion refusée, coupure par un pare-feu |
| PSH | Push, transmettre tout de suite à l’application | Échanges interactifs |
| URG | Données urgentes | Rare aujourd’hui |
Filtres Wireshark utiles
tcp.flags.syn == 1 && tcp.flags.ack == 0 affiche les demandes de connexion (le premier SYN). Un grand nombre de ces paquets vers des ports ou des machines différentes, c’est la signature d’un scan.
Ce que les flags disent d’un scan
Quand un outil comme Nmap scanne un port TCP, il envoie un SYN et regarde la réponse :
| Réponse | État du port | Explication |
|---|---|---|
| SYN-ACK | Ouvert | Un service écoute |
| RST | Fermé | La machine répond, mais rien n’écoute |
| Rien, ou ICMP « unreachable » | Filtré | Un pare-feu bloque |
Le scan SYN (nmap -sS) répond au SYN-ACK par un RST au lieu de finir la poignée de main : c’est un scan semi-ouvert. Le scan connect (-sT) termine la poignée de main complète, ce qui laisse plus de traces dans les journaux applicatifs.
Piège classique
« Fermé » et « filtré » ne veulent pas dire la même chose. Fermé, la machine existe et répond. Filtré, quelque chose bloque le chemin. Pour un attaquant, savoir qu’une machine répond est déjà une information.
Les attaques qui exploitent TCP et UDP
Le SYN flood
L’attaquant envoie une avalanche de SYN, souvent avec des adresses source usurpées, et ne termine jamais la poignée de main. Le serveur garde chaque connexion à moitié ouverte en mémoire, jusqu’à saturer sa file d’attente. Les vraies connexions ne passent plus.
La parade classique est le SYN cookie : le serveur encode l’état de la connexion dans son numéro de séquence et ne réserve rien tant que l’ACK final n’est pas arrivé.
L’amplification UDP
Comme UDP n’a pas de poignée de main, on peut usurper l’adresse source. L’attaquant envoie de petites requêtes à des serveurs publics en se faisant passer pour la victime. Les serveurs répondent avec des réponses bien plus grosses, directement à la victime.
| Service | Pourquoi il amplifie |
|---|---|
| DNS | Petite requête, grosse réponse (requête ANY, DNSSEC) |
| NTP | L’ancienne commande monlist renvoyait une longue liste |
| Memcached | Facteur d’amplification énorme quand il est exposé |
| SSDP, CLDAP | Exposés par erreur sur Internet |
Le tunneling
Parce qu’ils sont presque toujours autorisés, certains protocoles servent à faire passer d’autres données en douce : DNS tunneling (des données encodées dans des noms de domaine), ICMP tunneling (des données dans les pings). Un volume anormal de requêtes DNS vers un même domaine aux sous-domaines aléatoires est un signal classique.
QUIC : UDP qui fait mieux que TCP
QUIC est le protocole de transport d’HTTP/3. Il tourne sur UDP/443, gère lui-même la fiabilité et l’ordre, et intègre TLS 1.3. Il réduit le temps d’établissement des connexions.
Un angle mort fréquent
Beaucoup de proxys et d’outils d’inspection ne gèrent que TCP. Si UDP/443 est ouvert en sortie, les navigateurs peuvent passer en QUIC et échapper à l’inspection. Certaines entreprises bloquent volontairement UDP/443 pour forcer le retour à TCP.
Le prochain article détaille le protocole UDP le plus important pour un analyste : le DNS.
L'essentiel
- TCP est orienté connexion et fiable (accusés de réception, retransmission, ordre). UDP est sans connexion et sans garantie, mais plus léger et plus rapide.
- Poignée de main TCP : SYN → SYN-ACK → ACK. Fermeture propre : FIN / ACK dans chaque sens. RST coupe brutalement.
- Flags TCP à connaître : SYN, ACK, FIN, RST, PSH, URG.
- Port fermé en TCP : la cible répond RST. Port filtré : pas de réponse (ou un ICMP d'erreur). Port ouvert : SYN-ACK.
- SYN flood = envoyer des SYN sans jamais finir la poignée de main pour saturer la file des connexions à moitié ouvertes. Parade : SYN cookies.
- UDP sert quand la vitesse compte plus que la fiabilité : DNS, DHCP, NTP, SNMP, VoIP, streaming, QUIC (HTTP/3).
Idées reçues
Quelle est la différence entre un port fermé et un port filtré ?
L'erreur courante. Dire que c'est la même chose.
En réalité. Fermé : la machine répond, mais aucun service n'écoute. En TCP elle renvoie un RST. Filtré : un pare-feu bloque, donc pas de réponse du tout (ou un ICMP « destination unreachable »). Nmap affiche « closed » dans le premier cas et « filtered » dans le second.
Pourquoi un scan SYN est-il appelé « semi-ouvert » ?
L'erreur courante. Dire qu'il n'ouvre que la moitié des ports.
En réalité. Parce que le scanner envoie un SYN, reçoit le SYN-ACK si le port est ouvert, puis répond par un RST au lieu d'un ACK : la poignée de main n'est jamais terminée. La connexion n'est donc pas journalisée par beaucoup d'applications, mais elle reste visible pour un pare-feu ou un IDS.
UDP n'a pas de poignée de main. Comment un scanner sait-il qu'un port UDP est fermé ?
L'erreur courante. Dire qu'on ne peut pas savoir.
En réalité. S'il est fermé, la machine renvoie en général un ICMP « port unreachable ». S'il est ouvert, le service peut répondre, ou ne rien dire du tout. C'est pour ça que les scans UDP sont lents et ambigus (« open|filtered » dans Nmap).
Pourquoi les attaques par amplification utilisent-elles UDP et pas TCP ?
L'erreur courante. Répondre « parce qu'UDP est plus rapide ».
En réalité. Parce qu'UDP n'a pas de poignée de main : l'attaquant peut usurper l'adresse source (celle de la victime) et le serveur répond directement à la victime. En TCP, la poignée de main échouerait. On choisit des services dont la réponse est bien plus grosse que la requête : DNS, NTP (monlist), memcached, SSDP.
HTTP/3 fonctionne-t-il sur TCP ?
L'erreur courante. Répondre oui, comme HTTP/1.1 et HTTP/2.
En réalité. Non. HTTP/3 repose sur QUIC, qui tourne sur UDP/443 et intègre le chiffrement TLS 1.3. C'est important en défense : un proxy ou un filtrage qui ne gère que TCP/443 peut se faire contourner par QUIC si UDP/443 est ouvert.
Tester ses connaissances
Références
- TCP/IP Illustrated, Volume 1 : The Protocols (2e éd.)Kevin R. Fall, W. Richard Stevens · Addison-Wesley
- Nmap Network ScanningGordon « Fyodor » Lyon · Insecure.Com LLC