Réglage des règles de protection

Utilisez le pare-feu d'application Web pour le réglage des règles de protection.

Ces informations de base sur le réglage du service WAF décrivent les principes fondamentaux du réglage des règles, de l'inspection des journaux et de la configuration des exclusions de règle. Les avantages liés au réglage d'une politique WAF sont les suivants :

Réduction des risques de blocage d'une demande légitime.
Protection contre les attaques d'application Web standard.
Protection contre les attaques d'application Web spécifiques.
Réduction de la quantité de données à balayer et, par conséquent, amélioration de la performance.

Le tableau suivant présente les termes relatifs aux règles de protection et les définitions correspondantes.

Définitions des règles de protection
Terme	Définition
Réglage	Processus au cours duquel un ingénieur ou un analyste modifie les règles de protection et les actions associées pour permettre au serveur d'applications d'être protégé tout en restant fonctionnel. Il existe un équilibre entre le fait de verrouiller le serveur d'applications et le fait de lui permettre de continuer à fonctionner. Le réglage optimal requiert une connaissance approfondie du serveur d'applications à protéger et des règles de protection disponibles pour le protéger.
Faux positif	Un faux positif est généré lorsqu'une règle de protection est mise en correspondance avec une transaction HTTP qui est légitime (non malveillante).
Exclusion	Modification d'une règle de protection qui permet d'ignorer la valeur ou le nom de la valeur d'un témoin ou d'un argument HTTP.
Oracle Recommendation Engine (ORE)	Le moteur ORE facilite l'optimisation de votre profil de sécurité WAF en vous permettant d'activer toutes les règles qui ne se déclenchent pas pendant une période de recommandation initiale.

Aperçu des règles de protection WAF

Le service WAF protège vos applications Web contre les menaces. Ce service en nuage prend en charge plus de 500 jeux de règles, ainsi que des jeux de règles pour Open Web Application Security Project (OWASP). Ces règles vous permettent de protéger vos applications Web essentielles contre les cyberattaques malveillantes. Ces règles sont comparées aux demandes entrantes pour déterminer si elles contiennent des données utiles d'attaque. S'il s'avère que la demande est une attaque, le service WAF la bloque ou vous avertit. Ces attaques sont diverses et incluent des menaces telles que l'injection SQL, les scripts intersites et l'injection HTML. Toutes ces attaques peuvent être détectées et bloquées par les jeux de règles WAF.

La protection WAF est une boîte à outils conçue pour la surveillance, la journalisation et le contrôle d'accès des applications Web en temps réel. La boîte à outils vous permet de décider comment tirer parti de toutes les règles de protection disponibles. Cette flexibilité est un élément essentiel des règles de protection WAF, car nous offrons constamment des mises à jour pour augmenter la portée de sécurité de nos règles.

Note

Les règles de protection WAF ajoutent des cycles d'UC supplémentaires à chaque transaction. Par conséquent, il est recommandé d'activer uniquement les règles conçues pour votre topologie d'application Web.

Pour identifier et défendre les applications Web contre les attaques, les règles de protection WAF exécutent des vérifications sur chacune des demandes envoyées au serveur Web et sur toutes les réponses associées émises par le serveur, en les comparant au jeu de règles. Si les vérifications réussissent, la demande HTTP est envoyée au site Web pour récupérer le contenu pertinent. Si les vérifications échouent, les actions prédéfinies appropriées sont lancées.

Les principes de base des règles de protection WAF sont les suivants :

