Offre Durée limitée : -10% sur tout le site* avec le code ELYPSEWELCOME10

Lister les ports en écoute sur un serveur Linux avec ss

Mis à jour le 24 septembre 2026 5 min de lecture 10 sections

Sur un VPS ou un serveur dédié Linux, connaître les ports en écoute permet de vérifier quels services acceptent des connexions. La commande ss fournit cette vue directement depuis le système, sans modifier le pare-feu et sans interrompre un service. Ce guide distingue un port TCP ou UDP, une adresse d’écoute et le processus associé.

Avant de commencer

Connectez-vous avec un compte autorisé. Les options de base de ss fonctionnent souvent sans privilège élevé, mais l’identification complète d’un processus peut nécessiter sudo et le compte root. La commande observe l’état local : elle ne prouve pas qu’un port est accessible depuis Internet, car un pare-feu, une règle réseau, une route, une adresse IP ou un routeur peuvent bloquer la connexion.

Séparez trois questions : quel socket est ouvert, quel programme l’utilise, et le trafic est-il autorisé jusqu’au serveur ? Pour l’espace disque ou les performances, utilisez la surveillance de l’espace disque et le diagnostic CPU.

Afficher les ports en écoute

Commencez par afficher les sockets TCP et UDP :

sudo ss -tulpen

-t sélectionne TCP, -u UDP, -l les sockets en écoute, -p le processus, -e les informations étendues et -n évite la résolution DNS des noms de services et des adresses. Une variante courte est :

sudo ss -tuln
sudo ss -ltn

Une sortie UDP ne présente pas le même état LISTEN que TCP. Regardez toujours le protocole et le port.

Lire la sortie de ss

Netid indique notamment TCP ou UDP. State décrit l’état du socket. Pour TCP, LISTEN attend des connexions. Local Address:Port indique l’adresse et le port. 0.0.0.0:22 signifie toutes les adresses IPv4 locales, alors que 127.0.0.1:8080 limite l’écoute à la machine. Une adresse IPv6 comme [::]:80 doit être interprétée avec la configuration IPv6.

Une écoute sur une adresse privée ou loopback ne donne pas le même résultat qu’une écoute publique. Apache ou une application Web peut écouter sur 80 ou 443. Une base MySQL doit généralement rester locale ou interne selon l’architecture. FTP, SMTP et SSH doivent correspondre à un besoin précis et à une authentification adaptée.

Identifier le service et le processus

Avec -p, ss affiche le programme et son identifiant de processus. Comparez le PID avec systemd :

sudo ss -lntup
sudo systemctl status nom-du-service

Ne tuez pas un processus uniquement parce que son port paraît inhabituel. Vérifiez son unité systemd, son fichier de configuration, son propriétaire et ses journaux avec journalctl. La liste des services actifs complète cette observation :

systemctl --type=service --state=running

Filtrer un port ou une adresse

Pour rechercher le port SSH :

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

Pour une application Web, confirmez le processus, le proxy et le certificat. Consultez le guide de publication en HTTPS. Un port sur 127.0.0.1 ne répond pas comme un port lié à toutes les adresses IP, ce qui explique de nombreuses erreurs à distance.

Ne pas confondre écoute et ouverture réseau

Un port en écoute est une condition locale, pas une mesure complète d’accessibilité. Un firewall local ou un filtrage en amont peut bloquer le trafic. Vérifiez l’outil réellement utilisé :

sudo ufw status verbose

Sur un système utilisant iptables ou nftables, la syntaxe diffère. Avec UFW, confrontez les règles à la liste des sockets et consultez le guide d’ouverture des ports. Un test local ne prouve pas l’accès depuis Internet : prenez en compte DNS, NAT, routeur, réseau local et adresse IP publique.

Adresse IP, interface et routage

Identifiez l’interface réseau et le chemin choisi par le noyau :

ip address
ip route

ip address liste les interfaces, les adresses IPv4 et IPv6, tandis que ip route montre la route par défaut et la passerelle. Une IP publique, une IP privée, une IP fixe et l’interface loopback n’ont pas le même périmètre. Dans un réseau privé ou un LAN derrière un routeur, une redirection NAT peut être nécessaire, mais elle ne remplace pas l’écoute sur le serveur.

Le DNS associe un nom de domaine à une adresse, il n’ouvre pas un port. Vérifiez séparément le nom résolu, les serveurs DNS, les requêtes, l’adresse IP, le firewall et le routage. Dans un sous-réseau, contrôlez le masque de sous-réseau et l’adressage. Une adresse DHCP, une configuration réseau statique, une interface Ethernet désactivée ou un serveur DHCP indisponible peuvent changer le chemin du trafic. Une adresse MAC identifie la carte réseau sur le réseau local, mais ne remplace ni l’adresse IP ni la règle de pare-feu.

Ces contrôles se font en ligne de commande depuis un terminal. Ils sont utiles derrière un VPN, un modem ou un routeur : le tunnel et la redirection doivent conduire vers la bonne interface. ifconfig peut apparaître sur d’anciens systèmes, mais ip address est la commande à privilégier sur une installation Linux actuelle. Les protocoles TCP et UDP ne donnent pas toujours le même signal lors d’un test distant.

Procédure courte

  1. Listez les sockets avec sudo ss -tulpen.
  2. Repérez les adresses publiques, privées et locales.
  3. Identifiez le processus de chaque port inattendu.
  4. Vérifiez service, configuration et journaux.
  5. Comparez avec le firewall actif.
  6. Contrôlez DNS, IP, interface, masque et route.
  7. Testez depuis une source autorisée.

Si le serveur ne répond plus, ne modifiez pas plusieurs paramètres à la fois. Commencez par le diagnostic d’un VPS inaccessible, puis revenez à la liste des sockets.

Bonnes pratiques

Conservez la liste des ports attendus et notez les changements. Faites écouter une interface locale lorsque le service n’a pas besoin d’être public. Utilisez des règles de firewall explicites et contrôlez les services après une installation ou une mise à jour de paquets. Pour Ubuntu ou Debian, vérifiez le service après chaque redémarrage. Pour un serveur Web, contrôlez Apache ou le proxy, HTTPS et le firewall. Pour un serveur de jeu, vérifiez le port TCP ou UDP annoncé.

Pour approfondir la protection, consultez les premiers réglages d’un serveur dédié. Ne partagez pas publiquement les adresses IP, PID ou journaux complets d’une machine de production.

Besoin d’un environnement pour votre projet ?

Choisissez un VPS Linux adapté à vos services et gardez une vue claire des ports, des processus et des règles réseau.

Découvrir les VPS Linux