Proxies résidentiels vs blocage IP : ce qui fonctionne

Environ un quart des nœuds de sortie résidentiels vendus par les grands fournisseurs tournent sur des appareils dont les propriétaires ignorent totalement qu'ils font partie d'une infrastructure. Cette estimation vient de plusieurs années de travaux académiques sur ces réseaux, et elle explique beaucoup de choses, y compris le fait qu'une entreprise de sécurité ait récemment repéré des sorties de proxies résidentiels dans une plage d'IP attribuée au Executive Office of the President. Quand les chercheurs ont remarqué ce trafic, dont la moitié arrivait entre 17 h et minuit, heure de l'Est, internet s'en est donné à cœur joie. Mais derrière les blagues se cache une leçon réelle pour nous tous : les proxies résidentiels sont le moyen le plus efficace de contourner les défenses basées sur les IP, et si votre modèle de menaces considère encore « IP résidentielle » comme un signal de confiance, vous êtes en retard d'une génération.

J'ai passé quatre ans à gérer la détection pour une entreprise SaaS de taille moyenne, et le changement était visible en temps réel dans nos tableaux de bord. Au moment où les équipes de credential stuffing sont passées des proxies de datacenter aux sorties résidentielles, nos listes de blocage d'IP sont passées de 80 % du trafic d'attaque détecté à presque rien. Mêmes attaques, mêmes outils, mais un dernier saut différent. Cet article explique pourquoi cela arrive et ce qui fonctionne vraiment quand la réputation IP ne sert plus à rien.

Comment fonctionnent réellement les proxies résidentiels

Un proxy résidentiel n'est qu'un nœud de sortie tournant sur un appareil grand public : un téléphone, une smart TV, une box TV, un routeur domestique. Le client du réseau de proxies paie pour le trafic qui sort de ces appareils, et le travail du fournisseur est d'en avoir des millions disponibles dans chaque zone géographique. L'offre provient de trois sources, classées de la plus respectable à la moins respectable.

