Les CRS OWASP sont de nature plus générique qu’un ensemble de règles commerciales et couvrent un ensemble beaucoup plus large d’applications à partir d’une surface d’attaque plus large. Cela signifie que le CRS vous protège des attaques génériques plutôt que des exploits connus spécifiques individuels. Par exemple, il n’existe pas de règles pour toutes les attaques par injections SQL connues, mais un petit ensemble de règles protégeant votre application de toute attaque qui ressemble à une attaque par injection SQL. Cela offre une couverture considérablement améliorée pour Zero Day et d’autres attaques inconnues.

Une fois le WAF activé sur le LoadMaster, nous pouvons vérifier qu’il fonctionne immédiatement en utilisant :

curl http://<<Virtual Services IP Address>>/index.html?exec=/bin/bash

La chaîne de requête contient une tentative d’exploitation d’un backend imaginaire. Cet exploit ne fonctionnera pas bien sûr, mais il suffit de déclencher CRS. La demande n’est cependant pas bloquée immédiatement. Ne vous inquiétez pas, dans ce blog, nous expliquerons à la fois les paramètres et comment bloquer cette demande.

Les journaux LoadMaster les plus intéressants ici sont les Fichier journal des événements WAF sous Configuration du système – Options de journalisation – Fichiers journaux du système. Le journal généré à partir de cette tentative d’accès est affiché ici :

2021-04-18T21:40:43+00:00 lb100 wafd: [client 10.0.31.231] ModSecurity: Warning. Matched phrase "bin/bash" at ARGS:exec. [file "/tmp/waf/3/REQUEST-932-APPLICATION-ATTACK-RCE.conf"] [line "500"] [id "932160"] [msg "Remote Command Execution: Unix Shell Code Found"] [data "Matched Data: bin/bash found within ARGS:exec: /bin/bash"] [severity "CRITICAL"] [ver "OWASP_CRS/3.3.0"] [tag "application-multi"] [tag "language-shell"] [tag "platform-unix"] [tag "attack-rce"] [tag "paranoia-level/1"] [tag "OWASP_CRS"] [tag "capec/1000/152/248/88"] [tag "PCI/6.5.2"] [hostname "10.35.56.58"] [uri "/index.html"] [unique_id "e8035fe4-c980-49e8-b87a-6360afe9c44b"]

Nous examinons plusieurs entrées dans ce journal

• id qui nous dit que la règle 932160 a été touchée
• msg pour savoir ce qui s’est passé, dans ce cas l’exécution de la commande à distance, Unix Shell Code trouvé
• hostname est l’adresse de service virtuel contre laquelle l’attaque a été déclenchée

Donc, ce que nous avons appris, c’est que l’ensemble de règles est actif et qu’il enregistre les attaques, même si, pour le moment, il permet à ces attaques de se produire.

Avant de plonger dans le blocage de cette attaque, passons en revue les paramètres WAF sur le LoadMaster et leurs significations.

Les principaux paramètres sont illustrés à la figure 1 ci-dessus et comprennent les éléments suivants :

• Audit mode: Cela permet de séparer les journaux d’audit et de débogage ModSecurity (Configuration du système – Options de journalisation –Fichiers journaux étendus – Journaux d’audit WAF ou Configuration du système – Options de journalisation – Fichiers journaux du système – Fichier journal de débogage WAF), qui sont verbeux : vous pouvez l’utiliser pour enregistrer l’intégralité du trafic dans un LoadMaster via le WAF. Cela peut remplir votre espace disque rapidement. C’est pourquoi la valeur par défaut est Pas de vérification. Le paramètre Audit All enregistre chaque requête, ce qui serait utile pour un débogage détaillé, Audit pertinent enregistrera les demandes qui déclenchent des alertes de règle CRS et les demandes qui ont un code d’état HTTP indiquant une erreur.

Ce qui est spécifiquement enregistré dans ces fichiers est contrôlé sous Paramètres avancés – Auditer les pièces qui est décrit ci-dessous.

