Stratégies de Web App Firewall

Une stratégie de pare-feu est une règle associée à un profil. La règle est une expression ou un groupe d’expressions qui définissent les types de paires demande/réponse que le Web App Firewall doit filtrer en appliquant le profil. Les expressions de stratégie de pare-feu sont écrites dans le langage des expressions Citrix ADC, un langage de programmation orienté objet avec des fonctionnalités spéciales pour prendre en charge des fonctions spécifiques de Citrix ADC. Le profil est l’ensemble d’actions que le Web App Firewall doit utiliser pour filtrer les paires demande/réponse qui correspondent à la règle.

Les stratégies de pare-feu vous permettent d’affecter différentes règles de filtrage à différents types de contenu Web. Tous les contenus Web ne se ressemblent pas. Un site Web simple qui n’utilise aucun script complexe et qui accède et ne gère aucune donnée privée peut nécessiter uniquement le niveau de protection fourni par un profil créé avec des valeurs par défaut de base. Le contenu Web qui contient des formulaires Web améliorés par Java ou qui accède à une base de données SQL nécessite probablement une protection plus personnalisée. Vous pouvez créer un profil différent pour filtrer ce contenu et créer une stratégie de pare-feu distincte qui peut déterminer quelles demandes tentent d’accéder à ce contenu. Vous associez ensuite l’expression de stratégie à un profil que vous avez créé et liez globalement la stratégie pour la mettre en œuvre.

Le Web App Firewall traite uniquement les connexions HTTP et utilise donc un sous-ensemble du langage global des expressions Citrix ADC. Les informations ici sont limitées aux rubriques et exemples susceptibles d’être utiles lors de la configuration du Web App Firewall. Vous trouverez ci-dessous des liens vers des informations supplémentaires et des procédures relatives aux stratégies de pare-feu :

Remarque

Le Web App Firewall évalue les stratégies en fonction des expressions de priorité et de goto configurées. À la fin de l’évaluation de la stratégie, la dernière stratégie évaluée à true est utilisée et la configuration de sécurité du profil correspondant est appelée pour le traitement de la demande.

Par exemple, considérez un scénario dans lequel il existe 2 stratégies.

  • Policy_1 est une stratégie générique avec expression=ns_true et a un profile_1 correspondant qui est un profil de base. La priorité est définie sur 100.
  • Policy_2 est plus spécifique avec expression=http.req.url.contains (« XYZ ») et a un profile_2 correspondant qui est un profil avancé. L’expression GoTo est définie sur NEXT et la priorité est définie sur 95, ce qui est une priorité plus élevée que Policy_1.

Dans ce scénario, si la chaîne cible « XYZ » est détectée dans l’URL de la requête traitée, la correspondance Policy_2 est déclenchée car elle a une priorité plus élevée même si Policy_1 est également une correspondance. Toutefois, conformément à la configuration de l’expression GoTo de Policy_2, l’évaluation de la stratégie se poursuit et la stratégie suivante Policy_1 est également traitée. À la fin de l’évaluation de la stratégie, Policy_1 est évaluée comme true et les vérifications de sécurité de base configurées dans Profile_1 sont invoquées.

Si le Policy_2 est modifié et que l’expression GoTo passe de NEXT à END, la demande traitée qui a la chaîne cible « XYZ », déclenche la correspondance Policy_2 en raison de la priorité et selon la configuration de l’expression GoTo, l’évaluation de la stratégie se termine à ce stade -ci. Policy_2 est évaluée comme true et les contrôles de sécurité avancés configurés dans Profile_2 sont invoqués.

NEXT END

L’évaluation des stratégies se fait en une seule fois. Une fois que l’évaluation de la stratégie est terminée pour la demande et que les actions de profil correspondantes sont invoquées, la demande ne passe pas par une autre ronde d’évaluation de la stratégie.

Stratégies de Web App Firewall