Censys, Onyphe, Shodan : ce qu'un index d'exposition voit de vos serveurs, et ce
qu'il rate

L'espace IPv4 tient dans environ 4,3 milliards d'adresses. C'est assez petit pour qu'une infrastructure bien dimensionnée frappe à chaque porte en une journée, et c'est ce que font Censys, Shodan et Onyphe : ils balaient l'Internet public et publient un index de ce qui répond, sur quel port, avec quelle bannière. Avant de scanner quoi que ce soit, vous pouvez donc lire ce qu'ils ont déjà noté sur vous. Reste une question que les articles sur ces outils ne posent jamais : ce qu'ils notent, est-ce juste ?

Je l'ai vérifié sur le seul terrain où la vérité est connue, mes propres machines. Le 7 octobre 2026, j'ai interrogé l'index gratuit de Shodan, InternetDB, sur les trois serveurs d'own2pwn et sur scanme.nmap.org, puis j'ai comparé sa réponse à un scan nmap complet et à la configuration réelle des hôtes. Résultat en une ligne : 15 ports exposés sur 18 retrouvés, un seul port périmé, mais aucune date dans la réponse, un nom d'hôte sur sept, et une partie des CVE affichées qui ne concernent pas le logiciel identifié. Le détail, puis ce que ça implique pour le choix entre les trois moteurs.

La mesure : un index gratuit face à quatre machines dont on connaît la vérité

Shodan propose, à côté de son moteur payant, InternetDB, une API gratuite et sans clé qui renvoie pour une adresse IP six champs seulement : les ports, les CPE (le logiciel et sa version, déduits de la bannière), les CVE, les noms d'hôte, des étiquettes et l'IP elle-même. C'est ce que la plupart des outils gratuits interrogent quand ils affichent "vu par Shodan".

En face, la réalité. Pour nos trois serveurs (production, serveur annexe et un troisième), nmap a balayé les 65 535 ports TCP depuis un accès résidentiel français, puis identifié les versions, et j'ai relu en SSH les ports en écoute, le pare-feu et les conteneurs. Pour l'UDP, qu'un scan externe distingue mal, la vérité vient de la configuration : un port compte s'il écoute publiquement et que le pare-feu le laisse passer. Pour scanme.nmap.org, faute d'accès à l'hôte, la réalité se limite aux 1 000 ports TCP les plus courants, plus deux ports connus et NTP en UDP, en un seul passage. Les versions annoncées ont ensuite été rapprochées des configurations de la NVD (miroir du 6 octobre 2026).

15 ports exposés sur 18 retrouvés, et trois manques qui n'ont rien d'exotique

Sur les quatre machines, 18 ports étaient réellement exposés le jour de la mesure. InternetDB en listait 15, soit 83,3 %. Sur nos trois serveurs seuls, 12 sur 14 (85,7 %). Dans l'autre sens, il n'a listé qu'un port fermé sur les 16 qu'il annonçait, ce qui est peu. La couverture est donc bonne, et l'intérêt est dans ce qui manque.

Le premier manque n'en est pas vraiment un. Notre OpenVPN est configuré pour ignorer tout paquet qui ne porte pas la bonne signature, et aucun scanner externe ne peut donc le voir, pas plus Shodan que nmap. Le compter comme un défaut de l'index serait injuste : sans lui, le taux passe à 15 sur 17, soit 88,2 %. Je donne les deux chiffres, parce que l'un mesure ce que voit l'index et l'autre ce qu'un index peut voir.

Le deuxième manque est plus instructif. C'est un service TCP qui envoie sa bannière dès la connexion, ouvert depuis au moins 64 jours, autrement dit exactement ce que Shodan sait collecter. Il n'y figurait pas. Avec un parcours annoncé hebdomadaire, on aurait pu l'attendre ; la réponse gratuite ne permet pas de savoir s'il a été sondé et oublié, ou jamais sondé.

Une IP, pas un périmètre

Notre serveur de production répond sous 7 noms publics, visibles dans les journaux de transparence des certificats (Certificate Transparency), qui servent 6 applications distinctes derrière le même reverse proxy. InternetDB en associait un seul à l'adresse. Rien de surprenant pour un index qui raisonne par IP, mais la conséquence est pratique : une recherche par nom de domaine dans un moteur d'exposition ne remonte qu'une partie de ce qui tourne réellement, et les applications hébergées derrière une même adresse se fondent en une seule ligne.

Aucune date dans la réponse