• Seuil de notation des anomalies : C’est le réglage clé. Chaque règle de détection dans CRS augmente le score d’anomalie. La plupart des règles ajoutent un score de 5 et lorsque le seuil est atteint, la demande est bloquée. Le défaut Seuil de notation des anomalies sur LoadMaster est de 100. Ainsi, un attaquant aurait besoin de déclencher 20 règles pour être bloqué. C’est rare, mais il est également rare qu’un utilisateur inoffensif d’une application déclenche autant de règles. Ainsi, ce paramètre par défaut est relativement sûr pour les débutants. Pourtant, j’ai vu des applications Web présenter un comportement qui faisait que les utilisateurs normaux atteignaient des valeurs de notation d’anomalie beaucoup plus élevées. C’est pourquoi j’ai d’abord défini cette valeur sur 10 000 jusqu’à ce que j’aie une bonne idée du service virtuel à portée de main. Et puis je le baisse progressivement tout en éliminant les fausses alarmes positives.

• Niveau de paranoïa : Il s’agit d’un espace réservé d’information. Ceci est configuré sous Réglages avancés qui est traité ci-dessous. Cette information est importante car un niveau de paranoïa plus élevé signifie plus de faux positifs. Et cela signifie en retour un score d’anomalie plus élevé jusqu’à ce que vous ayez éliminé les faux positifs.

• Gérer les règles : Les règles CRS sont organisées en groupes et cette liste vous donne la possibilité d’activer et de désactiver des groupes de règles ainsi que des règles individuelles. Cliquez sur le nom d’un groupe pour étendre la vue aux règles individuelles de chaque groupe. Vous pouvez ensuite activer ou désactiver les règles individuelles.

Presque tous les groupes de règles sont activés par défaut. Pourtant, lorsque vous faites défiler vers le bas Gérer les règles, vous tombez sur une section intitulée Charges de travail. Ce sont des groupes qui facilitent le travail avec ces applications bien connues. Ce qu’ils font, c’est qu’ils anticipent le comportement du logiciel et empêchent l’application de certaines règles, car ils déclencheraient un faux positif.

Prenons l’exemple de Drupal : Drupal soumet de nombreux paramètres avec des crochets dans le nom du paramètre (par exemple, id [0]). Dès qu’un certain nombre de crochets est rencontré dans un paramètre, CRS déclenche une alarme. L’activation de la charge de travail Drupal dans ce menu fait disparaître ces fausses alarmes sans qu’il soit nécessaire de les régler individuellement.

Plus d’informations sur les règles CRS sont disponibles ici

• Seuil horaire de notification d’alerte : Le LoadMaster enverra des notifications syslog à un 3^rd party syslog server ou SIEM car des vulnérabilités sont détectées. Ici, nous définissons le seuil avant l’envoi d’une notification syslog.

• Activer le blocage de la réputation IP : Ce paramètre permet d’accéder aux données de réputation mises à jour quotidiennement, ce qui permet un blocage basé sur les informations IP GEO ; il s’agit de l’emplacement géographique de l’adresse IP du client HTTP qui exécute la requête. Cela devrait être activé sous Firewall d’applications Web – Paramètres d’accès, où vous pouvez configurer automatiquement l’heure de téléchargement et d’installation des données de réputation mises à jour.

• Cliquez ici pour effectuer une analyse des faux positifs : Cela vous permet d’effectuer une analyse faussement positive pour ce service virtuel spécifique afin d’adapter le WAF à votre application. Ceci est traité dans un blog séparé, restez à l’écoute ! ?

Ensuite, regardons le Réglages avancés, comme le montre la figure 2 ci-dessous.

Il s’agit de paramètres avancés qui doivent être traités avec précaution :

• Inspectez les corps de requête HTML POST : Cela active une série d’options qui sont décrites comme suit : L’analyseur JSON et XML ainsi que l’option permettant à CRS d’inspecter d’autres types de contenu. Il est évident que vous avez besoin des deux analyseurs si vous voulez donner un sens à JSON et XML. Sinon, il s’agit simplement d’une accumulation de caractères spéciaux avec peu d’informations. Mais aussi, la troisième case à cocher, « Activer d’autres types de contenu« , est important. Il s’assure que les soumissions de formulaires normales (Type de contenu « application/x-www-form-urlencoded ») sont inspectées. Vous pouvez ensuite continuer à saisir les types de contenu individuels que vous souhaitez faire inspecter, mais vous pouvez laisser la zone de texte telle quelle (« Tous les types de contenu ») et le WAF inspectera les formulaires.

• Traiter les réponses HTTP : CRS effectue 90% de sa détection d’attaque sur la requête et son corps. Mais il existe un groupe décent de règles ciblant le corps de la réponse.

