Shodan : comprendre ce qu'il indexe et auditer sa
propre exposition
Shodan n'indexe pas des pages web mais des bannières de services. Ce que ça change, comment lire la fraîcheur d'un résultat, quels filtres servent vraiment à auditer son propre périmètre, et où s'arrête le moteur.
own2pwn··17 min de lecture
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 une par une, adresse par adresse, port par port, et rien d'autre.
D'où l'étiquette de "Google des hackers", qui traîne dans à peu près tous les articles écrits sur le sujet et qui induit deux contresens d'affilée. Le premier sur la nature de l'index : ce n'est pas un moteur de pages, c'est un catalogue de services, et on n'y cherche pas des mots mais des empreintes techniques. Le second sur l'usage. Un moteur qui montre ce que le monde voit de vos machines sert d'abord à contrôler votre propre exposition, et c'est l'usage majoritaire dans une équipe sécurité. Encore faut-il savoir lire ce qu'il renvoie, parce qu'un résultat Shodan répond rarement à la question qu'on croit lui avoir posée.
La ligne juridique, à poser tout de suite
Une bannière, pas une page web
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.
La conséquence pratique est structurante : 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.
ENREGISTREMENT SHODAN = un service, une mesure, une date
------------------------------------------------------------
ip_str 203.0.113.10
port 443
transport tcp
timestamp 2026-09-14T04:11:52.284000 <- a lire EN PREMIER
hostnames [ www.exemple.com ] <- PTR + noms vus au passage
org Exemple Hosting SAS <- proprietaire du BLOC IP
asn AS64500 (souvent l'hebergeur)
data HTTP/1.1 200 OK <- le TEXTE BRUT
Server: nginx/1.18.0 c'est la-dedans que
Content-Type: text/html cherche une requete
... sans filtre
product nginx <- champ DEDUIT du texte
version 1.18.0 <- deduit aussi : une
banniere se falsifie
ssl.cert subject.cn = exemple.com
issuer.cn = R11
expired = falseLa 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.
Comment Shodan collecte, étape par étape
Le mécanisme est plus simple qu'on ne l'imagine, et c'est justement 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 digne de ce nom : 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.
Forcer une mesure fraîche
scan avec l'identifiant renvoyé. Deux contraintes à connaître : la fonction exige un plan payant, et une adresse récemment parcourue ne peut pas être re-scannée avant vingt-quatre heures. Ne demandez évidemment ce balayage que sur des adresses dont vous avez la responsabilité : c'est un scan actif, avec des paquets réels vers la cible, et il n'a rien de passif.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:6379Lire 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:trueSurveiller 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:trueDater 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/2026Les deux filtres qui ne répondront pas chez vous
vuln, qui filtre sur une CVE précise, et tag. La page tarifaire est explicite sur le seuil : vuln demande au moins le plan Small Business, tag le plan Corporate. La conséquence est vicieuse : une requête copiée sur un blog peut ne rien renvoyer chez vous, non parce qu'elle est fausse, mais parce que votre compte n'a pas le droit de l'exécuter. Un résultat vide n'est pas une réponse. Notez au passage l'asymétrie utile : has_vuln, lui, n'est pas restreint. Vous pouvez donc demander quels hôtes de votre bloc portent au moins une vulnérabilité connue (net:203.0.113.0/24 has_vuln:true) sans pouvoir demander lesquels sont vulnérables à telle CVE.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 précisément 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 vraiment
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.
| Moteur | Origine | Modèle de données | Ce qu'il fait le mieux | Réserve |
|---|---|---|---|---|
| Shodan | John Matherly, 2009, États-Unis | La bannière comme unité de base | La diversité des protocoles non web : industriel, embarqué, bases de données, ports exotiques | Champs déduits faillibles, attribution organisationnelle faible |
| Censys | Équipe ZMap, université du Michigan, États-Unis | L'hôte et le certificat comme entités de premier rang | Le pivot par certificat : d'une empreinte vers toutes les machines qui la présentent. Annonce un re-scan quotidien de tout service vu il y a plus de 24 h | Palier gratuit à 100 crédits par mois, soit environ 20 recherches. L'ancienne interface et sa syntaxe sont en fin de vie |
| FOFA | Chine | Proche de Shodan, orienté empreintes web | Une couverture qui déborde parfois là où les deux autres sont pauvres | Palier gratuit affiché comme non commercial. Juridiction hors UE, sans décision d'adéquation : à arbitrer consciemment |
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.
La conclusion honnête, c'est qu'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, et elle est structurelle : le moteur indexe des adresses, pas des organisations. Le champ org décrit le propriétaire du bloc, qui est votre hébergeur neuf fois sur dix. 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.
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 tient une place dans cette chaîne ; il en occupe un maillon, celui de la mesure brute.
Questions fréquentes sur Shodan
Shodan, c'est quoi exactement ?
Shodan est un moteur de recherche d'appareils et de services connectés à Internet, lancé par John Matherly en 2009. Contrairement à un moteur web, il n'indexe pas le contenu des pages : il balaie en continu l'espace d'adressage, se connecte aux ports qui répondent et enregistre la bannière du service, c'est-à-dire les métadonnées que ce service annonce à tout client qui se présente. Un enregistrement Shodan est donc une mesure datée : une adresse IP, un port, la réponse brute du service, et un ensemble de champs déduits de cette réponse comme le produit, la version ou le certificat TLS. La documentation officielle indique que l'ensemble d'Internet est parcouru au moins une fois par semaine.
Est-il légal d'utiliser Shodan en France ?
Consulter Shodan est licite : le moteur publie des informations que les services concernés diffusent eux-mêmes à quiconque s'y connecte. La frontière se situe à la requête suivante. Si une bannière révèle un identifiant constructeur ou une interface d'administration sur un système qui ne vous appartient pas, tenter de vous y connecter constitue un accès frauduleux à un système de traitement automatisé de données, puni par l'article 323-1 du code pénal de trois ans d'emprisonnement et de 100 000 euros d'amende, et de cinq ans et 150 000 euros si des données ou le fonctionnement du système en sont altérés. La Cour de cassation a jugé le 20 mai 2015, dans l'affaire dite Bluetouff, qu'un document atteignable depuis un moteur de recherche n'emporte aucun droit d'y accéder ni de s'y maintenir. L'accessibilité de fait ne vaut pas autorisation.
Shodan est-il gratuit ?
Partiellement, et moins qu'on ne le croit. Sans être connecté, une recherche contenant le moindre filtre est refusée : le moteur répond qu'il faut se connecter pour utiliser les filtres. Un compte gratuit débloque la recherche filtrée et un accès de base à l'API, mais l'usage sérieux passe par un compte payant. Au 16 août 2026, la page tarifaire officielle affiche une adhésion à vie à 49 dollars en paiement unique, qui donne 100 crédits de requête et 100 crédits de scan par mois, puis des abonnements mensuels Freelancer à 69 dollars, Small Business à 359 dollars et Corporate à 1 099 dollars. Un crédit de requête correspond à 100 résultats téléchargés, un crédit de scan à une adresse IP soumise au balayage à la demande. Ces montants évoluent : vérifiez-les sur le site officiel avant de bâtir un budget dessus.
Les résultats de Shodan sont-ils à jour ?
Pas forcément, et c'est la première chose à vérifier. Shodan répond depuis son index, pas depuis la machine : un résultat est une mesure prise à un instant donné, dont l'horodatage figure dans l'enregistrement. Comme la documentation annonce un parcours complet d'Internet au moins hebdomadaire, une bannière peut avoir plusieurs jours ou plusieurs semaines. Conséquence directe : un service fermé depuis peut encore apparaître, et un service ouvert ce matin n'y figure pas encore. Pour obtenir une mesure fraîche, il faut demander un balayage à la demande, qui consomme un crédit de scan par adresse et renvoie ses résultats de façon asynchrone.
Quelle différence entre Shodan et Censys ?
Les deux balaient Internet et publient un index de ce qui répond, mais leur modèle de données diffère. Shodan raisonne bannière par bannière et excelle sur la diversité des protocoles non web, notamment les protocoles industriels et les équipements embarqués. Censys, issu des travaux de l'équipe ZMap de l'université du Michigan, structure sa donnée autour de l'hôte et du certificat, ce qui le rend particulièrement efficace pour pivoter d'un certificat TLS vers toutes les machines qui le présentent. En pratique, un inventaire sérieux interroge les deux, parce que leurs angles morts ne se recouvrent pas. Un troisième moteur, FOFA, opéré depuis la Chine, couvre parfois des plages que les deux autres traitent mal, mais soumettre son périmètre à une plateforme relevant d'une juridiction hors Union européenne mérite d'être arbitré consciemment.
Shodan suffit-il à connaître sa surface d'attaque ?
Non, et pour une raison structurelle : Shodan répond sur ce qu'il a observé depuis l'extérieur pour une adresse IP donnée. Il ne sait pas ce qui vous appartient. Le champ org d'un enregistrement décrit le propriétaire du bloc d'adresses, souvent un hébergeur mutualisé ou un fournisseur cloud, pas l'entité qui exploite le service. Le moteur ne rattache donc pas les actifs à une organisation de façon fiable, il ne construit pas votre périmètre à partir de votre nom, et son index principal ne conserve pas l'historique de vos changements. Il constitue une excellente source ponctuelle dans une chaîne de découverte, pas un inventaire.
À retenir
- 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 famillessl. Ajoutez-ybeforeetafterau 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.
Articles liés
appsec
EASM : qu'est-ce que la gestion de surface d'attaque externe ?
L'EASM en clair : définition, fonctionnement, et ce qui le distingue d'un scanner ou d'un pentest. Comment cartographier votre surface d'attaque externe et qui en a besoin.
appsec
Découverte d'actifs (asset discovery) : cartographier sa surface d'attaque externe
L'asset discovery en pratique : énumération de sous-domaines, ASN, scan de ports, actifs cloud et shadow IT pour cartographier votre surface d'attaque externe.
appsec
Certificate Transparency : débusquer le shadow IT par les certificats partagés
Chaque certificat TLS émis finit dans un journal public et permanent. En pivotant sur les certificats partagés (mêmes SAN, même empreinte), on relie des actifs inconnus à un périmètre connu. La technique de recon par Certificate Transparency, côté EASM/NIS2 et bug bounty.