Règles personnalisées du pare-feu d’applications web v2 sur Azure Application Gateway

Article
01/30/2024

Le pare-feu d’applications web (WAF) Azure Application Gateway v2 est fourni avec un ensemble de règles préconfigurées, géré par la plateforme, qui offre une protection contre de nombreux types d’attaques. Ces attaques comprennent l’exécution de scripts de site à site, l’injection de code SQL etc. Si vous êtes administrateur de pare-feu d’applications web, nous vous recommandons d’écrire vos propres règles pour augmenter les règles de l’ensemble de règles de base (CRS). Vos règles personnalisées peuvent bloquer, autoriser ou consigner le trafic demandé en fonction de critères de correspondance. Si la stratégie WAF est définie sur le mode de détection et qu’une règle de bloc personnalisée est déclenchée, la requête est consignée et aucune action de blocage n’est effectuée.

Les règles personnalisées vous permettent de créer vos propres règles évaluées pour chaque requête passant par le pare-feu d’applications Web (WAF). Ces règles ont une priorité plus élevée que les autres règles des ensembles de règles gérés. Les règles personnalisées contiennent un nom de règle, une priorité de règle et un tableau des conditions de correspondance. Si ces conditions sont remplies, une action est entreprise (pour autoriser, bloquer ou consigner). Si une règle personnalisée est déclenchée et qu’une action d’autorisation ou de blocage est effectuée, aucune autre action d’une règle personnalisée ou gérée n’est effectuée. En cas de règle personnalisée déclenchant une action d’autorisation ou de blocage, vous pouvez toujours voir certains événements de journal pour les correspondances de règles à partir d’un ensemble de règles configuré (ensemble de règles de base/ensemble de règles par défaut) mais ces règles ne sont pas appliquées. Les événements de journal s’affichent simplement en raison de l’optimisation appliquée par le moteur WAF pour le traitement des règles parallèles et peuvent être ignorés en toute sécurité. Les règles personnalisées peuvent être activées/désactivées à la demande.

Par exemple, vous pouvez bloquer toutes les demandes à partir d’une adresse IP de la plage 192.168.5.0/24. Dans cette règle, l’opérateur est IPMatch, matchValues correspond à la plage d’adresses IP (192.168.5.0/24) et l’action consiste à bloquer le trafic. Vous définissez également le nom, la priorité et l’état d’activation de la règle.

Les règles personnalisées prennent en charge l’utilisation de la logique de composition pour établir des règles plus avancées répondant à vos besoins de sécurité. Par exemple, vous pouvez utiliser deux règles personnalisées pour créer la logique suivante ((rule1:Condition 1 et rule1:Condition 2) ou rule2:Condition 3). Cet exemple signifie que si Condition 1 et Condition 2 sont remplies, ou si Condition 3 est remplie, le pare-feu d’applications web doit effectuer l’action spécifiée dans la règle personnalisée.

Différentes conditions de correspondance au sein de la même règle sont toujours composées à l’aide de et. Par exemple, bloquer le trafic à partir d’une adresse IP spécifique, et seulement si un certain navigateur est utilisé.

Si vous voulez utiliser or entre deux conditions différentes, ces conditions doivent se trouver dans des règles différentes. Par exemple, bloquer le trafic à partir d’une adresse IP spécifique, ou seulement si un certain navigateur est utilisé.

Les expressions régulières sont également prises en charge dans les règles personnalisées, comme dans les ensembles de règles CRS. Pour plus de détails, voir les exemples 3 et 5 dans Créer et utiliser des règles de pare-feu d’applications web personnalisées.

Remarque

Le nombre maximal de règles personnalisées WAF est de 100. Pour en savoir plus sur les limites de la passerelle Application Gateway, consultez Limites, quotas et contraintes applicables aux services et abonnements Azure.

Attention

Les règles de redirection appliquées au niveau de la passerelle applicative ignorent les règles personnalisées WAF. Pour plus d’informations sur les règles de redirection, consultez Vue d’ensemble de la redirection Application Gateway.

