Proxys en tant que service : comment identifier les fournisseurs de proxys via les bots-as-a-service

Il existe une multitude de fournisseurs de proxys sur le web pour tous les types de tâches de bots imaginables. Nous allons nous concentrer aujourd’hui sur les fournisseurs de proxys qui exposent leur réseau via des bots en tant que service (BaaS) pour faciliter le processus de scraping.

Lorsqu’il s’agit de scraping, l’objectif du bot est de collecter des détails sur les produits ; les sessions peuvent donc être très courtes et différentes pour chaque produit. Ainsi, le bot peut fréquemment changer d’adresse IP. En revanche, cette stratégie ne convient pas au scalping, où une session cohérente est nécessaire depuis la visite de la page produit jusqu’au paiement. Pour le scraping, une bonne source de proxys augmentera considérablement le taux de succès du bot : même si certaines requêtes sont bloquées, le volume de requêtes contournera toutes les adresses IP bannies.

Cet article explique comment DataDome identifie les réseaux de proxys à partir de ces services, comment détecter les BaaS et quel type d’adresses IP se cache derrière les BaaS.

Pourquoi utiliser les bots en tant que service ?

À grande échelle, pour scraper des milliers de pages produits par minute, la gestion des bots devient un défi sur les sites web protégés. Ils doivent se connecter à de multiples sources de proxys, orchestrer la rotation des adresses IP, éviter de changer d’IP après avoir passé un défi CAPTCHA, et surveiller le taux de réussite pour mettre à jour leur source de proxys.

Comme le scraping peut être un défi complexe, il est courant de voir des BaaS offerts par des fournisseurs de proxys pour simplifier la tâche : les développeurs de bots n’ont qu’à fournir les URL que les bots doivent scraper. Plusieurs paramètres optionnels et génériques peuvent être spécifiés, comme le type de navigateur (plutôt qu’un en-tête user-agent complet), la géolocalisation ou la langue principale (plutôt qu’un header Accept-Language complet).

{
"url": "https://target.com/page/to/scrape.html",
"geolocation": "United States",
"locale": "en-us",
"user_agent_family": "desktop_chrome"
}

En arrière-plan, le BaaS prend en charge le reste des tâches pour éviter la détection des bots :

• Sélectionner des adresses IP correspondant à la géolocalisation demandée.
• Générer des header et des empreintes digitales crédibles.
• Configurer les cookies.
• Réessayer avec une autre IP si une requête est bloquée (mais s’arrêter si toutes les requêtes échouent).
• Suivre les redirections, le cas échéant.

Ainsi, les fournisseurs de proxys aident les développeurs de bots à simplifier le scraping des sites web protégés, attirant davantage de clients pour leur réseau de proxys. En général, les BaaS offrent différents modes :

• Par défaut : les utilisateurs fournissent simplement l’URL, et laissent le BaaS décider de tout le reste (géolocalisation, navigateur, initiation des cookies nécessaires).
• Standard : les utilisateurs fournissent des contraintes de base (type de navigateur, géolocalisation, langue) ainsi que certains cookies.
• Avancé : les utilisateurs peuvent être très spécifiques et fournir tous les en-têtes qu’ils souhaitent. Cependant, l’avantage du BaaS diminue, car les utilisateurs doivent alors gérer eux-mêmes les empreintes digitales de leurs bots.

Détection des bots en tant que service

Dans cette section, nous présentons une première approche que nous avons adoptée pour détecter un BaaS de scraping ciblant des centaines de sites e-commerce. Pour ce faire, nous nous sommes inscrits au BaaS, avons tenté de scraper des sites web protégés par DataDome et étudié les empreintes digitales afin de caractériser le comportement du BaaS.

Nous avons ensuite localisé d’autres requêtes présentant un comportement et une signature très similaires à nos propres requêtes BaaS pour créer des règles de détection. Comparé au scénario où chaque attaquant construit son propre scraper, le fait que plusieurs attaquants utilisent le même service BaaS implique que les empreintes digitales (comme le timing entre les requêtes, la structure des valeurs d’en-tête utilisées pour représenter une langue, la structure de la chaîne user-agent, les empreintes JavaScript, etc.) sont concentrées. Cela forme un cluster d’empreintes digitales avec des caractéristiques similaires mais anormales qui peuvent être distinguées des humains.

La détection de DataDome s’appuie sur un cookie chiffré qui contient des informations sur la session utilisateur, ainsi que sur plusieurs signaux JavaScript (JS). Cela nous permet d’effectuer une détection comportementale par session. Dans le contexte du BaaS, le JS est exécuté dès la première requête sur la page d’accueil du site web, juste avant le scraping.

Test 1 : Mode par défaut

