L'évolution du pare-feu d'applications Web: des pare-feu aux systèmes de sécurité basés sur le cloud d'apprentissage automatique

Dans notre précédent matériel basé sur le cloud, nous avons expliqué comment protéger les ressources informatiques dans un cloud public et pourquoi les antivirus traditionnels ne conviennent pas tout à fait à 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 vaut mieux choisir: matériel, logiciel ou cloud.



Qu'est-ce que le WAF?


Plus de 75% des attaques de pirates visent les vulnérabilités des applications 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 les risques de compromission et de fraude des comptes d'utilisateurs et des données personnelles, mots de passe, numéros de carte de crédit. De plus, les vulnérabilités du site Web servent de point d'entrée pour les cybercriminels dans le réseau d'entreprise.

Le pare-feu d'application Web (WAF) est un pare-feu qui bloque les attaques sur les applications Web: injection SQL, scriptage croisé, exécution de code à distance, force brute et contournement d'authentification. Y compris les attaques utilisant des vulnérabilités zero-day. Les pare-feu d'application offrent une protection en surveillant le contenu des pages Web, y compris HTML, DHTML et CSS, et en filtrant les demandes potentiellement malveillantes via HTTP / HTTPS.

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


Les premières tentatives de création d'un pare-feu d'application Web ont été faites au début des années 90. Au moins trois ingénieurs qui travaillent dans ce domaine sont connus. Le premier est Gene Spafford, professeur d'informatique à l'Université Purdue. Il a décrit l'architecture du pare-feu d'application avec un proxy et l'a publiée en 1991 dans le livre «UNIX Security in Practice» .

Les deuxième et troisième - étaient des spécialistes de la sécurité de l'information William Cheswick et Marcus Ranum de Bell Labs. Ils ont développé l'un des premiers prototypes de pare-feu d'application. DEC a été engagé dans sa distribution - le produit est sorti sous le nom SEAL (Secure External Access Link).

Mais SEAL n'était pas une solution WAF complète. Il s'agissait d'un pare-feu réseau classique avec des fonctionnalités avancées - la possibilité de bloquer les attaques sur FTP et RSH. Pour cette raison, la première solution WAF aujourd'hui est considérée comme le produit de Perfecto Technologies (plus tard Sanctum). En 1999, elle a introduit le système AppShield. À cette époque, Perfecto Technologies développait des solutions de sécurité de l'information pour le commerce électronique et les magasins en ligne sont devenus le public cible de leur nouveau produit. AppShield a pu analyser les requêtes HTTP et les attaques bloquées en fonction de politiques de sécurité des informations dynamiques.

À peu près au même moment qu'AppShield (en 2002), le premier WAF open source est apparu. Ils sont devenus ModSecurity . Il a été créé afin de vulgariser les technologies WAF et est toujours pris en charge par la communauté informatique (voici son référentiel sur GitHub ). ModSecurity bloque les attaques contre les applications basées sur un ensemble standard d'expressions régulières (signatures) - outils pour comparer les requêtes par rapport à un modèle - OWASP Core Rule Set .

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 l'histoire


Il est d'usage de distinguer trois générations de systèmes WAF qui ont évolué à mesure que la technologie se développe.

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

Un exemple de découverte d'expression régulière est le projet open source Core Rule Set déjà mentionné. Un autre exemple est Naxsi , qui est également open source. Les systèmes avec des expressions régulières présentent plusieurs inconvénients, en particulier 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 oublier que les vérifier peut réduire les performances du réseau.

Les expressions régulières ont également un niveau assez élevé de faux positifs. Le célèbre linguiste Noam Chomsky a proposé une classification des grammaires, dans laquelle il les a divisées en quatre niveaux de difficulté conditionnelle. Selon cette classification, les expressions régulières ne peuvent décrire que des règles de pare-feu qui n'impliquent pas d'écarts par rapport au modèle. Cela signifie que les attaquants peuvent facilement «tromper» le WAF de première génération. L'une des méthodes pour lutter contre ce problème consiste à ajouter des caractères spéciaux aux demandes d'application qui n'affectent pas la logique des données malveillantes, mais violent la règle de signature.



