La surveillance des ports ouverts se fait service par service : vérifiez que chaque port attendu accepte les connexions, que le bon protocole y répond, et comparez le temps de connexion à une référence. Les ports web et de messagerie doivent être testés depuis plusieurs régions publiques, tandis que les ports de base de données doivent être surveillés depuis un point interne ou autorisé par liste blanche, avec une alerte dès qu'ils deviennent accessibles publiquement.
Pourquoi une connexion TCP ne suffit pas
Une poignée de main TCP réussie prouve seulement que quelque chose écoute. Un pool de workers bloqué ou un proxy mal configuré peut accepter des connexions sans rien renvoyer d'utile. Une bonne surveillance de ports vérifie donc la réponse du protocole : une ligne de statut HTTP, une poignée de main TLS, une bannière SMTP 220 ou un handshake de base de données. Le fingerprinting de service ajoute un second signal en confirmant quel logiciel, et quelle version, répond.
Tableau de référence par service
| Service | Port(s) | Ce qu'il faut valider | Exposition attendue |
|---|---|---|---|
| HTTP | 80 | Redirection vers HTTPS | Public |
| HTTPS | 443 | Handshake TLS, certificat, statut | Public |
| MySQL | 3306 | Message d'accueil et version | Interne uniquement |
| PostgreSQL | 5432 | Réponse à SSLRequest | Interne uniquement |
| MongoDB | 27017 | Réponse à la commande hello |
Interne uniquement |
| Redis | 6379 | +PONG ou -NOAUTH |
Interne uniquement |
| SQL Server | 1433 | Réponse TDS pre-login | Interne uniquement |
| SMTP | 25 | Bannière 220, STARTTLS |
Public (MX) |
| Soumission | 587 / 465 | 220 ; STARTTLS / TLS implicite |
Public ou restreint |
| IMAP | 143 / 993 | * OK ; TLS sur 993 |
Public ou restreint |
| POP3 | 110 / 995 | +OK ; TLS sur 995 |
Public ou restreint |
Serveurs web : ports 80 et 443
Testez les deux ports depuis plusieurs régions. Sur le port 80, attendez une redirection 301 ou 308 vers HTTPS ; un 200 peut signifier que la redirection a été perdue lors d'un changement de configuration. Sur le port 443, validez le handshake TLS et le certificat, car un certificat expiré ou non conforme bloque les clients même si le port est ouvert. Suivez le temps de connexion séparément de la latence de réponse : une hausse du temps de connexion oriente vers le réseau ou le load balancer, une hausse du temps de réponse vers l'application.
Bases de données : surveiller en privé, alerter en cas d'exposition
Les ports de base de données ne doivent jamais être exposés à Internet, ce qui implique deux vérifications distinctes :
- Contrôle de santé depuis l'intérieur. Lancez-le depuis un hôte interne ou une source autorisée par liste blanche. MySQL envoie un message d'accueil dès l'ouverture de la connexion, alors que PostgreSQL, MongoDB, Redis et SQL Server attendent le client : la sonde doit donc parler en premier.
- Contrôle d'exposition depuis l'extérieur. Sondez 3306, 5432, 27017, 6379 et 1433 depuis des emplacements publics et considérez l'état « ouvert » comme un échec. Une modification de security group ou un conteneur publié avec un mauvais mapping de ports peut exposer une base en quelques minutes, et les scanners automatisés repèrent vite les instances exposées.
Services de messagerie : lire la bannière
Les protocoles de messagerie s'annoncent d'eux-mêmes, ce qui facilite leur validation. Les serveurs SMTP doivent répondre 220 ; un 421 signifie que le service refuse les connexions. Sur le port 587, vérifiez que STARTTLS est annoncé après EHLO ; sur 465, 993 et 995, vérifiez que le handshake TLS aboutit. IMAP doit répondre * OK et POP3 +OK. Certains réseaux cloud bloquent le port 25 sortant : sondez depuis des emplacements où ce trafic est autorisé.
Intervalles et seuils
Points de départ courants, à ajuster selon votre propre référence :
- Web (80/443) : toutes les minutes depuis au moins trois régions ; alerte quand deux emplacements ou plus échouent sur deux vérifications consécutives.
- Messagerie (25/587/993) : toutes les 1 à 5 minutes ; alerte après deux échecs consécutifs ou une bannière inattendue.
- Santé des bases (interne) : toutes les minutes ; alerte après deux à trois échecs consécutifs.
- Exposition des bases (externe) : toutes les 5 à 15 minutes ; alerte dès le premier résultat « ouvert ».
- Latence : avertissement quand le temps de connexion reste à deux à trois fois sa référence.
Pour une vue plus large, consultez nos bonnes pratiques de surveillance des ports.
Mise en pratique avec UpScanX
La surveillance des ports UpScanX exécute des vérifications de ports TCP et UDP depuis plus de 15 emplacements mondiaux, avec fingerprinting de service et détection de version, validation des réponses propre à chaque protocole, et suivi du temps de connexion et de la latence de réponse. Elle compare l'état des ports à une configuration de référence, signale les services inattendus et alerte par e-mail, Slack, Telegram, Microsoft Teams ou Webhook.
Points clés
- Validez la réponse du protocole sur chaque port, pas seulement la connexion TCP.
- Testez les ports web et de messagerie publics depuis plusieurs régions et exigez une concordance avant d'alerter.
- Surveillez la santé des bases en interne et traitez toute accessibilité publique comme un incident.
- Tenez un inventaire des ports attendus et alertez sur tout écart.