Nous avons récemment déployé sur nos serveurs une nouvelle version de notre reverse proxy HTTP, avec son lot de nouveautés. Ce billet de blog est le premier d’une série visant à vous les présenter en détail.
Nous vous présentons ici le pare-feu applicatif web (Web Application Firewall, ou WAF).
Un WAF, qu’est-ce que c’est ?
La quasi-totalité des applications ont des bugs, et notamment les applications web. Ils peuvent rendre les sites vulnérables et être utilisés par des attaquants pour les pénétrer et prendre le contrôle (on parle alors généralement d’infection). Les conséquences peuvent être handicapantes (site web qui ne fonctionne plus), voire pire (fuite de données personnelles).
La cybersécurité est un domaine à part entière. En suivant certaines bonnes pratiques, et en utilisant un WAF, il est possible de diminuer drastiquement la vulnérabilité de vos sites web. Bonne nouvelle : nous avons intégré un WAF au sein de notre infrastructure et simplifié au maximum sa mise en place pour que tous nos clients puissent l’utiliser.
Un WAF est un pare-feu protégeant les applications web face à divers vecteurs d’attaques. Le WAF examine chaque requête HTTP, et peut soit les autoriser à transiter jusqu’à l’application, soit les bloquer, alerter ou consigner si elles sont jugées malveillantes. Il est généralement capable de réagir à un grand nombre de vecteurs d’attaques et donc de limiter au maximum les infections.
Le WAF Modsecurity
Plutôt que de développer une solution en interne, nous avons opté pour le WAF ModSecurity développé par Trustwave SpiderLabs. Ce projet jouit d’une bonne notoriété dans le secteur de la sécurité applicative. Par ailleurs, la communauté d’utilisateurs de ModSecurity est très active, ce qui participe à son amélioration jour après jour.
Néanmoins, ModSecurity est un moteur de sécurité applicative et un moteur sans carburant ne peut fonctionner. Le carburant de ModSecurity ce sont les règles permettant de déterminer si une requête est malveillante. Nous avons choisi d’utiliser l’ensemble de règles libres OWASP Modsecurity Core Rule Set (CRS) qui offre une protection générique à diverses attaques ainsi qu’au Top 10 OWASP avec un minimum de faux positifs.
Configurer son pare-feu applicatif chez alwaysdata
Pour plus de flexibilité et de modularité, le WAF est activable individuellement pour chacun de vos sites hébergés chez alwaysdata.
Plusieurs profils sont activables, chacun offrant un niveau de protection différent. Ils sont au nombre de six, triés par ordre croissant de protection :
- Aucun (par défaut)
- Basique
- Respect strict du protocole HTTP
- Détection de robots malveillants
- Fort
- L’ensemble des règles du profil basique
- Détection d’exécution de code à distance (RCE)
- Détection d’attaque type Cross-Site Scripting (XSS)
- Détection d’injection SQL
- Complet
- L’ensemble des règles du profil fort
- Détection d’attaques relatives au langage PHP
- Détection d’attaque par inclusion de fichier local (LFI)
- Détection d’attaque par inclusion de fichier distant (RFI)
- WordPress
- L’ensemble des règles du profil complet
- Règles spécifiques à WordPress
- Drupal
- L’ensemble des règles du profil complet
- Règles spécifiques à Drupal
Il est important de noter que l’activation d’un profil de protection va se traduire par une légère augmentation de la latence lors du traitement d’une requête HTTP. Cette latence, de l’ordre de quelques millisecondes, augmente avec le degré de protection. Ceci s’explique par le fait que cette requête doit être confrontée à un nombre plus important de règles de sécurité avant que Modsecurity ne puisse tirer ses conclusions.
Pour l’utiliser, c’est très simple. Rendez vous dans Sites → Modification → WAF et sélectionnez le profil le plus adapté à votre besoin. C’est tout.
Cette fonctionnalité est pour le moment considérée comme en phase bêta.
C’est dans notre optique de vous fournir un hébergement toujours plus qualitatif, sans rogner sur la simplicité d’utilisation, que nous vous proposons le déploiement d’un WAF en trois clics pour vos sites.
Après la sécurité, la performance ! Dans le prochain billet, nous vous présenterons notre tout nouveau cache HTTP et son impact sur la qualité de service pour vos sites web.
Rebonjour, même question que pour le cache sous WordPress. Est-ce que l’on peut considérer (une fois la phase beta passée) qu’il n’est pas nécessaire d’activer une extension pare-feu sous WP ? Est-ce que les deux seront compatibles ?
J’utilise Ninja Firewall qui protége notamment contre les attaques sur wp-login (un grand classique). J’imagine que votre solution ne va pas gérer ce genre de chose ?
Je ne connais pas Ninja Firewall mais on peut effectivement partir du principe que les deux se complètent. Pour le coup, et contrairement au cache, notre WAF fonctionne quelle que soit l’application.
Bonjour
le WAF fonctionne t il avec Joomla ?
Il n’y a pas de profil spécifique à Joomla, mais vous pouvez utiliser les autres profils sans problème.
Bonjour,
le WAF s’applique à toutes les requêtes HTTP, y compris ressources statiques (images et autres) ?
@Nicod : oui, toutes, puisque le WAF analyse la requête (et non la réponse), et qu’on ne peut pas déduire d’une URL le type de ressource qui sera réellement renvoyé.