Dans notre précédent article sur le thème du cloud, nous , avons discuté de la protection des ressources informatiques dans le cloud public et pourquoi les antivirus traditionnels ne sont pas tout à fait adaptés à ces fins. Dans ce billet, nous poursuivrons le sujet de la sécurité dans le cloud et parlerons de l'évolution des WAF et de ce qu'il est préférable de choisir : matériel, logiciel ou cloud.
Qu'est-ce qu'un WAF
Plus de 75 % des attaques des hackers ciblent les vulnérabilités des applications web et des sites : ces attaques sont généralement invisibles pour les infrastructures et services de sécurité informatique. Les vulnérabilités des applications web comportent, à leur tour, des risques de compromission et de fraude des comptes et des données personnelles des utilisateurs, mots de passe, numéros de cartes de crédit. De plus, les vulnérabilités sur un site web servent de point d'entrée pour les cybercriminels dans le réseau d'entreprise.
Un Web Application Firewall (WAF) est un écran de protection qui bloque les attaques sur les applications web : injections SQL, scripting intersite, exécution de code à distance, attaques par force brute et contournement d'autorisation (auth bypass). Cela inclut les attaques utilisant des vulnérabilités zero-day. Les pare-feu applicatifs assurent la protection en surveillant le contenu des pages web, y compris HTML, DHTML et CSS, et en filtrant les requêtes potentiellement malveillantes via HTTP/HTTPS.
Comment étaient les premières solutions ?
Les premières tentatives de créer un Web Application Firewall ont eu lieu au début des années 90. On sait qu'au moins trois ingénieurs ont travaillé dans ce domaine. Le premier est le professeur d'informatique Gene Spafford de l'Université Purdue. Il a décrit l'architecture d'un pare-feu applicatif avec proxy et a publié celle-ci en 1991 dans le livre .
Le deuxième et le troisième étaient des spécialistes de la sécurité informatique, William Cheswick et Marcus Ranum des Bell Labs. Ils ont développé l'un des premiers prototypes de pare-feu applicatifs. Sa diffusion était assurée par la société DEC — le produit a été lancé sous le nom de SEAL (Secure External Access Link).
Mais SEAL n'était pas une solution WAF complète. C'était un pare-feu réseau classique avec une fonctionnalité étendue — la capacité de bloquer les attaques sur FTP et RSH. Pour cette raison, le premier produit considéré comme une solution WAF aujourd'hui est celui de Perfecto Technologies (plus tard Sanctum). En 1999, elle a le système AppShield. À l'époque, Perfecto Technologies développait des solutions de sécurité pour le commerce électronique, et leur nouveau produit ciblait les magasins en ligne. AppShield était capable d'analyser les requêtes HTTP et de bloquer les attaques en fonction de politiques de sécurité dynamiques.
Environ au même moment qu'AppShield (en 2002), le premier WAF open source est apparu. Il s'agit de . Il a été créé dans le but de populariser les technologies WAF et est toujours soutenu par la communauté IT (voici son ). ModSecurity bloque les attaques sur les applications en se basant sur un ensemble standard d'expressions régulières (signatures) — des outils pour valider les requêtes selon un modèle — .
En fin de compte, les développeurs ont atteint leur objectif — de nouvelles solutions WAF ont commencé à émerger sur le marché, y compris celles basées sur ModSecurity.
Trois générations — déjà de l'histoire
On distingue généralement trois générations de systèmes WAF, qui ont évolué avec le développement des technologies.
La première génération. Fonctionne avec des expressions régulières (ou des grammaires). ModSecurity en fait partie. Le fournisseur du système étudie les types d'attaques sur les applications et crée des modèles qui décrivent les requêtes légitimes et potentiellement malveillantes. Le WAF se confronte à ces listes et décide quoi faire dans une situation donnée — bloquer le trafic ou pas.
Un exemple de détection basée sur des expressions régulières est le projet déjà mentionné open source. Un autre exemple est , qui est également open source. Les systèmes basés sur des expressions régulières présentent plusieurs inconvénients, notamment lorsqu'il s'agit de détecter une nouvelle vulnérabilité où l'administrateur doit créer manuellement des règles supplémentaires. Dans le cas d'une infrastructure IT de grande envergure, le nombre de règles peut atteindre plusieurs milliers. Gérer un tel volume d'expressions régulières est assez difficile, sans parler du fait que leur vérification peut réduire les performances du réseau.
Les expressions régulières présentent également un niveau d'erreurs assez élevé. Le linguistique célèbre Noam Chomsky a proposé une classification des grammaires, la divisant en quatre niveaux de complexité conditionnels. Selon cette classification, les expressions régulières ne peuvent décrire que des règles de pare-feu qui ne prévoient pas d'écarts par rapport au modèle. Cela signifie que les attaquants peuvent facilement « tromper » un WAF de première génération. L'une des méthodes pour y remédier consiste à ajouter des caractères spéciaux aux requêtes des applications, qui n'affectent pas la logique des données malveillantes, mais qui violent la règle de signature.
Deuxième génération. Pour contourner les problèmes de performance et de précision des WAF, des pare-feu d'applications de deuxième génération ont été développés. Ils sont dotés de parseurs chargés d'identifier des types d'attaques strictement définis (sur HTML, JS, etc.). Ces parseurs fonctionnent avec des jetons spéciaux décrivant les requêtes (par exemple, variable, chaîne, inconnu, nombre). Les séquences de jetons potentiellement malveillantes sont mises sur une liste séparée, que le système WAF vérifie régulièrement. Cette approche a été présentée pour la première fois lors de la conférence Black Hat 2012 sous forme de bibliothèque C/C++ , qui permet de détecter les injections SQL.
Comparées aux WAF de première génération, les parseurs spécialisés peuvent fonctionner plus rapidement. Cependant, ils n'ont pas résolu les difficultés liées à la configuration manuelle du système face à l'émergence de nouvelles attaques malveillantes.
Troisième génération. L'évolution dans la logique de détection de la troisième génération réside dans l'application de méthodes d'apprentissage automatique, permettant de rapprocher au maximum la grammaire de détection de la véritable grammaire SQL/HTML/JS des systèmes protégés. Cette logique de détection est capable d'adapter la machine de Turing pour couvrir des grammaires énumérables récursivement. De plus, la tâche de créer une machine de Turing adaptable était auparavant insurmontable, jusqu'à la publication des premières recherches sur les machines de Turing neuronales.
L'apprentissage automatique offre une opportunité unique d'adapter n'importe quelle grammaire pour couvrir tout type d'attaque sans avoir à créer manuellement des listes de signatures, comme cela était nécessaire pour la détection de première génération, et sans avoir à développer de nouveaux tokenizers/parsers pour de nouveaux types d'attaques, tels que les injections Memcached, Redis, Cassandra, SSRF, comme l'exigeait la méthodologie de deuxième génération.
En combinant les trois générations de logique de détection, nous pouvons dessiner un nouveau diagramme, où la détection de troisième génération est représentée par un contour rouge (fig. 3). Cette génération inclut l'une des solutions que nous mettons en œuvre dans le cloud en collaboration avec « Onsec », le développeur de la plateforme de protection adaptative des applications web et des API Valarm.
Dans la logique de détection, les retours d'informations des applications sont désormais utilisés pour l'auto-ajustement. Dans le cadre de l'apprentissage automatique, ce cycle de rétroaction est appelé « renforcement ». Il existe généralement un ou plusieurs types de ce renforcement :
- Analyse comportementale de la réponse de l'application (passif)
- Scan/fuzzer (actif)
- Fichiers de rapports/procédures-intercepteurs/pièges (a posteriori)
- Manuel (déterminé par le superviseur)
En conséquence, la logique de détection de troisième génération résout également un problème important de précision. Il est désormais possible non seulement d'éviter les faux positifs et les faux négatifs, mais aussi de détecter des résultats négatifs réellement acceptables, tels que la détection de l'utilisation d'instructions SQL dans le panneau de contrôle, le chargement de modèles de pages web, des requêtes AJAX liées à des erreurs JavaScript, et d'autres.
Examinons maintenant les capacités technologiques des différentes options de mise en œuvre de WAF.
Matériel, logiciel ou cloud — que choisir ?
Une des options de mise en œuvre des pare-feu d'applications est la solution « matérielle ». Ces systèmes représentent des dispositifs de calcul spécialisés que l'entreprise installe localement dans son centre de données. Mais dans ce cas, il est nécessaire d'acheter son propre matériel et de payer des intégrateurs pour sa configuration et son réglage (si l'entreprise n'a pas son propre service informatique). Dans ce cas, tout matériel devient obsolète et se dégrade, ce qui pousse les clients à prévoir un budget pour la mise à niveau de leur infrastructure.
Une autre option de déploiement du WAF est sa réalisation logicielle. La solution s'installe comme un complément à un logiciel existant (par exemple, ModSecurity est configuré au-dessus d'Apache) et fonctionne sur le même serveur que celui-ci. En général, de telles solutions peuvent être déployées à la fois sur un serveur physique et dans le cloud. Leur inconvénient est les capacités limitées d'évolutivité et de support de la part du fournisseur.
La troisième option est la configuration du WAF dans le cloud. Ces solutions sont fournies par des fournisseurs cloud sous forme de service par abonnement. Les entreprises n'ont pas besoin d'acheter et de configurer du matériel spécialisé, ces tâches incombent au fournisseur de services. Un point important est qu'un WAF cloud moderne ne nécessite pas de migration des ressources vers la plateforme du fournisseur. Le site peut être déployé n'importe où, même sur site.
Pourquoi regardons-nous de plus en plus vers le WAF cloud, nous allons l'expliquer ci-dessous.
Que peut faire un WAF dans le cloud
D'un point de vue technologique :
- Le fournisseur est responsable des mises à jour. Le WAF est proposé par abonnement, donc le fournisseur de services veille à la mise à jour et à la validité des licences. Les mises à jour concernent non seulement les logiciels, mais aussi le matériel. Le fournisseur met à niveau le parc serveur et en assure la maintenance. Il s'occupe également de l'équilibrage de la charge et de la redondance. En cas de défaillance du serveur WAF, le trafic est immédiatement redirigé vers une autre machine. Une distribution rationnelle du trafic permet d'éviter des situations où le pare-feu passe en mode fail open — ne peut plus gérer la charge et cesse de filtrer les requêtes.
- Patching virtuel. Des correctifs virtuels limitent l'accès aux parties compromises de l'application jusqu'à ce que le développeur ferme la vulnérabilité. En conséquence, le client du fournisseur de cloud peut attendre tranquillement que le fournisseur du logiciel publie les « correctifs » officiels. Faire cela le plus rapidement possible est une priorité pour le fournisseur de logiciels. Par exemple, dans la plateforme « Valarm », un module logiciel distinct est responsable du patching virtuel. L'administrateur peut ajouter des expressions régulières personnalisées pour bloquer les requêtes malveillantes. Le système permet de marquer certaines requêtes avec le drapeau « Données confidentielles ». Ainsi, leurs paramètres sont masqués et elles ne sont, en aucun cas, transmises au-delà de la zone de travail du pare-feu.
- Scanner de périmètre et de vulnérabilités intégré. Cela permet de définir soi-même les limites réseau de l'infrastructure informatique, en utilisant les données des requêtes DNS et du protocole WHOIS. Ensuite, le WAF analyse automatiquement les services et les applications en fonctionnement au sein du périmètre (effectue un scan des ports). Le pare-feu est capable de détecter tous les types de vulnérabilités courants — SQLi, XSS, XXE, etc. — et d'identifier les erreurs de configuration logicielle, par exemple, un accès non autorisé aux dépôts Git et BitBucket et des accès anonymes à Elasticsearch, Redis, MongoDB.
- Les attaques sont surveillées par les ressources cloud. En règle générale, les fournisseurs de cloud disposent de grandes capacités de traitement. Cela permet d'analyser les menaces avec une grande précision et rapidité. Un cluster de nœuds filtrants est déployé dans le cloud, par lequel tout le trafic passe. Ces nœuds bloquent les attaques sur les applications web et envoient les statistiques au Centre d'analytique. Celui-ci utilise des algorithmes d'apprentissage automatique pour mettre à jour les règles de blocage pour toutes les applications protégées. La mise en œuvre d'un tel schéma est indiquée sur la fig. 4. De telles règles de sécurité adaptées minimisent le nombre de faux positifs du pare-feu.
Voyons maintenant les particularités des WAF cloud du point de vue des aspects organisationnels et de la gestion :
- Passage à l'OpEx. Dans le cas des WAF cloud, le coût d'implémentation sera nul, car tout le matériel et les licences ont déjà été payés par le fournisseur, le paiement du service se fait par abonnement.
- Différents plans tarifaires. L'utilisateur du service cloud peut rapidement activer ou désactiver des options supplémentaires. La gestion des fonctionnalités s'effectue à partir d'un tableau de bord unique, qui est également sécurisé. L'accès se fait via HTTPS, et un mécanisme d'authentification à deux facteurs basé sur le protocole TOTP (Time-based One-Time Password Algorithm) est également disponible.
- Connexion par DNS. Il est possible de modifier le DNS soi-même et de configurer le routage sur le réseau. Pour résoudre ces tâches, il n'est pas nécessaire de former des spécialistes individuels. En général, le support technique du fournisseur peut aider avec la configuration.
Les technologies WAF ont évolué des simples pare-feux réseau avec des règles empiriques vers des systèmes de protection complexes avec des algorithmes d'apprentissage automatique. Aujourd'hui, les pare-feux d'application disposent d'un large éventail de fonctionnalités qui étaient difficiles à réaliser dans les années 90. En grande partie, l'émergence de nouvelles fonctionnalités a été rendue possible grâce aux technologies cloud. Les solutions WAF et leurs composants continuent d'évoluer, tout comme d'autres domaines de la sécurité de l'information.
Texte préparé par Alexandre Karpuzikov, responsable du développement des produits de sécurité de l'information du fournisseur cloud #CloudMTS.
Source : habr.com
