Shodan mesuré sur nos serveurs : 15 ports exposés sur 18 retrouvés, 1 nom d'hôte
sur 7

Le 7 octobre 2026, j'ai posé à Shodan une question dont je connaissais déjà la réponse : que sais-tu de nos serveurs ? Trois machines d'own2pwn, dont j'ai lu le même jour la configuration, les règles de pare-feu et les conteneurs, puis que j'ai scannées depuis l'extérieur sur les 65 535 ports TCP. En face, la réponse de Shodan InternetDB, l'accès gratuit et sans clé du moteur. L'écart entre les deux dit mieux qu'une définition ce qu'est un index d'exposition, et ce qu'il n'est pas.

Le résultat tient en trois chiffres. Shodan retrouvait 15 des 18 ports réellement exposés sur nos trois machines et sur scanme.nmap.org, la machine que le projet Nmap met à disposition pour ce genre de test (15 sur 17 si l'on retire un port qu'aucun scanner ne peut voir, j'y reviens). Il ne connaissait qu'un seul des sept noms d'hôte qui pointent vers notre serveur de production. Et sur les 122 CVE qu'il attribuait à scanme, 17 visaient un logiciel que la bannière ne mentionne pas. Shodan voit bien les ports, mal le périmètre, et ses CVE sont des hypothèses. La suite reprend ces mesures, puis revient sur le fonctionnement du moteur et sur les filtres qui servent à auditer son propre périmètre.

La mesure : trois serveurs à nous, une cible de test, un index gratuit

Le principe est de comparer ce que publie un index à une vérité qu'on connaît. Je l'ai donc fait sur les seules machines dont je connais la vérité, les nôtres : le serveur de production, qui porte les sites, les applications et un VPN, un serveur annexe de supervision, et une troisième machine. Leur propriété a été vérifiée le jour même par connexion SSH. Les noms publics viennent des journaux de Certificate Transparency et d'une énumération faite en septembre, résolus le jour de la mesure. La quatrième machine est scanme.nmap.org, dont le propriétaire autorise explicitement le scan.

Côté réalité, un scan nmap 7.92 en SYN sur les 65 535 ports TCP de nos machines, lancé depuis un accès résidentiel français en IPv4, puis une détection de version sur les ports trouvés. L'UDP ne se mesure pas proprement de l'extérieur (un port ouvert et muet ressemble à un port filtré), donc pour nos machines je l'ai lu dans la configuration : un port compte s'il écoute publiquement et que le pare-feu l'autorise. Sur scanme, je me suis limité aux 1 000 ports TCP les plus courants, à deux ports connus et au NTP. Côté index, InternetDB renvoie pour une adresse ses ports, ses CPE (produit et version), ses CVE, ses noms d'hôte et ses étiquettes. Les CVE ont été rapprochées des configurations de la NVD, sur un miroir du 6 octobre 2026. L'étude a ensuite été recomptée par une contre-expertise, qui a confirmé les comptages et corrigé deux formulations, reprises ici dans leur version corrigée.

15 ports exposés sur 18 : ce que Shodan voit, et les trois qu'il rate

Sur nos trois machines, Shodan listait 12 des 14 ports réellement exposés (85,7 %), et 15 sur 18 en ajoutant scanme (83,3 %). Le serveur annexe est décrit sans erreur. Les erreurs dans l'autre sens sont rares : un seul des 16 ports listés était fermé, le 31337 de scanme, qui a renvoyé un refus de connexion lors de mon unique sondage. Ce port s'ouvre et se ferme au fil du temps sur scanme, je parlerai donc d'un état qui a changé plutôt que d'une erreur. Ce qui intéresse vraiment, ce sont les trois ports manqués, parce qu'aucun n'est un service exotique caché sur un port improbable.

Un VPN muet. Notre serveur OpenVPN écoute en UDP sur le port 1194, configuré en tls-auth : il ignore tout paquet qui n'est pas signé avec une clé partagée. Depuis l'extérieur, nmap le classe comme les cinq autres ports UDP sondés sur ce serveur, "open|filtered", ce que rend un scan de ports quand il ne tranche pas, autrement dit il ne sait pas. Aucun scanner externe ne peut voir ce port, et le compter comme un trou de Shodan serait injuste : c'est pourquoi je donne aussi le rappel sans lui, 15 sur 17, soit 88,2 %. C'est une bonne nouvelle pour qui configure un VPN : un service qui ne répond qu'aux paquets signés n'apparaît dans aucun index.

Un service bavard, et pourtant absent. Sur la troisième machine, un service TCP envoie sa bannière dès la connexion, sans attendre qu'on lui parle. Il était ouvert depuis au moins 64 jours, d'après la date de démarrage de son conteneur, et il n'était pas dans InternetDB. C'est le cas le plus instructif des trois, parce qu'il n'a aucune excuse technique : un collecteur qui se serait connecté l'aurait vu. Le troisième manque est le port 9929 de scanme, où tourne un service d'écho de nping.

Une précision pour lire ces chiffres : ils sont bons en partie parce que nos machines exposent peu. Le serveur de production n'a que deux ports TCP ouverts pour 65 533 filtrés. Sur un parc de plusieurs centaines de services, dont certains sur des ports peu courants, rien ne dit que la proportion tiendrait, et la liste des ports balayés par Shodan, que je détaille plus bas, invite à la prudence.

Un nom d'hôte sur sept : Shodan voit une IP, pas un périmètre

Notre serveur de production répond pour sept noms publics, trouvés dans les certificats et résolus vers la même adresse le jour de la mesure. Derrière, six applications distinctes, servies par le même reverse proxy selon le nom demandé. InternetDB n'associait à cette adresse qu'un seul nom, le domaine racine. Pour Shodan, les six applications se résument à deux ports, 80 et 443, sur une adresse.

Ce n'est pas tant un défaut qu'une conséquence du modèle : le moteur part des adresses, pas des noms, et ne rattache un nom à une adresse que s'il l'a croisé quelque part. Une recherche hostname: sur votre domaine ne remonte donc que les noms qu'il a eu l'occasion de rencontrer, et l'inventaire de vos applications web ne peut pas venir de lui. Il vient du DNS et des certificats, ce que fait une découverte d'actifs digne de ce nom.

122 CVE pour une machine de test, dont 17 sans fondement

InternetDB attribuait 122 CVE à scanme.nmap.org. Toutes se rattachent à Apache 2.4.7, la version annoncée par la bannière du serveur web ; aucune ne vise OpenSSH ni NTP, pourtant annoncés eux aussi. En les rapprochant des configurations de la NVD, 105 tombent bien dans la plage de versions vulnérables d'Apache. Les 17 autres visent un module ou un logiciel distinct (mod_auth_openidc, mod_pagespeed, ModSecurity, Subversion, un agent RSA, un panneau d'administration de jeu en ligne) : la NVD n'y cite Apache que comme plateforme, explicitement non vulnérable.

