La guerre des robots : lutte contre les vecteurs d'attaques automatisés

0:11 Bonjour à toutes et à tous. Aujourd'hui, je vais vous parler de bots, ou de robots informatiques en français. Ça ne vous parle peut-être pas, par contre vous êtes peut-être familier avec ce genre d'image. Ça s'appelle une captcha. Et donc la raison pour laquelle on vous montre si souvent ces captchas, la raison pour laquelle on vous demande de cliquer sur les feux tricolores, de localiser les bouches à incendie, c'est parce qu'en fait, quand vous allez sur un site, il y a beaucoup de bots qui attaquent ce site, et l'idée des captchas, c'est de prouver qu'un utilisateur est humain, ou si c'est un robot. Alors les captchas, ça commence à montrer ses limites, j'en parlerai un peu par la suite, mais à la base l'idée c'était de se servir d'un challenge qui était censé être compliqué, donc de la reconnaissance d'image ou de la reconnaissance audio, pour prouver que vous étiez un humain, parce que les bots n'étaient pas censés pouvoir le faire. Et donc on les trouve vraiment partout parce que la plupart des sites, il y a des choses à voler, et donc du coup les attaquants vont faire des bots pour scaler leur attaque.

1:15 Et donc l'idée des capchas c'est de différencier les vrais utilisateurs des faux utilisateurs. Excusez-moi, il y a des feux tricolores, c'est vraiment difficile parce qu'on a le sentiment que... Une fois sur trois, il y a des fois qui sont... De moins en moins, mais je vais vous expliquer. Pourquoi c'est... En fait, les bots, c'est vraiment un problème plus compliqué que ce qu'on pense. Parce que derrière, on a des gens qui essayent continuellement de se cacher. On a un trade-off entre prendre des mesures agressives, mais qui vont nuire à l'expérience utilisateur de vos vrais utilisateurs humains, et améliorer la détection. Et donc toute la difficulté, c'est comment améliorer la sécurité de son site tout en gardant une bonne expérience utilisateur pour les vrais humains. Et avant de vous donner des éléments de réponse, je vais vous montrer un peu l'ampleur du problème et à quel point les bots sont sophistiqués en 2022. Donc la première chose à avoir à l'esprit, c'est que les attaquants vont cibler par défaut, ils vont commencer à taper sur vos API, ils vont commencer, voilà, c'est là où il y a du JSON qui est structuré, c'est pratique, etc.

2:17 Et donc beaucoup d'entreprises vont simplement mettre quelques règles pour break limiting ou un petit peu de règles à base de signature pour sécuriser leur API, mais ce n'est pas suffisant en fait. S'il y a des données qui intéressent les attaquants, ils vont automatiser un navigateur ou automatiser une application pour récupérer la donnée autre part. Donc c'est important de vraiment tout sécuriser avec du JS ou un SDK qui va collecter d'autres signes. Pareil, jusqu'à présent, il y a beaucoup de solutions qui se reposent sur des signatures, bloquer une IP, des choses assez simples. Bloquer une signature, ça ne suffit pas de nos jours. Il y a beaucoup d'outils qui permettent aux attaquants de créer des bots qui ont une empreinte parfaite, qui ont une empreinte qui est similaire à celle de vos utilisateurs, qui aura l'air d'un vrai Chrome. Soit avec des outils open source, soit avec des browsers as a service, des SaaS on va dire, qui permettent d'instancier des navigateurs dans le cloud et qui auront des empreintes, des signatures réalistes. En plus de ça, dans le passé, les attaquants avaient accès à peu d'adresses IP, ils faisaient des attaques depuis peu d'IP, ou depuis une seule IP,

3:25 Ce qui veut dire que chaque IP allait faire un gros volume, par exemple, de tentatives de connexion malicieuse. De nos jours, les attaques sont très distribuées. Donc là, ce qu'on voit sur cette carte, c'est une attaque de Cradle and Chalk Station qui a eu lieu il y a quelques mois et qu'on a bloqué. Du coup, on voit que l'attaquant a distribué son attaque sur des millions d'adresses IP localisées partout sur Terre. Et chaque IP faisait seulement une ou deux tentatives de connexion. Donc, les approches à base de rate limiting, ce n'est plus suffisant contre ce genre de bot. En plus de ça, et c'est pas fini, les bots utilisent des IP qui sont de plus en plus propres. Ce qu'on voit, ça dépend des sites, mais de manière générale, environ un tiers des requêtes de bots passent par des proxys résidentiels. Donc c'est des proxys où l'adresse IP va appartenir à Orange, va appartenir à SFR. Et donc en fait, on ne peut plus simplement se dire que l'adresse IP vient d'un VPN ou d'un fournisseur cloud, donc du coup, je vais être plus agressif. En fait, ils vont utiliser des adresses IP qui sont potentiellement localisées dans le même pays que le site qu'ils essayent de cibler.

