Ports et Sockets

Les ports : l'adressage des applications

Une adresse IPadresse IPRéseauxIdentifiant numérique attribué à une machine sur un réseau, qui permet de l'atteindre depuis n'importe où. Elle tient sur 32 bits en IPv4 et sur 128 bits en IPv6.Voir dans le glossaire identifie un hôte sur le réseau. Mais un hôte fait tourner des dizaines d'applications simultanément : un serveur web, un serveur SSHSSHRéseauxProtocole sécurisé d'accès distant à un serveur, chiffrant session et authentification (clé ou mot de passe).Voir dans le glossaire, une base de donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire, un agentagentIASystème qui enchaîne des appels d'outils de façon autonome pour atteindre un objectif : il planifie, agit, observe, recommence. Sa fiabilité décroît exponentiellement avec le nombre d'étapes.Voir dans le glossaire de monitoring... Comment la couche réseau sait-elle vers quelle application livrer chaque paquet ?

La réponse : les portsportRéseauxNuméro sur 16 bits qui désigne l'application destinataire sur une machine. Les ports 0 à 1023 sont réservés aux services système, comme 443 pour HTTPS.Voir dans le glossaire. Un port est un entier sur 16 bits (0 à 65535) qui identifie une application ou un service spécifique sur un hôte. Combiné avec l'adresse IP et le protocole (TCPTCPRéseauxProtocole de transport qui garantit que les données arrivent complètes, dans l'ordre et sans doublon. Il établit une connexion, numérote chaque segment et retransmet ce qui manque.Voir dans le glossaire ou UDPUDPRéseauxProtocole de transport sans connexion ni garantie de livraison, réduit à un en-tête de 8 octets. Sa légèreté convient au DNS, à la voix et à la vidéo, où un retard coûte plus qu'une perte.Voir dans le glossaire), il permet d'adresser précisément un processus applicatif.

Analogie

Imaginez un immeuble de bureaux :

• L'adresse IP = l'adresse de l'immeuble (ex: 192.168.1.100)
• Le port = le numéro de bureau (ex: :80, :443, :22)
• Le socketsocketRéseauxAssociation d'une adresse IP et d'un port, qui identifie une extrémité de communication. Le quadruplet formé par les deux sockets d'une connexion la distingue de toutes les autres.Voir dans le glossaire = la ligne téléphonique directe du bureau

Vous envoyez votre courrier à "Immeuble 192.168.1.100, Bureau 443" → il arrive exactement au bon destinataire.

Les 3 catégories de ports

L'IANA (Internet Assigned Numbers Authority) divise les 65536 ports en trois catégories :

Ports éphémères (ephemeral ports)

Quand votre navigateur ouvre une connexion vers google.com:443, votre OS lui attribue automatiquement un port source éphémère choisi aléatoirement dans la plage dynamique. Ce port identifie votre connexion particulière.

# Voir la plage de ports éphémères configurée sur Linux
cat /proc/sys/net/ipv4/ip_local_port_range
# → 32768	60999  (plage par défaut sur Linux)

# Modifier la plage (pour serveurs très chargés)
sudo sysctl -w net.ipv4.ip_local_port_range="1024 65535"

Tableau des ports importants

Ports systèmes essentiels (0-1023)

Ports enregistrés courants (1024-49151)

Définition d'un socket

Un socket est un point de communication identifié par un quintuplet unique :

Socket = (Protocole, IP_source, Port_source, IP_destination, Port_destination)

Exemple : votre connexion HTTPS à Google

Protocole     : TCP
IP source     : 192.168.1.100   (votre IP)
Port source   : 54321           (port éphémère)
IP destination: 142.250.74.46   (IP Google)
Port dest     : 443             (HTTPS)

→ Socket identifiant : TCP 192.168.1.100:54321 ↔ 142.250.74.46:443

Ce quintuplet est globalement unique : il n'existe qu'une seule connexion avec cette combinaison précise au monde à cet instant.

Types de sockets

Cycle de vie d'un socket

Côté serveur (TCP)

# Pseudo-code du cycle de vie serveur
socket()    # Création du socket
bind()      # Lier à l'adresse et au port (ex: 0.0.0.0:80)
listen()    # Marquer comme passif, définir la file d'attente
accept()    # Bloquer jusqu'à l'arrivée d'une connexion client
            # → retourne un NOUVEAU socket pour cette connexion
