Używanie niestandardowych reguł geomatchu zapory aplikacji internetowej platformy Azure w celu zwiększenia bezpieczeństwa sieci
Zapory aplikacji internetowych to ważne narzędzie, które pomaga chronić aplikacje internetowe przed szkodliwymi atakami. Mogą 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ł. Gwarantuje to, że zapora aplikacji internetowej stosuje najbardziej odpowiednie działania 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. Chroni to ścieżkę krytyczną w aplikacji z najwyższym priorytetem, umożliwiając ocenę ruchu bardziej ogólnego w innych regułach niestandardowych lub zarządzanych zestawach reguł.
Aby ułatwić zrozumienie akapitu dla odbiorców technicznych przy użyciu napiętego i aktywnego głosu, możesz napisać go ponownie w następujący sposób:
Zawsze testuj reguły przed zastosowaniem ich do środowiska produkcyjnego i regularnie monitoruj ich wydajność i wpływ. Korzystając z tych najlepszych rozwiązań, możesz zwiększyć bezpieczeństwo aplikacji internetowej przy użyciu możliwości niestandardowych reguł geomatch.
W tym artykule przedstawiono niestandardowe reguły geomatchu zapory aplikacji internetowej platformy Azure i pokazano, jak tworzyć je i zarządzać nimi przy użyciu witryny Azure Portal, aplikacji Bicep i programu 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 szczególnie 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 z wyjątkiem "x"
Niestandardowe reguły geomatchu są przydatne, gdy chcesz zablokować ruch ze wszystkich krajó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łę geomatchu, która utrudnia ruch ze wszystkich krajów z wyjątkiem Stanów Zjednoczonych, zapoznaj się z następującymi przykładami portalu, Bicep i programu PowerShell:
Przykład portalu — Application Gateway
Przykład portalu — Front Door
Uwaga
Zwróć uwagę na zaporę aplikacji internetowej usługi Azure Front Door, która jest używana SocketAddr jako zmienna 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.
Przykład Bicep — 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'
}
Przykład Bicep — 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'
}
Przykład programu Azure PowerShell — 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
Przykład programu Azure PowerShell — 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
Scenariusz 2 — blokowanie ruchu ze wszystkich krajó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ł geomatch, aby zablokować ruch ze wszystkich krajów, z wyjątkiem dwóch lub większej liczby konkretnych, 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.
Ten wzorzec przetwarza żądania ładunków z USA 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. 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 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 z wyjątkiem Stanów Zjednoczonych i Kanady do określonego identyfikatora URI, zapoznaj się z podanymi przykładami portalu, Bicep i programu Azure PowerShell.
Przykład portalu — Application Gateway
Przykład portalu — Front Door
Przykład Bicep — 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'
}
Przykład Bicep — 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'
}
Przykład programu Azure PowerShell — 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
Przykład programu Azure PowerShell — 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
Scenariusz 3 — blokowanie ruchu z kraju "x"
Możesz użyć niestandardowych reguł geograficznych, aby zablokować ruch z określonych krajów. Jeśli na przykład aplikacja internetowa odbiera wiele złośliwych żądań z kraju "x", utwórz niestandardową regułę geomatchu, aby zablokować wszystkie żądania z tego kraju. 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. Ta technika wymaga warunku dopasowania dla wzorca ruchu. Aby zablokować ruch z kraju "x", zobacz następujące przykłady: portal, Bicep i Azure PowerShell.
Przykład portalu — Application Gateway
Przykład portalu — Front Door
Przykład Bicep — 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'
}
Przykład Bicep — 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'
}
Przykład programu Azure PowerShell — 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
Przykład programu Azure PowerShell — 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
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, a zapora aplikacji internetowej blokuje cały inny ruch.
Scenariusz 4 — zezwalanie na ruch z kraju "x"
Unikaj ustawiania niestandardowej reguły niezgodności geograficznej, aby zezwolić na ruch z określonego kraju. 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, 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 do wykluczenia podczas używania niestandardowych reguł geomatch. Jeśli na przykład chcesz zezwolić na ruch ze wszystkich krajó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 lub krajów o niskich lub bez standardów zabezpieczeń, uwidaczniając aplikację internetową w potencjalnych lukach w zabezpieczeniach lub atakach. allow Użycie akcji dla wszystkich krajów z wyjątkiem STANÓW Zjednoczonych wskazuje zaporę 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, które mają zezwalać 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.