Créer et utiliser des règles personnalisées du pare-feu d’applications web v2 sur Application Gateway

Le pare-feu d’applications web (WAF) v2 sur Azure Application Gateway fournit une protection pour les applications web. Cette protection est fournie par le jeu de règles (Core Rule Set, CRS) de l’Open Web Application Security Project (OWASP). Dans certains cas, vous devrez peut-être créer vos propres règles personnalisées pour répondre à vos besoins spécifiques. Pour plus d’informations sur les règles de pare-feu d’applications web personnalisées, consultez Vue d’ensemble des règles personnalisées pour un pare-feu d’applications web.

Cet article montre quelques exemples de règles personnalisées que vous pouvez créer et utiliser avec votre pare-feu d’applications web v2. Pour savoir comment déployer un pare-feu d’applications web avec une règle personnalisée à l’aide d’Azure PowerShell, consultez Configurer les règles personnalisées du pare-feu d’applications web à l’aide d’Azure PowerShell.

Les extraits de code JSON présentés dans cet article sont dérivés d’une ressource ApplicationGatewayWebApplicationFirewallPolicies.

Notes

Si votre passerelle Application Gateway n’utilise pas la couche WAF, l’option de mise à niveau de la passerelle Application Gateway vers la couche WAF s’affiche dans le volet de droite.

Exemple 1

Vous souhaitez empêcher un robot nommé evilbot d’analyser votre site web. Dans ce cas, le blocage doit porter sur evilbot de l’agent utilisateur dans les en-têtes de requête.

Logique : p

$variable = New-AzApplicationGatewayFirewallMatchVariable `
   -VariableName RequestHeaders `
   -Selector User-Agent

$condition = New-AzApplicationGatewayFirewallCondition `
   -MatchVariable $variable `
   -Operator Contains `
   -MatchValue "evilbot" `
   -Transform Lowercase `
   -NegationCondition $False

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

Et voici le JSON correspondant :

{
  "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"
          ]
        }
      ]
    }
  ]
}

Pour voir un pare-feu d’applications web déployé à l’aide de cette règle personnalisée, consultez Configurer une règle personnalisée du pare-feu d’applications web à l’aide d’Azure PowerShell.

Exemple 1a

Vous pouvez accomplir la même chose à l’aide d’une expression régulière :

$variable = New-AzApplicationGatewayFirewallMatchVariable `
   -VariableName RequestHeaders `
   -Selector User-Agent

$condition = New-AzApplicationGatewayFirewallCondition `
   -MatchVariable $variable `
   -Operator Regex `
   -MatchValue "evilbot" `
   -Transform Lowercase `
   -NegationCondition $False

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

Voici le JSON correspondant :

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

Exemple 2

Vous souhaitez autoriser uniquement le trafic en provenance des États-Unis à l’aide de l’opérateur GeoMatch tout en conservant les règles managées :

$variable = New-AzApplicationGatewayFirewallMatchVariable `
   -VariableName RemoteAddr `

$condition = New-AzApplicationGatewayFirewallCondition `
   -MatchVariable $variable `
   -Operator GeoMatch `
   -MatchValue "US" `
   -Transform Lowercase `
   -NegationCondition $True

$rule = New-AzApplicationGatewayFirewallCustomRule `
   -Name "allowUS" `
   -Priority 2 `
   -RuleType MatchRule `
   -MatchCondition $condition `
   -Action Block `
   -State Enabled

Voici le JSON correspondant :

{
  "customRules": [
    {
      "name": "allowUS",
      "priority": 2,
      "ruleType": "MatchRule",
      "action": "Block",
      "state": "Enabled",
      "matchConditions": [
        {
          "matchVariables": [
            {
              "variableName": "RemoteAddr"
            }
          ],
          "operator": "GeoMatch",
          "negationCondition": true,
          "matchValues": [
            "US"
          ],
          "transforms": [
            "Lowercase"
          ]
        }
      ]
    }
  ]
}

Exemple 3

Vous souhaitez bloquer toutes les requêtes provenant d'adresses IP de la plage 198.168.5.0/24.

Dans cet exemple, vous bloquez tout le trafic provenant d’une plage d’adresses IP. Le nom de la règle est myrule1 et la priorité est définie sur 10.

Logique : p

$variable1 = New-AzApplicationGatewayFirewallMatchVariable `
   -VariableName RemoteAddr

