Cloudflare ajoute une règle WAF d’urgence : vérifiez protection et exceptions

Cloudflare a ajouté le 14 octobre une règle de blocage d’urgence à son ensemble Cloudflare Managed Ruleset, en indiquant répondre à l’exploitation active d’une vulnérabilité d’exécution de code à distance dans des frameworks web. Pour un propriétaire de site, la prochaine étape utile consiste à vérifier les règles et la configuration qui protègent réellement son site.

L’avis de publication ne nomme pas les frameworks concernés, ne liste pas les versions vulnérables et n’identifie aucun correctif fournisseur. Il ne permet donc pas d’établir si un site particulier est vulnérable. L’affirmation d’une exploitation active est celle de Cloudflare ; elle ne prouve pas que le site d’un lecteur donné a été attaqué.

Vérifier la protection dont vous disposez

L’avis situe la nouvelle détection dans Cloudflare Managed Ruleset, avec l’action Block. La documentation sur les règles gérées distingue cet ensemble du Free Managed Ruleset : le Cloudflare Managed Ruleset, plus étendu, est disponible avec les offres Pro, Business et Enterprise.

Ne déduisez pas qu’un site est couvert du seul fait que son domaine utilise les serveurs de noms Cloudflare. Demandez à la personne qui gère le compte de confirmer que le trafic concerné passe par la protection, que le bon ensemble de règles est déployé et que son action effective n’a pas été modifiée.

Notez le nom d’hôte, l’ensemble de règles et la configuration vérifiés. Une assurance générale devient ainsi un élément qu’un autre administrateur peut contrôler. Si votre hébergement est géré par un prestataire, demandez-lui quelles parties de l’application et du parcours du trafic il contrôle.

La documentation de Cloudflare explique aussi que les exceptions et les substitutions de paramètres peuvent modifier les règles exécutées et leurs actions. Une ancienne exception créée pour réparer un formulaire mérite un nouvel examen si elle contourne largement les contrôles de sécurité de l’application.

Contrôler l’application autant que le pare-feu

Un filtre placé devant un site et un correctif de l’application constituent deux protections distinctes. Cette annonce ne fournit aucune version corrigée à installer : consultez donc les avis officiels relatifs aux logiciels que vous utilisez réellement. Ne choisissez pas un correctif en devinant quel framework non nommé Cloudflare désigne.

Tenez un inventaire du CMS, des frameworks, des extensions et des applications personnalisées maintenues sur le site. Les prochains avis pourront alors déboucher sur une action : il sera possible de faire correspondre un produit et une version nommés à un composant installé, au lieu de partir de mémoire.

Si les journaux de sécurité montrent des requêtes bloquées, conservez-les pour analyse. Une requête bloquée ne démontre pas à elle seule une compromission réussie. Inversement, un rapport sans activité ne constitue pas une évaluation complète de l’application. Transmettez les indices de modifications ou d’accès non autorisés à la personne responsable de la réponse aux incidents.

Vérifier que la publication fonctionne toujours

Après avoir contrôlé la règle, essayez les parcours habituels des lecteurs et des rédacteurs : charger un article, se connecter, enregistrer un brouillon et envoyer un formulaire de test autorisé. Si une action légitime est bloquée, recueillez les informations sur l’événement concerné et précisez le diagnostic avant de modifier la protection.

Évitez une désactivation générale comme première étape de dépannage. Identifiez la requête concernée et examinez avec l’administrateur la correction adaptée la plus limitée possible.

Ajoutez les contrôles de configuration et d’application à la routine de maintenance du site. Si personne ne sait qui en est responsable, clarifiez ce point avant le prochain renouvellement ou changement d’hébergement.