Comment surveiller un port TCP (et quand alerter en cas d'ouverture)

La surveillance de port, c'est deux tâches en une. Parfois, vous voulez savoir qu'un service est en écoute, comme une base de données ou un relais SMTP. Parfois, vous voulez savoir qu'un port reste bloqué par le pare-feu, comme SSH sur une instance exposée à Internet. La même sonde répond aux deux questions, mais vous alertez sur des résultats opposés. Ce guide couvre quand utiliser chaque mode, sur quoi alerter, et les ports qui prennent les gens au dépourvu.

Comment fonctionne réellement un moniteur de port TCP

Un moniteur de port TCP ouvre un socket vers la cible sur le port choisi et attend que la poignée de main en trois étapes s'achève. Si la poignée de main réussit, le port est ouvert. Si la connexion est refusée, le port est fermé. Si la connexion expire, quelque chose entre la sonde et votre hôte rejette le paquet, généralement un pare-feu.

La sonde ne parle pas de protocole au-dessus du socket. Elle ne négocie pas TLS, n'échange pas de bannières SSH et n'exécute pas de requête de base de données. Elle vous indique seulement si le port répond. Pour la santé de la couche applicative, vous avez besoin d'un HTTP ou d'une vérification personnalisée en plus.

Quand vous voulez que le port soit OUVERT

Utilisez la surveillance de port comme sonde de santé de service lorsque vous ne pouvez pas facilement effectuer une vérification HTTP. Cinq cas courants se présentent.

• Serveurs de base de données sur le port 5432 (Postgres), 3306 (MySQL), 6379 (Redis), 27017 (MongoDB). Si l'écouteur plante, tous les services dépendants tombent en panne, mais vous ne pouvez pas exécuter une sonde HTTP.
• Relais SMTP sur le port 25 ou 587. Les vérifications de bannière SMTP détectent les plantages d'écouteur que les points de terminaison de santé internes manquent.
• Serveurs de jeu et autres protocoles TCP personnalisés qui ne parlent pas HTTP.
• Équilibreurs de charge internes qui exposent un port de santé non-HTTP aux services en amont.
• Points de terminaison VPN sur des ports UDP-mais-aussi-TCP comme 443 pour OpenVPN-TCP et WireGuard.

Quand vous voulez que le port soit FERMÉ

La surveillance de port inversée est un garde-fou de sécurité. Vous configurez le moniteur pour alerter lorsque le port devient ouvert, car il ne devrait jamais être ouvert depuis l'internet public. Ce schéma détecte les choses qui tournent mal pendant une semaine normale de changements d'infrastructure.

Quelqu'un ouvre temporairement une règle de pare-feu pour déboguer et oublie de revenir en arrière. Un service Kubernetes obtient un type LoadBalancer par accident. Une nouvelle instance reçoit le mauvais groupe de sécurité. Une modification d'un module Terraform expose un port qui devait être interne. Dans chaque cas, le moniteur de port inversé détecte l'exposition en un seul intervalle de vérification.

Les ports à haute valeur à surveiller en mode inversé dès maintenant

Cinq ports valent la peine de mettre en place une vérification inversée pour tout hôte exposé à Internet qui ne devrait pas les exposer.

• 22 (SSH) sur les serveurs d'applications de production. L'accès uniquement par bastion est la norme, et un port SSH accidentellement ouvert apparaît dans les journaux de scan de masse en quelques heures.
• 3306 (MySQL) et 5432 (Postgres). Les ports de base de données publics sont responsables d'une part importante des attaques par bourrage d'identifiants.
• 6379 (Redis). Redis ouvert sans authentification est l'une des configurations les plus exploitées du secteur.
• 27017 (MongoDB). Même histoire que Redis. Configuration par défaut, sans authentification, port public égale perte de données.
• 9200 (Elasticsearch). Les clusters ouverts sont scrapés, minés et rançonnés en quelques heures.

Seuils d'alerte pour la surveillance de port

La santé de service (le port doit être OUVERT) requiert le même schéma de seuil que HTTP : alerter après 3 échecs consécutifs, supprimer les courts battements. Les microcoupures réseau qui ferment une seule sonde sont du bruit.

La sécurité (le port doit être FERMÉ) demande l'inverse. Alertez à la première détection. Un port SSH ou Redis accidentellement ouvert est un événement à cinq alarmes. Les bots scannent l'internet public en permanence, et la fenêtre entre l'exposition et la compromission sur un port bien connu se mesure en minutes.

Une liste de contrôle de surveillance de port de sécurité pour débuter

Pour chaque IP exposée à Internet exploitée par votre équipe, configurez des moniteurs inversés sur 22, 3306, 5432, 6379 et 27017 à un intervalle de 60 secondes. Acheminez les alertes vers votre canal de sécurité séparément de vos alertes de santé de service. Une fois par trimestre, effectuez un véritable scan de port sur vos propres IP comme contrôle. Le coût est faible, la couverture est large, et les modes de défaillance qu'il détecte sont catastrophiques.