Peler l’oignon
Avant de revoir le fonctionnement interne de nos règles gérées, examinons les différentes couches (jeu de mots) des protections dans notre WAAP. Chaque couche du WAAP joue un rôle important. Les informations ci-dessous donnent un aperçu de ses fonctions.Règles de contrôle d’accès
Les règles de contrôle d’accès permettent de créer des listes de permis modulaires, des listes de denylists et des listes d’accès à sécurité positive pour contrôler l’accès aux sites protégés par adresse IP, proxy anonyme, pays, ASN, code de région géographique, agent utilisateur, cookie, référent, URL, méthode de requête HTTP, type de contenu, extension de fichier, taille de fichier et en-têtes de requête.Règles de limitation de débit
Les règles de limitation de débit limitent le flux de requêtes HTTP vers une application protégée par le WAAP pour empêcher le trafic DDoS malveillant ou involontaire des applications et empêcher les serveurs d’applications d’un client d’être surchargés de requêtes provenant d’attaques ou de pics de trafic imprévus.Règles du gestionnaire de robots
Bot manager détecte les bons et les mauvais bots. Il fournit plusieurs options pour atténuer l’automatisation indésirable ou les mauvais bots et les empêche d’atteindre vos applications. Cela protège votre site contre les robots malveillants effectuant le bourrage d’informations d’identification, le grattage de votre contenu, le carding, le spamming de vos formulaires, le lancement d’attaques DDoS et la fraude publicitaire.Règles personnalisées
Les règles personnalisées mettent notre puissant moteur WAAP entre vos mains pour créer vos propres règles de sécurité. Le trafic malveillant est identifié à l’aide d’une combinaison de variables (en-têtes de requête, corps, requête, méthode, URL, cookie, etc). Cette méthode offre une flexibilité accrue pour la détection des menaces et vous permet de filtrer des requêtes malveillantes spécifiques et de prendre des mesures pour les atténuer. L’identification personnalisée des menaces associée à des tests et à un déploiement rapides vous permet de résoudre rapidement les vulnérabilités à long terme et zero-day en créant des correctifs virtuels.Règles gérées
Les règles gérées d’Edgio identifient le trafic malveillant via un jeu de règles propriétaire géré par Edgio. Les règles gérées se composent de plus de 500 règles réparties dans trois catégories :- Règles de propriété Edgio.
- Règles avancées spécifiques aux applications.
- Règles OWASP génériques.
Créer de l’ordre hors du chaos
En plus d’avoir un puissant moteur waflz développé en interne spécialement conçu pour évoluer dans un environnement multi-tenant hautes performances, la clé est de créer un ordre d’opérations approprié pour exécuter le WAAP de la manière la plus efficace et la plus efficace. Pour ce faire, notre WAAP exécute ses différentes couches de modules de règles dans l’ordre suivant :- Règles de contrôle d’accès : toutes les demandes sont filtrées par un ensemble statique de listes d’autorisation/refus/accès configurées par le client, composées des variables mentionnées précédemment. Le WAAP supprime toute requête correspondant à la liste de refus, empêchant tout trafic indésirable d’être traité plus avant.
- Règles de limitation de débit : les demandes qui passent par les règles de contrôle d’accès sont ensuite suivies par les règles de limitation de débit, qui suivent la demande pour chaque client dans un intervalle de temps spécifié par la configuration. Le WAAP rejette les demandes dépassant un seuil de taux de demandes particulier, ce qui réduit encore les volumes de demandes de passer à l’étape suivante.
- Règles du gestionnaire de robots : chaque requête atteignant cette étape est inspectée par notre plateforme ML pour déterminer si elle est basée sur un bot en fonction d’une combinaison de signatures et de comportements de requête. Toutes les requêtes de bot malveillantes peuvent être atténuées ici par divers moyens, y compris le défi du navigateur, la réponse personnalisée ou le captcha. La plupart des attaques sont effectuées via des clients automatisés, ce qui fait du gestionnaire de bot une solution efficace pour atténuer ces attaques et réduire davantage le volume de requêtes qui doivent être traitées par les modules de règles suivants.
- Règles personnalisées : à cette étape, le WAAP inspecte la demande à l’aide de divers filtres personnalisés créés par les clients pour détecter et atténuer les demandes indésirables. Cela peut inclure toutes les règles spécifiques aux applications que les clients peuvent déployer en temps réel pour atténuer les vulnérabilités zero-day sans attendre la mise à jour du jeu de règles WAAP géré. Il s’agit d’un outil précieux pour gagner en visibilité et en contrôle sur des attaques spécifiques. En raison de la spécificité des règles personnalisées, elles ont priorité sur les règles gérées par Edgio et traiteront les requêtes avant de les transmettre à la couche finale.
- Règles gérées : toute demande atteignant ce stade est traitée par les règles gérées 500+ dans les catégories OWASP propriétaires, spécifiques aux applications avancées et génériques d’Edgio.
Le traitement de chaque requête en séquence (comme illustré à la figure 1) garantit l’exécution de plusieurs couches de filtrage. Cela nous aide à capturer les attaques recherchées par nos clients (IP/pays denylistés, flood DDoS/HTTP d’application, clients automatisés et signatures de requêtes personnalisées spécifiques) avant que les requêtes n’atteignent les règles gérées.
Cependant, ce n’est qu’une partie de l’histoire de la sécurité.
L’efficacité d’un WAAP n’est pas seulement déterminée par sa capacité à atténuer les attaques (vrais positifs) mais aussi par sa capacité à empêcher le blocage du trafic légitime (faux positifs). Examinons comment nous capturons la plupart des attaques applicatives tout en réduisant les faux positifs.
Un approfondissement des règles gérées Edgio
Lorsqu’une requête atteint les règles gérées, elle est évaluée par notre jeu de règles Edgio propriétaire de plus de 500 règles créées pour atténuer un large éventail d’attaques d’applications. Cela présente une couche supplémentaire de complexité parce qu’il y a tellement de catégories de règles [c’est-à-dire, les injections SQL génériques (SQLi), cross-site scripting (XSS), et l’exécution de code à distance (RCE)] et les règles spécifiques WordPress, Joomla et Apache Struts. Une hiérarchisation minutieuse est nécessaire pour s’assurer qu’ils se complètent et maximisent la précision.
Comme pour les modules de règles mentionnés précédemment, la clé est l’ordre des opérations entre chaque catégorie du jeu de règles géré.
Dans les règles gérées, la demande est traitée par différentes catégories de règles dans cet ordre : règles propriétaires Edgio >règles spécifiques aux applications avancées >règles OWASP génériques.
-
Les règles propriétaires Edgio et les règles spécifiques aux applications recherchent les signatures associées à une vulnérabilité spécifique d’un type spécifique d’application. Ces règles couvrent les applications (Apache Struts, WordPress, Joomla, Drupal, SharePoint, cPanel, etc.) et sont très précises dans la détection des attaques sur ces applications. Nous avons conçu ces règles pour qu’elles s’exécutent en mode signature (alias binaire), ce qui signifie que toute requête déclenchant ces règles provoque une action. Ces règles offrent une approche plus chirurgicale pour faire correspondre et filtrer des vecteurs d’attaque spécifiques à une application ; elles constituent donc la première couche du filtre jeu de règles Edgio. Étant donné que les requêtes ne correspondant pas aux règles propriétaires et spécifiques à l’application peuvent toujours présenter un risque pour l’application du client, nous avons besoin d’une autre approche pour détecter les attaques potentielles dans la phase suivante.
-
Les règles OWASP génériques du jeu de règles Edgio recherchent une combinaison de signatures associées à différentes catégories d’attaques courantes (SQLi, XSS, RCE, violation de protocole, inclusion de fichier local (LFI), inclusion de fichier distant (RFI), etc.). Ces règles fonctionnent ensemble pour déterminer si une requête présente une combinaison de signatures correspondant à une catégorie d’attaque. Ces règles génériques s’exécutent en mode de notation des anomalies qui permet aux clients de définir la sensibilité des règles en ajustant le seuil de notation des anomalies afin de contrôler le nombre de règles à déclencher pour que la demande soit considérée comme malveillante. Plus le seuil de score d’anomalie est bas, plus le jeu de règles générique devient sensible ou strict et plus il est facile pour une requête potentiellement malveillante de dépasser le seuil. Les clients ont la flexibilité d’ajuster la sensibilité de leur WAAP en fonction du type d’application et de leur tolérance au risque. Les règles OWASP génériques servent de fourre-tout final pour les requêtes qui correspondent à une caractéristique d’attaque particulière mais ne correspondent pas nécessairement à des vulnérabilités d’application spécifiques.
Figure 1 : flux de travail Edgio WAAP
Figure 2 : nos règles gérées s’exécutent dans une séquence spécialement conçue pour maximiser la détection et minimiser les faux positifs.
Une autre caractéristique importante qui améliore la précision des règles gérées est la personnalisabilité des règles. Chacune des 500 règles gérées peut être personnalisée pour ignorer des paramètres de requête spécifiques (par exemple, les paramètres d’en-tête de requête, de cookie, de requête et de corps). Cela permet aux clients de supprimer rapidement les faux positifs à l’aide d’une interface utilisateur simple ou d’une API.
Rassembler toutes les pièces
Vous avez maintenant effectué le parcours d’une requête HTTP via notre WAAP. Quelque chose qui se produit des milliards de fois par jour sur chaque serveur Edgio dans les 300 points de présence (POP) dans le monde entier, car notre WAAP hautes performances fonctionne nativement sur la même pile qui exécute nos services de diffusion de contenu. Au début de ce blog, j’ai mentionné que je reçois beaucoup de questions sur notre WAAP. J’espère que vous comprenez maintenant ce qui le distingue des autres solutions. Nous combinons un ordre intelligent des opérations avec les différents modules de règles WAAP (de l’ACL à la limitation de débit en passant par les règles bot et personnalisées), les règles gérées (des règles spécifiques aux règles génériques), et le mode hybride signature et notation des anomalies pour une sécurité qui n’entrave pas les performances.
Considérez cette analogie : concevoir et assembler des composants WAAP est comme faire un hamburger. Il ne s’agit pas seulement d’avoir les bons ingrédients ; il s’agit de les combiner de la bonne façon pour faire un bon repas. Les mêmes ingrédients mis ensemble différemment peuvent avoir un impact considérable sur le goût et l’expérience du client.
