Qu’est-ce que la Protection DDoS de couche d'application ?

La protection DDoS de couche d'application est un ensemble de mesures de sécurité conçues pour détecter et atténuer les attaques par déni de service distribué (DDoS) ciblant les sites web, les API et d’autres services d’application à la couche 7 du modèle OSI.

Contrairement aux attaques qui visent principalement à saturer la bande passante du réseau, les attaques DDoS de couche d'application ciblent les fonctions dont une application a besoin pour servir les utilisateurs légitimes. Les hacker peuvent inonder les pages de connexion, les fonctions de recherche, les API, les processus de paiement, ou d’autres points de terminaison gourmands en ressources, avec des requêtes pouvant ressembler à un trafic normal.

Une protection efficace exige donc plus que la simple absorption de grandes quantités de bande passante. Les organisations doivent distinguer les utilisateurs légitimes du trafic malveillant, détecter les comportements anormaux, contrôler les requêtes abusives, et empêcher les attaques d’épuiser les ressources de l’application et de l’origine.

Comment fonctionne une attaque DDoS de couche d’application ?

Une attaque DDoS de couche d’application est une attaque distribuée qui tente de rendre une application indisponible en submergeant ses ressources au niveau de l’application. Au lieu d’envoyer uniquement des quantités massives de trafic réseau brut, les hackers peuvent générer des requêtes qui obligent l’application cible à effectuer un travail significatif. Par exemple, effectuer de manière répétée des requêtes de pages web, interroger des API, initier des recherches, tenter des connexions, ou déclencher des opérations coûteuses en calcul.

Une requête relativement petite peut parfois entraîner considérablement plus de travail en aval. Cela peut déclencher une logique d’application, des requêtes de base de données, des appels d’API, ou d’autres processus back-end. Cette asymétrie peut rendre les attaques de couche d'application particulièrement perturbatrices.

Les hackers génèrent généralement des requêtes à partir de nombreux clients distribués, qui peuvent inclure des dispositifs compromis formant un botnet. Le trafic est dirigé vers les points de terminaison de l’application dans le but de consommer des ressources finies comme :

• Capacité du serveur d’application

• Connexions à la base de données

• CPU et mémoire

• Capacité de l’API

• Pools de connexions

• Bande passante du back-end

• Services tiers

• infrastructure d’origine

Un exemple simple est une inondation HTTP ; un hacker envoie de grandes quantités de requêtes HTTP à un site web ou à une API jusqu’à ce que les requêtes légitimes ne puissent plus être traitées efficacement. Des attaques plus sophistiquées peuvent cibler délibérément des points de terminaison coûteux. Par exemple, un hacker pourrait déclencher de manière répétée une opération de recherche qui nécessite plusieurs requêtes de base de données, plutôt que de demander un fichier statique léger.

En quoi les attaques par déni de service distribué (DDoS) de couche d'application sont-elles différentes des attaques de couche réseau ?

La principale différence réside dans ce que le hacker tente d’épuiser. Les attaques de la couche réseau et de la couche transport ciblent généralement l’infrastructure, comme la bande passante, les protocoles, ou la capacité de connexion. Les attaques de la couche d'application ciblent l’application elle-même et les ressources nécessaires au traitement de requêtes d’apparence légitime.

Les organisations peuvent rencontrer les deux types simultanément, donc une stratégie complète de déni de service distribué devrait prendre en compte les attaque sur plusieurs couche.

Pourquoi la Protection DDoS de couche d'application est-elle nécessaire ?

Les attaques de la couche d’application présentent un défi particulier, car les requêtes malveillantes peuvent sembler légitimes. Une requête pour « /search », « /login » ou « /api/products », par exemple, n’est pas intrinsèquement malveillante. Déterminer si des milliers de telles requêtes représentent une activité réelle des clients ou une attaque coordonnée nécessite du contexte.

Voici pourquoi une solution et une stratégie dédiées de Protection DDoS de couche d’application sont si importantes : 

Les attaques d’application peuvent contourner les défenses réseau Basic

Un pare-feu réseau traditionnel peut voir des connexions HTTPS valides plutôt qu’un trafic réseau manifestement malformé. Des contrôles conscients des applications sont nécessaires pour comprendre ce que font ces connexions.

Les petites requêtes peuvent consommer des ressources back-end importantes

Les hackers peuvent délibérément cibler des points de terminaison dont le traitement est coûteux. Une requête peut déclencher des recherches dans la base de données, des opérations d’authentification, des appels d’API, ou une logique d’application gourmande en calcul.

Les botnets distribuent le trafic d’attaque

Botnets peuvent répartir les requêtes sur un grand nombre d’adresses IP et de dispositifs. Cela peut rendre le blocage simple des IP et les seuils par IP moins efficaces.

