L'évolution du Web Application Firewall : des pare-feu aux systèmes de protection basés sur le cloud avec apprentissage automatique

Dans notre matériel précédent sur les sujets liés au cloud, nous dit, comment protéger les ressources informatiques dans le cloud public et pourquoi les antivirus traditionnels ne sont pas entièrement adaptés à ces fins. Dans cet article, nous continuerons le sujet de la sécurité du cloud et parlerons de l'évolution du WAF et de ce qu'il est préférable de choisir : matériel, logiciel ou cloud. 

L'évolution du Web Application Firewall : des pare-feu aux systèmes de protection basés sur le cloud avec apprentissage automatique

Qu'est-ce que WAF

Plus de 75 % des attaques de pirates informatiques visent les vulnérabilités des applications Web et des sites Web : ces attaques sont généralement invisibles pour l'infrastructure de sécurité de l'information et les services de sécurité de l'information. Les vulnérabilités des applications Web comportent, à leur tour, des risques de compromission et de fraude des comptes d'utilisateurs et des données personnelles, des mots de passe et des numéros de carte de crédit. De plus, les vulnérabilités du site Web servent de point d’entrée aux attaquants dans le réseau de l’entreprise.

Web Application Firewall (WAF) est un écran de protection qui bloque les attaques sur les applications Web : injection SQL, cross-site scripting, exécution de code à distance, force brute et contournement d'autorisation. Y compris les attaques qui exploitent les vulnérabilités du jour zéro. Les pare-feu d'applications assurent la protection en surveillant le contenu des pages Web, notamment HTML, DHTML et CSS, et en filtrant les requêtes HTTP/HTTPS potentiellement malveillantes.

Quelles ont été les premières décisions ?

Les premières tentatives de création d’un pare-feu d’applications Web 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 d'application proxy et l'a publié en 1991 dans le livre "La sécurité UNIX en pratique".

Les deuxième et troisième étaient les spécialistes de la sécurité de l'information, William Cheswick et Marcus Ranum des Bell Labs. Ils ont développé l’un des premiers prototypes de pare-feu applicatif. Il a été distribué par DEC - le produit a été publié sous le nom de SEAL (Secure External Access Link).

Mais SEAL n’était pas une solution WAF à part entière. Il s'agissait d'un pare-feu réseau classique doté de fonctionnalités avancées : la possibilité de bloquer les attaques sur FTP et RSH. Pour cette raison, la première solution WAF actuelle est considérée comme un produit de Perfecto Technologies (plus tard Sanctum). En 1999, elle présenté Système AppShield. À cette époque, Perfecto Technologies développait des solutions de sécurité de l'information pour le commerce électronique, et les boutiques en ligne devenaient le public cible de leur nouveau produit. AppShield a pu analyser les requêtes HTTP et bloquer les attaques sur la base de politiques dynamiques de sécurité des informations.

À peu près au même moment qu’AppShield (en 2002), le premier WAF open source est apparu. Il est devenu ModSecurity. Il a été créé dans le but de vulgariser les technologies WAF et est toujours soutenu par la communauté informatique (le voici dépôt sur GitHub). ModSecurity bloque les attaques contre les applications sur la base d'un ensemble standard d'expressions régulières (signatures) - outils de vérification des requêtes basées sur des modèles - Ensemble de règles de base OWASP.

En conséquence, les développeurs ont réussi à atteindre leur objectif : de nouvelles solutions WAF ont commencé à apparaître sur le marché, y compris celles construites sur la base de ModSecurity.

Trois générations, c'est déjà de l'histoire

Il est d'usage de distinguer trois générations de systèmes WAF, qui ont évolué avec l'évolution de la technologie.

Première génération. Fonctionne avec des expressions régulières (ou grammaires). Cela inclut ModSecurity. Le fournisseur de système étudie les types d'attaques sur les applications et génère des modèles qui décrivent les requêtes légitimes et potentiellement malveillantes. WAF vérifie ces listes et décide quoi faire dans une situation particulière : bloquer ou non le trafic.

Un exemple de détection basée sur des expressions régulières est le projet déjà mentionné Ensemble de règles de base Open source. Un autre exemple - Naxsi, qui est également open source. Les systèmes avec expressions régulières présentent un certain nombre d'inconvénients, notamment lorsqu'une nouvelle vulnérabilité est découverte, l'administrateur doit créer manuellement des règles supplémentaires. Dans le cas d’une infrastructure informatique à grande échelle, il peut y avoir plusieurs milliers de règles. Gérer autant 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 ont également un taux de faux positifs assez élevé. Le célèbre linguiste Noam Chomsky a proposé une classification des grammaires dans laquelle il les a divisées en quatre niveaux conditionnels de complexité. Selon cette classification, les expressions régulières ne peuvent décrire que des règles de pare-feu qui n'impliquent pas de déviations par rapport au modèle. Cela signifie que les attaquants peuvent facilement « tromper » le WAF de première génération. Une méthode pour lutter contre ce problème consiste à ajouter des caractères spéciaux aux requêtes des applications qui n'affectent pas la logique des données malveillantes, mais violent la règle de signature.

