Comment enquêter sur une adresse IP : 3 IP réelles, 3 verdicts

Le 19 octobre 2026 à 05:34 UTC, nous avons fait passer trois adresses dans le même pipeline et obtenu trois verdicts différents. Une sortie VPN Mullvad a obtenu 100, block. Une adresse AhrefsBot vérifiée a obtenu 59, step_up, parce que Spamhaus la liste. Un serveur DigitalOcean a obtenu 12, allow. Onze jours plus tôt, cette même adresse AhrefsBot obtenait 23, allow.

Vous trouverez ci-dessous les douze vérifications dans l'ordre, le champ à lire à chaque étape, les seuils sur lesquels nous agissons, où signaler les abus, et la limite légale de toute enquête IP.

Comment enquêter sur une adresse IP : trois adresses, trois verdicts

Les mêmes douze questions ont conduit trois adresses vers trois actions différentes, et dans chaque cas un seul signal a tranché. Il s'agit de requêtes sans clé sur notre API, enregistrées aux heures indiquées, valeurs non modifiées :

Nos tranches sont : allow jusqu'à 25, review jusqu'à 50, step_up jusqu'à 75 et block au-delà de 75. L'ordre des vérifications est le suivant : routabilité, propriétaire, type de réseau, nom d'hôte, anonymisation, robot d'exploration ou scanner, listes de blocage, score, décision, signalement, expiration et limite légale.

La ligne du milieu est la leçon. Un robot d'exploration vérifié peut tout de même figurer sur une liste de blocage, et la remise accordée aux robots d'exploration dans notre score ne l'a pas maintenu en allow.

Avant de commencer : restez passif et notez où l'IP est apparue

Notez le contexte de l'alerte avant de rechercher quoi que ce soit : l'horodatage avec son fuseau horaire, le port ou le chemin touché, et ce que l'adresse a fait, par exemple des sondages de /wp-admin ou de /.env, ou une rafale de connexions échouées. Ce contexte pèse autant dans le verdict que n'importe quelle requête.

Restez passif : utilisez des requêtes, des registres et des sites de réputation, et ne scannez jamais l'adresse en retour. Un scan de ports peut alerter la personne qui gère l'hôte, et scanner un réseau sans autorisation peut enfreindre la loi ou les conditions de votre fournisseur.

Étape 1 : est-ce une adresse publique routable ?

Vérifiez que l'adresse a bien pu vous atteindre via Internet. Lisez threat.is_bogon et threat.is_cgnat. Un bogon est une adresse qui ne devrait jamais apparaître sur l'Internet public, comme une plage privée ou réservée. Si l'une d'elles apparaît comme source à la périphérie de votre réseau côté Internet, vous avez affaire à du trafic interne, à un proxy mal configuré ou à un paquet usurpé, et le reste de ce pipeline ne s'applique pas.

Une adresse de NAT de niveau opérateur (CGNAT) est routable mais partagée. Une seule adresse mobile ou haut débit peut porter des centaines d'abonnés à la fois : toute décision prise à son sujet retombe donc sur chacun d'eux.

Nos trois adresses ont renvoyé is_bogon false et is_cgnat false ; elles poursuivent donc dans le pipeline.

Étape 2 : à qui appartient-elle ? ASN et RDAP

Le propriétaire ressort de deux enregistrements : le système autonome (AS) qui annonce l'adresse, et l'enregistrement du registre pour le bloc. Lisez asn.asn, asn.org et asn.rpki pour la route, puis whois.org, whois.netname, whois.registered et network.abuse_contact pour l'enregistrement.

Remarquez ce que les enregistrements ne disent pas. Rien dans l'enregistrement du serveur Mullvad ne mentionne « Mullvad » : il nomme 31173 Services, la société qui exploite le réseau de Mullvad, et whois.has_vpn_keywords vaut false. Le whois.org de DigitalOcean est revenu à « none » : c'est donc l'ASN qui porte la propriété dans ce cas. Voici ce qu'un ASN vous apprend sur le réseau si vous avez besoin du contexte.

Lorsque l'enregistrement stocké est maigre, remontez à la source. Les données d'enregistrement sont détenues par les cinq registres Internet régionaux : ARIN, RIPE NCC, APNIC, LACNIC et AFRINIC. Le fichier d'amorçage RDAP de l'IANA vous indique lequel détient une plage. RDAP est le successeur structuré de WHOIS, au format JSON. Lorsque nous avons ouvert l'enregistrement RDAP du RIPE pour 5.39.1.230 à 05:43 UTC, il montrait un bloc plus petit, 5.39.1.224/27, dont l'organisation titulaire est Ahrefs Pte Ltd. Notre enregistrement stocké reflète le bloc failover plus large d'OVH. L'enregistrement de registre le plus spécifique l'emporte.