La réponse d'InternetDB ne contient aucun champ de date. On lit des ports et des CVE sans savoir quand ils ont été observés. Seul indice indirect, la mise à jour des CVE : deux failles Apache publiées le 1^er octobre 2026 et analysées par la NVD le 2 figuraient bien dans l'enregistrement IPv4 de scanme le 7, mais pas dans son enregistrement IPv6, ni dans celui d'une autre cible de test Apache. Une même machine, deux états selon l'adresse : sur 3 enregistrements Apache, 1 seul était à jour. L'API payante de Shodan horodate chaque service ; si vous travaillez avec la version gratuite, considérez chaque résultat comme d'âge inconnu.

Les CVE affichées : complètes sur Apache, absentes sur OpenSSH, parfois sans fondement

C'est la partie la plus utile de l'exercice, parce que les CVE affichées par ces moteurs finissent souvent telles quelles dans un rapport. Pour chaque version qu'InternetDB annonçait, j'ai compté les CVE de la NVD dont la plage de versions vulnérables couvre cette version, et combien l'index en listait.

Sur Apache et PHP, l'index est presque complet. Sur PHP 7.1.26, il ne manque rien. Sur Apache, les CVE manquantes (13 pour la version 2.4.7, 15 pour la 2.4.25) ont toutes été publiées le 1^er octobre et analysées par la NVD entre le 2 et le 5 octobre : c'est un retard de quelques jours, pas un trou. Sur OpenSSH 6.6.1p1, en revanche, InternetDB annonce bien le logiciel et sa version, mais ne liste aucune des 47 CVE en plage.

OpenSSH : les versions de distribution sans CVE

J'ai d'abord cru à une particularité de scanme. Pour le vérifier, j'ai lu dans InternetDB, sans me connecter à aucune machine, les enregistrements de neuf serveurs publics tiers dont le SSH est ouvert, en plus de scanme et de nos deux serveurs à SSH public. Douze machines en tout, pour lesquelles l'index annonce une version d'OpenSSH.

Sur cet échantillon, aucune des 7 versions portant le suffixe p1, celles que livrent les distributions Linux, n'a de CVE OpenSSH listée, alors que la NVD en compte au moins une vingtaine dans la plage de chacune. Trois des cinq machines à version sans suffixe en ont, 24, 19 et 6. La cause n'est pas observable depuis l'index : prudence délibérée face aux correctifs rétroportés par les distributions, ou défaut d'appariement de la version. Si c'est de la prudence, elle n'est pas uniforme, puisque Apache, annoncé "(Ubuntu)" sur scanme, reçoit ses CVE. Douze machines choisies par commodité ne permettent pas de généraliser ; elles suffisent à ne pas lire un "0 CVE" comme un certificat de bonne santé.

Le rétroportage, je peux en revanche le mesurer chez nous. Notre OpenSSH s'annonce en 9.6p1 : un outil qui rapproche la bannière de la NVD par version retiendrait 22 CVE. Le journal des modifications du paquet Ubuntu installé en cite 19 comme corrigées. Des 3 restantes, une ne concerne que des paquets Red Hat, une suppose le module OPIE configuré dans PAM, et la dernière est contestée par les développeurs d'OpenSSH.

17 CVE sur 122 qui ne visent pas Apache

