Port Checker en ligne
Teste des ports TCP sur un host ou une IP publique, lis les notes d'exposition et copie un rapport propre.
Ce port checker en ligne tape un port TCP depuis notre serveur et te dit si quelque chose répond vraiment, ce qui est exactement ce que tu veux savoir après une modification de firewall, une migration ou une config mail qui refuse de coopérer. Tape un host ou une IP publique, liste les ports ou une petite plage, ou charge un profil pour un serveur web, un serveur mail, une machine d'admin distante ou une revue de base de données. Chaque résultat arrive avec une lecture d'exposition, donc un port de base de données ouvert ou un service d'admin grand ouvert est signalé plutôt qu'enfoui. Un point à bien comprendre : ça teste la joignabilité, rien d'autre. Ça ne se connecte pas, ne fait pas de fingerprint et ne prouve pas qu'un service est sûr. Un port open veut juste dire que quelqu'un a décroché. Tu peux aussi copier un rapport texte propre et parcourir la référence intégrée des ports courants.
Les requêtes passent par le service de lookup PeopleAreGeek. Nous ne journalisons rien.
Utilitaire de joignabilité TCP en direct
Bon, voilà ce que ça fait. On tape un port TCP depuis notre serveur et on te dit si quelque chose répond. Tu charges un profil, tu parcours les notes d'exposition, et tu récupères un rapport propre quand un firewall fait des siennes ou que tu viens de monter une nouvelle machine. Un truc à bien comprendre quand même : ça teste la joignabilité. Ça ne se connecte pas, ça ne fait pas de fingerprint, et ça ne te dira jamais qu'un service est sûr. Un port open veut juste dire que quelqu'un a décroché. Ce qu'il y a derrière, et si ça devrait être joignable tout court, c'est à toi de le juger au regard du rôle du serveur.
Chaque sonde part du backend du site en TCP. Petit rappel : un firewall peut très bien avaler le test exprès, et même un port qui répond doit encore être correctement verrouillé.
Ce qu'un port checker en ligne peut, et ne peut pas, te dire
Un port checker en ligne répond à une seule question, bien précise, et elle est utile : un réseau extérieur peut-il vraiment atteindre cet host sur ce port ? C'est exactement ce que tu veux savoir après avoir modifié un firewall, après une migration, ou quand une config mail refuse de coopérer. Le boulot sur un reverse proxy aussi. Si le HTTPS est censé être public, 443 doit décrocher. Et si une base de données est censée rester privée mais que son port répond depuis l'extérieur, eh bien, c'est typiquement le genre de truc qu'on va vérifier tout de suite.
Maintenant, ce que ce n'est pas. Ce n'est pas un scan de vulnérabilités, et ce n'est certainement pas la preuve que ton service est en bonne santé. Un port open peut très bien se trouver devant quelque chose de parfaitement patché et bloqué derrière une allowlist. Un port qui timeout peut être totalement volontaire, juste un firewall qui laisse tomber les sondes des inconnus en silence. Honnêtement, je trouve que tout l'intérêt est dans la comparaison : joignable par rapport à ce que tu voulais vraiment exposer. C'est dans l'écart entre les deux que se cachent les problèmes.
Comment interpréter les ports TCP courants
- 80 et 443 portent HTTP et HTTPS. Du trafic web public. Les voir open est généralement normal.
- 22 et 3389 sont la façon d'entrer dans une machine à distance, donc ils ne devraient être open que parce que tu l'as décidé.
- 25, 465 et 587 gèrent le transport ou la soumission de mail, mais seulement si cet host fait réellement de l'email. Sinon, pourquoi répondent-ils ?
- 3306, 5432, 1433, 6379 et 27017 sont des services de données. En règle générale, leur place est derrière un réseau privé ou une allowlist, pas en plein air.
- 21, 23 et 445 méritent un examen sérieux. Du legacy, et le genre de ports que les attaquants adorent pour se déplacer latéralement une fois dans la place.
Un workflow firewall qui marche
Commence par te demander à quoi sert le serveur. Un serveur web public, une passerelle VPN, un nœud de base de données qui bosse tranquillement au fond, aucun ne veut la même exposition. Donc vérifie les ports qui doivent être open. Puis passe une courte liste des ports sensibles qui ne doivent absolument pas l'être, et assure-toi qu'ils ne le sont pas. Tu as un service de management qui doit vraiment rester public ? Alors emballe-le : restreins-le aux IP sources connues, mets-le derrière un VPN, ajoute du MFA et garde des logs bavards. Et quand un port ressort closed alors que l'appli devrait être joignable, remonte la chaîne. Le service est-il seulement bind sur une interface publique ? Ensuite les security groups cloud, le firewall de l'host, le NAT, ce que ton provider filtre en amont. En général, c'est le truc ennuyeux que tu as zappé.
Résultats du port checker et contexte sécurité
La joignabilité, c'est juste la première couche. Pour un service web, l'étape suivante, c'est les headers HTTP et le certificat SSL, plus un coup d'œil rapide au comportement des redirections. Tu fais du mail ? Alors ce sont les enregistrements DNS et la politique TLS, et franchement la question de la réputation compte plus que les gens ne le pensent. Pour les ports d'admin, je voudrais confirmation que c'est patché et que seul l'accès par clé est autorisé, avec du rate limiting et un œil sur les logs. Voilà le truc sur lequel je reviens toujours, et c'est peut-être juste moi : le meilleur rapport de ports, ce n'est pas celui avec le moins de services open. C'est celui qui colle à un plan que tu as réellement écrit quelque part.
Questions fréquentes
Pourquoi mon port s'affiche closed alors que le service marche en local ?
En général, le service écoute seulement sur localhost ou sur une interface privée, donc ça marche pour toi et personne d'autre. Ou alors un truc sur le chemin bloque la connexion extérieure, un firewall, un security group cloud, le routeur, ton provider en amont. N'importe lequel suffit.
Cet outil peut-il tester l'UDP ?
Non, TCP uniquement. Il fonctionne en essayant d'ouvrir une connexion. L'UDP, c'est une autre bête, et franchement plus dur à lire, vu que plein de services UDP restent simplement là sans jamais répondre à une sonde qu'ils n'ont pas demandée.
Que veut dire un port open ou closed ?
Open : quelque chose écoute et tu l'as atteint. Closed : soit il n'y a personne, soit un firewall t'a activement renvoyé balader. Filtered, c'est le sournois. Là, c'est un firewall qui laisse tomber ta sonde en silence sans jamais rien dire, du coup tu restes planté à attendre.
Pourquoi ne pas laisser les ports de base de données ouverts sur internet ?
Parce que les bots scannent 3306, 5432, 6379 et 27017 en continu. Laisse une base de données traîner là-dehors et elle se fait brute-forcer ou frapper par un exploit connu très vite, parfois en quelques minutes après sa mise en ligne. Range-la derrière un VPN ou un tunnel SSH et laisse-la parler à ton appli, pas à internet tout entier.