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é. Notez que si une exclusion de champ de requête est associée à une règle WAF, vous ne pouvez pas utiliser l'action allow
.
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
Liste des 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
Liste des 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 des noms de paramètres de requê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é 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 demande
Liste des URI de la ligne de requête à l'exclusion des 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, l'ensemble de caractères autorisé pour les valeurs de champ inclut les caractères suivants:
!
,#
,$
,%
,&
,*
,+
,-
,.
,^
,_
,`
,|
,~
- Caractères alphanumériques
A
àZ
(majuscules et minuscules) - 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 telles quelles aux valeurs (non sensibles à la casse, après transformation) de la requête. Vous n'êtes pas tenu d'effectuer d'encodage supplémentaire si vous souhaitez exclure un caractère spécifique qui ne figure pas dans l'ensemble de caractères autorisé.
Pour les URI de requête, la valeur du champ doit être indiquée au format URI suivant:
- Un schéma est autorisé, mais il est limité à http ou https uniquement.
- Un hôte est autorisé et peut être une adresse IP.
- Vous pouvez indiquer un port.
- Un chemin d'accès est autorisé.
- Une requête n'est pas autorisée.
- Un fragment n'est pas autorisé.
Lorsque vous appliquez des exclusions pour les URI de requête, les valeurs des champs configurées sont comparées telles quelles aux URI (non sensibles à la casse, après transformation) de la ligne de requête, à l'exclusion de la chaîne de requête. Les URI de la ligne de requête peuvent être relatifs ou absolus. Tenez compte de ce point lorsque vous configurez des exclusions pour les 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 aux règles WAF préconfigurées, l'en-tête Content-Type
indique le format des données du corps de la requête. Par défaut, Google Cloud Armor traite le contenu du corps POST comme une seule chaîne, qui peut être inspectée et mise en correspondance avec 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 accepte les types d'encodage suivants:
- JSON
- GraphQL
Pour en savoir plus, consultez la section Analyse du contenu du corps POST.
Étape suivante
- Découvrez comment configurer des règles de sécurité.
- En savoir plus sur les signatures de règle disponibles pour les règles WAF préconfigurées.
- Pour en savoir plus sur les règles WAF préconfigurées, consultez la documentation de référence sur le langage des règles personnalisées.