Condividi tramite


Usare regole personalizzate di corrispondenza geografica di Azure WAF per migliorare la sicurezza di rete

I web application firewall (WAF) sono uno strumento importante che consente di proteggere le applicazioni Web da attacchi dannosi. Possono filtrare, monitorare e arrestare il traffico Web usando regole predefinite e personalizzate. È possibile creare una regola personalizzata che il WAF controlla la presenza di ogni richiesta che ottiene. Le regole personalizzate hanno priorità più alta rispetto alle regole gestite e vengono controllate per prime.

Una delle funzionalità più potenti di Web application firewall di Azure è la corrispondenza geografica delle regole personalizzate. Queste regole consentono di associare le richieste Web alla posizione geografica da cui provengono. È possibile arrestare le richieste da determinate posizioni note per attività dannose oppure consentire richieste da luoghi importanti per l'azienda. Le regole personalizzate per la corrispondenza geografica consentono anche di seguire la sovranità dei dati e le leggi sulla privacy limitando l'accesso alle applicazioni Web in base alla posizione delle persone che le usano.

Usare il parametro priority in modo saggio quando si usano regole personalizzate per la corrispondenza geografica per evitare conflitti o elaborazioni non necessarie. Azure WAF valuta le regole nell'ordine determinato dal parametro priority, un valore numerico compreso tra 1 e 100, con valori inferiori che indicano una priorità più alta. La priorità deve essere univoca in tutte le regole personalizzate. Assegnare priorità più alta a regole critiche o specifiche per la sicurezza delle applicazioni Web e priorità inferiore a regole meno essenziali o generali. In questo modo WAF applica le azioni più appropriate al traffico Web. Ad esempio, lo scenario in cui si identifica un percorso URI esplicito è il più specifico e deve avere una regola di priorità più alta rispetto ad altri tipi di modelli. In questo modo viene protetto un percorso critico nell'applicazione con la priorità più alta, consentendo al contempo la valutazione di un traffico più generico tra altre regole personalizzate o set di regole gestite.

Per semplificare la comprensione del paragrafo per un pubblico tecnico usando la voce attuale e attiva, è possibile riscriverla nel modo seguente:

Testare sempre le regole prima di applicarle all'ambiente di produzione e monitorare regolarmente le prestazioni e l'impatto. Seguendo queste procedure consigliate, è possibile migliorare la sicurezza delle applicazioni Web usando la potenza delle regole personalizzate di corrispondenza geografica.

Questo articolo presenta le regole personalizzate di corrispondenza geografica waf di Azure e illustra come crearle e gestirle usando le portale di Azure, Bicep e Azure PowerShell.

Modelli di regole personalizzate di corrispondenza geografica

Le regole personalizzate di corrispondenza geografica consentono di soddisfare obiettivi di sicurezza diversi, ad esempio bloccare le richieste da aree ad alto rischio e consentire richieste da posizioni attendibili. Sono particolarmente efficaci per mitigare gli attacchi DDoS (Distributed Denial of Service), che cercano di inondare l'applicazione Web con numerose richieste provenienti da diverse origini. Con le regole personalizzate di corrispondenza geografica, è possibile individuare e bloccare tempestivamente le aree che generano il traffico DDoS più grande, concedendo comunque l'accesso a utenti legittimi. In questo articolo vengono illustrati i vari modelli di regole personalizzate che è possibile usare per ottimizzare Azure WAF usando regole personalizzate di corrispondenza geografica.

Scenario 1 - Bloccare il traffico da tutti i paesi o aree geografiche ad eccezione di "x"