Deuxième génération . Pour contourner les problèmes de performances et de précision avec WAF, des pare-feu d'application de deuxième génération ont été développés. Des analyseurs y sont apparus qui sont chargés d'identifier les types d'attaques strictement définis (HTML, JS, etc.). Ces analyseurs fonctionnent avec des jetons spéciaux qui décrivent les demandes (par exemple, variable, chaîne, inconnue, nombre). Les séquences de jetons potentiellement malveillantes sont placées dans une liste distincte avec laquelle le système WAF est régulièrement vérifié. Cette approche a été présentée pour la première fois lors de la conférence Black Hat 2012 sous la forme de la bibliothèque de libinjection C / C ++, qui permet de détecter les injections SQL.

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



Troisième génération . L'évolution de la logique de détection de troisième génération consiste en l'application de méthodes de machine learning, qui permettent de rapprocher le plus possible la grammaire de détection de la vraie 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 les grammaires énumérées récursivement. De plus, auparavant, la tâche de créer une machine de Turing adaptable était insoluble jusqu'à la publication des premières études sur les machines de Turing neurales.

L'apprentissage automatique offre une occasion unique d'adapter n'importe quelle grammaire pour couvrir tout type d'attaque sans créer manuellement de listes de signatures, comme requis lors de la détection de la première génération, et sans développer de nouveaux tokeniseurs / analyseurs pour de nouveaux types d'attaques, tels que les déploiements de Memcached, Redis, Cassandra, 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 un contour rouge (Fig. 3). Cette génération comprend l'une des solutions que nous mettons en œuvre dans le cloud avec Onsek, le développeur de la plate-forme de protection adaptative pour les applications Web et l'API Valarm.

Maintenant, la logique de détection utilise les commentaires de l'application d'autoréglage. 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 renforts:

  • Analyse du comportement de réponse des applications (passive)
  • Scan / Fuzzer (actif)
  • Fichiers de rapport / procédures d'intercepteur / d'interruption (post factum)
  • Manuel (déterminé par le superviseur)

Par conséquent, la logique de détection de troisième génération résout également l'important problème de précision. Désormais, il est possible non seulement d'éviter les faux positifs et les faux négatifs, mais également de détecter des résultats véritablement négatifs valides, tels que la détection de l'utilisation de l'élément de commande SQL dans le panneau de configuration, le chargement de modèles de page Web, les requêtes AJAX liées aux erreurs JavaScript, etc.







Ensuite, nous considérons les capacités technologiques de diverses options de mise en œuvre de WAF.

Fer, logiciel ou cloud - que choisir?


L'une des options de mise en œuvre des pare-feu d'application est une solution matérielle. Ces systèmes sont des dispositifs informatiques spécialisés que l'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 sa configuration et son débogage (si l'entreprise n'a pas son propre service informatique). Dans le même temps, tout équipement devient obsolète et se détériore, de sorte que les clients sont obligés de prévoir un budget pour la mise à jour du matériel.

Une autre option de déploiement WAF est une implémentation logicielle. La solution est installée en tant que module complémentaire pour n'importe quel logiciel (par exemple, ModSecurity est configuré au-dessus d'Apache) et s'exécute sur le même serveur que celui-ci. En règle générale, ces solutions peuvent être déployées à la fois sur un serveur physique et dans le cloud. Leur inconvénient est l'évolutivité et la prise en charge limitées du fournisseur.

La troisième option consiste à configurer WAF à partir du cloud. Ces solutions sont fournies par les fournisseurs de cloud en tant que 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 que le WAF basé sur le cloud moderne n'implique pas la migration des ressources vers la plate-forme du fournisseur. Un site peut être déployé n'importe où, même sur site.

