En termes de technologie, les pare-feu sont vieux comme le monde. En 40 ans d’existence, il y a eu plus de pare-feu de « nouvelle génération » que de pare-feu de genre musical. Au fond, ils autorisent ou refusent les paquets qui entrent ou sortent d’un réseau et, aussi utile que cela puisse être, ils n’ont pas grand-chose d’autre à offrir. Chaque génération ajoute quelque chose de nouveau au mélange de politiques qui décide de ce qui « passe la porte », mais un videur mieux informé n’est toujours qu’un videur. L’identification de l’utilisateur, la détection des intrusions, l’heure de la journée, les chaussures, l’utilisation de la bande passante, la coiffure ou l’état de la session TCP ne déterminent toujours pas si quelque chose est sûr ou digne de confiance.
C’est là qu’intervient notre « réparateur », qui en sait (ou du moins peut en apprendre) beaucoup plus sur nos clients et sur ce qu’ils sont susceptibles de faire : le pare-feu d’application Web, ou WAF (Web Application Firewall). Oubliez qui est autorisé à entrer, un WAF spécifie quels comportements sont acceptables et lesquels ne le sont pas une fois que vous êtes à l’intérieur du périmètre. Avec un WAF, ce sont les fonctions de l’application et les entrées et sorties qui sont autorisées ou refusées, et non l’accès.
Il s’agit clairement d’une approche plus sophistiquée et plus approfondie qu’un choix binaire entre autoriser ou refuser. Elle permet un contrôle fin et la mise en œuvre d’une politique de sécurité d’une manière plus significative, voire naturelle. Si un site web ne fournit que des informations à lire ou à télécharger, un WAF vous permet de vous assurer qu’aucun fichier n’est téléchargé sur les serveurs qui le fournissent. Vos serveurs peuvent utiliser un backend SQL, mais ce n’est pas une raison pour que les clients incluent des requêtes SQL dans leurs demandes. En résumé, un WAF vous protégera contre un utilisateur malveillant – un utilisateur que votre pare-feu « réseau » a déjà laissé passer, car il n’a aucun moyen de faire la différence avec un utilisateur bénin.
Le module WAF, disponible avec notre version de l « équilibreur de charge avancé ALB-X, est le premier que nous avons publié sous forme de conteneur Docker. Il s’agit d’une nouvelle orientation passionnante et, conformément à notre philosophie, aussi simple que possible. Vous n’avez pas besoin de comprendre les subtilités de Docker ou des conteneurs pour l’utiliser. Comme il s’agit d’un conteneur, le WAF peut être installé et mis à jour indépendamment du logiciel ALB-X – pas besoin de redémarrer. Vous pouvez également exécuter plusieurs conteneurs WAF pour appliquer différentes politiques à différents services et améliorer l »isolation. En bref, cette approche offre une grande souplesse d’exploitation.
Dans cette optique, plusieurs options de mise en œuvre sont disponibles selon que vous souhaitez protéger le trafic non crypté ou crypté (HTTPS) (qui doit être décrypté pour permettre l’inspection). Avec HTTPS, vous pouvez choisir de recrypter le trafic avant de l’envoyer à un serveur réel.
Le module WAF offre une protection contre les applications web mal codées et leurs vulnérabilités, mais il ne doit pas être considéré comme une solution unique pour un code mal écrit avec des trous béants ; traitez la cause, pas les symptômes. N’oubliez pas qu’une approche conjointe et approfondie constitue la meilleure défense. Des cookies correctement formulés, des règles de gestion du trafic flightPATH, des en-têtes et des restrictions HTTP appropriés et d’autres outils combinés sont de loin supérieurs à un seul mur apparemment impénétrable. Sécurisez tout ce que vous pouvez et la vraie sécurité pourrait bien suivre.
Prenez en compte les paquets et le trafic (adresses IP et ports), les protocoles, les applications, les services et les transactions. Si vous vous fiez trop aux protections d’un seul élément, vous risquez d’avoir des problèmes. Dans le même esprit de prudence, gardez à l’esprit les points suivants ;
- Même s’il est conscient de l’application, un WAF ne peut pas faire grand-chose, car il ne sait pas comment fonctionne votre application ni comment vous souhaitez qu’elle fonctionne.
- Le WAF utilise une « base de règles » commune qui repose sur un certain nombre d’hypothèses qui peuvent ne pas convenir à votre application (par exemple, les téléchargements de fichiers ne sont pas autorisés) – testez de manière appropriée en utilisant le mode Détection par défaut avant de passer à la production.
- Les innovations plus récentes telles que AJAX, HTML5 et autres peuvent ne pas être prises en compte ou protégées.
Comme c’est le cas pour la plupart des fonctionnalités d’ALB-X, l’énorme avantage de leur mise en œuvre sur ALB-X est que nous n’avons à le faire qu’en un seul endroit central afin de protéger tous nos serveurs. Nous n’avons pas besoin de faire appel à des développeurs ou à des reconfigurations de serveurs web. La mise à jour du jeu de règles du WAF (la liste des comportements inacceptables) ne prend que quelques clics et ne doit être effectuée qu’une seule fois, quel que soit le nombre de WAF que vous exécutez.
Vous trouverez plus d’informations sur le WAF ici – une autre nouveauté passionnante que nous vous encourageons à découvrir. Vous trouverez un guide d’installation détaillé ici.
Testez-le en ligne maintenant
Un pare-feu d’application Web permet un contrôle et une mise en œuvre très précis de la politique de sécurité, y compris la gestion de ce qui est autorisé ou refusé dans les fonctions d’application et les entrées et sorties.