Le regole personalizzate di corrispondenza geografica risultano utili quando si mira a bloccare il traffico da tutti i paesi o le aree geografiche, bloccando uno. Ad esempio, se l'applicazione Web si rivolge esclusivamente agli utenti nel Stati Uniti, è possibile formulare una regola personalizzata di corrispondenza geografica che impedisce a tutte le richieste non provenienti dagli Stati Uniti. Questa strategia riduce al minimo la superficie di attacco dell'applicazione Web e scoraggia l'accesso non autorizzato da altre aree. Questa tecnica specifica usa una condizione di negazione per facilitare questo modello di traffico. Per la creazione di una regola personalizzata di corrispondenza geografica che impedisce il traffico da tutti i paesi o le aree geografiche, ad eccezione degli Stati Uniti, vedere gli esempi di portale, Bicep e PowerShell seguenti:

Esempio di portale - gateway applicazione

Screenshot che mostra la schermata di aggiunta di regole personalizzate gateway applicazione WAF.

Esempio di portale - Frontdoor

Screenshot che mostra la schermata Di aggiunta di regole personalizzate di Frontdoor WAF.

Nota

Si noti che il WAF di Frontdoor di Azure viene usato SocketAddr come variabile di corrispondenza e non RemoteAddr. La RemoteAddr variabile è l'indirizzo IP client originale che viene in genere inviato tramite l'intestazione della X-Forwarded-For richiesta. La variabile SocketAddr è l'indirizzo IP di origine visualizzato dal WAF.

Esempio bicep - gateway applicazione

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

Esempio bicep - Frontdoor

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

Esempio di Azure PowerShell - gateway applicazione

$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

Esempio di Azure PowerShell - Frontdoor

$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

Scenario 2- Bloccare il traffico da tutti i paesi o aree geografiche ad eccezione di "x" e "y" destinati all'URI "foo" o "bar"

Si consideri uno scenario in cui è necessario usare regole personalizzate per la corrispondenza geografica per bloccare il traffico da tutti i paesi o le aree geografiche, ad eccezione di due o più aree specifiche, destinate a un URI specifico. Si supponga che l'applicazione Web abbia percorsi URI specifici destinati solo agli utenti negli Stati Uniti e in Canada. In questo caso, si crea una regola personalizzata di corrispondenza geografica che blocca tutte le richieste non provenienti da questi paesi o aree geografiche.

Questo modello elabora i payload delle richieste dagli Stati Uniti e dal Canada tramite i set di regole gestite, intercettando eventuali attacchi dannosi, bloccando le richieste provenienti da tutti gli altri paesi o aree geografiche. Questo approccio garantisce che solo i destinatari di destinazione possano accedere all'applicazione Web, evitando il traffico indesiderato da altre aree.

Per ridurre al minimo i potenziali falsi positivi, includere il codice paese ZZ nell'elenco per acquisire gli indirizzi IP non ancora mappati a un paese o un'area geografica nel set di dati di Azure. Questa tecnica usa una condizione di negazione per il tipo di georilevazione e una condizione non negata per la corrispondenza URI.

Per creare una regola personalizzata di corrispondenza geografica che blocca il traffico da tutti i paesi o le aree geografiche, ad eccezione degli Stati Uniti e del Canada a un URI specificato, vedere gli esempi di portale, Bicep e Azure PowerShell forniti.

Esempio di portale - gateway applicazione

Screenshot che mostra l'aggiunta di una regola personalizzata per gateway applicazione.

Esempio di portale - Frontdoor

Screenshot che mostra l'aggiunta di una regola personalizzata per Frontdoor.

Esempio bicep - gateway applicazione

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

Esempio bicep - Frontdoor

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

Esempio di Azure PowerShell - gateway applicazione

$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

Esempio di Azure PowerShell - Frontdoor

$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

Scenario 3 - Bloccare il traffico in modo specifico dal paese o dall'area geografica "x"

