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. -
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 utilizzareasmith/asmith
come nome utente e password.
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.
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 cartellalogs/dev
del progetto di strumento dashboard elastico.{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'ambientedev
. -
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.
-
-
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.
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).
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
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.
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).
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.
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
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.
I pannelli Distribuzione flag WAF e Attacchi principali mostrano ulteriori dettagli che possono essere utilizzati per ottimizzare ulteriormente la configurazione della regola.
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 regolablock-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).
Inoltre, i pannelli Distribuzione flag WAF e Attacchi principali mostrano ulteriori dettagli.
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
Passaggio successivo
Acquisisci familiarità con le best practice consigliate per ridurre il rischio di violazioni della sicurezza.
Risorse aggiuntive
Sintassi delle regole filtro traffico