Les attaques peuvent affecter les revenus et l’expérience client

Si les clients ne peuvent pas accéder à une page de paiement, à une API, à un service de streaming, à une application Logiciel en tant que service ou à un autre service critique, les problèmes de disponibilité peuvent rapidement devenir des problèmes métier.

Le trafic d’attaque peut augmenter les coûts d’infrastructure

Même lorsqu’une attaque ne provoque pas de panne, le traitement des requêtes malveillantes peut consommer des ressources de calcul cloud, des ressources de base de données, de la bande passante, et de la capacité d’API tierces. La protection de couche d’application vise à arrêter ou à contrôler ces requêtes avant qu’elles ne consomment des ressources back-end coûteuses.

Quels sont les types courants d’attaques DDoS de couche d'application ?

Inondations HTTP

Les attaques par saturation HTTP génèrent de grandes quantités de requêtes HTTP GET, POST, ou autres, contre un site web ou une application. Les versions plus sophistiquées peuvent faire varier les URL, les en-têtes, les cookies, les modèles de requête, et les caractéristiques du client afin de rendre le trafic plus difficile à distinguer d’une activité légitime.

Inondations API

Les hackers peuvent cibler directement les points de terminaison d’API avec de grandes quantités de requêtes. Cela peut être particulièrement dommageable lorsque des opérations d’API déclenchent des requêtes de base de données, des calculs, ou des appels à des services en aval.

Inondations de connexion et d’authentification

Les points de terminaison d’authentification peuvent être coûteux, car ils peuvent impliquer des opérations de base de données, le hachage des mots de passe, des appels au fournisseur d’identité, des vérifications de fraude, ou d’autres traitements. Les hackers peuvent invoquer ces fonctions de manière répétée pour consommer des ressources.

Attaques par épuisement des ressources

Plutôt que de simplement maximiser le volume de requêtes, les hackers peuvent identifier des fonctions d’application qui nécessitent un traitement disproportionné. La recherche, la génération de rapports, l’exportation de données, le filtrage complexe, le traitement de fichiers, ou d’autres opérations coûteuses peuvent devenir des cibles.

Attaques low-and-slow

Toutes les attaques par déni de service distribué de couche d’application ne dépendent pas de taux de requête extrêmement élevés. Certaines attaques consomment délibérément les ressources de l’application ou du serveur lentement, ce qui peut les rendre plus difficiles à identifier à l’aide de simples seuils de volume de trafic.

Quelles sont les bonnes pratiques en matière de Protection DDoS de couche d'application ?

Une protection efficace est multicouche. Les organisations doivent combiner l’architecture d’application, les contrôles du trafic, la surveillance, et des technologies de sécurité spécialisées.

1. Établir des références de trafic normal

Comprendre les volumes et les comportements normaux des requêtes permet d’identifier plus facilement les activités inhabituelles. Surveillez le trafic par point de terminaison, zone géographique, statut de réponse, agent utilisateur, caractéristiques du client, et autres dimensions pertinentes.

2. Protéger l’origine

Les hackers ne devraient pas pouvoir contourner les contrôles de sécurité en périphérie, et attaquer directement l’origine. Restreignez l’accès à l’origine lorsque cela est possible afin que le trafic légitime de l’application atteigne l’infrastructure back-end via les couches de distribution et de sécurité approuvées.

3. Mettre en cache le contenu approprié

La mise en cache peut réduire la quantité de travail effectuée par les origines de l’application. Si un Content Delivery Network peut traiter une requête depuis le cache, la requête n’a pas besoin de déclencher le même traitement back-end. L’augmentation de l’efficacité du cache peut donc améliorer à la fois les performances et la résilience.

4. Utilisez une limitation du débit intelligente

Les rate limits (limitation du débit) peuvent empêcher des clients individuels ou des groupes de clients d’effectuer un nombre excessif de requêtes. Évitez d’appliquer un seuil universel unique à chaque endpoint. Une page d’accueil, une API de connexion, un endpoint de recherche, et le téléchargement d’un fichier volumineux peuvent présenter des schémas de trafic normal très différents.

5. Protégez les points de terminaison coûteux

Identifiez quelles requête consomment le plus de ressources back-end. La recherche, l’authentification, la génération de rapports, les requête API, et d’autres Opérations coûteuses peuvent nécessiter des contrôle plus stricts que les ressources en cache peu coûteuses.

6. Utilisez Bot Management

Les botnets sont fréquemment responsables d’attaques d’applications distribuées. Les systèmes de gestion des bots peuvent utiliser des signaux comportementaux et client pour distinguer le trafic automatisé des utilisateurs légitimes et appliquer les réponses appropriées.