Rien dans la chaîne Apache/2.4.7 ne dit si ces modules sont installés. Je ne peux pas prouver qu'ils sont absents de scanme (il faudrait un accès à la machine), donc je ne parle pas de faux positifs : ce sont des attributions infondées, des CVE qui ne concernent pas le logiciel identifié. La proportion est presque la même sur une autre cible de test, rest.vulnweb.com : 19 sur 142, soit 13,4 %. Pour qui trie ses alertes sur le nombre de CVE affichées, c'est une sur sept qui part dans le mauvais tas. Et 22 des 122 portent un score CVSS v3 d'au moins 9, de quoi nourrir un rapport alarmant sur une machine que personne n'a regardée.

Le cas d'OpenSSH est plus étrange, et c'est la contre-expertise qui l'a fait ressortir. J'ai lu dans InternetDB, sans me connecter aux machines, les enregistrements de douze serveurs pour lesquels Shodan annonce une version d'OpenSSH : scanme, nos deux serveurs à SSH public, et neuf serveurs publics tiers que je ne nommerai pas. Les sept qui affichent une version de distribution, avec le suffixe p1 (6.6.1p1, 7.6p1, 8.9p1, 9.6p1), n'ont aucune CVE OpenSSH listée, alors que la NVD en place des dizaines dans leur plage. Trois des cinq versions sans suffixe en ont, de 6 à 24. Prudence face aux correctifs rétroportés, ou simple défaut d'appariement de version ? La cause ne se voit pas depuis InternetDB, et l'échantillon est petit et choisi par commodité. Ce qui se voit, c'est que la règle n'est pas uniforme : Apache "(Ubuntu)" reçoit bien, lui, ses CVE.