L'évolution du Web Application Firewall : des pare-feu aux systèmes de protection basés sur le cloud avec apprentissage automatique

La deuxième génération. Pour contourner les problèmes de performances et de précision des WAF, des pare-feu applicatifs de deuxième génération ont été développés. Ils disposent désormais d’analyseurs chargés d’identifier des types d’attaques strictement définis (sur HTML, JS, etc.). Ces analyseurs fonctionnent avec des jetons spéciaux qui décrivent les requêtes (par exemple, variable, chaîne, inconnu, nombre). Les séquences de jetons potentiellement malveillantes sont placées dans une liste distincte, 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 la forme de C/C++. bibliothèques libinjection, qui permet de détecter les injections SQL.

Par rapport aux WAF de première génération, les analyseurs spécialisés peuvent être plus rapides. Cependant, ils n'ont pas résolu les difficultés liées à la configuration manuelle du système lorsque de nouvelles attaques malveillantes apparaissent.

L'évolution du Web Application Firewall : des pare-feu aux systèmes de protection basés sur le cloud avec apprentissage automatique

Troisième génération. L'évolution de la logique de détection de troisième génération consiste en l'utilisation de méthodes d'apprentissage automatique qui permettent de rapprocher au maximum la grammaire de détection de la réelle grammaire SQL/HTML/JS des systèmes protégés. Cette logique de détection est capable d'adapter une machine de Turing pour couvrir des grammaires récursivement énumérables. De plus, la tâche de créer une machine de Turing adaptable était auparavant insoluble jusqu'à la publication des premières études sur les machines neuronales de Turing.

L'apprentissage automatique offre la capacité unique d'adapter n'importe quelle grammaire pour couvrir tout type d'attaque sans créer manuellement de listes de signatures comme requis dans la détection de première génération, et sans développer de nouveaux tokeniseurs/analyseurs pour de nouveaux types d'attaques tels que Memcached, Redis, Cassandra, les injections SSRF. , comme l'exige 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 dans lequel la troisième génération de détection est représentée par le contour rouge (Figure 3). Cette génération comprend l'une des solutions que nous implémentons dans le cloud en collaboration avec Onsek, le développeur de la plateforme de protection adaptative des applications web et de l'API Wallarm.

La logique de détection utilise désormais les retours de l'application pour s'auto-ajuster. En apprentissage automatique, cette boucle de rétroaction est appelée « renforcement ». En règle générale, il existe un ou plusieurs types de tels renforcements :

  • Analyse du comportement de réponse des applications (passif)
  • Scan/fuzzer (actif)
  • Signaler les fichiers/procédures d'interception/pièges (après coup)
  • Manuel (défini par le superviseur)

En conséquence, la logique de détection de troisième génération résout également le problème important de la précision. Il est désormais possible non seulement d'éviter les faux positifs et les faux négatifs, mais également de détecter les vrais négatifs valides, tels que la détection de l'utilisation d'éléments de commande SQL dans le Panneau de configuration, le chargement de modèles de pages Web, les requêtes AJAX liées aux erreurs JavaScript, etc.

L'évolution du Web Application Firewall : des pare-feu aux systèmes de protection basés sur le cloud avec apprentissage automatique

L'évolution du Web Application Firewall : des pare-feu aux systèmes de protection basés sur le cloud avec apprentissage automatique

L'évolution du Web Application Firewall : des pare-feu aux systèmes de protection basés sur le cloud avec apprentissage automatique

Nous examinerons ensuite les capacités technologiques des différentes options de mise en œuvre du WAF.

Matériel, logiciel ou cloud : que choisir ?

