Réglage des règles de protection

Utilisez Web Application Firewall pour le réglage des règles de protection.

Ces informations de réglage WAF de base 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. Le réglage d'une stratégie WAF peut être avantageux pour les motifs suivants :

Réduit le risque de bloquer une demande légitime.
Protège contre les attaques d'application Web standard.
Protège contre les attaques d'application Web spécifiques.
Réduit le nombre d'analyses, ce qui améliore les performances.

Le tableau suivant présente les termes relatifs aux règles de production et leur définition.

Définitions relatives aux règles de protection
Terme	Définition
Réglage	Processus par lequel un ingénieur ou un analyste modifie les règles et actions de protection pour que le serveur d'applications soit protégé tout en restant opérationnel. Il s'agit de trouver l'équilibre entre verrouiller le serveur d'applications et lui permettre d'effectuer les tâches qui lui incombent. L'obtention du réglage optimal suppose une connaissance approfondie du serveur d'applications protégé et des règles disponibles pour le protéger.
Faux positif	Un faux positif se produit lorsqu'une règle de protection est mise en correspondance avec une transaction HTTP alors que cette dernière est légitime (non malveillante).
Exclusion	Modification apportée à une règle de protection qui permet d'ignorer la valeur ou le nom de valeur d'un cookie ou d'un argument HTTP.
Moteur de recommandation Oracle (ORE)	Le moteur de recommandation Oracle 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.

Présentation des règles de protection WAF

WAF protège vos applications Web contre les menaces. WAF repose sur le cloud et prend en charge plus de 500 ensembles de règles, ainsi que des ensembles de règles pour OWASP (Open Web Application Security Project). Utilisez ces règles pour protéger vos applications Web stratégiques contre les cyberattaques malveillantes. Les règles sont comparées aux demandes entrantes pour déterminer si ces dernières contiennent une charge utile d'attaque. Si WAF identifie la demande comme une attaque, il la bloque ou vous avertit. Les attaques sont variées et comprennent des menaces telles que l'injection SQL, la génération de scripts inter-site et l'injection HTML, qui peuvent toutes être détectées et bloquées par les ensembles de règles WAF.

La protection WAF est un toolkit conçu pour la surveillance, la journalisation et le contrôle d'accès en temps réel des applications Web. Le toolkit vous permet de décider de la manière dont tirer parti de toutes les règles de protection disponibles. Cette flexibilité est un élément clé des règles de protection WAF, car nous propageons constamment des mises à jour pour améliorer la portée de sécurité de nos règles.

Remarque

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

Pour identifier les attaques et défendre les applications Web contre celles-ci, les règles de protection WAF soumettent toute demande adressée au serveur Web et toutes les réponses associées du serveur à des vérifications basées sur l'ensemble de règles. Une fois les vérifications effectuées, la demande HTTP est envoyée au site Web pour extraire le contenu pertinent. Si les vérifications échouent, les actions prédéfinies appropriées sont lancées.

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

Passivité : vous décidez des règles requises et disposez donc d'un contrôle total.
Flexibilité : les règles de protection WAF ont été créées par un expert sécurité qui a fourni plus de 250 règles et offert la possibilité d'introduire des règles de protection personnalisées.
Qualité et non quantité : les règles de protection WAF sont un module dédié conçu pour l'inspection du trafic HTTP fonctionnant avec les autres fonctionnalités WAF (par exemple, le contrôle d'accès et la gestion des bots).
Prévisibilité : disposer d'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 régler vos règles de protection, puis laisser la configuration sans surveillance, sachant qu'elle continue à fonctionner telle qu'elle a été définie.

Intégration et réglage initial

Tout d'abord, vous devez avoir des connaissances sur l'application Web pour mener à bien le processus de réglage. Sinon, vous risquez par exemple d'activer des règles propres à Linux pour votre origine ou votre serveur Windows. Les règles analysent alors le trafic inutilement, ce qui entraîne une dégradation des performances. ORE vous aide en fournissant un ensemble de règles de protection fiable et sécurisé. La période de recommandation est un paramètre configurable avec une valeur par défaut de 10 jours. Nous vous recommandons d'augmenter cette valeur à 15 jours afin d'obtenir un large échantillon de journaux pour le trafic normal sur l'application Web. Environ 24 heures après la création de la stratégie WAF, des recommandations de règle de protection apparaissent dans l'onglet des recommandations. Les recommandations sont des règles choisies par les experts WAF pour couvrir la liste OWASP des dix principales menaces. Ces règles recommandées ont été sélectionnées car elles produisent généralement moins de faux positifs tout en offrant toujours une bonne protection.

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

