Home Blogs Réglage WAF simplifié
Applications

About The Author

Outline

Les petites et nouvelles entreprises sont confrontées à un défi de sécurité critique. Ils ont besoin d’une solution de sécurité sophistiquée pour protéger leurs applications Web tout en minimisant les coûts liés au recrutement de spécialistes de la sécurité dédiés ou de services gérés tiers. Avec l’émergence constante de nouveaux vecteurs d’attaque, la sécurité des applications Web devient plus cruciale et plus difficile que jamais.

L’Edgecast, maintenant Edgio, WAF est la solution. Il offre une solution robuste et sophistiquée qui simplifie la gestion. Les tableaux de bord en temps réel et la diffusion des journaux offrent une visibilité à jour afin que les administrateurs puissent rapidement identifier les menaces et prendre des mesures.

Dans ce blog, nous nous concentrerons sur la façon dont les entreprises peuvent identifier et éliminer les faux positifs et créer des solutions personnalisées pour leur application Web sans encourir de coûts de support supplémentaires.

Si vous êtes nouveau dans ce domaine et que vous n’avez pas encore travaillé avec Edgio WAF, veuillez regarder ce court tutoriel pour comprendre l’interface utilisateur et comment elle fonctionne.

Si vous avez déjà un compte, n’hésitez pas à faire cet exercice avec moi.

1. Commençons par nous diriger vers le tableau de bord en temps réel et filtrer les événements WAF par heure. Il s’agit de la période pendant laquelle vous souhaitez analyser le trafic Web. (Remarque : si vous avez déjà effectué le réglage de certaines règles auparavant, assurez-vous de choisir une période après le dernier réglage).

Figure 1 : événements WAF survenus au cours des dernières 6 heures.

2. Regardez les 10 premiers ID de règle déclenchés par ce trafic. Les ID de règle sont un excellent moyen de filtrer davantage le trafic et d’observer les charges utiles pour divers événements WAF. Cela dit, commencez à filtrer le trafic par ces ID de règle un par un pour une analyse plus approfondie.

Figure 2 : les 10 principales règles déclenchées par les événements WAF.

3. Examinez ensuite les valeurs de charge utile qui ont déclenché cette règle en consultant le champ valeur correspondante.

Figure 3 : valeurs de charge utile sous la colonne valeur correspondante.

4. Analysez les valeurs de charge utile pour déterminer si elles sont malveillantes. Vous ne savez pas à quoi elles ressemblent ? Voici quelques valeurs potentiellement malveillantes que vous pouvez trouver dans la charge utile.

  • Traversée du chemin : http://some_site.com.br/../../../../some dir/some file¹ http://testsite.com/get.asp?f=/etc/passwd²‍
  • Vulnérabilités LFI : un attaquant tente d’accéder à des fichiers sensibles sur le serveur, tels que .ini. Le WAF Edgecast bloque cette extension de système de fichiers et bien d’autres extensions critiques par défaut.³‍
  • Script inter-sites : http://testsite.test/<script>Alert(“TEST”);</script>⁴ <img src=”http://url.to.file.which/not.exist” onerror=alert(document.cookie);>⁵‍
  • Injection SQL : SÉLECTIONNEZ * PARMI LES éléments OÙ ‘a’=’a’ ;⁶ SÉLECTIONNEZ 1 ;⁷‍
  • Exécution de code à distance : eval(“\$$user = ‘$regdate’) ;⁸‍
  • Attaques basées sur le temps : sélectionnez 1 et Sleep(2) ;⁹ sélectionnez BENCHMARK(2000000,MD5(‘A’)) ;¹⁰

5. Si vous ne savez toujours pas si la charge utile était malveillante, un excellent moyen de le comprendre est de consulter la liste des adresses IP clientes qui ont initié les requêtes avec la charge utile correspondante. Si les IP clients sont distribuées, c’est-à-dire variées, il y a de fortes chances que la charge utile soit un faux positif. Cependant, si toutes les adresses IP des clients ont la même valeur, cela indiquerait une attaque volumétrique potentielle, la classant ainsi comme une charge utile malveillante. Pour le démontrer, référons-nous à l’étape 3 et choisissons cette valeur appariée– {“iata”:[“TGZ”,”MEX”]} et utilisons-la comme exemple. Pour connaître la liste des adresses IP des clients qui ont envoyé cette charge utile, ajoutez la valeur correspondante comme filtre comme suit :

Figure 5 : adresses IP des clients qui ont envoyé la valeur de charge utile : {“iata”:[“TGZ”,”MEX”]}.

Dans ce cas, compte tenu de la variété des adresses IP faisant cette demande, il y a une forte probabilité que ces demandes proviennent d’utilisateurs réels, ce qui en fait un bon candidat pour un faux positif.