Dernier constat, le plus gênant pour qui recopie ces listes. Pour scanme, InternetDB affiche 122 CVE, toutes rattachées à Apache 2.4.7. Pour 105, la NVD place bien la version dans sa plage. Pour les 17 autres, soit 13,9 %, la NVD ne cite Apache que comme plateforme non vulnérable : la faille est dans un module ou un logiciel distinct (mod_auth_openidc, mod_pagespeed, ModSecurity, mod_fcgid, un agent d'authentification tiers...) dont rien dans la bannière Apache/2.4.7 ne dit s'il est installé. J'ai vérifié six de ces fiches une par une dans la NVD en ligne. Prouver que ces modules sont absents de la machine demanderait d'y avoir accès, je ne l'affirme donc pas : ce sont des attributions infondées, des CVE qui ne concernent pas le logiciel identifié. Sur rest.vulnweb.com (Apache 2.4.25 et PHP 7.1.26), la proportion est la même, 19 sur 142, soit 13,4 %.

Un moteur de recherche pour hacker indexe des services, pas des pages

Ces écarts se comprennent mieux quand on se rappelle ce que ces moteurs collectent. On les surnomme volontiers "le Google des hackers", et l'image induit un contresens. Google parcourt le web, des pages reliées par des liens. Un moteur d'exposition parcourt l'Internet, c'est-à-dire des services qui écoutent sur des ports. Quand un serveur SSH accepte une connexion, il annonce sa version. Un serveur web renvoie un en-tête Server: et un certificat TLS. Cette réponse s'appelle la bannière, et tout ce que l'index sait d'une version vient d'elle. C'est aussi la matière première de tout travail d'renseignement en source ouverte (OSINT) sur une infrastructure.

Censys : la profondeur en ports et le culte du certificat

Censys est, sur le papier, le plus systématique des trois. Sa documentation revendique un balayage continu des 65 535 ports de l'espace IPv4, avec détection de protocole pour reconnaître un service même sur un port non standard, un catalogue de plus de 3 milliards de services, et un rescan de tout service observé depuis plus de 24 heures, pour un âge moyen d'environ 16 heures sur les services qu'il juge les plus importants. Je n'ai pas pu le vérifier faute de clé : c'est exactement la mesure à refaire, parce qu'un service TCP bavard ouvert depuis deux mois, comme celui qu'InternetDB a manqué, ne devrait pas lui échapper si ces chiffres tiennent.

L'autre marque de fabrique de Censys, c'est le traitement des certificats TLS comme objet de recherche à part entière. Chaque certificat croisé pendant le scan est indexé, ce qui permet de pivoter d'un certificat vers toutes les machines qui le présentent, ou d'un nom de domaine vers les certificats émis pour lui. C'est la réponse au problème "une IP, pas un périmètre" mesuré plus haut : on part des noms, pas des adresses. La syntaxe est structurée par champs.

# Un port précis, sur une plage d'adresses que vous possédez
services.port: 3389 and ip: 203.0.113.0/24

# Les services RDP exposés situés en France
services.service_name: RDP and location.country: France

La logique "un champ, une valeur" se combine avec and et or. On raisonne en propriétés du service (nom, port, version, certificat, localisation), pas en mots-clés, ce qui rend Censys efficace pour la découverte d'actifs d'un périmètre : on part d'un attribut connu et on déroule tout ce qui le partage.

Shodan : la profondeur applicative, et deux portes d'entrée

Shodan collecte des bannières depuis 2009 et annonce parcourir l'Internet entier chaque semaine. Il compense un rythme plus lent par la richesse de ce qu'il expose et par des filtres qui descendent loin dans l'applicatif : titre HTML d'une page, hash d'un favicon, empreinte JARM d'une pile TLS, capture d'écran d'un service graphique. Il faut simplement savoir par quelle porte on entre. Le moteur complet, avec un compte, horodate chaque bannière. InternetDB, la porte gratuite que j'ai mesurée, résume une IP en six champs sans date.

# Toutes les machines présentant un certificat pour votre domaine
ssl.cert.subject.CN:"votre-domaine.fr"

# Pivoter sur l'empreinte d'un favicon pour retrouver les hôtes jumeaux
http.favicon.hash:<empreinte_mmh3>

Le hash de favicon illustre bien la logique Shodan : deux serveurs qui servent la même icône ont de fortes chances d'appartenir à la même organisation, même sans nom ni IP en commun. Pour la syntaxe des filtres, la lecture de la fraîcheur et les usages défensifs, voir l'article dédié à Shodan et à ses requêtes.

Onyphe : le regard français, découpé en catégories métier

Onyphe est édité par une société française, et sa structure diffère des deux autres. Là où Censys et Shodan exposent un grand index unifié, Onyphe découpe sa donnée en catégories orientées défense qu'on interroge séparément : datascan pour les services et leurs bannières, ctl pour la transparence des certificats, vulnscan et riskscan pour les expositions à risque. Comme pour Censys, je ne l'ai pas mesuré, et je me garde donc de reprendre ici ses chiffres de couverture.

# Services RDP vus en France dans la catégorie de scan
category:datascan protocol:rdp country:FR

# Certificats émis pour votre domaine (transparence)
category:ctl host:votre-domaine.fr

Ses catégories vulnscan et riskscan font une partie du tri entre "exposé" et "à risque", ce qui rejoint la logique de la gestion des vulnérabilités. Les 17 CVE sur 122 mesurées plus haut rappellent seulement qu'un classement automatique par bannière se vérifie avant d'être cru, quel que soit le moteur qui le produit.

De la bannière au CVE : ce que l'index ne fait pas pour vous

Prenez un cas concret. Un moteur signale un RDP ouvert, un autre confirme le port 3389. Vous savez que la porte existe, pas si elle est fragile. Un poste Windows non corrigé qui expose RDP peut être vulnérable à CVE-2019-0708, la faille "BlueKeep" divulguée en mai 2019, une exécution de code à distance sans authentification dans les services Bureau à distance. Mais la mesure l'a montré dans les deux sens : un index peut taire des CVE en plage (les versions de distribution d'OpenSSH de l'échantillon) et en afficher qui ne concernent pas le logiciel (17 sur 122 sur scanme). Il faut relier la bannière à la CVE, puis vérifier que la cible est concernée.

C'est l'étape que ces moteurs laissent à votre charge, et celle qui sépare une liste d'expositions d'un plan de remédiation. Corréler une bannière ou une version à une CVE connue, puis hiérarchiser par exploitabilité réelle, c'est le travail du module pentest automatisé de l'EASM own2pwn, qui embarque plus de 240 modules de détection et fait cette corrélation en continu, sans jamais chercher à exploiter la cible.

Utiliser ces moteurs pour votre propre surface d'attaque

L'usage majoritaire de ces outils en défense n'est pas d'aller regarder les autres, c'est de se regarder soi, du dehors, ce que décrivent les cinq étapes d'un EASM. On part du domaine, on récupère les certificats émis pour lui via la transparence, on obtient une liste de sous-domaines, puis on interroge chaque moteur sur ces noms et sur les plages d'adresses que l'on possède. La mesure suggère trois réflexes.

• Comparer à votre propre scan. Sur nos machines, l'index retrouvait 15 ports sur 18. Un port qui manque à l'index n'est pas un port caché : il est seulement absent d'une base parmi d'autres, et un attaquant qui scanne lui-même le trouvera.
• Partir des noms, pas des IP. Un nom d'hôte sur sept associé à notre serveur de production : l'inventaire se construit à partir des certificats et du DNS, et les moteurs servent ensuite à qualifier ce qui répond.
• Recompter les CVE. Une liste de CVE issue d'une bannière est une hypothèse à trier contre la NVD et contre le paquet réellement installé, jamais un constat à recopier.

Ce déroulé recoupe des chantiers détaillés ailleurs : la chasse au shadow IT par les journaux de transparence, la détection des fuites de secrets et l'outillage assemblé dans un framework d'outils OSINT. La limite de l'exercice manuel : c'est une photo prise un jour donné, et dans le cas d'InternetDB une photo sans date. Passer de la photo au film, c'est interroger ces sources en continu et alerter sur les écarts, ce que fait la surveillance de surface d'attaque plutôt que de relancer les mêmes requêtes tous les trimestres.

À retenir

• Bonne couverture, pas exhaustive. Shodan InternetDB listait 15 des 18 ports exposés sur quatre machines (83,3 %), 15 sur 17 (88,2 %) sans l'OpenVPN muet qu'aucun scanner ne peut voir, et un seul port périmé. Quatre machines ne décrivent pas Internet.
• Aucune date dans la réponse gratuite. L'âge d'un résultat InternetDB n'est pas lisible, et une même machine peut avoir un enregistrement à jour en IPv4 et pas en IPv6.
• Une IP, pas un périmètre. Un nom d'hôte sur sept rattaché à notre serveur de production. L'inventaire part des noms.
• Des CVE à recompter. 17 sur 122 attribuées sans fondement sur scanme, et aucune CVE OpenSSH sur les 7 versions de distribution de notre échantillon. Exposition n'est pas vulnérabilité.
• Censys et Onyphe restent à mesurer. Leurs chiffres de couverture sont ceux de leur documentation. L'union de plusieurs sources vaut mieux qu'une seule, à condition de vérifier chacune.

Ces moteurs sont d'excellents révélateurs, gratuits à interroger pour un usage modeste. Leur limite est structurelle : ils montrent des expositions sans dire lesquelles comptent pour vous, ni quand une nouvelle apparaît, et ils peuvent se tromper sur les CVE. Si vous voulez que ce travail tourne seul, agrège les sources, corrèle les bannières aux CVE et vous alerte sur les écarts, c'est ce que fait la surveillance de surface d'attaque externe d'own2pwn. Et si vous préférez qu'un humain regarde votre périmètre en conditions réelles avant de trancher, il suffit de nous décrire votre contexte.

Questions fréquentes sur Censys, Onyphe et Shodan