Suivez les étapes ci-dessous pour activer les règles recommandées en mode de détection. Une fois que les règles sont en mode de détection, nous vous conseillons d'attendre 15 jours avant de les passer en mode de blocage.

Remarque

Pendant la période d'évaluation, toutes les règles sont en mode de détection. Le mode de détection signifie que les règles de protection n'entraînent aucun blocage. Nous vous recommandons d'effectuer les tests d'acceptation utilisateur et d'utiliser normalement les applications pour faciliter le processus de réglage grâce aux journaux générés. Consultez les journaux et recherchez les faux positifs lorsque les règles sont en mode de détection. La consultation des journaux qui se déclenchent pour les règles de protection vous donne une idée du trafic qui provoquerait un blocage après passage des règles en mode de blocage. Pendant la période d'évaluation, le trafic reçu par l'application doit être aussi proche que possible du trafic normal ou de type production. Le trafic normal vous indique via les journaux les règles qui se déclenchent, ce qui permet de filtrer les faux positifs.

Procédure de modification de la période de recommandations

Ouvrez le menu de navigation et sélectionnez Identité et sécurité. Sous Pare-feu d'applications Web, sélectionnez Ressources de stratégie en périphérie.
La liste Stratégies s'ouvre. Toutes les stratégies en périphérie sont répertoriées dans une table.
Sélectionnez la stratégie en périphérie pour laquelle configurer les paramètres de règle.
La page de détails de la stratégie en périphérie 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 la règle.
Le panneau Modifier les paramètres de règle s'ouvre.
Augmentez la période de recommandation de 10 à 15 jours.
Sélectionnez Enregistrer les modifications.

Procédure d'acceptation des recommandations

Ouvrez le menu de navigation et sélectionnez Identité et sécurité. Sous Pare-feu d'applications Web, sélectionnez Ressources de stratégie en périphérie.
La liste Stratégies s'ouvre. Toutes les stratégies en périphérie sont répertoriées dans une table.
Sélectionnez la stratégie en périphérie pour laquelle configurer les paramètres de règle.
La page de détails de la stratégie en périphérie 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 Publier tout.
Dans le panneau Publier les modifications, sélectionnez Tout publier.

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

L'API fournit la plupart des options de filtrage de règles. Vous trouverez ci-après des exemples d'utilisation de l'interface de ligne de commande pour filtrer les journaux.

Pour filtrer les journaux par ID de 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, règles de protection ou d'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 à affiner les règles de protection qui requièrent votre attention. Utilisez les informations suivantes pour configurer le service Log Analytics avec WAF. Pour plus d'informations, reportez-vous à Informations de sécurité sur vos applications Web avec OMC Log Analytics.

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

La consultation des journaux est une partie essentielle du processus de réglage. Les journaux nous indiquent la règle mise en correspondance et la partie de la transaction HTTP avec laquelle elle a été mise en correspondance. Reportez-vous au tableau suivant pour voir des exemples de journaux et savoir comment les utiliser pour créer une exclusion.

L'objet protectionRuleDetections dans WafLog fournit une correspondance entre clés de règle de protection et détails de 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	A utiliser pour les valeurs d'un argument spécifique.
ARGS_NAMES	Noms de paramètre de demande	A utiliser pour le nom de l'argument.
REQUEST_COOKIES	Valeurs de cookie de demande	A utiliser pour les valeurs d'un cookie spécifique.
REQUEST_COOKIES_NAMES	Noms de cookie de demande	A utiliser pour le nom du cookie.

Exemples d'exclusions avec des journaux

La section suivante fournit des échantillons de journal brut et des exemples de la valeur d'exclusion à définir pour chaque règle.

ID de 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 de règle 9411000. L'exclusion à créer concerne les 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 de 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 de règle 9411000. L'exclusion à créer concerne les 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 de 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 de règle 9411100. L'exclusion à créer concerne les valeurs de cookie 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"
},

Procédure de création d'exclusions

Ouvrez le menu de navigation et sélectionnez Identité et sécurité. Sous Pare-feu d'applications Web, sélectionnez Ressources de stratégie en périphérie.
La liste Stratégies s'ouvre. Toutes les stratégies en périphérie sont répertoriées dans une table.
Sélectionnez la stratégie en périphérie pour laquelle configurer les paramètres de règle.
La page de détails de la stratégie en périphérie s'ouvre.
Sélectionnez Règles de protection.
Le panneau Règles de protection s'ouvre.
Sélectionnez l'onglet Règles.
Recherchez 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'exclusions avec des journaux.
Sélectionnez Enregistrer les modifications.
Sélectionnez Modifications non publiées.
Sélectionnez Publier tout.
Dans la boîte d' dialogue Publier des modifications, sélectionnez Tout publier.