6. Une fois qu’un faux positif est identifié, vous pouvez créer une exception pour lui dans la section règles gérées, mais avant de faire cela, vous devez savoir où cette charge utile a été trouvée : chaîne de requête, en-tête de requête, URL ou autre emplacement. Pour ce faire, consultez la colonne correspondant à sur la même page à partir de l’étape 5. Dans ce cas d’utilisation, la charge utile a été trouvée dans l’argument de requête « data », comme indiqué ci-dessous :

Figure 6 : emplacement de la valeur de la charge utile : {“iata”:[“TGZ”,”MEX”]}.

7. Une bonne règle empirique est de filtrer ces correspondances spécifiques sur les champs qui contiennent la charge utile faussement positive, puis de vérifier qu’il n’y a pas d’autre requête avec ce paramètre apparié sur portant une charge utile malveillante réelle. En d’autres termes, la charge utile dans le champ particulier apparié sur n’est jamais malveillante. Ceci est réalisé en ajoutant un filtre sur le champ correspondant à un champ en question. En regardant notre cas d’utilisation, nous pouvons confirmer qu’il n’y a pas de charge utile malveillante trouvée dans cet argument de requête:

Figure 7 : toutes les valeurs de charge utile envoyées dans l’argument de requête : Data.

8. La dernière étape avant de créer une exception consiste à trouver les ID de règle déclenchés par le champ correspondant on. Nous essayons de noter toutes les règles (Rule IDS) qui ont été déclenchées par ce faux positif. Sur la base de notre cas d’utilisation, ces informations sont disponibles sur la même page à partir de l’étape 5.

Figure 8 : liste des règles déclenchées par la valeur de charge utile : {“iata” : [“TGZ”,”MEX”]}.

9. Il est temps de créer l’exception. Accédez à la section règles gérées et cliquez sur la règle gérée à laquelle vous souhaitez ajouter ces exceptions.

Figure 9 : règles gérées existantes créées pour la configuration WAF.

10. Allez dans l’onglet exceptions et cliquez sur Ajouter une nouvelle condition. Choisissez le type de correspondance sur le champ, tel que args, request_cookies ou URL où la charge utile a été trouvée. Entrez ensuite le nom du paramètre, tel que query ou cookie. Enfin, entrez la liste de tous les ID de règle déclenchés par la charge utile.

Figure 10 : onglet exceptions sous la configuration règle gérée.

11. Allez-y et créez cette condition. Dans les 30 secondes suivant l’enregistrement de la règle gérée, vous pourrez voir ce faux positif passer par le WAF

12. Maintenant que vous savez comment cela fonctionne, retournez à l’étape 3, filtrez le trafic par un autre ID de règle, et répétez ce processus pour éliminer autant de faux positifs que possible.

Vous l’avez fait. Vous venez de personnaliser la solution WAF pour votre trafic.

Quelques derniers conseils

Si vous utilisez l’Edgio WAF pour la première fois, nous vous recommandons d’effectuer 2-3 tours de cet exercice avant d’activer le mode bloc. Et en fonction de votre volume de trafic, vous pouvez répéter cet exercice tous les 2-7 jours. Pour les clients existants de Edgio WAF, nous recommandons d’effectuer cet exercice de réglage toutes les 3-4 semaines. Une autre chose que vous devriez considérer est d’abaisser la valeur de seuil de votre règle gérée à moins de 10, en faisant progressivement votre chemin vers la valeur optimale de 5. Cela garantit que vous curez régulièrement un jeu de règles plus précis et plus net. N’oubliez pas que l’Edgio WAF offre un double WAF, un environnement de mise en scène réel (le mode audit) pour votre trafic en temps réel. Vous pouvez utiliser le mode audit pour toutes vos mises à jour récurrentes et réglages précis du jeu de règles sans vous soucier de perdre du trafic légitime.

Contactez-nous dès aujourd’hui pour en savoir plus sur toutes nos technologies de sécurité qui protègent vos applications Web.

Ressources :

¹⁻² OWASP, «traversée de chemin», owasp.org, owasp.org/www-community/attacks/Path_Traversal.

³ sécurité offensive, «vulnérabilités d’inclusion de fichiers» , offensive-security.com, offensive-security.com/metasploit-unleashed/file-inclusion-vulnerabilities/.

⁴⁻⁵ OWASP, «Cross site scripting» , owasp.org, owasp.org/www-community/attacks/xss/.

⁶⁻⁷OWASP, «injection SQL» , owasp.org, owasp.org/www-community/attacks/SQL_Injection.

⁸ Netsparker, «vulnérabilité d’évaluation (d’exécution) de code à distance» , netsparker.com, netsparker.com/blog/web-security/remote-code-evaluation-execution/.

⁹⁻¹⁰ Asheff, Ahmad, «Timing-based Attacks in web applications» , owasp.org, owasp.org/www-pdf-archive/2018-02-05-AhmadAshraff.pdf.