7. Déployer un pare-feu d’application web

Un WAF peut identifier et bloquer les requêtes d’application malveillantes, en complément de la protection DDoS. Cela est particulièrement utile lorsque les attaques combinent l’inondation de requêtes avec des tentatives d’exploiter des vulnérabilités applicatives.

8. Créer la résilience des application

L’architecture de l’application reste importante. Les délais d’expiration, les disjoncteurs, la mise en file d’attente, les limites de ressources, la mise en cache, les protections de base de données et la dégradation progressive peuvent réduire l’impact lorsque du trafic inhabituel atteint les systèmes back-end.

9. Surveiller en temps réel

Les attaques visant la couche d’application peuvent évoluer rapidement. La sécurité en temps réel et la visibilité sur le trafic aident les équipes à identifier les points de terminaison ciblés, à comprendre le comportement de l’atténuation, et à ajuster les protections pendant un incident.

Quels types de Protection DDoS de couche d'application sont disponibles ?

Aucun contrôle unique ne permet de contrer toutes les attaques de couche 7. Les technologies de protection courantes incluent :

Content Delivery Network et mise en cache en périphérie

Les Content Delivery Network peuvent traiter les requêtes dont la mise en cache est possible sans solliciter l’origine, réduisant ainsi les ressources que les hackers peuvent épuiser. Les réseaux de périphérie peuvent également fournir un emplacement pour identifier et atténuer le trafic malveillant avant qu’il n’atteigne l’infrastructure des applications.

Pare-feu d’application web

Un WAF examine les requêtes HTTP et applique des règles de sécurité basées sur des informations de la couche d'application. Les WAF sont principalement associés à la protection des applications contre les vulnérabilités et les charges utiles malveillantes, mais ils peuvent également contribuer à une défense DDoS multicouche.

Limitation du débit

La limitation du débit contrôle la fréquence à laquelle des requête peuvent être effectuées. Des règles peuvent être appliquées à des URL, des API, des clients ou d’autres caractéristiques de requête particulières afin de protéger des fonctions sensibles ou gourmandes en ressources.

Bot Management

Bot Management tente de distinguer les humains légitimes et l’automatisation approuvée des bots malveillants. Étant donné que de nombreuses attaques DDoS au niveau de la couche d'application proviennent de botnets, la Détection de bot peut être particulièrement utile lorsque les requêtes d’attaque semblent par ailleurs valides.

Détection comportementale et d’anomalies

La protection comportementale recherche les écarts par rapport au trafic attendu de l’application plutôt que de s’appuyer exclusivement sur des signatures d’attaque connues. Cela peut aider à identifier des attaques et des schémas de trafic jusque-là inconnus, qui ne deviennent suspects que lorsqu’ils sont examinés collectivement.

Défis des clients

Le cas échéant, les clients suspects peuvent être tenus d’effectuer des tests de navigateur ou de calcul avant d’être autorisés à accéder aux ressources protégées. Les défis doivent être appliqués avec précaution, car des frictions inutiles peuvent affecter les utilisateurs légitimes et l’accessibilité.

Protection DDoS réseau

Les défenses de la couche d’application ne devraient pas remplacer la protection de la couche réseau. Les hackers peuvent combiner des techniques de couche 7 avec des attaques volumétriques ou de protocole, les organisations devraient donc envisager une protection sur les couches 3, 4 et 7.

Comment les organisations peuvent-elles détecter une attaque DDoS au niveau de la couche d'application ?

Les organisations doivent surveiller les signes avant-coureurs connus d’une attaque par déni de service distribué. On peut citer notamment : 

• Augmentations soudaines des requêtes HTTP ou API

• Trafic inattendu vers des points de terminaison spécifiques

• Latence plus élevée de l’application

• Augmentation des erreurs 4xx ou 5xx

• Saturation de la base de données ou du back-end

• Trafic géographique inhabituel

• Grand nombre de nouveaux clients ou d’adresses IP

• Modèles de requêtes anormaux

• Baisse des taux de connexion au cache

• Augmentation soudaine du trafic d’origine

• Utilisation accrue de l’infrastructure sans augmentation correspondante de l’activité commerciale légitime

La clé, c’est le contexte. Une augmentation soudaine du trafic pourrait représenter une attaque, mais elle pourrait aussi correspondre au lancement réussi d’un produit ou à un événement d’actualité de dernière minute. Les contrôles de sécurité doivent distinguer les bons pics de trafic des pics malveillants avec autant de précision que possible.

Que propose Fastly pour la protection DDoS de couche d'application ?

Fastly fournit plusieurs technologies complémentaires pour protéger les applications contre les attaques par déni de service distribué et autres menaces de couche 7.

