IP & Network

Vérification banner-grab serveur

Scanne quels services (HTTP, FTP, SSH, SMTP) tournent sur un hôte.

Host or IP Public addresses only. Banner-grab on common service ports.

Try example.com cloudflare.com github.com

À propos de cet outil

Une vérification de serveur va un cran au-delà d'un scan de port. Nous nous connectons à une liste fixe de ports de service courants sur votre hôte — HTTP, HTTPS, SSH, FTP, SMTP, IMAP, POP3, DNS, MySQL, PostgreSQL, Redis, RDP — et lisons ce que le démon dit en premier. La plupart des services en clair annoncent leur produit et leur version dans la première ligne de la conversation ; les ouverts reviennent avec une véritable empreinte, les fermés reviennent honnêtes, et les pare-feu expirent à 3 secondes.

Pour chaque port ouvert, nous enregistrons la bannière brute, notre verdict analysé sur le produit (par exemple nginx/1.25.3, OpenSSH_8.9p1, vsFTPd 3.0.5) et le temps qu'a pris l'appel. HTTP et HTTPS sont sondés avec une véritable requête HEAD / afin que nous puissions capturer l'en-tête Server plutôt que deviner à partir du numéro de port ; HTTPS utilise TLS sans validation de certificat afin que les hôtes de développement auto-signés rapportent toujours.

Ce que vous pouvez en faire

Voir ce qui est réellement exposé. Un port peut être ouvert sur un scanner de port, mais la vérification de serveur vous dit exactement quel démon écoute — ce qui est souvent la différence entre "attendu" et "voyou".
Repérer les versions obsolètes en quelques secondes. Si votre nginx répond toujours Server: nginx/1.18.0 après le bulletin de sécurité que vous avez lu, vous avez un problème CI/CD à corriger.
Vérifier un changement de durcissement. Vous avez resserré ServerTokens sur Apache ou défini server_tokens off sur nginx ? Une nouvelle exécution devrait maintenant signaler juste nginx ou Apache sans version — preuve que la directive a atterri.

Lecture du résultat

"Ouvert + bannière" est le cas en or : un service a parlé et nous l'avons reconnu. "Ouvert + pas de bannière" est normal pour les protocoles binaires (RDP, poignée de main MySQL, démarrage PostgreSQL) — nous signalons que le port est joignable mais ne pouvons pas le prendre en empreinte sans parler le format de fil. "Fermé" signifie que le noyau a dit RST — le service ne s'exécute pas. "Filtré" signifie qu'un pare-feu a mangé le SYN — beaucoup sont intentionnels (VPN d'administration à code source fermé), certains indiquent une mauvaise configuration. Les résultats sont mis en cache pendant 15 minutes par hôte afin que les rechargements ne re-composent pas le monde.

Questions fréquentes

En quoi cela diffère-t-il du port checker ?

Le port checker demande seulement "la poignée de main TCP se termine-t-elle ?". La vérification de serveur va plus loin : elle fait une véritable saisie de bannière — lisant le salut que SSH/FTP/SMTP/POP3/IMAP envoient à la connexion, plus une véritable requête HEAD pour HTTP/HTTPS — afin que nous puissions nommer le produit et (quand non supprimée) la version. Le port checker est plus rapide pour une longue liste de ports personnalisés ; la vérification de serveur est le bon outil quand vous voulez savoir ce qui est sur chaque port, pas seulement qu'il y a quelque chose.

Pourquoi certains ports ouverts n'ont-ils pas de bannière ?

Les protocoles binaires — RDP, poignée de main pré-auth MySQL, démarrage PostgreSQL, Redis brut sans salut RESP — n'envoient pas de ligne lisible par l'humain à la connexion. Nous les marquons comme ouverts sans empreinte. Pour identifier les versions de ces services, vous avez besoin d'un client conscient du protocole (par exemple mysqladmin, nmap -sV avec le bon script). La configuration qui cache les bannières (Apache ServerTokens Prod, nginx server_tokens off) apparaît de manière similaire comme "ouvert, produit uniquement, pas de version".

Les IP privées sont-elles prises en charge ?

Non. Les plages privées RFC 1918, loopback, link-local (169.254/16), CGN (100.64/10) et les points de terminaison de métadonnées cloud sont refusés — même politique SSRF que le reste de nos outils. La vérification de serveur est pour les hôtes joignables publiquement. Pour auditer un hôte interne, exécutez un outil de saisie de bannière depuis l'intérieur de votre réseau.

Pourquoi HTTPS est-il signalé même avec un mauvais certificat ?

Nous désactivons la validation de certificat délibérément. Le but de la vérification est de savoir ce qui est sur le port, pas de valider la confiance — de nombreux hôtes de développement et auto-signés n'ont pas de chaîne publique valide mais sont toujours des cibles de scan légitimes. Si vous voulez un verdict de confiance, l'outil SSL Checker à venir exécute une validation complète de la chaîne, de l'expiration et de l'émetteur ; cet outil lit uniquement l'en-tête Server :.

Combien de temps prend un scan ?

Pire cas environ 45 secondes — 15 services × délai d'attente de 3 secondes — lorsque chaque port est filtré. En pratique, les hôtes typiques répondent sur une poignée de ports en moins de 5 secondes au total. Les résultats arrivent en streaming au fur et à mesure que chaque service répond, donc vous n'attendez pas les lents pour connaître les rapides ; le résultat est mis en cache pendant 15 minutes par hôte afin qu'une actualisation soit instantanée.