• Niveau de blocage de la paranoïa : Le niveau de paranoïa par défaut est 1 et c’est assez bon pour la plupart des installations LoadMaster. Cependant, lorsque vous souhaitez un ensemble de règles plus strict et que vous êtes prêt à régler plus de fausses alarmes, il est alors logique d’augmenter le niveau de paranoïa.

Lorsque vous augmentez le niveau de paranoïa, il est généralement suffisant d’augmenter le soi-disant niveau de paranoïa bloquant. Définir ce paramètre sur Paranoïa niveau 2 active les règles de Paranoïa niveau 2. Elles contribueront désormais au score de la demande et le WAF utilisera ensuite ce score pour décider si la demande doit être bloquée ou non.

• Exécution du niveau de paranoïa : Vous pouvez l’utiliser pour exécuter un niveau de paranoïa supérieur à celui que vous utilisez pour le score, par exemple, vous exécutez sur le niveau de paranoïa 3, mais vous ne bloquez qu’au niveau 2. Cela vous permet de jeter un coup d’œil au niveau de paranoïa 3 sans bloquer les utilisateurs légitimes. De cette façon, vous pouvez éliminer les fausses alarmes de paranoïa de niveau 3 avant d’augmenter également le niveau de blocage de paranoïa à 3.

Veuillez noter que l’interface utilisateur vous empêche de définir un Blocage du niveau de paranoïa qui est plus élevé que le Exécuter le niveau de paranoïa. Il est évident que vous ne pouvez pas bloquer à un niveau supérieur si vous n’exécutez pas ses règles.

Pièces d’audit : Les cases à cocher vous permettent de contrôler le niveau de détail dans le Audit mode fichiers journaux. Ces paramètres sont entièrement détaillés ici.

• En-tête et pied de page
  Dans tous les cas, les formats du journal d’audit UNE (En-tête du journal d’audit) et AVEC (pied de page du journal d’audit) sont fournis.
• Traiter les demandes
  Dans la configuration par défaut du traitement des requêtes, les formats du journal d’audit B (En-têtes de demande) et H (Audit Log Trailer) sont fournis.
• Réponses de processus
  Lorsque Traiter les réponses HTTP est cochée, les formats de journal d’audit supplémentaires (à tous ceux ci-dessus) E(organisme d’intervention prévu) et F (En-têtes de réponse) sont fournis. La figure 2 ci-dessus montre cette configuration.Limite de correspondance PCRE : Cette valeur contrôle le comportement du moteur d’expressions régulières dans ModSecurity. La valeur par défaut est de 3 000, ce qui est prudent et peut entraîner de nombreux messages d’erreur PCRE (« limites PCRE dépassées »). Il est donc logique d’augmenter cette valeur. Pourtant, l’augmentation de la valeur augmente également le risque d’être victime d’une soi-disant attaque par déni de service par expression régulière (« ReDoS »).Pays à bloquer : Cela vous permet d’empêcher les adresses IP de pays individuels d’accéder à votre application.

Pour boucler la boucle du test initial, j’ai mis le Seuil de notation des anomalies à 5 et répéter le test. J’obtiens ce qui suit où le WAF bloque la demande avec une erreur 403.

Demander

curl http://<<Virtual Service IP Address>>/index.html?exec=/bin/bash

Réponse

<html><head><title>403 Forbidden</title></head><body>Access denied</body>

Journaux

Les journaux LoadMaster les plus intéressants ici sont les Fichier journal des événements WAF sous Configuration du système – Options de journalisation –Fichiers journaux du système. Les journaux générés à partir de cette tentative d’accès sont affichés ici :

2021-04-18T22:46:28+00:00 lb100 wafd: [client 10.0.31.231] ModSecurity: Access denied with code 403 (phase 2). Operator GE matched 5 at TX:anomaly_score. [file "/tmp/waf/3/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "93"] [id "949110"] [msg "Inbound Anomaly Score Exceeded (Total Score: 8)"] [severity "CRITICAL"] [ver "OWASP_CRS/3.3.0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-generic"] [hostname "10.35.56.58"] [uri "/index.html"] [unique_id "5a9a2689-8e75-4cff-baef-6245cff57c67"]

Nous examinons plusieurs entrées dans ce journal

• id qui nous dit que la règle 949110 a été touchée
• msg pour savoir ce qui s’est passé, dans ce cas le score d’anomalie a été dépassé
• hostname est l’adresse de service virtuel contre laquelle l’attaque a été déclenchée
• Accès refusé indiquant que cette tentative d’accès a été bloquée avec une erreur 403