Advanced Rate limiting Utiliser des seuils de tolérance

Bonjour, Antoine, Solutions Engineer chez CloudCloud. Dans cette vidéo, je voulais parler du rate limiting et la création de seuils de tolérance. Alors, les seuils de tolérance peuvent être utiles lorsque l'on souhaite bloquer un attaquant, mais une fois que l'on a déjà vu plusieurs fois du trafic malicieux venant de sa part. En fait, voilà, on va tolérer quelques attaques, puis ensuite on va le bloquer. L'intérêt, c'est lorsque vous vous retrouvez dans des situations où vous avez trop de faux positifs, l'utilisation de seuils de tolérance peut être vraiment utile. Je vous montre un exemple. Ici, j'ai par exemple un bot ou un attaquant. Je vais le laisser faire des requêtes malicieuses sur mon application, puis, je vais lui en laisser par exemple l'autorisation de faire 10 requêtes malicieuses, puis, une fois qu'on a passé ces 10, là, je vais appliquer un blocage et bloquer toutes ces requêtes, toutes les requêtes suivantes. Alors, peut-être que vous allez me dire, quel est l'intérêt de laisser passer des requêtes qui sont clairement des attaques contre mon application ? L'intérêt et la réalité est que les attaquants ne font pas en fait des requêtes manuelles, ou très très peu. Ça va être surtout des requêtes avec des scripts automatisés, des bots qui vont faire de la reconnaissance, qui vont essayer plein d'injections au global sur votre application. Donc, c'est quelque chose que vous allez voir, vous allez en voir toujours plus d'une. Et on peut utiliser ce genre de comportement pour mettre en place un seuil. Ici, ce système s'appuie sur deux composants. Un, la partie Advanced Rate Limiting de Cloudflare, et deux, le score du WAF. Pour rappel, la façon dont le WAF fonctionne sur Cloudflare, c'est que chaque requête est analysée par deux systèmes indépendants. Toujours. Premièrement, une analyse ici par signature. Donc, Cloudflare va regarder si cette attaque est connue dans une base de données, une liste de signatures. Puis toujours, en parallèle, on va regarder à quoi ressemble la requête, et avec des algorithmes de machine learning, on va être capable de dire, tiens, cette requête ressemble à une injection XSS, SQLI, RCE, et lui donner un score. On lui donne un score global, ce qu'on appelle le WAF Attack Score, puis un score par catégorie, SQLI, RCE, XSS. Donc, dans notre cas, l'idée, c'est de créer du rate limiting en se basant sur ce score du WAF. Je vous montre un exemple avec les résultats d'un script que j'ai créé pour cette démonstration. Ici, je fais des requêtes avec des injections SQL. On va laisser passer les dix premières requêtes, puis, au-delà, du coup, on a passé le seuil, et le reste va être bloqué. Alors, on peut implémenter cette logique de deux façons. La première chose qu'on peut faire, c'est de se dire qu'une fois que l'attaquant a passé le seuil, on peut décider de bloquer toutes les requêtes, ou uniquement les requêtes qui ont dépassé le seuil, est malveillante. Alors, cette approche de laisser passer les requêtes qui ne sont pas malveillantes, même si au-delà du seuil, est une approche plutôt conservatrice, qui est une approche plutôt intéressante, parce qu'il ne faut pas oublier qu'on a beaucoup d'utilisateurs sur Internet qui se retrouvent derrière la même adresse IPv4 du fait du CGNAT. Et ce n'est pas impossible d'avoir dans une entreprise plusieurs dizaines, centaines de salariés qui vont sortir sur Internet avec la même adresse IP. Donc, pour implémenter ce système, tout simplement, une règle de Advanced Rate Limiting qui va ici se concentrer sur le hostname spécifique de mon application et dire, voilà, on va compter toutes les requêtes qui ont un score de WAF inférieur ou égal à 50. On pourrait tout à fait affiner notre règle ici. Puis, on va sélectionner ici le fait de pouvoir appliquer cette règle même pour les assets en cash, pour par exemple protéger votre contenu. Ça protégera... L'idée, ce n'est pas forcément de protéger ici l'origine, mais d'éviter le scrapping de contenu, ça peut être utile de cocher cette case. Puis, voilà, on va sélectionner après combien de requêtes et quel est notre seuil de tolérance. Ici, 10. Une autre approche pourrait être de, une fois que l'attaquant a passé le seuil, de bannir toutes les requêtes. Même les requêtes qui sont propres, qui ne contiennent pas d'attaque, comme même les bloquer, et donc de bannir l'IP pour une période donnée. Vous voyez ici, dans mon graphique, une fois qu'on a passé le seuil, même si c'est une requête qui ne contient pas d'attaque, on la bloque quand même. Et voilà la règle qu'il faut créer pour cela. Tout d'abord, notre règle de rate limiting va se mettre à compter l'ensemble de nos utilisateurs. Donc, on va utiliser une règle, un filtre qui est très large. Ici, tous les utilisateurs qui vont sur mon application, donc avec mon hostname. Mais le point intéressant à la partie rate limiting de Cloudflare, c'est qu'on va pouvoir utiliser une règle pour compter personnalisée. Ici, c'est une, ce qu'on appelle une custom counting expression. Donc, une règle de décompte personnalisée. Et là, on va compter, le compteur va s'incrémenter uniquement pour les requêtes avec un score d'attaque inférieur ou égal à 50. Ce qui fait qu'ici, dans mon exemple, et voilà bien mes premières requêtes qui passent. Ensuite, elles sont bloquées. Puis, les requêtes considérées comme propres ici, clean, continuent de passer. Donc, dans cette deuxième implémentation, ça passe, on bloque, puis les requêtes propres continuent de passer. Ce qu'on voit ici. J'espère que cette vidéo vous a été utile et que vous avez bien compris la puissance du rate limiting de Cloudflare avec notamment ses fonctionnalités de décompte personnalisé. À bientôt.