$condition1 = New-AzApplicationGatewayFirewallCondition `
   -MatchVariable $variable1 `
   -Operator IPMatch `
   -MatchValue "192.168.5.0/24" `
   -NegationCondition $False

$rule = New-AzApplicationGatewayFirewallCustomRule `
   -Name myrule1 `
   -Priority 10 `
   -RuleType MatchRule `
   -MatchCondition $condition1 `
   -Action Block `
   -State Enabled

Voici le JSON correspondant :

{
  "customRules": [
    {
      "name": "myrule1",
      "priority": 10,
      "ruleType": "MatchRule",
      "action": "Block",
      "state": "Enabled",
      "matchConditions": [
        {
          "matchVariables": [
            {
              "variableName": "RemoteAddr"
            }
          ],
          "operator": "IPMatch",
          "negationCondition": false,
          "matchValues": [
            "192.168.5.0/24"
          ],
          "transforms": []
        }
      ]
    }
  ]
}

Règle CRS correspondante : SecRule REMOTE_ADDR "@ipMatch 192.168.5.0/24" "id:7001,deny"

Exemple 4

Pour cet exemple, vous souhaitez bloquer evilbot dans l'en-tête User-Agent et le trafic de la plage 192.168.5.0/24. Pour faire cette action, vous pouvez créer deux conditions de correspondance distinctes et les placer dans la même règle. Cette configuration garantit le blocage de la demande si evilbot dans l’en-tête User-Agent et des adresses IP de la plage 192.168.5.0/24 correspondent.

Logique : p and q

$variable1 = New-AzApplicationGatewayFirewallMatchVariable `
   -VariableName RemoteAddr

 $variable2 = New-AzApplicationGatewayFirewallMatchVariable `
   -VariableName RequestHeaders `
   -Selector User-Agent

$condition1 = New-AzApplicationGatewayFirewallCondition `
   -MatchVariable $variable1 `
   -Operator IPMatch `
   -MatchValue "192.168.5.0/24" `
   -NegationCondition $False

$condition2 = New-AzApplicationGatewayFirewallCondition `
   -MatchVariable $variable2 `
   -Operator Contains `
   -MatchValue "evilbot" `
   -Transform Lowercase `
   -NegationCondition $False

 $rule = New-AzApplicationGatewayFirewallCustomRule `
   -Name myrule `
   -Priority 10 `
   -RuleType MatchRule `
   -MatchCondition $condition1, $condition2 `
   -Action Block `
   -State Enabled

Voici le JSON correspondant :

{
  "customRules": [
    {
      "name": "myrule",
      "priority": 10,
      "ruleType": "MatchRule",
      "action": "Block",
      "state": "Enabled",
      "matchConditions": [
        {
          "matchVariables": [
            {
              "variableName": "RemoteAddr"
            }
          ],
          "operator": "IPMatch",
          "negationCondition": false,
          "matchValues": [
            "192.168.5.0/24"
          ],
          "transforms": []
        },
        {
          "matchVariables": [
            {
              "variableName": "RequestHeaders",
              "selector": "User-Agent"
            }
          ],
          "operator": "Contains",
          "negationCondition": false,
          "matchValues": [
            "evilbot"
          ],
          "transforms": [
            "Lowercase"
          ]
        }
      ]
    }
  ]
}

Exemple 5

Pour cet exemple, vous souhaitez l'activation du blocage si la demande est en dehors de la plage d'adresses IP 192.168.5.0/24, ou si la chaîne de l'agent utilisateur n'est pas chrome (ce qui signifie que l'utilisateur n'utilise pas le navigateur Chrome). Étant donné que cette logique utilise ou, les deux conditions se trouvent dans des règles distinctes, comme cela a été abordé dans l’exemple suivant. myrule1 et myrule2 doivent toutes deux correspondre pour bloquer le trafic.

Logique : not (p and q) = not p or not q.

$variable1 = New-AzApplicationGatewayFirewallMatchVariable `
   -VariableName RemoteAddr

$variable2 = New-AzApplicationGatewayFirewallMatchVariable `
   -VariableName RequestHeaders `
   -Selector User-Agent

$condition1 = New-AzApplicationGatewayFirewallCondition `
   -MatchVariable $variable1 `
   -Operator IPMatch `
   -MatchValue "192.168.5.0/24" `
   -NegationCondition $True

$condition2 = New-AzApplicationGatewayFirewallCondition `
   -MatchVariable $variable2 `
   -Operator Contains `
   -MatchValue "chrome" `
   -Transform Lowercase `
   -NegationCondition $True

