Ports ouverts Linux : les vérifier, identifier les services et sécuriser votre machine

Pour vérifier les ports ouverts Linux, lancez d’abord sudo ss -tulnp ou sudo lsof -nP -iTCP -sTCP:LISTEN. Ces commandes affichent les ports en écoute et, selon les droits disponibles, les processus associés. Un port listé localement n’est pas automatiquement accessible depuis le réseau ou Internet.

Le diagnostic utile suit trois vérifications : repérer le service qui écoute, contrôler l’adresse d’écoute et tester l’accès depuis une machine autorisée. Cette méthode permet de distinguer un service normal, comme SSH, d’un port inattendu qui mérite une vérification de configuration ou de pare-feu.

Comprendre ce qu’est un port ouvert sous Linux

Un port réseau est un numéro qui permet à un service réseau Linux de recevoir ou d’émettre des échanges sur une machine. Un serveur SSH, un serveur web ou un service de base de données peuvent chacun utiliser un port distinct. Les numéros de port vont de 0 à 65 535, selon le registre des services et ports de transport de l’IANA.

Les ports de 0 à 1 023 sont traditionnellement associés à des services réservés ou connus, comme SSH sur 22 et HTTP sur 80. Les ports de 1 024 à 49 151 accueillent fréquemment des applications installées. Les ports de 49 152 à 65 535 sont généralement utilisés comme ports temporaires côté client. La plage ne suffit jamais à identifier un risque : le programme et son exposition comptent davantage.

Port en écoute, port ouvert et port accessible

Un port en écoute est associé à un processus prêt à accepter des connexions. Un port ouvert est souvent employé comme synonyme dans les sorties d’outils, mais l’interprétation dépend du point d’observation. Un pare-feu, une règle réseau, un routeur ou une adresse d’écoute peuvent empêcher toute connexion extérieure.

Une écoute sur 127.0.0.1:8080 n’accepte que les connexions depuis la machine elle-même. Une écoute sur 0.0.0.0:8080 vise les interfaces IPv4 disponibles, sous réserve des règles de filtrage. Lire l’adresse avant de conclure évite de confondre un service local et un service exposé.

TCP et UDP : deux mécanismes différents

TCP établit une connexion suivie entre un client et un service. SSH et HTTPS utilisent souvent TCP. UDP envoie des datagrammes sans établir la même relation persistante ; DNS ou DHCP peuvent l’utiliser selon leur rôle et leur configuration.

Le mot LISTEN s’applique surtout à TCP. Pour UDP, les outils signalent un socket associé à une adresse et à un port, sans que l’état de connexion soit identique. Cette différence explique pourquoi la même lecture ne convient pas exactement aux deux protocoles.

Un port visible dans un terminal décrit une écoute locale ; l’accessibilité réelle doit être vérifiée depuis le réseau concerné.

Comment vérifier les ports ouverts Linux avec ss ?

La commande sudo ss -tulnp affiche les sockets TCP et UDP en écoute, les adresses locales et les processus lorsqu’ils sont accessibles avec les permissions utilisées. La commande ss est l’outil à privilégier sur les distributions actuelles : elle remplace couramment netstat pour ce diagnostic.

La page de manuel de ss détaille les filtres disponibles, qui peuvent varier légèrement selon la version et la distribution. Utilisez sudo lorsque vous devez voir les processus appartenant à d’autres comptes système.

sudo ss -tulnp

Option	Effet	Utilité pratique
-t	Affiche les sockets TCP	Repérer les services TCP en écoute
-u	Affiche les sockets UDP	Voir notamment les services UDP configurés
-l	Filtre les sockets en écoute	Éviter les connexions déjà établies
-n	Conserve les numéros bruts	Lire immédiatement les ports
-p	Affiche le processus si autorisé	Trouver le programme responsable

Étape 1 : afficher les sockets en écoute

Ouvrez un terminal sur la machine à diagnostiquer et exécutez sudo ss -tulnp. La colonne d’adresse locale indique où le service écoute. Le résultat attendu est une liste limitée aux sockets prêts à recevoir des connexions, avec le protocole, l’adresse, le port et parfois le processus.

sudo ss -tulnp

Étape 2 : repérer l’adresse et le numéro de port

Recherchez une ligne telle que 0.0.0.0:22, 127.0.0.1:3306 ou [::]:80. Une adresse de bouclage, comme 127.0.0.1, limite l’écoute à la machine. Une adresse générique demande ensuite un contrôle du pare-feu et du réseau.

Étape 3 : relier le port au processus

Observez la dernière colonne lorsque -p a fourni un résultat. Une mention du type users:((“sshd”,pid=...)) indique le nom du service et son identifiant de processus. Le résultat attendu est un lien clair entre un port, un service réseau Linux et sa configuration.

Étape 4 : noter les services non attendus

Comparez les services listés avec les logiciels réellement nécessaires sur la machine. Un serveur de développement local, une base de données ou un agent de supervision peuvent être légitimes. Un processus inconnu doit être identifié avant toute fermeture, car arrêter un service au hasard peut interrompre une application ou un accès distant.

