Check Ports Linux : Commandes et Astuces

La plupart des tutoriels sur la vérification des ports Linux se limitent à deux ou trois commandes de base. Voici les astuces moins connues que j’utilise réellement, au-delà de ss et netstat, quand un audit express doit aller vite chez un client — souvent en pleine urgence, un incident en cours, pas dans le confort d’un audit planifié.

Pourquoi je garde ces astuces sous la main

Lors d’un incident de production, je n’ai souvent que quelques minutes pour comprendre si un service inattendu écoute quelque part avant qu’il ne devienne le suspect numéro un. Ces commandes et astuces me font gagner un temps précieux, en particulier quand l’accès au serveur est limité ou que les outils habituels ne sont pas installés.

Les commandes et astuces moins connues

lsof -i :PORT — au lieu de lister toutes les connexions, cette syntaxe cible un port précis directement. Utile quand on soupçonne déjà un port spécifique et qu’on veut confirmer en une seule commande quel processus l’occupe
fuser PORT/tcp — retourne directement le PID du processus qui occupe un port TCP donné, plus rapide à lire que la sortie complète de lsof quand on veut juste tuer le bon processus
ss -tlnp — l’ajout du p à la combinaison habituelle affiche directement le nom du processus et son PID, évitant une commande supplémentaire pour croiser l’information
/proc/net/tcp et /proc/net/tcp6 — pour les environnements minimalistes où aucun des outils ci-dessus n’est installé (certains conteneurs Docker allégés, par exemple), ces fichiers virtuels du noyau listent les connexions actives dans un format hexadécimal moins lisible, mais toujours accessible sans dépendance externe
nc -zv host port — teste la connectivité vers un port distant sans établir de session complète, particulièrement utile pour vérifier depuis un serveur si un port sur une autre machine du réseau interne répond, avant de suspecter un pare-feu
nmap -p 80,443,22,3306 votre_ip — un scan ciblé sur une liste précise de ports, bien plus rapide qu’un scan complet quand on veut juste confirmer l’état de quelques ports critiques (web, SSH, base de données)

L’astuce que peu de gens connaissent : Docker et les ports masqués

Un piège récurrent que je rencontre chez des clients utilisant des conteneurs Docker : la commande ss -tuln exécutée sur l’hôte ne montre pas toujours les ports internes utilisés par les conteneurs entre eux, seulement ceux explicitement publiés vers l’hôte. Pour une vue complète, je combine systématiquement ss -tuln côté hôte avec docker ps et docker port <conteneur>, qui révèlent le mappage réel entre ports internes et ports exposés. J’ai vu un service de debug laissé actif à l’intérieur d’un conteneur, invisible depuis l’hôte, mais accessible depuis d’autres conteneurs du même réseau Docker interne — une faille discrète qu’aucune des commandes système classiques ne révèle seule.

Astuce express pour repérer un port suspect nouvellement ouvert

Quand je soupçonne qu’un service a été ouvert récemment sans autorisation, je compare la sortie de ss -tuln avec l’historique des modifications système via journalctl --since "1 hour ago" | grep -i listen, qui remonte souvent les messages de démarrage de service mentionnant explicitement le port utilisé. Cette astuce m’a permis, chez un client, d’identifier en quelques minutes qu’un service de monitoring tiers, installé par erreur lors d’un test, avait ouvert un port resté actif après la fin du test.

Ne pas confondre port ouvert et port éphémère

Une confusion fréquente, même chez des profils techniques expérimentés : la plage des ports éphémères (généralement de 32768 à 60999 sur les distributions Linux modernes, configurable via /proc/sys/net/ipv4/ip_local_port_range) est utilisée automatiquement par le système pour les connexions sortantes temporaires — une requête vers une API externe, par exemple. Voir un port dans cette plage apparaître dans ss -tuln avec un état autre que LISTEN ne signifie pas qu’un service y écoute en permanence, mais qu’une connexion sortante est simplement en cours. Confondre les deux fait perdre un temps précieux à investiguer un « port ouvert » qui n’est en réalité qu’une connexion sortante normale et temporaire.

Pour couper court à cette confusion pendant un audit express, je filtre systématiquement sur l’état exact de la connexion avec ss -tuln state listening, qui n’affiche que les ports réellement en écoute permanente — la seule catégorie pertinente quand on cherche un service potentiellement exposé par erreur.

Checklist express en cas d’incident

Lancer ss -tlnp pour obtenir en une commande la liste des ports en écoute et leur processus associé
Si le serveur utilise Docker, croiser immédiatement avec docker ps et docker port
Utiliser fuser PORT/tcp pour confirmer rapidement le PID avant toute action (redémarrage, arrêt du service)
Vérifier l’historique récent avec journalctl --since "1 hour ago" pour situer le moment exact d’ouverture du port suspect

Le mythe à nuancer

On croit souvent qu’il suffit d’une seule commande « magique » pour avoir une vue complète des ports d’un serveur. En réalité, chaque commande a un angle mort — ss ne voit pas toujours l’intérieur des conteneurs, nmap depuis l’extérieur peut être filtré par un pare-feu qui masque un port réellement ouvert en interne, et lsof nécessite parfois des droits élevés pour afficher l’intégralité des informations. Je combine systématiquement au moins deux de ces outils avant de conclure qu’un port est fermé ou inutilisé.

Pour aller plus loin : consultez le guide complet d’audit des ports et l’analyse de logs pour aller plus loin.

Quelle est la dernière fois que vous avez vérifié les ports ouverts à l’intérieur de vos conteneurs, et pas seulement ceux visibles depuis l’hôte ? C’est souvent cet angle mort précis, entre l’hôte et le conteneur, qui sépare un audit de surface d’un audit qui trouve réellement le problème.