J’ai testé encore cette approche la semaine dernière, et voici ce que j’ai appris : avant de conclure un audit de sécurité périphérique pour un client, je vérifie systématiquement quels ports sont réellement ouverts sur son serveur — pas ceux que la documentation prétend ouverts, mais ceux qui répondent réellement. L’écart entre les deux est plus fréquent qu’on ne le pense.
Pourquoi un audit SEO technique inclut la vérification des ports
Un serveur mal configuré, exposant des ports qui ne devraient pas l’être, n’est pas qu’un risque de sécurité — c’est aussi souvent le symptôme d’une infrastructure mal documentée, la même infrastructure qui explique des incohérences de cache, des redirections mal posées, ou des services fantômes qui ralentissent le serveur. Je considère la vérification des ports ouverts comme la première étape de tout audit d’infrastructure, avant même de m’intéresser au contenu du site.
Guide complet, commande par commande
ss -tuln— la commande moderne recommandée sur la majorité des distributions Linux récentes, remplaçant progressivementnetstat. L’option-tfiltre TCP,-ufiltre UDP,-ln’affiche que les ports en écoute,-névite la résolution DNS qui ralentit l’affichagenetstat -tuln— l’équivalent historique, toujours présent sur de nombreux serveurs plus anciens, avec exactement la même logique d’optionsnmap -sT -p- localhost— scanne l’intégralité des 65535 ports depuis le serveur lui-même, utile pour confirmer ce qui est réellement accessible en TCP, avec l’option-p-couvrant tous les ports plutôt que les seuls ports courantslsof -i -P -n— liste chaque connexion réseau active avec le processus exact qui l’a ouverte, la commande la plus utile pour identifier quel service écoute sur un port suspectufw status verbose(oufirewall-cmd --list-allselon la distribution) — affiche les règles de pare-feu actives, à croiser systématiquement avec les ports réellement ouverts détectés parssounmap
Le cas concret qui illustre l’utilité de cette vérification
Chez un client dont le serveur hébergeait plusieurs sites WordPress, j’ai découvert via ss -tuln un port ouvert sur une interface accessible publiquement, correspondant à une instance Redis installée par une agence précédente pour un projet abandonné depuis longtemps, sans authentification configurée. N’importe qui connaissant l’adresse IP et le port aurait pu se connecter directement à cette instance et lire ou modifier les données en cache — un risque de sécurité concret, resté invisible pendant des mois parce que personne n’avait audité les ports ouverts après la fin du projet qui l’avait justifiée.
Checklist d’audit des ports, à exécuter régulièrement
- Lister tous les ports en écoute avec
ss -tuln, et identifier le processus associé à chacun aveclsof -i -P -n - Comparer cette liste aux règles de pare-feu actives — tout port en écoute qui ne correspond à aucune règle explicite doit être investigué
- Fermer ou restreindre à l’interface locale (
127.0.0.1) tout service qui n’a pas besoin d’être exposé publiquement (bases de données, caches applicatifs, interfaces d’administration) - Documenter chaque port ouvert intentionnellement, avec sa justification et le service concerné, dans un registre versionné
- Refaire cette vérification après chaque projet ou test technique temporaire, pas seulement lors d’un audit annuel
Automatiser la surveillance plutôt que la refaire manuellement
Après cette découverte chez ce client, j’ai mis en place un script simple exécuté quotidiennement via une tâche cron, qui capture la sortie de ss -tuln et la compare à une liste de référence validée des ports attendus. Toute divergence — un nouveau port apparu, un port de référence disparu — envoie une alerte par e-mail à l’équipe technique. Ce n’est pas une solution de sécurité périmétrique sophistiquée, mais un filet de sécurité à faible coût qui aurait détecté l’instance Redis oubliée dès le lendemain de son installation, plutôt que des mois plus tard.
J’ai testé trois approches différentes avant de trouver celle qui fonctionnait sans faux positifs : une comparaison stricte ligne par ligne échouait dès qu’un port éphémère de connexion sortante apparaissait dans la liste ; j’ai donc restreint la comparaison aux seuls ports en état LISTEN, ce qui élimine le bruit des connexions sortantes temporaires et ne laisse que les services qui écoutent réellement des connexions entrantes.
Le cas des ports au-dessus de 1024
Un point que beaucoup négligent : les ports privilégiés (en dessous de 1024) ne sont pas les seuls à surveiller. La grande majorité des services applicatifs modernes — bases de données, caches, interfaces de monitoring, outils de développement laissés actifs par erreur — écoutent sur des ports non privilégiés, largement au-dessus de 1024, précisément parce qu’ils ne nécessitent pas les droits root pour être lancés. Un audit de ports qui ne couvre que la plage 1 à 1024 passera systématiquement à côté de ce type de service exposé par inadvertance, comme cela a été le cas pour l’instance Redis mentionnée plus haut, qui écoutait sur son port par défaut, 6379.
Le mythe à corriger
La plupart des équipes pensent que « le pare-feu du fournisseur cloud suffit à protéger le serveur ». En réalité, un pare-feu cloud filtre le trafic entrant au niveau du réseau, mais il ne dit rien de ce qui écoute réellement sur le serveur lui-même — un service mal configuré peut rester accessible depuis d’autres machines du même réseau interne, ou depuis une interface que le pare-feu cloud ne couvre pas. La vérification côté serveur, avec les commandes ci-dessus, reste indispensable en complément, jamais en remplacement.
Pour aller plus loin : consultez ces astuces complémentaires et la gestion des groupes utilisateurs.
Avez-vous déjà comparé la liste des ports réellement ouverts sur votre serveur à ce que votre pare-feu est censé autoriser ?