4:27 Alors selon le type de proxy, est-ce qu'il est partagé ou pas, ça peut coûter assez cher. Ce que je montre à droite, c'est un site qui s'appelle Exproxy, avec un peu la Rolls Royce des proxys. Ça coûte environ 500 dollars pour avoir 100 proxys pendant deux mois. Donc ça coûte quelque chose, mais selon le type d'attaque, ça peut valoir le coup d'investir pour maximiser ses chances, du moins d'un point de vue de l'attaquant. Les captchas, de nouveau, du coup, comme je vous le disais, c'est plus suffisant vraiment parce que les bots sont capables de passer les captchas. Alors, ça va en stopper certains, mais maintenant, Maintenant, que ce soit avec des techniques de reconnaissance d'images ou des captcha farms, on peut passer des captcha. Il n'y a pas vraiment besoin d'être un expert, parce que des frameworks comme Puppetir et Strastels, par exemple, vont fournir une intégration pour se coupler automatiquement avec une captcha farm. Et en fait, tout ce que je vous ai montré avant, c'est... Avant, il y avait différents outils à droite à gauche, un fournisseur de proxy, un navigateur, etc., un package open source.

5:29 Il fallait savoir un minimum les combiner. De nos jours, il y a eu un vrai changement. Nous, on a appelé ça des bots as a service. L'entreprise qui use vraiment ça, c'est Luminati. Luminati, dans le passé, c'était un fournisseur de proxy résidentiel. Ils se vendaient comme le plus grand fournisseur de proxys résidentiels. Ils se sont renommés en Bright Data et maintenant leur proposition commerciale, ce n'est plus de fournir des proxys, c'est de donner accès à des données même si elles sont protégées. Faire des bots devient aussi simple que de faire un call API. Vous donnez l'URL à laquelle vous souhaitez accéder. Ils vont instancier 10, 15, 20, 30 navigateurs, spouffer les fingerprints, faire de la rotation d'IP, etc., forger de la captcha si nécessaire. Et à la fin, en tant que développeur de bots, vous ne payez que les requêtes qui ont été réussies. Du coup, c'est plutôt pratique pour gérer ses coûts. Pas besoin d'être expert en bot detection ou en contournement de bot detection. Donc ça a vraiment facilité.

6:30 la création de bots beaucoup plus sophistiqués. Mais ça existe aussi sur des outils open source. Alors là, j'ai choisi OpenBullet, mais selon le type d'attaque, on va trouver plein d'outils qui permettent de faire des bots. Donc là, cet outil, c'est OpenBullet 2. Donc c'est un outil open source qui permet, officiellement, de tester la sécurité de votre login. Avec un petit disclaimer bien sûr qu'il ne faut pas s'en servir à des fins non autorisées. Mais dans les faits, le fait qu'il y ait un open bullet 2 montre qu'il y avait un open bullet 1 et qu'il y a une demande. Et donc du coup les développeurs ont développé cet outil pour faire des attaques de credential stuffing. Donc, Cradle and Shostakoff, en fait, c'est des attaques où on va voler, on va tester des combinaisons de username et password qui ont leaké sur d'autres sites. Et on va les tester en masse avec des bots pour voir si, sur un autre site, des personnes réutiliseraient le même mot de passe et voler le compte. Tous les jours. Et donc du coup, pourquoi ça marche?

7:31 Parce que ça peut sembler un peu absurde, mais en fait, la plupart des gens réutilisent leur même email, leur même mot de passe sur différents services. Et donc du coup, malheureusement, les attaquants savent qu'en essayant, statistiquement, ils vont trouver des comptes qui matcheront sur une autre plateforme. Et donc il y a vraiment un vrai écosystème, encore une fois, entre les bots as a service où il faut un peu payer, mais c'est très poussé. Il y a aussi des outils open source gratuits avec une vraie communauté derrière. Et là, cet outil-là, qu'est-ce qu'il intègre? fonctionnalités pour rajouter des proxys bien sûr pour éviter d'être détecté trop facilement des word lists donc ça va être vous pouvez rajouter les combinaisons de username password qui ont leaké dans des fuites de données récentes et plein d'autres options Et même pas besoin de savoir comment forger les bons headers, vraiment c'est très facile. C'est-à-dire que vous allez sur GitHub, alors là j'ai vraiment dézoomé, on est de la lettre C à D, mais ce qu'il faut imaginer c'est que ça va de la lettre A à Z. Et en fait on a des configurations qui permettent de faire des attaques relativement réalistes sur la plupart des sites.

8:33 Donc là j'ai mis par exemple Coinbase, qui est une plateforme de crypto-monnaie. DHL, donc un transporteur, et Disney+, mais de manière générale, tous les services de streaming, par exemple, sont ciblés par ce genre de choses. Et donc si on regarde ce que c'est une configuration, ça va être une sorte de langage de script qui est compatible avec OpenBullet, et du coup les gens vont décrire quel header mettre en place pour être cohérent, là par exemple sur l'appli Disney+, voilà quel header ajouter, vérifier si on a été bloqué ou pas, parser la réponse, etc. Donc après le script continue, mais voilà l'idée c'est de tester avec des headers cohérents et de paralléliser ça sur plein de proxys. Globalement, tout le monde est à risque. Alors là, je vous ai montré du create and show stuffing. Alors dès que vous avez un endroit pour vous connecter ou créer des comptes, globalement, il y a toujours des gens qui s'amuseront à tenter de voler les comptes de vos utilisateurs, soit pour les revendre s'ils ont une valeur, soit pour faire de la fraude avec des comptes utilisateurs qui ont un certain historique, parce que ça permet de contourner potentiellement les systèmes anti-fraude en place.

