Le Cloudflare WAF démo et démarrage rapide

Bonjour, ici Antoine, solution engineer chez Cloudflare. Je vous parlais ici du web application firewall, quelques concepts et comment le mettre en place. Donc le WAF, c'est la ceinture de sécurité des applications web. Ça ne vous empêche pas d'avoir du code vulnérable dans vos applications, mais en cas de tentative d'attaque, le WAF va aller bloquer les requêtes malveillantes avant qu'elles arrivent sur votre origine, sur votre serveur. Donc la qualité d'un WAF se joue surtout sur la qualité de sa détection. Donc à quel point il est capable de bloquer les requêtes malicieuses sans faire de faux positifs. C'est vraiment ça l'enjeu, c'est la détection. Donc la question maintenant que vous avez sûrement en tête, c'est comment le WAF de Cloudflare génère sa détection. Alors pour vous expliquer comment fonctionne en fait la détection, j'ai besoin de vous expliquer rapidement comment une requête est analysée par le Cloudflare WAF. Qu'est-ce que fait Cloudflare quand on a une requête qui arrive ? Donc lorsqu'on a une requête, on l'analyse avec deux systèmes. Premier système de défense, il va détecter les attaques par signature. C'est ce qu'on va retrouver ici. Donc en fait, on gère, notre équipe de sécurité et nos experts en sécurité gèrent pour vous une liste de règles qui est mise à jour de manière extrêmement régulière contre des attaques connues, des nouvelles attaques. Je prends par exemple l'exemple de l'attaque React to Shell qui est bloqué par le rule set, bloqué par sa signature. C'est-à-dire que Cloudflare connaît cette attaque, reconnaît cette attaque et va aller directement la bloquer. Maintenant, on a aussi un deuxième système qui est utilisé pour la même requête. Donc les deux systèmes fonctionnent en parallèle et c'est un système qui va mettre un score sur la requête avec des algorithmes basés sur du machine learning. C'est-à-dire que Cloudflare a vu tellement d'attaques SQL, XSS, Traverse Hall, etc., qu'on a créé un moteur qui est capable, même sur une requête, sur une signature qui n'est pas connue, de savoir s'il y a une attaque dans cette requête. Donc ce qu'on va faire, c'est que lors de l'analyse de la requête, on va lui donner un score d'attaque entre 0 et 100. Plus on est proche de 100, moins il y a une attaque dedans. Plus on est proche de 0, plus ça va être un score d'attaque élevé. Donc on est quasiment sûr que c'est une attaque. Donc pourquoi avoir ces deux systèmes en parallèle ? Parce qu'on souhaite protéger votre application, même pour les attaques qui ne sont pas connues de manière préalable, donc par signature. Ce qui fait que grâce à ce système, on est capable en fait à les bloquer des zéro-day avant qu'on les intègre dans notre détection de signature. Alors je vous donne un exemple ici d'une attaque contre Apache, le serveur web. Et en fait, on a été capable de la détecter avant qu'elle soit publiquement partagée. Je vais vous montrer rapidement comment on met en place le WAF et comment ça fonctionne. Alors dans le dashboard, on va aller dans Security, Overview et ce qu'on va pouvoir faire, c'est cliquer ici sur le nombre total des requêtes. Ici tout à droite, je peux aller changer la temporalité. Je vais mettre sur les 30 derniers jours. Donc on voit mon trafic sur les 30 derniers jours et je peux uniquement me concentrer sur le trafic que Cloudflare a filtré pour moi. Et si je veux en savoir plus, le mieux c'est d'aller dans événements de sécurité. Là, je vais remettre la temporalité de 30 jours. Et là, on va retrouver à peu près le même chiffre. Pourquoi je dis à peu près ? Parce qu'il y a du sampling qui est effectué. Et là, je peux voir rapidement les actions que Cloudflare a pris contre des événements de sécurité. Donc, on a envoyé environ 21 000 challenges. On a bloqué plus de 13 000 requêtes. On a laissé Cloudflare gérer des challenges JavaScript environ 5000 fois et on a 50 logs. Donc détection, on n'a pas pris d'action, on a juste logé l'action. Alors, on va regarder par exemple sur quoi Cloudflare a bloqué. Et on va aller, par exemple, analyser ce pic. Alors, je peux facilement aller filtrer quelle adresse IP m'a attaqué pour regarder les adresses IP principales. Regardez les hosts qui ont été principalement attaqués. Donc, on va par exemple ici cliquer sur filtre. Donc là, le filtre est ajouté. Et on voit là qu'on a eu une reconnaissance. Donc, un bot qui a essayé de trouver des chemins. Je peux voir plus de chemins ici. Ok, on voit qu'il a essayé pas mal de choses. Je peux regarder d'où il est venu. On voit que ça, c'est une adresse IP qui vient de Google, Google Cloud. Donc, c'était une machine dans le cloud. Et puis, je peux aller regarder aussi un sample de logs où je vais avoir des informations sur le chemin qui a été utilisé, la méthode, l'user adjoint, etc. Ici, sur cette partie haute, je vais voir ce qui a déclenché la détection. Donc, on voit ici que c'est le Cloudflare Manage Ruleset avec cette règle en particulière. Donc là, on est sur une détection basée sur les signatures. Je vous ai parlé de la détection basée sur les scores. Donc, ici, on voit plus on est proche de 100, moins il y a une attaque dans cette requête. Et là, vous allez peut-être me dire, mais c'est effectivement un bot qui cherchait à faire de la reconnaissance. pourquoi c'est détecté comme assez clean, donc sans qu'il n'y a pas de signaux d'attaque dans cette requête. On est à 89, 89 sur 100. C'est parce qu'on est simplement sur un get de cette URL. Donc, il n'y a pas de payload malicieux dans ce get. Il n'y a pas de tentative d'injection. Donc, c'est pour ça qu'on n'a pas d'XSS à l'intérieur, pas d'injection SQL ou pas de tentative d'exécution de code. Alors, comment on peut mettre ça en place ? Alors, je vais aller dans Settings. Je vais cliquer sur Web Application Exploits. Et là, je vais m'assurer d'avoir le Cloudflare Manage Ruleset coché. Une fois que j'ai ça coché, si je vais dans Security Rules, là, je peux voir les règles managées que Cloudflare exécute. Donc, on a deux types de listes de règles managées. La Cloudflare Manage Ruleset et le Cloudflare OAuth Core Ruleset. Moi, ce que je vais vous recommander, c'est d'utiliser le Cloudflare Manage Ruleset. La bonne pratique, c'est de ne pas utiliser les deux en même temps. Maintenant, on va voir comment on va pouvoir créer des règles dans le WAF pour se protéger. Et quand je parle de règles, c'est de règles custom qui vont s'adapter spécifiquement à notre trafic. Alors, si je regarde un petit peu de manière globale mon Analytics, j'ai quelque chose qui remonte, qui est intéressant. C'est ici. J'ai beaucoup d'accès, de tentatives d'accès, donc majoritairement à ma page de login. Donc, si je l'entre ici, voilà. Et là, on voit que c'est du trafic qui est majoritairement automatisé. On ne va pas retrouver ici en France du SFR, du Orange, etc. C'est majoritairement du trafic qui vient de Data Center. Alors, ici, on voit que j'ai déjà appliqué une règle pour me protéger. On va voir un petit peu comment j'ai construit cette règle. Alors, premièrement, déjà, ce qu'il faut faire, c'est regarder à quoi ressemble notre trafic. Donc ici, si on regarde les types d'attaques, enfin le score d'attaques, on n'a pas d'injection. Puisque c'est quelqu'un qui va essayer en fait de tenter des logins. Donc, il y a juste login mot de passe. Alors là, j'ai juste un get pour celui-ci. Mais ce qui est intéressant, c'est de se concentrer sur les posts. Je vais, hop, sur post, je vais faire filtrer pour regarder ce qu'il se passe. Et là, donc, je vois un post. Donc, c'est plutôt clean aussi. Donc, on n'a pas d'injection dans cette requête. Mais voilà, c'est quelqu'un qui va tenter de se loguer. Par contre, ce qui est intéressant, c'est de voir le bot score. Et on voit que c'est du trafic qui est automatisé. Et une façon simple de se débarrasser de ce trafic automatisé, c'est de créer une règle qui dit, lorsque je détecte du trafic automatisé sur cette URL wp-login, alors je vais lui envoyer un challenge JavaScript. Alors voilà à quoi ressemble, par exemple, un challenge JavaScript. Il y a une vérification JavaScript, ici, que les bots ne vont pas réussir à faire parce qu'ils n'exécutent pas le JavaScript. Ici, j'ai réussi à passer puisque j'exécute la page dans un navigateur et je ne suis pas un roux. Donc, l'idée, ça va être de mettre ça en place sur notre page login. Donc, si on crée une règle, on va aller dans security rule custom rule. Je vais recréer une règle custom. Et ce qu'on va vouloir faire, c'est déjà de cibler ma page. Donc, quand la page contient mieux wp-login.php et pour des raisons d'expérience utilisateurs, imaginons que ce soit un vrai site avec beaucoup d'utilisateurs, parce que c'est en principe d'e-commerce, il n'y a pas envie de challenger tout le monde. Donc, on va ajouter un filtre lié sur l'automatisation. Donc, on va dire qu'on va le faire ça uniquement sur des bots qui ont un score inférieur à 29. Donc, le bot score, comme la partie attaque score, plus on est proche de zéro, plus on va être un bot, on est sûr que ce soit un bot, plus on est proche de 100, plus on est un humain. Et ce que je vais faire ici pour l'action, je vais dire manage challenge, c'est-à-dire que je vais laisser Cloudflare, en fonction de la situation, choisir le type de challenge JavaScript à déclencher. Une fois fait, vous allez avoir sur deux règles. Alors, moi, j'avais déjà cette règle en place. Et ce que vous allez avoir ici, c'est le nombre de fois où cette règle a été déclenchée sur une période de 24 heures. Donc, si je clique ici, j'ai des statistiques sur ma règle pour aller sur une période en particulier. Et là, je peux voir que ma règle fonctionne. Pour une protection encore plus avancée, je peux utiliser l'attaque score pour créer des règles custom, pour par exemple aller protéger des zones spécifiques de mon application qui seraient plus sensibles. Donc, par exemple, pour augmenter la sensibilité, je pourrais dire lorsque j'ai un score de 30, entre 0 et 30, donc on est entre la clé attaque et attaque, je peux faire un blocage. Pour me rendre compte quel genre de trafic est catégorisé par ce score, je peux aller dans Analytics, Attaque Analysis. Là, je vais changer la temporalité. Et ensuite, je vais aller ajuster le score, ici, et on peut mettre par exemple entre 30 et 1. Et ce qui va être très intéressant, c'est de regarder le nombre de roquettes qui n'ont pas été bloquées. Donc, ils sont passés vers mon serveur avec ses scores, donc ils n'ont pas été attrapés par les Manage Rules Set. Donc, je vais aller à Edge, je vais aller sélectionner Edge Statue Code. Et là, je vais sélectionner 200. Et là, je peux voir que j'ai uniquement ici deux roquettes. Et on voit que cette roquette est allée à l'origine, ici, parce qu'elle a été... On connaît d'une certaine façon qu'ils ne correspondaient pas à la signature. Et pour bloquer ce genre de roquettes, je vais pouvoir créer une règle. Et ma règle va dire, hop, créer une règle, Custom Rule. Et je vais aller sélectionner Attaque Score. Donc là, je peux être beaucoup plus précis en regardant, en sélectionnant XSS, SQL Injection, etc. Je vais sélectionner Attaque Score. Puis, est inférieur ou égal, less than or equal to 30. Et dans un premier temps, ce que je pourrais faire, c'est de la mettre en log pour observer ce qu'on attrape. Ou alors, si je suis confiant, de la bloquer ou de mettre des challenges, des challenges javascript. Ça peut être intéressant de d'émettre des challenges javascript, parce qu'on va retrouver souvent des roquettes qui sont automatisées. Mais pour être plus sécurisé, on peut mettre carrément ici un bloc. Je mets un titre à cette roquette. Et j'appuie sur Déployer. C'était un tour rapide du Web Application Firewall de Cloudflare. N'hésitez pas si vous avez la moindre question. A bientôt !