Informations supplémentaires sur les règles de protection

Règles de protection individuelles et collaboratives

Pour limiter les faux positifs, il existe des règles de protection spéciales marquées comme "collaboratives". Ces groupes de règles fonctionnent différemment du reste des règles de protection, car ils utilisent un système de score et de seuil pour évaluer le trafic. Les règles individuelles fonctionnent en mettant en correspondance les éléments de la transaction HTTP avec la signature de règle. Si une correspondance est établie, la règle effectue l'action définie (par exemple, détection ou blocage). Chacune des règles de protection collaboratives utilise un groupe de règles individuelles. Les règles de protection collaboratives requièrent plusieurs mises en correspondance d'éléments de la transaction HTTP avec des règles individuelles pour effectuer l'action définie (par exemple, détection ou blocage). Pour qu'une règle collaborative exécute l'action définie, au moins trois éléments de la transaction HTTP doivent correspondre aux règles individuelles du groupe collaboratif. Une fois l'exclusion ajoutée au groupe de règles de protection collaboratif, elle s'applique à toutes les règles qu'il contient. Voici la liste des ID de règle de protection collaborative.

ID de règle de protection collaborative

9300000 - Inclusion de fichier local (LFI) - Groupe collaboratif - Catégories de filtre LFI
9320000 - Exécution distante de code (RCE) - Groupe collaboratif - Catégories de filtre RCE UNIX
9320001 - Exécution distante de code (RCE) - Groupe collaboratif - Catégories de filtre RCE Windows
9330000 - Attaques par injection PHP - Groupe collaboratif - Catégories de filtres PHP
9410000 - Génération de scripts inter-site (XSS) - Groupe collaboratif - Catégories de filtres XSS
9420000 - Injection SQL (SQLi) - Groupe collaboratif - Catégories de filtres SQLi

ID de règle d'inspection de corps de demande

Les règles suivantes requièrent l'activation de l'inspection du corps de réponse. Rappelez-vous que l'inspection du corps de réponse retarde la transaction, car elle scanne toutes les informations qu'elle 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

Règles sans exception

Les règles suivantes créent des valeurs de journal brut autres qu'ARGS, ARGS_NAMES, REQUEST_COOKIE et REQUEST_COOKIE_VALUE. Il n'existe pas d'exclusions pour ces règles car celles-ci reposent sur la présence ou non de l'élément. Par exemple, si l'en-tête Content-Type est présent, la seule option pour exclure la règle est d'ouvrir une demande d'assistance auprès de My Oracle Support afin de demander une règle WAF personnalisée qui exclut toutes les 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 parasites, avec des descriptions et recommandations vous aidant à comprendre ce que la règle tente de mettre en correspondance. Les exclusions ne peuvent pas être appliquées à certaines de ces règles.