9:40 Quand il s'agit du credential stuffing, il y a quelques sites encore plus à risque, enfin quelques industries plus à risque que d'autres. Je pense notamment au site de Paris en ligne, tous les sites où il y a de l'argent, on va dire brut, qui peut être utilisé directement. Les sites financiers aussi, les banques, les sites e-commerce et les plateformes de streaming qui sont très populaires. Là, c'est payant. Beaucoup de gens sont prêts à acheter ou à squatter des comptes volés contre quelques euros par mois plutôt que de payer le vrai prix. Mais voilà, il y a d'autres types d'attaques dont on parlera également par la suite, qui touchent différentes industries. Donc par exemple, le scrapping, ça va toucher des sites de petites annonces, des réseaux sociaux, des sites e-commerce, pour différentes raisons, par exemple pour récupérer des informations sur le produit, etc. La manipulation de vote, on peut rencontrer ça sur les sites de streaming, où des maisons de disques peu scrupuleuses pourraient être tentées d'augmenter le nombre de vues, d'augmenter le nombre de likes pour un peu tromper les algorithmes et favoriser leurs artistes. Ou les réseaux sociaux, tout simplement, pareil, pour paraître plus populaires que ce qu'on est.

10:44 Et le scalping, qui consiste à acheter des produits en édition limitée, récemment avec les tickets de concert de Taylor Swift, mais avec plein de biens comme les consoles de jeux vidéo, les GPU, les sneakers, etc. Donc toutes les industries ont certains types de bots, mais globalement, toutes les industries ont au moins un bot qui les cible plus particulièrement. Pourquoi je vous raconte ça ? C'est parce que moi je m'appelle Antoine Vastel, je dirige la recherche chez DataDome et mon métier c'est d'améliorer la protection contre les bots. Donc mon métier, c'est vraiment de, et celui de mon équipe, c'est de rester en avance sur les bottes, parce qu'on a des attaquants qui sont continuellement en train de s'adapter, de mentir sur leur raider, sur leur empreinte, sur leur comportement, sur leur IP. Et nous, notre mission, c'est vraiment de protéger nos clients, donc ils peuvent être des sites e-commerce, des plateformes de Paris, etc., contre différents types de bots, tout en protégeant l'expérience utilisateur.

11:47 Encore une fois, l'idée, ce n'est pas de mettre des captchas à chaque fois et de challenger tout le monde. Et donc, je vais vous expliquer un peu comment on fait ça. La première des choses déjà, si vous êtes un site et que vous souhaitez savoir comment vous protéger, c'est d'identifier un peu les endpoints de valeur, les assets que des attaquants pourraient être tentés de récupérer. Typiquement, si vous avez du login, commencez à monitorer un tout petit peu pour voir si vous n'avez pas des tentatives de credential stuffing. Si vous avez du contenu, voir si une grosse partie des requêtes n'est pas faite par des bots qui essayent de scraper vos pages produits, par exemple. Tout ce qui est paiement, vous pouvez faire la même chose pour vérifier s'il n'y a pas des bots qui sont en train de faire du carding, par exemple pour tester des cartes bleues qui ont été volées, voir si elles sont encore valides en faisant des petites transactions. Et si vous avez des pubs, voir avec votre régie publicitaire, par exemple, si vous n'avez pas trop de trafic fraudule. C'est la première étape. Après, on a plusieurs manières pour se protéger. On a des manières qui vont impacter l'expérience utilisateur, je vous en parlerai après, mais on a aussi des manières qui peuvent être relativement transparentes.

12:53 Qui n'impactent pas l'expérience utilisateur parce qu'elles vont se faire de manière transparente en background. Ça passe par la collecte de signaux qui servent à la détection de bots et à une analyse temps réel. On va collecter des signaux et l'idée c'est de, chaque requête qui est faite par l'utilisateur, de pouvoir analyser si oui ou non ça vient d'un utilisateur légitime ou d'un bot. Quand on parle de bad detection, globalement, il y a à peu près trois familles de signaux. La première, ça va être des signaux qu'on peut considérer comme des signatures. Donc ça peut être des signatures server-side comme les headers HTTP, les TLS fingerprint, mais aussi des signatures client-side comme les empreintes de navigateur. Après, on a tous les signaux comportementaux. Donc souvent, quand on parle de comportement, les gens s'imaginent les mouvements de souris et la manière dont on clique sur l'écran. Donc ça, c'est vrai. On peut s'en servir pour faire de la détection. Mais il y a aussi le pattern des requêtes HTTP qui sont faites. La stérie temporelle, est-ce qu'elle est cohérente? Le graphe de navigation, est-ce qu'il est cohérent avec ce qu'un humain ferait? Et après, on peut calculer différents types de réputations sur l'IP, sur la session, sur l'utilisateur.

