Bloquer des attaques DoS et DDoS à l’aide de règles de filtrage du trafic

Découvrez comment bloquer des attaques par déni de service (DoS) et par déni de service distribué (DDoS) à l’aide de règles de règles de filtrage du trafic limitant le débit et d’autres stratégies sur le réseau de diffusion de contenu géré par AEM as a Cloud Service (AEMCS). Ces attaques provoquent des pics de trafic sur le réseau de diffusion de contenu et potentiellement sur le service de publication AEM (soit l’origine) et peuvent avoir un impact sur la réactivité et la disponibilité du site.

Ce tutoriel sert de guide pour savoir comment analyser vos modèles de trafic et configurer des règles de filtrage du trafic limitant le débit pour réduire l’impact de ces attaques. Le tutoriel décrit également comment configurer des alertes afin de vous avertir en cas de suspicion d’attaque.

Présentation des protections

Examinons les protections par défaut contre les attaques DDoS de votre site web AEM :

Ces protections intégrées doivent être considérées comme une référence pour la capacité d’une organisation à minimiser l’impact d’une attaque DDoS sur les performances. Chaque site web ayant des caractéristiques de performances différentes et pouvant ainsi subir une dégradation des performances avant que la limite de débit définie par Adobe ne soit atteinte, il est recommandé d’étendre les protections par défaut via la configuration des clientes et clients.

Voici quelques autres mesures recommandées que les clientes et clients peuvent prendre pour protéger leurs sites contre les attaques DDoS :

Variantes des règles de filtrage du trafic limitant le débit rate-limit-variations

Il existe deux variantes des règles de filtrage du trafic limitant le débit :

Parcours des clientes et clients

Les étapes ci-dessous illustrent le processus possible que les clientes et les clients doivent suivre pour protéger leurs sites web.

Le reste de ce tutoriel vous guide tout au long de ce processus.

Reconnaître la nécessité de configurer des règles recognize-the-need

Comme précisé précédemment, Adobe bloque par défaut le trafic sur le réseau de diffusion de contenu si ce trafic dépasse un certain débit. Cependant, certains sites web peuvent subir une dégradation de leurs performances en dessous de ce seuil. Par conséquent, les règles de filtrage du trafic limitant le débit doivent être configurées.

Idéalement, vous devez configurer les règles avant de passer en production. Dans la pratique, de nombreuses organisations ne déclarent les règles que de manière réactive lorsqu’elles sont alertées d’un pic de trafic indiquant une attaque probable.

Adobe envoie une alerte de pic de trafic à l'origine sous la forme d’une Notification du Centre d’actions lorsque le seuil de trafic par défaut d’une adresse IP unique est dépassé, pour un PoP donné. Si vous avez reçu une telle alerte, il est recommandé de configurer une règles de filtrage du trafic limitant le débit. Cette alerte par défaut est différente des alertes que les clientes et les clients doivent activer explicitement lorsque ceux-ci définissent des règles de filtrage du trafic. Cela vous sera détaillé dans une section ultérieure.

Analyser les modèles de trafic analyze-traffic

Si votre site est déjà actif, vous pouvez analyser les modèles de trafic à l’aide des journaux du réseau CDN et des tableaux de bord fournis par Adobe.

Configurez l’outil de tableau de bord à l’aide de l’une des options suivantes  :

ELK - configurer les outils du tableau de bord

Les outils de tableau de bord Elasticsearch, Logstash et Kibana (ELK) fournis par Adobe peuvent être utilisés pour analyser les journaux du réseau de diffusion de contenu. Ces outils incluent un tableau de bord qui affiche les modèles de trafic, qui aide à déterminer les seuils optimaux pour vos règles de filtrage du trafic limitant le débit.

Splunk - configurer les outils du tableau de bord

Les clientes et clients qui ont activé le transfert de journal Splunk peuvent créer un tableau de bord pour analyser les modèles de trafic.

Pour créer des tableaux de bord dans Splunk, suivez les étapes Tableau de bord Splunk pour l’analyse de journaux de réseau CDN AEMCS.

Observer les données

Les visualisations suivantes sont disponibles dans les tableaux de bord ELK et Splunk :

Choix des valeurs de seuil

Les valeurs de seuil pour les règles de filtrage du trafic limitant le débit doivent être basées sur l’analyse ci-dessus et s’assurer que le trafic légitime n’est pas bloqué. Consultez le tableau suivant pour savoir comment choisir les valeurs de seuil :

Le facteur de multiplication à utiliser dépend des pics de trafic normaux auxquels vous vous attendez, en raison du trafic organique, de campagnes et d’autres événements. Un facteur de multiplication compris entre 5 et 10 est une option raisonnable.

Si votre site n’est pas encore en ligne, il n’y a aucune donnée à analyser. Vous devez estimer raisonnablement les valeurs appropriées à définir pour vos règles de filtrage du trafic limitant le débit. Par exemple :

