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 requête/réponse que le Web App Firewall doit filtrer en appliquant le profil. Les expressions de politique de pare-feu sont écrites dans le langage d’expressions NetScaler, un langage de programmation orienté objet doté de fonctionnalités spéciales destinées à prendre en charge des fonctions NetScaler spécifiques. Le profil est l’ensemble des actions que le Web App Firewall doit utiliser pour filtrer les paires requête/réponse qui correspondent à la règle.
Les stratégies de pare-feu vous permettent d’attribuer 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 traite 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 JavaScript 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 les demandes qui tentent d’accéder à ce contenu. Vous associez ensuite l’expression de stratégie à un profil que vous avez créé et vous 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 d’expressions NetScaler global. 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 :
- Pour connaître les procédures expliquant comment créer et configurer une stratégie, reportez-vous à la section Création et configuration de stratégies de Web App Firewall.
- Pour obtenir une procédure expliquant en détail comment créer une règle de stratégie (expression), reportez-vous à la section Pour créer ou configurer une règle de Web App Firewall (expression).
- Pour obtenir une procédure expliquant comment utiliser la boîte de dialogue Ajouter une expression pour créer une règle de stratégie, reportez-vous à la section Pour ajouter une règle de pare-feu (expression) à l’aide de la boîte de dialogue Ajouter une expression.
- Pour obtenir une procédure expliquant comment afficher les liaisons actuelles d’une stratégie, reportez-vous à la section Affichage des liaisons d’une stratégie de pare-feu.
- Pour connaître les procédures expliquant comment lier une stratégie de Web App Firewall, reportez-vous à la section Liaison des stratégies de Web App Firewall.
- Pour des informations détaillées sur le langage d’expressions NetScaler, consultez Politiques etexpressions.
Remarque
Web App Firewall évalue les stratégies en fonction de la priorité configurée et des expressions goto. À 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 traiter la demande.
Par exemple, imaginez un scénario dans lequel il existe deux stratégies.
- Policy_1 est une stratégie générique avec expression=NS_true et possède un profile_1 correspondant qui est un profil de base. La priorité est fixée à 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é supérieure à celle de Policy_1.
Dans ce scénario, si la chaîne cible « XYZ » est détectée dans l’URL de la demande 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 prochaine policy_1 est également traitée. À la fin de l’évaluation de la stratégie, Policy_1 évalue la valeur true et les vérifications de sécurité de base configurées dans Profile_1 sont appelées.
Si la stratégie Policy_2 est modifiée et que l’expression GoTo passe de NEXT à END, la demande traitée qui contient la chaîne cible « XYZ » déclenche la correspondance Policy_2 en raison de la priorité et, conformément à la configuration de l’expression GoTo, l’évaluation de la stratégie se termine à ce point. Policy_2 est évalué comme vrai et les vérifications de sécurité avancées configurées dans Profile_2 sont appelées.
FIN SUIVANTE
L’évaluation des politiques se fait en un seul passage. 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.