La détection complète des transactions est maintenant disponible pour le pare-feu Cloudflare WAF

Aujourd’hui, nous étendons les capacités de notre pare-feu d’applications web (WAF) avec l’ajout de deux nouvelles fonctionnalités : la détection complète des transactions et les règles de réponse. La détection complète des transactions évalue chaque requête HTTP ainsi que sa réponse afin d’identifier d’éventuelles preuves d’exploitation. Elle aide ainsi à obtenir des réponses à deux questions : « Cette requête semble-t-elle malveillante ? » et « Que s’est-il passé lorsque l’application l’a traitée ? » Les règles de réponse peuvent ensuite bloquer la réponse du serveur d’origine avant qu’elle ne parvienne au demandeur.

Ces protections sont précieuses à l’heure où les nouveaux modèles avancés révèlent des vulnérabilités enfouies au cœur de logiciels largement utilisés. S’ils permettent aux équipes responsables de la défense des infrastructures d’identifier clairement les failles devant être corrigées, ils offrent également aux acteurs malveillants de nouvelles approches qu’ils peuvent exploiter. La récente vulnérabilité de ​php2shell met en évidence les enjeux : une faille au sein d’un composant logiciel commun peut compromettre des applications sur l’ensemble d’Internet. Les agents IA qui recherchent des vulnérabilités peuvent être extrêmement persistants, et utilisent les retours d’informations pour adapter les contenus malveillants et corréler les vulnérabilités, les identifiants et les autorisations. La réponse d’une application peut révéler si une tentative a abouti et fournir à un acteur malveillant des informations qui l’aideront à approfondir son analyse.

L’inspection des requêtes entrantes reste essentielle pour bloquer les attaques identifiables avant qu’elles n’atteignent une application. Cependant, certaines menaces ne deviennent manifestes que lorsque la requête est examinée à la lumière de la réponse renvoyée par le serveur d’origine. Une saisie suspecte suivie d’une réponse divulguant des informations sensibles raconte en effet une tout autre histoire que la même saisie suivie d’un refus ou d’une erreur.

Grâce à ces nouvelles fonctionnalités, les clients peuvent utiliser les protections gérées par Cloudflare ou définir leurs propres politiques associant les propriétés des requêtes et des réponses. Ce système vient compléter notre infrastructure toujours active de sécurité des applications, les résultats des détections étant disponibles dans les données d’analyse de sécurité afin de faciliter l’étude d’incidents. Nos premières mesures de protection gérées utilisant cette fonctionnalité ont pour finalité de remédier à la vulnérabilité php2shell récemment révélée.

Et, cerise sur le gâteau, nous mettons ces nouvelles fonctionnalités à la disposition de tous les clients de Cloudflare, offres gratuites incluses.

L’inspection des requêtes ne suffit pas

Le pare-feu Cloudflare WAF protège les sites web et les API grâce aux règles gérées, aux règles personnalisées et au contrôle du volume des requêtes. Les règles gérées offrent une protection contre les techniques d’attaque et les vulnérabilités connues, tandis que les règles personnalisées permettent aux équipes de créer leurs propres politiques avec des paramètres tels que l’adresse IP, le chemin d’accès de l’URL, l’en-tête et le corps de la requête. Ces contrôles interviennent au niveau des requêtes afin de prévenir les tentatives d’exploitation ou d’empêcher le trafic indésirable d’atteindre le serveur d’origine.

Pour de nombreuses menaces, c’est l’endroit idéal pour agir. Cependant, traiter chaque requête suspecte comme une tentative d’exploitation avérée entraîne un dilemme complexe. Les signatures de requêtes étendues permettent de détecter davantage d’attaques potentielles, mais elles peuvent également générer des « faux positifs » – par exemple, en identifiant du trafic légitime au risque d’entraîner des dysfonctionnements des applications. Déployer uniquement des règles qui ne génèrent pas de faux positifs permet de réduire ce risque, mais peut permettre à du trafic plus ambigu d’atteindre le serveur.

La réponse fournit les éléments de preuve manquants. Cloudflare est désormais en mesure de corréler la réponse avec la requête qui l’a générée, ce qui permet à la détection de prendre en compte le résultat de l’ensemble de la transaction HTTP.

