Verwenden von benutzerdefinierten Geomatch-Regeln von Azure WAF zur Verbesserung der Netzwerksicherheit
Web Application Firewalls (WAFs) sind ein wichtiges Tool zum Schutz von Webanwendungen vor schädlichen Angriffen. Sie können Webdatenverkehr mit voreingestellten und benutzerdefinierten Regeln filtern, überwachen und beenden. Sie können eine eigene Regel erstellen, die von der WAF für jede erhaltene Anforderung überprüft wird. Benutzerdefinierte Regeln haben eine höhere Priorität als die verwalteten Regeln und werden zuerst überprüft.
Eines der wichtigsten Features von Azure Web Application Firewall sind die benutzerdefinierten Geomatch-Regeln. Mit diesen Regeln können Sie Webanforderungen dem geografischen Standort zuordnen, von dem sie stammen. Sie könnten Anforderungen von bestimmten Orten beenden, die für schädliche Aktivitäten bekannt sind, oder auch Anforderungen von wichtigen Orten für Ihr Unternehmen zulassen. Benutzerdefinierte Geomatch-Regeln können auch dabei helfen, Gesetze bezüglich Datenhoheit und Datenschutz einzuhalten, indem Sie den Zugriff auf Ihre Webanwendungen basierend auf dem Benutzerstandort einschränken.
Verwenden Sie den Parameter „priority“ bei benutzerdefinierten Geomatch-Regeln mit Bedacht, um unnötige Prozesse oder Konflikte zu vermeiden. Die Reihenfolge, in der Regeln von Azure WAF ausgewertet werden, wird durch den Parameter „priority“ bestimmt. Er hat einen numerischen Wert zwischen 1 und 100, wobei niedrigere Werte einer höheren Priorität entsprechen. Die Priorität muss für alle benutzerdefinierten Regeln eindeutig sein. Weisen Sie kritischen oder spezifischen Regeln für die Webanwendungssicherheit höhere Priorität zu und senken Sie die Priorität für weniger wichtige oder allgemeine Regeln. Das stellt sicher, dass WAF die am besten geeigneten Aktionen auf Ihren Webdatenverkehr anwendet. So ist beispielsweise das Szenario, in dem Sie einen expliziten URI-Pfad identifizieren, das spezifischste und sollte eine Regel mit einer höheren Priorität haben als andere Mustertypen. Dadurch wird ein kritischer Pfad der Anwendung mit der höchsten Priorität geschützt, während allgemeiner Datenverkehr mit anderen benutzerdefinierten Regeln oder verwalteten Regelsätzen ausgewertet werden kann.
Damit der Absatz für ein technisches Publikum leichter verständlich ist, können Sie ihn wie folgt im Präsens Aktiv umformulieren:
Sie sollten Ihre Regeln immer testen, bevor Sie sie auf die Produktion anwenden, und ihre Leistung und Auswirkungen regelmäßig überprüfen. Befolgen Sie diese Best Practices, um die Webanwendungssicherheit mit den Vorteilen von benutzerdefinierten Geomatch-Regeln zu verbessern.
In diesem Artikel werden benutzerdefinierte Geomatch-Regeln von Azure WAF vorgestellt und es wird erläutert, wie Sie diese mit dem Azure-Portal, Bicep und Azure PowerShell erstellen und verwalten können.
Muster für benutzerdefinierte Geomatch-Regeln
Mit benutzerdefinierten Geomatch-Regeln können Sie verschiedene Sicherheitsziele erreichen, z. B. das Blockieren von Anforderungen aus Risikogebieten und das Zulassen von Anforderungen von vertrauenswürdigen Standorten. Sie sind besonders effektiv bei der Abwehr von verteilten Denial-of-Service(DDoS)-Angriffen, mit denen versucht wird, Ihre Webanwendung mit einer großen Anzahl von Anforderungen aus verschiedenen Quellen zu überfluten. Mit benutzerdefinierten Geomatch-Regeln können Sie Regionen, aus denen der Großteil des DDoS-Datenverkehrs stammt, umgehend ermitteln und blockieren, während legitimen Benutzern der Zugriff weiterhin gestattet wird. In diesem Artikel erfahren Sie mehr über verschiedene Muster für benutzerdefinierte Geomatch-Regeln, mit denen Sie Azure WAF optimieren können.
Szenario 1 – Blockieren des Datenverkehrs aus allen Ländern außer „x“
Benutzerdefinierte Geomatch-Regeln sind nützlich, wenn der Datenverkehr aus allen Ländern – außer einem bestimmten – blockiert werden soll. Wenn Ihre Webanwendung z. B. ausschließlich für Benutzer in den USA bestimmt ist, können Sie eine benutzerdefinierte Geomatch-Regel formulieren, die alle Anforderungen blockiert, die nicht aus den USA stammen. Diese Strategie minimiert effektiv die Angriffsfläche Ihrer Webanwendung und verhindert nicht autorisierten Zugriff aus anderen Regionen. Diese spezielle Technik verwendet eine negierte Bedingung, um dieses Datenverkehrsmuster zu unterstützen. Um eine benutzerdefinierte Geomatch-Regel zu erstellen, die den Datenverkehr aus allen Ländern außer den USA blockiert, beachten Sie die folgenden Beispiele für Portal, Bicep und PowerShell:
Portal-Beispiel – Application Gateway
Portal-Beispiel – Front Door
Hinweis
Beachten Sie, dass Sie in der Azure Front Door-WAF SocketAddr als Übereinstimmungsvariable und nicht RemoteAddr verwenden. Die Variable RemoteAddr ist die ursprüngliche Client-IP-Adresse, die normalerweise über den X-Forwarded-For-Anforderungsheader gesendet wird. Die SocketAddr-Variable ist die Quell-IP-Adresse, die die WAF sieht.
Bicep-Beispiel – 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-Beispiel – 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-Beispiel – 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-Beispiel – 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
Szenario 2 – Blockieren des Datenverkehrs aus allen Ländern außer „x“ und „y“, der auf den URI „foo“ oder „bar“ abzielt
Stellen Sie sich ein Szenario vor, in dem Sie benutzerdefinierte Geomatch-Regeln verwenden müssen, um den Datenverkehr aus allen Ländern zu blockieren, mit Ausnahme des Datenverkehrs aus zwei oder mehr bestimmten Ländern, der auf einen bestimmten URI abzielt. Angenommen, Ihre Webanwendung hat bestimmte URI-Pfade, die nur für Benutzer in den USA und Kanada vorgesehen sind. In diesem Fall erstellen Sie eine benutzerdefinierte Geomatch-Regel, die alle Anforderungen blockiert, die nicht aus diesen Ländern stammen.
Dieses Muster verarbeitet Anforderungsnutzdaten aus den USA und Kanada über die verwalteten Regelsätze, wobei alle böswilligen Angriffe abgefangen werden, während die Anforderungen aus allen anderen Ländern blockiert werden. Dieser Ansatz stellt sicher, dass nur Ihre Zielgruppe auf Ihre Webanwendung zugreifen kann, während unerwünschter Datenverkehr aus anderen Regionen verhindert wird.
Um potenzielle False Positives zu minimieren, nehmen Sie die Landeskennzahl ZZ in die Liste auf, um IP-Adressen festzuhalten, die im Azure-Dataset noch keinem Land zugeordnet sind. Diese Technik verwendet eine negierte Bedingung für den Geolocation-Typ und eine nicht negierte Bedingung für die URI-Übereinstimmung.
Um eine benutzerdefinierte Geomatch-Regel zu erstellen, die Datenverkehr aus allen Ländern außer den USA und Kanada zu einem angegebenen URI blockiert, beachten Sie die folgenden Beispiele für Portal, Bicep und Azure PowerShell.
Portal-Beispiel – Application Gateway
Portal-Beispiel – Front Door
Bicep-Beispiel – 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-Beispiel – 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-Beispiel – 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-Beispiel – 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
Szenario 3 – Blockieren des Datenverkehrs aus dem spezifischen Land „x“
Sie können benutzerdefinierte Geomatch-Regeln verwenden, um Datenverkehr aus spezifischen Ländern zu blockieren. Wenn Ihre Webanwendung beispielsweise viele böswillige Anforderungen aus dem Land „x“ empfängt, können Sie eine benutzerdefinierte Geomatch-Regel erstellen, um alle Anforderungen aus diesem Land zu blockieren. Dadurch wird Ihre Webanwendung vor potenziellen Angriffen geschützt und die Ressourcenlast reduziert. Wenden Sie dieses Muster an, um böswillige oder feindliche Angriffe aus mehreren Ländern zu blockieren. Diese Technik erfordert eine Vergleichsbedingung für das Datenverkehrsmuster. Um Datenverkehr aus dem Land „x“ zu blockieren, beachten Sie die folgenden Beispiele für Portal, Bicep und Azure PowerShell.
Portal-Beispiel – Application Gateway
Portal-Beispiel – Front Door
Bicep-Beispiel – 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-Beispiel – 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-Beispiel – 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-Beispiel – 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
Antimuster für benutzerdefinierte Geomatch-Regeln
Vermeiden Sie Antimuster bei der Verwendung von benutzerdefinierten Geomatch-Regeln wie das Festlegen der Aktion für die benutzerdefinierte Regel auf allow anstelle von block. Das kann unbeabsichtigte Folgen haben, z. B. dass der Datenverkehr die WAF umgehen kann und Ihre Webanwendung anderen Bedrohungen ausgesetzt wird.
Anstatt die Aktion allow zu verwenden, verwenden Sie die Aktion block mit einer negierten Bedingung, wie in den vorhergehenden Mustern gezeigt. Das stellt sicher, dass nur Datenverkehr aus den gewünschten Ländern zugelassen wird und die WAF den gesamten anderen Datenverkehr blockiert.
Szenario 4 – Zulassen des Datenverkehrs aus dem Land „x“
Vermeiden Sie es, die benutzerdefinierte Geomatch-Regel so zu konfigurieren, dass der Datenverkehr aus einem bestimmten Land zugelassen wird. Wenn Sie beispielsweise den Datenverkehr aus den USA wegen der großen Kundenbasis zulassen möchten, könnte es sinnvoll erscheinen, eine benutzerdefinierte Regel mit der Aktion allow und dem Wert United States zu erstellen. Diese Regel lässt jedoch den gesamten Datenverkehr aus den USA zu, unabhängig davon, ob er schädliche Nutzdaten enthält oder nicht, da mit der Aktion allow die weitere Regelverarbeitung von verwalteten Regelsätzen umgangen wird. Zudem verarbeitet die WAF weiterhin Datenverkehr aus allen anderen Ländern und verbraucht Ressourcen. Dadurch wird Ihre Webanwendung böswilligen Anforderungen aus den USA ausgesetzt, die die WAF sonst blockieren würde.
Szenario 5 – Zulassen des Datenverkehrs aus allen Ländern außer „x“
Wenn Sie benutzerdefinierte Geomatch-Regeln verwenden, sollten Sie es vermeiden, die Regelaktion auf allow festzulegen und eine Liste von Ländern anzugeben, die ausgeschlossen werden sollen. Wenn Sie beispielsweise den Datenverkehr aus allen Ländern außer den USA zulassen möchten, wo Sie böswillige Aktivitäten vermuten, kann dieser Ansatz unbeabsichtigte Folgen haben. Dadurch kann Datenverkehr aus nicht überprüften oder unsicheren Ländern oder Ländern mit niedrigen oder ohne Sicherheitsstandards zugelassen werden, wodurch Ihre Webanwendung potenziellen Sicherheitsrisiken oder Angriffen ausgesetzt wird. Wenn Sie die Aktion allow für alle Länder außer die USA verwenden, wird die WAF angewiesen, Anforderungsdaten nicht mehr mit verwalteten Regelsätzen zu verarbeiten. Alle Regelauswertungen werden eingestellt, sobald die benutzerdefinierte Regel mit allow verarbeitet wird, wodurch die Anwendung unerwünschten böswilligen Angriffen ausgesetzt wird.
Verwenden Sie stattdessen eine restriktivere und spezifischere Regelaktion, beispielsweise „block“, und geben Sie eine Liste der zugelassenen Länder mit einer negierten Bedingung an. Dadurch wird sichergestellt, dass nur Datenverkehr von vertrauenswürdigen und bestätigten Quellen auf Ihre Webanwendung zugreifen kann, während verdächtiger oder unerwünschter Datenverkehr blockiert wird.