Passivité : C'est vous qui décidez des règles à respecter, vous disposez donc d'un contrôle total.
Flexibilité : Les règles de protection WAF ont été créées par un expert en sécurité qui a fourni plus de 250 règles et la capacité d'introduire des règles de protection personnalisées.
Qualité plutôt que quantité : Les règles de protection WAF constituent un module dédié conçu pour inspecter le trafic HTTP qui fonctionne avec les autres fonctions WAF (par exemple, le contrôle d'accès et la gestion des robots).
Prévisibilité : Le fait d'avoir un contrôle total sur les règles de protection WAF vous permet de contrôler les résultats attendus. Vous pouvez définir et ajuster vos règles de protection et laisser le réglage s'exécuter automatiquement, dans la mesure où il continue de fonctionner tel qu'il a été configuré.

Intégration et réglage initial

Tout d'abord, vous devez avoir une certaine connaissance de l'application Web pour le processus de réglage. Sinon, vous risquez d'activer des règles propres à Linux pour votre serveur ou origine Windows. Ces règles analyseront inutilement votre trafic, ce qui peut nuire à la performance. Le moteur ORE vous aide en fournissant un jeu solide et sécurisé de règles de protection. La période de recommandation est un paramètre configurable dont la valeur par défaut est 10 jours. Nous vous recommandons de régler cette valeur à 15 jours pour obtenir un vaste échantillon de journaux pour le trafic normal sur l'application Web. Environ vingt-quatre heures après la création de votre politique WAF, les règles de protection recommandées s'affichent dans l'onglet des recommandations. Il s'agit de règles sélectionnées par les spécialistes WAF pour couvrir les dix principales menaces d'OWASP. Ces règles recommandées ont été sélectionnées parce qu'elles produisent généralement le nombre de faux positifs le plus faible tout en offrant une bonne protection.

Modification de la période de recommandation et acceptation des recommandations

En suivant les étapes ci-dessous, vous activez les règles recommandées en mode de détection. Une fois les règles en mode de détection, nous vous conseillons d'attendre 15 jours avant de les faire passer en mode de blocage.

Note

Pendant la période d'évaluation, toutes les règles sont en mode de détection. Avec le mode de détection, les règles de protection n'entraînent aucun blocage. Nous vous recommandons d'effectuer des tests d'acceptation par les utilisateurs et d'utiliser les applications dans des conditions normales afin de générer des journaux. Cela permet de faciliter le processus de réglage. Consultez les journaux et recherchez les faux positifs générés alors que les règles sont en mode de détection. La consultation des journaux générés par les règles de protection vous donne une idée du trafic qui est susceptible de provoquer un blocage une fois les règles en mode de blocage. Pendant la période d'évaluation, l'application doit recevoir un trafic aussi proche que possible de la normale ou du trafic de type production. Le trafic normal vous montre quelles règles se déclenchent grâce aux journaux, et les faux positifs peuvent être exclus par filtrage.

Pour modifier la période d'analyse des recommandations

Ouvrez le menu de navigation et sélectionnez Identité et sécurité. Sous Pare-feu d'application Web, sélectionnez Ressources de politique de périphérie de réseau.
La liste Politiques s'ouvre. Toutes les politiques de périphérie de réseau sont répertoriées dans un tableau.
Sélectionnez la politique de périphérie de réseau pour laquelle vous souhaitez configurer les paramètres de règle.
La page de détails de la politique de périphérie de réseau s'ouvre.
Sélectionnez Règles de protection.
Le panneau Règles de protection s'ouvre.
Sélectionnez l'onglet Paramètres.
Sélectionnez Modifier les paramètres de règle.
Le panneau Modifier les paramètres de règle s'ouvre.
Augmenter la période des recommandations de 10 à 15 jours.
Sélectionnez Enregistrer les modifications.

Pour accepter des recommandations

Ouvrez le menu de navigation et sélectionnez Identité et sécurité. Sous Pare-feu d'application Web, sélectionnez Ressources de politique de périphérie de réseau.
La liste Politiques s'ouvre. Toutes les politiques de périphérie de réseau sont répertoriées dans un tableau.
Sélectionnez la politique de périphérie de réseau pour laquelle vous souhaitez configurer les paramètres de règle.
La page de détails de la politique de périphérie de réseau s'ouvre.
Sélectionnez Règles de protection.
Le panneau Règles de protection s'ouvre.
Sélectionnez l'onglet Recommandations.
Le panneau Recommandations s'ouvre.
Sélectionnez Accepter les recommandations.
Sélectionnez Modifications non publiées.
Sélectionnez Tout publier.
Dans le panneau Publier les modifications, sélectionnez Tout publier.

Utilisation de l'API pour interroger des journaux spécifiques

L'API offre le plus d'options pour les règles de filtrage. Les exemples suivants montrent comment utiliser l'interface de ligne de commande pour filtrer les journaux.

Pour filtrer les journaux par ID règle de protection :

oci waas waf-log list --waas-policy-id <WASS Policy OCID> --protection-rule-key <protection rule id number>

Pour filtrer les journaux par type de règle (par exemple, protection ou accès) :

oci waas waf-log list --waas-policy-id <WAAS Policy OCID> --log-type PROTECTION_RULES
oci waas waf-log list --waas-policy-id <WAAS Policy OCID> --log-type ACCESS

Pour filtrer les journaux par URL de demande :

oci waas waf-log list --waas-policy-id <WAAS Policy OCID> --request-url <request url>

Configuration de Log Analytics

Log Analytics vous aide à restreindre les règles de protection qui nécessitent une attention particulière. Utilisez les informations suivantes pour configurer le service Log Analytics avec le service WAF. Pour plus d'informations, voir Données clés de sécurité pour vos applications Web avec OMC Log Analytics.

Création d'exclusions dans les règles de protection

La consultation des journaux est une partie essentielle du processus de réglage. Les journaux indiquent quelle règle a été mise en correspondance et avec quelle partie de la transaction HTTP elle a été mise en correspondance. Consultez le tableau suivant pour obtenir des exemples de journaux et pour savoir comment les utiliser pour créer une exclusion.

L'objet protectionRuleDetections dans WafLog fournit un mappage entre les clés de règle de protection et les détails du message de détection. Le tableau suivant présente quatre exclusions possibles pouvant être configurées pour une règle de protection.


Valeur de journal	Valeur d'exclusion	Description
ARGS	Paramètres de demande	Utilisé pour les valeurs d'un argument spécifique.
ARGS_NAMES	Noms de paramètre de demande	Utilisé pour le nom de l'argument.
REQUEST_COOKIES	Valeurs de témoin de demande	Utilisé pour les valeurs d'un témoin spécifique.
REQUEST_COOKIES_NAMES	Noms de témoin de demande	Utilisé pour le nom du témoin.

Exemples d'exclusion avec des journaux

La section suivante fournit des exemples de journaux bruts et des exemples de la valeur d'exclusion pour chaque règle.

ID règle 9411000 - ARGS
Dans cet exemple, les données mises en correspondance ont été trouvées dans l'argument ARGS:foo. L'exclusion concerne l'ID règle 9411000. L'exclusion à créer concerne Paramètres de demande avec la valeur foo.
```
"protection-rule-detections": {
 "9411000": {
  "Message": "detected XSS using libinjection.",
  "Message details": "Matched Data: found within ARGS:foo: <script>xss"
},
```

ID règle 9411000 - ARGS_NAMES
Dans cet exemple, les données mises en correspondance ont été trouvées dans l'argument ARGS_NAMES. L'exclusion concerne l'ID règle 9411000. L'exclusion à créer concerne Noms de paramètre de demande avec la valeur <script>xss.
```
"protection-rule-detections": {
 "9411000": {
  "Message": "detected XSS using libinjection.",
  "Message details": "Matched Data: found within ARGS_NAMES:<script>xss: <script>xss"
},
```

ID règle 9411100

Dans cet exemple, les données mises en correspondance ont été trouvées dans l'argument REQUEST_COOKIES:a. L'exclusion concerne l'ID règle 9411100. L'exclusion à créer concerne Valeurs de témoin de demande avec la valeur a.

"protection-rule-detections": {
 "9411100": {
  "Message": "Pattern match \"(?i)([<\\xef\\xbc\\x9c]script[^>\\xef\\xbc\\x9e]*[>\\xef\\xbc\\x9e][\\\\s\\\\S]*?)\" at REQUEST_COOKIES:a.",
  "Message details": "Matched Data: <script> found within REQUEST_COOKIES:a: <script>xss"
},

Pour créer des exclusions

Ouvrez le menu de navigation et sélectionnez Identité et sécurité. Sous Pare-feu d'application Web, sélectionnez Ressources de politique de périphérie de réseau.
La liste Politiques s'ouvre. Toutes les politiques de périphérie de réseau sont répertoriées dans un tableau.
Sélectionnez la politique de périphérie de réseau pour laquelle vous souhaitez configurer les paramètres de règle.
La page de détails de la politique de périphérie de réseau s'ouvre.
Sélectionnez Règles de protection.
Le panneau Règles de protection s'ouvre.
Sélectionnez l'onglet Règles.
Repérez la règle de protection à laquelle appliquer une action.
Sélectionnez le menu Actions (trois points) et sélectionnez Exclusions. Incluez les exclusions à l'aide des informations obtenues dans la section précédente, Exemples d'exclusion avec des journaux.
Sélectionnez Enregistrer les modifications.
Sélectionnez Modifications non publiées.
Sélectionnez Tout publier.
Dans la boîte de dialogue Publish Changes, sélectionnez Publish All (Tout publier).

Informations supplémentaires sur les règles de protection

Règles de protection individuelles et règles de protection collaboratives

Pour limiter le nombre de faux positifs, il existe des règles de protection spéciales identifiées comme "collaboratives". Ces groupes de règles ne fonctionnent pas de la même manière que les autres règles de protection, car ils utilisent un système de notation et de seuil pour évaluer le trafic. Les règles individuelles fonctionnent en faisant correspondre les éléments de la transaction HTTP à leur signature. Si une correspondance est établie, la règle exécute l'action qui lui est associée (par exemple, détection ou blocage). Les règles de protection collaboratives utilisent un groupe de règles individuelles. Elles nécessitent plusieurs correspondances d'éléments de la transaction HTTP aux règles individuelles pour exécuter l'action qui leur est associée (par exemple, détection ou blocage). Pour qu'une règle collaborative exécute l'action qui lui est associée, au moins trois éléments de la transaction HTTP doivent correspondre aux règles individuelles du groupe. Une fois l'exclusion ajoutée dans le groupe de règles de protection collaboratives, elle s'applique à toutes les règles de celui-ci. Voici la liste des ID règles de protection collaboratives.

ID règles de protection collaboratives

9300000 - Groupe collaboratif pour les attaques par inclusion de fichier local (LFI) - Catégories de filtre LFI
9320000 - Groupe collaboratif pour les attaques par exécution de code à distance - Catégories de filtre d'exécution de code à distance UNIX
9320001 - Groupe collaboratif pour les attaques par exécution de code à distance - Catégories de filtre d'exécution de code à distance Windows
9330000 - Groupe collaboratif pour les attaques par injection de code PHP - Catégories de filtres PHP
9410000 - Groupe collaboratif pour les attaques par script intersites (XSS) - Catégories de filtres XSS
9420000 - Groupe collaboratif pour les attaques par injection SQL (SQLi) - Catégories de filtres SQLi

ID règles d'inspection du corps de la demande

Les règles suivantes nécessitent d'activer l'inspection du corps de la réponse. Rappelez-vous que l'inspection du corps de la réponse retarde la transaction, car elle analyse toutes les informations qu'il contient. Activez uniquement les règles requises.

970014, 90005, 120133, 970008, 970016, 981080, 920020, 920006, 920008, 920010, 920012, 920014, 920016, 920018, 90017, 90018, 90020, 90019, 90014, 90021, 90015, 90016, 920021, 920022, 920023, 90024, 90022, 90023, 970013, 970011, 981177, 981000, 981001, 981003, 970018, 970004, 970904, 970010, 970118, 2100090, 970012, 970903, 970009, 970015, 970902, 981005, 981004, 981007, 981006, 970003, 970002, 950110, 950921, 950922, 90002, 90025, 970021, 970007

Aucune règle d'exception

Les règles suivantes créent des valeurs de journal brutes autres que ARGS, ARGS_NAMES, REQUEST_COOKIE et REQUEST_COOKIE_VALUE. Il n'existe aucune exclusion pour ces règles, car elles dépendent seulement de la présence ou non de l'élément. Par exemple, si l'en-tête de type de contenu est présent, l'unique moyen d'exclure cette règle consiste à ouvrir une demande de service auprès de My Oracle Support pour demander une règle WAF personnalisée excluant l'une des règles suivantes.

960020, 960015, 960009, 950103

Ces règles sont facilement repérables, car les valeurs de journal sont REQUEST_URI, REQUEST_PROTOCOL et REQUEST_HEADERS.

Autres règles de protection

Voici une liste de règles de protection générant du "bruit", accompagnées de descriptions et de recommandations qui vous aideront à comprendre les correspondances que la règle tente d'établir. Les exclusions ne peuvent pas être appliquées à certaines de ces règles.


ID règle	Nom de la règle	Notes
981318	Fin de chaîne/Fin d'énoncé	Cette règle est importante, car elle signale tout caractère d'échappement détecté dans un champ d'entrée et une chaîne d'interrogation [ARGS] ou un témoin. Vérifiez les validations effectuées côté application et assurez-vous qu'elles autorisent uniquement les caractères d'entrée appropriés, par exemple des lettres et des chiffres. Si une autre valeur d'entrée est requise, une exclusion peut être appliquée à la règle dans le service WAF afin de la laisser passer.
960015 960021	En-tête d'acceptation (accept) manquant	Même si les demandes sans en-tête d'acceptation (accept) ne signifient pas qu'une violation du protocole HTTP a eu lieu, le plus souvent elles ne sont pas des demandes authentiques. La règle peut générer des alertes pour les demandes d'API ou d'application personnalisée. Pour éviter de balayer les demandes d'API ou d'application personnalisée, collectez une liste des applications bien connues qui envoient du trafic et demandez des règles personnalisées. Pour plus d'informations, voir le document RFC 7231, section-5.3.2.
960007 960008	En-tête hôte (host) manquant	Comme décrit dans le document RFC 7230, section-5.4, "Un serveur doit répondre avec un code de statut 400 (demande incorrecte) à tout message de demande HTTP/1.1 ne comportant pas de champ En-tête d'hôte et à tout message de demande contenant plus d'un champ En-tête d'hôte ou un champ En-tête d'hôte avec une combinaison champ-valeur non valide." Il s'agit d'une méthode de protection essentielle qui permet en même temps aux serveurs WAF d'identifier correctement la politique WAF à laquelle la demande est destinée. Comme le service WAF a besoin d'un en-tête d'hôte pour transmettre le trafic à l'origine appropriée, cette règle peut générer un taux élevé de faux positifs.
960009 960006	En-tête agent utilisateur (user-agent) manquant	Cette règle empêche les utilisateurs non identifiés d'accéder à votre application Web. L'agent utilisateur est l'un des en-têtes de demande définis dans divers documents RFC qui fournit des informations sur l'utilisateur. Même si une demande contient un agent utilisateur, cela ne signifie pas qu'elle provient d'un humain réel. Cette règle fonctionne comme un premier niveau d'atténuation pour les attaques factices provenant de robots potentiels ou d'applications non compatibles avec le document RFC. Note : Certaines API peuvent ne pas inclure l'en-tête agent utilisateur (user-agent). Si des demandes d'API sont attendues, assurez-vous d'ajouter l'adresse IP de l'API à la liste d'autorisation ou de disposer d'une règle WAF personnalisée qui exclut ce trafic de l'inspection. Pour plus d'informations, voir le document RFC 7231, section-5.5.3. Cette règle est un indicateur de mauvais trafic ou de trafic malveillant, mais il est possible que des applications légitimes ne comportent pas d'agent utilisateur. Demandez aux responsables d'application d'utiliser des agents utilisateurs, le cas échéant.
960011	Validation des demandes GET/HEAD	Comme décrit dans le document RFC 7231, section 4.3.1 et section 4.3.2, HEAD et GET sont des méthodes HTTP destinées à extraire des informations du serveur d'origine. Même s'il n'est pas interdit par le document RFC, l'envoi du corps ou des données utiles au moyen de ces types de méthode n'est pas une pratique commune. Cela est généralement dû à des applications mal définies qui ne respectent pas les meilleures pratiques du document RFC, et peut être utilisé par des utilisateurs malveillants comme technique de contournement. Le document RFC 2616, section 4.3, indique également que "si la méthode de demande n'inclut pas la sémantique définie pour un corps d'entité, le corps du message doit être ignoré lors du traitement de la demande".
960904	En-tête de type de contenu manquant	Comme défini dans le document RFC 2616, section 7.2.1, "Tout message HTTP/1.1 contenant un corps d'entité doit inclure un champ d'en-tête de type de contenu définissant le type de média de ce corps." Le non-respect de cette meilleure pratique pourrait entraîner des attaques par détection de type MIME.
960032	Méthodes HTTP autorisées	Les méthodes HTTP autorisées par défaut sont GET, HEAD, POST et OPTIONS. OPTIONS est connue pour être une méthode non sécurisée, car elle est très souvent utilisée par les attaquants pour collecter des informations à partir du serveur d'origine. Cette méthode est également requise par certaines applications pour fonctionner correctement. Si cette méthode n'est pas requise, créez une demande de service auprès de My Oracle Support pour la désactiver. D'autres méthodes peuvent également être ajoutées si nécessaire, au moyen d'une demande de service.
960335	Nombre maximal d'arguments	Le document RFC n'impose aucun nombre d'arguments par demande, mais l'utilisation d'un grand nombre d'arguments peut être une technique adoptée par des utilisateurs malveillants pour tenter de générer un dépassement de la capacité d'une application Web. Pour vous protéger contre ces types d'attaque, nous vous recommandons de limiter le nombre maximal d'arguments autorisés par demande. La valeur par défaut est 255.
960208	Longueur maximale d'un argument	Le document RFC n'impose aucune longueur d'argument par demande, mais l'utilisation d'une longueur d'argument élevée peut être une technique adoptée par des utilisateurs malveillants pour tenter d'effectuer un dépassement de la capacité d'une application Web. Pour vous protéger contre ces types d'attaque, nous vous recommandons de limiter la longueur maximale d'argument par demande. La valeur par défaut est 400.
960341	Longueur maximale totale des arguments	Le document RFC n'impose aucune taille totale d'arguments (combinés) par demande, mais l'utilisation de valeurs d'arguments combinés élevées peut être une technique adoptée par des utilisateurs malveillants pour tenter d'effectuer un dépassement de la capacité d'une application Web. Pour vous protéger contre ces types d'attaque, nous vous recommandons de limiter la valeur maximale des arguments combinés autorisée par demande. La valeur par défaut est 64000.
92035032	L'en-tête hôte (host) est l'adresse IP	Cette règle ne se déclenche généralement pas, car le service WAF a besoin d'un en-tête d'hôte pour envoyer le trafic à l'origine.
941120	Tentative d'attaque par script intersites (XSS) : Filtres XSS - Catégorie 2	Le traitement de cette règle prend beaucoup de temps si les données utiles sont volumineuses. Par exemple, le traitement de données utiles de 64 005 octets prend environ 32 secondes.

Documentation sur Oracle Cloud Infrastructure