Comment identifier le programme qui utilise un port avec lsof ?

La commande lsof traite les sockets réseau comme des fichiers ouverts et permet d’identifier le programme associé à un port. Pour afficher les ports TCP en écoute, utilisez sudo lsof -nP -iTCP -sTCP:LISTEN ; les options -nP évitent la résolution des noms et conservent les numéros de port lisibles.

La documentation de lsof décrit de nombreux filtres, utiles lorsque la sortie de ss ne suffit pas. L’intérêt de lsof est de passer rapidement du numéro de port au nom concret du programme.

sudo lsof -nP -iTCP -sTCP:LISTEN

Étape 5 : rechercher un port précis

Pour trouver le processus utilisant le port 8080, ciblez directement ce numéro. La commande suivante affiche le programme, son PID et le socket concerné. Le résultat attendu est une ligne qui permet de décider si le service appartient à votre application ou nécessite une vérification.

sudo lsof -nP -iTCP:8080 -sTCP:LISTEN

Étape 6 : vérifier les connexions d’un programme

Après avoir obtenu le nom d’un processus, examinez sa documentation ou son unité de service avant de le modifier. Sur une distribution comme Manjaro, les emplacements, paquets et mécanismes de gestion peuvent différer d’Ubuntu ou Debian ; ce repère sur l’utilisation de Manjaro Linux aide à replacer les commandes dans le fonctionnement général de la distribution.

ss, lsof, netstat, nmap ou nc : quel outil choisir ?

Utilisez ss pour inventorier rapidement les ports en écoute sur la machine, lsof pour identifier un programme, et nmap ou nc pour tester un accès depuis un point donné. Netstat reste utile sur certaines installations, mais il peut être absent des distributions récentes car il appartient au paquet net-tools.

Netstat n’est donc ni une erreur ni le premier choix pour une installation moderne. Si la commande est disponible, sudo netstat -tulnp affiche les ports TCP et UDP en écoute avec les processus. Sur Debian ou Ubuntu, l’installation de net-tools doit être une décision explicite si vous en avez réellement besoin.

• ss : inventaire rapide des sockets en écoute ; choix courant pour le diagnostic local.
• lsof : identification détaillée du programme et de ses fichiers sockets.
• netstat : compatibilité avec des procédures anciennes ou des systèmes où il est déjà installé.
• nmap : observation réseau depuis une machine autorisée.
• nc : test ciblé d’un port précis.

Le bon outil dépend de la question : « quel processus écoute ? » ne demande pas le même test que « ce port répond-il depuis le réseau ? »

Comment tester un port Linux depuis une autre machine ?

Pour savoir si un service est joignable, testez-le depuis une machine placée sur le réseau réellement concerné, avec une autorisation explicite. Un inventaire local avec ss ne traverse ni le pare-feu ni les équipements réseau. Un test distant permet donc de vérifier l’exposition effective, pas seulement l’existence du service.

Un scan doit viser uniquement vos propres machines, vos environnements de test ou des systèmes pour lesquels vous disposez d’un accord clair. Un balayage non autorisé peut être assimilé à une activité intrusive, même si l’objectif paraît limité.

Étape 7 : tester le port 22 depuis un poste autorisé

Depuis une autre machine Linux ayant accès au réseau concerné, utilisez netcat pour tester SSH sur le port 22. Remplacez adresse-du-serveur par une adresse IP ou un nom d’hôte que vous êtes autorisé à contrôler. Le résultat attendu est une indication de succès ou d’échec de connexion TCP.

nc -zv adresse-du-serveur 22

Étape 8 : vérifier toute la plage locale avec nmap

Pour analyser les ports TCP de la machine locale, nmap propose le scan TCP connect suivant. La documentation officielle du projet Nmap précise le rôle des techniques de scan et leurs limites. Cette commande peut prendre du temps car elle couvre l’ensemble de la plage de ports.

sudo nmap -sT -p- localhost

Étape 9 : comparer le résultat local et le résultat réseau

Notez les écarts entre ss et le test distant. Un service peut écouter sur 127.0.0.1 et répondre localement, tout en restant inaccessible ailleurs. Un pare-feu Linux, une règle de routeur ou une politique d’hébergement peut aussi bloquer un port pourtant lié à toutes les interfaces.

Vérifier le pare-feu Linux avant de bloquer un port

Un pare-feu Linux est un ensemble de règles qui autorisent, refusent ou filtrent des flux réseau. Avant de modifier ces règles, identifiez le gestionnaire réellement actif sur votre système : UFW, firewalld ou nftables sont des interfaces et mécanismes courants, mais ils ne s’utilisent pas de façon interchangeable.

Commencez par consulter l’état et les règles, puis documentez le service concerné. Une fermeture brutale du port SSH d’un serveur distant peut couper l’accès d’administration. La règle prudente consiste à vérifier le service, la dépendance applicative et un accès de secours avant toute modification.