read()/write()  # Communication avec le client
close()     # Fermer la connexion

Côté client (TCP)

# Pseudo-code du cycle de vie client
socket()    # Création du socket
            # Le kernel attribue automatiquement un port éphémère
connect()   # Initie le three-way handshake
write()/read()  # Envoi de la requête, lecture de la réponse
close()     # Fermeture de la connexion

États LISTEN vs ESTABLISHED

# Voir les sockets en état LISTEN (serveur en attente)
ss -tlnp

# Exemple de sortie typique d'un serveur web :
# State    Recv-Q  Send-Q  Local Address:Port  Peer Address:Port  Process
# LISTEN   0       511     0.0.0.0:80          0.0.0.0:*          nginx
# LISTEN   0       511     0.0.0.0:443         0.0.0.0:*          nginx
# LISTEN   0       128     0.0.0.0:22          0.0.0.0:*          sshd
# LISTEN   0       128     127.0.0.1:3306      0.0.0.0:*          mysqld

# Voir les connexions ESTABLISHED
ss -tnp state established

# Exemple :
# ESTAB  0  0  192.168.1.100:22   192.168.1.200:54321  users:(("sshd"))
# ESTAB  0  0  192.168.1.100:443  203.0.113.5:48291    users:(("nginx"))

La commande ss — Socket Statistics

ss (socket statistics) est le remplaçant moderne de netstat. Plus rapide, plus précis, directement depuis le kernel.

Syntaxe et options principales

ss [options] [filtres]

Options :
  -t    TCP sockets
  -u    UDP sockets
  -l    Sockets en écoute (LISTEN)
  -n    Afficher numéros (pas résolution nom/service)
  -p    Afficher le processus propriétaire
  -s    Résumé statistique
  -e    Informations étendues
  -i    Informations TCP internes (cwnd, rtt, etc.)
  -4    IPv4 uniquement
  -6    IPv6 uniquement

Commandes ss les plus utiles

# Tous les ports en écoute (TCP + UDP)
ss -tulnp

# Sortie exemple :
# Netid  State   Local Address:Port  Process
# udp    UNCONN  0.0.0.0:68          dhclient
# udp    UNCONN  0.0.0.0:123         ntpd
# tcp    LISTEN  0.0.0.0:22          sshd
# tcp    LISTEN  0.0.0.0:80          nginx
# tcp    LISTEN  0.0.0.0:443         nginx
# tcp    LISTEN  127.0.0.1:3306      mysqld

# Toutes les connexions TCP établies avec processus
ss -tnp state established

# Compter le nombre de connexions par état
ss -tn | awk 'NR>1 {print $1}' | sort | uniq -c | sort -rn

# Voir les connexions vers un port spécifique
ss -tnp dst :443

# Voir les connexions depuis une IP source
ss -tnp src 192.168.1.200

# Statistiques globales
ss -s
# Total: 856
# TCP: 43 (estab 31, closed 2, orphaned 0, timewait 2)
# UDP: 8

# Informations TCP avancées (RTT, cwnd, etc.)
ss -tip state established

# Filtres avancés
ss -tnp 'sport > 1024 and dport = 443'
ss -tnp 'dst 192.168.1.0/24'

Champ par champ : décoder la sortie de ss

State  Recv-Q  Send-Q  Local Address:Port  Peer Address:Port  Process