Nos propres serveurs permettent de mesurer ce que vaudrait l'approche inverse. Ils font tourner OpenSSH 9.6p1 dans le paquet Ubuntu 1:9.6p1-3ubuntu13.19. Un outil qui lirait la bannière et la rapprocherait de la NVD par numéro de version trouverait 22 CVE dont la configuration NVD couvre la version 9.6. Le journal des modifications du paquet installé en cite 19 comme corrigées. Des trois restantes, une ne concerne que des paquets Red Hat, une suppose un mode d'authentification particulier configuré dans PAM, et la dernière est contestée par les développeurs d'OpenSSH. InternetDB n'en listait aucune. Un rapprochement par version produit donc beaucoup de bruit sur une distribution maintenue, et le silence ne prouve rien non plus : dans les deux cas, c'est la version du paquet qui tranche, pas celle de la bannière.

Une bannière, pas une page web

Pour comprendre ces écarts, il faut revenir à ce que collecte Shodan. Quand un serveur SSH accepte une connexion, il annonce sa version avant même de demander quoi que ce soit. Un serveur web renvoie un en-tête Server: à qui lui adresse la parole. Un automate industriel décline son modèle. Cette politesse protocolaire porte un nom, la bannière, et c'est ce que Shodan collecte depuis 2009 : des réponses de services, mesurées adresse par adresse, port par port. D'où l'étiquette de "Google des hackers", qui induit en erreur deux fois : ce n'est pas un moteur de pages mais un catalogue de services, et son usage majoritaire est défensif, contrôler ce que le monde voit de ses propres machines.

La documentation de Shodan définit la bannière comme les métadonnées d'un logiciel qui tourne sur un appareil : la version du serveur, les options que le service prend en charge, un message d'accueil, ou n'importe quoi d'autre que le service estime utile d'annoncer avant l'interaction. C'est une définition volontairement large, parce que la forme d'une bannière dépend entièrement du protocole. Un SMTP se présente en une ligne, un HTTPS embarque des en-têtes, du HTML, un certificat, parfois une capture d'écran de la page rendue.

Conséquence pratique : une recherche Shodan sans filtre ne cherche que dans le texte brut de la bannière. Le blog officiel le dit noir sur blanc, les requêtes de base portent sur la propriété data de l'enregistrement, et il faut passer par des filtres pour interroger les autres propriétés. Taper le nom de votre entreprise dans la barre de recherche ne fait donc pas ce que vous croyez : cela cherche cette chaîne dans les réponses protocolaires du monde entier, pas dans un annuaire d'organisations. Voilà pourquoi tout travail sérieux sur Shodan commence par la syntaxe des filtres, et pourquoi les recherches en texte libre produisent surtout du bruit.

La distinction entre champs mesurés et champs déduits commande toute la confiance qu'on peut accorder à un enregistrement. L'adresse, le port et l'horodatage sont des faits. Le produit et la version sont des interprétations du texte brut, et elles héritent de tous ses défauts : une bannière se configure, se tronque et se falsifie. Un administrateur qui affiche Server: nginx/1.18.0 sur une pile entièrement corrigée par son distributeur fabrique un faux positif chez tous ceux qui corrèlent les versions aux CVE. Le phénomène est loin d'être marginal, et c'est une des raisons pour lesquelles la gestion des vulnérabilités ne peut pas se réduire à un rapprochement mécanique entre une chaîne de version et un flux de failles connues.

Shodan est d'ailleurs le premier à le reconnaître. Les vulnérabilités qu'il associe à un enregistrement portent un champ verified, et sa documentation prévient que celles qui restent à false sont déduites des métadonnées et peuvent générer des faux positifs significatifs. Le cas qui concerne le plus les parcs français est écrit noir sur blanc dans cette même documentation : quand un correctif de sécurité ne change pas le numéro de version, ce qui est le principe même des correctifs rétroportés par les distributions d'entreprise, Shodan ne peut pas voir que la faille est corrigée. Une machine Debian ou Red Hat à jour peut donc rester affichée comme vulnérable indéfiniment. Notre mesure nuance à peine ce constat : un Apache annoncé "(Ubuntu)" reçoit bien ses CVE de plage, et seules les versions de distribution d'OpenSSH de notre échantillon y échappaient, pour une raison que l'extérieur ne permet pas de connaître.

Comment Shodan collecte, étape par étape

