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

S’applique à : ✔️ Application Gateway V2

Le Azure Application Gateway Web Application Firewall (WAF) v2 inclut un ensemble de règles préconfiguré géré par la plateforme qui protège contre de nombreux types d’attaques différents. Ces attaques incluent l’écriture de scripts intersites, l’injection SQL et d’autres. 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 journaliser le trafic demandé en fonction des critères correspondants. Si vous définissez la stratégie WAF sur le mode de détection et qu’une règle de bloc personnalisée se déclenche, la requête est journalisée et aucune action de blocage n’est effectuée.

Utilisez des règles personnalisées pour créer vos propres règles évaluées par le WAF pour chaque requête. Ces règles ont une priorité plus élevée que le reste des règles dans les ensembles de règles managé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, le WAF prend une action pour autoriser, bloquer ou enregistrer. Si une règle personnalisée se déclenche et que le WAF effectue une action d’autorisation ou de blocage, le WAF n’effectue aucune autre action à partir de règles personnalisées ou gérées. En cas de règle personnalisée déclenchant une action d’autorisation ou de bloc, vous pouvez toujours voir certains événements de journal pour les correspondances de règles à partir de l’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é. Vous pouvez activer ou désactiver des règles personnalisé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ésactivé 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 souhaitez utiliser ou entre deux conditions différentes, les deux conditions doivent être 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 règles personnalisées prennent également en charge les expressions régulières, 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.

Autoriser et bloquer

Vous pouvez facilement autoriser ou bloquer le trafic à l’aide de règles personnalisées. Par exemple, vous pouvez bloquer tout le trafic à partir d’une plage d’adresses IP. Vous pouvez créer une autre règle pour autoriser le trafic si la requête provient d’un navigateur spécifique.

Pour autoriser un élément, définissez le -Action paramètre sur Autoriser. Pour bloquer un élément, définissez le -Action paramètre 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 ou 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 ou plage de la connexion à 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 qui utilisent cette variable de correspondance s’appliquent uniquement si l’en-tête « Content-Type » est défini sur « application/x-www-form-urlencoded » ou « multipart/form-data ». CRS version 3.2 ou ultérieure prend en charge un type de contenu supplémentaire de application/json, ainsi que l'ensemble de règles de protection des bots et les règles personnalisées de correspondance géographique.
• 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 qui utilisent cette variable de correspondance s’appliquent uniquement si l’en-tête « Content-Type » est défini sur application/x-www-form-urlencoded le type de média. CRS version 3.2 ou ultérieure prend en charge des types de contenu supplémentaires de application/soap+xml, application/xml, text/xml, ainsi que des règles de protection des bots et des règles personnalisées de géolocalisation.
• 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]

Utilisez l’un des opérateurs suivants :

• IPMatch - Utilisez uniquement lorsque la variable de correspondance est RemoteAddr et qu’elle prend uniquement en charge IPv4.
• Equal - Utilisez quand l’entrée est identique à MatchValue.
• Any - Utiliser lorsqu’il n’y a pas de MatchValue. Il est recommandé pour la variable de correspondance avec un sélecteur valide.
• Contains - Utiliser quand MatchValue est une valeur explicite uniquement. Les caractères génériques et les expressions régulières ne sont pas pris en charge.
• LessThan
• GreaterThan
• LessThanOrEqual
• GreaterThanOrEqual
• BeginsWith
• EndsWith
• Regex
• Geomatch

Negate condition [facultatif]

Annule la condition actuelle.

Transform [facultatif]

Liste de valeurs de chaîne qui spécifient des transformations à appliquer avant d’essayer une correspondance. Les transformations disponibles sont les suivantes :

• Minuscules
• Majuscules
• SupprEspace
• UrlDecode (décodage d'URL)
• UrlEncode
• RemoveNulls
• HtmlEntityDecode

Match values [obligatoire]

Liste de valeurs à mettre en correspondance, que vous pouvez considérer comme étant reliées par un OU. Par exemple, la liste peut contenir des 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 :

• OBTENIR
• EN-TÊTE
• PUBLIER
• OPTIONS
• PUT
• Supprimer
• 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 journalise la transaction en fonction de SecDefaultAction (mode de détection ou de prévention). - Mode prévention : bloque la transaction basée sur SecDefaultAction. Tout comme l’action, une fois la Allow requête évaluée et ajoutée à la liste de blocs, l’évaluation s’arrête et la demande 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 : journalise la transaction basée sur SecDefaultAction après laquelle l’évaluation s’arrête. Toute demande qui remplit les mêmes conditions n’est pas évaluée et est enregistré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

Vous pouvez dupliquer des règles personnalisées dans une stratégie donnée. Lorsque vous dupliquez une règle, vous devez spécifier un nom unique pour la règle et une valeur de priorité unique. En outre, vous pouvez copier des règles personnalisé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 ou région. Pour plus d’informations, voir Règles personnalisées de géocorrespondance.

Étape suivante