Pourquoi regarder de plus en plus souvent vers un WAF nuageux, nous le dirons plus loin.

Que peut WAF dans le cloud


En termes de capacités technologiques:

  • Le fournisseur est responsable des mises à jour . Le WAF est fourni par abonnement, de sorte que le fournisseur de services surveille la pertinence des mises à jour et des licences. Les mises à jour concernent non seulement le logiciel, mais aussi le matériel. Le fournisseur met à niveau le parc de serveurs et est engagé dans sa maintenance. 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 distribution rationnelle du trafic vous permet d'éviter les situations où le pare-feu passe en mode d'ouverture défaillante - ne gère pas la charge et arrête les demandes de filtrage.
  • Patch virtuel . Les correctifs virtuels restreignent l'accès aux parties compromises de l'application jusqu'à ce que la vulnérabilité soit corrigée par le développeur. En conséquence, le client du fournisseur de cloud a la possibilité d'attendre calmement que le fournisseur de l'un ou l'autre logiciel publie des «correctifs» officiels. Faire cela le plus rapidement possible est une priorité pour le fournisseur de logiciels. Par exemple, dans la plate-forme Valarm, un module logiciel distinct est responsable du patch virtuel. Un administrateur peut ajouter des expressions régulières personnalisées pour bloquer les demandes malveillantes. Le système permet de signaler certaines requêtes avec le drapeau Données confidentielles. Leurs paramètres sont ensuite masqués et eux-mêmes ne sont en aucun cas transférés hors de la zone de travail du pare-feu.
  • Périmètre intégré et scanner de vulnérabilité . 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. Après que WAF analyse automatiquement les services exécutés à l'intérieur du périmètre (effectue une analyse de port). Le pare-feu est capable de détecter tous les types de vulnérabilités courants - SQLi, XSS, XXE, etc. - et de détecter les erreurs dans la configuration logicielle, par exemple, l'accès non autorisé aux référentiels Git et BitBucket et les appels anonymes à Elasticsearch, Redis, MongoDB.
  • Les attaques sont surveillées par des 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é. Dans le cloud, un cluster de nœuds de filtrage est déployé à travers lequel passe tout le trafic. Ces sites bloquent les attaques contre les applications Web et envoient des statistiques au centre d'analyse. 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 à la Fig. 4. De telles règles de sécurité adaptées minimisent le nombre de faux positifs pour le pare-feu.



Maintenant, un peu sur les caractéristiques du cloud WAF en termes de problèmes d'organisation et de gestion:

  • Transition vers OpEx . Dans le cas du WAF basé sur le 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 se fait par abonnement.
  • Différents plans tarifaires . Un utilisateur d'un service cloud peut rapidement activer ou désactiver des options supplémentaires. La gestion des fonctions est implémentée à partir d'un seul panneau de contrôle, qui est également protégé. Son accès se fait via HTTPS, en plus d'un mécanisme d'authentification à deux facteurs basé sur le protocole TOTP (Time-based One-Time Password Algorithm).
  • Connexion DNS . Vous pouvez modifier le DNS vous-même et configurer le routage sur le 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 aider à la configuration.

Les technologies WAF sont passées de simples pare-feu avec des règles empiriques à des systèmes de sécurité complexes avec des algorithmes d'apprentissage automatique. Désormais, les pare-feu applicatifs ont un large éventail de fonctions qui étaient difficiles à mettre en œuvre dans les années 90. À bien des égards, l'émergence de nouvelles fonctionnalités a été rendue possible grâce à la technologie cloud. Les solutions WAF et leurs composants continuent d'évoluer. Ainsi que d'autres domaines de la sécurité de l'information.

Le texte a été préparé par Alexander Karpuzikov, Product Development Manager du fournisseur de cloud IS #CloudMTS.

Source: https://habr.com/ru/post/fr485220/


All Articles