La surveillance des ports consiste à se connecter régulièrement à un hôte et à un port précis, par exemple db01:5432, pour confirmer qu’un service accepte réellement les connexions. Elle se situe entre le ping et les vérifications HTTP et répond à une seule question : le processus est-il à l’écoute, joignable par le chemin réseau et capable d’accepter les connexions assez vite ? C’est essentiel pour la fiabilité du réseau, car de nombreuses pannes surviennent alors que l’hôte est toujours en ligne, et seule une vérification au niveau du port les repère.
Comment fonctionne une vérification de port
Une vérification de port TCP ouvre une connexion comme le ferait un client : SYN, SYN-ACK, ACK, puis fermeture. Le résultat correspond à l’un de ces trois états :
- Open : la poignée de main TCP a abouti ; un service est à l’écoute et joignable.
- Closed : l’hôte a répondu par un reset (RST) ; il est joignable, mais rien n’est lié à ce port.
- Filtered : aucune réponse n’est arrivée avant le timeout, généralement parce qu’un pare-feu, un security group ou une ACL a supprimé le paquet sans le signaler.
UDP n’a pas de poignée de main : la vérification envoie donc un datagramme de sonde et considère une réponse valide comme un succès. Un message ICMP « port unreachable » signifie que le port est fermé, tandis que l’absence de réponse reste ambiguë. Les vérifications UDP fonctionnent donc mieux avec une charge utile propre au protocole, comme une vraie requête DNS vers le port 53.
Le temps de connexion compte aussi : une poignée de main qui passe de 20 ms à 800 ms est un signal d’alerte précoce, même si le port est toujours signalé comme ouvert.
La place de la surveillance des ports entre ping et HTTP
Considérez les trois types de vérification comme des couches : hôte, service, application.
| Vérification | Question à laquelle elle répond | Angle mort typique |
|---|---|---|
| Ping (ICMP) | L’hôte est-il joignable sur le réseau ? | Service planté alors que l’OS continue de répondre |
| Port (TCP/UDP) | Ce service accepte-t-il les connexions ? | L’application renvoie des erreurs après la connexion |
| HTTP/HTTPS | L’application renvoie-t-elle la bonne réponse ? | Services non HTTP comme les bases de données, SMTP ou MQTT |
Pour les services qui ne parlent pas HTTP, comme PostgreSQL, Redis, SMTP, SSH ou RabbitMQ, la vérification de port est souvent le signal de disponibilité externe le plus direct.
Les défaillances que la surveillance des ports détecte
Ces incidents échappent au ping et n’apparaissent qu’au niveau du port :
- Service planté, hôte toujours en ligne. La base de données a été tuée par l’OOM killer, mais le noyau répond toujours au ping. Le port passe à « closed » en un seul intervalle.
- Modification du pare-feu ou d’un security group. Un changement d’infrastructure as code bloque le trafic vers le port 5432. L’hôte reste joignable par ping, le port devient « filtered ».
- Listener lié à la mauvaise interface. Le service écoute sur
127.0.0.1au lieu de0.0.0.0. Tout semble sain en local, mais les vérifications distantes voient le port fermé. - Accept lent ou épuisement des ports. Un backlog d’accept plein, une accumulation de connexions en TIME_WAIT ou un pool saturé bloquent les poignées de main. La hausse du temps de connexion est souvent le premier symptôme.
- Services inattendus. Un port censé être fermé, comme une interface de debug, apparaît soudain ouvert : c’est à la fois un problème de fiabilité et de sécurité.
Ce que la surveillance des ports ne détecte pas
Un port ouvert ne prouve pas qu’un service est en bonne santé. Un serveur web peut accepter les connexions et renvoyer des erreurs 500, une base de données peut accepter les connexions et rejeter les requêtes parce que le disque est plein, et un listener TLS peut présenter un certificat expiré. Les vérifications de port ne disent rien non plus des requêtes lentes ni de l’exactitude des données. Associez-les à des vérifications HTTP, API et SSL pour les couches supérieures, et au ping pour le réseau en dessous.
Conseils pratiques de configuration
- Surveillez chaque port de service accessible depuis l’extérieur, ainsi que les ports internes dont dépendent les chemins critiques.
- Utilisez des intervalles de 30 à 60 secondes pour les services de production ; 1 à 5 minutes suffisent généralement pour les systèmes moins critiques.
- Fixez des timeouts d’environ 5 à 10 secondes et alertez lorsque le temps de connexion dépasse nettement la baseline, pas seulement en cas d’échec.
- Confirmez les échecs depuis plusieurs emplacements avant d’alerter, afin qu’un seul chemin réseau défaillant ne déclenche pas de fausse alerte.
- Tenez à jour une baseline des ports qui doivent être ouverts ou fermés, et alertez sur les écarts dans les deux sens.
La surveillance des ports UpScanX propose des vérifications TCP et UDP, l’identification des services (fingerprinting) avec détection de version, la validation des réponses spécifique à chaque protocole et le suivi du temps de connexion depuis plus de 15 emplacements dans le monde. UpScanX compare également l’état des ports à votre baseline de configuration pour signaler les services inattendus, et envoie des alertes par Email, Slack, Telegram, Microsoft Teams ou Webhook. Pour aller plus loin, consultez comment fonctionne la surveillance des ports.
Points clés
- La surveillance des ports vérifie qu’un service précis accepte les connexions, et pas seulement que l’hôte est joignable.
- Elle détecte les processus plantés, les changements de pare-feu, les mauvaises adresses d’écoute et la saturation des connexions que le ping ne voit pas.
- Les états « open », « closed » et « filtered » orientent vers des causes différentes, ce qui accélère le diagnostic.
- Elle ne valide pas le comportement de l’application : combinez-la avec des vérifications ping, HTTP et SSL pour une couverture complète.