Blockieren von DoS- und DDoS-Angriffen mithilfe von Traffic-Filterregeln

Erfahren Sie, wie Sie Denial of Service (DoS)- und Distributed Denial of Service (DDoS)-Angriffe mithilfe von Ratenbegrenzungs-Traffic-Filterregeln und anderen Strategien im von AEM as a Cloud Service (AEMCS) verwalteten CDN blockieren können. Diese Angriffe führen zu Traffic-Spitzen beim CDN und möglicherweise beim AEM-Publish-Service (auch bekannt als Ursprung) und können die Reaktionsfähigkeit und Verfügbarkeit der Website beeinträchtigen.

Dieses Tutorial dient als Anleitung zur Analyse Ihres Traffic-Musters und zur Konfiguration von Ratenbegrenzungs-Traffic-Filterregeln, um diese Angriffe zu entschärfen. In diesem Tutorial wird auch beschrieben, wie Sie Warnhinweise konfigurieren können, damit Sie benachrichtigt werden, wenn ein Verdacht auf einen Angriff besteht.

Grundlegendes zum Schutz

Im Folgenden werden die standardmäßigen DDoS-Schutzmaßnahmen für Ihre AEM-Website beschrieben:

Diese integrierten Schutzmechanismen sollten als Grundlage für die Fähigkeit eines Unternehmens betrachtet werden, die Auswirkungen eines DDoS-Angriffs auf die Leistung zu minimieren. Da jede Website unterschiedliche Leistungsmerkmale aufweist und es zu einer Leistungsverschlechterung kommen kann, bevor die von Adobe definierte Ratenbegrenzung erreicht wird, wird empfohlen, die Standardschutzmaßnahmen über die Kundenkonfiguration zu erweitern.

Sehen wir uns einige zusätzliche, empfohlene Maßnahmen an, die kundenseitig ergriffen werden können, um ihre Websites vor DDoS-Angriffen zu schützen:

Varianten von Ratenbegrenzungs-Traffic-Regeln rate-limit-variations

Es gibt zwei Varianten von Traffic-Regeln für Ratenbegrenzungen:

Customer Journey

Die folgenden Schritte veranschaulichen den wahrscheinlichen Prozess, den Kundinnen und Kunden durchlaufen, um ihre Websites zu schützen.

Der Rest dieses Tutorials führt Sie durch diesen Prozess.

Wie Sie erkennen, wann es notwendig ist, Regeln zu konfigurieren recognize-the-need

Wie bereits erwähnt, blockiert das Adobe standardmäßig den Traffic beim CDN, der eine bestimmte Rate überschreitet. Allerdings können einige Websites schon unterhalb dieses Schwellenwerts eine verschlechterte Leistung aufweisen. Daher sollten Ratenbegrenzungs-Traffic-Filterregeln konfiguriert werden.

Idealerweise sollten Sie die Regeln konfigurieren, bevor Sie in die Produktion gehen. In der Praxis deklarieren viele Unternehmen erst dann reaktive Regeln, wenn sie auf eine Traffic-Spitze aufmerksam gemacht werden, die auf einen wahrscheinlichen Angriff hindeutet.

Adobe sendet eine Traffic-Spitzen-Warnung als Aktionszentrums-Benachrichtigung, wenn ein Standardschwellenwert für den Traffic von einer einzelnen IP-Adresse für einen bestimmten PoP überschritten wird. Wenn Sie einen solchen Warnhinweis erhalten haben, wird empfohlen, eine Ratenbegrenzungs-Traffic-Filterregel zu konfigurieren. Dieser Standardwarnhinweis unterscheidet sich von den Warnhinweisen, die auf Kundenseite bei der Definition von Traffic-Filterregeln explizit aktiviert werden müssen. Dies wird in einem späteren Abschnitt erläutert.

Analysieren von Traffic-Mustern analyze-traffic

Wenn Ihre Site bereits live ist, können Sie die Traffic-Muster anhand der CDN-Protokolle und der von Adobe bereitgestellten Dashboards analysieren.

Konfigurieren Sie die Dashboard-Tools mit einer der folgenden Optionen:

ELK – Konfigurieren des Dashboard-Tools

Die Dashboard-Tools Elasticsearch, Logstash und Kibana (ELK) von Adobe können zur Analyse der CDN-Protokolle verwendet werden. Diese Tools enthalten ein Dashboard, das die Traffic-Muster visualisiert, sodass Sie die optimalen Schwellenwerte für Ihre Ratenbegrenzungs-Traffic-Filterregeln leichter bestimmen können.

Splunk – Konfigurieren der Dashboard-Tools

Kundinnen und Kunden, die die Splunk Log-Weiterleitung aktiviert haben, können neue Dashboards erstellen, um Traffic-Muster zu analysieren.

Um Dashboards in Splunk zu erstellen, folgen Sie den Schritten Splunk-Dashboards für AEMCS CDN Log Analysis.