À titre d’exemple, prenons une application qui permet aux utilisateurs de télécharger des fichiers. Un acteur malveillant manipule le paramètre file pour demander un fichier de configuration privé situé hors du répertoire autorisé :

GET /download?file=../../config/database.ini

L’inspection de la requête permet de détecter cette tentative de traversée de chemin et de la bloquer avant qu’elle n’atteigne l’application. Cependant, la requête ne permet pas, à elle seule, de déterminer si l’application rendrait le fichier accessible. Le serveur peut refuser la requête, ignorer la traversée de répertoire ou renvoyer une erreur. Si la requête parvient au serveur d’origine, une réponse comme celle-ci fournit une preuve supplémentaire :

200 OK
Content-Type: text/plain
[database]
username=app_service
password=EXAMPLE_SECRET

La détection complète des transactions apporte la pièce manquante : elle permet de mettre en corrélation la tentative d’accès au fichier et le contenu de la réponse, caractéristique d’un fichier de configuration privé. Du texte semblable à des informations de configuration peut légitimement être inclus dans une documentation ou dans des exemples disponibles en téléchargement ; l’associer à une tentative de traversée constitue une preuve plus solide de l’exposition de données sensibles que l’un ou l’autre de ces signaux pris isolément. Une règle de réponse peut ensuite remplacer la réponse du serveur d’origine par une page de blocage du pare-feu Cloudflare WAF et un code d’erreur HTTP 403 avant que celle-ci ne parvienne au demandeur, et ainsi, bloquer efficacement la tentative d’exploitation en empêchant la transmission d’informations sensibles à l’acteur malveillant.

Les fonctions de détection et d’atténuation sont intrinsèquement distinctes

La détection complète des transactions vient étendre l’​infrastructure de détection toujours active que nous avons présenté plus tôt cette année. Les détections analysent le trafic et joignent des métadonnées à la requête et à la réponse ; les règles déterminent ensuite la suite à donner à ces résultats.

La séparation de ces tâches offre de la visibilité aux clients en amont de l’élaboration d’une politique. Les équipes de sécurité peuvent analyser les détections dans leur propre trafic, comprendre quels points de terminaison et signatures sont impliqués, puis choisir la réponse la mieux adaptée à leur application. De manière semblable à l’approche utilisée pour la règle basée sur les requêtes ​Attack Signature Detection (détection de signatures d’attaque), les résultats des détections sont stockés dans des champs accessibles via les règles de réponse personnalisées ou utilisés dans les détections gérées pour bloquer le trafic.

À l’instar des champs de détection des requêtes, les nouveaux champs suivants ont été ajoutés à notre plateforme :

Les premières détections complètes des transactions priorisent essentiellement la confirmation de l’exploitation d’une vulnérabilité très médiatisée. Elles établissent une corrélation entre les entrées suspectes et les signaux de réponse indiquant qu’une tentative d’exploitation pourrait avoir abouti.

Nous élargirons notre couverture au fil du temps en prenant en charge d’autres scénarios d’utilisation, notamment la détection des signaux d’exposition et d’exfiltration de données. Il s’agit là d’un élément important pour l’Internet, au-delà de toute application isolée : les mesures défensives peuvent en effet distinguer les tentatives de sondage des preuves d’impact, tandis que la détection des données et des services exposés peut atteindre les clients qui ne disposent pas d’une équipe de sécurité dédiée, capable de paramétrer précisément chaque règle du pare-feu WAF.

Créer des règles de réponse

La détection des preuves d’exploitation n’a de véritable utilité que si vous pouvez y réagir en temps réel. Les règles de réponse personnalisées transforment la détection complète des transactions en protection en ligne en bloquant la réponse d’un serveur d’origine correspondant aux signaux avant qu’elle n’atteigne le demandeur. Toutefois, elles ne peuvent pas annuler les actions déjà effectuées au niveau du serveur d’origine.

Les équipes de sécurité peuvent désormais associer les propriétés des requêtes et des réponses aux résultats de détection, afin de déterminer quelles réponses doivent être bloquées. Lorsqu’une règle de blocage est déclenchée, Cloudflare remplace la réponse du serveur d’origine par une page de blocage du pare-feu WAF ou une réponse personnalisée.

