Ports ouverts sous Linux : ss, netstat, lsof, nmap

Lister les ports ouverts avec ss, le standard moderne

Chaque port ouvert sur un système Linux existe parce qu'un processus a demandé au noyau d'écouter dessus. L'outil qui affiche ces sockets aujourd'hui est ss (socket statistics), issu de la suite iproute2 installée sur toutes les distributions modernes. Une seule commande couvre la majorité des cas :

sudo ss -tulpn

Chaque option remplit un rôle précis :

• -t : inclure les sockets TCP
• -u : inclure les sockets UDP
• -l : n'afficher que les sockets en écoute (retirez-la pour voir aussi les connexions établies)
• -p : afficher le processus propriétaire de chaque socket ; c'est la raison du sudo, car sans lui vous ne voyez que vos propres processus
• -n : sortie numérique, qui affiche :22 au lieu de :ssh et évite les résolutions DNS inverses, ce qui accélère aussi la commande

Une ligne de sortie typique ressemble à ceci :

Netid State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
tcp   LISTEN 0      128          0.0.0.0:22         0.0.0.0:*    users:(("sshd",pid=712,fd=3))

La colonne Local Address est celle qui compte pour la sécurité. 0.0.0.0:22 signifie que le socket accepte les connexions sur toutes les interfaces IPv4, [::]:22 en est l'équivalent IPv6, et 127.0.0.1:5432 indique un service qui ne répond que sur la boucle locale, totalement injoignable depuis le réseau.

Quelques variantes à retenir :

ss -tlnp                      # TCP listeners only
ss -ulnp                      # UDP listeners only
sudo ss -tlnp 'sport = :22'   # who is listening on port 22
ss -tn state established      # active TCP connections right now

netstat fonctionne encore, mais c'est du legacy

Des millions de tutoriels indiquent toujours netstat -tulpn, et les options correspondent une à une à la commande ss ci-dessus : la mémoire musculaire se transpose dans les deux sens. La différence est interne : netstat appartient au paquet net-tools en mode maintenance et lit des fichiers de /proc, tandis que ss interroge directement le noyau via netlink, ce qui est nettement plus rapide sur des machines qui jonglent avec des milliers de sockets.

La plupart des distributions actuelles ne fournissent plus net-tools par défaut. Si vous en avez tout de même besoin :

sudo netstat -tulpn

# if the command is missing:
sudo apt install net-tools    # Debian / Ubuntu
sudo dnf install net-tools    # RHEL / Fedora

Aucune raison de l'installer sur un serveur neuf. Considérez netstat comme un repli de compatibilité pour les systèmes anciens dont vous héritez, et utilisez ss partout ailleurs.

lsof : les ports vus du côté des processus

Sous Linux tout est fichier, y compris les sockets réseau : lsof (list open files) fait donc aussi office d'inspecteur de ports. Il brille lorsque vous raisonnez déjà en processus plutôt qu'en ports :

sudo lsof -i -P -n                  # every process with a network socket
sudo lsof -iTCP -sTCP:LISTEN -P -n  # TCP listeners only
sudo lsof -i :443                   # everything touching port 443

-P et -n désactivent la résolution des noms de ports et d'hôtes, exactement comme le -n de ss -tulpn. La troisième forme est celle du quotidien : vous visez un port et vous obtenez le nom de la commande, le PID, l'utilisateur et le descripteur de fichier dans un tableau lisible. Contrairement à ss, lsof liste aussi les connexions établies de chaque processus à côté de ses sockets en écoute, ce qui aide quand vous voulez savoir qui dialogue actuellement avec un service, et pas seulement que ce service existe.

nmap : être en écoute n'est pas être joignable

Tout ce qui précède répond à une question : qu'est-ce qui écoute sur cette machine. Une autre question compte davantage pour la sécurité : qu'est-ce qui est réellement joignable depuis l'extérieur. Les deux listes coïncident rarement, car les pare-feu locaux, le filtrage côté hébergeur et les binds sur la boucle locale creusent des écarts entre elles. C'est aussi pourquoi se scanner soi-même depuis soi-même ne prouve rien : nmap localhost passe par l'interface loopback, contourne intégralement vos règles de pare-feu externe et signale joyeusement des services qu'aucun attaquant ne pourrait atteindre.