Autoriser et bloquer

Autoriser et bloquer le trafic est simple avec des règles personnalisées. Par exemple, vous pouvez bloquer tout le trafic entrant à partir d’une plage d’adresses IP. Vous pouvez créer une autre règle autorisant le trafic si la requête provient d’un navigateur spécifique.

Pour autoriser quelque chose, vérifiez que le paramètre -Action est défini sur Autoriser. Pour bloquer quelque chose, vérifiez que le paramètre -Action est défini sur Bloquer.

$AllowRule = New-AzApplicationGatewayFirewallCustomRule `
   -Name example1 `
   -Priority 2 `
   -RuleType MatchRule `
   -MatchCondition $condition `
   -Action Allow `
   -State Enabled

$BlockRule = New-AzApplicationGatewayFirewallCustomRule `
   -Name example2 `
   -Priority 2 `
   -RuleType MatchRule `
   -MatchCondition $condition `
   -Action Block `
   -State Enabled

Le $BlockRule précédent est mis en correspondance avec la règle personnalisée suivante dans Azure Resource Manager :

"customRules": [
      {
        "name": "blockEvilBot",
        "priority": 2,
        "ruleType": "MatchRule",
        "action": "Block",
        "state": "Enabled",
        "matchConditions": [
          {
            "matchVariables": [
              {
                "variableName": "RequestHeaders",
                "selector": "User-Agent"
              }
            ],
            "operator": "Contains",
            "negationCondition": false,
            "matchValues": [
              "evilbot"
            ],
            "transforms": [
              "Lowercase"
            ]
          }
        ]
      }
    ],

Cette règle personnalisée contient un nom, une priorité, une action et le tableau des conditions de correspondance qui doivent être remplies pour que l’action puisse être effectuée. Pour en savoir plus sur ces champs, consultez les descriptions suivantes. Pour voir des exemples de règles personnalisées, consultez Créer et utiliser des règles de pare-feu d’applications web personnalisées.

Champs de règles personnalisées

Name [facultatif]

nom de la règle. Il apparaît dans les journaux.

Activer la règle [facultatif]

Activez/désactivez cette règle. Les règles personnalisées sont activées par défaut.

Priorité [requise]

Détermine l’ordre d’évaluation de la règle. Plus la valeur est faible, plus l’évaluation de la règle est récente. La plage autorisée est comprise entre 1 et 100.
Doit être unique parmi toutes les règles personnalisées. Une règle dont la priorité est égale à 40 est évaluée avant une règle dont la priorité est égale à 80.

Type de règle [obligatoire]

Actuellement, ce doit être MatchRule.

Variable de correspondance [obligatoire]

Doit être l’une des variables suivantes :

RemoteAddr - Adresse IPv4/Portée de la connexion de l’ordinateur distant
RequestMethod – Méthode de requête HTTP
Chaîne de requête - Variable de l’URI
PostArgs – Arguments envoyés dans le corps POST. Les règles personnalisées utilisant cette variable de correspondance ne sont appliquées que si l’en-tête « Content-Type » est défini sur « application/x-www-form-urlencoded » et « multipart/form-data ». Le type de contenu supplémentaire de application/json est pris en charge avec CRS version 3.2 ou ultérieure, l’ensemble de règles de protection des bots et les règles personnalisées de géocorrespondance.
RequestUri - URI de la requête
RequestHeaders - En-têtes de la requête
RequestBody : cette variable contient le corps de la requête en tant que tout. Les règles personnalisées utilisant cette variable de correspondance sont appliquées seulement si l’en-tête « Content-Type » est défini sur le type de média application/x-www-form-urlencoded. Les types de contenu supplémentaires de application/soap+xml, application/xml, text/xml sont pris en charge avec CRS version 3.2 ou ultérieure, l’ensemble de règles de protection des bots et les règles personnalisées de géocorrespondance.
RequestCookies - Cookies de la requête

