Utiliser des règles personnalisées de géo-correspondance du pare-feu d’applications web Azure pour améliorer la sécurité réseau

Le pare-feu d’applications web (WAF) est un outil important qui permet de protéger les applications web contre les attaques dangereuses. Il peut filtrer, surveiller et arrêter le trafic web à l’aide de règles prédéfinies et personnalisées. Vous pouvez établir votre propre règle qui sera vérifiée par le WAF à chaque requête qu’il reçoit. Les règles personnalisées ont une priorité plus élevée que les règles managées et sont vérifiées en premier.

Parmi les fonctionnalités les plus puissantes d’Azure Web Application Firewall figurent les règles personnalisées de géo-correspondance. Ces règles vous permettent de faire correspondre les requêtes web à l’emplacement géographique dont elles proviennent. Vous pouvez arrêter les requêtes de certaines provenances connues pour leurs activités dangereuses ou autoriser celles issues de provenances importantes pour votre activité. Les règles personnalisées de géo-correspondance peuvent également vous aider à vous mettre en conformité avec les lois de souveraineté et de confidentialité des données en limitant l’accès à vos applications web en fonction de la localisation des personnes qui les utilisent.

Pour éviter les traitements ou conflits inutiles, utilisez le paramètre de priorité à bon escient lorsque vous employez des règles personnalisées de géo-correspondance. Le pare-feu d’applications web Azure évalue les règles selon l’ordre déterminé par le paramètre de priorité, dont la valeur numérique peut varier de 1 à 100, la plus faible représentant la priorité plus élevée. La priorité de chaque règle personnalisée doit être unique (vous ne pouvez pas utiliser la même valeur pour chaque règle). Attribuez une haute priorité aux règles critiques ou spécifiques pour la sécurité de votre application web et une basse priorité aux règles moins essentielles ou générales. Cela garantit que waf applique les actions les plus appropriées à votre trafic web. Par exemple, le scénario où vous identifiez un chemin d’URI explicite s’avère le plus spécifique et doit disposer d’une règle de priorité plus élevée que les autres types de modèles. Le fait d’avoir la priorité la plus élevée protège un chemin critique sur l’application tout en autorisant l’évaluation d’un trafic plus générique entre d’autres règles personnalisées ou ensembles de règles managés.

Testez toujours vos règles avant de les appliquer à l’environnement de production et surveillez régulièrement leurs performances et leur impact. En suivant ces bonnes pratiques, vous pouvez améliorer la sécurité de votre application web à l’aide de la puissance des règles personnalisées geomatch.

Cet article présente les règles personnalisées de géomatch Azure WAF et vous montre comment les créer et les gérer à l’aide du portail Azure, de Bicep et d’Azure PowerShell.

Modèles de règles personnalisées de géo-correspondance

Les règles personnalisées de géo-correspondance vous permettent de répondre à divers objectifs de sécurité, comme le blocage des demandes en provenance de zones à haut risque et l’autorisation des demandes issues de localisations de confiance. Ils sont efficaces pour atténuer les attaques par déni de service distribué (DDoS), qui cherchent à inunder votre application web avec une multitude de requêtes provenant de différentes sources. Grâce aux règles personnalisées de géo-correspondance, vous pouvez identifier et bloquer rapidement les régions générant la majeure partie du trafic DDoS, tout en accordant l’accès aux utilisateurs légitimes. Dans cet article, vous allez découvrir différents modèles de règles personnalisés que vous pouvez employer pour optimiser votre pare-feu d’applications web Azure à l’aide de règles personnalisées de géo-correspondance.

Scénario 1 – Bloquer le trafic en provenance de tous les pays ou régions à l’exception de « x »

Les règles personnalisées de géo-correspondance s’avèrent utiles quand votre objectif est de bloquer le trafic en provenance de tous les pays ou régions, sauf un(e). Par exemple, si votre application web s’adresse exclusivement à des utilisateurs situés aux États-Unis, vous pouvez formuler une règle personnalisée de géo-correspondance qui bloque toutes les requêtes ne provenant pas des États-Unis. Cette stratégie réduit efficacement la surface d’attaque de votre application web et prévient les accès non autorisés depuis d’autres régions. Cette technique spécifique emploie une condition de négation pour faciliter ce modèle de trafic. Pour créer une règle personnalisée de géomatch qui bloque le trafic provenant de tous les pays ou régions, à l'exception des États-Unis, consultez les exemples suivants dans le portail, PowerShell ou Bicep :

Capture d’écran montrant l’écran d’ajout d’une règle personnalisée du pare-feu d’applications web pour Application Gateway.

