Présentation

Les attaques par déni de service distribué (DDoS) sont des tentatives malveillantes visant à perturber le trafic normal d'un serveur, d'un service ou d'un réseau ciblé en le submergeant d'un flot de trafic Internet. Si elles ne sont pas efficacement atténuées, les attaques DDoS peuvent entraîner une diminution de la disponibilité ou une dégradation des temps de réponse des applications Web. Dans de telles situations,si l'application se met à l'échelle pour faire face à l'attaque, elle entraîne des coûts de mise à l'échelle indésirables. Heureusement, les applications construites sur AWS bénéficient de protections DDoS natives et peuvent être conçues pour être très résistantes à ces attaques en utilisant les services et les contrôles de sécurité d'AWS.

L'approche d'AWS en matière de protection contre les attaques DDoS

AWS et le client se partagent la responsabilité d'assurer la sécurité. AWS est responsable de la protection de l'infrastructure qui sous-tend ses services de cloud. Pour protéger son infrastructure, AWS utilise des protections natives contre les attaques DDoS (aux couches 3 et 4) sans frais supplémentaires. Ces protections sont fournies par le biais de Shield Standard et sont basées sur les composants suivants :

  • Les systèmes de surveillance analysent diverses sources, telles que NetFlow provenant de dispositifs de mise en réseau et de journaux de service, afin de détecter les attaques DDoS.
  • Les systèmes de nettoyage nettoient le trafic des attaques DDoS à l'aide de l'inspection approfondie des paquets, du pare-feu et de la mise en forme du trafic. Pour des services tels que CloudFront et Route 53, des systèmes de nettoyage sont déployés au sein de leurs points de présence (PoP), ce qui permet une détection et une atténuation en moins d'une seconde. En revanche, pour les services régionaux tels que ALB ou EC2, les systèmes de nettoyage atténuent les attaques après leur détection, généralement en quelques minutes.
  • L'équipe Shield Response veille à la résolution rapide des attaques DDoS qui ne sont pas automatiquement détectées et atténuées par les systèmes de surveillance et de nettoyage.

Dans le modèle de responsabilité partagée, votre responsabilité en matière de protection contre les attaques DDoS dépend des services cloud AWS que vous utilisez, qui déterminent l'ampleur du travail de configuration que vous devez effectuer. Par exemple, exposer des fichiers depuis S3 au lieu d'une instance EC2 réduit les contrôles de sécurité que vous devez utiliser contre les attaques DDoS. Quels que soient les services utilisés, AWS fournit des fonctionnalités pour protéger, surveiller et répondre aux attaques DDoS relevant de votre responsabilité.

Vous êtes responsable de la conception d'architectures résilientes aux attaques DDoS à l'aide des services AWS. Les bonnes pratiques sont notamment les suivantes :

Protection de l'infrastructure contre les attaques DDoS grâce aux services de périphérie AWS

Le blocage des inondations HTTP à l'aide d'AWS WAF

Pour bloquer efficacement les inondations HTTP (attaques DDoS au niveau de la couche 7), AWS WAF propose une combinaison de plusieurs règles.

  • Règles visant à réduire l'attaque de surface de l'application, en refusant tout modèle de requête inattendu. Par exemple, vous pouvez écrire des règles pour refuser les demandes dont les URL ne correspondent pas aux schémas d'URL de votre API, les demandes contenant des verbes HTTP non pris en charge par votre API ou simplement les valeurs d'en-tête Host ne figurant pas dans vos noms de domaine. Ces règles bloquent immédiatement le trafic indésirable.
  • Règles basées sur la réputation IP qui bloquent le trafic provenant d'adresses IP mal réputées. Vous pouvez utiliser les règles gérées par Amazon sur la base des renseignements sur les menaces collectées par AWS, les règles gérées pour AWS WAF par des fournisseurs d'AWS Marketplace, tels qu'Imperva, ou vous pouvez créer votre propre liste de réputation IP et mettre à jour automatiquement AWS WAF. Les règles basées sur la réputation IP ont tendance à bloquer immédiatement une partie importante des inondations HTTP.
  • Règles de limitation de débit qui regroupent les demandes en fonction d'une dimension configurée (par exemple, IP), puis bloquent le trafic si le volume de demandes agrégé dépasse les seuils configurés (par exemple 100 demandes) pendant une certaine durée (par exemple 1 min). Les limites de débit bloquent le trafic incriminé en quelques dizaines de secondes jusqu'à ce que son volume descende en dessous des seuils configurés. Si vous souhaitez prolonger la durée de blocage des limites de débit, implémentez la solution personnalisée décrite dans ce blog. Voici des exemples de règles de limitation de débit : une règle globale basée sur une adresse IP avec un seuil élevé (par exemple, 2 000), une règle basée sur une adresse IP spécifique à un URI (par exemple /login) avec un seuil inférieur (par exemple 100), une règle basée sur le pays pour les pays dans lesquels vous n'exercez pas d'activité significative, une règle basée sur des cookies pour bloquer les sessions authentifiées incriminées, etc.
  • Règles avec action JavaScript Challenge, pour bloquer immédiatement le trafic indésirable généré par les outils qui ne parviennent pas à exécuter JavaScript et à résoudre les problèmes comme le font les navigateurs légitimes.
  • Règles de contrôle des bots pour vous protéger contre les inondations HTTP orchestrées par des robots évasifs. Les techniques de gestion des bots utilisant le contrôle des bots AWS WAF incluent les détections comportementales, la détection basée sur le ML d'activités coordonnées, la détection automatique des navigateurs et les défis CAPTCHA. La détection et l'atténuation se produisent en quelques dizaines de secondes.
  • Règles basées sur la signature d'attaque créée automatiquement par l'atténuation automatique des attaques DDoS contre la couche applicative de Shield Advanced (L7AM). Lorsque cette fonctionnalité de Shield Advanced est activée, un groupe de règles géré vide est créé dans votre AWS WAF WebACL, et le trafic de votre application est surveillé pendant au moins 72 heures afin de créer une base de référence pour le trafic normal. En cas d'écart significatif entre le profil de trafic et la base de référence établie, Shield Advanced signale une détection DDoS et commence à analyser le trafic à la recherche d'une signature d'attaque. Si une signature est trouvée, elle est d'abord testée sur le trafic passé afin de réduire le risque de faux positifs, puis s'il est possible de l'utiliser en toute sécurité, une règle WAF correspondante est placée dans le groupe de règles créé précédemment. Après un certain temps, lorsque l'attaque est arrêtée, la règle est automatiquement supprimée du groupe de règles. En cas de succès, ce processus prend plusieurs minutes.

