Sources de données

En bref

Pour surveiller une entreprise, le programme de monitoring interroge des services extérieurs : sous-domaines, certificats, DNS, réputation des adresses IP. Cette page dit quel service fournit quelle donnée, ce qu’il coûte et ce qui se passe quand il manque. À retenir : si une clé manque ou si le quota est épuisé, la source se tait sans alerte. Les noms de domaine et les adresses IP surveillés, prospects compris, sont envoyés à ces tiers.

Les fuites et les vulnérabilités sont dans Sources : fuites et vulnérabilités. Les scanners sont décrits dans Scanners, les horaires dans Planification. Les noms techniques des sources et des clés sont dans la correspondance technique en bas de page.

Tableau récapitulatif

Source	Ce qu’on y prend et pourquoi	Accès et coût	Si la source ou la clé manque
Shodan (interface payante)	Ports ouverts, failles connues, noms DNS du domaine, IP trouvées par certificat. Sert au scan de ports, à la découverte et à la couverture Shodan	Clé payante : 1 requête par seconde, crédits du forfait	Scan de ports et couverture Shodan sautés ; la découverte se fait sans Shodan
Shodan InternetDB	Ports, étiquettes, produits et failles par IP. Seule source de ports des prospects	Sans clé, gratuit	Erreur passagère, nouvel essai
CertSpotter	Certificats émis pour un domaine. Sert à la découverte, au contrôle des certificats et à la surveillance des nouveaux certificats	Gratuit : 75 requêtes par heure et par IP sans clé ; clé optionnelle	Si CertSpotter refuse (429), crt.sh prend le relais pour la découverte et les certificats ; la surveillance des nouveaux certificats s’arrête
crt.sh	Solution de repli : sous-domaines et certificats	Sans clé, gratuit	Ignoré en flash scan ; s’il échoue aussi, la découverte échoue avec « toutes les sources ont échoué »
HackerTarget	Sous-domaines	Gratuit, quota anonyme faible ; clé optionnelle	Quota dépassé : lu comme un échec
Chaos (ProjectDiscovery)	Sous-domaines des clients monitorés	Clé requise, coût non précisé	Source sautée
SecurityTrails	Sous-domaines des clients monitorés	Plan gratuit : 50 crédits par mois, arrêt à 45	Source sautée
DNS public de Cloudflare	Enregistrements DNS et DNSSEC, pour presque tous les scanners	Sans clé, gratuit	Une panne donne une réponse vide, lue comme « aucun enregistrement »
Annuaires officiels des domaines (RDAP)	Dates, statuts, domaine libre ou non. Sert au contrôle d’expiration et à la reprise de sous-domaine	Sans clé, gratuit	Le scanner signale une erreur
AbuseIPDB	Score d’abus par adresse IP	Clé payante, plafond quotidien du plan	Scanner sauté ; au refus (429), le lot s’arrête
GreyNoise Community	Classification de l’IP	Clé, gratuit dans le quota Community	Ignoré, le scan continue
Google Web Risk	Verdict de malware ou d’hameçonnage par domaine	Clé, gratuit sous 100 000 appels par mois, 600 par jour	Vérification sautée
Projet Tor	Liste des sorties Tor	Sans clé, gratuit, 1 appel par semaine	La liste précédente est conservée
Cloudflare (temps de navigateur)	Mesure du temps de navigateur consommé, pour le rendu des pages	Inclus au forfait, plafond de 8 h par mois	Aucun rendu par navigateur (par prudence)

Fiches

Seulement ce que le tableau ne dit pas.

• Shodan. Pause de 60 s sur un refus de quota ; un refus d’identification rend la clé invalide. Chaque nuit à 02:45 UTC, 500 IP au plus sont traitées ; les rescans se limitent aux crédits du mois divisés par les jours restants. Risque : la clé voyage dans l’adresse de la requête, les IP des clients sont envoyées à Shodan et le rescan les fait scanner.
• InternetDB. Les adresses sont publiques : aucun risque.
• CertSpotter. Le quota anonyme est partagé par toutes les tâches et par la sonde de santé. La surveillance des nouveaux certificats n’a aucun repli : elle s’arrête au premier refus.
• SecurityTrails. Une seule tentative par domaine monitoré, sans nouvel essai en cas d’échec.
• DNS de Cloudflare. Aucun résolveur de repli. Une panne se distingue d’un domaine inexistant. Risque : tous les noms interrogés, prospects compris, passent par un tiers.
• AbuseIPDB. Toutes les 4 heures, 50 IP au plus (10 par client). Le flash scan ignore le coffre à clés et un fournisseur désactivé : il ne lit que la clé de secours.
• Google Web Risk. 25 hôtes par heure, chaque hôte une fois par semaine. Clé refusée : invalide ; quota atteint : pause d’1 h. Risque : chaque nom d’hôte client est communiqué à Google.
• Cloudflare (navigateur). Le balayage mensuel n’utilise que 80 % du plafond au rythme du mois. Si la consommation est illisible, aucun rendu n’est lancé.
• Jeux de données embarqués. Règles de détection, fin de vie des logiciels, plages du réseau CloudFront : aucun appel en cours de route, mais ils vieillissent tant que personne ne les régénère.
• Sondes de santé. Sept sondes (Shodan, AbuseIPDB, Intelligence X, DNS de Google, CertSpotter, IANA, ransomware.live) alimentent la page d’état. Le backend les garde en mémoire 60 à 180 s (1 à 2 h pour ransomware.live).