13:58 Et sur l'IP, on peut par exemple détecter s'il s'agit d'un proxy, le type d'IP, data center, résidentiel. Donc si on zoome sur quelques signaux pour vous expliquer un peu comment on peut s'en servir, les headers HTTP, typiquement on peut regarder l'ordre des headers, l'absence ou la présence de certains headers, et de manière générale la cohérence entre tous les signaux HTTP et l'identité que la personne prétend avoir dans son user agent. Quelqu'un qui prétendrait par exemple être Chrome et qui n'a pas d'accept language, on peut bloquer parce que ce n'est pas quelque chose de normal. Pareil sur les TLS Fingerprint, mais c'est un autre niveau. On va regarder les métadonnées qui sont échangées pendant l'établissement de la connexion HTTPS. On va regarder par exemple si les algorithmes de chiffrement supportés sont cohérents par exemple avec un Chrome ou si finalement ils sont peut-être liés à une librairie Python. Dans ce cas-là, ce n'est peut-être pas cohérent et on va interdire l'accès au site. Au niveau client-side, on va pouvoir collecter des informations sur le device, l'opérating system, etc.

15:00 comme le GPU, la liste des plugins. Mais ce qui est vraiment important et puissant au niveau Client-Site, c'est qu'on peut exécuter des challenges JavaScript qui permettent en une simple exécution de détecter des frameworks comme Puppeteer ou Puppeteer ExtraStells ou des navigateurs headless comme Headless Chrome. Et en une simple exécution, on peut dire que cet utilisateur n'est pas Chrome, c'est un Chrome instrumenté avec Puppeteer par exemple, de manière précise. Et on va aussi se servir du Client-Site pour collecter, comme je disais tout à l'heure, les mouvements de souris, les interactions avec l'écran tactile, etc. Donc tout ça, après, on va les ingérer et les processer en temps réel. Donc dès qu'on va recevoir une requête, on va l'enrichir avec des métadonnées, par exemple est-ce que l'IP est un proxy, est-ce qu'elle a récemment fait des attaques chez d'autres clients, sa localisation, etc. Et après, en parallèle, en moins de 2 millisecondes, on va exécuter un ensemble de techniques de détection pour s'assurer si oui ou non la requête doit être bloquée.

16:04 On va d'abord vérifier si la requête vient d'un verified bot ou d'un good bot style Google bot, qui est bénéfique au site parce qu'il va permettre d'indexer son contenu, ou s'il match des règles qui ont été définies par nos clients. On va également vérifier si la requête match des signatures déjà connues de bots. Alors ça permet de détecter les bots déjà connus les plus simples, mais c'est très efficace. Et enfin, on va aussi exécuter différents modèles de machine learning qui prennent en compte des empreintes de navigateurs, le contexte, l'âge de la session, le comportement. Donc en moins de 2 millisecondes, on va fournir une réponse, si oui ou non, la requête doit être bloquée ou autorisée. Et donc tout ça c'est de manière transparente, et ça marche plutôt. Alors c'est quelques screenshots Twitter ou de GitHub de certaines librairies. Voilà, donc c'est des gens qui font des sneakerbots ou des librairies, ça c'est Undetected Cram Driver je crois. Voilà, donc de manière en fait transparente, sans challenger les utilisateurs, en collectant des signaux dans le background, on peut améliorer plus qu'avec une capture, en fait, la sécurité d'un site contre les bots.

17:11 Après, tout ne se règle pas comme ça. De manière générale, on peut quand même améliorer la sécurité, malheureusement aussi en impactant l'expérience utilisateur, mais parfois ça vaut le coup. Par exemple, inciter ses utilisateurs à activer l'authentification multifacteur, ça peut être très bénéfique, tout de suite ça rend beaucoup plus complexe les attaques de credential stuffing. Pareil, vérifier si les credentials, donc le mot de passe ou les usernames, ne sont pas déjà fuités et demander à l'utilisateur de les changer. Il y a des services comme Avail Bimpong, vous pouvez vérifier si le mot de passe n'a pas fuité. Forcer des utilisateurs à se connecter, par exemple si vous avez des problèmes avec des scrappers. Après, ça peut déplacer le problème potentiellement, parce qu'ils vont se mettre à créer des faux comptes. Mais ça peut être des choses auxquelles on peut réfléchir. Ou forcer l'utilisation d'un numéro de téléphone pour créer un compte. Tout ça, bien sûr, ça impacte l'expérience utilisateur, ça rajoute de la friction. Donc ça va complètement à l'encontre de ce que nous disait la dame de chez Back Market ce matin. C'est plein de choses. un peu chiante, mais dans certains cas, ça a du sens.