Pour le premier test, nous avons utilisé le mode par défaut du BaaS, où le cookie DataDome est géré par le BaaS. Après avoir scrapé et collecté nos propres empreintes digitales, nous avons observé que :

• Le BaaS n’envoie que le cookie DataDome et aucun autre cookie lié au site web ciblé.
• L’URL est scrapée dès la première requête. Contrairement à certains BaaS qui effectuent plusieurs requêtes avant d’atteindre l’URL ciblée (pour paraître plus humain), ce BaaS cible directement l’URL demandée.
• Le BaaS initie une nouvelle session DataDome pour chaque URL.

Le graphique ci-dessous montre un échantillon des requêtes bloquées entre le 14 et le 19 mars. Cependant, ce modèle de détection est assez générique et peut correspondre à davantage de bots que le BaaS que nous avons testé.

Test 2 : Mode standard

Pour notre deuxième test, nous avons voulu détecter le mode standard du BaaS. Nous avons fourni un cookie DataDome et observé le comportement de la session :

• Le BaaS transmet uniquement le cookie DataDome fourni par le bot.
• Le cookie DataDome circule entre plusieurs adresses IP.
• Le cookie DataDome indique que la session a déjà effectué des requêtes qui ont été bloquées.

La figure ci-dessous montre un échantillon des requêtes bloquées entre le 14 et le 19 mars.

Nous avons observé que les attaquants choisissent le mode standard environ 10 fois plus souvent que le mode par défaut. En mode standard, les configurations les plus courantes choisies par le BaaS sont la géolocalisation (le pays d’origine des requêtes du bot) et la langue globale (par exemple, l’attaquant indique la locale fr-fr et le BaaS traduit cela en un en-tête de langue complet comme fr-FR,fr;q=0.9).

Cependant, nous avons constaté que l’origine de l’adresse IP et la langue étaient incohérentes 95 % du temps. Cette incohérence provient probablement soit d’une erreur de configuration du bot, soit d’un fournisseur de proxys de mauvaise qualité. Néanmoins, cette incohérence nous a permis de renforcer la détection.

Apprendre sur les réseaux de proxys

Dans cette section, nous étudions les adresses IP de proxy utilisées par le BaaS : le type d’IP utilisées (centre de données ou résidentiel), la distribution des plages d’IP, les nouvelles IP que nous pouvons toujours relier au fournisseur de proxy, et le chevauchement des IP utilisées par d’autres BaaS.

Tout d’abord, le BaaS n’est pas une solution universelle pour toutes les attaques. Il impose la manière dont l’URL à scraper sera demandée. Par exemple, certains fournisseurs préfèrent changer d’adresse IP dès qu’ils sont confrontés à un CAPTCHA, plutôt que de relever le défi. Même avec un délai entre deux URL, l’attaquant n’a aucun contrôle sur la manière dont chacune sera soumise à la cible. Cela se traduit souvent par la même URL demandée par des bots avec exactement la même signature mais plus de 10 adresses IP distinctes, le tout en l’espace d’une minute – sans même charger le défi CAPTCHA.

Nous avons utilisé ces signaux forts pour collecter un échantillon d’environ un million de requêtes identifiées comme une activité de scraping provenant du fournisseur BaaS, et étudié les réseaux de proxys derrière les adresses IP utilisées pour ces requêtes. L’échantillon contient environ 330 000 adresses IP uniques, car le BaaS effectue en moyenne trois requêtes par IP avant de les faire tourner.

Type de proxy

Pour nos tests, nous avons analysé le type et la qualité des proxys utilisés par le fournisseur BaaS, puis les avons divisés en deux catégories principales :

• Proxy de centre de données : l’adresse IP provient de services d’hébergement tels qu’OVH, GCP, AWS, etc. Ce type de proxy offre généralement un large pool d’adresses IP à moindre coût.
• Proxy résidentiel : l’adresse IP provient d’un fournisseur d’accès à internet (FAI) comme AT&T, Orange, Deutsche Telekom, etc. Ce type de proxy permet aux bots de se faire passer plus facilement pour des utilisateurs humains, mais ils sont plus coûteux et le pool disponible est plus restreint.

Sur la base de cette classification, nous avons constaté que 90 % des IP dans l’échantillon de trafic BaaS provenaient de proxys de data centers. En d’autres termes, lorsque l’utilisateur ne paie pas de supplément, le BaaS redirige les requêtes des bots via des proxys de faible qualité. Cela nous permet de renforcer la détection, car les utilisateurs humains ont tendance à visiter les sites web depuis un FAI plutôt que depuis un serveur dans un data center.

Réutilisation des sous-réseaux

