Les menaces changent de visage à chaque seconde. Au fur et à mesure que les pirates évoluent, devenant plus dynamiques et sournois, les vulnérabilités se matérialisent plus rapidement que les ingénieurs ne peuvent corriger leurs applications. La mission de Cloudflare consiste en partie à garantir votre sécurité et celle de vos applications. Aujourd'hui, Cloudflare lance une nouvelle fonctionnalité qui offre aux clients ce qu'ils réclamaient : un contrôle précis sur les requêtes qu'ils reçoivent.
Cloudflare offre déjà un certain nombre d'outils de pare-feu puissants comme les règles IP, les règles CIDR, les règles ASN, les règles nationales, le blocage d’agent utilisateur HTTP, Zone Lockdown (car ces URI n'autorisent le trafic qu'à partir de ces adresses IP) et notre WAF (Web Application Firewall). Cependant, il faut parfois combiner leur puissance pour contrer efficacement une attaque, et formuler une règle de blocage allant au-delà des limites des outils existants, pour pouvoir « bloquer le trafic vers cette URI lorsque la requête provient de cette IP et que l'agent utilisateur correspond à une de celles-ci ».
Flexibilité et contrôle
© Stefano Kocka : Source Wikipedia
Des thèmes communs sont ressortis lorsque nous avons échangé avec les clients concernant leurs besoins et examiné les demandes de fonctionnalités observées par notre service d'assistance client. Nous avons ainsi pu classer les principaux commentaires et demandes de fonctionnalités en trois principales catégories de besoins :
Plus de flexibilité pour créer une règle de pare-feu correspondant à plusieurs attributs, comme une adresse IP et un agent utilisateur
Une flexibilité permettant non seulement de faire correspondre exactement un attribut, mais aussi de le faire correspondre partiellement, en utilisant une chaîne de caractères ou un motif, par exemple
User-Agent: *Firefox*Un contrôle total en libre-service grâce à l'interface utilisateur et à l'API publique de Cloudflare, même pour les règles de pare-feu les plus complexes
L'équipe a travaillé de concert pour faire évoluer notre pare-feu, avec une mission primordiale : concevoir un couteau suisse de pare-feu pour nos clients. Nos principaux objectifs étaient les suivants :
Fournir un outil donnant aux clients un contrôle flexible et précis de leur trafic
Offrir une expérience utilisateur fluide et intuitive, ce qui nous tient à cœur
Faire en sorte qu'il soit accessible et utilisable par tous nos clients, quelles que soient leurs compétences ou la taille de leur entreprise
Firewall Rules
Firewall Rules, la nouvelle solution de Cloudflare, donne aux clients la possibilité de contrôler les requêtes d'une manière flexible et intuitive, inspirée du langage Wireshark® dont la réputation est largement établie. Il est possible de configurer les règles non seulement à l'aide de notre tableau de bord et de notre API, mais aussi à l'aide de Terraform (lien ici).
Deux éléments se dégagent de la structure de Firewall Rules :
Correspondance : définissez un filtre global correspondant exactement à votre trafic.
Action : indiquez l'action Cloudflare à effectuer lorsque le filtre correspond.
Autrement dit, lorsque le filtre correspond, appliquez l'action voulue.
Correspondance : détermination de la portée de la règle
Avec Cloudflare Firewall Rules, les clients ont accès aux propriétés de la requête HTTP, y compris le référant, l'agent utilisateur, les cookies, le score de menace Cloudflare (score de réputation IP), et plus encore.
Tous les en-têtes pris en charge peuvent être reconnus par de nombreux opérateurs, notamment en cas de correspondance partielle ( contient ), de chaîne complète ou de correspondance d'entier ( est égal à) et, pour nos clients Business et Enterprise, de correspondance de structures ( correspond à ). Oui, vous avez bien lu, nous proposons maintenant le filtrage par expressions régulières, directement via le tableau de bord et l'API !
L'avantage le plus intéressant de Firewall Rules est la flexibilité dont bénéficie Cloudflare pour les options de champ. Par exemple, Cloudflare Threat Intelligence, qui détermine notre niveau de sécurité fonctionnel sur le tableau de bord, sera un champ accessible aux clients. L'un des champs les plus importants introduits par Cloudflare est notre champ cf.client.bot, qui contrôle les bots bienveillants par reverse DNS. Dans notre première version, nous donnons aux clients l'accès au classement général des « bots de bonne réputation ». Vous trouverez de plus amples détails concernant la liste ici. Cloudflare a toujours mis Google sur liste blanche pour ses clients et a utilisé des règles de pare-feu applicatif Web, qui ne sont disponibles que pour les clients Pro et plus, pour bloquer les robot d'indexation usurpés. Avec Firewall Rules, tous les clients ont désormais accès à ces protections. Puisque Cloudflare a supprimé la fonctionnalité de mise en liste blanche, les clients doivent inclure simplement cf.client.bot dans une règle autorisée pour éviter de bloquer par inadvertance de bons robots d'indexation qui pourraient avoir une incidence sur le référencement et sur le suivi.
Action : détermination de l’action appliquée à la requête
Toutes les actions Cloudflare standard telles que JavaScript Challenge, Challenge et Block sont disponibles.
Nous avons ajouté un nouvel élément à la liste d'atténuation standard, l'action d'autorisation, qui donne au client la possibilité de créer une règle lui permettant de dire « si ce critère est respecté, ne plus appliquer de règles ».
Des exemples, s’il vous plaît !
Bien sûr. Voici quatre bons exemples de ce qui est utilisé aujourd'hui. Les règles avancées ou intégrées ne sont pas prises en charge dans Visual Rule Builder actuellement. Ces dernières sont notées sous chaque règle.
Exemple 1 : Imposer un questionnaire à tous les pays sauf la Grande-Bretagne
(ip.geoip.country ne "GB")Prise en charge : Visual Builder, Expression Editor
(http.request.method eq "GET" and http.referer ne ".example.com" and not http.user_agent matches "(googlebot|facebook)" and http.request.uri.path eq "/content/")Vous pouvez le faire à l'aide de notre pare-feu IP, mais cela nécessiterait plus de 150 règles !
(http.request.uri.path eq "/login" and (cf.threat_score < 10 or ip.geoip.asnum eq 12345))Exemple 2 : Protection anti-hotlink avancée
((http.host eq "api.example.com" and http.request.uri.path eq "/api/v2/auth") or (http.host matches "^(www|store|blog)\.example.com" and http.request.uri.path contains "wp-login.php") or ip.geoip.country in {"CN" "TH" "US" "ID" "KR" "MY" "IT" "SG" "GB"} or ip.geoip.asnum in {12345 54321 11111}) and not ip.src in {11.22.33.0/24}
111Prise en charge : Visual Builder, Expression Editor
La protection anti-hotlink intégrée de Cloudflare peut être contraignante pour certains clients, car elle ne permet pas de contourner certaines connexions. Certains robots d'indexation légitimes peuvent également être interceptés.
Exemple 3 : Blocage des clients dont le score de menace est supérieur à 10 ou de ceux provenant d'un réseau malveillant par numéro AS, vers ma page de connexion
Prise en charge : Expression Editor
L'un des avantages de Firewall Rules est que nous vous avons donné accès à cf.threat_score, qui détermine le niveau de sécurité du tableau de bord actuel.
Exemple 4 : Cas d'utilisation de type Zone Lockdown utilisant l'expression régulière, les CIDR d'adresse IP, le code pays et les numéros AS pour protéger les terminaux d'authentification via le site Web Wordpress et une API
Prise en charge : Expression Editor
Zone Lockdown est un excellent outil, mais il a ses limites pour certains cas d'utilisation critiques. Voici une idée un peu folle pour démontrer la flexibilité :
Modèles de sécurité positive et négative
Cette solution est un excellent complément au pare-feu, car elle permet à nos clients de choisir entre une politique de sécurité positive (autoriser les requêtes spécifiques et refuser tout le reste) et une politique de sécurité négative (bloquer les requêtes spécifiques et autoriser tout le reste).
Par défaut, Cloudflare autorise tout dans Firewall Rules. Le grand avantage de cette approche est qu'elle permet de ne bloquer que les éléments nuisibles. Bien qu'il s'agisse d'un moyen très efficace et performant de faire fonctionner un pare-feu, il pose un certain nombre de problèmes. En laissant passer tout le trafic, vos dispositifs de sécurité doivent être réactifs en cas de problème.
Le monde de la sécurité prône le concept de « confiance zéro ». Comme son nom l'indique, le principe de confiance zéro signifie que l'on ne fait confiance à rien et que toute autorisation doit être justifiée d'une manière ou d'une autre. Pour établir une politique de sécurité de type « confiance zéro », vous devez inverser le fonctionnement de votre politique de pare-feu par défaut, c'est-à-dire faire basculer la dernière action de allow à block, soit une politique de sécurité positive. Auparavant, cela n'était pas possible ; aujourd'hui, ça l'est avec Firewall Rules.
Visual Rule Builder et Expression Editor
L'une des plus grandes préoccupations lorsque l'on donne du pouvoir aux clients, c'est de le faire de manière sûre et efficace. L'équipe de conception produit et d'interface utilisateur a élaboré plusieurs versions successives pour aboutir à un éditeur de règles puissant mais accessible. L'équipe a passé plusieurs mois à élaborer plusieurs versions successives pour aboutir à un outil de création et une solution d'édition de règles performants, sans encombrer ou compliquer l'interface utilisateur.
Pete Thomas, concepteur en chef de la nouvelle interface utilisateur du pare-feu, nous a rappelé les bases des sessions de prototypage sur papier pour tester et découvrir comment les règles sont créées et gérées.
Vous pouvez voir ci-dessous une photo de Matthew Bullock, l'un de nos ingénieurs de Londres, et moi-même, en train de procéder à des essais.
Tout au long du processus de conception, nous avons voulu nous focaliser sur les raisons pour lesquelles les clients auraient besoin de Firewall Rules. Les résultats ont été simples : créer des règles défensives proactives, pour sécuriser une application, et des règles réactives, pour protéger les applications attaquées.
Dans Visual Rule Builder, nous avons mis à la disposition des clients un moyen intuitif de créer des règles de pare-feu, sans restreindre l'accès aux fonctionnalités de base. La future feuille de route permet un regroupement plus souple grâce à Visual Builder. Cependant, nous proposons une option pour les exigences plus complexes ou les règles de pare-feu intégrées. Vous pouvez les créer dans l'éditeur de règles, qui est basé sur notre langage inspiré de Wireshark® qui vous permet de vous servir d'expressions créées dans Wireshark et de créer des règles de pare-feu. David Kitchen, directeur technique responsable de l'élaboration des règles de pare-feu, rédigera un blog au cours des prochaines semaines pour expliquer en détail pourquoi nous avons choisi un DSL inspiré de Wireshark® pour nos expressions de filtrage. Pour voir la liste des champs pris en charge, consultez notre documentation.