Udostępnij za pośrednictwem


Tworzenie i używanie reguł niestandardowych usługi Web Application Firewall w wersji 2 w usłudze Application Gateway

Zapora aplikacji internetowej (WAF) w wersji 2 w usłudze aplikacja systemu Azure Gateway zapewnia ochronę aplikacji internetowych. Ta ochrona jest zapewniana przez podstawowy zestaw reguł open Web Application Security Project (OWASP) Core Rule Set (CRS). W niektórych przypadkach może być konieczne utworzenie własnych reguł niestandardowych w celu spełnienia określonych potrzeb. Aby uzyskać więcej informacji na temat reguł niestandardowych zapory aplikacji internetowej, zobacz Omówienie niestandardowych reguł zapory aplikacji internetowej.

W tym artykule przedstawiono przykładowe reguły niestandardowe, które można tworzyć i używać z zaporą aplikacji internetowej w wersji 2. Aby dowiedzieć się, jak wdrożyć zaporę aplikacji internetowej przy użyciu reguły niestandardowej przy użyciu programu Azure PowerShell, zobacz Konfigurowanie reguł niestandardowych zapory aplikacji internetowej przy użyciu programu Azure PowerShell.

Fragmenty kodu JSON pokazane w tym artykule pochodzą z zasobu ApplicationGatewayWebApplicationFirewallPolicies .

Uwaga

Jeśli twoja brama aplikacji nie korzysta z warstwy zapory aplikacji internetowej, w okienku po prawej stronie zostanie wyświetlona opcja uaktualnienia bramy aplikacji do warstwy zapory aplikacji internetowej.

Włączanie zapory aplikacji internetowej

Przykład 1

Wiesz, że istnieje bot o nazwie evilbot , który chcesz zablokować przeszukiwanie witryny internetowej. W takim przypadku w nagłówkach żądania zablokujesz złego bota User-Agent.

Logika: 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

Oto odpowiedni kod JSON:

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

Aby wyświetlić zaporę aplikacji internetowej wdrożona przy użyciu tej reguły niestandardowej, zobacz Konfigurowanie reguły niestandardowej zapory aplikacji internetowej przy użyciu programu Azure PowerShell.

Przykład 1a

Można to zrobić przy użyciu wyrażenia regularnego:

$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

I odpowiadający kod JSON:

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

Przykład 2

Chcesz zezwolić na ruch tylko z Stany Zjednoczone przy użyciu operatora GeoMatch i nadal mają zastosowanie reguły zarządzane:

$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

I odpowiadający kod JSON:

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

Przykład 3

Chcesz zablokować wszystkie żądania z adresów IP w zakresie 198.168.5.0/24.

W tym przykładzie blokujesz cały ruch pochodzący z zakresu adresów IP. Nazwa reguły to myrule1 , a priorytet ma wartość 10.

Logika: 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

Oto odpowiedni kod JSON:

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

Odpowiadająca reguła CRS: SecRule REMOTE_ADDR "@ipMatch 192.168.5.0/24" "id:7001,deny"

Przykład 4

W tym przykładzie chcesz zablokować źlebota agenta użytkownika i ruch w zakresie 192.168.5.0/24. Aby wykonać tę akcję, można utworzyć dwa oddzielne warunki dopasowania i umieścić je w tej samej regule. Ta konfiguracja gwarantuje, że jeśli zarówno złabot w nagłówku User-Agent, jak i adresy IP z zakresu 192.168.5.0/24 są zgodne, żądanie zostanie zablokowane.

Logika: p i 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

Oto odpowiedni kod JSON:

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

Przykład 5

W tym przykładzie chcesz zablokować, czy żądanie znajduje się poza zakresem adresów IP 192.168.5.0/24 lub ciąg agenta użytkownika nie jest chrome (co oznacza, że użytkownik nie korzysta z przeglądarki Chrome). Ponieważ ta logika używa lub, dwa warunki znajdują się w oddzielnych regułach, jak pokazano w poniższym przykładzie. zarówno myrule1 , jak i myrule2 muszą być zgodne, aby zablokować ruch.

Logika: nie (p i q) = nie p lub nie 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

I odpowiadający kod JSON:

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

Przykład 6

Chcesz zezwolić tylko na żądania od określonych znanych agentów użytkowników.

Ponieważ logika używana w tym miejscu jest lub, a wszystkie wartości znajdują się w nagłówku User-Agent, wszystkie wartości MatchValues mogą znajdować się na liście rozdzielanej przecinkami.

Logika: p lub q lub 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

Odpowiedni kod JSON:

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

Przykład 7

Usługa Azure Front Door wdrożona przed usługą Application Gateway nie jest rzadkością. Aby upewnić się, że ruch odbierany przez usługę Application Gateway pochodzi z wdrożenia usługi Front Door, najlepszym rozwiązaniem jest sprawdzenie, czy X-Azure-FDID nagłówek zawiera oczekiwaną unikatową wartość. Aby uzyskać więcej informacji na temat zabezpieczania dostępu do aplikacji przy użyciu usługi Azure Front Door, zobacz How to lock down the access to my backend to only Azure Front Door (Jak zablokować dostęp do zaplecza tylko w usłudze Azure Front Door)

Logika: nie 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

Oto odpowiedni kod JSON:

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

Następne kroki

Po utworzeniu reguł niestandardowych możesz dowiedzieć się, jak wyświetlać dzienniki zapory aplikacji internetowej. Aby uzyskać więcej informacji, zobacz Diagnostyka usługi Application Gateway.