Använda anpassade Azure WAF-geomatchningsregler för att förbättra nätverkssäkerheten
Brandväggar för webbprogram (WAFs) är ett viktigt verktyg som skyddar webbprogram från skadliga attacker. De kan filtrera, övervaka och stoppa webbtrafik med både förinställda och anpassade regler. Du kan skapa en egen regel som WAF söker efter varje begäran den får. Anpassade regler har högre prioritet än de hanterade reglerna och kontrolleras först.
En av de mest kraftfulla funktionerna i Azure Web Application Firewall är geomatchade anpassade regler. Med de här reglerna kan du matcha webbbegäranden med den geografiska platsen där de kommer ifrån. Du kanske vill stoppa begäranden från vissa platser som är kända för skadlig aktivitet, eller så kanske du vill tillåta begäranden från platser som är viktiga för ditt företag. Geomatch anpassade regler kan också hjälpa dig att följa lagar om datasuveränitet och sekretess genom att begränsa åtkomsten till dina webbprogram baserat på platsen för de personer som använder dem.
Använd prioritetsparametern klokt när du använder anpassade geomatchningsregler för att undvika onödig bearbetning eller konflikter. Azure WAF utvärderar regler i den ordning som bestäms av prioritetsparametern, ett numeriskt värde mellan 1 och 100, med lägre värden som anger högre prioritet. Prioriteten måste vara unik för alla anpassade regler. Tilldela högre prioritet till kritiska eller specifika regler för din webbprogramsäkerhet och lägre prioritet till mindre viktiga eller allmänna regler. Detta säkerställer att WAF tillämpar de lämpligaste åtgärderna på din webbtrafik. Scenariot där du identifierar en explicit URI-sökväg är till exempel den mest specifika och bör ha en regel med högre prioritet än andra typer av mönster. Detta skyddar en kritisk sökväg i programmet med högsta prioritet samtidigt som mer allmän trafik kan utvärderas över andra anpassade regler eller hanterade regeluppsättningar.
Om du vill göra stycket lättare att förstå för en teknisk publik med nuvarande tempus och aktiv röst kan du skriva om det på följande sätt:
Testa alltid dina regler innan du tillämpar dem på produktion och övervaka regelbundet deras prestanda och påverkan. Genom att följa dessa metodtips kan du förbättra säkerheten för webbprogram med hjälp av kraften i anpassade geomatchningsregler.
Den här artikeln beskriver anpassade regler för Azure WAF-geomatchning och visar hur du skapar och hanterar dem med hjälp av Azure-portalen, Bicep och Azure PowerShell.
Anpassade regelmönster för geomatchning
Med anpassade geomatchningsregler kan du uppfylla olika säkerhetsmål, till exempel blockera begäranden från högriskområden och tillåta begäranden från betrodda platser. De är särskilt effektiva när det gäller att minimera DDoS-attacker (Distributed Denial-of-Service), som försöker översvämma webbappen med en mängd förfrågningar från olika källor. Med anpassade geomatchningsregler kan du snabbt hitta och blockera regioner som genererar mest DDoS-trafik, samtidigt som du ger åtkomst till legitima användare. I den här artikeln får du lära dig mer om olika anpassade regelmönster som du kan använda för att optimera din Azure WAF med hjälp av geomatchade anpassade regler.
Scenario 1 – Blockera trafik från alla länder utom "x"
Geomatch anpassade regler visar sig vara användbara när du vill blockera trafik från alla länder, med undantag för en. Om ditt webbprogram till exempel uteslutande vänder sig till användare i USA kan du formulera en anpassad geomatchningsregel som hindrar alla begäranden som inte kommer från USA. Den här strategin minimerar effektivt ditt webbprograms attackyta och avskräcker obehörig åtkomst från andra regioner. Den här specifika tekniken använder ett negeringsvillkor för att underlätta det här trafikmönstret. Om du vill skapa en anpassad geomatchningsregel som hindrar trafik från alla länder utom USA läser du följande portal, Bicep och PowerShell-exempel:
Portalexempel – Application Gateway
Portalexempel – Front Door
Kommentar
Observera på Azure Front Door WAF att du använder SocketAddr som matchningsvariabel och inte RemoteAddr. Variabeln RemoteAddr är den ursprungliga klientens IP-adress som vanligtvis skickas via begärandehuvudet X-Forwarded-For . Variabeln SocketAddr är källans IP-adress som WAF ser.
Bicep-exempel – Application Gateway
properties: {
customRules: [
{
name: 'GeoRule1'
priority: 10
ruleType: 'MatchRule'
action: 'Block'
matchConditions: [
{
matchVariables: [
{
variableName: 'RemoteAddr'
}
]
operator: 'GeoMatch'
negationConditon: true
matchValues: [
'US'
]
transforms: []
}
]
state: 'Enabled'
}
Bicep-exempel – Front Door
properties: {
customRules: {
rules: [
{
name: 'GeoRule1'
enabledState: 'Enabled'
priority: 10
ruleType: 'MatchRule'
matchConditions: [
{
matchVariable: 'SocketAddr'
operator: 'GeoMatch'
negateCondition: true
matchValue: [
'US'
]
transforms: []
}
]
action: 'Block'
}
Azure PowerShell-exempel – Application Gateway
$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
Azure PowerShell-exempel – Front Door
$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 – Blockera trafik från alla länder utom "x" och "y" som riktar sig mot URI:n "foo" eller "bar"
Tänk dig ett scenario där du behöver använda anpassade geomatchningsregler för att blockera trafik från alla länder, förutom två eller flera specifika, som riktar sig mot en specifik URI. Anta att ditt webbprogram har specifika URI-sökvägar som endast är avsedda för användare i USA och Kanada. I det här fallet skapar du en anpassad geomatchningsregel som blockerar alla begäranden som inte kommer från dessa länder.
Det här mönstret bearbetar begärandenyttolaster från USA och Kanada via de hanterade regeluppsättningarna, fångar eventuella skadliga attacker och blockerar begäranden från alla andra länder. Den här metoden säkerställer att endast målgruppen kan komma åt ditt webbprogram och undvika oönskad trafik från andra regioner.
För att minimera potentiella falska positiva identifieringar inkluderar du landskoden ZZ i listan för att samla in IP-adresser som ännu inte har mappats till ett land i Azures datauppsättning. Den här tekniken använder ett negatvillkor för geoplatstypen och ett icke-negatvillkor för URI-matchningen.
Om du vill skapa en anpassad geomatchningsregel som blockerar trafik från alla länder utom USA och Kanada till en angiven URI läser du exemplen portal, Bicep och Azure PowerShell.
Portalexempel – Application Gateway
Portalexempel – Front Door
Bicep-exempel – Application Gateway
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'
}
Bicep-exempel – Front Door
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'
}
Azure PowerShell-exempel – Application Gateway
$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
Azure PowerShell-exempel – Front Door
$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 – Blockera trafik specifikt från land "x"
Du kan använda anpassade geomatchningsregler för att blockera trafik från specifika länder. Om webbprogrammet till exempel tar emot många skadliga begäranden från landet "x" skapar du en anpassad geomatchregel för att blockera alla begäranden från det landet. Detta skyddar ditt webbprogram från potentiella attacker och minskar resursbelastningen. Använd det här mönstret för att blockera flera skadliga eller fientliga länder. Den här tekniken kräver ett matchningsvillkor för trafikmönstret. Information om hur du blockerar trafik från land "x" finns i följande portal, Bicep och Azure PowerShell-exempel.
Portalexempel – Application Gateway
Portalexempel – Front Door
Bicep-exempel – Application Gateway
properties: {
customRules: [
{
name: 'GeoRule3'
priority: 12
ruleType: 'MatchRule'
action: 'Block'
matchConditions: [
{
matchVariables: [
{
variableName: 'RemoteAddr'
}
]
operator: 'GeoMatch'
negationConditon: false
matchValues: [
'US'
]
transforms: []
}
]
state: 'Enabled'
}
Bicep-exempel – Front Door
properties: {
customRules: {
rules: [
{
name: 'GeoRule3'
enabledState: 'Enabled'
priority: 12
ruleType: 'MatchRule'
matchConditions: [
{
matchVariable: 'SocketAddr'
operator: 'GeoMatch'
negateCondition: false
matchValue: [
'US'
]
transforms: []
}
]
action: 'Block'
}
Azure PowerShell-exempel – Application Gateway
$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
Azure PowerShell-exempel – Front Door
$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
Geomatcha anpassade regelskyddsmönster
Undvik antimönster när du använder anpassade geomatchningsregler, till exempel om du anger åtgärden för anpassad regel till allow i stället blockför . Detta kan få oavsiktliga konsekvenser, till exempel att tillåta trafik att kringgå WAF och potentiellt exponera ditt webbprogram för andra hot.
I stället för att använda en allow åtgärd använder du en block åtgärd med ett negatvillkor, som du ser i tidigare mönster. Detta säkerställer att endast trafik från önskade länder tillåts och WAF blockerar all annan trafik.
Scenario 4 – tillåt trafik från land "x"
Undvik att ange den anpassade geomatchningsregeln för att tillåta trafik från ett visst land. Om du till exempel vill tillåta trafik från USA på grund av en stor kundbas skapar du en anpassad regel med åtgärden allow och värdet United States kan verka som lösningen. Den här regeln tillåter dock all trafik från USA, oavsett om den har en skadlig nyttolast eller inte, eftersom allow åtgärden kringgår ytterligare regelbearbetning av hanterade regeluppsättningar. Dessutom bearbetar WAF fortfarande trafik från alla andra länder och förbrukar resurser. Detta exponerar ditt webbprogram för skadliga begäranden från USA som WAF annars skulle blockera.
Scenario 5 – Tillåt trafik från alla län utom "x"
Undvik att ange regelåtgärden till allow och ange en lista över länder som ska undantas när du använder anpassade geomatchningsregler. Om du till exempel vill tillåta trafik från alla länder utom USA, där du misstänker skadlig aktivitet, kan den här metoden få oavsiktliga konsekvenser. Det kan tillåta trafik från overifierade eller osäkra länder eller länder med låga eller inga säkerhetsstandarder, vilket exponerar ditt webbprogram för potentiella sårbarheter eller attacker. Att använda åtgärden allow för alla länder utom USA anger för WAF att sluta bearbeta nyttolaster för begäranden mot hanterade regeluppsättningar. Alla regelutvärderingar upphör när den anpassade regeln med allow har bearbetats och exponerar programmet för oönskade skadliga attacker.
Använd i stället en mer restriktiv och specifik regelåtgärd, till exempel blockera, och ange en lista över länder som ska tillåtas med ett negatvillkor. Detta säkerställer att endast trafik från betrodda och verifierade källor kan komma åt webbprogrammet samtidigt som misstänkt eller oönskad trafik blockeras.