Les contrôles de la phase de réponse sont disponibles dans le tableau de bord de Cloudflare, en bas de la page Sécurité > Règles de sécurité, où figurent à la fois les protections gérées et les règles personnalisées.

Nous avons publié des règles gérées et personnalisées pour toutes les offres, y compris les offres gratuites. À terme, nous adopterons la même approche que celle que nous utilisons pour la détection des requêtes : les détections gérées pour les offres gratuites ​priorisent les vulnérabilités les plus critiques, tandis que les clients des offres payantes bénéficient d’un catalogue de détections plus complet.

Détections gérées

Tous les clients bénéficient de la protection offerte par l’ensemble complet de détections de transactions via l’ensemble de règles Cloudflare Managed Response Firewall Default, conçu pour permettre un déploiement simple en un clic et une configuration simplifiée. Lorsqu’une signature correspond, le système de détection gérée bloque la réponse et affiche une page de blocage standard du pare-feu WAF.

Vous pouvez modifier la portée de l’ensemble de règles Cloudflare Managed Response Firewall Default afin de limiter les détections à une partie seulement des applications ; par exemple, en excluant ou en restreignant la détection à un chemin d’accès spécifique. Les clients des offres payantes peuvent utiliser les champs de détection dans les règles de réponse personnalisées pour créer des politiques mieux adaptées.

Règles personnalisées

Les règles de réponse personnalisées sont conçues pour donner aux clients un contrôle total sur la logique de ces règles. Une règle utile peut empêcher l’exposition d’une interface d’administration lorsqu’une passerelle d’authentification n’a pas identifié la requête comme interne. Par exemple :

http.request.uri.path starts_with "/admin" and not http.request.headers["x-internal-user"][0] eq "true" and http.response.code eq 200 and http.response.headers["content-type"][0] contains "text/html"

Cette règle déclenche uniquement un blocage lorsqu’une requête non authentifiée cible /admin et que le serveur d’origine renvoie effectivement une page d’administration HTML correcte. Elle ne bloque pas les échecs d’authentification courants, les redirections ou le trafic non lié à l’administration.

Tous les clients peuvent créer jusqu’à trois règles de réponse personnalisées prenant en charge les actions Log (Journaliser) et Block (Bloquer). Les champs et fonctions disponibles en réponse aux règles personnalisées correspondent aux fonctionnalités contenues dans votre offre dans les ​règles de requêtes personnalisées. La création de règles pour le corps de la réponse n’est pas encore disponible.

Conformément à l’approche ​Attack Signature Detection (détection des signatures d’attaques), les clients des offres payantes ont également accès aux résultats des détections d’attaques via les champs cf.waf.signature.response.* présentés ci-dessus. Ces champs peuvent être associés à d’autres paramètres (tels qu’un nom d’hôte, un chemin d’accès d’URL, une adresse IP source ou un en-tête de requête) afin d’activer la protection sur un chemin d’accès spécifique ou de limiter la politique à un contexte propre à une application. Nous sommes actuellement en train de déployer les champs de réponse sur tous nos comptes. Si vous n’y avez pas encore accès, veuillez contacter l’équipe chargée de votre compte.

Examiner les requêtes correspondantes

Lorsqu’une règle de réponse gérée ou personnalisée enregistre ou bloque une transaction, l’événement devient disponible dans les événements de sécurité. Cela signifie que les intervenants peuvent retracer chaque détection jusqu’au contexte complet de la requête et à la règle spécifique qui a pris les mesures nécessaires.

Actuellement, les règles relatives aux requêtes uniquement et les règles relatives aux transactions complètes sont affichées sur la même page d’analyses de données. Dans les événements de sécurité, les événements générés par les règles de réponse font partie du service Règles gérées ou Règles personnalisées. Vous pouvez filtrer les événements appartenant à un ID de règle spécifique dans la section des listes de règles relatives.

Lancez-vous dès aujourd’hui

La détection complète des transactions est proposée en disponibilité générale pour toutes les zones qui traitent le trafic en proxy via Cloudflare. Pour vérifier que vous êtes protégé, accédez à Sécurité > Règles de sécurité dans le tableau de bord de Cloudflare. Si vous souhaitez personnaliser votre politique, commencez par examiner les détections complètes de transactions dans les Outils d’analyse de la sécurité, puis créez la politique de phase de réponse adaptée à votre application.