Pare-feu d’application web sur Front Door

Un Web Application Firewall (WAF) inspecte les requêtes HTTP/HTTPS au niveau 7 et bloque les schémas d’attaque connus avant qu’ils n’atteignent votre application. Parmi les attaques courantes qu’il empêche figurent l’injection SQL, le cross-site scripting (XSS), l’inclusion de fichiers distants et les anomalies de protocole. Sans WAF, des attaquants peuvent exploiter des vulnérabilités dans le code de votre application même si votre réseau est correctement sécurisé. Azure WAF s’intègre à Azure Front Door et à Azure Application Gateway.

Dans Azure, une stratégie WAF est une ressource autonome qui contient des ensembles de règles gérés et des règles personnalisées. Vous créez la stratégie, configurez les règles, puis vous l’associez à un ou plusieurs points de terminaison Front Door ou à des instances Application Gateway. Cette conception découplée signifie qu’une même stratégie WAF peut protéger plusieurs points de terminaison Front Door : une seule modification de la stratégie est automatiquement propagée à tous les points de terminaison associés. Les stratégies WAF existent dans une région Azure spécifique, mais lorsqu’elles sont associées à Front Door, la protection est appliquée à l’échelle mondiale dans tous les PoPs.

Les stratégies WAF fonctionnent selon deux modes. Le mode Détection inspecte toutes les requêtes et consigne les correspondances avec les règles, mais ne bloque aucun trafic. Il est utile lors du déploiement initial pour comprendre quel trafic votre stratégie bloquerait avant de l’appliquer. Le mode Prévention consigne les requêtes et bloque activement celles qui correspondent aux conditions des règles. Il est recommandé de commencer en mode Détection, d’examiner les journaux WAF pour repérer les faux positifs, d’ajuster les règles, puis de passer en mode Prévention lorsque vous êtes certain que la stratégie est correcte.

Le Microsoft Default Rule Set (DRS) est un groupe de règles géré et maintenu par l’équipe de sécurité de Microsoft. Il contient des règles qui détectent les vulnérabilités de l’OWASP Top 10, ainsi que des signatures de robots et des schémas de bourrage d’identifiants. Microsoft met continuellement à jour DRS avec de nouvelles règles en réponse aux menaces émergentes : vous n’avez pas besoin d’écrire vous-même vos règles. De nouvelles versions de DRS sont publiées périodiquement (par exemple, DRS 2.1), et vous pouvez mettre à niveau votre stratégie WAF vers une version plus récente pendant une fenêtre de maintenance.

Le OWASP Core Rule Set (CRS) est disponible sur Application Gateway WAF et intégré au WAF du CDN de niveau Verizon. Il contient plus de 200 règles couvrant l’OWASP Top 10 : attaques par injection, authentification défaillante, exposition de données sensibles, attaques par entités externes XML, et bien plus encore. Chaque règle possède un ID et un groupe (par exemple, REQUEST-942-APPLICATION-ATTACK-SQLI). Vous pouvez désactiver des règles individuelles par ID afin de supprimer les faux positifs sans désactiver tout le groupe de règles.

Les règles personnalisées vous permettent d’écrire des conditions d’autorisation ou de blocage précises que les ensembles de règles gérés ne couvrent pas. Une règle personnalisée se compose d’une ou plusieurs conditions de correspondance (par exemple, l’adresse IP source, l’URI de la demande, la valeur d’un en-tête ou la chaîne de requête), combinées à une action (autoriser, bloquer, journaliser ou rediriger). Les règles personnalisées sont évaluées avant les ensembles de règles gérés et prennent en charge un ordre de priorité. Cas d’utilisation courant : bloquer certains pays, limiter le débit des robots d’exploration agressifs ou autoriser une IP de supervision approuvée à contourner les règles WAF.

Les règles de limitation du débit restreignent le nombre de demandes HTTP provenant d’une seule adresse IP cliente pendant une fenêtre temporelle (1 ou 5 minutes). Lorsque le nombre de demandes dépasse le seuil, le WAF renvoie le code HTTP 429 (trop de demandes) à ce client. La limitation du débit est efficace contre les attaques par force brute visant la connexion, le bourrage d’identifiants et les abus d’API. Vous configurez le seuil et la fenêtre de demandes dans la définition de la règle personnalisée de la stratégie WAF.

L’ensemble de règles Bot Manager (disponible dans Front Door Premium) classe le trafic entrant en bons robots (robots d’exploration de moteurs de recherche vérifiés), mauvais robots (scanners connus et sondes de vulnérabilités) et robots inconnus (trafic automatisé non classifié). Vous pouvez configurer l’action pour chaque catégorie : autoriser les bons robots, bloquer les mauvais et journaliser les inconnus. Sans protection contre les robots, des scanners automatisés peuvent générer des volumes de trafic considérables, augmenter vos coûts et masquer le trafic réel des utilisateurs dans les analyses.

Les ensembles de règles gérés génèrent parfois des faux positifs : ils bloquent des demandes légitimes parce que celles-ci correspondent par hasard au modèle d’une règle de sécurité. Par exemple, un CMS doté d’un éditeur de texte enrichi peut envoyer du HTML dans le corps de demandes POST, ce qui correspond à une règle XSS. Les exclusions WAF vous permettent d’exclure certains attributs de demande (en-têtes de demande, cookies, paramètres de chaîne de requête ou champs du corps de la demande) de l’évaluation des règles, globalement ou pour un groupe de règles ou un ID de règle précis, sans désactiver entièrement la règle.

WAF génère deux types d’entrées de journal dans Azure Monitor : les journaux WAF (chaque demande correspondant à une règle, qu’elle soit bloquée ou journalisée) et les journaux d’accès (toutes les demandes, y compris celles qui sont passées sans correspondre à aucune règle). Envoyez ces journaux vers un espace de travail Log Analytics et utilisez KQL pour interroger les tendances des demandes bloquées, identifier les points de terminaison les plus attaqués ou examiner une adresse IP cliente précise. Le classeur WAF Insights du portail fournit des tableaux de bord prédéfinis qui visualisent ces journaux.

Pour activer la protection WAF, vous devez associer la stratégie WAF à votre profil de sécurité Front Door. Dans le portail, accédez à votre profil Front Door, sélectionnez Security policies, puis ajoutez la stratégie WAF en indiquant les domaines auxquels elle s’applique. Vous pouvez également utiliser le CLI pour lier la stratégie. Une fois l’association effectuée, le WAF inspecte toutes les demandes HTTP/HTTPS arrivant sur ces domaines Front Door avant de les acheminer vers l’origine. Vous pouvez associer une seule stratégie WAF par domaine.

Vérifiez votre compréhension des concepts Microsoft Azure Fundamentals (AZ-900) présentés dans cette leçon.

Dans cette leçon, vous avez appris que les stratégies WAF contiennent des ensembles de règles gérés (Microsoft DRS, OWASP) et des règles personnalisées qui inspectent le trafic HTTP avant qu’il n’atteigne votre origine, que le mode Détection vous permet d’ajuster les règles avant de passer au mode Prévention, et que les règles de limitation du débit vous protègent contre la force brute et les abus. Nous allons maintenant découvrir comment utiliser le moteur de règles de Front Door pour optimiser les performances avec des redirections et des en-têtes de sécurité.