En outre, vous pouvez implémenter des règles WAF dynamiques qui s'adaptent au niveau de menace perçu, permettant ainsi des réponses plus agressives (par exemple, des actions CAPTCHA ou Challenge) lors d'attaques DDoS de haute gravité. Découvrez comment implémenter ce modèle en utilisant cette solution.

Protection contre les DDoS avec AWS WAF

Utilisation de Shield Advanced

Shield Advanced est un service AWS supplémentaire qui renforce votre sécurité contre les attaques DDoS. Il fournit une atténuation automatique au niveau de la couche 7 à l'aide d'AWS WAF pour les applications Web et de meilleures protections pour les applications non Web, telles que l'application des règles de la liste de contrôle d'accès au réseau (NACL) sur le réseau frontalier doté d'une capacité de bande passante plus élevée. Avec Shield Advanced, les attaques qui ne sont pas atténuées automatiquement peuvent être transmises à l'équipe de réponse de Shield pour être atténuées manuellement.

Comparaison entre AWS Shield Standard et AWS Shield Advanced
Valeur ajoutée par l'équipe d'intervention d'AWS Shield

Pour bénéficier de toutes les fonctionnalités de Shield Advanced, il est recommandé ce qui suit :

  1. Ajouter les protections Shield Advanced à vos ressources AWS accessibles sur Internet après vous être abonné à Shield Advanced. Mettre en place les protections 72 heures avant une attaque pour garantir que le trafic des applications est défini comme référence et que des mesures d'atténuation sont appliquées.
  2. Pour les ressources CloudFront et ALB, associer une WebACL AWS WAF aux bonnes pratiques décrites dans la section précédente (par exemple, limitation du débit, réputation IP, etc.). Activer la protection de couche 7 pour ces ressources. Configurer éventuellement la journalisation AWS WAF.
  3. Configurez un engagement proactif pour recevoir un contact direct de la part de l'équipe d'intervention AWS Shield (SRT). L'engagement proactif peut être activé avant de créer les surveillances de l'état d'Amazon Route 53. Les surveillance de l'état associés à votre application améliorent la sensibilité de détection de Shield Advanced. Par exemple, lorsque les surveillances de l'état détectent une augmentation des erreurs 5xx renvoyées par votre application, Shield Advanced abaisse les seuils de détection. Regardez cette vidéo courte pour savoir comment configurer les surveillances de l’état.
  4. Configurez les alarmes CloudWatch pour que Shield et WAF reçoivent des notifications lorsque vous êtes attaqué.

Pour auditer votre configuration de Shield Advanced, exécutez le runbook sur l’évaluation de la résilience contre les attaques DDoS dans AWS Systems Manager. Il collecte, analyse et évalue les ressources suivantes : Amazon Route 53, équilibreur de charge Amazon, distributions Amazon CloudFront, AWS Global Accelerator et AWS Elastic IPs pour leurs paramètres de configuration conformément aux meilleures pratiques recommandées pour la protection AWS Shield Advanced.

Test de résilience aux attaques DDoS

Les tests de simulation d'attaques DDoS sont autorisés sur AWS et sont soumis aux conditions générales détaillées sur cette page. AWS propose deux options pour exécuter des tests de simulation DDoS : soit une attaque DDoS simulée dans le trafic de production avec un partenaire AWS autorisé et pré-approuvé tel que NCC Group plc, RedWolf et Red Button ; soit une attaque DDoS simulée synthétique avec la Shield Response Team, également appelée firedrill.

Ressources

 

Cette page vous a-t-elle été utile ?

 Commentaires