Blick auf die Daten

Die folgenden Visualisierungen sind in den ELK- und Splunk-Dashboards verfügbar:

Auswählen von Schwellenwerten

Die Schwellenwerte für die Ratenbegrenzungs-Traffic-Filterregeln sollten auf der obigen Analyse basieren und sicherstellen, dass legitimer Traffic nicht blockiert wird. In der folgenden Tabelle finden Sie Anleitungen zur Auswahl der Schwellenwerte:

Der zu verwendende Multiplikator hängt von Ihren Erwartungen an normale Spitzen im Traffic ab, die durch organischen Traffic, Kampagnen und andere Ereignisse verursacht werden. Ein Multiplikator zwischen 5 und 10 kann angemessen sein.

Wenn Ihre Site noch nicht live ist, können keine Daten analysiert werden. Stellen Sie daher sicher, welche Werte für die Ratenbegrenzungs-Traffic-Filterregeln festgelegt werden sollten. Zum Beispiel:

Konfigurieren der Regeln configure-rules

Konfigurieren Sie die Ratenbegrenzungs-Traffic-Filterregeln in der Datei /config/cdn.yaml Ihres AEM-Projekts mit Werten, die auf der obigen Diskussion basieren. Wenden Sie sich bei Bedarf an Ihr Web-Sicherheits-Team, um sicherzustellen, dass die Ratenbegrenzungswerte angemessen sind und nicht den legitimen Traffic blockieren.

Weitere Einzelheiten finden Sie unter Erstellen von Regeln in Ihrem AEM-Projekt.

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

Beachten Sie, dass sowohl Ursprungs- als auch Edge-Regeln deklariert sind und dass die Warnhinweis-Eigenschaft auf true festgelegt ist, sodass Sie Warnhinweise erhalten können, wenn der Schwellenwert erreicht wird, was wahrscheinlich auf einen Angriff hinweist.

Es wird empfohlen, den Aktionstyp auf die anfängliche Protokollierung zu setzen, damit Sie den Traffic für einige Stunden oder Tage überwachen können, um sicherzustellen, dass der zulässige Traffic diese Raten nicht überschreitet. Wechseln Sie nach einigen Tagen in den Blockierungsmodus.

Führen Sie die folgenden Schritte aus, um die Änderungen in Ihrer AEMCS-Umgebung bereitzustellen:

Konfigurieren von Anfrageumwandlungen configure-request-transform-rules

Zusätzlich zur Ratenbegrenzungs-Traffic-Filterregel wird empfohlen, Anfrageumwandlungen zu verwenden, um Abfrageparameter zu entfernen, die von der Anwendung nicht benötigt werden, wodurch die Möglichkeit minimiert wird, den Cache durch Cache-Busting-Techniken zu umgehen. Wenn Sie zum Beispiel nur die Abfrageparameter search und campaignId zulassen möchten, kann die folgende Regel deklariert werden:

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$).*$

Empfang von Warnhinweisen zu Traffic-Filterregeln receiving-alerts

Wenn die Traffic-Filterregel experimental_alert: true enthält, erhalten Sie einen Warnhinweis, wenn die Regel wie oben beschrieben zutrifft.

Maßnahmen bei Warnhinweisen acting-on-alerts

Manchmal ist der Warnhinweis nur informativ und gibt Ihnen einen Eindruck von der Häufigkeit der Angriffe. Es lohnt sich, Ihre CDN-Daten mithilfe des oben beschriebenen Dashboards zu analysieren und zu überprüfen, ob die Traffic-Spitze auf einen Angriff und nicht nur auf einen Anstieg des legitimen Traffic-Volumens zurückzuführen ist. Wenn dies der Fall ist, sollten Sie Ihren Schwellenwert erhöhen.

Angriffssimulation attack-simulation

In diesem Abschnitt werden Methoden zur Simulation eines DoS-Angriffs beschrieben, mit denen Sie Daten für die in diesem Tutorial verwendeten Dashboards generieren und überprüfen können, ob die konfigurierten Regeln Angriffe erfolgreich blockieren.

Um einen Angriff zu simulieren, können Tools wie Apache Benchmark, Apache JMeter, Vegeta und andere verwendet werden.

Edge-Anfragen

Mit dem folgenden Vegeta-Befehl können Sie viele Anfragen an Ihre Website stellen:

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

Der obige Befehl führt 120 Abfragen für 5 Sekunden durch und gibt einen Bericht aus. Sofern die Website keine Ratenbegrenzung hat, kann dies zu einem starken Anstieg des Traffics führen.

Ursprungsanfragen

Um den CDN-Cache zu umgehen und Anfragen an den Ursprung (AEM-Publish-Service) zu stellen, können Sie der URL einen eindeutigen Abfrageparameter hinzufügen. Weitere Informationen finden Sie in dem Apache JMeter-Beispielskript unter Simulieren eines DoS-Angriffs mithilfe des JMeter-Skripts