Amélioration de la réponse pour l'action Bloquer

Dans les règles personnalisées, vous pouvez personnaliser la réponse de l'action Bloquer.

La réponse par défaut du bloc est une page HTML standard ( CIS ). Si vous devez envoyer une réponse personnalisée pour les actions de blocage, configurez la règle personnalisée pour renvoyer une réponse fixe avec un code de réponse personnalisé (403, par défaut) et un corps personnalisé (HTML, JSON, XML ou texte brut).

Pour définir une réponse personnalisée pour une règle unique, accédez à Sécurité > WAF > Règles personnalisées, modifiez la règle personnalisée et complétez les options relatives au blocage.

Les configurations de réponse de bloc personnalisées ne sont pas renvoyées par l'API des règles de pare-feu. Utilisez l'API Rulesets pour gérer cette nouvelle fonctionnalité.

Page d'erreur différente pour les demandes bloquées

Les demandes bloquées par une règle de pare-feu avec une action Bloquer reçoivent une réponse avec le code d'erreur 1020 ( CIS ). Les utilisateurs d' CIS peuvent personnaliser cette page d'erreur dans Pages personnalisées > Erreurs de classe 1000.

Les requêtes bloquées par une règle personnalisée du WAF reçoivent une réponse différente : la réponse de blocage du WAF. Pour personnaliser la réponse par défaut du bloc, vous pouvez soit :

• Définissez une réponse de blocage WAF personnalisée pour l'ensemble de votre zone dans Pages personnalisées > Blocage WAF. Cette page personnalisée aura toujours un type de contenu HTML.
• Définir une réponse personnalisée pour les requêtes bloquées par une règle personnalisée spécifique du WAF. Cette réponse personnalisée prend en charge d'autres types de contenu que le HTML.

Si vous avez personnalisé votre page d'erreur d' 1xxx, dans Pages personnalisées pour les demandes bloquées par les règles de pare-feu, vous devez créer une nouvelle page de réponse pour les demandes bloquées en utilisant l'une des méthodes précédentes.

Nouvelle action Ignorer remplaçant les actions Autoriser et Ignorer

Les règles de pare-feu prenaient en charge les actions Autoriser et Ignorer, souvent utilisées ensemble. Ces actions étaient couramment utilisées pour traiter les demandes légitimes connues, par exemple les demandes provenant d'adresses IP de confiance.

Lorsqu'une demande déclenche l'autorisation, toutes les autres règles de pare-feu ne sont pas évaluées, ce qui permet effectivement à la demande de passer au produit de sécurité suivant. L'action Bypass a été conçue pour spécifier quels produits de sécurité (tels que les règles gérées par le WAF, les règles de limitation de débit et le blocage de l'agent utilisateur) ne doivent pas être exécutés sur la requête qui déclenche l'action.

Avec les règles de pare-feu, si vous souhaitez arrêter l'exécution de tous les produits de sécurité pour une demande donnée, vous devez créer deux règles :

• Une règle avec action de contournement (sélection de tous les produits de sécurité).
• Une règle avec Autoriser l'action (pour arrêter l'exécution des autres règles de pare-feu).

L'exigence d'avoir deux règles pour traiter ce scénario commun ne s'applique plus aux règles personnalisées WAF. Utilisez maintenant l'action Ignorer, qui combine les actions Autoriser et Ignorer. L'action Ignorer remplace entièrement les actions Autoriser et Ignorer, qui ne sont pas prises en charge dans les règles personnalisées WAF.

L'action Ignorer vous permet d'effectuer les opérations suivantes :

• Arrêter d'exécuter toutes les règles personnalisées WAF restantes (équivalentes à l'action Autoriser)
• Éviter d'exécuter d'autres produits de sécurité (équivalent à l'action Bypass)
• Une combinaison des deux.

Vous pouvez également choisir d'ignorer ou non les événements correspondant à la règle personnalisée avec l'action Ignorer. Cela est particulièrement utile lors de la création d'un modèle de sécurité positive pour éviter l'enregistrement de grandes quantités de trafic légitime.

L'API des règles de pare-feu ne prend pas en charge l'action Ignorer. Lorsque vous créez une règle personnalisée avec l'action Ignorer, elle est traduite en Autoriser et Ignorer dans l'API des règles de pare-feu. Utilisez l'API Rulesets pour exploiter pleinement la nouvelle fonctionnalité d'action Ignorer.

Les règles personnalisées sont évaluées dans l'ordre suivant

Les actions des règles de pare-feu avaient un ordre de priorité spécifique lors de l'utilisation de l'ordre de priorité. En revanche, les actions des règles personnalisées WAF n'ont pas cet ordre. Les règles personnalisées sont toujours évaluées dans l'ordre, et certaines actions, telles que Bloquer, arrêtent l'évaluation des autres règles.

Par exemple, si vous utilisez le classement par priorité et que vous avez les règles de pare-feu suivantes avec la même priorité, toutes deux correspondant à une requête entrante :

• Règle de pare-feu n° 1 — Priorité : 2 / Action : Bloquer
• Règle de pare-feu n° 2 — Priorité : 2 / Action : Autoriser

La demande est autorisée car l'action Autoriser dans les règles de pare-feu a priorité sur l'action Bloquer.

En revanche, si vous créez deux règles personnalisées WAF où les deux règles correspondent à une requête entrante :

• Règle personnalisée n° 1 — Action : Bloquer
• Règle personnalisée n° 2 — Action : Ignorer (configurée pour ignorer toutes les règles personnalisées restantes)

La demande est bloquée car les règles personnalisées du WAF sont évaluées dans l'ordre et l'action Bloquer arrête l'évaluation des autres règles.

Pour les règles personnalisées du WAF issues de la conversion de vos règles de pare-feu existantes, CIS conserve l'ordre d'exécution actuel.

Journaux et événements

Les événements enregistrés par les règles personnalisées WAF sont disponibles dans Sécurité > Événements, avec Custom rules comme source. Pour plus d'informations, voir Utilisation de la fonctionnalité Événements de sécurité d' CIS.

Il se peut que vous trouviez encore des événements générés par des règles de pare-feu dans la page Événements de sécurité lorsque vous sélectionnez une période incluant les jours où la transition vers les règles personnalisées WAF a eu lieu. De même, vous pourriez encore trouver des événements avec les actions Ignorer et Autoriser dans la même vue pendant la période de transition.

Nouvelle API

L'API privilégiée pour gérer les règles personnalisées WAF est l'API Rulesets. L'API Rulesets est utilisée sur tous les produits de sécurité récents d' CIS, afin d'offrir une expérience utilisateur uniforme lors de l'interaction avec l'API IBM. Pour plus d'informations sur la migration vers l'API Rulesets, consultez la section Modifications pertinentes pour les utilisateurs de l'API.

L'API des règles de pare-feu et l'API des filtres fonctionneront jusqu'au 30 juillet 2025. Il y aura une seule liste de règles pour les règles de pare-feu et les règles personnalisées, et cette liste contient les règles personnalisées WAF. Grâce à un processus de conversion interne, les API Firewall Rules et Filters renvoient des règles/filtres de pare-feu convertis à partir de ces règles personnalisées WAF.