18:15 Si vous êtes une institution financière, si vous êtes une plateforme de Paris en ligne, on peut essayer d'inciter les utilisateurs, peut-être pas au moment où ils créent le compte, mais on va dire de les inciter après à activer l'authentification multifactor. Par exemple, je ne sais pas, en leur donnant un petit crédit de Paris en plus, ou je ne sais pas, dans certains jeux vidéo, en leur donnant des récompenses virtuelles qui ne coûtent pas forcément grand-chose, mais qui vont permettre de sécuriser les comptes et de faire ça de manière plus facile. L'idée, c'est d'essayer de gamifier pour faciliter la transition. Alors ça rajoute quand même de la friction, mais dans certaines industries, ça vaut quand même le coup de rajouter ces choses-là. Parce qu'en cas de compromission de compte, les enjeux peuvent être quand même assez gros. Voilà, donc tout ce que je vous ai dit pour l'instant, c'est un peu théorique, même si certains outils viennent du monde réel. Je vais vous montrer OpenBullet ou certaines plateformes de bot as a service. Là, je vais vous montrer une attaque de credential stuffing. Je continue dans la même lignée.

19:17 Où un attaquant a essayé de voler des comptes. C'est un site qu'on protège, une plateforme de gaming. L'attaque a duré 4 jours, donc on l'a détecté et bloqué. Mais au total, il y a eu plus de 107 millions de tentatives de connexion malicieuses, venant de plus de 91 millions d'adresses IP. Ça veut dire qu'en moyenne, chaque IP faisait à peu près 1,18 tentative de login. C'est très précis, mais voilà. Donc autant dire que toute tentative de rate limiting n'aurait pas réellement aidé. Et donc on l'a détecté. Alors je résume parce qu'il y a plein de signaux, il y a plein de modèles, mais les facteurs qui ont le plus contribué, ça a été la détection d'outliers, d'anonymes. On monitore continuellement les endpoints, style login, et on a détecté notamment qu'il y avait une variation dans le nombre distinct d'autonomes systèmes, le nombre distinct de sessions qui se connectaient, et ça a déclenché des modèles qui ont après généré des patterns de blocage. Donc la deuxième partie.

20:18 Et après, un de mes sujets de prédilection qui est la détection de proxy résidentiel, mais en fait c'est quelque chose de clé pour scaler une attaque, un bot a besoin de beaucoup d'IP. Alors du coup, investir dans la détection de proxy résidentiel, c'est un facteur clé. Alors toutes les requêtes qui passent par un proxy ne sont pas malicieuses, mais savoir qu'une requête est passée par une IP qui a récemment été utilisée comme un proxy, ça permet quand même de prendre une meilleure décision. Donc si on regarde la courbe de l'attaque, on voit en vert le trafic humain et en bleu le trafic bot. Donc on voit des pics à plusieurs millions de tentatives de connexion par heure. Et là, c'est la même courbe, mais c'est le nombre distinct d'adresses IP dans le temps. En fait, il n'y a pas de grande différence globalement, à part au début où l'attaquant a dû bourriner depuis une seule IP. Mais après, il a continué depuis plein d'IP pour tester son attaque. Et donc si on regarde le type d'adresse IP utilisée, donc là c'est les autonomes systèmes, on peut voir ça un peu comme les fournisseurs d'accès qui appartiennent à l'adresse IP.

21:27 Le premier n'est pas très très connu, donc ce n'est pas forcément de la très bonne qualité d'un point de vue attaque, mais après on voit quand même des IP ChinaNet, pour cibler un site qui opérait notamment en Asie, en Asie et aux US, ce n'est pas un critère discriminant d'un point de vue du site. AT&T, Comcast, Korea Telecom et Unet qui est Verizon. Donc globalement, l'attaquant est passé quand même par des proxys plutôt propres qui appartiennent pour la plupart à des fournisseurs dans lesquels on aurait confiance. Voilà donc pour conclure, du coup les bots sont vraiment de plus en plus sophistiqués. De nos jours c'est très facile pour un attaquant de forger ses fingerprints, ses signatures, de distribuer ses attaques en utilisant en plus des IP résidentielles qui ont l'air plus propres que des IP data center. Et la plupart des bots peuvent forger des captchas de manière assez simple. Pour vous donner un ordre de grandeur, forger 1000 recaptchas ça coûte environ 3 dollars.

22:30 Donc c'est pas particulièrement un critère discriminant. Sur les attaques de credential stuffing, l'idée de l'attaquant c'est vraiment de tester des combinaisons de username et de mot de passe qui ont fuité sur des fuites de données d'autres sites et de les tester sur votre site pour potentiellement compromettre des utilisateurs qui réutiliseraient leur mot de passe. Et donc pour lutter contre ce type d'attaque en particulier, on peut à la fois utiliser des mesures qui vont impacter l'expérience utilisateur, comme l'authentification multifacteur, vérifier que les mots de passe ont déjà fuité via des services comme Avail Bean Porn. Donc ça on peut essayer de gamifier un peu l'opération pour que les utilisateurs installent ça plus facilement. Là après on peut aussi utiliser des techniques de bot detection beaucoup plus transparentes qui vont utiliser la collecte de signaux, différents types de fingerprints, différents signaux comportementaux, différents... Réputation pour en fait classifier en temps réel et dans le background si en fait la requête provient d'un administrateur légitime ou pas.

