Używanie niestandardowych reguł geomatchu zapory aplikacji internetowej platformy Azure w celu zwiększenia bezpieczeństwa sieci

Zapora aplikacji internetowej (WAF) to ważne narzędzie, które pomaga chronić aplikacje internetowe przed szkodliwymi atakami. Może filtrować, monitorować i zatrzymywać ruch internetowy przy użyciu reguł wstępnych i niestandardowych. Możesz ustawić własną regułę, że zapora aplikacji internetowej sprawdza każde żądanie, które otrzymuje. Reguły niestandardowe mają wyższy priorytet niż reguły zarządzane i są najpierw sprawdzane.

Jedną z najbardziej zaawansowanych funkcji usługi Azure Web Application Firewall jest reguł niestandardowych niezgodności geograficznych. Te reguły umożliwiają dopasowywanie żądań internetowych do lokalizacji geograficznej, z której pochodzą. Możesz zatrzymać żądania z niektórych miejsc znanych ze szkodliwych działań lub zezwolić na żądania z miejsc ważnych dla twojej firmy. Niestandardowe reguły geomatchu mogą również pomóc w przestrzeganiu przepisów dotyczących niezależności i prywatności danych przez ograniczenie dostępu do aplikacji internetowych na podstawie lokalizacji osób, z których korzystają.

Użyj parametru priorytetu odpowiednio podczas korzystania z reguł niestandardowych zgodności geograficznej, aby uniknąć niepotrzebnego przetwarzania lub konfliktów. Zapora aplikacji internetowej platformy Azure ocenia reguły w kolejności określonej przez parametr priorytetu, wartość liczbową z zakresu od 1 do 100, z niższymi wartościami wskazującymi wyższy priorytet. Priorytet musi być unikatowy we wszystkich regułach niestandardowych. Przypisz wyższy priorytet do krytycznych lub specyficznych reguł dotyczących zabezpieczeń aplikacji internetowej i niższego priorytetu do mniej podstawowych lub ogólnych reguł. Dzięki temu WAF podejmuje najbardziej odpowiednie działania w odniesieniu do ruchu internetowego. Na przykład scenariusz, w którym można zidentyfikować jawną ścieżkę identyfikatora URI, jest najbardziej specyficzny i powinien mieć regułę o wyższym priorytcie niż inne typy wzorców. Posiadanie najwyższego priorytetu chroni ścieżkę krytyczną w aplikacji, pozwalając na ocenę bardziej ogólnego ruchu w ramach innych reguł niestandardowych lub zestawów reguł zarządzanych.

Zawsze testuj reguły przed zastosowaniem ich do środowiska produkcyjnego i regularnie monitoruj ich wydajność i wpływ. Postępując zgodnie z tymi najlepszymi rozwiązaniami, możesz zwiększyć bezpieczeństwo aplikacji internetowej przy użyciu możliwości niestandardowych reguł geomatch.

W tym artykule przedstawiono niestandardowe reguły geomatch zapory aplikacji internetowej platformy Azure i pokazano, jak tworzyć je i zarządzać nimi przy użyciu portalu Azure, języka Bicep i Azure PowerShell.

Niestandardowe wzorce reguł geograficznych

Niestandardowe reguły geomatchu umożliwiają spełnienie różnych celów zabezpieczeń, takich jak blokowanie żądań z obszarów wysokiego ryzyka i zezwalanie na żądania z zaufanych lokalizacji. Są one skuteczne w ograniczaniu rozproszonych ataków typu "odmowa usługi" (DDoS), które mają na celu zalewanie aplikacji internetowej wieloma żądaniami z różnych źródeł. Dzięki niestandardowym regułom geograficznym można szybko wskazać i zablokować regiony generujące najwięcej ruchu DDoS, jednocześnie udzielając dostępu do uprawnionych użytkowników. W tym artykule przedstawiono różne niestandardowe wzorce reguł, które można zastosować w celu zoptymalizowania zapory aplikacji internetowej platformy Azure przy użyciu niestandardowych reguł geomatchu.