Capture d’écran montrant l’écran d’ajout d’une règle personnalisée du pare-feu d’applications web pour Front Door.

Remarque

Sur le WAF Azure Front Door, vous utilisez SocketAddr comme variable de correspondance et non RemoteAddr. La variable RemoteAddr est l’adresse IP du client d’origine qui est généralement envoyée via l’en-tête de demande X-Forwarded-For. La variable SocketAddr est l'adresse IP source que le WAF voit.

$RGname = "rg-waf "
$policyName = "waf-pol"
$variable = New-AzApplicationGatewayFirewallMatchVariable -VariableName RemoteAddr
$condition = New-AzApplicationGatewayFirewallCondition -MatchVariable $variable -Operator GeoMatch -MatchValue "US" -NegationCondition $true
$rule = New-AzApplicationGatewayFirewallCustomRule -Name GeoRule1 -Priority 10 -RuleType MatchRule -MatchCondition $condition -Action Block
$policy = Get-AzApplicationGatewayFirewallPolicy -Name $policyName -ResourceGroupName $RGname
$policy.CustomRules.Add($rule)
Set-AzApplicationGatewayFirewallPolicy -InputObject $policy

$RGname = "rg-waf"
$policyName = "wafafdpol"
$matchCondition = New-AzFrontDoorWafMatchConditionObject -MatchVariable SocketAddr -OperatorProperty GeoMatch -MatchValue "US" -NegateCondition $true
$customRuleObject = New-AzFrontDoorWafCustomRuleObject -Name "GeoRule1" -RuleType MatchRule -MatchCondition $matchCondition -Action Block -Priority 10
$afdWAFPolicy= Get-AzFrontDoorWafPolicy -Name $policyName -ResourceGroupName $RGname
Update-AzFrontDoorWafPolicy -InputObject $afdWAFPolicy -Customrule $customRuleObject