• Avec UFW, consultez l’état et les règles configurées avec sudo ufw status verbose.
• Avec firewalld, vérifiez la configuration active avec sudo firewall-cmd --list-all.
• Avec nftables, affichez l’ensemble des règles avec sudo nft list ruleset.

Les syntaxes et politiques par défaut dépendent de la distribution et de son administration. Consultez la documentation de votre distribution et conservez une session locale ou console avant de changer une règle réseau sur une machine distante.

Erreurs fréquentes lors du contrôle des ports ouverts

Le diagnostic des ports ouverts Linux devient trompeur lorsque les niveaux d’analyse sont mélangés. Une sortie locale, un scan réseau et une règle de pare-feu ne répondent pas à la même question. Les erreurs suivantes expliquent une grande part des faux constats.

1. Confondre localhost et réseau externe. Une écoute sur 127.0.0.1 est locale ; vérifiez l’adresse d’écoute avant d’ouvrir ou de fermer une règle de pare-feu.
2. Lire toute ligne comme une faille. Un port en écoute indique un service actif, pas une vulnérabilité démontrée. Vérifiez la version du service, son usage et ses restrictions d’accès.
3. Oublier UDP. Une commande limitée à TCP ne montre pas les sockets UDP. Utilisez l’option -u de ss lorsque votre diagnostic concerne les deux protocoles.
4. Fermer un port sans identifier le service. Le port peut être requis par SSH, une application métier ou une supervision. Recherchez d’abord le processus avec lsof ou ss.
5. Scanner une machine sans autorisation. Testez uniquement les hôtes dont vous assurez l’administration ou pour lesquels vous avez un accord documenté.

Surveiller les changements de ports en écoute

Une vérification ponctuelle détecte l’état présent, mais elle ne montre pas ce qui a changé après une mise à jour ou le démarrage d’un nouveau service. Une surveillance simple peut comparer des sorties successives de ss, à condition de stocker les résultats dans un emplacement protégé et d’examiner les différences avec prudence.

La commande suivante crée un instantané trié des ports en écoute. Le résultat attendu est un fichier texte comparable à un état précédent avec l’outil diff. Cette méthode ne remplace pas la journalisation système ni une supervision de sécurité, mais elle fournit un repère utile sur une machine administrée.

sudo ss -tulnp | sort > ports-ecoute-actuels.txt
diff -u ports-ecoute-precedents.txt ports-ecoute-actuels.txt

Avant d’automatiser cette tâche, vérifiez que les fichiers ne divulguent pas des informations sensibles sur les services installés. Les principes de prudence utilisés pour vérifier une information en ligne s’appliquent aussi ici : observer, recouper et ne pas tirer de conclusion à partir d’un seul signal.

Vérifier puis réduire l’exposition réseau

La démarche la plus fiable consiste à lister les ports en écoute avec ss, identifier les programmes avec lsof, puis tester seulement les accès nécessaires depuis un emplacement autorisé. Chaque résultat doit être interprété avec son adresse d’écoute, le protocole concerné et les règles de filtrage en vigueur.

Réduire l’exposition réseau ne signifie pas fermer tous les ports. La bonne cible est de conserver les services nécessaires, à jour et limités aux réseaux ou interfaces qui en ont besoin. Un inventaire régulier rend cette décision plus factuelle.

Questions fréquentes sur les ports ouverts Linux

Comment vérifier si le port 22 est ouvert sous Linux ?

Sur la machine concernée, utilisez sudo ss -tulnp et recherchez le port 22 dans la colonne d’adresse locale. Depuis une machine autorisée, nc -zv adresse-du-serveur 22 teste la connexion TCP. Les deux vérifications répondent à des questions différentes : écoute locale et joignabilité réseau.

Quelle commande utiliser à la place de netstat sous Linux ?

La commande ss est généralement l’alternative à utiliser : sudo ss -tulnp liste les sockets TCP et UDP en écoute avec les processus disponibles. Netstat peut rester présent sur certains systèmes, mais il dépend souvent du paquet net-tools.

Pourquoi un port est-il ouvert localement mais fermé depuis Internet ?

Un service peut écouter uniquement sur 127.0.0.1, ce qui limite les connexions à la machine elle-même. Une règle de pare-feu, un routeur, une politique cloud ou un réseau privé peut aussi bloquer l’accès extérieur à un service qui écoute sur une interface réseau.

Comment fermer un port ouvert sous Linux ?

Un port se ferme généralement en arrêtant, désactivant ou reconfigurant le service qui écoute dessus, puis en adaptant le pare-feu si nécessaire. Identifiez d’abord le processus avec lsof ou ss, car bloquer un port sans connaître son rôle peut interrompre un service indispensable.

Un port ouvert signifie-t-il que la machine Linux est piratée ?

Non. Un port ouvert ou en écoute indique qu’un programme attend potentiellement des connexions sur une adresse donnée. Le contrôle pertinent porte sur l’identité du programme, sa configuration, ses mises à jour, les comptes autorisés et les règles réseau qui encadrent son accès.