À propos des règles personnalisées WAF

Utilisez la fonctionnalité de règles personnalisées WAF pour contrôler le trafic entrant en filtrant les requêtes vers un domaine. Vous pouvez effectuer des actions telles que le blocage ou la contestation gérée des demandes entrantes selon les règles que vous définissez.

Comme les autres règles évaluées par le moteur de règles, les règles personnalisées WAF nécessitent les paramètres de base suivants :

Expression qui spécifie les critères de filtrage du trafic à l'aide du langage de règles.
Action qui spécifie ce qu'il faut faire lorsqu'il y a une correspondance avec la règle.

Les règles personnalisées sont évaluées dans l'ordre où elles sont définies, de la première à la dernière position, dans le tableau des règles personnalisées. Vous pouvez consulter le tableau en accédant à Sécurité > Règles de pare-feu. Certaines actions comme Bloquer arrêtent l'évaluation des autres règles. Pour plus de détails sur les actions et leur comportement, voir Actions de règles du moteur de jeu de règles.

Scénarios d'utilisation courants

Les sections suivantes détaillent des exemples de cas d'utilisation courants pour les règles personnalisées WAF.

N'autoriser que le trafic provenant de pays spécifiés

En utilisant l'action Block, cet exemple bloque les requêtes en fonction de leur code pays en utilisant le champ ip.src.country, ce qui permet de n'autoriser que les requêtes provenant de deux pays : les États-Unis et le Mexique :

(not ip.src.country in {"US" "MX"})

Bloquer les requêtes par réputation IP

La réputation IP est un score allant de 0 (risque nul) à 100 (risque élevé), classant la réputation IP d'un visiteur.

La réputation IP est calculée à partir des données issues du projet Honeypot, des informations externes sur les adresses IP publiques et des renseignements internes sur les menaces provenant des règles gérées et de DDoS.

En utilisant l'action Bloquer, cet exemple bloque les requêtes basées sur les codes pays (format ISO 3166-1 Alpha 2 ↗), provenant d'adresses IP dont le score est supérieur à 0 :

(ip.src.country in {"CN" "TW" "US" "GB"} and cf.threat_score gt 0)

N'autoriser que le trafic en provenance des adresses IP spécifiées

L'action Bloquer restreint l'accès à votre domaine, en autorisant uniquement les requêtes provenant d'adresses IP spécifiées et en refusant toutes les autres.

Par exemple, pour n'autoriser que le trafic en provenance des adresses IP 192.0.2.10 et 203.0.113.25, exécutez l'expression suivante :

(not ip.src in {"192.0.2.10" "203.0.113.25"})

Utilisez l'une des expressions suivantes en fonction du protocole que vous souhaitez restreindre :

Si vous souhaitez spécifier des sous-réseaux au lieu d'adresses IP individuelles, IBM Cloud CIS ne prend en charge que les sous-réseaux :

IPv4: /16 et /24

IPv6: /32, /48, et /64
Pour une couverture complète, il faut toujours inclure les sites IPv4 et IPv6.
Le fait de ne bloquer que IPv4 ( 0.0.0.0/0 ) permet toujours le trafic IPv6. Bloquer les deux :
```
(ip.src in {0.0.0.0/0} or ip.src in {::/0})
```

Configuration d'une règle pour ignorer d'autres fonctionnalités d' CIS

L'action Ignorer prend en charge différentes options d'ignorance, en fonction des fonctions de sécurité ou des produits que vous souhaitez ignorer.

Cette section contient des exemples de différents scénarios de règles de contournement pour les règles personnalisées WAF. Tenez compte des considérations suivantes :

La valeur « {zone_id} » est l'ID de la zone où vous souhaitez ajouter la règle.
La valeur « {ruleset_id} » est l'ID du jeu de règles du point d'entrée de la phase « http_request_firewall_custom ». Pour plus de détails sur l'obtention de cet ID de jeu de règles, voir Liste et affichage des jeux de règles. Les exemples d'API suivants ajoutent une règle de saut à un ensemble de règles existant à l'aide de l'opération de règle Créer un ensemble de règles de zone.