Sélecteur [facultatif]

Décrit le champ de la collection matchVariable. Par exemple, si matchVariable est RequestHeaders, le sélecteur peut être sur l’en-tête User-Agent.

Opérateur [obligatoire]

Il doit s’agir de l’un des opérateurs suivants :

IPMatch - Utilisé uniquement quand la variable de correspondance est RemoteAddr et prend uniquement en charge IPv4
Equal : indique que la saisie est identique à MatchValue
Any – Ne doit pas comporter de MatchValue. Il est recommandé pour la variable de correspondance avec un sélecteur valide.
Contient
LessThan
GreaterThan
LessThanOrEqual
GreaterThanOrEqual
BeginsWith
EndsWith
Expression régulière
Geomatch

Negate condition [facultatif]

Annule la condition actuelle.

Transform [facultatif]

Liste de chaînes avec les noms des transformations à effectuer avant la tentative de la mise en correspondance. Il peut s’agir des transformations suivantes :

Minuscules
Majuscules
SupprEspace
UrlDecode
UrlEncode
RemoveNulls
HtmlEntityDecode

Match values [obligatoire]

Liste des valeurs selon lesquelles effectuer la mise en correspondance, ce qui peut être considéré comme étant soumis à l’opérateur OR. Par exemple, il peut s’agir d’adresses IP ou d’autres chaînes. Le format de la valeur dépend de l’opérateur précédent.

Les valeurs de la méthode de requête HTTP prises en charge incluent :

GET
HEAD
POST
OPTIONS
PUT
DELETE
PATCH

Action [obligatoire]

En mode de détection de stratégie WAF, si une règle personnalisée est déclenchée, l’action est toujours consignée indépendamment de la valeur d’action définie sur la règle personnalisée.

Autoriser - Autorise la transaction, en ignorant toutes les autres règles. La demande spécifiée est ajoutée à la liste d’autorisation et une fois qu’elle a trouvé une correspondance, elle interrompt l’évaluation et est envoyée au pool back-end. Les règles qui se trouvent dans la liste d’autorisation ne sont pas évaluées par rapport à d’autres règles personnalisées ou managées.
Bloquer - Bloque ou consigne la transaction selon SecDefaultAction (mode de détection/prévention).
- Mode de prévention - Bloque la transaction selon SecDefaultAction. Tout comme l’action Allow, une fois que la requête est évaluée et ajoutée à la liste de refus, l’évaluation est interrompue et la requête est bloquée. Toute requête subséquente répondant aux mêmes conditions n’est pas évaluée et est bloquée.
- Mode de détection - Consigne la transaction selon SecDefaultAction après quoi l’évaluation est arrêtée. Toute requête subséquente répondant aux mêmes conditions n’est pas évaluée et est simplement consignée.
Journal - Autorise la règle à écrire dans le journal, mais autorise l’exécution du reste des règles pour évaluation. Les autres règles personnalisées consécutives sont évaluées par ordre de priorité, suivies des règles managées.

Copie et duplication de règles personnalisées

Les règles personnalisées peuvent être dupliquées au sein d’une stratégie donnée. Lors de la duplication d’une règle, vous devez spécifier un nom unique pour la règle et une valeur de priorité unique. En outre, les règles personnalisées peuvent être copiées d’une stratégie WAF Application Gateway vers une autre tant que les stratégies se trouvent dans le même abonnement. Lorsque vous copiez une règle d’une stratégie vers une autre, vous devez sélectionner la stratégie WAF Application Gateway dans laquelle vous souhaitez copier la règle. Une fois que vous avez sélectionné la stratégie WAF, vous devez attribuer un nom unique à la règle et attribuer un rang de priorité.

Règles personnalisées Geomatch

Vous pouvez créer des règles personnalisées pour répondre aux besoins exacts de vos applications et stratégies de sécurité. Vous pouvez restreindre l’accès à vos applications web par pays/région. Pour plus d’informations, voir Règles personnalisées de géocorrespondance.

Partager via