Le mécanisme est simple, et c'est sa simplicité qui explique ses limites. Des collecteurs répartis dans le monde ouvrent des connexions vers des adresses et des ports, notent ce qui répond, analysent la réponse, l'enrichissent de données extérieures, et versent le tout dans un index consultable. Rien dans cette chaîne ne part de vous ni de votre nom.

Cette dernière étape a une conséquence appréciable pour un défenseur : interroger Shodan sur votre propre périmètre est une opération strictement passive. Aucun paquet ne part vers vos machines, rien n'apparaît dans vos journaux, et vous ne risquez pas de déstabiliser un service fragile. C'est la même logique que l'interrogation des journaux de Certificate Transparency, et c'est ce qui fait de ces sources le premier réflexe de toute découverte d'actifs : on épuise ce qui ne coûte rien avant de toucher quoi que ce soit.

La fraîcheur, le piège numéro un

Un index n'est pas un scan. La formule paraît anodine, elle est à l'origine de la moitié des mauvaises décisions prises sur la foi d'un résultat Shodan. Le moteur ne vous dit pas ce qui est ouvert maintenant, il vous dit ce qui répondait la dernière fois qu'un collecteur est passé. La documentation officielle situe ce passage à au moins une fois par semaine pour l'ensemble d'Internet, ce qui est remarquable à cette échelle, et parfaitement insuffisant quand la question porte sur l'état d'un service précis.

Un second chiffre, beaucoup moins cité, pèse encore plus lourd. La documentation consacrée aux fenêtres temporelles précise que le moteur principal, celui du site et de l'API de recherche, n'affiche que les bannières collectées au cours des trente derniers jours. Au-delà, l'enregistrement sort de la vue par défaut. L'historique passe alors par d'autres portes : le paramètre d'historique de l'API, borné à quatre-vingt-dix jours et à mille bannières, Shodan Trends pour des agrégats remontant à 2017, et Shodan Monitor, qui ne regarde lui que les quarante-huit dernières heures mais re-scanne plusieurs fois par jour les plages qu'on lui confie. Trois fenêtres, trois produits distincts : c'est déjà l'aveu qu'un moteur de recherche ne fait pas de la surveillance.

Les deux erreurs sont symétriques et ne se rattrapent pas de la même manière. Le faux positif de fermeture d'abord : vous avez fermé un port la semaine dernière, Shodan l'affiche encore ouvert, et vous passez une heure à chercher une régression qui n'existe pas. Le faux négatif d'ouverture ensuite, nettement plus dangereux : une équipe a déployé un service hier, il n'est pas encore dans l'index, et l'absence de résultat vous fait conclure à l'absence d'exposition. Dans les deux cas, la parade est la même et tient en un réflexe : lire l'horodatage avant de lire le résultat.

