Comment savoir si une adresse IP est un proxy (pas à pas)

Comprendre le problème de la détection de proxy

Savoir si une connexion entrante provient d’un proxy est une vérification courante lorsqu’on enquête sur un abus, que l’on protège des points d’authentification ou que l’on analyse un trafic réseau inhabituel. Les proxies prennent de nombreuses formes : relais HTTP/SOCKS ouverts, serveurs VPN commerciaux, infrastructures de scraping hébergées en datacenter, nœuds de sortie Tor ou encore réseaux de proxies résidentiels.

Comme chaque architecture de proxy interagit différemment avec le routage IP et les protocoles de transport, aucune commande manuelle ne permet à elle seule d’obtenir une réponse définitive. La détection repose plutôt sur le croisement de plusieurs signaux réseau indépendants. Ce guide détaille les vérifications pratiques à mener sur une IP, puis explique comment passer à une détection à grande échelle.

Étape 1 : examiner le DNS inverse (rDNS) et les enregistrements PTR

Les recherches DNS inverses permettent d’associer une adresse IP au nom de domaine configuré côté opérateur. De nombreux hébergeurs, FAI grand public et opérateurs mobiles utilisent des conventions de nommage assez structurées dans leurs enregistrements PTR, ce qui donne souvent des indices sur le contexte d’utilisation de l’IP.

Vous pouvez interroger l’enregistrement PTR avec dig :

bash dig -x 198.51.100.42 +short

Ce que ce signal peut révéler

• FAI résidentiel ou haut débit : des noms d’hôte contenant des segments comme pool, cable, fiber, dhcp, ou des formats dynamiques fondés sur les octets de l’adresse IP (par exemple 198-51-100-42.dyn.exampleisp.net), correspondent généralement à des accès grand public classiques.
• Datacenter ou VPS : des noms d’hôte contenant vps, server, compute, hosted-by, linode, ovh, ou des noms cloud bruts (par exemple ec2-198-51-100-42.compute-1.amazonaws.com) signalent plutôt une infrastructure de datacenter. Un visiteur web légitime navigue rarement directement depuis un VPS, sauf s’il passe par un VPN ou un proxy auto-hébergé.
• PTR absent ou générique : de nombreux opérateurs de proxies utilisent des VPS bon marché sans configurer de DNS inverse cohérent ni de forward-confirmed reverse DNS (FCrDNS).

Limites

Les acteurs qui utilisent des réseaux de proxies résidentiels font transiter le trafic via des équipements grand public compromis ou loués. L’enregistrement PTR affichera alors un FAI résidentiel tout à fait normal, ce qui contourne complètement ce type de vérification.

Étape 2 : interroger l’ASN et les données de routage

Toute adresse IP appartient à un système autonome, ou Autonomous System (AS). L’enregistrement de l’AS indique l’entité qui détient le bloc IP et l’annonce via BGP. Les utilisateurs résidentiels classiques reçoivent des IP rattachées aux ASN d’opérateurs télécoms grand public, tandis que les proxies commerciaux et les serveurs VPN se trouvent presque toujours dans des ASN d’hébergement, de cloud ou de colocation.

Vous pouvez obtenir les informations ASN via les services DNS ou WHOIS de Team Cymru :

bash whois -h whois.cymru.com " -v 198.51.100.42"

Vous pouvez aussi interroger directement les registres Internet régionaux (ARIN, RIPE, APNIC) :

bash whois 198.51.100.42 | grep -iE "origin|org-name|descr|nettype"

Interpréter les signaux ASN

• Si l’IP appartient à DigitalOcean, Hetzner, OVH, AWS ou M247, et que l’utilisateur est censé être un simple visiteur web interactif, il passe vraisemblablement par un intermédiaire : VPN, proxy commercial ou script automatisé.
• Vérifiez le champ NetType ou le type d’attribution. Les blocs réalloués ou portables associés à des agrégateurs de proxies font souvent apparaître des noms d’entreprises distincts de l’opérateur télécom sous-jacent.

Limites

Les contrôles au niveau ASN ne détectent pas les proxies résidentiels lorsque l’opérateur apparent reste AT&T, Comcast ou un opérateur mobile international.

Étape 3 : vérifier les nœuds de sortie Tor et les listes de menace

Le réseau Tor publie une liste dynamique et faisant autorité des adresses IP de ses nœuds de sortie actifs. Comme ces relais de sortie sont publics, comparer une IP à cette liste offre un niveau de confiance élevé.

