Commencez par les ports que vos clients utilisent directement : HTTPS sur 443, la redirection sur 80, les ports de la passerelle API, ainsi que DNS ou SMTP si vous les hébergez vous-même. Couvrez ensuite les dépendances internes capables de faire tomber toute la pile, comme les bases de données, les caches et les files de messages. Enfin, surveillez les ports d'administration tels que SSH, RDP et l'API Docker pour vérifier qu'ils ne sont pas accessibles depuis Internet.
Classer les ports par impact, pas par numéro
Surveiller tous les services en écoute en même temps génère des alertes bruyantes et aucune responsabilité claire. Évaluez plutôt chaque port selon trois questions avant d'ajouter un contrôle :
- Impact client et chiffre d'affaires. Si ce port ne répond plus, les utilisateurs voient-ils des erreurs, le paiement échoue-t-il, les clients API expirent-ils ?
- Point de défaillance unique. Y a-t-il une seule base de données principale, un seul broker ou un seul load balancer derrière, ou le trafic bascule-t-il automatiquement ?
- Risque d'exposition. Si ce port devenait accessible depuis l'Internet public, s'agirait-il d'un incident de sécurité ?
Un score élevé aux deux premières questions place un port dans un niveau de disponibilité. Un score élevé à la troisième le place dans un niveau d'exposition, où « ouvert » est la condition d'alerte.
Niveau 1 : les points d'entrée publics
Créez ces contrôles en premier, généralement à des intervalles de 30 à 60 secondes depuis plusieurs régions :
- 443 (HTTPS) : votre porte d'entrée principale. Validez la négociation TLS, pas seulement la connexion TCP.
- 80 (HTTP) : doit répondre par une redirection vers 443. Une redirection cassée laisse en plan les utilisateurs arrivant par d'anciens liens.
- Ports de la passerelle API (par exemple 8443 ou un port gRPC dédié) que les partenaires ou les applications mobiles appellent directement.
- 53 en TCP et UDP, si vous hébergez votre propre DNS faisant autorité. UDP transporte la plupart des requêtes, tandis que TCP gère les réponses volumineuses et les transferts de zone : contrôlez donc les deux.
- 25, 465 ou 587, si vous envoyez des e-mails transactionnels depuis vos propres relais. Si SMTP tombe en silence, les réinitialisations de mot de passe et les factures n'arrivent plus.
Les contrôles multi-sites sont essentiels, car une modification de pare-feu ou de CDN peut laisser un port ouvert dans une région et filtré dans une autre.
Niveau 2 : les dépendances internes
Ces services ne doivent pas être publics : contrôlez-les depuis l'intérieur du réseau ou depuis une IP de supervision explicitement autorisée dans votre pare-feu :
- 5432 (PostgreSQL) et 3306 (MySQL) : les points de terminaison principaux comme les réplicas.
- 6379 (Redis) : les caches tombent souvent sans bruit, puis surchargent la base de données qui se trouve derrière.
- 5672 (RabbitMQ) et 9092 (Kafka) : un broker bloqué retarde toutes les tâches asynchrones.
- Les listeners des load balancers internes placés devant les différentes couches de services.
Suivez le temps de connexion en plus du statut disponible/indisponible. Un port de base de données qui met 800 ms à accepter une connexion au lieu de 5 ms signale souvent un pool de connexions saturé ou un hôte surchargé.
Niveau 3 : les ports qui doivent rester fermés
Le dernier niveau inverse la logique : vous déclenchez une alerte lorsque ces ports sont accessibles depuis l'Internet public.
| Port | Service | Pourquoi l'exposition publique est risquée |
|---|---|---|
| 22 | SSH | Cible permanente d'attaques par force brute et de credential stuffing |
| 3389 | RDP | Point d'entrée fréquent des rançongiciels |
| 2375 / 2376 | API Docker | 2375 n'est pas authentifié et donne le contrôle de l'hôte |
| 6443 | API Kubernetes | Doit être limité à des plages d'IP autorisées ou à un réseau privé |
| 9200 | Elasticsearch | Source fréquente de fuites de données |
| 27017 | MongoDB | Historiquement scanné en masse et effacé lorsqu'il restait ouvert |
Exécutez ces contrôles depuis des sites externes toutes les 5 à 15 minutes. Vous détecterez ainsi un security group assoupli, un chart Helm mal configuré ou un port de débogage oublié.
Déployer cette approche avec UpScanX
La surveillance de ports UpScanX exécute des contrôles TCP et UDP depuis plus de 15 sites dans le monde, ce qui se prête bien à un déploiement progressif :
- Semaine 1 : ajoutez les contrôles de niveau 1 avec validation des réponses propre à chaque protocole, afin qu'un port qui accepte les connexions mais renvoie des réponses invalides déclenche quand même une alerte.
- Semaine 2 : ajoutez les contrôles de niveau 2 partout où votre réseau autorise l'accès de supervision, avec le suivi du temps de connexion et de la latence de réponse. Alertez à environ 2 à 3 fois le temps de connexion habituel.
- Semaine 3 : enregistrez une baseline de configuration pour le niveau 3 et activez la détection des changements d'état des ports. L'empreinte des services avec détection de version signale aussi un port censé exécuter nginx qui s'identifie soudain comme autre chose.
Acheminez les alertes de niveau 1 vers Slack ou Microsoft Teams, là où vos équipes d'intervention les verront, et envoyez les alertes d'exposition de niveau 3 à votre équipe sécurité par e-mail ou webhook. Pour savoir quoi vérifier sur chaque port ouvert, consultez notre checklist de surveillance des ports ouverts critiques.
Points clés à retenir
- Priorisez selon l'impact client, les points de défaillance uniques et le risque d'exposition plutôt que selon le numéro de port.
- Surveillez d'abord les points d'entrée publics, puis les dépendances de données internes, puis les ports d'administration.
- Mesurez la latence de connexion, pas seulement l'accessibilité, pour détecter tôt les dégradations.
- Révisez la liste après chaque changement d'infrastructure important : les nouveaux services ajoutent discrètement de nouveaux ports.