WAF : qu’est-ce que c’est ?


Le Web Application Firewall

  1. Définition.
  2. Les différents WAF.
  3. WAF par liste bloquée ou par liste autorisée.
  4. WAF sur le réseau, hôte ou cloud.
  5. Mise en place d’un exemple avec ModSecurity sur Apache2.

1. Définition :

Le WAF : Web Application Firewall (pare-feu d’application web). Permet de protéger un serveur Web. C’est dans ce but que les requêtes faites au serveur sont analysées pour garantir sa sécurité.

Autrement dit : les requêtes sont filtrés et vérifiés selon les règles du firewall. En fait la requête malveillante n’atteint pas le serveur web ou d’applications. Ainsi, le firewall bloque la requête.

Schéma WAF avec requêtes
Schéma WAF avec requêtes
  • Attaques par injection
  • Authentification défectueuse
  • Exposition de données sensibles
  • Entités externes XML (XXE)
  • Contrôle d’accès défectueux
  • Mauvaise configuration de la sécurité
  • Scripts intersites (XSS)
  • Désérialisation non sécurisée

En résumé, un Web Application Firewall est un type de proxy inversé qui protège le serveur en faisant passer les requêtes par celui-ci avant d’atteindre le serveur.


2. Les différents WAF :

Il existe différents WAF disponibles, dont certains sont commerciaux, tels que : Cloudflare Web Application Firewall, AWS Web Application Firewall, Sucuri Website Firewall, Qualys Web Application Firewall, F5 Advanced Web Application Firewall. Il existe aussi des solutions open source comme ModSecurity (Apache2, Nginx, IIS (Windows Server)), Naxsi (pour Nginx), WebKnight (pour Microsoft IIS).


3. WAF par liste bloquée ou par liste autorisée :

En général, un Web Application Firewall fonctionnant avec une liste bloquée (modèle de sécurité négatif) protège contre les attaques connues.

À l’inverse, un Web Application Firewall basé sur une liste autorisée (modèle de sécurité positive) ne laisse entrer que le trafic préalablement approuvé.

De nombreux Web Application Firewall utilisent ces deux modèles car les listes bloquées et autorisées ont tous les deux des avantages et des inconvénients.


4. WAF sur le réseau, hôte ou cloud :

  • Un WAF basé sur le réseau est généralement matériel. Installés localement, ceux basés sur le réseau sont plus coûteux mais réduisent la latence. Ils nécessitent de l’espace, de l’entretien et de la maintenance des équipements physiques.

  • Ensuite un WAF basé sur l’hôte peut être intégré dans le logiciel d’une application. Comparativement à ceux basés sur le réseau, ils offrent plus de possibilités de personnalisation et sont moins coûteux. Cependant la consommation des ressources du serveur local, la complexité de la mise en œuvre et les coûts de maintenance peuvent faire aussi monter les prix non plus pour le WAF mais pour le serveur.

  • Pour finir les WAF basés sur le cloud offrent une alternative abordable et très facile à mettre en œuvre ; généralement, ils proposent une installation clé en main aussi simple qu’un changement de DNS pour rediriger le trafic. Les utilisateurs paient tous les mois ou tous les ans pour la sécurité de leurs service, de ce fait les WAF basés sur le cloud ont un coût minimal. Les WAF basés sur le cloud peuvent également offrir une solution continuellement mise à jour pour se protéger contre les menaces les plus récentes sans aucun travail ni coût supplémentaire pour l’utilisateur. L’inconvénient d’un WAF basé sur le cloud tient au fait que les utilisateurs transfèrent la responsabilité à un tiers, par conséquent, certaines de ses fonctionnalités peuvent constituer une zone noire pour eux (n’ont pas forcément plein pouvoir sur ce qui peut se passer). (Ceux basés sur le cloud est un type de pare-feu cloud ; en savoir plus sur les pare-feux cloud.)

5. Mise en place d’un exemple avec ModSecurity sur Apache2 :

Cependant, il est requis d’installer Apache2 pour se créer une application web, je vous conseille donc de vous diriger vers cette page.

Installation des paquets de modsecurity :

apt-get install libapache2-mod-security2

Renommer le fichier modsecurity.conf-recommended en modsecurity.conf :

cd /etc/modsecurity
mv modsecurity.conf-recommended modsecurity.conf

Modifier SecRuleEngine DetectionOnly :

sudo nano /etc/modsecurity/modsecurity.conf
#chercher la ligne en question et la mettre à la valeur ci-dessous
SecRuleEngine On 

Changement de SecAuditLogParts à :

SecAuditLogParts ABCEFHJKZ
#chercher la ligne en question

Restart le service apache2 :

sudo systemctl restart apache2

Chemin pour avoir accès aux logs de Modsecurity :

/var/log/apache2/modsec_audit.log