Ports ouverts sous Linux : netstat, ss et les commandes à utiliser aujourd’hui

Vous cherchez à savoir quels ports sont ouverts sur une machine Linux ? Commencez par une précision importante : un port « ouvert » côté serveur veut souvent dire en écoute localement. Cela ne prouve pas encore qu’il est accessible depuis Internet, ni qu’un pare-feu le laisse passer.

Dans mon cas, je vérifie toujours en deux temps : d’abord ce qui écoute sur le serveur avec ss, puis le service ou le processus derrière le port. netstat reste connu, mais sur beaucoup de distributions modernes, il n’est plus installé par défaut. Autant utiliser les bons réflexes actuels.

Tux inspecte les ports réseau ouverts d’un serveur Linux

La commande à utiliser aujourd’hui : ss

Sur Linux récent, ss est la commande à privilégier. Elle fait partie de la pile iproute2 et remplace très souvent netstat pour inspecter les sockets réseau.

sudo ss -lntup

Les options sont importantes :

-l affiche les ports en écoute.
-n évite la résolution DNS et garde les ports en chiffres.
-t limite aux connexions TCP.
-u ajoute UDP.
-p affiche le processus associé, quand vous avez les droits.

Sans sudo, vous verrez parfois le port, mais pas toujours le programme derrière. Pour un audit rapide sur un serveur, je préfère lancer la commande avec les droits administrateur et lire directement la colonne Process.

Lire le résultat sans se tromper

Un résultat typique ressemble à ceci :

State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
LISTEN 0      128        0.0.0.0:22       0.0.0.0:*       users:(("sshd",pid=812,fd=3))
LISTEN 0      511      127.0.0.1:3306     0.0.0.0:*       users:(("mariadbd",pid=1044,fd=21))

La colonne à regarder en premier est Local Address:Port. Si vous voyez 0.0.0.0:22, le service écoute sur toutes les interfaces IPv4. Si vous voyez 127.0.0.1:3306, le service écoute seulement en local. Ce n’est pas le même risque.

Pour IPv6, vous pouvez aussi voir [::]:80 ou [::1]:5432. Là encore, ne lisez pas trop vite : [::] peut signifier une écoute large côté IPv6, alors que [::1] reste local.

Filtrer un port précis

Si vous cherchez seulement SSH, HTTP ou une base de données, inutile de parcourir toute la sortie. Filtrez avec grep ou avec les filtres de ss.

sudo ss -lntup | grep ':22'
sudo ss -lntup | grep ':80'
sudo ss -lntup | grep ':443'

Pour une sortie plus ciblée sur TCP, vous pouvez utiliser :

sudo ss -ltnp '( sport = :22 )'

Je garde souvent la version avec grep quand je suis pressé, parce qu’elle parle à tout le monde. Pour un script ou un diagnostic propre, les filtres natifs de ss évitent les faux positifs.

Et netstat dans tout ça ?

netstat n’a pas disparu de la mémoire des admins, mais il vient du paquet net-tools, souvent absent sur Debian, Ubuntu ou des installations minimales. Si vous tombez sur une documentation qui demande netstat et que la commande manque, ce n’est pas forcément une erreur de votre serveur.

netstat -lntup

La sortie est proche dans l’idée : protocoles, adresses locales, ports, PID et nom du programme. Mais si vous devez installer un paquet juste pour utiliser netstat, demandez-vous d’abord si ss ne suffit pas. Sur un serveur récent, ma réponse est presque toujours oui.

La page de manuel de ss détaille les filtres disponibles. Celle de netstat reste utile si vous maintenez encore d’anciens scripts.

Retrouver le processus derrière un port

Quand un port vous surprend, ne le fermez pas au hasard. Identifiez d’abord le processus, puis le service systemd associé si nécessaire.

sudo ss -lntup
sudo lsof -iTCP -sTCP:LISTEN -P -n

lsof est pratique quand vous voulez relier un port, un PID et un binaire. Avec -P, les ports restent en chiffres. Avec -n, vous évitez les résolutions DNS qui ralentissent ou brouillent la lecture.

Si vous avez un PID, remontez ensuite vers le service :

ps -p 812 -o pid,ppid,user,cmd
systemctl status ssh

Pour un serveur qui tourne avec systemd, le guide sur les services Linux et les commandes systemctl complète bien cette étape. Le but est de savoir si vous avez un service attendu, un conteneur, un vieux daemon oublié ou un processus lancé à la main.

Port en écoute ne veut pas dire port exposé

C’est le piège classique. Si ss montre un port en écoute, vous savez qu’un programme accepte des connexions sur la machine. Vous ne savez pas encore si ce port passe le pare-feu local, les règles cloud, le NAT ou le routeur.

Pour faire le tri, vérifiez au minimum :

l’adresse d’écoute : 127.0.0.1, 0.0.0.0, IP privée, IP publique ;
le service derrière le port ;
le pare-feu local, par exemple ufw, nftables ou iptables ;
les règles de sécurité côté hébergeur ou cloud ;
un test depuis une autre machine quand vous devez valider l’exposition réelle.

sudo ufw status verbose
sudo nft list ruleset
sudo iptables -S

Ne lancez pas ces commandes dans un script de nettoyage automatique. Lisez d’abord. Sur un serveur distant, une mauvaise règle de pare-feu peut vous couper SSH plus vite que prévu. Si SSH ne répond déjà plus, reprenez plutôt la méthode pour réinstaller et vérifier SSH sur Ubuntu.

Ma vérification rapide avant de toucher au pare-feu

sudo ss -lntup pour voir les ports TCP et UDP en écoute.
sudo ss -ltnp si je veux seulement TCP.
sudo lsof -iTCP -sTCP:LISTEN -P -n pour confirmer le processus.
systemctl status nom-du-service pour vérifier le service derrière.
journalctl -u nom-du-service -b --no-pager si le service écoute alors qu’il ne devrait pas.
un test externe uniquement après avoir compris ce qui écoute localement.

Si vous découvrez un port inattendu, ne commencez pas par tuer le processus. Notez le port, le PID, le service, puis regardez les logs. Le guide sur journalctl au dernier démarrage vous aidera à savoir si le service démarre automatiquement ou s’il vient d’une action récente.

Pour résumer simplement : ss d’abord, netstat seulement si vous devez maintenir de vieux réflexes, et jamais de modification pare-feu avant d’avoir identifié le service derrière le port.