La surveillance des ports consiste à vérifier en permanence si des ports réseau spécifiques sur les serveurs sont ouverts, acceptent les connexions et répondent correctement. Il fonctionne au niveau TCP/UDP couche 4, indépendamment des protocoles au niveau de l'application, ce qui le rend essentiel pour surveiller les services d'infrastructure que les contrôles HTTP ne peuvent pas atteindre : bases de données, caches, files d'attente de messages, serveurs de messagerie et protocoles d'application personnalisés. Lorsqu'un port critique tombe en panne, toutes les applications qui dépendent de ce service échouent. La surveillance des ports détecte ces pannes en quelques secondes, souvent avant l'apparition de symptômes destinés à l'utilisateur.
Pourquoi la surveillance des ports est importante
Les services d'infrastructure sont invisibles pour la surveillance HTTP
Les contrôles de disponibilité HTTP vérifient que les serveurs Web répondent, mais les applications de production dépendent de dizaines de services backend qui ne servent jamais le trafic HTTP. Une base de données PostgreSQL sur le port 5432, un cache Redis sur le port 6379 ou un courtier RabbitMQ sur le port 5672 peuvent échouer silencieusement pendant que le serveur Web continue d'accepter les demandes – renvoyant des erreurs, des données obsolètes ou des réponses vides. La surveillance des ports détecte ces pannes cachées.
Les pannes de service peuvent être silencieuses
Un processus de service peut planter sans déclencher d’alerte au niveau du système d’exploitation. Le serveur continue de fonctionner, le réseau reste opérationnel, mais le port cesse d'accepter les connexions. Sans surveillance des ports, ces pannes silencieuses ne sont découvertes que lorsque les applications dépendantes commencent à échouer et que les utilisateurs signalent des problèmes.
La posture de sécurité nécessite une visibilité sur le port
Les ports ouverts non autorisés représentent des vulnérabilités de sécurité. Un port qui ne devrait pas être accessible depuis Internet (que ce soit à partir d'un pare-feu mal configuré, d'un démarrage involontaire d'un service ou d'un système compromis) crée une surface d'attaque. Une surveillance régulière des ports détecte ces expositions.
Ports critiques à surveiller
Serveurs de bases de données
- PostgreSQL : 5432 -MySQL/MariaDB : 3306 -MongoDB : 27017 -Redis : 6379
- Memcached : 11211
- Recherche élastique : 9 200
L'indisponibilité de la base de données est la cause la plus courante d'erreurs d'application. Surveillez les ports principaux et de réplique.
Serveurs Web et d'applications
- HTTP : 80 -HTTPS : 443
- Serveurs d'applications : 8080, 8443, 3000, 5000
Ces ports doivent toujours être surveillés parallèlement aux vérifications de contenu HTTP pour une couverture complète.
Courtiers de messages et files d'attente
- RabbitMQ : 5672 (AMQP), 15672 (gestion) -Kafka : 9092
- NATS : 4222
Les échecs de file d'attente entraînent des retards de traitement, des messages perdus et des erreurs d'application en cascade.
Autres services critiques
-SSH : 22 -SMTP : 25 587
- IMAP : 993 -DNS : 53
- FTP : 21
Meilleures pratiques pour la surveillance des ports
Classez vos services par criticité
Tous les services ne méritent pas la même intensité de surveillance. Classez les services en niveaux :
- Tier 1 (Critique) : Bases de données de production, passerelles de paiement, services d'authentification. Vérifiez toutes les 15 à 30 secondes avec une alerte immédiate.
- Niveau 2 (Important) : Serveurs d'applications, caches, courtiers de messages. Vérifiez toutes les 30 à 60 secondes.
- Niveau 3 (Support) : Outils internes, environnements de développement, infrastructure de surveillance. Vérifiez toutes les 2 à 5 minutes.
Définir des valeurs de délai d'attente appropriées
Utilisez des valeurs de délai d'attente de 5 à 10 secondes pour les tentatives de connexion TCP. Des délais d'attente plus courts génèrent des faux positifs sur les serveurs occupés ; des délais d'attente plus longs retardent la détection des pannes. Faites correspondre les délais d'attente au temps d'établissement de connexion prévu pour chaque type de service.
Combinez les vérifications TCP avec les vérifications de l'état des applications
Un port acceptant les connexions TCP ne signifie pas que le service est sain. Une base de données peut accepter les connexions mais rejeter les requêtes en raison de l'épuisement de l'espace disque. Utilisez la surveillance des ports comme contrôle de premier niveau et superposez la validation de l’état spécifique à l’application pour une couverture complète.
Surveiller le nombre et les modèles de connexion
Suivez non seulement si un port est ouvert, mais aussi la rapidité avec laquelle les connexions sont établies. L'augmentation des délais d'établissement de connexion précède souvent des pannes complètes de service. Surveillez l'utilisation du pool de connexions pour les serveurs de base de données afin de détecter les contraintes de capacité avant qu'elles ne provoquent des erreurs de refus de connexion.
Alerte sur les seuils basés sur un pourcentage
Au lieu d'alerter sur une seule tentative de connexion échouée, utilisez des seuils basés sur un pourcentage sur des fenêtres temporelles. Par exemple : alerte lorsque plus de 20 % des tentatives de connexion échouent sur une fenêtre de 2 minutes. Cela réduit les faux positifs dus à des problèmes de réseau transitoires.
Erreurs courantes à éviter
Surveillance uniquement des ports Web
Les contrôles HTTP/HTTPS ne couvrent que la pointe de l’iceberg de l’infrastructure. Les bases de données, les caches, les files d’attente et les services internes disposent tous de ports qui doivent être surveillés. Mappez les dépendances de votre application et assurez-vous que chaque port critique est couvert.
Ignorer les services UDP
La surveillance UDP est plus difficile que TCP car UDP est sans connexion : il n'y a pas de prise de contact à confirmer. Mais DNS (port 53), DHCP, Syslog et les serveurs de jeux utilisent tous UDP. Utilisez des sondes spécifiques au protocole qui envoient les paquets attendus et valident les réponses.
Pas de surveillance depuis l'extérieur du réseau
La surveillance des ports internes confirme que les services sont en cours d'exécution, mais la surveillance externe vérifie que les règles de pare-feu et les configurations réseau sont correctes. Un port peut être ouvert sur le serveur mais bloqué par un groupe de sécurité. Surveiller du point de vue interne et externe.
Oublier les infrastructures éphémères
La mise à l'échelle automatique du cloud, l'orchestration de conteneurs et les fonctions sans serveur créent et détruisent en permanence des instances de service. La surveillance des ports doit suivre l'infrastructure dynamique, en mettant à jour les cibles à mesure que les instances augmentent ou diminuent.
Cas d'utilisation
Infrastructure de base de données
Surveillez chaque port de base de données de votre cluster de production : instances principales, réplicas et basculement. Détectez le retard de réplication en surveillant les ports de réplique ainsi que la disponibilité principale.
Kubernetes et environnements de conteneurs
Les services de conteneur exposent les ports de manière dynamique. Surveillez les points de terminaison au niveau du service plutôt que les ports de conteneurs individuels pour savoir si le maillage de services Kubernetes achemine correctement le trafic.
Audit de sécurité du réseau
L'analyse régulière des ports détecte les services non autorisés, vérifie que les services mis hors service sont correctement arrêtés et confirme que les règles de pare-feu correspondent à la politique de sécurité. Comparez les états du port actuels à une référence approuvée.
Surveillance de la conformité
PCI DSS, SOC 2 et d'autres frameworks nécessitent de démontrer que seuls les ports autorisés sont accessibles. La surveillance des ports fournit des preuves de conformité continues plutôt que des instantanés d'audit à un moment précis.
Comment UpScanX gère la surveillance des ports
UpScanX surveille les ports TCP et UDP à partir de plus de 15 emplacements dans le monde avec des intervalles de vérification et des valeurs de délai d'attente configurables. Chaque vérification valide l'établissement de la connexion, mesure la latence de connexion et enregistre le comportement de réponse du service. La plate-forme prend en charge la surveillance de n'importe quel port sur n'importe quel hôte, avec une configuration d'alerte basée sur le niveau de service.
Lorsqu'un port surveillé devient inaccessible, les alertes sont confirmées à partir de plusieurs emplacements et envoyées par e-mail, SMS, Slack, Discord, Teams, PagerDuty et webhooks personnalisés. Les tableaux de bord historiques affichent les tendances de disponibilité des ports, les modèles de latence de connexion et la chronologie des incidents. Combiné à la surveillance de la disponibilité, du ping et des API, UpScanX offre une visibilité complète de l'infrastructure.
Liste de contrôle de surveillance des ports
Si vous créez une configuration de surveillance de niveau production, commencez par un inventaire des dépendances. Répertoriez chaque base de données, cache, courtier, API interne, hôte bastion et service d'infrastructure dont dépend votre application. Mappez ensuite ces services aux ports qui doivent être accessibles pour que la plate-forme fonctionne normalement. Cet exercice simple révèle généralement rapidement les angles morts.
Ensuite, séparez les ports par niveau de risque. Les ports destinés au public doivent être surveillés à la fois pour leur disponibilité et pour toute exposition inattendue. Les ports internes uniquement doivent être vérifiés sur les réseaux de confiance et validés par rapport à la politique de pare-feu. Pour les ports de base de données et de courtier, surveillez à la fois la connectivité et le temps de connexion afin de pouvoir détecter la dégradation avant une panne complète. Pour les services basés sur UDP, utilisez autant que possible des sondes prenant en charge le protocole au lieu d'hypothèses d'accessibilité génériques.
Enfin, connectez la surveillance aux opérations. Chaque alerte portuaire doit indiquer aux intervenants quel service se trouve derrière le port, quelle capacité commerciale est affectée, si le problème est régional ou mondial et à quoi ressemblait le dernier état de santé connu. La surveillance des ports devient considérablement plus utile lorsqu'elle est liée à la propriété, à la gravité et à un chemin de remédiation clair.
Pour les équipes cloud en évolution rapide, cela signifie également que la surveillance reste alignée sur l'infrastructure en tant que code. Lorsque de nouveaux services sont déployés ou que d'anciens ports sont retirés, l'inventaire de surveillance doit évoluer avec eux afin que la couverture reste précise.
Cette discipline permet de garantir une surveillance fiable, ce qui fait la différence entre une estimation réactive et une réponse rapide et fiable aux incidents.
Il améliore également l’auditabilité lors des examens de sécurité et des analyses post-incident.
Commencez à surveiller vos ports critiques avec UpScanX – plan gratuit disponible.