Bloccare gli attacchi DoS e DDoS utilizzando le regole di filtro del traffico

Scopri come bloccare gli attacchi Denial of Service (DoS) e Distributed Denial of Service (DDoS) utilizzando le regole del filtro del traffico rate limit e altre strategie nella rete CDN gestita di AEM as a Cloud Service (AEMCS). Questi attacchi causano picchi di traffico sulla rete CDN e potenzialmente sul servizio Publish dell’AEM (alias origine) e possono influire sulla capacità di risposta e sulla disponibilità del sito.

Questa esercitazione funge da guida su come analizzare i modelli di traffico e configurare le regole del filtro del traffico per mitigare tali attacchi. Il tutorial descrive anche come configurare gli avvisi in modo da ricevere una notifica quando si sospetta un attacco.

Informazioni sulla protezione

Comprendiamo le protezioni DDoS predefinite per il tuo sito web AEM:

Queste protezioni integrate devono essere considerate una base per la capacità di un'organizzazione di ridurre al minimo l'impatto sulle prestazioni di un attacco DDoS. Poiché ogni sito Web ha caratteristiche di prestazioni diverse e può notare un peggioramento delle prestazioni prima che venga raggiunto il limite di velocità definito dall'Adobe, si consiglia di estendere le protezioni predefinite tramite configurazione cliente.

Vediamo alcune misure aggiuntive consigliate che i clienti possono adottare per proteggere i propri siti web dagli attacchi DDoS:

Variazioni delle regole di traffico per limite di tariffa rate-limit-variations

Esistono due varianti delle regole di traffico dei limiti di velocità:

Percorso di clienti

I passaggi seguenti riflettono il probabile processo attraverso il quale i clienti dovrebbero proteggere i loro siti web.

Il resto di questa esercitazione ti guida attraverso questo processo.

Riconoscere la necessità di configurare le regole recognize-the-need

Come accennato in precedenza, per impostazione predefinita, Adobe blocca il traffico sulla rete CDN che supera una determinata velocità. Tuttavia, alcuni siti web potrebbero riscontrare un calo delle prestazioni al di sotto di tale soglia. Pertanto, è necessario configurare le regole del filtro del traffico del limite di velocità.

Idealmente, puoi configurare le regole prima di andare in produzione dal vivo. In pratica, molte organizzazioni dichiarano le regole in modo reattivo solo una volta avvisate di un picco di traffico che indica un probabile attacco.

L'Adobe invia un avviso di picco di traffico all'origine come Notifica Centro azioni quando viene superata una soglia predefinita di traffico da un singolo indirizzo IP per un determinato POP. Se hai ricevuto un avviso di questo tipo, ti consigliamo di configurare una regola per il filtro del traffico del limite di frequenza. Questo avviso predefinito è diverso dagli avvisi che devono essere abilitati esplicitamente dai clienti quando si definiscono le regole del filtro del traffico, e che verranno trattati in una sezione futura.

Analisi dei pattern di traffico analyze-traffic

Se il sito è già attivo, puoi analizzare i pattern di traffico utilizzando i registri CDN e i dashboard forniti con gli Adobi.

Configurare gli strumenti del dashboard utilizzando una delle opzioni seguenti:

ELK - configurazione degli strumenti del dashboard

Gli strumenti del dashboard Elasticsearch, Logstash e Kibana (ELK) forniti da Adobe possono essere utilizzati per analizzare i registri CDN. Questo strumento include una dashboard che visualizza i pattern di traffico e semplifica la determinazione delle soglie ottimali per le regole del filtro del traffico del limite di frequenza.

Splunk: configurazione degli strumenti del dashboard

I clienti che dispongono di Splunk Log Forwarding abilitato possono creare nuovi dashboard per analizzare i pattern di traffico.

Per creare dashboard in Splunk, segui I dashboard di Splunk per i passaggi di analisi del registro CDN di AEMCS.