Ensuite, nous avons utilisé le même échantillon pour mesurer la distribution des plages d’IP afin de déterminer si les IP sont concentrées dans le même bloc ou réparties sur plusieurs blocs. Dans ce dernier cas, nous pouvons en déduire qu’un bloc entier appartient à un fournisseur de proxys.

Lorsqu’un fournisseur de proxys construit son réseau, il achète ou loue des blocs entiers d’adresses IP. De plus, pour gérer la réputation de ses IP, il renouvellera son réseau en revendant une partie de ses blocs pour en acheter/louer d’autres, ou en utilisant seulement un sous-ensemble à la fois.

D’un point de vue réseau, un bloc d’adresses IP consiste en des adresses contiguës. Par exemple, le bloc de 256 adresses IP allant de 1.2.3.0 à 1.2.3.255 est noté 1.2.3.0/24 et appelé « sous-réseau de classe C ». Un fournisseur de proxys peut acheter/louer un bloc plus grand de 2 048 IP, comme 1.2.3.0 à 1.2.10.255, et le diviser en huit sous-réseaux de classe C : 1.2.3.0/24, 1.2.4.0/24, 1.2.5.0/24, etc. De cette façon, le fournisseur peut utiliser un sous-réseau, et le changer une fois que sa réputation devient insatisfaisante.

La division en sous-réseaux de classe C (bloc de 256 IP) est spécifique ; le fournisseur pourrait diviser son bloc en sous-réseaux plus petits, mais c’est la taille minimale standard dans le monde du web. Internet est un maillage de réseaux, chacun possédant un ensemble de blocs d’adresses IP et communiquant avec ses voisins. Pour acheminer une requête d’un utilisateur (la source) vers le site web visité (la destination), les réseaux Internet transfèrent la requête de pair à pair, de la source à la destination. Cela implique que chaque pair sait à qui transférer la requête ensuite. Pour ce faire, ils annoncent en continu les blocs d’adresses IP qu’ils possèdent et ceux qu’ils sont capables de transférer. Pour que ces annonces restent efficaces, la taille minimale du bloc annoncé est celle d’un sous-réseau de classe C, soit 256 adresses IP.

Ainsi, nous pouvons comprendre comment les fournisseurs de proxys organisent leurs réseaux en étudiant la distribution des IP parmi les sous-réseaux de classe C. À partir de l’échantillon, nous avons regroupé les adresses IP dans leurs sous-réseaux de classe C : le million de requêtes était réparti dans 16 528 de ces sous-réseaux.

La figure ci-dessous décompte le nombre de sous-réseaux dans l’échantillon, en fonction de leur taux d’occupation. Environ 10 000 sous-réseaux ont été observés avec des requêtes provenant d’une ou deux IP seulement sur les 256 disponibles. Cela représente 60 % des sous-réseaux et indique que les fournisseurs de proxys ont de grands réseaux et répartissent beaucoup les IP pour protéger la réputation de leurs adresses IP.

Cependant, pour les IP de data centers (90 % de l’échantillon), nous avons appris quelque chose de précieux : on peut supposer que l’ensemble du sous-réseau de classe C appartient au fournisseur de proxys. Ainsi, nous pouvons anticiper et défier les requêtes provenant d’autres IP non encore vues dans le sous-réseau.

Chevauchement entre les BaaS

DataDome surveille l’activité des fournisseurs de BaaS afin d’analyser le chevauchement des IP entre différents fournisseurs de proxys. À partir de l’échantillon d’environ 330 000 IP uniques observées sur quatre jours provenant d’un BaaS, nous avons constaté que 98 % des IP sont liées uniquement à ce fournisseur de proxy, sans chevauchement avec d’autres, ce qui le rend assez unique parmi les fournisseurs de BaaS. Le BaaS testé est également son propre fournisseur de proxys : il construit lui-même ses réseaux d’IP sans dépendre d’autres fournisseurs de réseau.

Conclusion

Bien que les services de BaaS facilitent la rotation des IP pour les bots, ce qui rend les attaques évolutives même pour des attaquants non formés, ils ne sont pas la meilleure solution pour rester indétectés. Les attaques de BaaS utilisent des comportements et des empreintes digitales distinctes de celles des humains. De plus, à travers ces empreintes, les fournisseurs de proxys révèlent leurs réseaux. Par défaut, à moins que les utilisateurs ne paient plus cher, les fournisseurs de BaaS acheminent les requêtes via des proxys de data centers de faible qualité, les rendant encore plus faciles à repérer et à stopper.

Vous voulez voir comment les attaques de BaaS pourraient affecter votre site web, application mobile ou API ? Essayez notre outil BotTester pour examiner les bots simples, et essayez DataDome gratuitement pour obtenir une vue plus approfondie du trafic automatisé affectant votre entreprise.