Ajuster les règles WAF préconfigurées de Google Cloud Armor

Google Cloud Armor propose des règles WAF préconfigurées, chacune étant composée de plusieurssignatures provenant de l'ensemble de règles de base ModSecurity (CRS). Chaque signature correspond à une règle de détection d'attaques dans l'ensemble de règles. Les requêtes entrantes sont évaluées par rapport aux règles WAF préconfigurées. Une requête correspond à une règle WAF préconfigurée si elle correspond à l'une des signatures associées à la règle WAF préconfigurée. Une correspondance est établie lorsque l'expression evaluatePreconfiguredWaf() ou evaluatePreconfiguredExpr() renvoie la valeur true.

Sélectionner un niveau de sensibilité

Chaque signature a un niveau de sensibilité qui correspond à un niveau de paranoïa ModSecurity. Vous pouvez sélectionner une sensibilité comprise entre 0 et 4, bien que le niveau de sensibilité 0 signifie qu'aucune règle n'est activée par défaut.

Un niveau de sensibilité inférieur indique des signatures de confiance plus élevées, qui sont moins susceptibles de générer un faux positif. Un niveau de sensibilité plus élevé augmente la sécurité, mais augmente également le risque de générer un faux positif. Lorsque vous sélectionnez un niveau de sensibilité pour votre règle WAF, vous activez des signatures aux niveaux de sensibilité inférieurs ou égaux au niveau de sensibilité sélectionné. Dans l'exemple suivant, vous ajustez une règle WAF préconfigurée en sélectionnant le niveau de sensibilité 1:

evaluatePreconfiguredWaf('sqli-v33-stable', {'sensitivity': 1})

Désactiver les signatures de règles

Si vous décidez qu'une règle WAF préconfigurée correspond à plus de trafic que nécessaire ou si la règle bloque le trafic qui doit être autorisé, la règle peut être ajustée afin de désactiver les signatures bruyantes ou autrement inutiles. Pour désactiver des signatures dans une règle WAF préconfigurée particulière, fournissez une liste d'ID des signatures indésirables à la commande evaluatePreconfiguredWaf().

L'exemple suivant exclut deux ID de règle CRS de la règle WAF sqli-v33-stable (CRS 3.3) préconfigurée :

evaluatePreconfiguredWaf('sqli-v33-stable', {'sensitivity': 4, 'opt_out_rule_ids': ['owasp-crs-v030301-id942350-sqli', 'owasp-crs-v030301-id942360-sqli']})

Lorsque vous excluez des ID de signature d'ensembles de règles CRS préconfigurées, vous devez faire correspondre la version de l'ID de signature à la version de l'ensemble de règles (CRS 3.0 ou 3.3) pour éviter les erreurs de configuration.

Vous pouvez également désactiver les ID de signature à l'aide de l'ancienne expression evaluatePreconfigureExpr(). Pour en savoir plus sur les expressions de règle WAF préconfigurées, consultez la documentation de référence sur le langage des règles personnalisées.

Activer les signatures de règles

Au lieu de désactiver les signatures de règle, vous pouvez activer les signatures de règle dans les niveaux de sensibilité désactivés. Nous vous recommandons d'activer les signatures de règle lorsque vous souhaitez utiliser moins de signatures dans un niveau de sensibilité donné qu'il existe de règles que vous souhaitez désactiver. Pour activer les signatures de règle, le niveau de sensibilité doit être 0. L'exemple suivant désactive toutes les signatures cve-canary à tous les niveaux de sensibilité, puis active explicitement owasp-crs-v030001-id044228-cve et owasp-crs-v030001-id144228-cve:

evaluatePreconfiguredWaf('cve-canary', {'sensitivity': 0, 'opt_in_rule_ids': ['owasp-crs-v030001-id044228-cve', 'owasp-crs-v030001-id144228-cve']})

Exclure des champs de requête de l'inspection

Votre application personnalisée peut inclure du contenu dans des champs de requête (tels que des en-têtes, des cookies, des paramètres de requête ou des URI) qui correspondent aux signatures dans les règles WAF préconfigurées, mais qui sont légitimes. Dans ce cas, vous pouvez réduire les faux positifs en excluant ces champs de requête de l'inspection en associant une liste d'exclusions de champs de requête à la règle de stratégie de sécurité.

Lorsque vous configurez une exclusion de champ de requête, vous l'associez à une cible, qui peut être une règle WAF préconfigurée ou une liste de signatures sous une règle WAF préconfigurée. Vous pouvez spécifier une correspondance exacte ou partielle à l'aide d'un opérateur de champ et d'une valeur de champ. Les opérateurs de champ disponibles sont les suivants:

  • EQUALS: l'opérateur correspond si la valeur du champ est égale à la valeur spécifiée.
  • STARTS_WITH: l'opérateur correspond si la valeur du champ commence par la valeur spécifiée.
  • ENDS_WITH: l'opérateur correspond si la valeur du champ se termine par la valeur spécifiée.
  • CONTAINS: l'opérateur correspond si la valeur du champ contient la valeur spécifiée.
  • EQUALS_ANY: l'opérateur correspond si la valeur du champ est une valeur.