Vous pouvez récupérer directement la liste active :

bash curl -s https://check.torproject.org/torbulkexitlist | grep -x "198.51.100.42"

Vous pouvez aussi effectuer une vérification DNS via la DNSBL du Tor Project :

bash # Inverser les octets de l’IP cible et interroger la zone dnsel dig 42.100.51.198.ip-port.exitlist.torproject.org A +short

Si cette requête renvoie 127.0.0.2, l’IP est un nœud de sortie Tor actif.

Limites

Tor ne représente qu’une sous-catégorie des outils d’anonymisation. Les blocklists publiques de proxies ouverts sont notoirement instables : elles recensent des proxies qui disparaissent parfois en quelques minutes, ce qui entraîne beaucoup de faux positifs lorsque des plages IP sont réattribuées.

Étape 4 : analyser les ports, passivement ou activement

Les proxies exécutent souvent des logiciels à l’écoute sur des ports standards ou secondaires. Lancer un scan de ports intrusif sur chaque connexion cliente serait excessif, lent et souvent discutable juridiquement. En revanche, dans le cadre d’une investigation manuelle après incident, inspecter quelques ports courants peut se justifier.

bash nc -zv -w 2 198.51.100.42 8080 3128 1080 8888 80

• Port 1080 : port SOCKS standard.
• Port 3128 : port par défaut de Squid pour un proxy HTTP.
• Ports 8080, 8888 : alternatives fréquentes pour des relais HTTP.

Si la connexion à ces ports renvoie un en-tête HTTP comme Proxy-Agent, Via: 1.1 squid, ou interrompt une négociation SOCKS inattendue, l’hôte est très probablement un serveur proxy.

Limites

Les VPN commerciaux de production, les reverse proxies et les daemons de proxies résidentiels n’écoutent généralement pas publiquement sur les interfaces exposées aux clients. Ils établissent plutôt des tunnels sortants vers un nœud d’orchestration, sans laisser de port entrant visible.

Vérifications manuelles vs réalité du terrain

| Technique | Signal principal | Angle mort majeur | | :--- | :--- | :--- | | DNS inverse | Noms d’hôte de datacenter, PTR manquant | Les proxies résidentiels ressemblent à des IP de FAI grand public | | Recherche ASN | Classification hébergeur/cloud | Ne signale pas le trafic relayé par des sous-réseaux résidentiels | | Listes de sortie Tor | Liste déterministe des sorties Tor actives | Aveugle aux VPN, SOCKS et proxies commerciaux | | Sondage de ports | Daemons proxy exposés (Squid, SOCKS) | Les tunnels modernes utilisent des connexions inverses sortantes |

Étape 5 : automatiser l’IP intelligence en temps réel

L’inspection manuelle est utile pour analyser un incident après coup, mais les applications interactives ont besoin de décisions en moins d’une seconde pendant une connexion, un paiement ou une inscription. À ce niveau, le principal défi est la détection des proxies résidentiels : repérer qu’une IP appartenant à un vrai FAI grand public sert en réalité de tunnel backconnect.

Pour y parvenir, il faut agréger annonces BGP, télémétrie de sondes actives, honeypots et comportements de connexion dans une seule réponse exploitable. Un service d’IP intelligence comme Guarda, via guarda.net, consolide ces signaux dans une réponse JSON unifiée :

bash curl -s "https://api.guarda.net/v1/ip/198.51.100.42" \ -H "Authorization: Bearer YOUR_API_KEY"

Une réponse typique renvoie des classifications booléennes distinctes, ainsi qu’un score de risque global :

{ "ip": "198.51.100.42", "is_proxy": true, "is_vpn": false, "is_tor": false, "is_datacenter": true, "asn": { "number": 16276, "org": "OVH SAS" }, "risk_score": 88 }

Ces champs structurés permettent à votre pare-feu ou à votre code applicatif d’appliquer des politiques fines : par exemple refuser les IP de datacenter à l’inscription tout en autorisant les VPN d’entreprise, ou renforcer l’authentification uniquement lorsque is_proxy vaut true ou lorsque le risk_score dépasse un seuil défini.

Si vous voulez tester une IP immédiatement sans mettre en place de script, vous pouvez lancer une vérification gratuite directement depuis la page d’accueil de guarda.net, qui a déjà traité plus de 594,400 recherches.