$rule1 = New-AzApplicationGatewayFirewallCustomRule `
   -Name myrule1 `
   -Priority 10 `
   -RuleType MatchRule `
   -MatchCondition $condition1 `
   -Action Block `
   -State Enabled

$rule2 = New-AzApplicationGatewayFirewallCustomRule `
   -Name myrule2 `
   -Priority 20 `
   -RuleType MatchRule `
   -MatchCondition $condition2 `
   -Action Block `
   -State Enabled

Voici le JSON correspondant :

{
  "customRules": [
    {
      "name": "myrule1",
      "priority": 10,
      "ruleType": "MatchRule",
      "action": "Block",
      "state": "Enabled",
      "matchConditions": [
        {
          "matchVariables": [
            {
              "variableName": "RemoteAddr"
            }
          ],
          "operator": "IPMatch",
          "negationCondition": true,
          "matchValues": [
            "192.168.5.0/24"
          ],
          "transforms": []
        }
      ]
    },
    {
      "name": "myrule2",
      "priority": 20,
      "ruleType": "MatchRule",
      "action": "Block",
      "state": "Enabled",
      "matchConditions": [
        {
          "matchVariables": [
            {
              "variableName": "RequestHeaders",
              "selector": "User-Agent"
            }
          ],
          "operator": "Contains",
          "negationCondition": true,
          "matchValues": [
            "chrome"
          ],
          "transforms": [
            "Lowercase"
          ]
        }
      ]
    }
  ]
}

Exemple 6

Vous souhaitez autoriser uniquement les demandes provenant d’agents utilisateurs connus spécifiques.

Comme la logique utilisée ici est or et que toutes les valeurs se trouvent dans l’en-tête User-Agent, toutes les MatchValues peuvent se trouver dans une liste séparée par des virgules.

Logique : p or q or r

$variable = New-AzApplicationGatewayFirewallMatchVariable `
   -VariableName RequestHeaders `
   -Selector User-Agent
$condition = New-AzApplicationGatewayFirewallCondition `
   -MatchVariable $variable `
   -Operator Equal `
   -MatchValue @('user1', 'user2') `
   -NegationCondition $True

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

Voici le JSON correspondant :

{
  "customRules": [
    {
      "name": "BlockUnknownUserAgents",
      "priority": 2,
      "ruleType": "MatchRule",
      "action": "Block",
      "state": "Enabled",
      "matchConditions": [
        {
          "matchVariables": [
            {
              "variableName": "RequestHeaders",
              "selector": "User-Agent"
            }
          ],
          "operator": "Equal",
          "negationCondition": true,
          "matchValues": [
            "user1",
            "user2"
          ],
          "transforms": []
        }
      ]
    }
  ]
}

Exemple 7

Il n’est pas rare de voir la porte Azure Front Door déployé devant Application Gateway. Pour s’assurer que le trafic reçu par Application Gateway provient du déploiement de Front Door, il est recommandé de vérifier si l'en-tête X-Azure-FDID contient la valeur unique attendue. Pour plus d’informations sur la sécurisation de l’accès à votre application à l’aide de Azure Front Door, consultez Comment verrouiller l’accès à mon back-end uniquement à Azure Front Door

Logique : non p

$expectedFDID = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
$variable = New-AzApplicationGatewayFirewallMatchVariable `
   -VariableName RequestHeaders `
   -Selector X-Azure-FDID

$condition = New-AzApplicationGatewayFirewallCondition `
   -MatchVariable $variable `
   -Operator Equal `
   -MatchValue $expectedFDID `
   -Transform Lowercase `
   -NegationCondition $True

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

Et voici le JSON correspondant :

{
  "customRules": [
    {
      "name": "blockNonAFDTraffic",
      "priority": 2,
      "ruleType": "MatchRule",
      "action": "Block",
      "state": "Enabled",
      "matchConditions": [
        {
          "matchVariables": [
            {
              "variableName": "RequestHeaders",
              "selector": "X-Azure-FDID"
            }
          ],
          "operator": "Equal",
          "negationCondition": true,
          "matchValues": [
            "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
          ],
          "transforms": [
            "Lowercase"
          ]
        }
      ]
    }
  ]
}

Étapes suivantes

Après avoir créé vos règles personnalisées, vous pouvez apprendre à afficher vos journaux d’activité WAF. Pour plus d’informations, consultez Diagnostics Application Gateway.