Esempi e analisi dei risultati delle regole del filtro del traffico, incluse le regole WAF

Scopri come dichiarare vari tipi di regole del filtro del traffico e analizzare i risultati utilizzando i registri CDN e gli strumenti della dashboard di Adobe Experience Manager as a Cloud Service (AEMCS).

In questa sezione verranno illustrati alcuni esempi pratici delle regole del filtro del traffico, incluse le regole WAF. Scoprirai come registrare, consentire e bloccare le richieste in base a URI (o percorso), indirizzo IP, numero di richieste e tipi di attacco diversi utilizzando Progetto siti WKND AEM.

Inoltre, scoprirai come utilizzare gli strumenti della dashboard che acquisiscono i registri CDN di AEMCS per visualizzare le metriche essenziali attraverso gli esempi di dashboard forniti da Adobe.

Per allinearsi ai requisiti specifici, puoi migliorare e creare dashboard personalizzate, ottenendo informazioni più approfondite e ottimizzando le configurazioni delle regole per i siti AEM.

Esempi

Esaminiamo vari esempi di regole del filtro del traffico, incluse le regole WAF. Assicurati di aver completato il processo di installazione richiesto come descritto nel precedente capitolo su come configurare e di aver clonato il progetto AEM WKND Sites.

Registrazione delle richieste

Iniziare registrando le richieste dei percorsi di accesso e disconnessione WKND rispetto al servizio Publish AEM.

  • Aggiungi la regola seguente al file /config/cdn.yaml del progetto WKND.
kind: CDN
version: '1'
metadata:
  envTypes:
    - dev
    - stage
    - prod
data:
  trafficFilters:
    rules:
    # On AEM Publish service log WKND Login and Logout requests
      - name: publish-auth-requests
        when:
          allOf:
            - reqProperty: tier
              matches: publish
            - reqProperty: path
              in:
                - /system/sling/login/j_security_check
                - /system/sling/logout
        action: log
  • Esegui il commit e invia le modifiche all’archivio Git di Cloud Manager.

  • Distribuire le modifiche all'ambiente di sviluppo AEM utilizzando la pipeline di configurazione di Cloud Manager Dev-Config creata in precedenza.

    Pipeline di configurazione Cloud Manager

  • Verifica la regola effettuando l'accesso e la disconnessione dal sito WKND del programma nel servizio Publish (ad esempio, https://publish-pXXXX-eYYYY.adobeaemcloud.com/us/en.html). È possibile utilizzare asmith/asmith come nome utente e password.

    Accesso WKND

Analisi analyzing

Analizziamo i risultati della regola publish-auth-requests scaricando i registri CDN di AEMCS da Cloud Manager e utilizzando gli strumenti del dashboard, impostati nel capitolo precedente.

  • Dalla scheda Ambienti di Cloud Manager, scarica i registri CDN del servizio Publish AEMCS.

    Download dei registri CDN di Cloud Manager

    note tip
    TIP
    La visualizzazione delle nuove richieste nei registri CDN potrebbe richiedere fino a 5 minuti.
  • Copiare il file di registro scaricato (ad esempio, publish_cdn_2023-10-24.log nella schermata seguente) nella cartella logs/dev del progetto di strumento dashboard elastico.

    Cartella registri strumenti ELK {width="800" modal="regular"}

  • Aggiornare la pagina dello strumento Dashboard elastica.

    • Nella sezione Global filter principale, modifica il filtro aem_env_name.keyword e seleziona il valore dell'ambiente dev.

      Filtro globale dello strumento ELK

    • Per modificare l’intervallo di tempo, fai clic sull’icona del calendario nell’angolo in alto a destra e seleziona l’intervallo di tempo desiderato.

      Intervallo tempo strumento ELK

  • Rivedi i pannelli Richieste analizzate, Richieste con flag e Dettagli richieste con flag del dashboard aggiornato. Per le voci di registro CDN corrispondenti, deve mostrare i valori dell’IP client (cli_ip), dell’host, dell’URL, dell’azione (waf_action) e del nome della regola (waf_match) di ciascuna voce.

    Dashboard dello strumento ELK

Blocco delle richieste

In questo esempio, aggiungiamo una pagina in una cartella internal nel percorso /content/wknd/internal nel progetto WKND distribuito. Dichiara quindi una regola del filtro del traffico che blocca il traffico verso pagine secondarie da qualsiasi posizione diversa da un indirizzo IP specificato corrispondente all'organizzazione (ad esempio, una VPN aziendale).

Puoi creare una pagina interna personalizzata (ad esempio, demo-page.html) oppure utilizzare il pacchetto allegato.

  • Aggiungi la seguente regola nel file /config/cdn.yaml del progetto WKND:
kind: CDN
version: '1'
metadata:
  envTypes:
    - dev
    - stage
    - prod