È possibile usare regole personalizzate di corrispondenza geografica per bloccare il traffico da paesi o aree geografiche specifiche. Ad esempio, se l'applicazione Web riceve molte richieste dannose dal paese o dall'area geografica "x", creare una regola personalizzata di corrispondenza geografica per bloccare tutte le richieste provenienti da tale paese o area geografica. Ciò protegge l'applicazione Web da potenziali attacchi e riduce il carico delle risorse. Applicare questo modello per bloccare più paesi o aree dannose o ostili. Questa tecnica richiede una condizione di corrispondenza per il modello di traffico. Per bloccare il traffico dal paese o dall'area geografica "x", vedere gli esempi di portale, Bicep e Azure PowerShell seguenti.

Esempio di portale - gateway applicazione

Screenshot che mostra la schermata aggiungi regola personalizzata al gateway applicazione.

Esempio di portale - Frontdoor

Screenshot che mostra la schermata di aggiunta di regole personalizzate nella frontdoor.

Esempio bicep - gateway applicazione

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

Esempio bicep - Frontdoor

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

Esempio di Azure PowerShell - gateway applicazione

$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

Esempio di Azure PowerShell - Frontdoor

$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

Anti-pattern di regole personalizzate per la corrispondenza geografica

Evitare anti-pattern quando si usano regole personalizzate di corrispondenza geografica, ad esempio l'impostazione dell'azione della regola personalizzata su allow anziché blocksu . Ciò può avere conseguenze impreviste, ad esempio consentire al traffico di ignorare il WAF e potenzialmente esporre l'applicazione Web ad altre minacce.

Anziché usare un'azione allow , usare un'azione block con una condizione di negazione, come illustrato nei modelli precedenti. In questo modo è consentito solo il traffico proveniente da paesi o aree geografiche desiderate e il WAF blocca tutto l'altro traffico.

Scenario 4: consentire il traffico dal paese o dall'area geografica "x"

Evitare di impostare la regola personalizzata di corrispondenza geografica per consentire il traffico da un paese o un'area geografica specifica. Ad esempio, se si vuole consentire il traffico dal Stati Uniti a causa di una vasta base clienti, la creazione di una regola personalizzata con l'azione allow e il valore United States potrebbe sembrare la soluzione. Tuttavia, questa regola consente tutto il traffico dall'Stati Uniti, indipendentemente dal fatto che abbia un payload dannoso o meno, poiché l'azione allow ignora un'ulteriore elaborazione delle regole dei set di regole gestite. Inoltre, waf elabora ancora il traffico da tutti gli altri paesi o aree geografiche, consumando risorse. In questo modo l'applicazione Web viene esposta a richieste dannose dal Stati Uniti che il WAF altrimenti blocca.

Scenario 5 - Consentire il traffico da tutte le contee ad eccezione di "x"

Evitare di impostare l'azione della regola su allow e specificare un elenco di paesi o aree geografiche da escludere quando si usano regole personalizzate di corrispondenza geografica. Ad esempio, se si vuole consentire il traffico da tutti i paesi o aree geografiche ad eccezione del Stati Uniti, in cui si sospetta un'attività dannosa, questo approccio può avere conseguenze impreviste. Potrebbe consentire il traffico da paesi/aree geografiche o paesi/aree geografiche/aree geografiche non sicure senza standard di sicurezza bassi o senza standard di sicurezza, esponendo l'applicazione Web a potenziali vulnerabilità o attacchi. L'uso dell'azione per tutti i paesi o le aree geografiche, ad eccezione degli Stati Uniti, indica al WAF di interrompere l'elaborazione allow dei payload delle richieste nei set di regole gestiti. Tutte le valutazioni delle regole cessano dopo l'elaborazione della regola allow personalizzata, esponendo l'applicazione a attacchi dannosi indesiderati.

Usare invece un'azione regola più restrittiva e specifica, ad esempio il blocco, e specificare un elenco di paesi o aree geografiche da consentire con una condizione di negazione. Ciò garantisce che solo il traffico proveniente da origini attendibili e verificate possa accedere all'applicazione Web bloccando qualsiasi traffico sospetto o indesiderato.

Passaggi successivi