23:35 Je vous remercie de votre attention. Je ne sais pas si vous avez des questions. Est-ce que vous savez aussi si vous détectez des faux positifs? Oui. Oui, il faut être... Le taux... Oui, le taux. Alors, le taux dans l'industrie, on vise le 1 pour 10 000. Et nous, on est très transparent. C'est-à-dire qu'on a pas mal de concurrents où c'est compliqué de savoir qu'il y a eu un faux positif. Nous, dans notre dashboard, on peut faire des exports, on peut visualiser le nombre de captchas passés. Voilà, et c'est quelque chose de transparent, il n'y a pas besoin de se battre pour avoir ce genre de métrique. Récemment, du coup, je voulais prendre des billets pour Roland-Garros. Et c'est toujours assez compliqué. Et justement, il y a eu plein de... Quand je faisais des recherches sur Internet, il y a eu plein de services, Rocket Ticket, je ne sais plus du nom exactement, qui proposaient justement de payer à l'avance, donc de payer plus, ou alors de payer à la réussite.

24:38 Et là, c'était des systèmes de bots, effectivement, qui allaient récupérer des tickets sur le site de Roland-Garros. Et je me demande si ces systèmes, en fait, c'est légal, du coup, de faire ça? Bonne question. Alors le scalping, ça a été... Enfin, il y a de la législation qui est passée dans pas mal de pays. Après, la loi, même si elle existe, il faut pouvoir la faire appliquer. Et globalement... Si on prend le cas de Roland Garance, je me mets à leur place. Ils font une mise en vente par an, leurs tickets partent. Après, attaquer des gens en justice, c'est rarement très bon pour l'image. Et puis il faut identifier les gens qui sont derrière, ils ne sont pas forcément localisés en Europe. Donc il y a des lois qui existent dans différents pays, mais après, les exercices, c'est toujours compliqué. Et du coup, ce serait à Roland Garros de faire appel, par exemple, à Datadome pour éviter d'avoir des... Il s'avère que Roland Garros est client de Datadome. D'accord. Après, je ne peux pas... Après, voilà. Après, je ne vais pas commenter exactement leur situation parce que dans leur cas... J'ai trouvé mes billets. Voilà. Ça veut dire que ça va bien marcher. Mais Roland Garros, c'est comme un cas très particulier.

25:39 C'est-à-dire qu'ils ont 5 ou 6 vagues de ventes avec licenciés, pas licenciés, club, pas club, etc. Il y a plein de... C'est beaucoup plus compliqué, on va dire, qu'une vente style Ticketmaster qui est ouverte à tout le monde. Parce qu'il y a d'autres types de problématiques. Mais bon, comme c'est des clients, du coup, on ne va pas commenter plus que ça. Oui. Bon, on va commencer. Moi, j'avais une question au niveau du machine learning que vous utilisez pour la détection. Qu'est-ce que vous utilisez comme données pour entraîner le modèle? Et où est-ce que vous les trouvez? Alors... On utilise différents types de modèles et différentes données. La manière dont on fonctionne, en gros, on n'essaye pas d'avoir un modèle qui essaye de tout résoudre et qui générerait le score parfait. On a des modèles qui, chacun, vont essayer de travailler sur un ensemble de données. du sens quand elles sont traitées ensemble. Par exemple, dans notre API server, qui fait la prédiction en moins de 10 secondes, on utilise par exemple de la classification supervisée avec 4Boost, on va utiliser des signaux liés au fingerprint, liés au contexte, donc le pays, l'IP,

26:47 la réputation, est-ce que c'est un proxy, Et ça va nous retourner un score qu'on pourra utiliser après dans la suite du pipeline de détection. On a des modèles qui sont eux par exemple plus sur le comportement et là on va plutôt être sur du non supervisé. Ça s'y prête mieux et on va se servir de différents mécanismes pour ajuster l'agressivité du modèle. Donc là sur le comportement après, Alors le comportement, on a le comportement avec les mouvements de souris, etc. Mais on a aussi du comportement avec le pattern de navigation sur le site. Et ça, c'est deux modèles distincts. L'idée, ce n'est pas de fusionner des données qui n'ont aucun sens ensemble. Et après, on a plein d'autres modèles qui n'interviennent soit pas en temps réel ou qui n'ont pas vocation à bloquer directement. On a des modèles qui vont être là pour enrichir de la donnée. Typiquement, est-ce qu'une IP est utilisée comme un proxy résidentiel? On n'a pas forcément besoin de le faire tout le temps en temps réel. On peut l'abêler après coup pour ajuster des réputations, etc. C'est très utile. Et après, il y a un autre élément, c'est qu'on peut travailler à différentes granularités.

27:52 Donc parfois, on peut travailler à la session, à la requête, à l'IP, ou au niveau du site, en fait, pour détecter des phénomènes à différents niveaux. Parce que parfois, on regarde... Gardant chaque requête, si la personne forge tout correctement, on ne va pas forcément voir grand-chose. Par contre, quand on prend du recul et qu'on monitore le nombre d'AS distincts, de pays, de sessions qui font des tentatives de connexion, on peut se rendre compte que même si les signatures ont l'air à peu près correctes, il y a quelque chose d'anormal qui est en train de se passer et déclencher un autre modèle qui, lui, va essayer de trouver ce qui est anormal. Parce que ce serait trop coûteux de le faire tout le temps, donc en fait on va le faire que dans des moments où on a détecté une anomalie. Après les signaux, on les collecte client-side avec du JavaScript, ou dans les applications mobiles avec notre SDK. Et sinon c'est nos modules server-side qui peuvent tourner dans des load balancers, dans des CDN, qui vont collecter les données liées à la requête. Et vous utilisez les données... Pardon, j'en ai pas. Au fur et à mesure que vous collectez des données, vous les réutilisez pour entraîner les modèles?