Protection DDoS

La Protection DDoS est conçue pour détecter et atténuer les attaques en périphérie avant que le trafic malveillant ne puisse submerger l’infrastructure d’application. Les capacités de protection DDoS de Fastly fonctionnent sur l’ensemble de son edge network mondial, ce qui permet de traiter le trafic d’attaque loin des origines protégées.

Pour les menaces de la couche d'application, cette approche est particulièrement précieuse, car l’atténuation peut se produire avant que des requête malveillantes ne consomment des serveur d’application, des bases de données, et d’autres ressources de back-end.

Fastly Next-Gen WAF

Fastly Next-Gen WAF fournit une protection des applications et des API contre les requêtes malveillantes. Il complète la protection DDoS en identifiant les attaques applicatives comme l’injection SQL, le cross-site scripting, l’injection de commandes, et d’autres trafics malveillants.

Le Next-Gen WAF de Fastly utilise la technologie SmartParse pour analyser les requêtes et identifier les intentions malveillantes, tout en visant à réduire les faux positifs couramment associés aux déploiements de WAF traditionnels riches en règles.

Fastly Bot Management

Fastly Bot Management peut aider à identifier et à contrôle le trafic automatisé ciblant les sites web et les applications. Cela est important pour le déni de service distribué de couche 7, car les hackers utilisent fréquemment des botnets pour répartir les requêtes malveillantes sur de nombreux clients.

Les capacités de Bot Management peuvent aider les organisations à distinguer le trafic automatisé des utilisateurs légitimes et à appliquer des contrôles en fonction de la nature de ce trafic.

Limitation du débit

Fastly fournit des capacités de limitation du débit que les organisations peuvent utiliser pour protéger les points de terminaison sensibles et contrôler des taux de requêtes excessifs. Au lieu de traiter chaque fonction de l’application de manière identique, les équipes peuvent concevoir des politiques autour des ressources qu’elles doivent protéger.

Mise en cache du Content Delivery Network et Origin Shield

Le Content Delivery Network de Fastly peut également contribuer à la résilience des applications. La mise en cache des réponses éligibles en périphérie réduit le nombre de requêtes qui doivent atteindre l’origine d’une application. Origin Shield fournit une couche de mise en cache supplémentaire qui peut réduire davantage les requêtes en double atteignant l’infrastructure back-end.

Ces capacités ne remplacent pas l’atténuation des attaques par déni de service distribué, mais elles peuvent réduire l’exposition de l’origine et améliorer la capacité d’une application à résister aux pics de trafic.

Visibilité en temps réel

Fastly fournit des capacités de journalisation en temps réel et d’observabilité qui peuvent aider les équipes de sécurité et d’Opérations à comprendre le trafic et le comportement de l’application pendant un incident.

Une visibilité rapide est particulièrement précieuse lors des attaques de couche 7, car les équipes peuvent avoir besoin de déterminer quels points de terminaison sont ciblés et en quoi les requêtes malveillantes diffèrent du trafic légitime.

Comment Fastly peut-il aider à protéger les applications contre les attaques DDoS de couche 7 ?

La Protection DDoS au niveau de la couche d'application fonctionne mieux lorsque plusieurs contrôles se renforcent mutuellement. Fastly réunit la Protection DDoS, le Next-Gen WAF, le Bot Management, la limitation du débit, la mise en cache du Content Delivery Network, Origin Shield, et la visibilité en temps réel sur sa plateforme Edge Cloud.

Cette approche en couches peut aider les entreprises :

• Détecter et atténuer le trafic malveillant en périphérie

• Réduire le trafic d’attaque atteignant l’infrastructure d’origine

• Protégez les sites web et les API contre les menaces de la couche d’application

• Identifier et contrôler les clients automatisés malveillants

• Appliquez des rate limits (limitation du débit) aux points de terminaison sensibles ou coûteux

• Absorbez plus efficacement les pics de trafic légitime

• Réduisez les requêtes vers le serveur d’origine grâce à la mise en cache

• Maintenir la visibilité pendant les incidents de sécurité

Plus important encore, les organisations ne devraient pas considérer la Protection DDoS de la couche d’application comme une simple question d’absorption du plus grand volume de trafic possible. Les attaque de couche 7 ciblent le comportement et les ressources de l’application. Une protection efficace doit donc comprendre suffisamment bien le trafic de l’application pour identifier les activités malveillantes tout en continuant à servir les utilisateur légitimes.

La combinaison de l’atténuation des DDoS à la périphérie avec une sécurité sensible aux applications, le Bot Management, la mise en cache, et la visibilité en temps réel peut offrir une défense plus solide contre les attaques conçues pour rendre indisponibles les applications web modernes et les API.