data:
  trafficFilters:
    rules:
    ...

    # Block requests to (demo) internal only page/s from public IP address but allow from internal IP address.
    # Make sure to replace the IP address with your own IP address.
      - name: block-internal-paths
        when:
          allOf:
            - reqProperty: path
              matches: /content/wknd/internal
            - reqProperty: clientIp
              notIn: [192.150.10.0/24]
        action: block
  • Esegui il commit e invia le modifiche all’archivio Git di Cloud Manager.

  • Distribuisci le modifiche all'ambiente di sviluppo AEM utilizzando la pipeline di configurazione creata in precedenza Dev-Config in Cloud Manager.

  • Verificare la regola accedendo alla pagina interna del sito WKND, ad esempio https://publish-pXXXX-eYYYY.adobeaemcloud.com/content/wknd/internal/demo-page.html o utilizzando il comando CURL seguente:

    code language-bash
    $ curl -I https://publish-pXXXX-eYYYY.adobeaemcloud.com/content/wknd/internal/demo-page.html
    
  • Ripeti il passaggio precedente sia dall’indirizzo IP utilizzato nella regola che da un indirizzo IP diverso (ad esempio, utilizzando il telefono cellulare).

Analisi

Per analizzare i risultati della regola block-internal-paths, seguire gli stessi passaggi descritti nell'esempio precedente.

Tuttavia, questa volta dovresti visualizzare le richieste bloccate e i valori corrispondenti nelle colonne IP client (cli_ip), host, URL, azione (waf_action) e nome regola (waf_match).

Richiesta bloccata dashboard strumenti ELK

Previeni gli attacchi DoS

Impediamo attacchi DoS bloccando le richieste provenienti da un indirizzo IP che effettua 100 richieste al secondo, causandone il blocco per 5 minuti.

  • Aggiungi la seguente regola 🔗 del filtro del traffico del limite di frequenza nel file /config/cdn.yaml del progetto WKND.
kind: CDN
version: '1'
metadata:
  envTypes:
    - dev
    - stage
    - prod
data:
  trafficFilters:
    rules:
    ...
    #  Prevent DoS attacks by blocking client for 5 minutes if they make more than 100 requests in 1 second.
      - name: prevent-dos-attacks
        when:
          reqProperty: path
          like: '*'
        rateLimit:
          limit: 100
          window: 1
          penalty: 300
          groupBy:
            - reqProperty: clientIp
        action: block
WARNING
Per l'ambiente di produzione, collaborare con il team di sicurezza Web per determinare i valori appropriati per rateLimit,
  • Eseguire il commit, il push e la distribuzione delle modifiche come indicato negli esempi precedenti.

  • Per simulare l'attacco DoS, utilizzare il seguente comando Vegeta.

    code language-shell
    $ echo "GET https://publish-pXXXX-eYYYY.adobeaemcloud.com/us/en.html" | vegeta attack -rate=120 -duration=5s | vegeta report
    

    Questo comando effettua 120 richieste per 5 secondi ed restituisce un rapporto. Come puoi vedere, il tasso di successo è del 32,5%; per il resto viene ricevuto un codice di risposta HTTP 406, a dimostrazione che il traffico era bloccato.

    Attacco DoS Vegeta

Analisi

Per analizzare i risultati della regola prevent-dos-attacks, seguire gli stessi passaggi descritti nell'esempio precedente.

Questa volta dovresti visualizzare molte richieste bloccate e i valori corrispondenti nelle colonne IP client (cli_ip), host, URL, azione (waf_action) e nome regola (waf_match).

Richiesta DoS dashboard strumenti ELK

Inoltre, i pannelli Primi 100 attacchi da parte di IP client, paese e agente utente mostrano ulteriori dettagli che possono essere utilizzati per ottimizzare ulteriormente la configurazione delle regole.

Dashboard strumenti ELK: 100 richieste DoS principali

Per ulteriori informazioni su come prevenire gli attacchi DoS e DDoS, vedere l'esercitazione Blocco degli attacchi DoS e DDoS mediante le regole del filtro del traffico.

Regole WAF

Gli esempi di regole del filtro del traffico finora possono essere configurati da tutti i clienti Sites e Forms.

Esaminiamo ora l’esperienza di un cliente che ha ottenuto una licenza di sicurezza avanzata o protezione WAF-DDoS, che consente di configurare regole avanzate per proteggere i siti web da attacchi più sofisticati.

Prima di continuare, abilitare la protezione WAF-DDoS per il programma, come descritto nella documentazione sulle regole del filtro del traffico passaggi di configurazione.

Senza WAFFlags

Vediamo innanzitutto l’esperienza anche prima che vengano dichiarate le regole WAF. Quando il WAF-DDoS è abilitato nel programma, i registri CDN per impostazione predefinita registrano qualsiasi corrispondenza di traffico dannoso, in modo da avere le informazioni giuste per trovare le regole appropriate.