28:55 Oui, oui, alors on réentraîne certains modèles plus ou moins souvent. Donc il y a des modèles qui sont réentraînés automatiquement. Il y en a d'autres, c'est en mode online learning, donc du coup il n'y a pas vraiment de notion d'entraînement. Mais oui, du coup, mais ça c'est vrai pour les modèles et c'est vrai pour les humains qui interviennent aussi en fait. L'humain, là on parle beaucoup de l'ML, mais il y a quand même beaucoup d'humains qui mettent aussi leur connaissance à profit pour corriger les modèles. Du coup, c'était plutôt en termes de mise en place. Qu'est-ce qu'on fait? Est-ce que c'est des agents? En tout cas, c'est un site web. Qu'est-ce qui se passe si j'ai un CDN ou un site en statique? Alors, s'il y a un CDN, c'est très simple. Généralement, on a une intégration qui va dans la plupart des CDN. Donc du coup, par exemple, je ne sais pas si on prend Cloudflare, sur la marketplace, c'est un clic. Et avec un free trial où il n'y a pas besoin de carte bleue, rien, on va analyser le trafic, mais pas bloquer. On va vous exposer en fait ce qui se passe sur votre site. Après, si c'est un load balancer style Hachaproxy, on a des modules pour Hachaproxy, pareil pour Nginx.

29:57 L'idée, c'est vraiment que ce soit super facile d'intégrer notre solution. Avec compte, par exemple, comme... On supporte le compte. Justement, sur la protection au niveau de la WES Blockfront, ils ont déjà un niveau de protection zéro, j'imagine, au niveau des bots. Quel niveau, jusqu'où ils vont par rapport à vous? Qu'est-ce que vous apportez par rapport à eux? Il y a encore des nouveautés, ils innovent sur le sujet. Donc après, je dirais, la bot detection, c'est quand même un état d'esprit assez particulier. Ça veut dire qu'en gros, on a en face de nous des gens qui sont continuellement en train d'essayer de contourner ce qu'on met en place. C'est-à-dire qu'en gros, ce n'est pas un produit, on installe, c'est fini. Je pourrais vous le dire, vous installez la DataDome, c'est fini, il ne se passera plus jamais rien, plus aucune attaque. En face, il y a des gens qui vont s'adapter pour essayer de contourner, parce qu'il y en a qui ont des entreprises dont leur business dépend de récupérer des données pour les monétiser. Et donc du coup, ça nécessite quand même des interactions pour mettre à jour les modèles, gérer les faux positifs, les faux négatifs, prendre en compte le contexte du client.

31:04 Et donc tout ça, c'est compliqué avec une solution complètement autonome. On peut bloquer beaucoup de bots, mais les bots les plus sophistiqués, ça nécessite aussi d'avoir des gens avec qui discuter. On le voit, la plupart des CDN ont des fonctionnalités de sécurité. Vous allez sur GitHub et vous verrez, il y a des librairies, je ne vais pas nommer, mais il y a des librairies qui permettent de contourner, parce que ça a vocation à stopper 80% des bots les plus simples. J'ai une question sur, très d'accord, comment c'est scale, dans un cas particulier sur les DDoS applicatifs, ce genre de l'ER7. Et d'ailleurs, merci beaucoup pour la présentation, c'était super. Je me suis rappelé de cette slide-là, et cette slide avec la timeline, quand c'est réduit, quand tu as des pics, je ne sais plus, c'est quoi les buzzwords à la mode, c'est slow DDoS, app DDoS, ou autre, tu sais, quand tu te manges un pic pendant 5 minutes, Est-ce que ton ML a le temps d'analyser, de comprendre et de traiter?

32:10 Oui. Et reprenons un cas complètement de la vie réelle avec les affaires proxys qui se calent pas et ta prod qui s'écroule pendant une seconde. En fait, nous, notre mission, on est là pour faire le punching ball entre les attaquants et les sites. Y compris le Montcoin d'ailleurs. On est client? Oui. Ah d'accord, je pensais que tu étais au courant. D'accord. Et du coup, en fait, en gros, on a développé nos propres autoscalers pour scaler plus rapidement que ce qui est proposé sur les plateformes cloud par défaut. Mais en fait, le pire, pour être honnête, ce n'est pas les attaques des DOS, c'est les ventes de chaussures. C'est les ventes de sneakers Nike Jordan édition limitée. C'est des attaques très distribuées avec des pics de plusieurs dizaines de millions de requêtes par minute, voire parfois sur quelques secondes en fait, où il y a une paire qui est mise en vente. Et donc en fait c'est une problématique qu'on rencontre souvent. Je ne vais pas dire que c'est facile, on a une équipe entière qui bosse sur la scalabilité. Mais notre idée, le but c'est quand même de proposer une solution qui est là pour absorber justement ce pic de trafic et le bloquer pour que ça n'atteigne pas l'infra de nos clients.

