AWS WAF
Définition
Un WAF est un pare-feu applicatif, donc de couche 7. Son principal intérêt est de bloquer les attaques communes sur vos applications. Je dis bien, communes et automatisées pour la plus part.
Donc ne vous y trompez pas, vous n’allez pas protéger vos applications d’un attaquant véritablement compétent en la matiére. Le point d’entrées de vos utilisateurs sera le WAF, tout transitera par lui, par contre une fois le WAF passé ce sera à vos applications de gérer leur sécurité.
Un WAF n’est pas magique.
Je dois dire que l’on voit du WAF de plus en plus, surtout dans le Cloud, car c’est relativement simple à implémenter via les solutions des CSP. Aujourd’hui nous allons voir le WAF d’AWS, plus précisément la version 2.
Préambule
Il existe 2 versions du WAF.
- La V1 (deprecated, qui est appelée “Classic”)
- La V2
Il est possible de migrer de la V1 vers la V2 assez facilement.
Présentation de l’architecture du WAF
Exemple de rules qui font parties du top 10 OWASP
- Command execution
- DDOS
- XSS
- SQLi
- SSI (Server Side includes Injection)
- Malformed XML
- PHP attack
Combien de temps pour intégrer ce WAF dans le cloud Amazon ?
La mise en place de ce WAF n’est pas en soi très complexe, et en quelques heures il y est possible de démarrer, avec les règles de bases.
Mais cela va demander de nombreux tests sur vos environnements afin de régler le niveau et le contenu des règles.
En plus d’assurer un suivi post implémentation afin de vérifier qu’il fonctionne de façon optimale (sans dégradation de performance, sans régression visuelle).
Logs
On peut bien évidemment visualiser des logs pour le WAF sur la console mais la rétention est de seulement 3 heures.
Vous pouvez néanmoins les envoyer à votre plateforme de log notamment ElasticSearch via Amazon Kinesis Firehose.
Pas de S3 directement ? Non, ce qui est dommageable, clairement cela représente un surcout à ne pas négliger (surtout en cas de DDOS …).
Alors que d’autres services comme les load balancers permettent d’exporter les logs brut dans S3.
Il y aussi la possibilité d’activer des samples rates, ils sont directement affichés via le dashboard WAF, qui stipule le nombre de requêtes qui sont acceptées ou refusées.
Métrologie
On peut bénéficier de métriques via CloudWatch.
Notamment pour chaque rules on peut créer une métrique, ce qui est pratique pour savoir s’il y a des règles qui sont plus sollicité que d’autres.
Limites du WAF
Le WAF n’est pas la seule solution permettant de sécuriser une infrastructure, ni un applicatif.
En effet, le WAF fait partie des nombreux outils permettant de diminuer les risques de façon automatisée.
Mais en soit, il n’est pas fait pour colmater des failles présentes dans les applicatifs, ou alors de manière ponctuelle avant que l’ingénierie logicielle réalise un fix.
En occurrence, il sera toujours plus efficace, et rentable d’hardener les applications, de faire votre veille sécurité, d’avoir dans vos pipeline des tests liés à la sécurité (CVE, scan de librairies, heuristique, etc.) notamment pour éviter les compromissions par le personnel interne, mais également par des hackers chevronnées, qui ne s’arrêteront pas à réaliser des attaques par robots pour exploiter les failles.
Tester l’efficacité des règles AWF
Je vous propose deux outils :
Ces deux outils sont trés simple à utiliser l’un tourne via Docker et l’autre est un script Python, ils vous permettront de savoir en quelques minutes si vos regles de Waf sont pertinentes et surtout efficaces.
Ces outils vous généreront des métriques notamment :
- Le nombre de requêtes envoyées
- Les requêtes qui sont OK ou KO (bloquée par le WAF)
Bien évidemment, je vous encourage également à vous appuyer de CloudWatch pour comptabiliser en détail quels sont les regles à améliorer et entrer dans une démarche itérative.
Page d’erreurs personnalisées
Les pages d’erreurs personalisées sont disponibles uniquement via CloudFront !
Règles du Marketplace
A ce propos AWS propose via son MarketPlace (environ 30€ / mois le groupe de règles, plus des coûts par millions de transactions), des règles additionnelles mais en toute honnêteté elles sont peu fiables pour la pluparts et ne sont pas customisables, on peut simplement sélectionner ou désélectionner les rules.
Payer des règles OWASP en 2020, c’est totalement overkill à mon sens, un mod_security ou NagXI fait bien mieux que ça, en plus de bénéficier de nombreuses règles de la communauté.
Non seulement cela ne vous protégera vous pas contre l’exploitation des CVE, mais en plus de ça les fameuses TOP 10 OWASP sont tellement simpliste, qu’elles ne devraient même pas avoir lieu en production si vous êtes un temps soit peu sensibilisé à la sécurité et les équipes de développement le sont aussi.
Mettre un WAF pour ça, c’est comme mettre un pansement sur une jambe en bois, je vous préconise plutot de faire dans l’accompagnemement, de la conduite au changement pour tendre vers un respects des bonnes pratiques.
Pour finir, les rules issues du Marketplace sont très opaques, on ne peut pas les personnaliser.
Conclusion
Afin d’améliorer le WAF AWS, créer des règles custom devient vite une obligation, mais ça deviendra chronophage. Le tarif de ce WAF est relativement élevé dés lors que l’on utilise Kynesis, CloudWatch afin d’avoir des métriques et logs, et CloudFront pour les pages d’erreurs.
Ce WAF n’est pas suffisamment efficace (j’ai benchmarké 3 WAF du marché dans le cadre d’un POC, il est sorti dernier du benchmark). Le WAF d’Amazon n’apporte pas grand chose vis à vis d’un mod_security ou NaxSI couplé à un ElasticSearch + Kibana + SIEM. Je dirai même que la solution d’Amazon vous limitera rapidement, notamment si vous êtes un DevSecOps, car il manque de fonctionnalités.
Dans un prochain post, je vous présenterai une solution que j’utilise, bien plus efficace et industrialisable et je dirai pourquoi je l’ai choisi.
Références :