1. SDK à adhésion volontaire. Des applications gratuites (VPN, widgets météo, jeux mobiles, applications « gagnez de l'argent en partageant votre bande passante ») intègrent un SDK de proxy. Le consentement est enterré dans des conditions d'utilisation que personne ne lit, mais il existe techniquement. C'est le modèle que les gros fournisseurs mettent en avant quand ils parlent d'éthique.
2. Micrologiciels compromis et malwares. Les botnets monétisent leurs machines depuis des années via la revente de proxies. Une box Android bon marché flashée en usine avec un micrologiciel douteux devient un nœud de proxy dès qu'elle se connecte. Le propriétaire croit avoir acheté un lecteur multimédia.
3. Location pure et simple de botnets. Le bas de gamme ne fait pas semblant. Si un fournisseur propose cinquante millions d'IP tournantes sans politique d'approvisionnement affichée, vous pouvez faire le calcul.

L'essentiel est de voir ce que cela donne du côté du défenseur. Le trafic arrive depuis un ASN résidentiel de Comcast, BT ou Deutsche Telekom. L'IP se géolocalise dans une ville plausible. Le DNS inverse renvoie quelque chose comme pool-96-225-14-7.nycmny.fios.verizon.net. Toutes les heuristiques que nous avons construites dans les années 2010 disent : c'est un humain chez lui. Ce n'en est pas un. C'est un relais facturé 3 $ le gigaoctet, et l'humain chez lui ignore totalement son existence.

Ce dernier point mérite qu'on insiste, car c'est la partie de l'histoire qui devrait vous inquiéter même si vous n'achetez ni ne combattez jamais de proxies. Le même SDK qui relaie la bande passante est un logiciel sous le contrôle à distance de quelqu'un d'autre, qui tourne à l'intérieur de votre périmètre réseau. Aujourd'hui, il vend de la bande passante. Rien dans l'architecture n'empêche l'opérateur, ou quiconque compromet l'opérateur, de confier à ces nœuds une tâche bien pire. Un SDK de proxy sur un appareil à l'intérieur d'un réseau sensible n'est pas un problème de bande passante. C'est un point d'ancrage avec un service de facturation.

Pourquoi les défenses basées sur les IP sont mortes

La réputation IP avait du sens quand les abus venaient d'endroits qui ressemblaient à des abus : hébergeurs à l'épreuve des balles, plages de datacenters détournées, proxys ouverts sur des instances VPS oubliées. On pouvait énumérer les mauvais quartiers. Les proxies résidentiels ont mis fin à cette époque en déplaçant le mauvais trafic dans les bons quartiers, un salon compromis à la fois.

L'économie aggrave les choses. L'espace d'adressage des datacenters est fini et très surveillé : brûlez un /24 et il figure sur toutes les listes de blocage en moins d'un jour. Les nœuds de sortie résidentiels sont pratiquement infinis et se régénèrent d'eux-mêmes. Une seule opération de credential stuffing peut faire tourner des dizaines de milliers d'IP domestiques distinctes, chacune ne faisant que deux ou trois requêtes, sans jamais déclencher les limites de débit par IP. Votre WAF voit dix mille « utilisateurs » différents. Bloquer une IP isolée ne sert à rien ; bloquer tout l'ASN revient à bloquer vos vrais clients.

C'est aussi pourquoi « le trafic venait de la Maison-Blanche » demande une précision, et les sceptiques dans toute discussion sur cette affaire ont raison de la soulever. Posséder une plage d'IP ne signifie pas que chaque annonce correspond à un seul lieu physique. Les grandes organisations annoncent des plages depuis de nombreux sites, exploitent des réseaux invités, des laboratoires et des superpositions NAT opérateur. Une IP de sortie dans la plage d'une organisation vous dit à qui appartient l'espace, pas à quel bureau les paquets ont été émis. Quand vous faites cette analyse sur votre propre réseau, et vous devriez, traitez l'attribution comme une hypothèse à vérifier dans vos journaux de flux internes, pas comme une conclusion.

Les signaux de détection qui fonctionnent encore

La réputation IP est morte, mais le trafic n'est pas invisible. Les sorties de proxies ont des empreintes. Aucun de ces signaux n'est suffisant seul, chacun ayant des explications légitimes, mais combinés ils sont remarquablement efficaces. C'est la démarche standard de l'ingénierie de détection moderne : arrêter de chercher l'arme fumante et commencer à construire un score à partir de signaux faibles. La même philosophie apparaît dans l'empreinte comportementale des scripts obfusqués : inutile de lire le code si vous savez caractériser son comportement.

Analyse de l'ASN et de la forme des connexions

Commencez par l'ASN, mais ne vous arrêtez pas à « est-ce résidentiel ». La vraie question est de savoir si l'ASN correspond au client annoncé. Une requête présentant un user agent Chrome sur ordinateur de bureau et arrivant depuis une plage 5G grand public d'un opérateur mobile est suspecte. Il en va de même pour du trafic venant d'un ASN de FAI grand public qui frappe votre API avec une concurrence typique d'un datacenter. Les nœuds de proxy sont de vraies maisons, et les vraies maisons ont de vraies contraintes : débit montant grand public, tables NAT, partage d'adresses via CGNAT. Une IP de sortie qui sert quarante clients de proxy différents en une heure produit des schémas de connexion qu'aucun foyer ne produit.

Empreintes TLS et TCP

C'est là que vous attrapez les opérateurs négligents. La plupart des clients de proxy font passer leur trafic par le logiciel client du fournisseur ou par des bibliothèques HTTP standard : Python requests, net/http de Go, Node. Chacune a un ClientHello TLS distinct : ordre des suites de chiffrement, listes d'extensions, groupes supportés. Les empreintes JA3 et JA4 vous permettent de comparer ce que dit la poignée de main TLS sur le client à ce que son user agent prétend être. Un « Chrome 126 sous Windows » qui envoie une empreinte TLS de Go est un bot déguisé. Certains réseaux de proxy sophistiqués font un passage TLS complet depuis la machine du client, ce qui préserve le mensonge, mais beaucoup ne le font pas, et même les bons trahissent quelque chose au niveau TCP. Un client Windows annoncé derrière un TTL et une taille de fenêtre qui indiquent Linux ajoute un point au score.

Latence et schémas temporels

Chaque proxy résidentiel ajoute un saut passant par du matériel grand public sur des liaisons montantes grand public. Ce saut a un coût. Si votre service voit aussi la vraie latence du client via WebRTC, une mesure depuis un nœud de CDN, ou même la distribution temporelle des requêtes au sein d'une session, vous pouvez comparer le RTT réseau à la géographie annoncée. Un « utilisateur à Denver » avec un RTT de 4 ms vers votre datacenter en Virginie n'est pas à Denver. Le timing au sein des sessions compte aussi : la navigation humaine comporte des pauses de lecture, des mouvements de souris, une cadence irrégulière. Le trafic acheminé par un proxy depuis un script d'automatisation a une régularité de métronome : intervalles entre requêtes constants, aucune dérive d'inactivité, soumissions de formulaire instantanées. Même quand les attaquants ajoutent de la gigue, c'est une gigue tirée d'une distribution qu'un humain ne produirait jamais.

Heuristiques comportementales

Le signal le plus fort est ce que fait le client, pas ce qu'il est. Les vrais utilisateurs flânent. Les bots exécutent des plans. Une session qui se connecte, accède directement à la page des paramètres via une URL qu'aucun parcours de l'interface ne mène là, change l'adresse e-mail et envoie une demande de paiement en quatre-vingt-dix secondes n'est pas une personne, quelle que soit son IP. Mesurez l'entropie des séquences : les sessions parcourent-elles votre application comme votre frontend les guide réellement, ou frappent-elles des endpoints dans un ordre que seul quelqu'un lisant votre documentation d'API choisirait ? L'agrégation inter-sessions est la fonctionnalité décisive ici. Une IP résidentielle qui fait trois requêtes semble innocente. Trois cents IP résidentielles faisant chacune trois requêtes avec des empreintes TLS identiques, des résolutions d'écran identiques et la même séquence d'endpoints, c'est une seule opération avec trois cents déguisements.

Chasse aux menaces : SDK de proxy sur votre propre réseau

Le problème entrant attire l'attention, mais l'histoire qui a déclenché tout cela est en réalité une histoire sortante : un appareil sur un réseau qui devrait faire mieux relayait le trafic d'autres personnes. C'est le scénario sur lequel vous pouvez réellement agir, car vous contrôlez le périmètre. Partez du principe qu'un utilisateur finira par brancher une box de streaming compromise ou installer un « VPN gratuit » sur un téléphone professionnel. Votre travail est de rendre cet événement bruyant.

La logique de détection est simple, car les SDK de proxy ont une posture caractéristique. Un nœud existe pour recevoir des instructions et relayer du trafic, ce qui signifie :

• Connexions de contrôle persistantes. Des sessions TLS longue durée vers des domaines ou IP inconnus, souvent avec de minuscules charges utiles périodiques. Établissez une base de référence de vos destinations sortantes ; un appareil client qui maintient une connexion de six heures vers un hôte dans un pays où aucun de vos éditeurs logiciels n'opère mérite un coup d'œil.
• Fan-out de connexions élevé depuis un appareil client. Un poste de travail qui ouvre des centaines de connexions sortantes vers des IP externes distinctes par heure se comporte comme une infrastructure, pas comme une personne. Les ordinateurs portables naviguent ; les relais relaient.
• Flux initiés depuis l'extérieur vers les sous-réseaux clients. Beaucoup de frameworks de proxy ouvrent des tunnels entrants ou utilisent une traversée NAT de type STUN. Si un appareil sur votre VLAN invité ou IoT reçoit des connexions depuis Internet, votre segmentation est gravement défaillante : trouvez la faille.
• Schémas d'envoi asymétriques. Un téléphone ou une box TV dont le volume d'envoi approche celui de la réception sert du contenu ou relaie du trafic. Ni l'un ni l'autre n'est normal pour des appareils grand public.
• Bases de référence horaires. Les chercheurs qui ont repéré les sorties sur le réseau gouvernemental s'étaient appuyés exactement sur cela : une activité concentrée en soirée suggérait un appareil sur un réseau personnel, et non invité. Votre version est plus simple : alertez quand le schéma de trafic d'un appareil change de nature, et pas seulement de volume.

Rien de tout cela ne nécessite l'inspection profonde des paquets, ce qui compte si vous tenez à faire tourner un réseau auquel les gens peuvent se fier. Les métadonnées de flux (NetFlow, journaux conn de Zeek, journaux de flux VPC) portent tous les signaux ci-dessus. Si vous ne conservez pas et ne modélisez pas déjà vos flux sortants, c'est la lacune à combler avant d'acheter quoi que ce soit. Les angles morts ici ressemblent à ceux de la journalisation de l'authentification cloud : les données existent, mais personne ne les regarde tant qu'un incident ne survient pas.

# Quick-and-dirty hunt: client devices acting like relays
# Feed this Zeek-style conn logs; flag RFC1918 sources with
# high distinct-destination fan-out and heavy upload ratios.
awk -F'\t' '
$3 ~ /^(10\.|192\.168\.|172\.(1[6-9]|2[0-9]|3[01]))/ {
src=$3; dst=$5
up[src]+=$10; down[src]+=$12
seen[src SUBSEP dst]=1
}
END {
for (k in seen) { split(k,a,SUBSEP); fanout[a[1]]++ }
for (s in fanout)
if (fanout[s] > 200 && up[s] > down[s] * 0.5)
printf "%s dsts=%d up=%d down=%d\n", s, fanout[s], up[s], down[s]
}' conn.log | sort -t= -k2 -nr | head -20

C'est une première passe, pas un produit fini : ajustez le seuil de fan-out à vos propres bases de référence, et attendez-vous à des faux positifs de la part de vos serveurs multimédias et de vos agents de sauvegarde tant que vous ne les aurez pas mis en liste blanche. L'idée est que la chasse coûte peu. Un après-midi d'analyse de journaux trouve ce qu'une appliance à six chiffres trouverait.

La segmentation est la vraie solution

Voici mon avis tranché, forgé à la dure : vous ne gagnerez jamais la course aux armements de la détection contre des appareils grand public compromis. L'offre est trop vaste et les fournisseurs qui livrent des micrologiciels peu sûrs ne subissent aucune conséquence. Ce que vous pouvez faire, c'est rendre un appareil compromis inoffensif. Une box de streaming infectée sur un VLAN IoT correctement segmenté peut vendre sa bande passante à un réseau de proxies : c'est agaçant, potentiellement embarrassant si votre plage d'IP est sensible, mais elle ne peut pas atteindre vos partages de fichiers, vos API internes ou quoi que ce soit qui transformerait un embarras en fuite de données.

Le schéma est toujours le même dans les revues d'incidents. L'organisation avait un réseau à plat, ou un réseau « invité » capable d'atteindre le DNS interne et les interfaces d'administration, ou une politique d'apportez votre propre appareil appliquée uniquement par une case à cocher. Puis une box Android bon marché ou un téléphone avec un SDK intégré a rejoint le réseau, et l'IP de sortie de l'organisation s'est mise à apparaître dans les inventaires des fournisseurs de proxies. Le correctif après coup est ce qu'il aurait dû être avant : isolation des clients sur les réseaux invités, appareils IoT sur un VLAN avec accès sortant uniquement et destinations RFC1918 bloquées, appareils personnels très loin des zones de confiance de production. La défense en profondeur n'est pas glamour, mais comme nous l'avons expliqué à propos des défenses en couches face aux contrôles uniques et robustes, ce sont les couches qui vous sauvent quand un contrôle lâche, et il y en a toujours un qui lâche.

Une discussion de politique interne mérite aussi d'avoir lieu. Les applications « gratuites » sont le principal vecteur de ces SDK. Si votre personnel peut installer n'importe quel logiciel sur des appareils qui touchent votre réseau, vous avez délégué votre périmètre à des entreprises d'adtech mobile. Certaines organisations répondent par MDM et listes blanches d'applications ; pour la plupart, la segmentation réseau offre le même confinement avec moins de coût politique.

Ce que cette histoire nous apprend vraiment

Au-delà des spéculations politiques, l'affaire est une démonstration claire de deux faits. D'abord, la détection des proxies résidentiels est devenue une catégorie de produits à part entière : les chercheurs peuvent désormais énumérer les nœuds de sortie à grande échelle et les rattacher à des plages d'IP, ce qui est une télémétrie réellement utile. Ensuite, et c'est plus inconfortable, chaque réseau ne se trouve qu'à un appareil imprudemment branché de devenir l'infrastructure de quelqu'un d'autre. Les réseaux les mieux protégés au monde comptent encore des humains, et les humains branchent des choses.

Si vous ne retenez qu'une chose : vérifiez si les IP de sortie de votre organisation figurent dans les inventaires de proxies résidentiels. Plusieurs services peuvent vous le dire, et votre flux de renseignements sur les menaces l'intègre peut-être déjà. Voir votre plage listée n'est pas la preuve d'une compromission, car le CGNAT et les espaces d'adressage partagés brouillent le tableau, mais c'est un point de départ peu coûteux et très révélateur pour une chasse. Ensuite, examinez votre fan-out sortant, vos connexions longue durée et la conception de vos VLAN.

Les attaquants se sont installés dans les bons quartiers il y a des années. Les défenseurs qui l'ont remarqué sont ceux qui ont cessé de vérifier les adresses et ont commencé à observer les comportements.