Configurer des règles configure-rules

Configurez les règles de filtrage du trafic limitant le débit de votre fichier de projet AEM /config/cdn.yaml avec des valeurs basées sur l’explication ci-dessus. Le cas échéant, consultez votre équipe de sécurité web pour vous assurer que les valeurs de limites de débit sont appropriées et ne bloquent pas le trafic légitime.

Pour plus d’informations, consultez la section Créer des règles dans votre projet AEM.

kind: CDN
version: '1'
metadata:
  envTypes:
    - dev
    - stage
    - prod
data:
  trafficFilters:
    rules:
    ...
    #  Prevent attack at edge by blocking client for 5 minutes if they make more than 500 requests per second on average
      - name: prevent-dos-attacks-edge
        when:
          reqProperty: tier
          in: ["author","publish"]
        rateLimit:
          limit: 500 # replace with the appropriate value
          window: 10 # compute the average over 10s
          penalty: 300 # block IP for 5 minutes
          count: all # count all requests
          groupBy:
            - reqProperty: clientIp
        action:
          type: log
          experimental_alert: true
    #  Prevent attack at origin by blocking client for 5 minutes if they make more than 100 requests per second on average
      - name: prevent-dos-attacks-origin
        when:
          reqProperty: tier
          in: ["author","publish"]
        rateLimit:
          limit: 100 # replace with the appropriate value
          window: 10 # compute the average over 10s
          penalty: 300 # block IP for 5 minutes
          count: fetches # count only fetches
          groupBy:
            - reqProperty: clientIp
        action:
          type: log
          experimental_alert: true

Notez que les règles d’origine et Edge sont déclarées et que la propriété alert est définie sur true, vous permettant de recevoir des alertes chaque fois que le seuil est atteint, ce qui indique probablement une attaque.

Il est recommandé de définir le type d’action de manière à pouvoir surveiller le trafic pendant quelques heures ou quelques jours, afin de s’assurer que le trafic légitime ne dépasse pas ces débits. Au bout de quelques jours, passez en mode bloc.

Pour déployer les modifications dans votre environnement AEMCS, procédez comme suit :

Configurer des règles de transformation de requêtes configure-request-transform-rules

En plus des règles de filtrage du trafic limitant le débit, il est recommandé d’utiliser des transformations de requêtes pour annuler des paramètres de requête dont l’application n’a pas besoin afin de réduire les possibilités de contourner le cache par le biais de techniques d’actualisation forcée du cache. Par exemple, si vous souhaitez autoriser uniquement les paramètres de requête search et campaignId, la règle suivante peut être déclarée :

kind: "CDN"
version: "1"
metadata:
  envTypes:
    - dev
    - stage
    - prod
data:
  experimental_requestTransformations:
    rules:
      - name: unset-all-query-params-except-those-needed
        when:
          reqProperty: tier
          in: ["publish"]
        actions:
          - type: unset
            queryParamMatch: ^(?!search$|campaignId$).*$

Recevoir des alertes sur les règles de filtrage du trafic receiving-alerts

Comme mentionné ci-dessus, si la règle de filtrage du trafic inclut experimental_alert: true, une alerte est reçue lorsque la règle est satisfaite.

Agir en réponse aux alertes acting-on-alerts

Parfois, l’alerte est à titre indicatif, ce qui vous permet d’avoir une idée de la fréquence des attaques. Il est utile d’analyser vos données de réseau de diffusion de contenu à l’aide du tableau de bord décrit ci-dessus, afin de vérifier que le pic de trafic est dû à une attaque et non à une simple augmentation du volume du trafic légitime. S’il s’agit de ce dernier cas, envisagez d’augmenter votre seuil.

Simulation d’attaque attack-simulation

Cette section décrit les méthodes de simulation d’une attaque par déni de service, qui peuvent être utilisées pour générer des données pour les tableaux de bord utilisés dans ce tutoriel et pour vérifier que toutes les règles configurées bloquent correctement les attaques.

Pour simuler une attaque, des outils tels qu’Apache Benchmark, Apache JMeter, Vegeta, ou autres, peuvent être utilisés.

Requêtes Edge

En utilisant la commande Vegeta suivante, vous pouvez envoyer de nombreuses requêtes à votre site web :

$ echo "GET https://<YOUR-WEBSITE-DOMAIN>" | vegeta attack -rate=120 -duration=5s | vegeta report

Cette commande effectue 120 requêtes pendant 5 secondes et génère un rapport. En supposant que le débit du site web ne soit pas limité, cela peut entraîner un pic de trafic.

Requêtes à l’origine

Pour contourner le cache du réseau de diffusion de contenu et envoyer des requêtes à l’origine (service de publication d’AEM), vous pouvez ajouter un paramètre de requête unique à l’URL. Reportez-vous à l’exemple de script Apache JMeter de la section Simuler une attaque DoS à l’aide du script JMeter.