properties: {
    customRules: [
      {
        name: 'GeoRule1'
        priority: 10
        ruleType: 'MatchRule'
        action: 'Block'
        matchConditions: [
          {
            matchVariables: [
              {
                variableName: 'RemoteAddr'
              }
            ]
            operator: 'GeoMatch'
            negationCondition: true
            matchValues: [
              'US'
            ]
            transforms: []
          }
        ]
        state: 'Enabled'
      }

properties: {
    customRules: {
      rules: [
        {
          name: 'GeoRule1'
          enabledState: 'Enabled'
          priority: 10
          ruleType: 'MatchRule'
          matchConditions: [
            {
              matchVariable: 'SocketAddr'
              operator: 'GeoMatch'
              negateCondition: true
              matchValue: [
                'US'
              ]
              transforms: []
            }
          ]
          action: 'Block'
        }

Scénario 2 – Bloquer le trafic en provenance de tous les pays ou régions à l’exception de « x » et « y » qui ciblent l’URI « foo » ou « bar »

Considérez un scénario où vous devez utiliser des règles personnalisées de géo-correspondance pour bloquer le trafic en provenance de tous les pays ou régions, à l’exception de deux pays/régions spécifiques (ou plus), ciblant un URI spécifique. Supposez que votre application web possède des chemins d’URI spécifiques qui s’adressent uniquement à des utilisateurs basés aux États-Unis et au Canada. Dans ce cas, vous créez une règle personnalisée de géo-correspondance qui bloque toutes les requêtes qui ne proviennent pas de ces pays ou régions.

Ce modèle traite les charges utiles de requêtes en provenance des États-Unis et du Canada via les ensembles de règles managés, interceptant ainsi les attaques malveillantes tout en bloquant les requêtes en provenance de tous les autres pays ou régions. Grâce à cette approche, vous avez la garantie que seul votre public cible peut accéder à votre application web et que le trafic indésirable en provenance d’autres régions est évité.

Pour réduire les faux positifs potentiels, incluez le code pays ZZ dans la liste pour capturer les adresses IP qui ne sont pas encore mappées à un pays ou une région dans le jeu de données d’Azure. Cette technique utilise une condition de négation pour le type de géolocalisation et une condition de non-négation pour la correspondance d’URI.

Pour créer une règle personnalisée de geomatch qui bloque le trafic de tous les pays ou régions sauf les États-Unis et le Canada vers un URI spécifié, reportez-vous aux exemples du portail, de PowerShell et de Bicep.

$RGname = "rg-waf "
$policyName = "waf-pol"
$variable1a = New-AzApplicationGatewayFirewallMatchVariable -VariableName RemoteAddr
$condition1a = New-AzApplicationGatewayFirewallCondition -MatchVariable $variable1a -Operator GeoMatch -MatchValue @(“US”, “CA”) -NegationCondition $true
$variable1b = New-AzApplicationGatewayFirewallMatchVariable -VariableName RequestUri
$condition1b = New-AzApplicationGatewayFirewallCondition -MatchVariable $variable1b -Operator Contains -MatchValue @(“/foo”, “/bar”) -NegationCondition $false
$rule1 = New-AzApplicationGatewayFirewallCustomRule -Name GeoRule2 -Priority 11 -RuleType MatchRule -MatchCondition $condition1a, $condition1b -Action Block
$policy = Get-AzApplicationGatewayFirewallPolicy -Name $policyName -ResourceGroupName $RGname
$policy.CustomRules.Add($rule1)
Set-AzApplicationGatewayFirewallPolicy -InputObject $policy

$RGname = "rg-waf"
$policyName = "wafafdpol"
$matchCondition1a = New-AzFrontDoorWafMatchConditionObject -MatchVariable SocketAddr -OperatorProperty GeoMatch -MatchValue @(“US”, "CA") -NegateCondition $true
$matchCondition1b = New-AzFrontDoorWafMatchConditionObject -MatchVariable RequestUri -OperatorProperty Contains -MatchValue @(“/foo”, “/bar”) -NegateCondition $false
$customRuleObject1 = New-AzFrontDoorWafCustomRuleObject -Name "GeoRule2" -RuleType MatchRule -MatchCondition $matchCondition1a, $matchCondition1b -Action Block -Priority 11
$afdWAFPolicy= Get-AzFrontDoorWafPolicy -Name $policyName -ResourceGroupName $RGname
Update-AzFrontDoorWafPolicy -InputObject $afdWAFPolicy -Customrule $customRuleObject1

properties: {
    customRules: [
      {
        name: 'GeoRule2'
        priority: 11
        ruleType: 'MatchRule'
        action: 'Block'
        matchConditions: [
          {
            matchVariables: [
              {
                variableName: 'RemoteAddr'
              }
            ]
            operator: 'GeoMatch'
            negationCondition: true
            matchValues: [
              'US'
              'CA'
            ]
            transforms: []
          }
          {
            matchVariables: [
              {
                variableName: 'RequestUri'
              }
            ]
            operator: 'Contains'
            negationCondition: false
            matchValues: [
              '/foo'
              '/bar'
            ]
            transforms: []
          }
        ]
        state: 'Enabled'
      }

properties: {
    customRules: {
      rules: [
        {
          name: 'GeoRule2'
          enabledState: 'Enabled'
          priority: 11
          ruleType: 'MatchRule'
          matchConditions: [
            {
              matchVariable: 'SocketAddr'
              operator: 'GeoMatch'
              negateCondition: true
              matchValue: [
                'US'
                'CA'
              ]
              transforms: []
            }
            {
              matchVariable: 'RequestUri'
              operator: 'Contains'
              negateCondition: false
              matchValue: [
                '/foo'
                '/bar'
              ]
              transforms: []
            }
          ]
          action: 'Block'
        }

Scénario 3 – Bloquer le trafic provenant spécifiquement du pays ou de la région « x »

Vous pouvez utiliser des règles personnalisées de géo-correspondance pour bloquer le trafic provenant de pays ou de régions spécifiques. Par exemple, si votre application web reçoit de nombreuses requêtes malveillantes du pays ou de la région « x », créez une règle personnalisée de géo-correspondance pour bloquer toutes les requêtes en provenance de ce pays ou de cette région. Vous protégerez ainsi votre application web contre les attaques potentielles et réduirez la charge des ressources. Appliquez ce modèle pour bloquer plusieurs pays ou régions malveillants ou hostiles. Cette technique nécessite une condition de correspondance pour le modèle de trafic. Pour bloquer le trafic à partir du pays ou de la région « x », consultez les exemples suivants du portail, de PowerShell et de Bicep.

Capture d’écran montrant l’écran d’ajout d’une règle personnalisée pour Application Gateway.

Capture d’écran montrant l’écran d’ajout d’une règle personnalisée pour Front Door.

$RGname = "rg-waf "
$policyName = "waf-pol"
$variable2 = New-AzApplicationGatewayFirewallMatchVariable -VariableName RemoteAddr
$condition2 = New-AzApplicationGatewayFirewallCondition -MatchVariable $variable2 -Operator GeoMatch -MatchValue "US" -NegationCondition $false
$rule2 = New-AzApplicationGatewayFirewallCustomRule -Name GeoRule3 -Priority 12 -RuleType MatchRule -MatchCondition $condition2 -Action Block
$policy = Get-AzApplicationGatewayFirewallPolicy -Name $policyName -ResourceGroupName $RGname
$policy.CustomRules.Add($rule2)
Set-AzApplicationGatewayFirewallPolicy -InputObject $policy

$RGname = "rg-waf"
$policyName = "wafafdpol"
$matchCondition2 = New-AzFrontDoorWafMatchConditionObject -MatchVariable SocketAddr -OperatorProperty GeoMatch -MatchValue "US" -NegateCondition $false
$customRuleObject2 = New-AzFrontDoorWafCustomRuleObject -Name "GeoRule3" -RuleType MatchRule -MatchCondition $matchCondition2 -Action Block -Priority 12
$afdWAFPolicy= Get-AzFrontDoorWafPolicy -Name $policyName -ResourceGroupName $RGname
Update-AzFrontDoorWafPolicy -InputObject $afdWAFPolicy -Customrule $customRuleObject2

properties: {
    customRules: [
      {
        name: 'GeoRule3'
        priority: 12
        ruleType: 'MatchRule'
        action: 'Block'
        matchConditions: [
          {
            matchVariables: [
              {
                variableName: 'RemoteAddr'
              }
            ]
            operator: 'GeoMatch'
            negationCondition: false
            matchValues: [
              'US'
            ]
            transforms: []
          }
        ]
        state: 'Enabled'
      }

properties: {
    customRules: {
      rules: [
        {
          name: 'GeoRule3'
          enabledState: 'Enabled'
          priority: 12
          ruleType: 'MatchRule'
          matchConditions: [
            {
              matchVariable: 'SocketAddr'
              operator: 'GeoMatch'
              negateCondition: false
              matchValue: [
                'US'
              ]
              transforms: []
            }
          ]
          action: 'Block'
        }

Anti-modèles de règles personnalisées de géo-correspondance

Évitez les anti-modèles lorsque vous utilisez des règles personnalisées de géo-correspondance, notamment en définissant l’action de règle personnalisée sur allow au lieu de block. Cela peut avoir des conséquences inattendues, comme autoriser le trafic à contourner le WAF et potentiellement d’exposer votre application web à d’autres menaces.

Au lieu d’utiliser une action allow, utilisez une action block avec une condition de négation, comme dans les modèles précédents. Ceci garantit que seul le trafic en provenance des pays ou régions souhaités est autorisé et que le pare-feu d’applications web bloque tout le reste du trafic.

Scénario 4 – Autoriser le trafic en provenance du pays ou de la région « x »

Évitez de définir la règle personnalisée de géo-correspondance pour autoriser le trafic en provenance d’un pays ou d’une région spécifique. Par exemple, si vous souhaitez autoriser le trafic provenant des États-Unis du fait de son clientèle importante, la création d’une règle personnalisée avec l’action allow et la valeur United States peut sembler être la solution. Cependant, cette règle autorise l’ensemble du trafic en provenance des États-Unis, qu’il comporte une charge utile malveillante ou non, car l’action allow contourne tout traitement de règle supplémentaire pour les ensembles de règles managés. En outre, le pare-feu d’applications web continue de traiter le trafic de tous les autres pays ou régions, ce qui consomme des ressources. Votre application web est alors exposée aux requêtes malveillantes en provenance des États-Unis qui auraient autrement été bloquées par le WAF.

Scénario 5 : Autoriser le trafic en provenance de tous les pays à l’exception de « x »

Évitez de définir l’action de la règle sur allow et de spécifier une liste de pays ou régions à exclure quand vous utilisez des règles personnalisées de géo-correspondance. Par exemple, si vous voulez autoriser le trafic en provenance de tous les pays ou régions à l’exception des États-Unis, où vous suspectez une activité malveillante, cette approche peut avoir des conséquences non souhaitées. Elle peut autoriser le trafic en provenance de pays/régions non vérifiés ou non sûrs, ou dont les standards de sécurité sont faibles ou inexistants, ce qui exposerait votre application web à des vulnérabilités ou des attaques potentielles. L’utilisation de l’action allow pour tous les pays ou régions à l’exception des États-Unis indique au pare-feu d’applications web d’arrêter le traitement des charges utiles des requêtes pour les ensembles de règles managés. Toute l’évaluation de règles cesse une fois que la règle personnalisée avec allow a été traitée, ce qui expose l’application aux attaques malveillantes indésirables.

Utilisez au lieu de cela une action de règle plus restrictive et spécifique, comme un blocage, et spécifiez une liste de pays ou régions à autoriser avec une condition de négation. Vous serez ainsi assuré que seul le trafic en provenance de sources fiables et vérifiées peut accéder à votre application web tout en bloquant le trafic suspect ou indésirable.

Rétroaction

Cette page a-t-elle été utile ?

Last updated on 2025-09-18