Étape 3 : de quel type de réseau s'agit-il ?

Le type de réseau donne le cadre de tous les signaux suivants : lisez-le donc avant toute donnée de réputation. Les champs sont asn.asn_type, asn.user_type, asn.connection_type, detection.is_hosting et detection.is_mobile.

Les trois sont des adresses d'hébergement, et une seule a fini en block. L'hébergement est un contexte, pas une culpabilité : les sorties VPN, les robots d'exploration et vos propres runners de CI vivent tous dans des datacenters. C'est pourquoi une IP d'hébergement n'est pas une preuve de fraude. Le user_type search_engine_spider d'AhrefsBot est le premier indice que la deuxième adresse est un robot d'exploration.

Étape 4 : que dit son nom d'hôte ? DNS inverse et FCrDNS

Le DNS inverse renvoie le nom d'hôte défini par le propriétaire du bloc, et le DNS inverse confirmé par résolution directe (FCrDNS) vérifie que ce nom d'hôte renvoie bien à la même IP. Lisez network.ptr_record et network.fcrdns_valid, puis lancez la vérification vous-même, car un PTR stocké peut être en retard sur le DNS en direct. Nous les avons exécutées le 19 octobre 2026 à 05:42 UTC :

L'adresse AhrefsBot passe le FCrDNS en direct, et la page robot d'Ahrefs indique que les noms d'hôtes de son robot d'exploration se terminent toujours par ahrefs.com ou ahrefs.net. Notre API, en revanche, ne stocke aucun PTR pour elle, ce qui explique pourquoi no_ptr_datacenter se déclenche plus loin. Fiez-vous à l'exécution en direct plutôt qu'au champ stocké.

Le serveur DigitalOcean illustre l'autre type d'échec. Notre API stocke pour lui un nom d'hôte appartenant à un tiers sans rapport, fcrdns_valid vaut false, et la méthode fcrdns_mismatch se déclenche. Notre propre dig -x n'a renvoyé aucun PTR : le nom stocké est donc obsolète. Une incohérence de ce genre est un signal faible : c'était l'une des deux seules méthodes déclenchées, et l'adresse a tout de même obtenu 12.

Étape 5 : est-ce un VPN, un proxy, une sortie Tor ou un relais ?

Cette étape cherche à savoir si quelqu'un se cache derrière l'adresse. Lisez detection.is_vpn, is_proxy, is_tor, is_relay, vpn_provider, relay_provider et last_seen.

Le serveur Mullvad est nommé avec un vpn_confidence de 95 parce qu'il figure sur la liste de serveurs que Mullvad publie pour ses propres applications. C'est ainsi qu'une IP VPN est rattachée à son fournisseur, et cette méthode a une limite : un VPN non listé peut tout de même être repéré par des sondes, mais reste sans nom. Pour Tor, comparez l'adresse avec la liste complète des sorties du Tor Project, ou lisez notre guide pour détecter le trafic de sortie Tor. Les relais comme iCloud Private Relay ne sont pas des VPN : ils transportent des utilisateurs de navigateur ordinaires, c'est pourquoi notre score plafonne une adresse de relais à 60, sans qu'elle puisse jamais atteindre block.

Étape 6 : est-ce un robot d'exploration vérifié ou un scanner connu ?

Un robot d'exploration vérifié est une adresse figurant sur la liste de plages publiée par son opérateur, et un scanner est une infrastructure qui sonde tout Internet. Lisez threat.crawler.verified, name, operator et verification_method, puis threat.is_scanner et threat_types.

AhrefsBot correspondait aux plages publiées par Ahrefs : son opérateur est donc établi. Tout ce dont le User-Agent prétend être Googlebot mérite le même traitement : vérifiez une IP qui se présente comme Googlebot avant de lui faire confiance. La vue d'ensemble se trouve dans la détection des bots par adresse IP.

La quatrième ligne est un scanner Censys situé à Ann Arbor, interrogé à 05:34 UTC. Il a renvoyé is_scanner true, un score de 0, allow et une liste detection_methods vide. L'indicateur de scanner ne fait pas bouger notre score : lisez-le donc directement.