Encore faut-il en avoir un. La réponse d'InternetDB, l'accès gratuit, compte six champs (ports, CPE, CVE, noms d'hôte, étiquettes, adresse) et aucune date. L'âge de la mesure ne s'y lit pas, il ne se devine qu'indirectement, et nos mesures du 7 octobre en donnent deux indices. Le premier est le service ouvert depuis au moins 64 jours et absent de l'index, décrit plus haut. Le second est plus inattendu : deux CVE Apache publiées le 1^er octobre et analysées par la NVD le 2 figuraient dans l'enregistrement IPv4 de scanme, mais pas dans son enregistrement IPv6, ni dans celui de rest.vulnweb.com, qui porte une version d'Apache également concernée. Une même machine n'a donc pas le même état selon l'adresse par laquelle on l'interroge, et sur trois enregistrements Apache, un seul était à jour.

Les filtres Shodan qui servent à auditer votre périmètre

La syntaxe est uniforme : filtre:valeur, sans espace entre les deux. Plusieurs filtres se combinent par simple juxtaposition, qui vaut ET, et une valeur contenant des espaces se met entre guillemets. Deux opérateurs complètent le tableau, attestés par les exemples officiels : la virgule vaut OU à l'intérieur d'un même filtre (port:22,3333), et le tiret en préfixe vaut NON (net:203.0.113.0/24 ssh -port:22, pour trouver du SSH sur un port non standard dans son propre plan d'adressage). La liste complète est publiée sur la page officielle des filtres, qui compte plus d'une centaine d'entrées réparties par famille de protocole. On n'en utilise qu'une poignée pour du travail défensif, et ce sont toujours les mêmes.

Ancrer le périmètre : net, hostname, org, ssl

Tout commence par délimiter ce que vous regardez, et c'est l'étape que les tutoriels bâclent. Le filtre le plus fiable est net, qui prend une adresse ou un bloc en notation CIDR : si vous possédez vos plages, aucune ambiguïté n'est possible. hostname filtre sur les noms associés à l'enregistrement, ce qui inclut la résolution inverse et les noms rencontrés au passage, et se prête bien à un domaine racine. ssl.cert.subject.cn vise le nom commun du certificat présenté, ce qui reste le meilleur moyen de retrouver une machine derrière une adresse qui ne dit rien.

# Votre bloc d'adresses : le point d'ancrage le plus sur
net:203.0.113.0/24

# Une adresse unique, meme syntaxe
net:203.0.113.10

# Tout ce qui porte un nom rattache a votre domaine
hostname:exemple.com

# Le certificat comme point d'ancrage : le nom commun du sujet
ssl.cert.subject.cn:exemple.com

# L'organisation declaree pour le bloc d'adresses.
# Utile SI vous possedez vos plages, trompeur sinon (voir plus bas).
org:"Exemple Hosting SAS"

Un mot sur org, parce qu'il est systématiquement mal employé. Ce champ provient de l'enregistrement du bloc d'adresses, pas d'une connaissance qu'aurait Shodan de votre société. Si vos serveurs vivent chez un hébergeur mutualisé ou dans un nuage public, il porte le nom du fournisseur et rassemble des dizaines de milliers de machines qui n'ont rien à voir avec vous. Il ne devient exploitable que pour les organisations qui détiennent leurs propres plages auprès d'un registre régional, ce qui est une minorité. Pour tout le monde, net et les certificats font un bien meilleur travail.

Qualifier ce qui tourne : port, product

Une fois le périmètre posé, on regarde ce qu'il expose. port prend un numéro, product prend le nom du logiciel tel que Shodan l'a déduit de la bannière. Ces deux filtres se combinent avec l'ancrage précédent, et c'est cette combinaison qui produit un inventaire utilisable.

# Tous les services de votre bloc : la vue d'ensemble, a lire en entier
net:203.0.113.0/24

# Les acces distants sur votre bloc, la question la plus rentable
net:203.0.113.0/24 port:3389
net:203.0.113.0/24 port:22

# Un logiciel precis sur votre perimetre, pour verifier une campagne
# de mise a jour (rappel : la version affichee peut mentir)
hostname:exemple.com product:nginx

# Les bases de donnees et files de messages de votre bloc :
# les requetes dont le resultat attendu est VIDE
net:203.0.113.0/24 port:5432
net:203.0.113.0/24 port:27017
net:203.0.113.0/24 port:6379

Lire le web : http.title

http.title filtre sur le contenu de la balise <title> de la page servie. C'est le filtre le plus sous-estimé du lot pour un usage défensif, parce que le titre d'une page trahit sa nature bien mieux qu'une version de serveur. Un portail interne, une console d'administration ou une page d'installation laissée en l'état se signalent tous par leur titre. Appliqué à votre propre domaine, ce filtre répond à une question très concrète : qu'est-ce qui, chez moi, s'annonce au monde avec un titre qui ne devrait pas être visible depuis Internet.

# Un titre precis sur VOTRE domaine, par exemple pour verifier
# qu'un environnement de recette n'est pas joignable publiquement
hostname:exemple.com http.title:"recette"

# Une page d'accueil par defaut restee en l'etat sur votre bloc :
# signature d'un service monte puis oublie
net:203.0.113.0/24 http.title:"Welcome to nginx"

# Les reponses interdites de votre perimetre : une 403 recouvre
# souvent une interface qu'on croyait filtree
net:203.0.113.0/24 http.status:403

# Les hotes de votre bloc dont Shodan a capture une capture d'ecran
net:203.0.113.0/24 has_screenshot:true

Surveiller le TLS : la famille ssl

C'est la famille de filtres la plus riche, et celle qui rend le service le plus immédiat. ssl.cert.expired prend un booléen et remonte les certificats périmés, ssl.cert.issuer.cn filtre sur l'autorité émettrice, ssl.version sur la version du protocole négociée. Croisés avec votre bloc d'adresses, ils constituent un audit TLS gratuit de votre périmètre, sans envoyer un seul paquet.

# Certificats expires sur votre perimetre
net:203.0.113.0/24 ssl.cert.expired:true

# Protocoles obsoletes encore acceptes chez vous
net:203.0.113.0/24 ssl.version:tlsv1
net:203.0.113.0/24 ssl.version:sslv3

# L'autorite emettrice de vos certificats. Listez-la, puis reperez
# les intrus : un CN d'emetteur inattendu signale un service monte
# en dehors de votre processus habituel
hostname:exemple.com ssl.cert.issuer.cn:"R11"

# Tout hote de votre bloc qui presente un certificat, quel qu'il soit
net:203.0.113.0/24 has_ssl:true

Dater les résultats : before et after

Ces deux filtres bornent la fenêtre temporelle des mesures retenues, et ils méritent un avertissement que vous ne lirez à peu près nulle part : ils ne figurent sur aucune page de référence de Shodan. Ni dans la liste officielle des filtres, ni dans le centre d'aide, ni dans la documentation de l'API. La seule attestation par l'éditeur lui-même est un exemple glissé dans un billet de blog, after:01/03/2015, dont on déduit le format jj/mm/aaaa que reprennent tous les aide-mémoire. Ils fonctionnent, et ils sont utiles, mais vous les employez sans filet : rien n'engage Shodan à les maintenir.

Cela dit, quand ils répondent, ils transforment une recherche ponctuelle en outil de contrôle. Après une opération de fermeture de ports, ne garder que les mesures postérieures permet de vérifier que le changement a bien été observé, au lieu de raisonner sur des données antérieures à votre propre intervention.

# Ce qui a ete MESURE sur votre bloc depuis le 1er septembre 2026
net:203.0.113.0/24 after:01/09/2026

# Verifier qu'un port ferme le 15 septembre n'apparait plus apres
net:203.0.113.0/24 port:3389 after:15/09/2026

# Encadrer une fenetre, par exemple autour d'une migration
net:203.0.113.0/24 after:01/09/2026 before:30/09/2026

Quatre usages défensifs qui tiennent la route

L'inventaire de son exposition. Poser net: sur chacun de vos blocs et lire la liste en entier, port par port. L'exercice prend vingt minutes et sort une surprise à peu près à chaque fois, parce qu'il ne s'appuie sur aucune déclaration interne. Un scanner de vulnérabilité qu'on alimente avec une liste de cibles hérite des trous de cette liste ; Shodan ne connaît pas votre inventaire, donc il n'en hérite pas.

La détection de shadow IT. Un service monté hors des procédures est invisible dans votre CMDB par construction, et visible depuis Internet par la même construction. Croiser hostname: sur votre domaine racine avec vos plages connues fait ressortir les machines qui portent votre nom sans vivre chez vous, ce qui est la signature exacte du shadow IT. Attention au symétrique : un nom qui pointe vers un service décommissionné n'apparaîtra plus dans Shodan puisque plus rien ne répond, alors qu'il reste exploitable pour un subdomain takeover. Ce risque-là se traque dans le DNS, pas dans un index de bannières.

La vérification qu'un service supposé interne est joignable. C'est l'usage à plus fort rendement, et le plus rassurant à mener. Une base de données, une console d'administration, un service de supervision, une file de messages : tout ce dont vous êtes convaincu qu'il vit derrière le pare-feu se vérifie en une requête sur votre propre bloc. Le résultat attendu est vide. Quand il ne l'est pas, vous venez de trouver bien plus qu'une CVE.

Si vous ne deviez en garder qu'un pour commencer, prenez plutôt le fil des certificats périmés. Un certificat expiré sur un actif que personne ne surveille est le symptôme le plus lisible d'un service orphelin : la requête tient en deux filtres, elle ne coûte rien, et elle remonte les machines dont plus aucune automatisation ne s'occupe. Dans une majorité de cas, c'est par là qu'on tire les trois autres.

Shodan, Censys, FOFA : ce qui les sépare

Les comparatifs se contentent en général de classer ces moteurs par nombre d'enregistrements, ce qui ne veut pas dire grand-chose. La différence utile porte sur le modèle de données : la manière dont chacun organise ce qu'il collecte détermine les pivots qu'il vous laisse faire. Un quatrième acteur, français, manque à ce tableau : on le confronte aux deux premiers, ports balayés et fraîcheur compris, dans Censys, Onyphe et Shodan.

Deux points passent à la trappe dans les comparatifs francophones. Sur la fraîcheur, l'écart annoncé est net : Shodan communique un plancher hebdomadaire, quand Censys documente un re-scan quotidien de tout service dont la dernière observation a plus de vingt-quatre heures. Ce sont des déclarations d'éditeur, pas des mesures indépendantes, mais elles engagent leurs auteurs. Sur FOFA ensuite, le palier gratuit est explicitement présenté comme réservé à un usage non commercial, l'usage commercial démarrant plusieurs centaines d'euros par mois plus haut. S'en servir gratuitement au cours d'une prestation facturée sort donc des conditions affichées, ce qui est un point à vérifier avant d'en faire un réflexe d'équipe.

Aucun ne remplace les autres. Leurs collecteurs partent de points différents, à des rythmes différents, et se font filtrer par des équipements différents : le recouvrement est loin d'être total. Un inventaire qui compte interroge au minimum les deux premiers, et accepte que le résultat soit une union, pas une intersection. Ce réflexe de croisement des sources est le même que celui décrit dans notre panorama des outils de collecte OSINT brique par brique, et il s'inscrit dans la démarche plus large de renseignement en source ouverte qui précède toute reconnaissance active.

Ce que coûte Shodan

Les articles francophones sur le sujet recopient des tarifs vieux de plusieurs années, d'où ce détour par la facturation. Les montants ci-dessous ont été relevés sur la page officielle le 16 août 2026, et ils bougent : vérifiez-les avant d'en faire une ligne budgétaire.

• Adhésion à vie : 49 dollars en paiement unique, pour 100 crédits de requête et 100 crédits de scan par mois. C'est l'offre qui explique la popularité du service, et elle suffit largement à un usage ponctuel de vérification de son propre périmètre.
• Freelancer : 69 dollars par mois, avec 10 000 crédits de requête et 5 120 crédits de scan mensuels.
• Small Business : 359 dollars par mois, 200 000 crédits de requête et 65 536 crédits de scan.
• Corporate : 1 099 dollars par mois, crédits de requête illimités et 327 680 crédits de scan.

La logique des crédits n'a rien d'intuitif, et c'est pourtant elle qui décide du plan qu'il vous faut. Un crédit de requête donne droit à cent résultats téléchargés, et il n'est décompté que si la recherche contient un filtre ou si vous demandez une page au-delà de la première : une recherche en texte libre sur la première page ne coûte rien. Un crédit de scan se dépense à l'adresse, un crédit par IP soumise au balayage à la demande. Ce sont ces derniers qui limitent la fréquence à laquelle vous pouvez rafraîchir votre propre périmètre, donc la frontière entre un usage exploratoire et un usage de surveillance.

Là où Shodan s'arrête

Tout ce qui précède décrit un excellent outil, à condition de lui poser la question à laquelle il sait répondre : qu'ai-je vu depuis l'extérieur pour cette adresse IP. Un RSSI, lui, en pose une autre : qu'est-ce que mon organisation expose aujourd'hui. Entre les deux, il manque trois choses, et aucune n'est un détail d'implémentation.

Shodan ne sait pas ce qui vous appartient. C'est la limite fondamentale : le moteur indexe des adresses, pas des organisations. Le champ org décrit le propriétaire du bloc, qui est le plus souvent votre hébergeur, et les noms qu'il associe à une adresse sont ceux qu'il a croisés : un sur sept pour notre serveur de production. Rattacher un actif à une entreprise demande de croiser le DNS, les certificats, les registres légaux, le contenu servi et le périmètre juridique du groupe, filiales comprises. Ce travail d'attribution est celui qui fait la différence entre une liste et un inventaire, et c'est celui qu'aucun moteur de recherche ne fera à votre place.

Il ne suit pas vos changements dans le temps. L'index principal montre l'état récent, pas la trajectoire. Shodan a bien construit un produit d'analyse historique, Trends, dont le blog officiel indique qu'il indexe des données remontant à 2017, mais il répond à des questions d'échelle sur Internet, pas à la question qui vous intéresse : qu'est-ce qui a changé sur mon périmètre depuis hier, et qui dois-je prévenir. Une surface d'attaque se lit en différentiel. Un moteur de recherche, par nature, vous renvoie un état.

Sa couverture est partielle par construction, et pour une fois le chiffre est public. Shodan expose la liste des ports qu'il balaie, sans authentification :

curl -s https://api.shodan.io/shodan/ports | jq 'length'
# 3846   (releve le 16 aout 2026)

Trois mille huit cent quarante-six ports sur les 65 535 possibles, soit moins de 6 % de l'espace. Tous les ports usuels y sont, et c'est là le problème : un service déplacé sur un port exotique, ce qui arrive souvent aux interfaces qu'on préfère discrètes, a de bonnes chances de ne jamais entrer dans l'index. S'ajoutent une couverture IPv6 très inégale, parce que l'espace est trop vaste pour être énuméré, et l'effet masquant des réseaux de diffusion de contenu, derrière lesquels vous voyez le point de présence du fournisseur et pas le serveur d'origine. Une absence de résultat n'est jamais une preuve d'absence d'exposition, et confondre les deux est le plus sûr moyen de se rassurer à tort. Sur nos machines, le port manqué n'était même pas exotique : un service bavard, ouvert depuis au moins 64 jours.

Corollaire que Shodan a lui-même publié sous le titre ne cherchez pas par port : raisonner en numéros de port ramasse des honeypots, des CDN et des services sans rapport, tout en manquant les instances déplacées. La correction que l'éditeur recommande consiste à s'appuyer sur product, os et tag. Sauf que tag est réservé au plan le plus cher : le remède officiel n'est pas à la portée de la majorité des comptes.

C'est l'écart que comble la gestion de la surface d'attaque externe. Une plateforme EASM part de votre nom plutôt que d'une adresse IP, interroge Shodan parmi d'autres sources, attribue chaque actif trouvé à votre organisation et repasse en boucle pour ne vous signaler que ce qui a bougé depuis la veille. Shodan occupe un maillon de cette chaîne, celui de la mesure brute.

À retenir

• Mesuré sur nos serveurs, Shodan voit bien les ports : InternetDB listait 15 des 18 ports réellement exposés sur quatre machines (83,3 %), 15 sur 17 hors un VPN que personne ne peut voir, et un seul port fermé. Mais il ne connaissait qu'un nom d'hôte sur sept, n'affiche aucune date, et 17 des 122 CVE attribuées à scanme visaient un module ou un logiciel distinct du serveur Apache. Quatre machines ne décrivent pas Internet : c'est un ordre de grandeur, pas une statistique.
• Shodan indexe des bannières, pas des pages : chaque enregistrement est une mesure datée sur un couple adresse et port. Une recherche sans filtre ne cherche que dans le texte brut de la bannière, d'où l'importance de la syntaxe des filtres.
• Lisez l'horodatage avant le résultat : la documentation annonce un parcours complet d'Internet au moins une fois par semaine, et le moteur principal n'affiche que les trente derniers jours. Un port fermé peut encore apparaître, un service ouvert hier peut manquer. Le balayage à la demande coûte un crédit de scan par adresse et exige un plan payant.
• Les champs déduits sont faillibles : adresse, port et date sont des faits, produit et version sont des interprétations du texte brut, et une bannière se falsifie.
• Pour un audit défensif, ancrez sur net et les certificats, pas sur org, qui désigne le propriétaire du bloc d'adresses et vaut donc rarement le nom de votre société. Les filtres utiles se comptent sur les doigts d'une main : net, hostname, port, product, http.title, la famille ssl. Ajoutez-y before et after au format jj/mm/aaaa, en sachant qu'ils ne sont documentés nulle part par Shodan.
• Consulter est licite, se connecter ne l'est pas : l'article 323-1 du code pénal punit l'accès et le maintien frauduleux dans un système de traitement automatisé de données, et la Cour de cassation a jugé en 2015 qu'un contenu atteignable via un moteur ne donne aucun droit d'y accéder.
• Le moteur ne connaît pas votre périmètre : il ne rattache pas les actifs à une organisation de façon fiable, ne suit pas vos changements dans le temps, et sa couverture est partielle. Une absence de résultat ne prouve rien.

Reste le geste le plus utile, et il tient en un quart d'heure : prenez vos blocs d'adresses, posez-y net:, lisez la liste jusqu'en bas sans sauter de ligne, et regardez la date de chaque enregistrement avant de conclure quoi que ce soit. Ce que vous trouverez sera daté, partiel et attribué à votre hébergeur, et ce sera quand même la vue la moins flattée que vous ayez de votre exposition. La suite, l'attribution à votre nom et le suivi des changements jour après jour, se traite avec la plateforme EASM d'own2pwn, ou en écrivant à un humain depuis la page contact.

Questions fréquentes sur Shodan