Renseignement IPL'intelligence IP contre la cybercriminalité : comment prévenir les cyberattaques
L'intelligence IP contre la cybercriminalité : quels signaux ASN, VPN, Tor et hébergeur bloquent quelles attaques, avec du Python testé pour 7 défenses et des requêtes réelles du jour.
Lorsque nous avons interrogé trois adresses publiques le 15 octobre 2026, un serveur VPN commercial confirmé par sondage a obtenu 92 (block), un nœud de sortie Tor a obtenu 100 (block), et l'hôte de test de Nmap, sur un serveur cloud Linode, a obtenu 10 (allow). Les trois se trouvent dans des datacenters, pourtant seuls les deux anonymiseurs ont été bloqués. Cet écart entre « cloud » et « criminel » est le sujet de tout le reste de ce guide.
Les enjeux sont mesurés, pas projetés. L'Internet Crime Complaint Center du FBI a reçu 1 008 597 plaintes en 2025, première année au-dessus du million, avec 20,877 milliards de dollars de pertes déclarées, soit 26 % de plus qu'en 2024 (IC3 2025 Internet Crime Report). Et le trafic qui porte les attaques est de moins en moins humain : le Bad Bot Report 2026 d'Imperva a constaté que le trafic automatisé représentait plus de 53 % de l'ensemble du trafic web en 2025, contre 51 % l'année précédente.
Ce guide présente ce que sont ces signaux, quelles catégories de crimes ils perturbent, sept défenses avec du Python testé aujourd'hui sur de vraies adresses, une matrice signal-attaque, et les cas où les données IP n'ont rien à dire.
Ce que l'intelligence IP ajoute à une adresse brute
L'intelligence IP consiste à enrichir une adresse IP brute de tout ce qu'elle révèle sur son origine et sa fiabilité. Une adresse brute n'est qu'un nombre. Passez-la dans un pipeline d'enrichissement et elle devient un profil :
- Géolocalisation : pays, région, ville approximative et fuseau horaire.
- Propriété du réseau : le numéro de système autonome (ASN) et l'organisation qui contrôle l'espace d'adresses.
- Type de connexion : haut débit résidentiel, mobile, entreprise, ou hébergeur et datacenter.
- Indicateurs d'anonymisation : s'agit-il d'un VPN, d'un proxy ou d'un nœud de sortie Tor ?
- Signaux de menace et d'abus : cette adresse a-t-elle été vue en train de scanner, d'envoyer du spam, ou figure-t-elle sur une liste de blocage DNS ?
- Un score de risque composite : un seul nombre qui fusionne les signaux ci-dessus en une décision allow, review, step-up ou block.
La distinction qui piège beaucoup de monde : ce n'est pas la même chose que la géolocalisation IP. La géolocalisation répond uniquement à « où est cette IP », et comme nous l'expliquons dans la précision réelle de la géolocalisation IP, elle est précise à environ 99 % au niveau du pays mais bien plus faible au niveau de la ville. La discipline plus large, que nous détaillons couche par couche dans notre guide de ce que couvre l'intelligence IP au-delà de la localisation, ajoute les couches réseau, type de connexion, anonymisation et réputation, qui répondent à la question qui intéresse réellement les équipes fraude et sécurité : puis-je faire confiance à cette connexion ? La plupart des implémentations ne lisent que le champ pays, et ce champ seul ne dit presque rien sur la légitimité d'une requête.
Pourquoi l'IP source est le premier signal d'une défense contre la cybercriminalité
L'IP source est le premier signal parce qu'un attaquant peut falsifier presque tout le reste mais doit vous présenter une adresse routable. Trois faits structurels lui donnent sa valeur.
1. Elle est incontournable. Un attaquant peut usurper un User-Agent, fabriquer une adresse e-mail, acheter une carte volée et forger une empreinte d'appareil. Ce qu'il ne peut pas faire, c'est atteindre votre serveur sans une IP source que vous pouvez observer. Il peut se cacher derrière une infrastructure, mais cette infrastructure laisse elle-même des indices.
2. Les attaquants réutilisent leur infrastructure à grande échelle. La cybercriminalité rentable est industrialisée. Les kits de credential stuffing martèlent des milliers de comptes depuis des serveurs loués ; les réseaux de test de cartes tournent sur des plages de datacenters ; les scrapers et les scalpers opèrent depuis des pools cloud et proxy. C'est précisément cette réutilisation que les signaux réseau exposent : une connexion depuis un ASN d'hébergeur, un paiement depuis une plage de datacenter, un « acheteur » qui arrive par un proxy ouvert.
3. Elle est disponible avant l'étape coûteuse. L'IP est présente dès le tout premier paquet, avant l'authentification et avant l'autorisation de paiement. C'est donc l'endroit le moins cher pour trier le risque, de sorte que vos défenses coûteuses (défis MFA, revue manuelle, KYC renforcé) ne se déclenchent que lorsqu'elles se justifient.
Le bémol, sur lequel nous revenons plus bas, est que l'IP est un signal, pas un verdict. Tout l'art consiste à s'en servir pour décider qui mérite un examen plus poussé, pas pour prononcer des bannissements généralisés.
Les catégories de cybercriminalité que les signaux IP perturbent
La cybercriminalité n'est pas une seule chose, et le rôle de l'IP pour l'enrayer ne l'est donc pas non plus. Voici comment l'IP source contribue dans les grandes catégories d'attaques, avec le guide détaillé pour chacune.
Prise de contrôle de compte et credential stuffing
Le credential stuffing (rejouer des paires identifiant et mot de passe divulguées contre des formulaires de connexion) est désormais la voie dominante vers la prise de contrôle de compte. L'attaque n'est rentable que parce qu'elle est automatisée et répartie sur une infrastructure bon marché. Une requête signale les ASN d'hébergeurs, les proxys et les sorties anonymisées sur lesquels s'appuie le stuffing volumétrique, et alimente une vision de la vélocité (combien de comptes cette IP touche-t-elle ?) qu'une connexion isolée ne peut pas révéler. La nuance : le blocage par IP seul échoue, car les acteurs sophistiqués passent aux proxys résidentiels ; l'IP doit donc être une entrée du calcul de risque, pas toute la décision.
Fraude au paiement, test de cartes et abus au paiement
Le paiement est le moment où la cybercriminalité se convertit en argent, ce qui explique qu'il attire les bots de carding, les scripts de test de cartes et, de plus en plus, les agents d'achat IA automatisés. Le test de cartes procède par autorisations à haute vélocité et de faible montant, souvent depuis des IP de datacenters et de proxys. Les signaux de type de connexion et de risque permettent d'augmenter la friction sur la minorité suspecte de paiements tout en laissant intactes les sessions légitimes (y compris le bon trafic d'agents). Où placer le seuil est traité dans le score de fraude IP à partir duquel bloquer.
Bots, scrapers et usurpation de robots d'exploration
Alors que les bots représentent désormais la majorité du trafic web, distinguer un vrai robot d'exploration d'un imposteur compte sur chaque point d'accès. Un en-tête User-Agent: GPTBot est une déclaration que n'importe qui peut envoyer. HUMAN Security a constaté que 5,7 % de l'ensemble du trafic observé se présentant avec un user agent de robot d'exploration ou de scraper d'IA était usurpé. La défense est la provenance : vérifier les robots d'exploration et agents d'IA par IP via le DNS inversé, les plages CIDR publiées et Web Bot Auth. Une requête ne voit pas le User-Agent ; la comparaison entre le nom revendiqué et threat.crawler.verified se fait donc dans votre code. Pour une vue plus large, voir comment les données IP classent les bots, et pour les scrapers qui copient votre contenu ou vos prix, notre guide de détection du web scraping.
Abus d'anonymisation : VPN, proxys et Tor
L'anonymisation est le camouflage du cybercriminel, mais elle est aussi utilisée par des millions de personnes parfaitement légitimes et soucieuses de leur vie privée. La détection moderne de VPN et de proxys sépare les deux à l'aide de listes de serveurs de fournisseurs, de l'analyse des ASN et du sondage actif des protocoles, plutôt que d'une liste de blocage périmée. La variante la plus dangereuse est le proxy résidentiel : des réseaux qui acheminent le trafic via de vrais appareils grand public. Infoblox a mesuré une croissance des requêtes DNS vers des domaines de proxys résidentiels, passées de près de 400 milliards par mois en janvier 2025 à plus de 500 milliards par mois en avril 2026. Les données IP seules ne peuvent pas les signaler de façon fiable, et GeoIPHub ne détecte pas les proxys résidentiels ; il faut donc les repérer avec des signaux d'appareil, de comportement et de vélocité. La gestion du trafic anonymisé sans écarter les utilisateurs légitimes de VPN fait l'objet de détecter le trafic anonymisé sans bloquer les vrais clients.
Faux comptes, identité synthétique et fraude à l'ouverture de compte
L'abus de bonus, le parrainage frauduleux, les mules financières et les réseaux d'identités synthétiques dépendent tous de la création de comptes à grande échelle. Comme chaque faux compte a besoin d'une origine « d'apparence neuve », les attaquants font tourner des IP de proxys et de datacenters, exactement l'infrastructure que ces signaux font ressortir. Intégrer le score de risque à l'inscription est l'un des moyens les moins coûteux d'augmenter le coût de la création de comptes en masse. Notre contrôle d'inscription par type d'IP montre ce que renvoie chaque type d'adresse et que faire de ce résultat.
Géo-fraude, usurpation de localisation et contournement de sanctions
L'abus de promotions, le contournement des licences de contenu et le contournement de sanctions reposent tous sur la falsification d'une localisation. Ici, la requête joue un double rôle : la géolocalisation établit la localisation revendiquée, tandis que les indicateurs VPN, proxy et type de connexion révèlent si cette localisation est usurpée. La défense de restriction géographique ci-dessous montre pourquoi le contrôle du pays ne signifie rien sans le contrôle d'anonymisation à ses côtés.
Trois requêtes du jour : VPN 92, sortie Tor 100, hôte cloud 10
Le score suit les preuves, pas le type de réseau. Nous avons exécuté ces trois requêtes le 15 octobre 2026 sur le point d'accès public (sans clé, 30 requêtes par minute), et les réponses ci-dessous sont des copies abrégées de la sortie réelle. Les résultats évoluent au gré des mouvements de plages.
curl https://api.geoiphub.com/v1/lookup/102.129.235.17
{
"ip": "102.129.235.17",
"asn": {
"asn": 834,
"org": "IPXO - IPXO LLC",
"asn_type": "vpn",
"connection_type": "datacenter"
},
"detection": {
"is_vpn": true,
"is_hosting": false,
"is_anonymous": true,
"vpn_provider": "none",
"vpn_confidence": 100
},
"scoring": {
"fraud_score": 92,
"recommended_action": "block",
"detection_methods": ["known_vpn_server", "openvpn_open", "ipsec_open"]
}
}
{
"ip": "185.220.101.47",
"asn": {
"asn": 60729,
"org": "TORSERVERS-NET - Stiftung Erneuerbare Freiheit",
"asn_type": "hosting",
"connection_type": "datacenter"
},
"geo": {
"country_code": "DE",
"city": "Hamburg (Hamburg-Nord)"
},
"detection": {
"is_tor": true,
"is_hosting": true,
"is_anonymous": true
},
"threat": {
"is_spammer": true,
"threat_types": ["spammer", "tor"],
"dnsbl_sources": ["bl.spamcop.net"]
},
"scoring": {
"fraud_score": 100,
"recommended_action": "block",
"detection_methods": ["tor_exit", "datacenter_blocklisted", "no_ptr_datacenter", "known_spammer"]
}
}
{
"ip": "45.33.32.156",
"asn": {
"asn": 63949,
"org": "AKAMAI-LINODE-AP - Akamai Connected Cloud",
"asn_type": "hosting",
"connection_type": "datacenter"
},
"detection": {
"is_vpn": false,
"is_hosting": true,
"is_anonymous": false
},
"scoring": {
"fraud_score": 10,
"recommended_action": "allow",
"detection_methods": ["datacenter_ip"]
}
}
Les detection_methods du serveur VPN montrent trois confirmations indépendantes : l'IP correspond à un serveur VPN connu, et nos sondes ont mené à terme de vraies négociations OpenVPN et IPsec sur cette adresse. Cette corroboration la fait basculer dans la tranche de blocage, bien que vpn_provider vaille "none" puisque l'adresse ne figure sur la liste d'aucun fournisseur. Le nœud de sortie Tor cumule la liste des nœuds de sortie du Tor Project et une inscription chez SpamCop, et atteint donc le plafond de 100.
Une méthode de la réponse Tor est plus faible qu'elle n'en a l'air. no_ptr_datacenter indique que l'adresse n'a pas de DNS inversé, or un dig -x en direct exécuté le même matin a renvoyé un nom d'hôte pour elle. Nos données PTR stockées comportent des lacunes pour certaines adresses ; accordez donc à cette méthode le poids le plus faible lorsque vous examinez ce verdict.
L'hôte de test de Nmap ne porte que le signal d'hébergeur : il obtient donc 10 et reçoit allow. De nombreuses API, sondes de supervision et agents d'IA légitimes tournent sur des serveurs cloud, et l'hébergement seul n'est pas la preuve d'un crime. Même le block du VPN est une valeur par défaut que vous pouvez remplacer flux par flux, comme le montrent les défenses ci-dessous.
Pourquoi un score de risque vaut mieux qu'une liste de blocage
Un score l'emporte sur une liste de blocage parce que l'IP est un signal, pas un verdict. Une même adresse IPv4 résidentielle peut être partagée par des centaines de personnes derrière un NAT de niveau opérateur, si bien qu'un vrai client et un fraudeur peuvent se trouver sur la même adresse. Une IP résidentielle irréprochable peut héberger un proxy. Une IP de datacenter peut appartenir à un VPN d'entreprise légitime.
Le schéma durable consiste à convertir les signaux IP en score de risque, puis à router la décision sur ce score :
Incoming request
|
v
[ IP lookup ] ASN, connection type, VPN / proxy / Tor, hosting, reputation
|
v
[ Risk score 0-100 ] fuse with device, behavioral, velocity and identity signals
|
+-- low : allow (don't punish the legitimate majority)
+-- medium : step-up / challenge (MFA, CAPTCHA, manual review)
+-- high : block or hold
C'est la différence entre mettre des IP sur liste noire (fragile, nombreux faux positifs, facile à contourner) et noter le risque des connexions (graduel, explicable, résilient). Chaque raison qu'un score explicable peut nommer, avec son poids, est listée dans les raisons du score de risque, champ par champ.
Comment prévenir les cyberattaques avec la géolocalisation IP et les signaux réseau
Vous prévenez les cyberattaques avec la géolocalisation IP en lisant plus que le pays : les groupes geo, asn, detection, threat et scoring d'une même requête alimentent chacun une défense différente. Les sept ci-dessous sont celles que nous rencontrons le plus souvent, chacune avec du Python que vous pouvez copier-coller. Toutes appellent une même petite fonction utilitaire :
import json
import urllib.request
API = "https://api.geoiphub.com/v1/lookup/"
def geoiphub_lookup(ip: str, api_key: str = "") -> dict:
# The API currently answers 403 to urllib's default User-Agent, so send your own.
# Without a key you get 30 lookups a minute; with one, 1,500 a day on the free tier.
headers = {"User-Agent": "my-app/1.0"}
if api_key:
headers["x-api-key"] = api_key
req = urllib.request.Request(API + ip, headers=headers)
with urllib.request.urlopen(req, timeout=5) as resp:
return json.load(resp)
1. Bloquer les abus connus en périphérie, mais laisser passer les robots d'exploration vérifiés
La défense la moins coûteuse rejette les scanners, les nœuds de botnet et les sorties Tor avant qu'ils touchent votre application, et confie tout le reste au score. Deux détails comptent. Les robots d'exploration vérifiés passent en premier, car un vrai robot peut se trouver sur une plage inscrite en liste de blocage (le 5.39.1.230 d'AhrefsBot renvoie is_abusive: true). Et l'indicateur de scanner se lit directement, car il ne fait pas bouger fraud_score : le scanner Censys à l'adresse 162.142.125.10 obtient 0.
def check_ip_at_entry(ip: str) -> dict:
data = geoiphub_lookup(ip)
threat, scoring = data["threat"], data["scoring"]
# Verified search and AI crawlers can sit on blocklisted ranges: let them through
if threat["crawler"]["verified"]:
return {"action": "allow", "reason": "verified_crawler"}
# Scanner and botnet flags don't move fraud_score, so read them directly
if threat["is_scanner"] or threat["is_botnet"]:
return {"action": "block", "reason": "scanner_or_botnet"}
# Tor exit at an entry point that handles accounts or money
if data["detection"]["is_tor"]:
return {"action": "block", "reason": "tor_exit"}
return {"action": scoring["recommended_action"], "fraud_score": scoring["fraud_score"]}
Calibrez par flux. Un formulaire de réinitialisation de mot de passe peut agir sur step_up, tandis qu'un point d'accès de contenu public n'agira peut-être que sur block. Le champ scoring.confidence (de 0,0 à 1,0) indique la quantité de preuves qui sous-tend le score : réservez donc les blocages stricts aux verdicts appuyés par des preuves solides.
2. Traiter le trafic VPN, proxy et Tor selon le flux
Les anonymiseurs méritent un traitement différent selon le flux, car les VPN commerciaux portent des millions d'utilisateurs ordinaires, alors que les proxys ouverts et les sorties Tor au moment du paiement en relèvent rarement. Bloquer tous les VPN est trop large pour la plupart des produits.
SENSITIVE_FLOWS = {"login", "signup", "checkout"}
def anonymization_response(ip: str, flow: str) -> str:
det = geoiphub_lookup(ip)["detection"]
sensitive = flow in SENSITIVE_FLOWS
if det["is_tor"] or det["is_proxy"]:
return "block" if sensitive else "challenge"
# Commercial VPNs carry millions of ordinary users: add friction only where money moves
if det["is_vpn"]:
return "challenge" if flow == "checkout" else "allow_and_log"
# iCloud Private Relay is a Safari setting, not an attack tool
return "allow"
Les preuves derrière chaque indicateur :
detection.is_vpn: une correspondance avec les listes de serveurs des fournisseurs eux-mêmes et avec une liste publique tierce (y compris le tag WireGuard que portent ces listes), ainsi que de véritables négociations OpenVPN et IPsec menées par nos sondes.detection.is_proxy: des sondes de négociation pour les proxys SOCKS4, SOCKS5, HTTP CONNECT et HTTP forward.detection.is_tor: la liste officielle des nœuds de sortie du Tor Project, actualisée chaque jour.detection.is_relay: iCloud Private Relay et la sortie de confidentialité de Cloudflare, que nous laissons passer volontairement.
Les proxys résidentiels ne figurent pas dans cette liste. L'API ne les détecte pas : ne construisez donc pas de règle sur is_residential_proxy.
3. N'appliquer les restrictions géographiques qu'avec la détection de VPN
Une restriction géographique ne fonctionne que si le contrôle du pays et le contrôle d'anonymisation s'exécutent ensemble. Si vous bloquez un pays sanctionné mais autorisez les requêtes is_vpn: true, les utilisateurs de ce pays se connectent via un serveur VPN en Allemagne et le blocage échoue.
BLOCKED_COUNTRIES = {"KP", "IR", "CU"} # example only: your compliance team owns this list
RESTRICTED_FLOWS = {"checkout", "download", "api_access"}
def check_geo_compliance(ip: str, flow: str) -> dict:
if flow not in RESTRICTED_FLOWS:
return {"action": "allow"}
data = geoiphub_lookup(ip)
det = data["detection"]
# Behind an anonymizer the apparent country is the server's, not the user's
if det["is_anonymous"]:
return {"action": "block", "reason": "country_unverifiable"}
# Relay geolocation is approximate: confirm the country from Apple's egress list
if det["is_relay"]:
return {"action": "verify_country", "reason": "private_relay"}
if data["geo"]["country_code"] in BLOCKED_COUNTRIES:
return {"action": "block", "reason": "geo_compliance"}
return {"action": "allow"}
La branche relay existe à cause d'une lacune que nous avons trouvée dans nos propres données. Apple maintient la sortie de Private Relay dans le pays de l'utilisateur, mais pour l'adresse de relais 104.28.46.99, notre base indique l'Angola alors que la liste de sortie d'Apple elle-même indique la Zambie. Un relais renvoie is_anonymous: false ; sans cette branche, le contrôle du pays se fierait donc à la mauvaise réponse.
4. Signaler les déplacements impossibles lors des connexions
Le déplacement impossible est l'un des signaux de prise de contrôle de compte les plus fiables : personne ne se connecte depuis Londres puis depuis la Californie 30 minutes plus tard. Enregistrez les coordonnées de chaque connexion, calculez la distance par rapport à la précédente et signalez les paires qui exigeraient un avion plus rapide qu'environ 900 km/h.
import math
from datetime import datetime, timezone
MIN_DISTANCE_KM = 500 # below this, city-level geolocation error can fake a "jump"
MAX_SPEED_KMH = 900 # roughly a commercial jet
def haversine_km(lat1, lon1, lat2, lon2) -> float:
r = 6371
dlat = math.radians(lat2 - lat1)
dlon = math.radians(lon2 - lon1)
a = (math.sin(dlat / 2) ** 2
+ math.cos(math.radians(lat1)) * math.cos(math.radians(lat2)) * math.sin(dlon / 2) ** 2)
return r * 2 * math.asin(math.sqrt(a))
def check_impossible_travel(previous, current_ip: str) -> dict:
# previous: your last stored login for this user, e.g.
# {"latitude": 51.5, "longitude": -0.12, "at": datetime(..., tzinfo=timezone.utc)}
data = geoiphub_lookup(current_ip)
det, geo = data["detection"], data["geo"]
# A VPN, Tor or relay location is not where the person is: don't compare it or store it
if det["is_anonymous"] or det["is_relay"]:
return {"action": "skip", "reason": "location_not_reliable"}
if previous is None:
return {"action": "allow"}
distance_km = haversine_km(previous["latitude"], previous["longitude"],
geo["latitude"], geo["longitude"])
hours = (datetime.now(timezone.utc) - previous["at"]).total_seconds() / 3600
if distance_km > MIN_DISTANCE_KM and hours < distance_km / MAX_SPEED_KMH:
return {"action": "step_up", "reason": "impossible_travel",
"distance_km": round(distance_km), "hours_elapsed": round(hours, 1)}
return {"action": "allow"}
Avec une connexion londonienne enregistrée 30 minutes plus tôt, l'hôte Linode de Fremont est ressorti en step_up à 8 617 km. Deux remarques de calibrage. Les utilisateurs de VPN déclenchent le déplacement impossible à chaque changement de serveur, ce qui explique que les connexions anonymisées soient ignorées plutôt qu'enregistrées. Et les opérateurs mobiles font passer de nombreux utilisateurs par des adresses partagées aux données de ville grossières ; le plancher de 500 km évite qu'une dérive de localisation ressemble à un vol.
5. Brider selon le type de réseau
Les limites de débit fonctionnent mieux lorsqu'elles suivent le réseau qui se cache derrière l'IP. Une adresse mobile peut porter des centaines de vraies personnes derrière le NAT de l'opérateur ; la brider fortement bloque donc des clients. Une adresse cloud est généralement un seul script, bien qu'il s'agisse parfois d'un agent d'IA agissant pour un vrai acheteur : challengez-la plutôt que de la bannir.
RATE_LIMITS = {
"isp": {"per_minute": 60, "on_exceed": "delay"},
"mobile": {"per_minute": 120, "on_exceed": "delay"}, # carrier NAT puts many people on one IP
"hosting": {"per_minute": 10, "on_exceed": "challenge"}, # usually one script, sometimes a real AI agent
"vpn": {"per_minute": 20, "on_exceed": "challenge"},
}
DEFAULT_LIMIT = {"per_minute": 30, "on_exceed": "delay"} # "unknown" and any new type
def rate_limit_for(ip: str) -> dict:
data = geoiphub_lookup(ip)
if data["threat"]["crawler"]["verified"]:
return {"per_minute": 120, "on_exceed": "delay"}
if data["scoring"]["recommended_action"] == "block":
return {"per_minute": 3, "on_exceed": "block"}
return RATE_LIMITS.get(data["asn"]["asn_type"], DEFAULT_LIMIT)
Ces chiffres sont des valeurs de départ à ajuster sur votre propre trafic, pas des optimums mesurés. Gardez une valeur par défaut : le scanner Censys est revenu avec asn_type: "unknown", qu'aucune table fixe ne listerait. Les scrapers qui louent des IP domestiques et mobiles passent à travers toute règle fondée sur le type de réseau, et notre guide sur comment savoir si votre site est scrapé couvre les contrôles au niveau des logs qui les attrapent.
6. Comparer le pays de l'IP au pays de facturation au paiement
Une carte avec une adresse de facturation au Royaume-Uni utilisée depuis une IP d'un autre pays est un schéma à fort signal pour la fraude au paiement, à condition de pouvoir se fier au pays de l'IP. Lorsqu'un anonymiseur le masque, demandez plutôt une authentification 3-D Secure (3DS).
def assess_checkout_geo_risk(ip: str, billing_country: str) -> dict:
data = geoiphub_lookup(ip)
det = data["detection"]
if det["is_vpn"] or det["is_proxy"] or det["is_tor"]:
return {"risk": "high", "reason": "anonymizer_hides_country", "action": "require_3ds"}
# Private Relay keeps the user's country but our relay geolocation can miss it: skip the compare
if det["is_relay"]:
return {"risk": "standard", "reason": "private_relay", "action": "allow"}
ip_country = data["geo"]["country_code"]
if ip_country != billing_country:
return {"risk": "elevated", "reason": f"ip_{ip_country}_billing_{billing_country}",
"action": "require_3ds"}
return {"risk": "standard", "action": "allow"}
Ne tenez pas à la main une liste de « pays à risque ». Les attaquants passent délibérément par des IP d'apparence saine dans des pays à faible risque : ciblez donc l'infrastructure (statut d'anonymiseur, indicateurs d'abus, type d'ASN) plutôt que la géographie dont elle semble provenir. Notre guide de réduction des rétrofacturations approfondit le parcours de paiement.
7. Garder les sessions de bots hors des statistiques
Filtrer les sessions automatisées avant qu'elles soient enregistrées dans les statistiques garde vos données de conversion, et tout modèle d'enchères entraîné dessus, centrés sur de vraies personnes. Les robots d'exploration vérifiés sont toujours servis ; ils ne sont simplement pas comptés.
def should_record_session(ip: str) -> bool:
data = geoiphub_lookup(ip)
det, threat, scoring = data["detection"], data["threat"], data["scoring"]
if threat["crawler"]["verified"]:
return False # serve the crawler, but keep it out of analytics
if det["is_tor"] or det["is_proxy"]:
return False
if scoring["recommended_action"] == "block":
return False
if det["is_hosting"] and scoring["fraud_score"] > 50:
return False
return True
Le trafic payant a son propre mode d'emploi, qui commence par renoncer à la liste d'exclusion d'IP : voir comment détecter la fraude au clic par adresse IP.
Ce que les sept contrôles ont renvoyé pour six vraies adresses
Nous avons exécuté chacune des fonctions ci-dessus, telles que publiées, sur six adresses publiques le 15 octobre 2026. La colonne paiement compare chaque IP à une adresse de facturation américaine.
| IP (ce que c'est) | Contrôle en périphérie | Anonymiseur à la connexion | Limite de débit | Paiement vs carte US | Comptée dans les statistiques |
|---|---|---|---|---|---|
| 185.220.101.47 (sortie Tor) | block: tor_exit | block | 3/min, block | high: require_3ds | non |
| 102.129.235.17 (VPN commercial) | block: score 92 | allow_and_log | 3/min, block | high: require_3ds | non |
| 45.33.32.156 (hôte de test Nmap, Linode) | allow: score 10 | allow | 10/min, challenge | standard: allow | oui |
| 162.142.125.10 (scanner Censys) | block: scanner_or_botnet | allow | 30/min, delay | standard: allow | oui |
| 5.39.1.230 (AhrefsBot, vérifié) | allow: verified_crawler | allow | 120/min, delay | elevated: FR vs US | non |
| 104.28.46.99 (iCloud Private Relay) | allow: score 9 | allow | 30/min, delay | standard: private_relay | oui |
Deux lignes montrent pourquoi les contrôles doivent s'exécuter ensemble. Le scanner Censys passe tous les contrôles sauf celui de la périphérie, parce que l'indicateur de scanner est son seul signal. Et le VPN que le contrôle en périphérie bloque sur le seul score n'est que journalisé à la connexion, ce qui est le comportement par flux que l'on veut : le bloquer là où l'on bloque strictement sur le score, et le journaliser là où un VPN est normal.
Quel signal IP arrête quelle attaque
Chaque signal correspond à une attaque distincte et à une action distincte. Utilisez ce tableau comme configuration de départ, puis ajustez par flux.
| Signal | Ce qu'il détecte | Action recommandée |
|---|---|---|
| detection.is_tor: true | Anonymisation Tor dans le credential stuffing, le carding et la fraude | Bloquer dans les flux sensibles |
| detection.is_proxy: true | Proxy SOCKS ou HTTP ouvert, généralement un outil d'abus | Bloquer à la connexion, au paiement, à l'inscription |
| detection.is_vpn: true | VPN commercial, usage mixte légitime et abusif | Challenger au paiement ; autoriser et journaliser ailleurs |
| detection.is_relay: true | iCloud Private Relay ou sortie de confidentialité Cloudflare | Autoriser ; ne pas se fier à sa ville |
| detection.is_hosting: true dans un flux grand public | Scripts, ou un agent d'IA qui achète pour une vraie personne | Challenger ; ne bloquer qu'avec un score élevé |
| threat.is_scanner ou is_botnet: true | Infrastructure de scan et de botnet (ne modifie pas le score) | Bloquer en périphérie |
| threat.crawler.verified: true | Un vrai robot d'exploration de moteur de recherche ou d'IA, sur les plages publiées par son opérateur | Autoriser ; exclure des statistiques |
| Distance de plus de 500 km à plus de 900 km/h | Prise de contrôle de compte avec des identifiants volés | Vérification renforcée, puis signaler le compte |
| geo.country_code diffère de la facturation, sans anonymiseur | Test de cartes, ou client en vacances | Exiger le 3DS |
| scoring.fraud_score supérieur à 75 (block) | Plusieurs signaux concordants à la fois | Bloquer ou suspendre pour revue manuelle |
Ce que les données IP ne peuvent pas détecter
Les données IP sont un filtre de premier passage, et trois types d'attaques les traversent sans encombre. Pour la procédure par incident, de la propriété au verdict, voir comment enquêter sur une adresse IP suspecte.
Les proxys résidentiels à la réputation propre. Une IP ajoutée hier à un pool de proxys n'a aucun historique d'abus et passe les contrôles de listes de blocage, et GeoIPHub ne détecte pas les proxys résidentiels. Les attraper demande des anomalies d'empreinte d'appareil, le rythme des sessions et les cadences d'interaction.
Les comptes compromis sur une connexion saine. Un attaquant muni d'identifiants valides sur une connexion domestique dans le pays de la victime ne laisse rien à signaler dans les données IP. Il faut des signaux comportementaux (rythme de frappe, navigation, divergence par rapport à l'historique d'achats).
Les attaques ciblées. Un attaquant qui étudie vos défenses choisira une IP résidentielle saine dans la ville de la victime et passera tous les contrôles au niveau de l'IP. La vérification par e-mail et l'association à l'appareil sont les défenses dans ce cas.
Le bon modèle : la requête filtre le volume des attaques automatisées et peu sophistiquées à un coût quasi nul par requête, afin que les contrôles coûteux (empreinte d'appareil, analyse comportementale, revue manuelle) puissent se concentrer sur ce qui reste.
Exécuter ces contrôles en production
Trois habitudes maintiennent la précision des défenses fondées sur l'IP après le lancement.
Mettre en cache par IP, brièvement. Les faits réseau changent lentement au sein d'une session, mais ils changent : nos sondes VPN et proxy tournent au plus toutes les 12 heures et les flux de menaces sont actualisés toutes les 6 heures. Mettez chaque requête en cache pour la durée de la session, faites-la expirer en moins d'une heure pour les décisions de sécurité, et en moins d'un jour pour les simples champs de géolocalisation. Une requête par IP et par session est le modèle de coût pratique.
Journaliser la réponse complète, pas seulement le verdict. Lorsqu'un blocage se déclenche, vous voulez savoir quel signal l'a provoqué. Enregistrez scoring.detection_methods et le scoring.fraud_score brut avec chaque décision. C'est ainsi que vous repérez les faux positifs, comme la méthode PTR périmée de l'exemple Tor ci-dessus, et que vous ajustez les seuils.
Ajuster les seuils par flux, pas par site. Une réinitialisation de mot de passe mérite un seuil de blocage plus bas que la lecture d'un article de blog. Gardez les seuils en configuration pour que votre équipe sécurité puisse les modifier sans déploiement :
FLOW_THRESHOLDS = {
"checkout": {"block_above": 75, "challenge_above": 50},
"login": {"block_above": 80, "challenge_above": 55},
"signup": {"block_above": 85, "challenge_above": 60},
"api_read": {"block_above": 90, "challenge_above": 75},
}
Ce que renvoie une requête GeoIPHub face à chaque menace
GeoIPHub regroupe toute cette couche en un seul appel d'API. Une requête renvoie plus de 100 champs de données répartis en 10 groupes de réponse (géolocalisation, ASN et réseau, type de connexion, opérateur mobile, DNS inversé, indicateurs d'anonymiseurs et score de risque calculé), si bien que vous n'avez pas à assembler cinq fournisseurs pour répondre à une seule question. Voici ce qui travaille face à chaque menace :
- Un score de risque de 0 à 100 issu de 36 raisons pondérées. Au lieu d'un simple indicateur oui ou non, GeoIPHub renvoie un score explicable avec des tranches de décision intégrées, allow (25 ou moins), review (50 ou moins), step-up (75 ou moins) et block (plus de 75), de sorte que la même requête peut être réglée plus strictement au paiement qu'à la connexion.
- Détection de VPN et de proxys par sondage actif. Au-delà des listes statiques, GeoIPHub exécute de vraies sondes de négociation sur plus de 25 ports et 8 protocoles, et recoupe les listes de serveurs des fournisseurs de VPN eux-mêmes avec une liste publique tierce, de sorte que la réponse reflète l'infrastructure en service, pas la liste de blocage du mois dernier.
- Détection des datacenters et des hébergeurs. La couverture comprend 853 ASN d'hébergeurs sélectionnés ainsi que les plages officielles de 10 fournisseurs cloud, le signal qui démasque les bots de carding, les scrapers et l'infrastructure de stuffing qui se font passer pour des navigateurs.
- Des données Tor actualisées chaque jour et 19 flux de plages officielles de robots d'exploration et de bots d'IA (Googlebot, GPTBot, ClaudeBot, PerplexityBot et d'autres), de sorte que les sorties anonymisées et les bots qui s'identifient eux-mêmes sont évalués par rapport à la réalité de terrain du moment.
- Plus de 30 sources de données et 5 flux WHOIS des RIR derrière tout cela, avec des requêtes en cache inférieures à la milliseconde et des IP inconnues classées en direct en moins de 2,5 secondes, assez vite pour s'insérer en ligne à la connexion, à l'inscription et au paiement.
Le service respecte aussi la vie privée par construction : vous n'envoyez que l'IP que vous voulez classifier et vous recevez des attributs de réseau et de risque. Aucun nom, e-mail ni donnée de paiement n'est nécessaire pour évaluer une requête.
Vous pouvez essayer les signaux directement avec l'outil gratuit de recherche d'IP, vérifier le score de fraude de n'importe quelle IP ou tester la détection de VPN sur votre propre connexion. Quand vous serez prêt à l'intégrer à votre application, le guide d'intégration en 10 minutes explique comment évaluer chaque requête avec cURL, Node et Python, sur une offre gratuite qui renvoie tous les champs, 1 500 requêtes par jour, sans champ réservé.
Augmenter le coût pour l'attaquant, pas la friction pour vos clients
La cybercriminalité est industrialisée, automatisée et de moins en moins humaine, et tout cela transite par une adresse IP que vous pouvez inspecter en premier. Les données IP n'arrêteront pas la fraude à elles seules, et tout traitement honnête du sujet le dit. Mais comme couche de provenance d'une défense en profondeur (le signal qui vous dit quelles sessions méritent un examen plus attentif), elles comptent parmi les contrôles les plus utiles et les moins intrusifs que vous puissiez déployer. Bien utilisées, elles augmentent le coût de l'attaque pour la minorité criminelle sans taxer la majorité légitime.
FAQ
Qu'est-ce que l'intelligence IP ?
L'intelligence IP consiste à enrichir une adresse IP brute de tout ce qu'elle révèle sur son origine et sa fiabilité : géolocalisation, réseau propriétaire (ASN), type de connexion, nature de l'adresse (datacenter, VPN, proxy ou nœud de sortie Tor), historique d'abus et score de risque calculé. Elle transforme l'attribut le plus universel de toute requête en ligne en un signal de décision exploitable avant qu'un mot de passe soit saisi ou qu'une carte soit débitée. Elle va plus loin que la géolocalisation IP, qui répond seulement à « où est cette IP » ; l'enrichissement répond aussi à « puis-je lui faire confiance ».
Comment les données IP aident-elles à prévenir les cyberattaques ?
Presque toutes les attaques (credential stuffing, test de cartes, scraping, création de faux comptes, paiements frauduleux) arrivent par une adresse IP, et les attaquants réutilisent leur infrastructure à grande échelle. Une requête met au jour les indices que cette infrastructure laisse derrière elle : une connexion depuis un ASN d'hébergeur, un paiement depuis un serveur VPN confirmé par sondage, un « navigateur » qui est en réalité un script dans le cloud. Utilisées comme signal de risque en temps réel à la connexion, à l'inscription et au paiement, ces données permettent de challenger ou de bloquer la minorité suspecte sans ajouter de friction pour la majorité légitime.
La géolocalisation IP seule peut-elle arrêter les cyberattaques ?
Non, et tout fournisseur qui l'affirme survend son produit. Les données IP forment une couche dans un modèle de défense en profondeur. Une IP mobile partagée peut porter à la fois un fraudeur et un vrai client, une IP résidentielle saine peut héberger un proxy, et un attaquant muni d'identifiants volés sur une connexion domestique dans la ville de la victime passe tous les contrôles IP. Les signaux IP sont les plus efficaces lorsqu'ils sont combinés à des signaux d'appareil, de comportement, de vélocité et d'identité. Utilisez le score de risque pour décider quelles sessions méritent un examen plus poussé, pas pour prononcer des blocages généralisés.
Quels types de cybercriminalité les signaux IP peuvent-ils détecter ?
Les signaux IP contribuent à détecter la prise de contrôle de compte et le credential stuffing, la fraude à la création de comptes et à l'identité synthétique, la fraude au paiement et le test de cartes, le trafic automatisé de bots et de scrapers, les robots d'exploration qui revendiquent un nom que leur IP ne confirme pas, ainsi que le contournement de politiques ou de sanctions via des VPN et des proxys. Dans chaque cas, ils constituent la couche de provenance : ils indiquent si la connexion provient d'une infrastructure cohérente avec une vraie personne ou avec une activité automatisée ou anonymisée. Ils ne détectent pas les proxys résidentiels ; ceux-ci exigent des signaux d'appareil et de comportement.
Qu'est-ce que la détection de déplacement impossible et comment fonctionne-t-elle ?
La détection de déplacement impossible signale deux connexions au même compte depuis des lieux trop éloignés pour être parcourus dans le temps qui les sépare. Londres et Singapour sont distantes d'environ 10 850 km : une connexion depuis Londres suivie d'une connexion depuis Singapour 30 minutes plus tard signifie que l'une des deux n'est pas le titulaire du compte. Enregistrez la latitude et la longitude de chaque connexion, calculez la distance par rapport à la précédente et signalez les paires qui exigeraient plus d'environ 900 km/h, soit à peu près la vitesse d'un avion de ligne. Ignorez les connexions issues d'adresses VPN, Tor ou de relais, car leur position n'est pas celle de l'utilisateur.
Dois-je bloquer tout le trafic de certains pays ?
Le blocage par pays est un instrument grossier aux dommages collatéraux importants. Avant de bloquer un pays entier, vérifiez si vous y avez des utilisateurs légitimes, car un blocage défini une fois pour toutes les touchera aussi. Des alternatives plus ciblées existent : exiger une vérification renforcée pour les parcours sensibles tels que le paiement et la réinitialisation du mot de passe, ne recourir à une restriction géographique stricte que lorsque la loi ou un contrat l'impose, et combiner le pays avec des signaux réseau (ASN d'hébergeur, détection de VPN) afin de cibler l'infrastructure abusée plutôt que la population dont elle semble provenir.
L'intelligence IP est-elle la même chose que la géolocalisation IP ?
Non. La géolocalisation IP en est un sous-ensemble. Elle associe une IP à un pays, une région et une ville approximative, avec une précision d'environ 99 % au niveau du pays mais bien plus faible au niveau de la ville. La requête complète inclut la géolocalisation, mais ajoute le réseau propriétaire (ASN), le type de connexion, les indicateurs VPN, proxy, Tor et datacenter, les signaux d'abus et un score de risque composite. La géolocalisation dit où ; le reste dit s'il faut faire confiance.
Le scoring de risque basé sur l'IP enfreint-il la vie privée ou le RGPD ?
Il porte sur l'adresse IP et les métadonnées réseau, pas sur les noms, les e-mails ou les données de paiement. Avec GeoIPHub, vous n'envoyez que l'IP à classifier et vous recevez en retour des attributs de réseau et de risque. Aucun échange de données personnelles n'est nécessaire pour évaluer une requête. Au titre du RGPD, une adresse IP peut constituer une donnée personnelle ; les bonnes pratiques restent donc applicables : l'utiliser pour la finalité légitime de prévention de la fraude et de sécurité, limiter la durée de conservation et documenter le traitement. Évaluer le risque d'une IP est un contrôle de sécurité, pas du suivi d'utilisateurs.
L'équipe derrière l'API GeoIPHub
Rédigé par l'équipe GeoIPHub, les personnes qui développent l'API de renseignement IP GeoIPHub et son scanner. Les brouillons sont préparés avec l'aide de l'IA et relus par l'équipe ; les exemples d'API sont de vraies requêtes sur l'API en production, sauf mention « illustratif ».
Sécurité réseau
