Comment Voyages-SNCF.com lutte contre les mauvais robots

Injecter un captcha de manière ciblée

Alors, début 2016, les équipes de Voyages-sncf.com ont décidé d’intervenir face à une menace qui avait considérablement gagné en sophistication. Car déjà deux ans plus tôt, du trafic généré par des bots était identifiable. Mais, grossièrement, il suffisait de bloquer l’adresse IP de l’automate en question pour s’en débarrasser. Progressivement, il a toutefois fallu adapter les stratégies de défense : « nous avons ajouté des règles à nos pare-feu applicatifs (WAF) [DenyAll] sur la base de la fréquence, pour présenter un captcha aux adresses IP multipliant les requêtes », explique Emmanuel Cordente. L’utilisation du captcha permettant, en cas de faux positif, à des visiteurs légitimes de poursuivre leur navigation ; un avantage important par rapport à un blocage pur et simple.

Mais cette approche basée sur la vélocité a présenté ses limites : « les robots se sont adaptés. Nous les avons vus arriver avec des dizaines de milliers d’adresses IP différentes, avec seulement deux ou trois requêtes par adresse ». De quoi passer inaperçu… en profitant d’infrastructures Cloud avec des plages d’adresses IP très étendues. Et des services Cloud, « il y en a plein qu’on ne connaît pas forcément, notamment en Chine. On a presque l’impression qu’il y en a un par ville… » D’où la mise en place de mécanismes d’analyse comportementale.

Un pilotage par l’analyse comportementale

Ceux-ci s’appuient sur une pile ELK déjà existante au sein de l’infrastructure de Voyages-SNCF.com : elle servait à l’époque à centraliser la collecte des journaux d’activité (logs) des WAF, des serveurs Web frontaux, des serveurs applicatifs, etc. Les algorithmes d’analyse comportementale ont été développés en interne et interrogent en continu la base Elasticsearch « pour identifier les IP des robots ». Chaque positif déclenche l’injection du captcha par le WAF.

Pour l’analyse comportementale, toutes les informations disponibles sur le trafic Web sont mises à contribution – adresse IP (avec éventuelles données de réputation), navigateur Web déclaré, géolocalisation, résolutions DNS inversées, opérateur titulaire de l’adresse, etc. « L’objectif n’est pas simplement de trouver les robots, mais de trouver les mauvais. Parce qu’il y a aussi de bons robots, comme Google, que l’on n’a pas du tout envie de bloquer… », souligne Emmanuel Cordente.

Et en fait, ne serait-ce que les « tops » sur une dimension d’analyse, comme par exemple les adresses IP générant beaucoup de codes d’erreur, contribuent déjà fortement à l’identification de ces robots parasites. A ce jour, c’est une dizaine d’algorithmes qui interviennent dans le processus de pondération des adresses IP, pour parfois jusqu’à 30 000 captchas affichés par minute.

Des faux positifs très limités

Ce nombre peut varier fortement, notamment selon les robots, avec certains s’arrêtant lorsqu’ils génèrent une erreur côté serveur, pour ne pas trop attirer l’attention, et d’autres qui continuent plus brutalement, même si le captcha est affiché. Mais le chiffre qui intéresse le RSSI, c’est surtout celui de captchas résolus, un indicateur du taux de faux positif… Et là, « aujourd’hui on tourne autour de 200 captchas par jour ». Un chiffre remarquablement bas rapporté au trafic. De quoi permettre à Emmanuel Cordente d’affirmer que « la gêne générée pour les visiteurs est négligeable ».

La mise en place de ces mécanismes a donc eu un effet positif considérable sur la charge affectant les serveurs Web, mais également la centrale de réservation de la SNCF avec laquelle communiquent les applications du voyagiste : « rien qu’avec ces mécanismes, nous avons gagné 10 à 20 % de ressources CPU ».