State    : LISTEN / ESTAB / TIME-WAIT / CLOSE-WAIT / etc.
Recv-Q   : Octets reçus non encore lus par l'application
           (en LISTEN : nombre de connexions en attente d'accept())
Send-Q   : Octets envoyés mais non encore acquittés
           (en LISTEN : backlog maximum configuré)
Local    : IP:Port local
Peer     : IP:Port distant (0.0.0.0:* si LISTEN)
Process  : Processus propriétaire (nécessite root pour les autres processus)

La commande lsof — List Open Files

lsof (List Open Files) liste tous les fichiers ouverts par tous les processus — et sous Linux, les sockets réseau sont des fichiers.

# Voir tous les fichiers réseau ouverts
sudo lsof -i

# Voir les processus sur le port 80
sudo lsof -i :80

# Exemple de sortie :
# COMMAND  PID     USER  FD  TYPE  DEVICE SIZE/OFF NODE NAME
# nginx    1234    root  6u  IPv4  23456  0t0      TCP  *:http (LISTEN)
# nginx    1235    www   6u  IPv4  23456  0t0      TCP  *:http (LISTEN)
# nginx    1235    www   8u  IPv4  24567  0t0      TCP  192.168.1.100:80->203.0.113.5:48291 (ESTABLISHED)

# Voir les sockets d'un processus spécifique (par nom)
sudo lsof -i -p $(pgrep nginx)

# Voir les connexions TCP
sudo lsof -i TCP

# Voir les connexions UDP
sudo lsof -i UDP

# Voir les Unix Domain Sockets (communication locale)
sudo lsof -U

# Trouver quel processus utilise le port 3306
sudo lsof -i :3306
# ou
sudo ss -tnlp | grep :3306

Port Forwarding

Le port forwarding (redirection de port) permet de rediriger le trafic arrivant sur un port vers une autre adresse/port.

SSH Port Forwarding (tunneling)

# Local port forwarding :
# Redirige localhost:8080 → serveur_distant:80
ssh -L 8080:localhost:80 user@serveur-distant
# Accédez à http://localhost:8080 dans votre navigateur

# Remote port forwarding :
# Le serveur distant redirige son port 9090 → votre localhost:3000
ssh -R 9090:localhost:3000 user@serveur-distant

# Dynamic port forwarding (proxy SOCKS5) :
# Crée un proxy SOCKS5 sur localhost:1080
ssh -D 1080 user@serveur-distant

iptables Port Forwarding (DNAT)

# Rediriger le port 8080 local vers un autre serveur sur le port 80
sudo iptables -t nat -A PREROUTING -p tcp --dport 8080 -j DNAT --to-destination 192.168.1.50:80

# Rediriger le port 80 vers une application interne sur 8080
sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080

# Voir les règles NAT actives
sudo iptables -t nat -L -n -v

Sécurité et bonnes pratiques

Un service qui n'écoute que sur 127.0.0.1 est inatteignable depuis le réseau, quel que soit l'état du pare-feupare-feuRéseauxÉquipement ou logiciel qui filtre le trafic selon des règles (ports, adresses, états) pour réduire la surface d'attaque.Voir dans le glossaire. Vérifiez systématiquement l'adresse d'écoute avec ss -tlnp : un 0.0.0.0 involontaire expose un service que vous croyiez local.

Minimiser la surface d'attaque

# Principe de base : n'exposer que les ports nécessaires

# Lister tous les ports en écoute (audit)
ss -tulnp

# Vérifier les ports exposés depuis l'extérieur
nmap -sT localhost
sudo nmap -sU -sT 192.168.1.100

# Fermer un service inutile (exemple : telnet)
sudo systemctl stop telnet
sudo systemctl disable telnet
sudo systemctl mask telnet  # empêche toute activation future

Bind sur localhost uniquement

# Mauvais : service exposé sur toutes les interfaces
mysqld --bind-address=0.0.0.0    # ← dangereux

# Bien : service uniquement sur localhost
mysqld --bind-address=127.0.0.1  # ← sécurisé

Vérifiez toujours dans /etc/mysql/mysql.conf.d/mysqld.cnf :

[mysqld]
bind-address = 127.0.0.1

Ports non-standard

Changer un service d'un port well-known (ex: SSH de 22 vers 2222) n'est pas une vraie sécurité (security by obscurity), mais peut réduire le bruit dans les logs provenant des scanners automatiques.

# Dans /etc/ssh/sshd_config
Port 2222

# Adapter le pare-feu
sudo ufw allow 2222/tcp
sudo ufw deny 22/tcp

Récapitulatif

Passez au chapitre suivant : ICMP et outils de diagnostic — les outilstool callingIACapacité d'un agent ou d'un LLM à invoquer des outils externes (API, calcul, recherche) pendant le raisonnement.Voir dans le glossaire essentiels pour diagnostiquer les pannes réseau.

IP = machine, port = service, socket = extrémité, quadruplet = connexion TCP.

Inventoriez les listeners (ss -tulpn) et fermez tout port non nécessaire.

Exposer un port admin sur 0.0.0.0 sans filtre est une invitation aux scans Internet.

Port = service logique sur un hôte

0–1023 dits privilégiés, 1024–49151 enregistrés, dynamique au-delà : utile comme culture, pas comme muraille. La sécurité vient des contrôles d’accès, pas du numéro « mythique ». Un SSH sur 2222 n’est pas secret ; il est seulement moins bruité par certains scanners naïfs.

Socket = quintuplet en pratique

Protocole, IP source, port source, IP dest, port dest. Deux connexions distinctes peuvent partager des éléments. ss -lntup montre qui écoute ; ss -ntu montre les flux. Lier une appli à 127.0.0.1 vs 0.0.0.0 change totalement l’exposition.

NAT et ports

Le NATNATRéseauxMécanisme qui permet à plusieurs machines d'un réseau privé de partager une seule adresse IP publique. Il compense la pénurie d'adresses IPv4 mais complique les connexions entrantes.Voir dans le glossaire réécrit ports/adresses. Un serveur derrière NAT nécessite port forwarding ou reverse tunnel. Les clients sortants s’appuient sur le suivi de connexion du NAT. Comprendre qui initie le flux évite d’ouvrir des trous inutiles.

« Port ouvert » côté nmap ≠ « application saine ». Cela signifie « quelque chose répond sur ce port ».

Ephemeral ports et épuisement

Sous charge, un client peut épuiser les ports éphémères ou saturer TIME_WAIT. Tuning possible, mais cherchez d’abord fuites de connexions applicatives.

Documentez pour chaque service : port, proto, listener IP, auth, owner — une ligne suffit souvent.

Cartographie d’écoute et surface d’attaque

Inventoriez périodiquement les listeners (ss -lntup) sur serveurs critiques. Chaque port ouvert inattendu est une piste : service oublié, malware, admin temporaire non retiré. Coupez, documentez, ou justifiez.

Les sockets Unix domain (fichiers) sortent du modèle IP/ports mais comptent pour la sécurité locale. Ne les ignorez pas sur les hôtes applicatifs.

Bind sur IPv6IPv6RéseauxVersion du protocole IP dont les adresses tiennent sur 128 bits, ce qui rend l'espace pratiquement inépuisable. Elle apporte aussi l'autoconfiguration et supprime le besoin de NAT.Voir dans le glossaire :: peut exposer aussi IPv4IPv4RéseauxVersion historique du protocole IP, dont les adresses tiennent sur 32 bits — soit environ 4,3 milliards de combinaisons, aujourd'hui épuisées.Voir dans le glossaire selon la stack (V6ONLY). Testez explicitement. Les reverse proxy doivent être la façade publique ; les backends écoutent en privé.

En conteneurs, le publication de ports (-p) est une décision de sécurité. Évitez de publier Redis/DB « pour dépanner ».

Firewall : deny by default et exceptions nommées

Chaque ouverture de port doit avoir un owner, une justification, une date de revue. Les règles « any any » temporaires deviennent permanentes. Automatisez l’inventaire des exceptions. Coupez ce qui n’a plus de ticket actif.

Sur les bastions, préférez l’accès par jump (SSH, SSM, VPN ZTNA) plutôt que d’exposer directement des ports d’admin. Le numéro de port n’est pas un secret ; le contrôle d’identité l’est.

Les healthchecks des load balancers ouvrent des flux réguliers : documentez-les pour ne pas les prendre pour du scan.

De la théorie socket à l’observabilité

Exposez métriques : connexions actives, errors, accept queue overflows, TIME_WAIT counts. Sans observabilité, vous réglez des ports à l’aveugle. Sur Kubernetes, services/ClusterIP/NodePort/LoadBalancer sont des indirection de ports : suivez le chemin jusqu’au pod.

Les probes de readiness sur le mauvais port mettent un service « up » pour le LB alors qu’il est KO applicativement. Alignez healthcheck et listener réel.

Exercice : sur une machine de lab, lancez un listener Python, connectez, observez ss, fermez mal, observez CLOSE_WAIT. Cette expérience sensorielle fixe le vocabulaire.

Inventaire continu et moindre exposition

Automatisez un scan interne authentifié des listeners et comparez à un baseline. Alertez sur nouveau port. Couplez avec le CMDB : tout listener doit mapper un service connu. Les écarts alimentent le backlog sécu.

Séparez ports d’admin et ports métier sur des interfaces/VLANVLANRéseauxRéseau local virtuel qui segmente logiquement un LAN Ethernet sans exiger un câblage physique séparé.Voir dans le glossaire différents quand c’est possible. Exposer SSH et HTTPS métier sur la même IP publique augmente le bruit et le risque.

Dans les architectures zero-trust, le « port ouvert » sur Internet tend vers zéro : identity-aware proxy, mesh mTLS, brokering. Comprendre sockets reste indispensable pour débugger le underlay.

Cas pratique : une application bind 0.0.0.0:8080 en conteneur + publication NodePort + SG cloud trop large = surface énorme. Refactor : bind localhost + sidecar proxy, ou service mesh. Expliquez ce chemin à un développeur en cinq minutes : c’est une compétence réseau moderne.

Les ephemeral port ranges varient selon OS. Sous charge de clients sortants (proxy, crawler), surveillez l’épuisement. Les symptômes ressemblent à des pannes réseau aléatoires.

Sockets : erreurs classiques développeur↔réseau

Bind permission denied sur port <1024 sans privilège. Bind address already in use (souvent TIME_WAIT ou double instance). Connexion refused = rien n’écoute. Timeout = filtre ou route. Broken pipe = l’autre a fermé. Traduire ces erreurs vers le réseau évite les ping-pong de tickets.

Standardisez les messages d’erreur applicatifs pour inclure IP:port cible et errno. Vous gagnerez des heures de correlation.

Sur les reverse proxies, la différence entre proxy_pass HTTP et stream TCP change le port backend et les headers. Documentez le mode. Les websockets ajoutent upgrade et timeouts idle spécifiques : testez-les explicitement après chaque changement de LB.

Enfin, dressez la liste des ports réellement nécessaires au fonctionnement d’un environnement de staging, et alignez prod. Les divergences staging/prod sur les ouvertures de ports sont une source classique de « ça marchait en recette ».

Approfondissement terrain — ports-sockets

Dans le chapitre ports-sockets, ancrez chaque notion par un exemple vécu ou un lab de cinq minutes. Écrivez le symptôme, l’hypothèse, la commande, le résultat, la conclusion : ce journal personnel accélère votre progression plus que la relecture passive. Partagez ensuite une version anonymisée dans le wiki d’équipe pour capitaliser. Revenez sur ce texte après un incident réel : annotez ce qui manquait. La maîtrise réseau se construit par boucles courtes de pratique, pas par accumulation de slides. Fixez-vous un exercice hebdomadaire de trente minutes jusqu’à ce que les commandes deviennent des réflexes. Variez les contextes : LAN, Wi-Fi, VPN, cloud, conteneur — le même concept change de visage. Quand une explication vous semble floue, reformulez-la sans jargon à un collègue non réseau. Si vous ne pouvez pas la reformuler, la notion n’est pas encore opérationnelle. Fermez chaque session d’étude par une question ouverte que vous résoudrez la fois suivante. Gardez une liste de « myths » à déconstruire : port élevé = sécurité, ping OK = service OK, etc. Ces myths coûtent cher en production ; les tuer est un objectif pédagogique explicite. Mesurez votre temps moyen pour classer un ticket réseau simple : il doit baisser au fil des chapitres. Enfin, reliez toujours la théorie à un risque : disponibilité, confidentialité, ou intégrité. Cas 13: documentez une observation concrète liée à ports sockets dans votre environnement de lab ou de staging. Dans le chapitre ports-sockets, ancrez chaque notion par un exemple vécu ou un lab de cinq minutes. Écrivez le symptôme, l’hypothèse, la commande, le résultat, la conclusion : ce journal personnel accélère votre progression plus que la relecture passive. Partagez ensuite une version anonymisée dans le wiki d’équipe pour capitaliser. Revenez sur ce texte après un incident réel : annotez ce qui manquait. La maîtrise réseau se construit par boucles courtes de pratique, pas par accumulation de slides. Fixez-vous un exercice hebdomadaire de trente minutes jusqu’à ce que les commandes deviennent des réflexes. Variez les contextes : LAN, Wi-Fi, VPN, cloud, conteneur — le même concept change de visage. Quand une explication vous semble floue, reformulez-la sans jargon à un collègue non réseau.

Closing note — ports et sockets

Retenez une phrase : un port n’est qu’un numéro ; la sécurité vit dans l’identité, le réseau de confiance et la revue des exceptions. Inventoriez, justifiez, expirez. Avec cette discipline, le chapitre sockets devient un réflexe d’hygiène plutôt qu’une liste à mémoriser.