Lancez le scan depuis une autre machine, en visant l'IP publique du serveur :

nmap 203.0.113.10                            # top 1000 TCP ports
nmap -p- 203.0.113.10                        # all 65535 TCP ports
sudo nmap -sU --top-ports 100 203.0.113.10   # common UDP ports (slow)

nmap rapporte trois états à comprendre : open signifie qu'un service a répondu, closed que le paquet est arrivé mais que rien n'écoute là, et filtered que le paquet a été silencieusement jeté, presque toujours par un pare-feu. Un port que ss affiche en LISTEN mais qu'un nmap distant signale comme filtered : c'est exactement l'image d'un pare-feu qui fonctionne. Une règle s'applique sans exception : ne scannez que des hôtes qui vous appartiennent ou que vous êtes explicitement autorisé à tester.

Trouver précisément quel processus occupe un port

Supposons que quelque chose squatte le port 8080 et que votre application ne parvienne pas à s'y lier. Trois chemins mènent au PID :

sudo ss -tlnp 'sport = :8080'
sudo lsof -i :8080
sudo fuser -v 8080/tcp

fuser est le plus compact : il affiche le PID, et -v ajoute l'utilisateur et le nom de la commande. Il peut même tuer le coupable directement avec fuser -k 8080/tcp, mais cela envoie un signal sans aucun nettoyage au niveau du service : à réserver au dernier recours. Une fois le PID en main, ps -fp PID montre la ligne de commande complète, et systemctl status PID indique quelle unité systemd l'a lancé.

Quand vous n'avez aucun outil (une image de conteneur minimaliste, par exemple), la table du noyau est toujours là : cat /proc/net/tcp. Les ports y apparaissent en hexadécimal (0016 vaut 22) et l'état 0A signifie LISTEN. Cette table brute est précisément la donnée que les autres outils analysent et mettent en forme pour vous.

Tout ce qui ouvre un socket apparaît de la même façon dans ces listes, qu'il s'agisse d'une base de données ou d'une pile de proxy : un inbound V2Ray, par exemple, n'est qu'un socket en écoute sur le port que vous avez configuré, comme l'explique notre guide du protocole V2Ray.

Fermer un port ouvert : kill ou pare-feu

Un port est ouvert parce qu'un processus écoute dessus, ce qui vous laisse deux leviers distincts : supprimer le socket en écoute, ou bloquer l'accès. Ils ne sont pas interchangeables, et sur tout ce qui compte vraiment, il faut généralement actionner les deux.

La bonne solution est d'arrêter et de désactiver le service propriétaire du socket. Tuer le PID paraît plus rapide mais tient rarement : systemd relance automatiquement les services supervisés, et le port est de retour avant que vous ne relanciez ss. Réservez kill aux processus que vous avez lancés à la main. Pour voir ce qui tourne et couper ce dont vous n'avez pas besoin, notre guide sur la liste des services avec systemctl couvre ce flux de bout en bout.

sudo systemctl stop cups
sudo systemctl disable cups

Le pare-feu prend en charge le second levier. Sous Ubuntu, autorisez SSH avant d'activer ufw, sinon vous vous verrouillerez hors de la machine :

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enable

Sur les systèmes de la famille RHEL, la zone par défaut de firewalld rejette déjà le trafic non sollicité ; retirez ce que vous aviez ouvert avec firewall-cmd --permanent --remove-port=8080/tcp puis firewall-cmd --reload. Une chose n'est pas une solution : déplacer un service sur un port non standard. Cela vous cache des scans les plus paresseux et allège vos logs, mais nmap -p- trouve le nouveau port en quelques minutes. L'obscurité n'est pas de la sécurité : fermez le port ou filtrez-le.

Un audit des ports en cinq minutes sur un serveur neuf

À la première connexion sur une machine fraîchement provisionnée, faites l'inventaire avec sudo ss -tulpn. Une installation minimale propre doit afficher très peu de choses : sshd sur le 22 et, sur les distributions utilisant systemd-resolved, un résolveur DNS local sur 127.0.0.53:53. Tout le reste mérite une explication. Déroulez ensuite cette checklist :