flowchart LR
    start["Découverte des<br/>sous-domaines"]
    mon{"Client<br/>monitoring ?"}
    anon["CertSpotter et HackerTarget<br/>sans clé"]
    keyed["Cinq sources en parallèle<br/>(clés du coffre)"]
    any{"Une source<br/>a répondu ?"}
    union["Union sans doublons"]
    crt["crt.sh<br/>(pas en flash)"]
    fail["Échec : aucune source<br/>(nouvel essai)"]
    start -->|"teste"| mon
    mon -->|"non"| anon
    mon -->|"oui"| keyed
    anon -->|"répondent"| any
    keyed -->|"répondent"| any
    any -->|"oui"| union
    any -->|"non"| crt
    crt -->|"échoue"| fail
    crt -->|"répond"| union
    classDef action fill:#ffe86d,stroke:#a28e26,color:#574900
    classDef status fill:#9ce6ff,stroke:#2c97bb,color:#1c4657
    classDef done fill:#b3e65f,stroke:#6f9a24,color:#2c4300
    classDef problem fill:#ffb575,stroke:#b8742f,color:#5a2d00
    classDef external fill:#e5e7eb,stroke:#9ca3af,color:#374151
    class start,anon,keyed,crt external
    class mon,any status
    class union done
    class fail problem

Pour un client monitoré, cinq sources sont interrogées ; sinon deux, sans clé. crt.sh n’intervient que si aucune n’a répondu.

Coffre à clés

• Choix de la clé. Le scanner demande sa clé au coffre. Fournisseur désactivé : aucune clé. Sinon le coffre prend une clé active, hors pause et sous 90 % de son quota, selon la stratégie de répartition du fournisseur. Des clés mais aucune utilisable : le scanner attend, il ne bascule pas. Aucune clé dans le coffre : la clé de secours sert.
• Clés de secours. Quatre fournisseurs seulement en ont une : Shodan, Intelligence X, AbuseIPDB et GitHub. Les huit autres n’existent que dans le coffre.
• Retours au coffre. Clé refusée : marquée invalide. Quota épuisé : pause jusqu’à la réinitialisation (sinon 1 h). Une panne du fournisseur ne pénalise jamais la clé. Toutes les 6 heures, l’usage réel de Shodan et d’Intelligence X est relu.
• Sans la clé de chiffrement du coffre. Le coffre est ignoré, les clés de secours servent, et enregistrer une nouvelle clé est refusé.
• Révélation d’une clé. Page admin des clés : mot de passe actuel exigé, 10 par minute, chaque révélation est journalisée.
• Rotation. Ajouter la nouvelle clé, puis désactiver l’ancienne. Inventaire : Secrets et clés.

Règles et pièges

• Une clé absente ne déclenche aucune alerte : seules les sondes de santé et les journaux le montrent.
• Si Chaos ou Shodan répondent « zéro sous-domaine », cela compte comme une réponse : crt.sh n’est alors pas tenté, même si CertSpotter et HackerTarget ont échoué.
• Les contrôles de certificats et la surveillance des nouveaux certificats ne signalent jamais au coffre un refus de clé ou de quota ; seule la découverte le fait.
• Le scanner de stockages cloud dépose puis supprime un fichier test chez des tiers, prospects compris. Seul le flash scan s’en abstient.
• Le droit de gérer les clés est réservé à une seule adresse e-mail, écrite en dur dans le backend.

Correspondance technique

Nom courant	Identifiant technique
Shodan, clé du coffre ou de secours	shodan, SHODAN_API_KEY
Intelligence X, clé de secours	intelx, INTELX_API_KEY
AbuseIPDB, clé du coffre ou de secours	abuseipdb, ABUSEIPDB_API_KEY
GitHub, clé de secours	github, GITHUB_TOKEN
CertSpotter, HackerTarget, Chaos, SecurityTrails	certspotter, hackertarget, chaos, securitytrails
GreyNoise, Google Web Risk	greynoise, google_web_risk
Cloudflare (temps de navigateur)	CLOUDFLARE_API_TOKEN, CLOUDFLARE_ACCOUNT_ID
Clé de chiffrement du coffre	KEY_VAULT_KEY
Scan de ports, découverte	port_scan, discovery
Ports gratuits (prospects), réputation des IP	internetdb, ip_reputation
Contrôle des certificats, surveillance des nouveaux certificats	ssl, ct_log
Contrôle d’expiration, reprise de sous-domaine	whois, subdomain_takeover
Stockages cloud	cloud_buckets

Où dans le code

• monitoring/src/platform/keyvault/index.ts (choix de la clé), monitoring/src/platform/db/apiKeys.ts
• monitoring/src/pipelines/asset-scanners/discovery/scan.ts (cinq sources et repli)
• backend/app/Http/Controllers/Admin/ApiKeyController.php

Questions ouvertes

• Quels plans et quels prix réels pour AbuseIPDB, GreyNoise, Chaos, HackerTarget et CertSpotter ? Le code ne les dit pas.
• La licence GPL-3.0 des règles de détection des technologies (webappanalyzer) est-elle compatible avec un programme propriétaire ?
• Quels contrats de traitement lient Inqase à Shodan, Google et Cloudflare pour les noms de domaine de clients ?
• Qui d’autre que le propriétaire de l’adresse codée doit pouvoir gérer les clés ?