Scenariusz 1 — blokowanie ruchu ze wszystkich krajów lub regionów z wyjątkiem "x"

Niestandardowe reguły geomatchu są przydatne, gdy chcesz zablokować ruch ze wszystkich krajów lub regionów, wykluczając je. Jeśli na przykład aplikacja internetowa obsługuje wyłącznie użytkowników w Stany Zjednoczone, możesz sformułować niestandardową regułę niezgodności geograficznej, która blokuje wszystkie żądania, które nie pochodzą z USA. Ta strategia skutecznie minimalizuje obszar ataków aplikacji internetowej i odstrasza nieautoryzowany dostęp z innych regionów. Ta konkretna technika wykorzystuje warunek negacji, aby ułatwić ten wzorzec ruchu. Aby utworzyć niestandardową regułę geomatch, która blokuje ruch ze wszystkich krajów lub regionów z wyjątkiem Stanów Zjednoczonych, zobacz następujące przykłady na portalu, w PowerShell lub Bicep:

Portal

Uwaga

W zaporze aplikacji internetowej usługi Azure Front Door należy użyć SocketAddr jako zmiennej dopasowania, a nie RemoteAddr. Zmienna RemoteAddr to oryginalny adres IP klienta, który jest zwykle wysyłany za pośrednictwem nagłówka X-Forwarded-For żądania. Zmienna SocketAddr to źródłowy adres IP widoczny przez zaporę aplikacji internetowej.

PowerShell

$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

Biceps

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'
        }

Scenariusz 2 — blokowanie ruchu ze wszystkich krajów lub regionów z wyjątkiem "x" i "y", które są przeznaczone dla identyfikatora URI "foo" lub "bar"

Rozważmy scenariusz, w którym należy użyć niestandardowych reguł geomatchu, aby zablokować ruch ze wszystkich krajów lub regionów, z wyjątkiem dwóch lub większej liczby określonych, przeznaczonych dla określonego identyfikatora URI. Załóżmy, że aplikacja internetowa ma określone ścieżki identyfikatorów URI przeznaczone tylko dla użytkowników w Stanach Zjednoczonych i Kanadzie. W takim przypadku tworzysz niestandardową regułę geomatchu, która blokuje wszystkie żądania, które nie pochodzą z tych krajów lub regionów.

Ten wzorzec przetwarza żądania ładunków ze Stanów Zjednoczonych i Kanady za pośrednictwem zarządzanych zestawów reguł, przechwytując wszelkie złośliwe ataki, jednocześnie blokując żądania ze wszystkich innych krajów lub regionów. Takie podejście zapewnia, że tylko docelowi odbiorcy mogą uzyskiwać dostęp do aplikacji internetowej, unikając niepożądanego ruchu z innych regionów.

Aby zminimalizować potencjalne wyniki fałszywie dodatnie, dołącz kod kraju ZZ na liście, aby przechwycić adresy IP, które nie są jeszcze mapowane na kraj lub region w zestawie danych platformy Azure. Ta technika używa warunku negacji dla typu geolokalizacji i warunku nie negacji dla dopasowania identyfikatora URI.

Aby utworzyć niestandardową regułę geomatchu blokującą ruch ze wszystkich krajów lub regionów z wyjątkiem Stanów Zjednoczonych i Kanady do określonego identyfikatora URI, zapoznaj się z przykładami portalu, programu PowerShell i Bicep.

Portal

PowerShell

$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

Biceps

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'
        }

Scenariusz 3 — blokowanie ruchu z kraju lub regionu "x"