Cependant, il se peut que le jeu de règles du point d'entrée n'existe pas encore. Dans ce cas, utilisez l'opération Update entrypoint ruleset pour créer le jeu de règles de point d'entrée avec une règle de saut.
Bien que chaque exemple ne comporte qu'un seul paramètre d'action, vous pouvez utiliser plusieurs options de saut dans la même règle en spécifiant simultanément les paramètres d'action du jeu de règles, des phases et des produits.

Ignorer les règles restantes de l'ensemble de règles actuel

Cet exemple utilise l'opération de règle Créer un ensemble de règles de zone pour ajouter une règle d'omission à l'ensemble de règles de point d'entrée de phase d' http_request_firewall_custom s existant avec l'ID RULESET_ID. Si vous ne connaissez pas l'ID du jeu de règles de votre point d'entrée, reportez-vous à la section Obtention du point d'entrée des règles personnalisées pour l'API. La règle ignore toutes les règles restantes dans le jeu de règles actuel pour les requêtes qui correspondent à l'expression de la règle :

curl -X POST "https://api.cis.cloud.ibm.com/v1/$CRN/zones/$ZONE_ID/rulesets/$RULESET_ID/rules" \
--header "X-Auth-User-Token: Bearer <API_TOKEN>" \
--header "Content-Type: application/json" \
--data '{
  "action": "skip",
  "action_parameters": {
    "ruleset": "current"
  },
  "expression": "http.request.uri.path contains \"/skip-current-ruleset/\"",
  "description": ""
}'

Sauter une phase

Cet exemple utilise l'ensemble de règles Créer une zone pour ajouter une règle à l'ensemble de règles de point d'entrée de phase d' http_request_firewall_custom s existant avec l'ID RULESET_ID. La règle ignore la phase d' http_ratelimit s pour les requêtes qui correspondent à l'expression de la règle :

curl -X POST "https://api.cis.cloud.ibm.com/v1/$CRN/zones/$ZONE_ID/rulesets/$RULESET_ID/rules" \
--header "X-Auth-User-Token: Bearer <API_TOKEN>" \
--header "Content-Type: application/json" \
--data '{
  "action": "skip",
  "action_parameters": {
    "phases": [
      "http_ratelimit"
    ]
  },
  "expression": "http.request.uri.path contains \"/skip-phase/\"",
  "description": ""
}'

Sauter une phase et ne pas enregistrer les demandes de rapprochement

Cet exemple utilise l'opération de règle Créer un ensemble de règles de zone pour ajouter une règle qui ignore la phase d' http_ratelimit s et désactive la journalisation des événements pour la règle actuelle :

curl -X POST "https://api.cis.cloud.ibm.com/v1/$CRN/zones/$ZONE_ID/rulesets/$RULESET_ID/rules" \
--header "X-Auth-User-Token: Bearer <API_TOKEN>" \
--header "Content-Type: application/json" \
--data '{
  "action": "skip",
  "action_parameters": {
    "phases": [
      "http_ratelimit"
    ]
  },
  "logging": {
    "enabled": false
  },
  "expression": "http.request.uri.path contains \"/disable-logging/\"",
  "description": ""
}'

Ignorer les produits de sécurité

Cet exemple utilise l'opération de règle Créer un jeu de règles de zone pour ajouter une règle qui ignore les produits Zone Lockdown et User Agent Blocking pour les requêtes qui correspondent à l'expression de règle :

curl -X POST "https://api.cis.cloud.ibm.com/v1/$CRN/zones/$ZONE_ID/rulesets/$RULESET_ID/rules" \
--header "X-Auth-User-Token: Bearer <API_TOKEN>" \
--header "Content-Type: application/json" \
--data '{
  "action": "skip",
  "action_parameters": {
    "products": [
      "zoneLockdown",
      "uaBlock"
    ]
  },
  "expression": "http.request.uri.path contains \"/skip-products/\"",
  "description": ""
}'