On connait tous le terme firewall qui sont des logiciels ou équipement capables de filtrer les connexions.
Ainsi, il est possible de bloquer des connexions sur des règles établies sur les ports, protocoles (TCP, UDP, etc) ou des adresses IPs.
Les WAF pour Web Application Firewall sont les dernières générations de pare-feux.
Ces derniers fonctionnent sur le serveur WEB ou dans une application comme WordPress.
A partir d’une signature, un WAF peut bloquer une requête HTTP malveillante et retourner un code, comme 403 pour “interdiction”.
Cela aide donc à protéger son serveur WEB et site internet contre les attaques DoS et piratages.
Voici une présentation et survol des WAF.
Table des matières
Qu’est-ce qu’un WAF
Un WAF est un firewall WEB.
Il surveille les connexions HTTPs et selon certaines règles et signatures peut bloquer ou autoriser une requête HTTP.
Ces signatures reposent souvent des règles en RegEx.
L’intérêt de ce type de pare-feu est multiple :
- Bloquer les tentatives de piratages du serveur WEB à partir de signatures
- Cross‑site scripting (XSS), (CSRF)
- Remote File Include (RFI)
- Remote code execution (RCE)
- Local File Include (LFI)
- Améliorer les protections contre les 0-days
- Bloquer des requêtes HTTP à partir d’une adresse IP, UserAgent, référent, GeoIP.
- Protéger certaines ressources sensibles et critiques (Page d’administration, etc)
- Atténuer le trafic automatique et les bots
- Log et journaux plus précis sur les requêtes HTTP et mise en place d’alerte en cas d’attaques
Cette surveillance et inspection se fait sur différentes parties de la requête HTTP.
- L’adresse IP du client : gestion de liste blanche ou liste noire
- Le userAgent, par exemple, on peut interdire des bots à partir de ce dernier.
- Le contenu de l’URL, par exemple, une attaque RFI peut-être détectée en vérifiant les paramètres passés dans l’URL par exemple : file=/etc/password
- Le contenu de la requête HTTP avec les données et par exemple détecter un script malveillant.
Enfin un WAF peut appliquer ces règles globalement, c’est à dire à toutes les ressources, URL ou paramètres.
Cela est très utile pour éviter et traiter les faux positifs.
Par exemple, ci-dessous l’accès au panneau d’administration de WordPress est interdite pour cette adresse IP.
En effet, le WAF n’autorise que les connexions à cette URL que pour des IPs autorisées.
Dans cet autre exemple, l’accès à la page est interdite car le WAF a détecté une attaque RFI/LFI car on tente d’accéder au fichier /etc/password.
WAF (Web Application Firewall) pour protéger son serveur WEB des attaques DoS et piratages
WAF intégré au serveur WEB
Un Web Application Firewall peut-être intégré au serveur WEB.
Ce dernier va donc analyser les requêtes HTTP en amont avant de les autoriser sur le serveur WEB.
Un administrateur ayant un serveur dédié peut donc installer un WAF sans soucis.
Le module modsecurity disponible pour Apache et Nginx est la référence.
Un article de présentation existe sur le site : Présentation modsecurity pour Apache
Pour résumer, il faut installer et active le module modsecurity puis on créé les règles de signatures à appliquer.
Du côté des applications possibles, un anti-spam phpBB basé sur du GeoIP : modsecurity avancé : antispam WordPress et phpBB
L’installation est relativement simple, par contre, la mise en place de signature s’avère plus compliquée.
Il faut gérer les faux positifs qui peuvent être nombreux.
A noter qu’il faut un serveur WEB assez puissant au niveau de la CPU et mémoire, en effet, ces analyses alourdissent le serveur WEB et peut donc allonger le temps de réponse des pages.
Pour les architectures plus complexes, on peut imaginer des WAF sur des serveurs dédiés sous la forme de web-proxy inversé (proxy reverse) qui se positionnent en amont du serveur WEB.
WAF et CDN
Des offres de CDN intégrant des WAF ont vu le jour avec des offres très accessibles : Cloudflare, Sucuri, Imperva, etc.
Il s’agit donc d’offres WAF en SAAS.
Le but est de positionner le CDN et WAF en amont du serveur WEB ou de l’hébergeur WordPress.
Ainsi il s’intercale entre le client et le serveur WEB final afin de contrôler et bloquer les requêtes WEB qui passent.
Le fonctionnement technique est globalement le même que précédemment.
Simplement ici vous bénéficiez d’infrastructures plus importantes et réparties dans le monde.
Vous n’avez donc pas à vous souciez ou très peu des montés de chargés.
Enfin, vous déléguez la partie vraiment complexe du WAF, ce qui vous permet de vous concentrez à d’autres tâches.
Le schéma ci-dessous récapitule l’architecture avec à gauche une requête HTTP/HTTPS provenant d’internet qui passe par le CDN (ici Sucuri).
Si la requête est autorisée ; la page du cache du CDN est envoyée ou on demande la page au serveur WEB final.
A contrario, si la requête correspond à une signature, elle est interdite.
On obtient alors une page d’erreur d’autorisation et d’accès provenant du CDN comme donnée en exemple dans le paragraphe précédent.
Une modification des DNS est nécessaire pour faire pointer le domaine du site sur l’adresse du CDN.
Ensuite, on fait les déclarations qui vont bien sur l’interface du CDN pour que la connexion entre le CDN et le serveur WEB se fasse.
Vous trouverez plus d’informations sur les CDN sur la page :
Exemple de règles de WAF
Ci-dessous le WAF de Cloudflare où l’on peut activer des règles par groupe par type de plateforme (PHP, Joomla, WordPress).
Cela active un groupe de règles qui protège des piratages ou attaques contre ces plateformes.
Les règles globales du WAF globales qui reprennent celle de ModSecurity.
Cela permet de bloquer des requêtes HTTP anormales ou suspicieuses.
Notez que l’action à effectuer est à paramétrer : bloquer ou un défi captcha.
On peut même activer ou désactiver certaines règles.
Enfin l’utilisateur peut aussi créer ses propre règles de filtrage sur le WAF.
Ici on interdit l’accès à une URL spécifique pour certains pays.
Très pratique pour sécuriser certaines pages sensibles de votre site internet.
Journaux et Logs
Enfin les requêtes WEB qui passent à travers le CDN et WAF sont enregistrées dans des journaux.
A partir de là, il est possible de proposer un résumé des évènements.
Cela permet d’avoir une idée des requêtes bloquées et détecter des comportements anormaux.
Par exemple ci-dessous, une petite attaque DoS L7.
On voit que la majorité des IP proviennent de Russie.
On a aussi le détails par numéro de réseau (ASN).
On peut ensuite aussi les afficher sur les graphiques.
A partir de là, il est possible de créer des règles de filtrages plus précises pour mieux protéger votre serveur WEB.
WAF en extension pour WordPress
Sur WordPress, il existe des plugins WAF.
Ces derniers analysent les requêtes HTTP avant d’autoriser l’accès au contenu de WordPress.
Ils ont l’avantages d’être très simples à mettre en place puisqu’il suffit d’installer l’extension.
Ensuite, on peut paramétrer l’extension et activer ou non certaines protections.
|
|
Les limites des WAF
Comme toute protection, les WAF ne dérogent pas et peuvent être contournés.
Par exemple, en jouant sur les X-Forwards ou contenu de la requête, il reste possible de contourner les règles.
La première chose à comprendre est que l’efficacité du WAF dépend des règles et signatures mises en place.
Ainsi, un WAF peut par exemple aider à se protéger des attaques 0day aveugles et automatisées.
Cependant, il sera probablement moins efficaces contre une attaque ciblée.
Par exemple, en mars 2019, CloudFlare protégeait ses sites Drupal d’une attaque 0-day massive : Stopping Drupal’s SA-CORE-2019-003 Vulnerability
Il faut aussi penser qu’un WAF est un logiciel, donc il peut aussi comporter des vulnérabilités.
Ce dernier peut donc au final être utilisé pour compromettre un serveur WEB.
En clair donc, il faut bien voir le WAF comme un maillon dans une chaîne de sécurité et non comme le maillon essentiel qui protège de tout.
Le WAF de Cloudflare
Voici une présentation complète du Firewall Web de Cloudflare :