Web core protection rules - Web Application Firewall - Centre de documentation Alibaba Cloud

Web Application Firewall (WAF) offre une sécurité prête à l'emploi. Après avoir ajouté vos ressources à WAF, un ensemble prédéfini de règles de protection essentielles s'applique automatiquement pour vous défendre instantanément contre les attaques courantes visant les applications web, telles que l'injection SQL, le cross-site scripting (XSS) et l'injection de commandes, sans configuration supplémentaire. Cette rubrique explique comment gérer et affiner ces règles.

Important

La fonctionnalité Core Protection Rule fait l'objet d'un déploiement progressif. Cette rubrique décrit la nouvelle version. Si vous utilisez l'ancienne version, consultez la page Règles de protection Web essentielles (héritées). Pour prendre connaissance de l'annonce de mise à niveau, reportez-vous à la section [[Avis] Mise à niveau de la fonctionnalité de règle de protection de base WAF 3.0](t2809165.xdita#). Vous pouvez identifier votre version en vérifiant la présence de la section Core Protection Rule sur la page Protection Config > Core Web Protection de la console WAF.

Nouvelle version

Un ensemble de règles intégré, fondé sur l'expérience en matière de protection de la sécurité, qui défend contre les attaques courantes visant les applications web, telles que l'injection SQL, le XSS, l'exécution de code, le téléchargement de webshell et l'injection de commandes. Cliquez sur Create Template pour créer un modèle de règle de protection.

Ancienne version

Concepts clés

Core Protection Rule : module de protection au sein de la protection Web essentielle. Ce module s'active via un modèle de protection. Après l'activation de WAF, le système crée automatiquement un modèle de protection par défaut. Vous pouvez également créer manuellement plusieurs modèles de protection.

Modèle de protection : un modèle de protection est un ensemble de règles de protection qui définit leur contenu et leur portée. Lors de la création d'un modèle de protection, configurez les éléments Template Information, Engine Configuration et Configure Effective Scope.

Template Information : définit le type de modèle, qui ne peut pas être modifié après la création du modèle. Il existe deux types de modèles :

Type de modèle	Description	Cas d'utilisation
Modèle de protection par défaut	Le système fournit un modèle de protection par défaut initial. Le modèle s'applique automatiquement aux objets protégés et aux groupes d'objets qui ne sont associés à aucun modèle de protection personnalisé. Il s'applique également aux nouveaux objets ajoutés. Vous pouvez exclure manuellement des objets spécifiques en définissant leur statut sur « Non appliqué ». Un seul modèle de protection par défaut peut exister dans le module de règles de protection essentielles. Lorsque vous retirez un objet protégé d'un modèle de protection personnalisé, il s'ajoute automatiquement au modèle de protection par défaut.	Utilisé pour déployer des règles de protection générales applicables globalement. Si vos services n'ont pas d'exigences de protection particulières, nous vous recommandons d'utiliser le modèle de protection par défaut. Aucune configuration supplémentaire n'est requise.
Modèle de protection personnalisé	Vous devez spécifier manuellement les objets protégés ou les groupes d'objets auxquels il s'applique.	Utilisé pour déployer des règles de protection granulaires adaptées à des besoins métier spécifiques.

Engine Configuration : définit les règles de protection. Conformément aux bonnes pratiques de sécurité, WAF propose plusieurs System Protection Rules, classées par Detection Modules, afin de se défendre contre différents types d'attaques. Configurez l'Action pour les System Protection Rules. Pour les ressources relevant des Custom Protection Rules, vous pouvez également configurer des Custom Protection Rules afin de répondre à vos exigences métier.
Configure Effective Scope : spécifie les cibles du modèle de protection. En configurant la portée effective, vous appliquez des règles de protection à des objets protégés ou à des groupes d'objets protégés spécifiques. Un objet protégé ou un groupe d'objets ne peut être associé qu'à un seul modèle de protection.
- Objet protégé : le système crée automatiquement un objet protégé pour chaque domaine ou instance de service cloud que vous ajoutez à WAF.
- Groupe d'objets protégés : ajoutez plusieurs objets protégés à un groupe d'objets protégés pour une gestion centralisée.

Avantages

Protection prête à l'emploi : le modèle système par défaut inclut plusieurs règles de protection intégrées. Les nouvelles ressources ajoutées sont automatiquement protégées par ces règles, ce qui répond aux besoins de sécurité courants sans configuration supplémentaire.
Plusieurs méthodes de décodage : WAF prend en charge l'analyse et le décodage de formats de données tels que JSON, XML et Form, ainsi que diverses méthodes d'encodage comme Base64 et les entités HTML. Cela garantit la détection du trafic malveillant dissimulé par plusieurs couches d'encodage ou de compression.
Moteur de liste blanche intelligent : WAF utilise l'IA pour apprendre de votre trafic historique, identifier les règles de protection qui génèrent des faux positifs pour des URL spécifiques et les ajouter automatiquement à une liste blanche. Cela réduit efficacement les faux positifs.

Remarque

Avant de commencer, assurez-vous d'avoir ajouté vos services web à WAF, ce qui crée les objets protégés requis. Si ce n'est pas le cas, consultez la page Présentation de l'intégration.

Créer un modèle de protection granulaire

Après avoir ajouté vos services à WAF, le système applique automatiquement le modèle de protection par défaut à tous les objets protégés et active la protection. Si vos services n'ont pas d'exigences de protection particulières, vous n'avez pas besoin de créer un modèle de protection. Suivez ces étapes uniquement si vous devez configurer des règles différentes pour différents objets protégés.

Si vous devez uniquement traiter les faux positifs ou les faux négatifs de WAF, consultez la section Traitement des faux positifs et des faux négatifs.

Accédez à la console :

Connectez-vous à la console Web Application Firewall 3.0. Dans la barre de navigation supérieure, sélectionnez le groupe de ressources et la région (Chinese Mainland ou Outside Chinese Mainland) de votre instance WAF. Dans le volet de navigation de gauche, choisissez Protection Config > Core Web Protection. Dans la section Core Protection Rule.
Configurez Create Template :
- Template Information : saisissez un nom facile à identifier.
- Template Name : le système fournit un modèle de protection par défaut initial, et un seul peut exister pour le module de règles de protection essentielles. Par conséquent, si le modèle par défaut initial existe, vous ne pouvez pas définir cette option sur « Yes ».
  - Yes : vous n'avez pas besoin de configurer l'élément Save as Default Template. Lors de la création, le modèle s'applique automatiquement aux objets protégés et aux groupes d'objets qui ne sont associés à aucun modèle de protection personnalisé. Il s'applique également aux nouveaux objets ajoutés. Vous pouvez exclure manuellement des objets spécifiques en définissant leur statut sur « Non appliqué ».
  - No : vous devez configurer l'élément Configure Effective Scope en spécifiant manuellement les objets protégés ou les groupes d'objets auxquels il s'applique.
Configure Effective Scope :
- Engine Configuration : cette fonctionnalité est activée par défaut.
  - Enabled : les mises à jour des règles de l'équipe de sécurité Alibaba Cloud se synchronisent automatiquement avec votre moteur de détection. WAF applique automatiquement les nouvelles règles. Le Automatic Update of Detection Engine de la règle est défini sur « Enabled » ou « Disabled », et l'Action de la règle est définie sur « Monitor » ou « Block ».
  - Disabled : les règles se synchronisent toujours, mais leur Status est défini sur « Disabled » et l'Status est définie sur « Monitor ».
- Action : cliquez sur Configure Engine dans le coin supérieur droit, ou sur Configure Engine dans la colonne Configure pour un Detection Modules spécifique ci-dessous afin de configurer les règles de protection. Pour obtenir la liste des modules de détection pris en charge, consultez l'Annexe.
  System Protection Rules
  
  Les règles de protection système sont basées sur les modules de détection intégrés d'Alibaba Cloud et sont disponibles à quatre niveaux de strictesse : Super Strict, Strict, Medium et Loose. Par défaut, les règles aux niveaux Medium et Medium sont activées, tandis que les règles aux niveaux Loose et Super Strict sont désactivées.
  
  Vous pouvez configurer les paramètres suivants pour les règles de protection système :
  - Strict : sélectionnez une action pour les requêtes correspondant à la règle.
    
    Action : bloque les requêtes correspondantes et renvoie une page de blocage au client.
    
    Block : autorise et enregistre les requêtes correspondantes. Lors du test d'une règle, utilisez d'abord le mode Monitor et analysez les journaux WAF pour confirmer qu'aucun faux positif n'est généré.
  - Monitor : activez ou désactivez la règle. Si elle est désactivée, la règle ne s'applique pas aux requêtes.
  Remarque
  Consultez les détails des occurrences pour diverses règles de protection dans les Rapports de sécurité.
  Status (mode cloud hybride uniquement)
  
  Les règles de protection personnalisées s'appliquent uniquement aux objets protégés ajoutés à WAF en mode cloud hybride. Pour ajouter des règles de protection personnalisées et les utiliser dans un modèle de protection, consultez la page Gestion de la bibliothèque de règles.
- Custom Protection Rules : la fonctionnalité Adaptive Engine est désactivée par défaut. Lorsqu'elle est activée, WAF utilise l'IA pour apprendre du trafic historique, identifier les règles qui génèrent des faux positifs au niveau de l'URL et créer automatiquement des règles de liste blanche afin de les réduire.
  
  Le modèle de liste blanche créé automatiquement est nommé AutoTemplate. Pour plus d'informations, consultez la page Liste blanche.
  
  Remarque
  Cette fonctionnalité est disponible uniquement pour les instances à la demande (Pay-As-You-Go), les éditions Enterprise par abonnement et les éditions Ultimate par abonnement.
Configurez Intelligent Whitelist Engine :

Sélectionnez les objets protégés et groupes d'objets protégés auxquels vous souhaitez appliquer ce modèle. La portée effective du modèle dépend de la configuration effectuée à l'étape 2 :
- Utilisation du modèle par défaut créé par le système ou définition en tant que modèle par défaut : vous n'avez pas besoin de définir la portée effective. Lors de la création, le modèle s'applique automatiquement aux objets protégés et aux groupes d'objets qui ne sont associés à aucun modèle de protection personnalisé, ainsi qu'aux nouveaux objets ajoutés. Vous pouvez exclure manuellement des objets spécifiques en définissant leur statut sur « Non appliqué ».
- Non défini comme modèle par défaut : spécifiez manuellement les objets protégés et les groupes d'objets auxquels le modèle s'applique.
  
  Remarque
  Vous pouvez ajuster manuellement le statut effectif des objets protégés ou des groupes d'objets protégés, aussi bien pendant qu'après la création du modèle.

Traitement des faux positifs et des faux négatifs

Lorsque WAF bloque un trafic légitime (faux positif) ou ne parvient pas à bloquer une attaque (faux négatif), suivez ces étapes pour identifier la cause et ajuster votre configuration.

Traitement des faux positifs

Dans le volet de navigation de gauche, choisissez Configure Effective Scope > Security Reports.

Remarque
Si vous avez activé Log Service, vous pouvez également accéder à Detection and Response > Detection and Response pour afficher les journaux complets des requêtes.
Filtrez les journaux par Time, Protected Objects (le domaine/l'instance de service cloud accédé) et Action pour localiser la requête bloquée spécifique.

Sur la page Log Service, définissez les conditions de filtre : sélectionnez une plage horaire Security Reports, sélectionnez le Custom cible et définissez l'Domain/Instance sur Action pour afficher les tendances de blocage des attaques et la répartition des types d'attaque pour la période spécifiée.
Si vous confirmez qu'une requête légitime a été bloquée, recherchez-la dans les Block et cliquez sur Logs dans la colonne Actions pour créer une règle de liste blanche et autoriser la requête.

Si vous remarquez que les requêtes partagent des caractéristiques communes (par exemple, une adresse IP de confiance déclenche plusieurs règles de protection différentes), nous vous recommandons d'ajouter l'adresse IP en tant que Actions dans une seule règle de liste blanche. Cette approche est plus efficace que la mise en liste blanche de chaque entrée de journal bloquée individuellement. Pour plus d'informations, consultez la section Liste blanche.

Traitement des faux négatifs

Si une attaque n'est pas bloquée par WAF, examinez les causes courantes suivantes et les solutions recommandées :

La requête n'est pas traitée par WAF
- Cause : le certificat SSL ou le port d'écoute configuré dans WAF ne correspond pas à celui du serveur d'origine.Recommandation : vérifiez que les configurations du certificat SSL et du port dans WAF et sur le serveur d'origine sont cohérentes.
- Cause : pour l'intégration via CNAME, l'enregistrement DNS n'a pas été correctement modifié, de sorte que le trafic n'est pas dirigé vers WAF.Recommandation : confirmez que l'enregistrement DNS pointe correctement vers l'adresse CNAME fournie par WAF.
- Cause : pour l'intégration via CNAME, l'attaquant contourne WAF en accédant directement à l'adresse IP du serveur d'origine.
  
  Recommandation : dans le groupe de sécurité de votre serveur, autorisez le trafic uniquement depuis les adresses IP de retour vers l'origine de WAF.
- Cause : pour l'intégration de service cloud, l'instance de service cloud ajoutée à WAF n'est pas celle vers laquelle le trafic du domaine est réellement acheminé.
  
  Recommandation : confirmez que la bonne instance de service cloud a été ajoutée à WAF.
La requête est traitée par WAF, mais aucune règle ne la couvre

Le modèle de protection par défaut ne peut pas couvrir tous les types d'attaques. Vous devrez peut-être activer d'autres modules de protection en fonction des caractéristiques de l'attaque :
- Pour les attaques CC (inondations HTTP de faible à moyenne fréquence) : utilisez la Protection CC ou des règles personnalisées de limitation de débit.
- Pour les attaques DDoS au niveau réseau (haute fréquence, volume élevé) : utilisez les produits Anti-DDoS.
- Pour les scripts automatisés ou les attaques de bots : utilisez la Gestion des bots.
- Pour les attaques présentant des caractéristiques spécifiques (telles qu'un User-Agent ou un chemin d'URL fixe) : utilisez des règles personnalisées.
- Pour les attaques provenant d'une adresse IP source fixe : utilisez une liste de blocage IP.
- Pour les attaques provenant de régions ou de pays non commerciaux : utilisez le Blocage par région.
- Pour les attaques ciblant les API : utilisez la Sécurité des API.

Maintenance courante

Afficher un modèle de protection : cliquez sur l'icône à gauche du nom d'un modèle pour afficher les informations du moteur qu'il contient.
Activer ou désactiver un modèle de protection : utilisez le commutateur Match Condition pour activer ou désactiver un modèle.
Modifier un modèle de protection : cliquez sur Status dans la colonne Edit d'un modèle pour modifier ses Actions, sa Template Information ou son paramètre Engine Configuration.
Supprimer un modèle de protection : lorsqu'un modèle n'est plus nécessaire, cliquez sur Apply To dans sa colonne Delete, puis sur Actions dans la boîte de dialogue de confirmation.
Important
- Si un modèle de protection personnalisé est supprimé, tout objet protégé qui lui était associé s'ajoute automatiquement au modèle de protection par défaut.
- Si le modèle de protection par défaut est supprimé alors qu'il contient encore des objets protégés, ces objets ne seront plus protégés par les règles de protection essentielles.

Modules de détection pris en charge

Les règles de protection essentielles prennent en charge les modules de détection suivants, qui peuvent identifier et bloquer divers types d'attaques contre les applications web.

Type d'attaque

Description

Delete

Une attaque par injection SQL consiste à injecter du code SQL malveillant dans une requête afin d'exécuter des commandes de base de données non intentionnelles.

SQL Injection

Une attaque par cross-site scripting (XSS) consiste à intégrer des scripts malveillants dans une page web, provoquant leur exécution lorsque d'autres utilisateurs consultent la page.

XSS

Les attaques par exécution de code utilisent du code malveillant injecté qui est exécuté par le serveur pour atteindre les objectifs de l'attaquant.

Code Execution

Une attaque par injection CRLF consiste à insérer un retour chariot (CR, \r) et un saut de ligne (LF, \n) dans un en-tête HTTP afin de manipuler les réponses HTTP ou d'effectuer une division de réponse HTTP.

CRLF Injection

Si l'option allow_url_include est activée sur un serveur, un attaquant peut exploiter des fonctions PHP telles que include(), require(), include_once() et require_once() pour inclure dynamiquement des fichiers via une URL. Si la source du fichier n'est pas strictement validée, cela peut entraîner la lecture arbitraire de fichiers ou l'exécution de commandes.

Local File Inclusion

Une attaque par inclusion de fichier distant (RFI) inclut un fichier provenant d'un serveur distant, permettant à un attaquant d'exécuter du code malveillant sur le serveur local.

Remote File Inclusion

Un webshell est un fichier de script malveillant qui, une fois téléchargé ou injecté, permet à un attaquant de contrôler le serveur à distance.

Webshell

Une attaque par injection de commande OS consiste à intégrer des commandes de système d'exploitation malveillantes dans un programme, amenant le serveur à les exécuter.

OS Command Injection

Cela fait référence au comportement et aux caractéristiques des scanners d'applications web. Ces outils analysent automatiquement les applications web pour trouver des vulnérabilités de sécurité potentielles, telles que l'injection SQL et le XSS, en générant et en envoyant un grand nombre de requêtes pour analyser les réponses de l'application.

Scanning Behavior

Les failles de logique métier sont des vulnérabilités dans la mise en œuvre des processus métier d'une application. Ces failles ne sont souvent pas évitables par la validation traditionnelle des entrées et l'encodage des sorties. Elles peuvent permettre à un attaquant de manipuler le flux de travail normal de l'application pour obtenir un accès non autorisé ou effectuer d'autres actions malveillantes.

Logic Defect

Une vulnérabilité de lecture arbitraire de fichiers permet à un attaquant de lire n'importe quel fichier sur le système, généralement via un paramètre de chemin de fichier dans une requête HTTP. En exploitant cette vulnérabilité, un attaquant peut accéder à des informations sensibles telles que des fichiers de configuration, des identifiants et des données personnelles.

Arbitrary File Read

Une vulnérabilité de téléchargement arbitraire de fichiers est similaire à la lecture arbitraire de fichiers, mais permet à un attaquant de télécharger n'importe quel fichier du système. Cela peut entraîner une fuite d'informations sensibles et permettre même à un attaquant d'obtenir une sauvegarde complète du système pour une analyse hors ligne.

Arbitrary File Download

Une vulnérabilité XXE exploite la manière dont les analyseurs XML traitent les entités externes, permettant à un attaquant de lire des fichiers système, d'exécuter des requêtes côté serveur (SSRF) ou de provoquer un déni de service (DoS). Cette attaque est généralement réalisée via une entrée XML contenant une entité externe malveillante.

XXE Injection

Une attaque CSRF incite un utilisateur authentifié à envoyer une requête non autorisée à une application web. Généralement, l'attaquant persuade l'utilisateur de cliquer sur un lien malveillant ou de visiter une page malveillante, qui exécute ensuite une action au nom de l'utilisateur, telle que la modification d'un paramètre ou la soumission d'un formulaire.

Cross-site Request Forgery

Une attaque par injection d'expression consiste à intégrer une expression malveillante qui est exécutée par le serveur.

Expression Injection

La désérialisation est le processus de conversion des données d'un format (tel que JSON, XML ou binaire) en objet. Dans les applications .NET, une désérialisation non sécurisée peut entraîner l'exécution de code arbitraire. Si un attaquant peut contrôler les données désérialisées, il peut injecter des données malveillantes et exécuter du code arbitraire.

.NET Deserialization

Une attaque par désérialisation Java consiste à désérialiser un objet malveillant, amenant le serveur à exécuter du code malveillant lors du processus.

Java Deserialization

Une attaque par désérialisation PHP consiste à désérialiser un objet malveillant, amenant le serveur à exécuter du code malveillant lors du processus.

PHP Deserialization

Une attaque par Server-Side Request Forgery (SSRF) forge une requête côté serveur, amenant le serveur à accéder à des ressources internes ou externes.

SSRF

Une attaque par path traversal consiste à injecter des séquences de chemin relatif (telles que ../) pour accéder à des fichiers sur le serveur qui ne devraient pas être accessibles publiquement.

Path Traversal

La violation de protocole consiste à manipuler malicieusement des protocoles (tels que HTTP ou HTTPS) pour lancer une attaque ou contourner des mécanismes de sécurité.

Protocol Non-compliance

Une attaque par téléchargement arbitraire de fichiers consiste à télécharger un fichier malveillant qui est ensuite exécuté par le serveur.

Web Application Firewall:Web core protection rules