Étape 7 : figure-t-elle sur des listes de blocage, et depuis quand ?

Les listes de blocage enregistrent que des abus ont été observés depuis une adresse, et leurs dates comptent davantage que leur simple présence. Lisez threat.is_abusive, is_spammer, is_botnet et dnsbl_sources.

Consultez ensuite les sources externes, de manière passive :

• Spamhaus. ZEN combine les listes de blocage IP gratuites de Spamhaus, et sa page renvoie vers l'outil de vérification de réputation des IP et des domaines de Spamhaus pour le détail des inscriptions.
• AbuseIPDB. AbuseIPDB affiche les signalements d'abus soumis par les utilisateurs. Lisez son score de confiance et les dates des derniers signalements, pas le nombre total.
• VirusTotal. VirusTotal indique combien d'éditeurs de sécurité signalent l'adresse ainsi que les fichiers ou URL qui y sont liés.
• Shodan et Censys. Shodan et Censys montrent ce que leurs scans ont déjà trouvé en fonctionnement sur l'hôte : vous voyez ainsi les services ouverts sans le toucher.

La récence l'emporte sur la présence. Une inscription de la semaine dernière compte, et un résultat propre datant de six mois ne vous dit presque rien sur aujourd'hui.

Étape 8 : lisez le score et les méthodes déclenchées

Le score est un récapitulatif daté de tout ce qui précède, et scoring.detection_methods vous indique pourquoi il s'est arrêté là où il s'est arrêté. Voici la requête AhrefsBot, réduite aux groupes utilisés dans ce guide, valeurs non modifiées :

Les méthodes pour les trois adresses :

verified_crawler est un signal disculpant qui vaut moins 28,5 dans notre calcul de score (moins 30 avec une confiance de 0,95), et il n'a tout de même pas suffi à compenser deux méthodes de liste de blocage et une inscription pour spam. La réputation est un historique, et le score en est un instantané ; voici comment se construit la réputation IP.

Étape 9 : décidez s'il faut bloquer l'IP, le préfixe ou l'ASN

Associez la tranche de score à une action, puis choisissez la portée de cette action. Voici les verdicts sur lesquels nous agirions :

La portée compte autant que l'action. Bloquez une adresse IPv4 isolée pour un incident ponctuel. Pour IPv6, bloquez un /64 IPv6 plutôt qu'une seule adresse, car un même client contrôle généralement tout le /64. Ne bloquez un ASN entier que pour des réseaux d'hébergement d'où vos vrais utilisateurs ne viennent jamais, et jamais pour un opérateur mobile ou une plage CGNAT.

Préférez les limites de débit et les défis aux bannissements stricts : un bannissement frappe aussi la personne qui détiendra l'adresse la semaine suivante. L'automatisation des bannissements à partir de vos journaux, par exemple avec fail2ban, est un sujet à part entière. Pour savoir quel signal arrête quelle attaque, consultez quel signal IP arrête quelle attaque.

Étape 10 : signalez une IP abusive au contact abuse de son réseau

Envoyez les signalements d'abus à l'adresse indiquée dans network.abuse_contact, qui provient de l'enregistrement du registre :

Envoyez des preuves, pas des adjectifs : des horodatages avec le fuseau horaire, les lignes de journal, l'hôte et le port de destination, et ce que le trafic a fait. Déposez aussi le signalement sur AbuseIPDB pour que les autres défenseurs le voient.

Étape 11 : combien de temps un verdict IP reste-t-il valable ?

Un verdict dure quelques jours, pas des mois, et nous en avons vu un changer. Le 8 octobre 2026, nous avons interrogé 5.39.1.230 pour un article sur le web scraping. La requête a renvoyé crawler.verified true, is_abusive true, un score de 23 et allow, avec les méthodes abusive_listed, datacenter_blocklisted, no_ptr_datacenter et verified_crawler.

Le 19 octobre 2026 à 05:34:32 UTC, la même adresse a renvoyé 59 et step_up. Même robot d'exploration, même plage vérifiée, même opérateur. Ce qui a changé dans les méthodes, c'est known_spammer, qui s'est ajoutée à la liste, et la requête du jour indique is_spammer true avec zen.spamhaus.org dans dnsbl_sources. Nous n'avions pas relevé ces deux champs le 8 octobre : nous savons donc que l'inscription pour spam est nouvelle pour le score, mais pas à quelle date Spamhaus l'a ajoutée. La remise pour robot d'exploration vérifié s'appliquait toujours, et elle n'a pas suffi. En onze jours, l'adresse a franchi deux tranches.