Les sections suivantes fournissent des informations supplémentaires sur les champs de requête que vous pouvez exclure de l'inspection, suivies d'exemples.

En-têtes de requête

Une liste de noms d'en-tête de requête dont la valeur est exclue de l'inspection lors de l'évaluation de la règle WAF préconfigurée

L'exclusion n'est applicable qu'aux signatures de la cible qui auraient inspecté la valeur d'en-tête de requête à l'origine. Cela inclut les signatures associées à l'option de requête suivante dans l'ensemble de règles de base ModSecurity:

  • REQUEST_HEADERS

Seule la valeur des en-têtes de requête spécifiés est exclue de l'inspection. Le nom est toujours inspecté.

Cookies de requête

Une liste de noms de cookies de requête dont la valeur est exclue de l'inspection lors de l'évaluation de la règle WAF préconfigurée

L'exclusion n'est applicable qu'aux signatures de la cible qui auraient inspecté la valeur du cookie de requête à l'origine. Cela inclut les signatures associées à l'indicateur de requête suivant dans l'ensemble de règles de base ModSecurity:

  • REQUEST_COOKIES

Seule la valeur des cookies de requête spécifiés est exclue de l'inspection. Le nom est toujours inspecté.

Paramètres de requête de la requête

Liste de noms de paramètres de requête dont la valeur est exclue de l'inspection lors de l'évaluation de la règle WAF préconfigurée.

L'exclusion n'est applicable qu'aux signatures de la cible qui auraient inspecté les paramètres de requête à l'origine. Cela inclut les signatures associées aux options de requête suivantes dans l'ensemble de règles de base ModSecurity:

  • ARGS
  • ARGS_GET
  • REQUEST_URI
  • REQUEST_URI_RAW
  • REQUEST_LINE

Seule la valeur des paramètres de requête spécifiés est exclue de l'inspection, qui peut se trouver dans la chaîne de requête ou le corps du message POST. Le nom est toujours inspecté.

Étant donné que les paramètres de requête font partie de l'URI et de la ligne de requête, ces champs sont réassemblés pour l'inspection après avoir exclu les paramètres de requête spécifiés. Cependant, pour les signatures qui inspectent l'intégralité du corps de la requête (comme les signatures associées à l'option de requête REQUEST_BODY), l'exclusion des paramètres de requête n'est pas appliquée.

Par exemple, si vous excluez un paramètre de requête nommé "args", vous verrez peut-être une correspondance sur une signature qui inspecte l'intégralité du corps de la requête si celle-ci comporte un paramètre "args" dans le corps POST et si la valeur de "args" a une correspondance.

URI de la requête

Liste des URI de la ligne de requête, excluant les données de la chaîne de requête à exclure de l'inspection lors de l'évaluation de la règle WAF préconfigurée.

L'exclusion n'est applicable qu'aux signatures de la cible qui auraient inspecter l'URI de la requête à l'origine. Cela inclut les signatures associées aux options de requête suivantes dans l'ensemble de règles de base ModSecurity:

  • REQUEST_URI
  • REQUEST_URI_RAW
  • REQUEST_LINE
  • REQUEST_FILENAME
  • REQUEST_BASENAME

Lorsque vous excluez l'un des champs ci-dessus, le champ est entièrement exclu de l'inspection et aucun ré-assemblage n'est effectué.

Valeurs des champs

Vous devez spécifier une valeur de champ si vous utilisez un opérateur de champ autre que EQUALS_ANY.

Pour les en-têtes de requête, les cookies de requête et les paramètres de requête de requête, le jeu de caractères autorisé pour les valeurs de champ comprend les caractères suivants:

  • !, #, $, %, &, *, +, -, ., ^, _, `, |, ~
  • Caractères alphanumériques de A à Z (en minuscules et en majuscules)
  • Caractères numériques : 0 à 9

Lorsque vous appliquez des exclusions pour ces champs de requête, les valeurs de champ configurées sont comparées aux valeurs (non sensibles à la casse, après la transformation) de la requête. Vous ne devez pas effectuer d'encodage supplémentaire si vous souhaitez exclure un caractère spécifique qui ne figure pas dans le jeu de caractères autorisé.

Pour les URI de requête, la valeur du champ doit être indiquée au format suivant:

  • Un schéma est autorisé, mais il est limité à http ou https uniquement.
  • Un hôte est autorisé, et il peut s'agir d'une adresse IP.
  • Un port est autorisé.
  • Un chemin d'accès est autorisé.
  • Une requête n'est pas autorisée.
  • Un fragment n'est pas autorisé.

