Auteur Sujet: Des petits malins usurpent le robot d'indexation de Google, Googlebot (Lu 202 fois)

vivien · « **le:** **Aujourd'hui** à 15:12:58 »

Des petits malins font des requêtes sur LaFibre.info usurpant le robot d'indexation de Google, Googlebot !

Vous pensez que les requêtes ci-dessous viennent de Google pour enrichir son moteur de recherche ?

Et non, c'est de l'usurpation. Les IP sources montrent clairement que ce n'est pas Google qui est derrière ces requêtes.

(Cliquer sur le tableau pour ouvrir un fichier PDF plus complet)

alain_p · « **Réponse #1 le:** **Aujourd'hui** à 16:05:21 »

Est-ce que cela pourrait être aussi des robots d'agents AI parcourant le web pour récupérer des données servant à entrainer les modèles d'IA ?
La question de savoir avec quelles données sont entrainés les modèles IA a peu de réponses précises... Il y a une plainte actuellement déposée par Le New-York Times contre Open AI pour pillage de ses articles...
D'ailleurs Google a lui-même Gemini.

On peut penser aussi que les robots IA absorbent plein de livres en PDF trouvés sur Internet, qui ne sont pas libres de droits...

vivien · « **Réponse #2 le:** **Aujourd'hui** à 16:36:02 »

J'ai des requêtes clairement identifiées comme étant pour l'IA dans le user-agent, ils ne se cachent pas (et je ne bloque pas).

J'ai des requêtes en masse qui proviennent d'une poignée de serveurs et là aussi, c'est peut-être de l'IA. Certains ne sont pas très évolués et vont charger à chaque fois les images de la page qui peuvent être pourtant identiques.

Les requêtes que j'ai mises dans mon PDF, c'est une grande variété de serveurs réseaux différents. Pour moi l'objectif, c'est de faire du déni de service. J'ai passé en revue une partie des AS de ces IP. Ce sont des AS connu pour faire beaucoup beaucoup de requêtes sur ce forum et qui sont pour la plupart bloquées soit de manière temporaire ou manière définitive (dans tous les cas, la première requête passe).

Certains de ces hébergeurs ont pleins de plages /24 (seulement 256 IPv4). Les IP avant et après sont à d'autres acteurs (c'est galère à bloquer, car il ne faut bloquer plus que le /24 pour éviter le surblocage et cela fait plein de règles).

Pour donner une idée du volume de requêtes, j'ai redémarré le serveur, il y a 48h. Depuis, il y a eu 10 millions de requêtes, soit 5 millions par jour (pas forcément avec des user-gagent de Google, il faut varier les plaisirs).

Les requêtes en question sont toutes en IPv4 et viennent hors de France. Beaucoup viennent d'Asie, mais on a aussi des acteurs UK et d'Europe de l'Est (quand je regarde le pays de l'AS qui n'est pas forcément le pays d'où sont émises les requêtes).

Ne pas hésiter à me signaler si il y a surblocage, mais maintenant avec l'expérience je fait attention. Terminé l'époque ou je bloquait l'intégralité d'un /8 qui envoyait beaucoup de DDOS.

acut3 · « **Réponse #3 le:** **Aujourd'hui** à 17:01:12 »

Je n'ai regardé que quelques IP, mais toutes celles que j'ai regardé font tourner un proxy HTTP sur un port qui varie suivant la machine. Elles font aussi toute tourner un serveur Corrosion en libre accès, toujours sur le port 30001. Corrosion est apparemment un système de clustering pour les bases de données sqlite.

Le serveur corrosion a une table "auth" qui semble définir les comptes d'accès au proxy (avec leur nom d'utilisateur et leur mot de passe), mais pour les IP que j'ai regardé, il n'y a pas de lignes (donc pas de comptes définis à priori).

Par exemple :

Code: [Sélectionner]

$ IP=155.254.34.75; curl -gs "http://$IP:30001/v1/queries" -X POST --json '"SELECT * FROM auth"' | jq 
{
  "columns": [
    "proxy_user_id",
    "username",
    "password",
    "allocation_method",
    "max_concurrent_requests",
    "max_concurrent_requests_pag",
    "max_speed_kbs",
    "max_speed_kbs_pag",
    "max_rps",
    "max_rps_pag",
    "request_priority",
    "request_timeout",
    "request_idle_timeout",
    "request_connect_timeout",
    "default_country_codes",
    "dynamic_settings",
    "proxy_allocation_group_id",
    "sync_hash",
    "default_state",
    "default_city",
    "default_postalcode"
  ]
}
{
  "eoq": {
    "time": 4.07E-7
  }
}