33:19 Sur comment c'est fait, les secrets techniques. Du coup, il y a des vrais humains qui arrivent à en avoir des mics? Ah oui, il y a des vrais humains, oui! Oui, il y a des vrais humains qui arrivent à en avoir, après c'est... C'est comme les places du FES, ils m'en parlent, mais moi je vous dis que c'est des grands qui les achètent. Sur... Ouais, bah... Il y a des humains qui arrivent à en avoir. Après, c'est vrai que c'est des volumes de requêtes énormes. À partir de quelle volumétrie ça commence à bloquer? Pour être plus simple, c'est un cas où on a par exemple des tests automatisés avec du... Du burn data test, du burn data stack, on va pas être ralenti. Ah ça va vous bloquer direct, c'est l'objectif? Après en fait, oui, l'idée nous c'est on détecte un bot, et après c'est à notre client de dire, ça c'est notre bot à nous, donc du coup on va l'autoriser. Mais par défaut, notre mission, nous, c'est on voit un bot, et si le client a mal configuré, alors on va le bloquer. C'est plutôt bon signe. Mais voilà. Mais l'idée, généralement, il faut l'autoriser.

34:22 Et en fait, ce qui se passe pendant la phase d'onboarding, tout à l'heure, je disais qu'il y avait le free trial. En fait, on ne fait que de la détection et pas de la protection. L'idée, c'est justement de pouvoir autoriser tous ses partenaires. Donc nous, on a une base de données, je ne sais pas, New Relic, Datadog, etc. Pour automatiquement dire, regardez là c'est du Datadog, vous pouvez l'autoriser simplement. Après si vous avez vos propres bots qui tournent sur vos propres VM, ce sera à vous de whitelisté peut-être vos ranges d'IP. J'ai une question par rapport à ce qu'on a dit tout à l'heure sur les adresses résidentielles. Comment on peut en avoir un? Alors, plusieurs points. Des Legos, mais pas très moraux, des illégaux. Légalement, pour monétiser les applications mobiles, il y a la pub. Et pour monétiser encore plus, il y a la pub et transformer ses utilisateurs en botnet. Donc des boîtes comme Bright Data vont proposer des SDK. Ce ne sont pas les seules, mais c'est les plus connues. Ils proposent un SDK, ils contactent les développeurs et leur disent, à la place de mettre de la pub, même si souvent c'est plutôt en plus de la pub, vous pouvez mettre notre SDK et monétiser.

35:29 Alors c'est légal parce qu'ils le font quand même avec le consentement des gens. C'est-à-dire qu'il y a des chercheurs qui ont vérifié les applis qui utilisent leur SDK, il y a un pop-up qui demande l'autorisation. Après on sait tous, les gens ne lisent pas forcément beaucoup les conditions d'utilisation. Ça c'est la partie légale. Essentiellement les applis, mais souvent ils ont des SDK pour logiciels sur PC, pour extensions de navigateurs. Après il y a la partie moins légale. Il y a les PC infectés, comment on les monétise? On va les transformer en proxy et comme ça après les gens peuvent s'en servir pour faire des attaques. Alors après, ce n'est pas une liste statique. Ce qu'il faut garder à l'esprit, c'est qu'en fait... À un moment donné, c'est le moyen de remonter comme étant une application potentielle. Oui. Oui. Il y a beaucoup d'IP résidentielles. On a même un collègue, par exemple, pour l'anecdote, qui, en testant justement le modèle de machine learning qui fait de la classification, il a testé sur son IP pour voir si ça ne faisait pas de faux positifs, et l'IP classifiée comme proxy résidentielle, bon, il va falloir mettre à jour le modèle parce qu'il ne marche pas, et non, en fait, un de ses colocataires à l'époque était probablement infecté.

36:44 Quel est votre site de délivrerie en général? Sur la logique de détection? Non, mais oui, même en général, déjà la release, les releases que vous avez. Alors au niveau du code, c'est surtout nos modules qui collectent la donnée. Donc on fait des mises à jour pour rajouter des nouveaux signaux ou des nouvelles fonctionnalités peut-être sur certains frameworks. Donc ça je dirais que c'est plutôt opportuniste s'il y a une raison d'upgrader les modules, parce que ce n'est pas non plus des composants très complexes, la plupart sont open source. Mais je dirais que toute la logique de détection est sur nos serveurs. Et donc en fait tout ça on peut, on déploie continuellement plusieurs fois par jour. Des modèles, des nouvelles règles, des nouveaux signaux aussi. Alors les signaux aussi, ils ne sont pas tous dans le... Dans les modules server-side, certains sont dans notre agent JavaScript, et ça c'est très simple en fait parce que les sites vont inclure un script qui charge un script, et donc du coup ils n'ont pas besoin de remettre à jour constamment notre script, ça se fait automatiquement.

37:59 Merci pour vos questions.