Możesz użyć niestandardowych reguł geograficznych, aby zablokować ruch z określonych krajów lub regionów. Jeśli na przykład aplikacja internetowa odbiera wiele złośliwych żądań z kraju lub regionu "x", utwórz regułę niestandardową niezgodności geograficznej, aby zablokować wszystkie żądania z tego kraju lub regionu. Chroni to aplikację internetową przed potencjalnymi atakami i zmniejsza obciążenie zasobów. Zastosuj ten wzorzec, aby zablokować wiele złośliwych lub wrogich krajów lub regionów. Ta technika wymaga warunku dopasowania dla wzorca ruchu. Aby zablokować ruch z kraju lub regionu "x", zobacz następujące przykłady portalu, programu PowerShell i Bicep.

Portal

PowerShell

$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

Biceps

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'
        }

Niestandardowe wzorce reguł geograficznych

Unikaj anty-wzorców podczas używania niestandardowych reguł geograficznych, takich jak ustawienie niestandardowej akcji reguły na wartość allow zamiast block. Może to mieć niezamierzone konsekwencje, takie jak zezwolenie na obejście zapory aplikacji internetowej i potencjalnie ujawnienie aplikacji internetowej innym zagrożeniom.

Zamiast używać allow akcji, użyj block akcji z warunkiem negacji, jak pokazano w poprzednich wzorcach. Gwarantuje to, że dozwolony jest tylko ruch z żądanych krajów lub regionów, a zapora aplikacji internetowej blokuje cały inny ruch.

Scenariusz 4 — zezwalanie na ruch z kraju lub regionu "x"

Unikaj ustawiania niestandardowej reguły niezgodności geograficznej, aby zezwolić na ruch z określonego kraju lub regionu. Jeśli na przykład chcesz zezwolić na ruch z Stany Zjednoczone ze względu na dużą bazę klientów, utworzenie reguły niestandardowej z akcją allow i wartość United States może wydawać się rozwiązaniem. Jednak ta reguła zezwala na cały ruch z Stany Zjednoczone, niezależnie od tego, czy ma złośliwy ładunek, czy nie, ponieważ allow akcja pomija dalsze przetwarzanie reguł zarządzanych zestawów reguł. Ponadto zapora aplikacji internetowej nadal przetwarza ruch ze wszystkich innych krajów lub regionów, zużywając zasoby. Spowoduje to uwidocznienie aplikacji internetowej złośliwych żądań z Stany Zjednoczone, które zapora aplikacji internetowej w przeciwnym razie zablokowałaby.

Scenariusz 5 — zezwalanie na ruch ze wszystkich powiatów z wyjątkiem "x"

Unikaj ustawiania akcji reguły na allow i określania listy krajów lub regionów do wykluczenia podczas używania niestandardowych reguł geomatch. Jeśli na przykład chcesz zezwolić na ruch ze wszystkich krajów lub regionów z wyjątkiem Stany Zjednoczone, gdzie podejrzewasz złośliwe działanie, takie podejście może mieć niezamierzone konsekwencje. Może zezwalać na ruch z niezweryfikowanych lub niebezpiecznych krajów/regionów lub krajów/regionów z niskimi lub żadnymi standardami zabezpieczeń, uwidaczniając aplikację internetową w celu potencjalnych luk w zabezpieczeniach lub ataków. allow Użycie akcji dla wszystkich krajów lub regionów z wyjątkiem Stanów Zjednoczonych wskazuje zaporze aplikacji internetowej, aby zatrzymać przetwarzanie ładunków żądań względem zarządzanych zestawów reguł. Ocena wszystkich reguł kończy się po przetworzeniu reguły allow niestandardowej, co powoduje ujawnienie aplikacji niepożądanych złośliwych ataków.

Zamiast tego należy użyć bardziej restrykcyjnej i konkretnej akcji reguły, takiej jak blokowanie, i określić listę krajów lub regionów, aby zezwolić na negację warunku. Gwarantuje to, że tylko ruch z zaufanych i zweryfikowanych źródeł może uzyskiwać dostęp do aplikacji internetowej, jednocześnie blokując każdy podejrzany lub niepożądany ruch.

Treści powiązane

• Reguły niestandardowe geodopasowania
• Tworzenie i używanie reguł niestandardowych usługi Web Application Firewall w wersji 2 w usłudze Application Gateway