L'une des options pour implémenter des pare-feu d'application est une solution matérielle. De tels systèmes sont des appareils informatiques spécialisés qu'une entreprise installe localement dans son centre de données. Mais dans ce cas, vous devez acheter votre propre équipement et payer de l'argent aux intégrateurs pour le configurer et le déboguer (si l'entreprise ne dispose pas de son propre service informatique). Dans le même temps, tout équipement devient obsolète et devient inutilisable, ce qui oblige les clients à prévoir un budget pour les mises à niveau matérielles.

Une autre option pour déployer un WAF est une implémentation logicielle. La solution est installée en tant que module complémentaire pour certains logiciels (par exemple, ModSecurity est configuré sur Apache) et s'exécute sur le même serveur que celui-ci. En règle générale, de telles solutions peuvent être déployées aussi bien sur un serveur physique que dans le cloud. Leur inconvénient est une évolutivité et un support fournisseur limités.

La troisième option consiste à configurer un WAF depuis le cloud. Ces solutions sont fournies par les fournisseurs de cloud sous forme de service d'abonnement. L'entreprise n'a pas besoin d'acheter et de configurer du matériel spécialisé ; ces tâches incombent au prestataire de services. Un point important est qu’un WAF cloud moderne n’implique pas la migration des ressources vers la plateforme du fournisseur. Le site peut être déployé n'importe où, même sur site.

Nous expliquerons plus en détail pourquoi les gens se tournent désormais de plus en plus vers le cloud WAF.

Ce que WAF peut faire dans le cloud

En termes de capacités technologiques :

  • Le fournisseur est responsable des mises à jour. WAF est fourni par abonnement, le fournisseur de services surveille donc la pertinence des mises à jour et des licences. Les mises à jour concernent non seulement les logiciels, mais également le matériel. Le fournisseur met à niveau le parc de serveurs et le maintient. Il est également responsable de l'équilibrage de charge et de la redondance. Si le serveur WAF tombe en panne, le trafic est immédiatement redirigé vers une autre machine. La répartition rationnelle du trafic vous permet d'éviter les situations dans lesquelles le pare-feu entre en mode échec d'ouverture - il ne peut pas faire face à la charge et arrête de filtrer les requêtes.
  • Correctifs virtuels. Les correctifs virtuels restreignent l'accès aux parties compromises de l'application jusqu'à ce que le développeur corrige la vulnérabilité. De ce fait, le client du fournisseur de cloud a la possibilité d'attendre sereinement que le fournisseur de tel ou tel logiciel publie des « patchs » officiels. Faire cela le plus rapidement possible est une priorité pour le fournisseur de logiciels. Par exemple, sur la plateforme Wallarm, un module logiciel distinct est responsable des correctifs virtuels. L'administrateur peut ajouter des expressions régulières personnalisées pour bloquer les requêtes malveillantes. Le système permet de marquer certaines demandes avec le drapeau « Données confidentielles ». Leurs paramètres sont ensuite masqués, et en aucun cas ils ne sont transmis en dehors de la zone de travail du pare-feu.
  • Scanner de périmètre et de vulnérabilité intégré. Cela vous permet de déterminer indépendamment les limites du réseau de l'infrastructure informatique à l'aide des données des requêtes DNS et du protocole WHOIS. Ensuite, WAF analyse automatiquement les services exécutés à l'intérieur du périmètre (effectue une analyse des ports). Le pare-feu est capable de détecter tous les types courants de vulnérabilités - SQLi, XSS, XXE, etc. - et d'identifier les erreurs de configuration logicielle, par exemple les accès non autorisés aux référentiels Git et BitBucket et les appels anonymes à Elasticsearch, Redis, MongoDB.
  • Les attaques sont surveillées par les ressources cloud. En règle générale, les fournisseurs de cloud disposent d’une grande puissance de calcul. Cela vous permet d’analyser les menaces avec une grande précision et rapidité. Un cluster de nœuds de filtrage est déployé dans le cloud, à travers lequel passe tout le trafic. Ces nœuds bloquent les attaques sur les applications Web et envoient des statistiques à Analytics Center. Il 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 illustrée sur la Fig. 4. Ces règles de sécurité personnalisées minimisent le nombre de fausses alarmes de pare-feu.

L'évolution du Web Application Firewall : des pare-feu aux systèmes de protection basés sur le cloud avec apprentissage automatique

Parlons maintenant un peu des fonctionnalités des WAF cloud en termes de problèmes d'organisation et de gestion :

  • Transition vers OpEx. Dans le cas des WAF cloud, le coût de mise en œuvre sera nul, puisque tout le matériel et les licences ont déjà été payés par le fournisseur ; le paiement du service s'effectue par abonnement.
  • Différents plans tarifaires. L'utilisateur du service cloud peut rapidement activer ou désactiver des options supplémentaires. Les fonctions sont gérées depuis un seul panneau de contrôle, également sécurisé. On y accède via HTTPS, et il existe un mécanisme d'authentification à deux facteurs basé sur le protocole TOTP (Time-based One-Time Password Algorithm).
  • Connexion via DNS. Vous pouvez modifier vous-même le DNS et configurer le routage réseau. Pour résoudre ces problèmes, il n’est pas nécessaire de recruter et de former des spécialistes individuels. En règle générale, le support technique du fournisseur peut vous aider à la configuration.

Les technologies WAF ont évolué de simples pare-feu dotés de règles empiriques à des systèmes de protection complexes dotés d'algorithmes d'apprentissage automatique. Les pare-feux applicatifs offrent désormais un large éventail de fonctionnalités difficiles à mettre en œuvre dans les années 90. À bien des égards, l’émergence de nouvelles fonctionnalités est devenue 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.

Le texte a été préparé par Alexander Karpuzikov, responsable du développement de produits de sécurité de l'information chez le fournisseur de cloud #CloudMTS.

Source: habr.com

Ajouter un commentaire