Utiliser des règles personnalisées de géo-correspondance du pare-feu d’applications web Azure pour améliorer la sécurité réseau
Les pare-feu d’applications web (WAF) constituent un outil important qui contribue à protéger les applications web contre les attaques dangereuses. Ils ont la capacité de filtrer, surveiller et arrêter le trafic web à l’aide de règles prédéfinies et personnalisées. Vous pouvez établir votre propre règle qui sera vérifiée par le WAF à chaque requête qu’il reçoit. Les règles personnalisées ont une priorité plus élevée que les règles managées et sont vérifiées en premier.
Parmi les fonctionnalités les plus puissantes d’Azure Web Application Firewall figurent les règles personnalisées de géo-correspondance. Ces règles vous permettent de faire correspondre les requêtes web à l’emplacement géographique dont elles proviennent. Vous pouvez arrêter les requêtes de certaines provenances connues pour leurs activités dangereuses ou autoriser celles issues de provenances importantes pour votre activité. Les règles personnalisées de géo-correspondance peuvent également vous aider à vous mettre en conformité avec les lois de souveraineté et de confidentialité des données en limitant l’accès à vos applications web en fonction de la localisation des personnes qui les utilisent.
Pour éviter les traitements ou conflits inutiles, utilisez le paramètre de priorité à bon escient lorsque vous employez des règles personnalisées de géo-correspondance. Le pare-feu d’applications web Azure évalue les règles selon l’ordre déterminé par le paramètre de priorité, dont la valeur numérique peut varier de 1 à 100, la plus faible représentant la priorité plus élevée. La priorité de chaque règle personnalisée doit être unique (vous ne pouvez pas utiliser la même valeur pour chaque règle). Attribuez une haute priorité aux règles critiques ou spécifiques pour la sécurité de votre application web et une basse priorité aux règles moins essentielles ou générales. Vous serez ainsi assuré que le WAF appliquera les actions les plus appropriées à votre trafic web. Par exemple, le scénario où vous identifiez un chemin d’URI explicite s’avère le plus spécifique et doit disposer d’une règle de priorité plus élevée que les autres types de modèles. Ceci permet de protéger un chemin critique de l’application avec la priorité la plus élevée tout en permettant au trafic plus générique d’être évalué par d’autres règles personnalisées ou ensembles de règles managés.
Pour faciliter la compréhension du paragraphe pour un public de techniciens avec l’emploi du présent et de la voix active, vous pouvez le réécrire de la façon suivante :
Veillez à toujours tester vos règles avant de les appliquer en production et surveillez régulièrement leur fonctionnement et leur impact. En suivant ces meilleures pratiques, vous pouvez améliorer la sécurité de votre application web en tirant parti de la puissance des règles personnalisées de géo-correspondance.
Cet article présente les règles personnalisées de géo-correspondance du pare-feu d’applications web Azure et vous montre comment les créer et les gérer à l’aide du portail Azure, de Bicep et d’Azure PowerShell.
Modèles de règles personnalisées de géo-correspondance
Les règles personnalisées de géo-correspondance vous permettent de répondre à divers objectifs de sécurité, comme le blocage des demandes en provenance de zones à haut risque et l’autorisation des demandes issues de localisations de confiance. Elles s’avèrent particulièrement efficaces pour atténuer les effets des attaques par déni de service distribué (DDoS), qui cherchent à inonder votre application web avec une multitude de requêtes en provenance de diverses sources. Grâce aux règles personnalisées de géo-correspondance, vous pouvez identifier et bloquer rapidement les régions générant la majeure partie du trafic DDoS, tout en accordant l’accès aux utilisateurs légitimes. Dans cet article, vous allez découvrir différents modèles de règles personnalisés que vous pouvez employer pour optimiser votre pare-feu d’applications web Azure à l’aide de règles personnalisées de géo-correspondance.
Scénario 1 – Bloquer le trafic en provenance de tous les pays à l’exception de « x »
Les règles personnalisées de géo-correspondance s’avèrent utiles lorsque votre objectif est de bloquer le trafic en provenance de tous les pays, sauf un. Par exemple, si votre application web s’adresse exclusivement à des utilisateurs situés aux États-Unis, vous pouvez formuler une règle personnalisée de géo-correspondance qui bloque toutes les requêtes ne provenant pas des États-Unis. Cette stratégie réduit efficacement la surface d’attaque de votre application web et prévient les accès non autorisés depuis d’autres régions. Cette technique spécifique emploie une condition de négation pour faciliter ce modèle de trafic. Pour créer une règle personnalisée de géo-correspondance qui bloque le trafic en provenance de tous les pays à l’exception des États-Unis, consultez les exemples de portail, Bicep et PowerShell suivants :
Exemple de portail – Application Gateway
Exemple de portail – Front Door
Remarque
Notez que pour le pare-feu d’applications web Azure Front Door, vous utilisez SocketAddr comme variable de correspondance et non RemoteAddr. La variable RemoteAddr est l’adresse IP du client d’origine qui est généralement envoyée via l’en-tête de demande X-Forwarded-For. La variable SocketAddr est l'adresse IP source que le WAF voit.
Exemple 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'
}
Exemple 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'
}
Exemple 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
Exemple 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
Scénario 2 : Bloquer le trafic en provenance de tous les pays à l’exception de « x » et « y » qui ciblent l’URI « foo » ou « bar »
Envisagez un scénario où vous devez utiliser des règles personnalisées de géo-correspondance pour bloquer le trafic en provenance de tous les pays, à l’exception de deux pays (ou plus) spécifiques, ciblant un URI spécifique. Supposez que votre application web possède des chemins d’URI spécifiques qui s’adressent uniquement à des utilisateurs basés aux États-Unis et au Canada. Dans ce cas, vous créez une règle personnalisée de géo-correspondance qui bloque toutes les requêtes ne provenant pas de ces pays.
Ce modèle traite les charges utiles de requêtes en provenance des États-Unis et du Canada via les ensembles de règles managés, interceptant ainsi les attaques malveillantes tout en bloquant les requêtes en provenance de tous les autres pays. Grâce à cette approche, vous avez la garantie que seul votre public cible peut accéder à votre application web et que le trafic indésirable en provenance d’autres régions est évité.
Pour réduire les faux positifs potentiels, incluez le code pays ZZ dans la liste pour capturer les adresses IP qui ne sont pas encore mappées à un pays dans le jeu de données Azure. Cette technique utilise une condition de négation pour le type de géolocalisation et une condition de non-négation pour la correspondance d’URI.
Pour créer une règle personnalisée de géo-correspondance qui bloque le trafic de tous les pays, à l’exception des États-Unis et du Canada, pour un URI spécifié, reportez-vous aux exemples de portail, Bicep et Azure PowerShell fournis.
Exemple de portail – Application Gateway
Exemple de portail – Front Door
Exemple 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'
}
Exemple 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'
}
Exemple 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
Exemple 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
Scénario 3 : Bloquer le trafic provenant précisément d’un pays « x »
Vous pouvez utiliser des règles personnalisées de géo-correspondance pour bloquer le trafic provenant de pays spécifiques. Par exemple, si votre application web reçoit de nombreuses requêtes malveillantes du pays « x », créez une règle personnalisée de géo-correspondance pour bloquer toutes les requêtes en provenance de ce pays. Vous protégerez ainsi votre application web contre les attaques potentielles et réduirez la charge des ressources. Appliquez ce modèle pour bloquer plusieurs pays malveillants ou hostiles. Cette technique nécessite une condition de correspondance pour le modèle de trafic. Pour bloquer le trafic en provenance du pays « x », consultez les exemples de portail, Bicep et Azure PowerShell suivants.
Exemple de portail – Application Gateway
Exemple de portail – Front Door
Exemple 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'
}
Exemple 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'
}
Exemple 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
Exemple 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
Anti-modèles de règles personnalisées de géo-correspondance
Évitez les anti-modèles lorsque vous utilisez des règles personnalisées de géo-correspondance, notamment en définissant l’action de règle personnalisée sur allow au lieu de block. Cela peut avoir des conséquences inattendues, comme autoriser le trafic à contourner le WAF et potentiellement d’exposer votre application web à d’autres menaces.
Au lieu d’utiliser une action allow, utilisez une action block avec une condition de négation, comme dans les modèles précédents. Vous aurez ainsi la garantie que seul le trafic en provenance des pays souhaités sera autorisé et que le WAF bloquera tout le reste du trafic.
Scénario 4 : Autoriser le trafic en provenance du pays « x »
Évitez de définir la règle personnalisée de géo-correspondance pour autoriser le trafic en provenance d’un pays spécifique. Par exemple, si vous souhaitez autoriser le trafic provenant des États-Unis du fait de son clientèle importante, la création d’une règle personnalisée avec l’action allow et la valeur United States peut sembler être la solution. Cependant, cette règle autorise l’ensemble du trafic en provenance des États-Unis, qu’il comporte une charge utile malveillante ou non, car l’action allow contourne tout traitement de règle supplémentaire pour les ensembles de règles managés. De plus, le WAF continue de traiter le trafic de tous les autres pays, ce qui consomme des ressources. Votre application web est alors exposée aux requêtes malveillantes en provenance des États-Unis qui auraient autrement été bloquées par le WAF.
Scénario 5 : Autoriser le trafic en provenance de tous les pays à l’exception de « x »
Évitez de définir l’action de règle sur allow et de spécifier une liste de pays à exclure lorsque vous utilisez des règles personnalisées de géo-correspondance. Par exemple, si vous souhaitez autoriser le trafic en provenance de tous les pays à l’exception des États-Unis, où vous suspectez une activité malveillante, cette approche peut avoir des conséquences inattendues. Le risque est que soit autorisé le trafic en provenance de pays non vérifiés ou peu sûrs ou dont les normes de sécurité sont faibles voire inexistantes, ce qui exposerait votre application web à des vulnérabilités ou attaques potentielles. L’utilisation de l’action allow pour tous les pays à l’exception des États-Unis indique au WAF d’arrêter le traitement des charges utiles de requêtes pour les ensembles de règles managés. Toute l’évaluation de règles cesse une fois que la règle personnalisée avec allow a été traitée, ce qui expose l’application aux attaques malveillantes indésirables.
Utilisez plutôt une action de règle plus restrictive et spécifique, telle que block, et spécifiez une liste de pays à autoriser avec une condition de négation. Vous serez ainsi assuré que seul le trafic en provenance de sources fiables et vérifiées peut accéder à votre application web tout en bloquant le trafic suspect ou indésirable.