Pare-feu logiciel.
Pour limiter les attaques sur ses sites web, au-delà des bonnes pratiques classiques (mise à jour des frameworks, langages et OS), il est possible d'utiliser un pare-feu logiciel.
Ce pare-feu peut proposer des protections au niveau IP, en limitant les DDOS et en utilisant la réputation des IPs (comme le si pénible CAPTCHA de Cloudflare dès que l'on utilise TOR Browser).
Les WAF web, eux, vont proposer de lire le flot HTTP, entrant et sortant, et d'appliquer des règles dessus avant de décider une action, comme interdire l'accès.
En produits open source, il existe quelques applications complètes (ModSecurity, Naxsi) et des briques pour construire ce genre d'outils (Libinjection). ModSecurity utilise d'ailleurs dans sa dernière version libinjection. Pour protéger la partie IP, Haproxy reste l'outil de bon gout;
Un pare feu logiciel utilise un moteur, dans notre cas un plugin pour un serveur web, et des règles, que l'on peut personnaliser.
Les deux applications ont des approches opposés :
- Modsecurity propose une approche liste noire, avec des listes de signatures d'attaques connues.
- Naxsi propose une approche liste blanche, spécifique à chacune des applications web.
ModSecurity est plus ambitieux, mais aussi plus gourmand (cf billet d'Haproxy sur Naxsi).
L'expertise express Google trends est clair, Modsecurity a connu son heure de gloire pour finalement rester stable, Naxsi est apparu plus tard et à du mal à se faire connaitre à l'étranger. Qu'importe!
Dans tous les cas, il est important d'avoir un jeu de test complet pour valider que le WAF ne gêne pas le fonctionnement normal de l'application. Un WAF permet de protéger une application, sans toucher à son code, pour peu que l'on soit capable d'effectuer un test le plus exhaustif possible pour valider qu'il ne bloque aucune action légitime.
Un WAF va agir sur le flot HTTP, il est possible d'avoir des règles de filtrages équivalentes sur les accès réseaux que va faire l'application (web service distant, envoie de mail), accès disques (Apparmor) ou même accès aux appels kernels (libsecomp).
Pour limiter le cout supplémentaire de la surveillance, il est possible de se contenter de lire les actions (réseau, disque, appels systèmes…), sans les filtrer, et de collecter des statistiques ou des journaux, et d'agir potentiellement, mais avec du retard.