Iniziamo attaccando il sito WKND senza aggiungere una regola WAF (o utilizzando la proprietà wafFlags) e analizzando i risultati.

  • Per simulare un attacco, utilizzare il comando Nikto di seguito, che invia circa 700 richieste dannose in 6 minuti.

    code language-shell
    $ ./nikto.pl -useragent "AttackSimulationAgent (Demo/1.0)" -D V -Tuning 9 -ssl -h https://publish-pXXXX-eYYYY.adobeaemcloud.com/us/en.html
    

    Simulazione attacco Nikto

    Per informazioni sulla simulazione degli attacchi, consultare la documentazione Nikto - Scan Tuning, che spiega come specificare il tipo di attacchi di test da includere o escludere.

Analisi

Per analizzare i risultati della simulazione dell'attacco, seguire gli stessi passaggi descritti nell'esempio precedente.

Tuttavia, questa volta dovresti visualizzare le richieste con flag e i valori corrispondenti nelle colonne IP client (cli_ip), host, URL, azione (waf_action) e nome regola (waf_match). Queste informazioni ti consentono di analizzare i risultati e ottimizzare la configurazione della regola.

Richiesta contrassegnata WAF dashboard strumenti ELK

I pannelli Distribuzione flag WAF e Attacchi principali mostrano ulteriori dettagli che possono essere utilizzati per ottimizzare ulteriormente la configurazione della regola.

Richiesta di flag di attacchi WAF dashboard strumento ELK

Richiesta attacchi principali WAF dashboard strumenti ELK

Con WAFFlags

Aggiungiamo ora una regola WAF che contiene la proprietà wafFlags come parte della proprietà action e blocchiamo le richieste di attacchi simulati.

Dal punto di vista della sintassi, le regole WAF sono simili a quelle visualizzate in precedenza, tuttavia, la proprietà action fa riferimento a uno o più valori wafFlags. Per ulteriori informazioni su wafFlags, consulta la sezione Elenco flag WAF.

  • Aggiungi la seguente regola nel file /config/cdn.yaml del progetto WKND. Si noti che la regola block-waf-flags include alcuni dei wafFlags visualizzati nella dashboard quando vengono attaccati con traffico dannoso simulato. In effetti, è buona prassi nel tempo analizzare i registri per determinare quali nuove regole dichiarare, man mano che il panorama delle minacce si evolve.
kind: CDN
version: '1'
metadata:
  envTypes:
    - dev
    - stage
    - prod
data:
  trafficFilters:
    rules:
    ...
    # Enable WAF protections (only works if WAF is enabled for your environment)
      - name: block-waf-flags
        when:
          reqProperty: tier
          matches: "author|publish"
        action:
          type: block
          wafFlags:
            - SANS
            - TORNODE
            - NOUA
            - SCANNER
            - USERAGENT
            - PRIVATEFILE
            - ABNORMALPATH
            - TRAVERSAL
            - NULLBYTE
            - BACKDOOR
            - LOG4J-JNDI
            - SQLI
            - XSS
            - CODEINJECTION
            - CMDEXE
            - NO-CONTENT-TYPE
            - UTF8
  • Eseguire il commit, il push e la distribuzione delle modifiche come indicato negli esempi precedenti.

  • Per simulare un attacco, utilizzare lo stesso comando Nikto di prima.

    code language-shell
    $ ./nikto.pl -useragent "AttackSimulationAgent (Demo/1.0)" -D V -Tuning 9 -ssl -h https://publish-pXXXX-eYYYY.adobeaemcloud.com/us/en.html
    
Analisi

Ripeti gli stessi passaggi descritti nell'esempio precedente.

Questa volta dovresti visualizzare le voci in Richieste bloccate e i valori corrispondenti nelle colonne IP client (cli_ip), host, URL, azione (waf_action) e nome regola (waf_match).

Richiesta bloccata WAF dashboard strumenti ELK

Inoltre, i pannelli Distribuzione flag WAF e Attacchi principali mostrano ulteriori dettagli.

Richiesta di flag di attacchi WAF dashboard strumento ELK

Richiesta attacchi principali WAF dashboard strumenti ELK

Analisi completa

Nelle sezioni analysis precedenti hai imparato ad analizzare i risultati di regole specifiche utilizzando lo strumento dashboard. Puoi esplorare ulteriormente l’analisi dei risultati utilizzando altri pannelli della dashboard, tra cui:

  • Richieste analizzate, contrassegnate e bloccate
  • Distribuzione dei flag WAF nel tempo
  • Attivazione delle regole del filtro del traffico nel tempo
  • Primi attacchi per ID flag WAF
  • Filtro del traffico attivato più alto
  • Primi 100 autori di attacchi per IP client, paese e agente utente

Analisi completa dashboard strumenti ELK

Analisi completa dashboard strumenti ELK

Passaggio successivo

Acquisisci familiarità con le best practice consigliate per ridurre il rischio di violazioni della sicurezza.

Risorse aggiuntive

Sintassi delle regole filtro traffico

Formato registro CDN

recommendation-more-help
4859a77c-7971-4ac9-8f5c-4260823c6f69