1. Identifiez chaque socket en écoute par nom de processus et PID ; désactivez tout service que vous n'avez pas demandé.
2. Remettez en question chaque bind sur 0.0.0.0 ou [::] : bases de données et panneaux d'administration ont leur place sur 127.0.0.1, sauf s'ils doivent réellement servir le réseau.
3. Reconnaissez les ports courants du premier coup d'œil : 22 SSH, 80/443 web, 3306 MySQL, 5432 PostgreSQL, 6379 Redis. Le port 3389 est celui du bureau à distance. Sous Linux, cela signifie que xrdp tourne, et son exposition comme son durcissement font l'objet de notre guide du port RDP 3389.
4. Scannez l'IP publique depuis votre propre machine avec nmap -p- et comparez le résultat à la liste de ss ; chaque écart est soit un pare-feu qui fait son travail, soit un bind sur la boucle locale.
5. Terminez par un pare-feu en refus par défaut qui n'autorise que les ports que vous avez sciemment choisi d'exposer.

Voici toute la boîte à outils, une ligne par commande :

Ces commandes ne deviennent des réflexes que sur une machine où vous détenez un vrai root et où rien d'important ne peut casser. Un VPS Linux chez rdp.monster vous donne exactement ce bac à sable : accès administrateur complet, CPU et RAM dédiés, bande passante illimitée (fair-use), sans KYC, et le serveur est en ligne environ 10 secondes après confirmation du paiement, assez vite pour y lancer votre premier ss -tulpn avant que votre café ne refroidisse.

Foire aux questions

Faut-il être root pour lister les ports ouverts sous Linux ?

Non pour lister les ports, oui pour voir quel processus les détient.

N'importe quel utilisateur peut lancer ss -tuln ou lire /proc/net/tcp : la liste des ports en écoute n'est jamais cachée. La limite se situe sur l'option -p : sans root, ss, lsof et fuser ne révèlent que les processus appartenant à votre utilisateur, et les autres sockets apparaissent avec une colonne de processus vide. Avec nmap, le scan SYN par défaut (-sS) exige root ; le repli non privilégié est le scan connect (-sT), qui fonctionne très bien mais reste un peu plus bruyant.

Comment vérifier si un port précis est ouvert sur un serveur distant ?

Utilisez netcat : nc -zv hote port donne une réponse immédiate.

nc -zv example.com 443 tente une connexion TCP et signale la réussite ou l'échec sans envoyer de données. Si netcat manque, Bash seul suffit : timeout 3 bash -c '</dev/tcp/example.com/443' && echo open. Les deux prouvent seulement que quelque chose a accepté la connexion : ils ne disent rien du service qui a répondu ni de son état de santé. Pour UDP, il n'existe pas de test rapide fiable, car un port silencieux peut être ouvert ou filtré ; utilisez nmap -sU dans ce cas.

Pourquoi ss affiche un port en écoute alors que je ne peux pas m'y connecter de l'extérieur ?

Le socket est lié à la boucle locale, ou un pare-feu jette le trafic.

Regardez d'abord la colonne Local Address : 127.0.0.1:PORT ou [::1]:PORT signifie que le service n'accepte que les connexions locales, ce qui est volontaire et courant pour les bases de données. S'il est lié à 0.0.0.0, les paquets sont filtrés quelque part sur le trajet : un pare-feu local comme ufw, firewalld ou nftables brut, ou le filtrage en bordure de votre hébergeur. Un scan nmap externe qui annonce le port comme filtered confirme un pare-feu ; closed signifie que le trafic arrive mais que rien n'écoute sur cette interface.

Quels ports doivent être ouverts sur un serveur Linux neuf ?

Un seul : SSH. Tout le reste, sur une installation propre, mérite une explication.

Une installation minimale de Debian, Ubuntu ou Rocky ne devrait exposer que sshd sur le port 22 au réseau. Un résolveur DNS local sur 127.0.0.53:53 (systemd-resolved) est normal et injoignable depuis l'extérieur. Les images cloud ajoutent parfois un agent ou un démon de supervision : identifiez chaque socket en écoute avec ss -tulpn et désactivez tout ce que vous n'avez pas demandé. Chaque service installé ensuite devrait se lier par défaut à la boucle locale, sauf s'il doit réellement servir le réseau, le pare-feu n'autorisant que ce qui est public.