Nos flux de menaces et nos fichiers de plages de robots d'exploration sont tous actualisés quotidiennement : un verdict peut donc évoluer du jour au lendemain. La règle : conservez la date avec chaque verdict, et relancez la requête avant d'agir sur un verdict plus ancien que le cycle de vos flux. Un indicateur n'est pas un verdict, et un verdict expire.

Étape 12 : peut-on retrouver la personne derrière une adresse IP ?

Non. Une adresse IP vous mène à un réseau, pas à une personne : seul le FAI ou l'hébergeur peut faire correspondre une adresse et un horaire à un abonné, et il ne communique cette information que dans le cadre d'une procédure judiciaire, par exemple sur décision de justice, ni à vous ni à nous.

Enquêtez sur les adresses qui ont touché vos propres systèmes, arrêtez-vous au réseau, et n'essayez ni de démasquer ni de scanner qui que ce soit. La géolocalisation est elle aussi approximative : nos trois requêtes ont situé les adresses à Francfort, Paris et North Bergen, ce qui localise un datacenter au niveau de la ville, jamais une adresse postale.

Appliquez le même pipeline à votre prochaine alerte

Prenez la prochaine adresse de votre file d'alertes et passez-la dans la même requête en gardant le contexte de l'alerte à côté. Pour automatiser les douze vérifications, commencez par la documentation de l'API de requête.

Les requêtes sans clé sont limitées à 30 par minute, et cette limite est stricte : la 30e requête dans la même minute renvoie déjà une erreur 429 et bloque l'IP appelante pendant deux heures. Utilisez une clé gratuite pour les scripts : elle donne droit à 1 500 requêtes par jour avec tous les champs. Alimenter un SIEM avec des requêtes à grande échelle est l'étape suivante pour une file d'alertes chargée.

Questions fréquentes

Comment enquêter sur une adresse IP suspecte ?

Procédez de manière passive et dans l'ordre. Vérifiez qu'il s'agit d'une adresse publique routable, identifiez son propriétaire et le type de réseau, examinez son nom d'hôte et ses indicateurs d'anonymisation et de robot d'exploration, lisez ses inscriptions sur des listes de blocage et leurs dates, puis agissez sur la base d'un score et notez la date.

Comment vérifier si une adresse IP est malveillante ?

Aucune vérification isolée ne le prouve. Recherchez des inscriptions actuelles, par exemple chez Spamhaus, des signalements d'abus récents sur AbuseIPDB et des indicateurs d'anonymisation, puis mettez-les en balance avec ce que l'adresse a fait sur vos propres systèmes. Un indicateur signifie que des abus ont été observés depuis l'adresse, pas que cette requête est un abus.

Peut-on retrouver la personne derrière une adresse IP ?

Pas par vous-même. Une IP mène à un opérateur réseau, et seul cet opérateur peut faire correspondre une adresse et un horaire à un abonné, information qu'il ne divulgue que dans le cadre d'une procédure judiciaire, pas à vous. Signalez plutôt l'abus au contact abuse du réseau.

Faut-il bloquer l'IP, le préfixe ou l'ASN entier ?

Bloquez une adresse IPv4 isolée pour un incident ponctuel, un /64 IPv6 plutôt qu'une seule adresse IPv6, et un ASN entier uniquement pour des réseaux d'hébergement d'où vos vrais utilisateurs ne viennent jamais. Évitez de bloquer des plages mobiles ou CGNAT, car une seule adresse peut porter de nombreux utilisateurs.

Un robot d'exploration vérifié peut-il toujours être autorisé sans risque ?

Non. L'adresse 5.39.1.230 d'AhrefsBot correspondait aux plages publiées par Ahrefs le 19 octobre 2026, mais elle figurait aussi sur Spamhaus ZEN et obtenait un score de 59, step_up. La vérification vous dit qui exploite l'adresse, pas que sa plage est propre.

Combien de temps le résultat d'une enquête IP reste-t-il valable ?

Quelques jours, pas des mois. La même adresse AhrefsBot obtenait 23, allow, le 8 octobre 2026 et 59, step_up, le 19 octobre. Relancez la requête avant d'agir sur un ancien verdict et conservez la date avec chaque verdict.