ID de règle	Nom de règle	Remarques
981318	Terminaison de chaîne/fin d'instruction	Cette règle est importante car elle avertit de tout caractère d'échappement détecté dans un champ d'entrée et queryString [ARGS] ou un cookie. Passez en revue les validations effectuées côté application et assurez-vous qu'elles autorisent uniquement les caractères d'entrée appropriés, par exemple les lettres et les chiffres. Si une autre valeur d'entrée est requise, une exclusion peut être appliquée à la règle dans WAF pour la laisser passer.
960015 960021	En-tête Accept manquant	Même si les demandes sans en-tête Accept ne constituent pas une violation du protocole HTTP, elles ne sont généralement pas des demandes authentiques. La règle peut générer une alerte pour des demandes d'API ou d'application personnalisée. Pour éviter d'analyser les demandes d'API ou d'application personnalisée, dressez la liste des applications connues qui envoient du trafic et nécessitent des règles personnalisées. Pour plus d'informations, reportez-vous au document RFC 7231, section 5.3.2.
960007 960008	En-tête Host manquant	Comme décrit dans la norme 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 sans champ d'en-tête Host, et à tout message de demande contenant plusieurs champs d'en-tête Host ou un champ d'en-tête Host avec une valeur de champ non valide." Il s'agit d'une méthode de protection essentielle. Elle garantit par ailleurs que les serveurs WAF identifient correctement la stratégie WAF à laquelle la demande est destinée. Comme WAF exige un en-tête Host pour transmettre le trafic vers l'origine appropriée, cette règle peut entraîner un taux élevé de faux positifs.
960009 960006	En-tête User-Agent manquant	Cette règle empêche les utilisateurs non identifiés d'accéder à votre application Web. User-Agent fait partie des en-têtes de demande définis dans diverses normes RFC qui fournissent des informations utilisateur. Même lorsqu'une demande contient un en-tête user-agent, elle ne provient pas forcément d'un être humain. Cette règle fonctionne comme un premier niveau de réduction des attaques "fictives" provenant d'éventuels bots ou d'applications non conformes aux normes RFC. Remarque : Certaines API peuvent ne pas inclure l'en-tête User-Agent. Si des demandes d'API sont attendues, veillez à ajouter l'adresse IP d'API à la liste d'autorisation ou à disposer d'une règle WAF personnalisée qui exclut l'inspection de ce trafic. Pour plus d'informations, reportez-vous au document RFC 7231, section 5.5.3. Cette règle est un indicateur de trafic dangereux ou malveillant, mais il arrive que des applications légitimes n'aient pas d'en-tête User-Agent. Demandez aux propriétaires des applications d'utiliser des en-têtes User-Agent, lorsque cela est possible.
960011	Validation des demandes GET/HEAD	Comme décrit dans la norme RFC 7231, sections 4.3.1 et 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 la norme RFC, l'envoi d'un corps ou d'une charge utile via ce type de méthode n'est pas une pratique courante. Habituellement, il est causé par des applications mal définies ne respectant pas les meilleures pratiques de la norme RFC. Il peut être utilisé par des utilisateurs malveillants comme technique de contournement. La norme RFC 2616, section 4.3, précise également : "Si la méthode de la demande n'inclut aucune sémantique définie pour un corps d'entité, le corps de message doit être ignoré lors du traitement de la demande."
960904	En-tête Content-Type manquant	Comme défini dans la norme RFC 2616, section 7.2.1 : "Tout message HTTP/1.1 contenant un corps d'entité doit inclure un champ d'en-tête Content-Type définissant le type de support de ce corps." Si cette meilleure pratique n'est pas respectée, des attaques par reniflage de type MIME peuvent se produire.
960032	Méthodes HTTP autorisées	Les méthodes HTTP autorisées par défaut sont GET, HEAD, POST et OPTIONS. La méthode OPTIONS est considérée comme non sécurisée car elle est souvent utilisée par les individus malveillants pour collecter des informations à partir du serveur d'origine. Toutefois, elle est également requise pour le bon fonctionnement de certaines applications. Si elle n'est pas nécessaire, créez une demande d'assistance auprès de My Oracle Support pour la désactiver. Au besoin, d'autres méthodes peuvent également être ajoutées avec une demande d'assistance.
960335	Nombre maximal d'arguments	Les documents RFC ne fixent pas le nombre d'arguments qu'une demande doit comporter. Toutefois, l'utilisation de nombreux arguments peut être un moyen pour les utilisateurs malveillants de tenter de déborder une application Web. Nous vous recommandons de limiter le nombre d'arguments (ARG) autorisés pour chaque demande afin de vous protéger contre ce type d'attaque. La valeur par défaut est 255.
960208	Longueur maximale d'un argument	Les documents RFC ne fixent pas la longueur des arguments d'une demande. Toutefois, l'utilisation d'une grande longueur d'argument peut être un moyen pour les utilisateurs malveillants de tenter de déborder une application Web. Nous vous recommandons de limiter la longueur autorisée pour les arguments (ARG) de chaque demande afin de vous protéger contre ce type d'attaque. La valeur par défaut est 400.
960341	Longueur totale maximale d'un argument	Les documents RFC ne fixent pas la taille totale (combinée) des arguments d'une demande. Toutefois, l'utilisation de grandes valeurs d'argument combinées peut être un moyen pour les utilisateurs malveillants de tenter de déborder une application Web. Nous vous recommandons de limiter la valeur combinée autorisée pour les arguments de chaque demande afin de vous protéger contre ce type d'attaque. La valeur par défaut est 64000.
92035032	L'en-tête Host est une adresse IP	En général, cette règle ne se déclenche pas car WAF a besoin d'un en-tête Host pour envoyer le trafic vers l'origine.
941120	Tentative de génération de scripts inter-site (XSS) : filtres XSS - Catégorie 2	Le traitement de cette règle est long s'il existe une charge utile volumineuse. Par exemple, le traitement d'une charge utile de 64 005 octets prend environ 32 secondes.

Documentation Oracle Cloud Infrastructure