Visualizzazione dei dati

Nelle dashboard ELK e Splunk sono disponibili le seguenti visualizzazioni:

Scelta dei valori di soglia

I valori di soglia per le regole del filtro del traffico del limite di velocità devono essere basati sull’analisi precedente e assicurarsi che il traffico legittimo non sia bloccato. Per istruzioni su come scegliere i valori di soglia, consulta la tabella seguente:

Il multiplo da utilizzare dipende dalle aspettative di picchi normali di traffico dovuti a traffico organico, campagne e altri eventi. Un multiplo tra 5 e 10 può essere ragionevole.

Se il sito non è ancora attivo, non vi sono dati da analizzare e devi effettuare una stima ragionata dei valori appropriati da impostare per le regole del filtro del traffico del limite di velocità. Ad esempio:

Configurazione delle regole configure-rules

Configura le regole del filtro del traffico per il limite di frequenza nel file /config/cdn.yaml del progetto AEM, con valori basati sulla discussione precedente. Se necessario, rivolgiti al team di sicurezza web per assicurarti che i valori limite di frequenza siano appropriati e non bloccino il traffico legittimo.

Per ulteriori informazioni, consulta Creare regole nel progetto 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

Si noti che vengono dichiarate sia le regole di origine che le regole edge e che la proprietà alert è impostata su true in modo da poter ricevere gli alert ogni volta che viene raggiunta la soglia, probabilmente a indicare un attacco.

Si consiglia di impostare il tipo di azione per la registrazione iniziale, in modo da poter monitorare il traffico per alcune ore o giorni, garantendo che il traffico legittimo non superi queste tariffe. Dopo alcuni giorni, passa alla modalità blocco.

Per distribuire le modifiche all’ambiente AEMCS, effettua le seguenti operazioni:

Configurazione delle regole di trasformazione delle richieste configure-request-transform-rules

Oltre alle regole del filtro del traffico per il limite di frequenza, si consiglia di utilizzare trasformazioni di richiesta per annullare l'impostazione dei parametri di query non necessari all'applicazione al fine di ridurre al minimo i modi per ignorare la cache tramite tecniche di busting della cache. Ad esempio, se desideri consentire solo i parametri di query search e campaignId, puoi dichiarare la seguente regola:

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

Ricezione degli avvisi sulle regole del filtro del traffico receiving-alerts

Come accennato in precedenza, se la regola del filtro del traffico include experiment_alert: true, viene ricevuto un avviso quando la regola viene rilevata.

Intervenire sugli avvisi acting-on-alerts

A volte, l’avviso è informativo, fornendo un senso della frequenza degli attacchi. Vale la pena analizzare i dati CDN utilizzando il dashboard descritto in precedenza, per verificare che il picco di traffico sia dovuto a un attacco e non solo a un aumento del volume di traffico legittimo. In quest’ultimo caso, puoi aumentare la soglia.

Simulazione di attacco attack-simulation

Questa sezione descrive i metodi per simulare un attacco DoS, che può essere utilizzato per generare dati per le dashboard utilizzate in questa esercitazione e per verificare che eventuali regole configurate blocchino correttamente gli attacchi.

Per simulare un attacco, è possibile utilizzare strumenti come Apache Benchmark, Apache JMeter, Vegeta e altri.

Richieste Edge

Utilizzando il seguente comando Vegeta puoi effettuare molte richieste al tuo sito Web:

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

Il comando precedente effettua 120 richieste per 5 secondi ed restituisce un rapporto. Supponendo che il sito web non sia soggetto a limitazioni di frequenza, questo può causare un picco nel traffico.

Richieste di origine

Per ignorare la cache CDN e effettuare richieste all’origine (servizio Publish AEM), puoi aggiungere all’URL un parametro di query univoco. Consulta lo script Apache JMeter di esempio dall'attacco DoS simulato utilizzando lo script JMeter