Donc si tu as des IP plus récentes, il devrait être possible de trouver un serveur avec des accès définis.

Bref ce qui en ressort, c'est surtout ce que sont tous des proxies HTTP... C'est donc l'infrastructure, mais ceux qui scrap le site sont de l'autre côté.

acut3 · « **Réponse #4 le:** **Aujourd'hui** à 17:21:37 »

Héhé dans ta liste j'ai trouvé 2 IP (2 seulement, j'ai tout testé) qui ont effectivement des accès définis... Les mots de passes sont hashés (sha1 salés).

Sur chacune de ces 2 IPs, il y a 2970 utilisateurs définis, et ce sont apparement les mêmes utilisateurs (ça doit être la même base sqlite sur deux noeuds Corrosion différents j'imagine). La plupart ont un nom qui est fait de 8 caractères minuscules aléatoires (par exemple "bipxjwyb"), mais d'autres ont ces 8 caractères suivis de "residential" (e.g "ilgogpddresidential").

vivien · « **Réponse #5 le:** **Aujourd'hui** à 17:33:17 »

Citation de: acut3 le Aujourd'hui à 17:01:12

Donc si tu as des IP plus récentes, il devrait être possible de trouver un serveur avec des accès définis.

J'ai d'autres IP, mais pas plus récentes. Je ne suis pas sur que les IP changent.
Si tu regardes dans ces deux fichiers il y a de nombreux /24 ou toutes les IP sont utilisées pour une attaque (ce sont des cases de couleur rouge pour être facilement repérable). Je ne serais pas étonné que tu retrouves des choses en commun avec les IP que tu as analysées, le nom des hébergeurs sont les mêmes.

(cliquez sur les miniatures ci-dessous - les documents sont au format PDF)

Il y a aussi des IP de fournisseur d'accès à internet grand public impliqué en Asie ou en Amérique du Nord, mais avec un taux beaucoup plus faible (5 à 20 IP par /24). Probablement une application compromise ou un ordinateur infecté.

alain_p · « **Réponse #6 le:** **Aujourd'hui** à 18:31:05 »

Citation de: acut3 le Aujourd'hui à 17:01:12

Je n'ai regardé que quelques IP, mais toutes celles que j'ai regardé font tourner un proxy HTTP sur un port qui varie suivant la machine. Elles font aussi toute tourner un serveur Corrosion en libre accès, toujours sur le port 30001. Corrosion est apparemment un système de clustering pour les bases de données sqlite.

Le serveur corrosion a une table "auth" qui semble définir les comptes d'accès au proxy (avec leur nom d'utilisateur et leur mot de passe), mais pour les IP que j'ai regardé, il n'y a pas de lignes (donc pas de comptes définis à priori).

Par exemple :

Code: [Sélectionner]
$ IP=155.254.34.75; curl -gs "http://$IP:30001/v1/queries" -X POST --json '"SELECT * FROM auth"' | jq { "columns": [ "proxy_user_id", "username", "password", "allocation_method", "max_concurrent_requests", "max_concurrent_requests_pag", "max_speed_kbs", "max_speed_kbs_pag", "max_rps", "max_rps_pag", "request_priority", "request_timeout", "request_idle_timeout", "request_connect_timeout", "default_country_codes", "dynamic_settings", "proxy_allocation_group_id", "sync_hash", "default_state", "default_city", "default_postalcode" ] } { "eoq": { "time": 4.07E-7 } }
Donc si tu as des IP plus récentes, il devrait être possible de trouver un serveur avec des accès définis.

Bref ce qui en ressort, c'est surtout ce que sont tous des proxies HTTP... C'est donc l'infrastructure, mais ceux qui scrap le site sont de l'autre côté.

Intéressant, je ne connaissait pas personnellement ce proxy corrosion. Et merci pour la petite ligne de commande, j'ai vérifié sur quelques IP, effectivement, cela retourne ce que tu indiques.

Je suppose que tu as fait une liste des IP du tableau et une boucle sur ces IP pour récupérer les deux IP qui ont des accès définis.

J'ai trouvé ce petit site (d'origine japonaise apparemment ?) qui explique l'intérêt de configurer des crawlers pour utiliser des proxies pour cacher la véritable IP du crawler et éviter de se faire bloquer. Mais si on bloque l'IP du proxy, cela revient au même ? Sauf que le serveur peut probablement changer de proxy...