Oubliez netstat

Introduction aux sockets sous Linux

Dans l’administration quotidienne et le dépannage d’infrastructure Linux, l’audit fin des communications réseau constitue une compétence incontournable. Alors que l’historique netstat souffre de lenteurs chroniques dues au parcours du système /proc, l’utilitaire ss (Socket Statistics) s’impose désormais comme le standard moderne incontournable. Conçu pour interroger directement le sous-système réseau du noyau, il permet d’inspecter les ports en écoute, de disséquer les sessions actives et d’isoler les démons associés avec une rapidité exemplaire.

1. Déploiement de l’environnement et extraction des métriques globales

L’utilitaire ss fait partie intégrante de la suite logicielle iproute2. Avant d’entamer les diagnostics, assurons-nous que le paquet est présent et à jour dans notre distribution Ubuntu.

Mise à jour et installation du paquet iproute2

Pour obtenir une vue synthétique sans encombrer la console avec des centaines de lignes de flux, le commutateur -s offre un état des lieux instantané de la pile réseau (répartition TCP, UDP, RAW ou Netlink).

⚙️ [Paramètres essentiels pour moduler l’affichage]

-s : Affiche un rapport chiffré récapitulatif de l’ensemble des sockets du système.
-t : Isole exclusivement le trafic et les sockets relevant du protocole TCP.
-u : Restreint le résultat aux échanges sous protocole UDP.
-l : Filtre pour n’afficher que les services passifs en attente de connexion (LISTEN).
-a : Expose l’exhaustivité des sockets, combinant ports à l’écoute et flux ouverts.
-n : Désactive la résolution DNS et le décodage de noms de services pour présenter adresses IP et ports sous leur forme numérique brute.
-p : Révèle le processus applicatif (nom du binaire et PID) exploitant chaque socket.

Affichage du résumé statistique global via ss -s

2. Déploiement d’un service HTTP et détection des points d’entrée TCP

Afin d’illustrer concrètement la capture d’un port ouvert, procédons au déploiement du serveur HTTP Nginx puis démarrons immédiatement son unité système.

Installation et lancement du serveur Nginx

L’exécution combinée ss -tl dresse l’inventaire des sockets TCP passives en convertissant les identifiants de ports en désignations textuelles conventionnelles (http, ssh, etc.).
Dans la sortie obtenue, nous constatons immédiatement que Nginx surveille activement les requêtes entrantes sur l’étiquette standard http.

Inspection des services TCP en attente de requêtes via ss -tl

L’adjonction de l’argument -n, formant la directive ss -tln, supprime toute interprétation sémantique issue du fichier /etc/services.
Cette présentation brute s’avère particulièrement précieuse pour lever toute ambiguïté lors de configurations de liaisons sur des ports non standards, traduisant http en 80 ou ssh en 22.

Visualisation numérique directe des ports en écoute avec ss -tln

3. Corrélation entre flux réseau et processus hôtes (PID & démons)

Pour savoir quel programme détient l’accès exclusif à une interface, invoquez le drapeau -p via la syntaxe ss -tlp.
La colonne Process expose alors l’association directe entre la ressource réseau et l’identifiant système (PID) des composants actifs, mettant en lumière le démon Nginx ou les services gérés par systemd.

Association des ports d’écoute à leurs exécutables respectifs avec ss -tlp

L’une des commandes les plus fréquemment dégainées par les administrateurs système chevronnés reste ss -tulpn. Elle regroupe en une seule analyse les protocoles TCP et UDP, affiche les valeurs numériques strictes et divulgue les processus associés.
Cette vue panoramique permet de vérifier en une fraction de seconde la conformité des écoutes sur les ports 80 (Nginx), 22 (OpenSSH) ou 53 (systemd-resolved).

Audit combiné TCP/UDP et identification des processus via ss -tulpn

4. Traçage des flux actifs et ciblage chirurgical par filtre

Générons un échange réseau réel à destination de notre instance locale à l’aide de l’outil curl, afin d’observer la dynamique des sockets en transit.

Émission d’un appel HTTP local à l’aide de curl

L’option -a appliquée à TCP via ss -ta lève le filtre restreint de l’écoute passive pour inclure l’intégralité des phases du cycle de vie réseau, telles que l’état transitoire TIME-WAIT.
La trace de la requête Web que nous venons de déclencher sur 127.0.0.1:http apparaît alors clairement en attente de clôture définitive.

Exposition de l’ensemble des sockets TCP y compris TIME-WAIT via ss -ta

Pour isoler les communications pleinement opérationnelles au moment T, le filtrage par machine à états ss -t state established ne retient que les sessions connectées (ESTABLISHED).
Puisque notre interrogation via curl a immédiatement achevé son cycle de transfert, aucun flux persistant ne subsiste dans cette catégorie.

Filtrage des connexions maintenues en état ESTABLISHED

Plutôt que de faire transiter la sortie par un tube grep, la commande ss intègre un moteur de filtrage natif extrêmement performant. En précisant par exemple ss -tln 'sport = :80', on restreint l’examen au seul port source 80.
Cette approche chirurgicale isole instantanément l’état opérationnel du serveur Web au sein d’une pile réseau saturée de connexions.

Filtrage sélectif sur le port source 80 avec ss -tln sport = :80

Vous disposez désormais de tous les réflexes nécessaires pour substituer définitivement l’antique netstat par la vélocité de ss au sein de vos parcs de serveurs Linux.
Adoptez sans attendre ces syntaxes lors de vos prochains audits de sécurité et diagnostics de connectivité sous Ubuntu.