Usare le regole personalizzate per la corrispondenza geografica waf di Azure 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 ad eccezione di "x"
Le regole personalizzate di corrispondenza geografica risultano utili quando si mira a bloccare il traffico da tutti i paesi, con un'unica opzione. 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 ad eccezione degli Stati Uniti, vedere gli esempi di portale, Bicep e PowerShell seguenti:
Esempio di portale - gateway applicazione
Esempio di portale - Frontdoor
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 SocketAddr variabile è 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'
negationConditon: 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 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, ad eccezione di due o più specifici, destinati 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.
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 da tutti gli altri paesi. 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 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 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
Esempio di portale - Frontdoor
Esempio bicep - gateway applicazione
properties: {
customRules: [
{
name: 'GeoRule2'
priority: 11
ruleType: 'MatchRule'
action: 'Block'
matchConditions: [
{
matchVariables: [
{
variableName: 'RemoteAddr'
}
]
operator: 'GeoMatch'
negationConditon: true
matchValues: [
'US'
'CA'
]
transforms: []
}
{
matchVariables: [
{
variableName: 'RequestUri'
}
]
operator: 'Contains'
negationConditon: 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 "x"
È possibile usare regole personalizzate di corrispondenza geografica per bloccare il traffico da paesi specifici. Ad esempio, se l'applicazione Web riceve molte richieste dannose dal paese "x", creare una regola personalizzata di corrispondenza geografica per bloccare tutte le richieste da tale paese. Ciò protegge l'applicazione Web da potenziali attacchi e riduce il carico delle risorse. Applicare questo modello per bloccare più paesi dannosi o ostili. Questa tecnica richiede una condizione di corrispondenza per il modello di traffico. Per bloccare il traffico dal paese "x", vedere gli esempi seguenti di portale, Bicep e Azure PowerShell.
Esempio di portale - gateway applicazione
Esempio di portale - Frontdoor
Esempio bicep - gateway applicazione
properties: {
customRules: [
{
name: 'GeoRule3'
priority: 12
ruleType: 'MatchRule'
action: 'Block'
matchConditions: [
{
matchVariables: [
{
variableName: 'RemoteAddr'
}
]
operator: 'GeoMatch'
negationConditon: 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 dai paesi desiderati e waf blocca tutto l'altro traffico.
Scenario 4: consentire il traffico dal paese "x"
Evitare di impostare la regola personalizzata di corrispondenza geografica per consentire il traffico da un paese specifico. 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, 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 da escludere quando si usano regole personalizzate per la corrispondenza geografica. Ad esempio, se si vuole consentire il traffico da tutti i paesi ad eccezione del Stati Uniti, in cui si sospetta attività dannosa, questo approccio può avere conseguenze impreviste. Potrebbe consentire il traffico da paesi o paesi non sicuri o non sicuri con 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, ad eccezione degli Stati Uniti, indica al WAF di interrompere l'elaborazione allow dei payload delle richieste nei set di regole gestite. 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 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.