Lors de l'application d'exclusions pour des URI de requête, les valeurs de champ configurées sont comparées aux URI (non sensibles à la casse, après transformation) de la ligne de requête, à l'exception de la chaîne de requête. Les URI de la ligne de requête peuvent être relatifs ou absolus. Tenez-en compte lorsque vous configurez des exclusions d'URI de requête.

Examples

Le premier exemple met à jour la règle dans la stratégie de sécurité POLICY_1 à PRIORITY pour ajouter une configuration d'exclusion pour toutes les signatures sous la règle WAF sqli-v33-stable, afin d'exclure tous les cookies de requête de l'inspection:

gcloud compute security-policies rules add-preconfig-waf-exclusion PRIORITY \
    --security-policy POLICY_1 \
    --target-rule-set "sqli-v33-stable" \
    --request-cookie-to-exclude "op=EQUALS_ANY"

Le deuxième exemple met à jour la règle dans la stratégie de sécurité POLICY_2 à PRIORITY pour ajouter une configuration d'exclusion pour les signatures owasp-crs-v030301-id941140-xss et owasp-crs-v030301-id941270-xss sous la règle WAF xss-v33-stable, pour exclure les en-têtes de requête commençant par abc ou se terminant par xyz de l'inspection:

gcloud compute security-policies rules add-preconfig-waf-exclusion PRIORITY \
    --security-policy POLICY_2 \
    --target-rule-set "xss-v33-stable" \
    --target-rule-ids "owasp-crs-v030301-id941140-xss" "owasp-crs-v030301-id941270-xss" \
    --request-header-to-exclude "op=STARTS_WITH,val=abc" \
    --request-header-to-exclude "op=ENDS_WITH,val=xyz"

Le troisième exemple met à jour la règle dans la stratégie de sécurité POLICY_3 à PRIORITY pour supprimer toutes les exclusions de champs de requête pour les ID de règle owasp-crs-v030301-id942110-sqli et owasp-crs-v030301-id942120-sqli sous sqli-v33-stable.

gcloud compute security-policies rules remove-preconfig-waf-exclusion PRIORITY \
    --security-policy POLICY_3 \
    --target-rule-set "sqli-v33-stable" \
    --target-rule-ids "owasp-crs-v030301-id942110-sqli,owasp-crs-v030301-id942120-sqli"

Appliquer l'analyse aux valeurs d'en-tête Content-Type personnalisées

Lorsque Google Cloud Armor évalue le corps POST par rapport à des règles WAF préconfigurées, l'en-tête Content-Type indique le format des données dans le corps de la requête. Par défaut, Google Cloud Armor traite le contenu du corps POST comme une seule chaîne, qui peut toutes être inspectée et mise en correspondance selon vos règles WAF préconfigurées. Toutefois, vous pouvez configurer une analyse plus précise si vos requêtes entrantes ont un encodage différent. Google Cloud Armor est compatible avec les types d'encodage suivants:

  • JSON
  • GraphQL

Pour configurer la liste des valeurs d'en-tête Content-Type personnalisées pour lesquelles une analyse alternative est appliquée, utilisez l'exemple suivant. L'exemple met à jour la stratégie de sécurité POLICY_NAME pour activer l'analyse JSON et spécifie les types de contenu application/json, application/vnd.api+json, application/vnd.collection+json et application/vnd.hyper+json:

gcloud compute security-policies update POLICY_NAME \
    --json-parsing STANDARD \
    --json-custom-content-types "application/json,application/vnd.api+json,application/vnd.collection+json,application/vnd.hyper+json"

Si votre stratégie de sécurité protège une application qui utilise GraphQL ou reçoit du contenu encodé au format GraphQL, vous pouvez utiliser l'argument STANDARD_WITH_GRAPHQL pour analyser le contenu du corps POST en tant que contenu GraphQL, comme dans l'exemple suivant:

gcloud compute security-policies update POLICY_NAME \
    --json-parsing STANDARD_WITH_GRAPHQL

L'inspection du corps POST est limitée aux 8 premiers Ko. Pour en savoir plus, consultez la section Limites des stratégies de sécurité.

  • Si le contenu JSON fait plus de 8 Ko, Google Cloud Armor applique l'analyse JSON aux 8 premiers Ko de contenu utilisés qui sont inspectés par des règles WAF préconfigurées.

  • Si l'analyseur JSON ne renvoie aucun résultat, vous pouvez tenter d'analyser l'URI. Si l'analyseur d'URI ne renvoie aucun paramètre nom-valeur ou uniquement des paramètres nom-valeur partiels, la chaîne entière ou partielle peut être traitée comme nom de paramètre pour l'inspection.

Étapes suivantes