Regole del filtro del traffico, incluse le regole WAF traffic-filter-rules-including-waf-rules
Le regole del filtro del traffico possono essere utilizzate per bloccare o consentire le richieste a livello CDN, che potrebbe essere utile in scenari come:
- La limitazione dell’accesso a domini specifici al traffico interno dell’azienda, prima della pubblicazione di un nuovo sito
- Definizione dei limiti di frequenza per essere meno suscettibili ad attacchi DoS volumetrici
- La prevenzione del targeting delle tue pagine da parte di indirizzi IP dannosi
La maggior parte di queste regole del filtro del traffico è disponibile per tutta la clientela di Sites e Forms di AEM as a Cloud Service. Denominate regole di filtro del traffico standard, funzionano principalmente sulle proprietà e sulle intestazioni della richiesta, inclusi IP, nome host, percorso e agente utente. Le regole standard del filtro del traffico includono regole del limite di frequenza per evitare picchi di traffico.
Una sottocategoria delle regole del filtro del traffico richiede una licenza di sicurezza avanzata o una licenza di protezione WAF-DDoS. Queste potenti regole sono note come regole del filtro del traffico WAF (Web Application Firewall, Firewall per l’applicazione web) (o regole WAF, in breve) e hanno accesso ai flag WAF descritti di seguito in questo articolo.
Le regole di filtro del traffico possono essere implementate nei tipi di ambiente di sviluppo, di staging e di produzione tramite la pipeline di configurazione di Cloud Manager. Il file di configurazione può essere implementato negli ambienti di sviluppo rapido (RDE, Rapid Developement Environments) utilizzando gli strumenti della riga di comando.
Segui con un tutorial per sviluppare rapidamente competenze concrete su questa funzione.
Struttura di questo articolo how-organized
Questo articolo è suddiviso nelle sezioni seguenti:
- Panoramica sulla protezione del traffico: scopri in che modo sei protetto dal traffico dannoso.
- Processo consigliato per la configurazione delle regole: scopri una metodologia di alto livello per proteggere il sito web.
- Configurazione: scopri come impostare, configurare e distribuire le regole del filtro del traffico, incluse le regole WAF avanzate.
- Sintassi delle regole: scopri come dichiarare le regole del filtro del traffico nel file di configurazione
cdn.yaml
. Questa sezione include sia le regole del filtro del traffico disponibili per tutta la clientela di Sites e Forms, nonché la sottocategoria delle regole WAF per coloro che concedono in licenza tale funzionalità. - Esempi di regole: per orientarti meglio, consulta alcuni esempi di regole dichiarate.
- Regole dei limiti di frequenza: scopri come utilizzare le regole dei limiti di frequenza per proteggere il sito da attacchi con volumi elevati.
- Avvisi sulle regole del filtro del traffico: configura gli avvisi da notificare quando le regole vengono attivate.
- Avviso predefinito di picco nel traffico all’origine: ricevi una notifica quando si verifica un sovraccarico di traffico all’origine indicativo di un attacco DDoS.
- Registri CDN: scopri quali regole dichiarate e contrassegni WAF corrispondono al tuo traffico.
- Strumenti dashboard: analizza i registri CDN per trovare nuove regole per il filtro del traffico.
- Regole iniziali consigliate: una serie di regole con cui iniziare.
- Tutorial: conoscenza pratica della funzione, incluso l’utilizzo degli strumenti della dashboard per dichiarare le regole corrette.
Panoramica sulla protezione del traffico traffic-protection-overview
Nel panorama digitale attuale, il traffico dannoso è una minaccia sempre presente. Adobe è consapevole della gravità del rischio e offre diverse strategie per proteggere le applicazioni della clientela e mitigare gli attacchi quando si verificano.
La rete CDN gestita da Adobe assorbe gli attacchi DoS a livello di rete (livelli 3 e 4) ai margini della stessa, inclusi gli attacchi di tipo flood e di riflessione/amplificazione.
Per impostazione predefinita, Adobe adotta misure per evitare la riduzione delle prestazioni dovuto a picchi di traffico estremamente elevato oltre una determinata soglia. Se si verifica un attacco DoS che influisce sulla disponibilità del sito, i team operativi di Adobe vengono avvisati e adottano le misure necessarie per attenuare l’impatto.
La clientela può adottare misure proattive per mitigare gli attacchi a livello di applicazione (livello 7), configurando regole a vari livelli del flusso di distribuzione dei contenuti.
Ad esempio, al livello Apache, è possibile configurare il modulo Dispatcher o ModSecurity per limitare l’accesso a determinati contenuti.
Come descritto in questo articolo, le regole di filtro del traffico possono essere distribuite alla rete CDN gestita da Adobe, utilizzando le pipeline di configurazione di Cloud Manager. Oltre alle regole del filtro del traffico standard basate su proprietà come indirizzo IP, percorso e intestazioni, o alle regole basate sull’impostazione dei limiti di frequenza, è possibile anche concedere in licenza alla clientela una potente sottocategoria di regole del filtro del traffico, denominate regole WAF.
Processo consigliato suggested-process
Di seguito è riportato un processo end-to-end di alto livello consigliato per individuare le regole corrette per il filtro del traffico:
- Configura le pipeline di configurazione di produzione e non di produzione, come descritto nella sezione Configurazione.
- La clientela che dispone della licenza per le regole del filtro del traffico WAF deve abilitarle in Cloud Manager.
- Leggi e prova l’esercitazione per comprendere concretamente come utilizzare le regole del filtro del traffico, incluse le regole WAF, se disponi della licenza. Il tutorial illustra come distribuire le regole in un ambiente di sviluppo, simulare traffico dannoso, scaricare i Registri CDN e analizzarli negli strumenti della dashboard.
- Copia le regole iniziali consigliate in
cdn.yaml
e implementa la configurazione nell’ambiente di produzione con alcune regole in modalità registro. - Dopo aver raccolto alcuni dati di traffico, analizza i risultati utilizzando gli strumenti della dashboard per vedere se ci sono state corrispondenze. Cerca i falsi positivi e apporta le eventuali modifiche necessarie, in ultima analisi abilitando tutte le regole iniziali in modalità blocco.
- Se necessario, aggiungi regole personalizzate basate sull’analisi dei registri CDN, eseguendo per prima un test con traffico simulato in ambienti di sviluppo prima di distribuirlo negli ambienti di staging e produzione in modalità registro e in seguito in modalità blocco.
- Monitora costantemente il traffico e modifica le regole man mano che il panorama delle minacce evolve.
Configurazione setup
-
Crea un file
cdn.yaml
con un set di regole di filtro del traffico, incluse le regole WAF. Ad esempio:code language-none kind: "CDN" version: "1" metadata: envTypes: ["dev"] data: trafficFilters: rules: # Block simple path - name: block-path when: allOf: - reqProperty: tier matches: "author|publish" - reqProperty: path equals: '/block/me' action: block
Consulta Utilizzo delle pipeline di configurazione per una descrizione delle proprietà al di sopra del nodo
data
. Il valore della proprietàkind
deve essere impostato su CDN e la versione su1
. -
Se le regole WAF sono concesse in licenza, per gli scenari di programma nuovi ed esistenti, devi abilitare la funzione in Cloud Manager, come descritto di seguito.
-
Per configurare WAF su un nuovo programma, seleziona la casella di controllo Protezione WAF-DDOS nella scheda Sicurezza quando aggiungi un programma di produzione.
-
Per configurare WAF su un programma esistente: modifica il programma e nella scheda Sicurezza deseleziona o seleziona l’opzione WAF-DDOS in qualsiasi momento.
-
-
Crea una pipeline di configurazione in Cloud Manager, come descritto nell’articolo sulle pipeline di configurazione. La pipeline farà riferimento a una cartella
config
di primo livello con il filecdn.yaml
posizionato in un punto qualsiasi al di sotto, consulta Utilizzo delle pipeline di configurazione.
Sintassi delle regole di filtro del traffico rules-syntax
Puoi configurare le regole di filtro del traffico affinché corrispondano a pattern quali IP, agente utente, intestazioni di richiesta, nome host, geo e URL.
La clientela che dispone di una licenza per l’offerta Sicurezza avanzata o Protezione WAF-DDoS può anche configurare una categoria speciale di regole di filtro del traffico denominate regole del filtro del traffico WAF (o regole WAF, in breve) che fanno riferimento a uno o più flag WAF.
Di seguito è riportato un esempio di un set di regole per il filtro del traffico, che include anche una regola WAF.
kind: "CDN"
version: "1"
metadata:
envTypes: ["dev"]
data:
trafficFilters:
rules:
- name: "path-rule"
when:
allOf:
- { reqProperty: path, equals: /block-me }
- { reqProperty: tier, equals: publish }
action:
type: block
- name: "Enable-SQL-Injection-and-XSS-waf-rules-globally"
when: { reqProperty: path, like: "*" }
action:
type: block
wafFlags: [ SQLI, XSS]
Il formato delle regole per il filtro del traffico nel file cdn.yaml
è descritto di seguito. Trovi alcuni altri esempi in una sezione successiva, nonché in una sezione separata su Regole di limite di tasso.
string
Condition
{ <getter>: <value>, <predicate>: <value> }
Consulta Sintassi della struttura delle condizioni di seguito, che descrive i getter, i predicati e come combinare più condizioni.
Action
RateLimit
Di seguito è riportata una sezione separata che descrive la sintassi di rateLimit con alcuni esempi.
Struttura della condizione condition-structure
Una condizione può essere una condizione semplice o un gruppo di condizioni.
Condizione semplice
Una condizione semplice è composta da un getter e da un predicato.
{ <getter>: <value>, <predicate>: <value> }
Gruppo di condizioni
Un gruppo di condizioni è composto da più condizioni semplici e/o da condizioni di gruppo.
<allOf|anyOf>:
- { <getter>: <value>, <predicate>: <value> }
- { <getter>: <value>, <predicate>: <value> }
- <allOf|anyOf>:
- { <getter>: <value>, <predicate>: <value> }
array[Condition]
array[Condition]
Getter
string
Proprietà richiesta.
Una di:
path
: restituisce il percorso completo di un URL senza i parametri di query. (utilizzapathRaw
per la variante senza escape)url
: restituisce l’URL completo, inclusi i parametri di query. (utilizzaurlRaw
per la variante senza escape)queryString
: restituisce la parte di query di un URLmethod
: restituisce il metodo HTTP utilizzato nella richiesta.tier
: restituisce uno traauthor
,preview
opublish
.domain
: restituisce la proprietà del dominio (come definito nell’intestazioneHost
) in minuscoloclientIp
: restituisce l’IP del client.forwardedDomain
: restituisce il primo dominio definito nell’intestazioneX-Forwarded-Host
in minuscoloforwardedIp
: restituisce il primo IP nell’intestazioneX-Forwarded-For
.clientRegion
: restituisce il codice di suddivisione del Paese che identifica l’area geografica in cui si trova il client, come descritto in ISO 3166-2.clientCountry
: restituisce un codice di due lettere (simbolo indicatore regionale) che identifica il paese in cui si trova il client.clientContinent
: restituisce un codice a due lettere (AF, AN, AS, EU, NA, OC, SA) che identifica il continente in cui si trova il client.clientAsNumber
: restituisce il numero di Sistema autonomo associato all’IP del client.clientAsName
: restituisce il nome associato al numero di Sistema autonomo.
string
string
string
string
application/x-www-form-urlencoded
Predicato
string
string
string
string
string
string
array[string]
array[string]
boolean
Note
- La proprietà di richiesta
clientIp
può essere utilizzata solo con i seguenti predicati:equals
,doesNotEqual
,in
,notIn
.clientIp
può essere confrontata anche con intervalli IP quando si utilizzano i predicatiin
enotIn
. L’esempio seguente implementa una condizione per valutare se l’IP di un client rientra nell’intervallo IP 192.168.0.0/24 (quindi da 192.168.0.0 a 192.168.0.255):
when:
reqProperty: clientIp
in: [ "192.168.0.0/24" ]
- Adobe consiglia di utilizzare regex101 e Fastly Fiddle, quando si lavora con regex. Per ulteriori informazioni su come Fastly gestisce regex, consulta la documentazione di fastly: espressioni regolari in Fastly VCL.
Struttura delle azioni action-structure
Un’action
può essere una stringa che specifica l’azione (consenti, blocca o registra) o un oggetto composto sia dal tipo di azione (consenti, blocca o registra) che da opzioni quali wafFlags e/o Stato.
Tipi di azioni
La priorità delle azioni dipende dal loro tipo; nella tabella seguente, le azioni sono elencate in base al rispettivo ordine di esecuzione:
wafFlags
(facoltativo), alert
(facoltativo)Se si specifica un avviso, viene inviata una notifica al Centro azioni se la regola viene attivata 10 volte in una finestra temporale di 5 minuti. Una volta attivato un avviso per una regola particolare, non verrà attivato nuovamente fino al giorno successivo (UTC).
status, wafFlags
(facoltativo e reciprocamente esclusivo), alert
(facoltativo)Se si specifica un avviso, viene inviata una notifica al Centro azioni se la regola viene attivata 10 volte in una finestra temporale di 5 minuti. Una volta attivato un avviso per una regola particolare, non verrà attivato nuovamente fino al giorno successivo (UTC).
wafFlags
(facoltativo), alert
(facoltativo)Se si specifica un avviso, viene inviata una notifica al Centro azioni se la regola viene attivata 10 volte in una finestra temporale di 5 minuti. Una volta attivato un avviso per una regola particolare, non verrà attivato nuovamente fino al giorno successivo (UTC).
Elenco contrassegni WAF waf-flags-list
La proprietà wafFlags
, che può essere utilizzata nelle regole del filtro del traffico WAF su licenza, può fare riferimento a quanto segue:
Traffico dannoso
BAD-IP
in modo che una richiesta venga contrassegnata se corrisponde sia ad ATTACK che a BAD-IP. Consulta la sezione Regole WAF consigliate per informazioni su come utilizzare questo flag in modo efficace./bin/
CMDEXE
durante la disabilitazione del falso positivo su /bin
dovuta all’architettura di AEM.CVE-<CVE Number>
. Per ulteriori informazioni sulle CVE da cui Adobe ti proteggerà, contatta Adobe.Traffico sospetto
/foo/./bar
è normalizzato su /foo/bar
)SANS
e TORNODE
oppure in base a un precedente rilevamento di comportamenti dannosi da parte del WAFContent-Encoding: gzip
e il corpo POST non è testo normale..htaccess
Apache o un file di configurazione, che potrebbero causare la perdita di informazioni riservate.Traffico (varie)
Considerazioni considerations
-
Quando vengono create due regole in conflitto, le regole consentite avranno sempre la precedenza sulle regole del blocco. Ad esempio, se crei una regola per bloccare un percorso specifico e una per consentire un indirizzo IP specifico, le richieste provenienti da tale indirizzo IP saranno consentite sul percorso bloccato.
-
Se una regola viene rilevata e bloccata, il CDN risponde con un codice di restituzione
406
. -
I file di configurazione non devono contenere segreti, in quanto potrebbero essere letti da chiunque abbia accesso all’archivio Git.
-
Gli elenchi di IP consentiti definiti in Cloud Manager hanno la precedenza sulle regole dei filtri di traffico.
-
Le corrispondenze delle regole WAF vengono visualizzate solo nei registri CDN per CDN miss e pass, non per hit.
Esempi di regole examples
Di seguito sono riportati alcuni esempi di regole. Per esempi di regole del limite di frequenza, consulta la sezione sul limite di frequenza più in basso.
Esempio 1
Questa regola blocca le richieste provenienti da IP192.168.1.1:
kind: "CDN"
version: "1"
metadata:
envTypes: ["dev"]
data:
trafficFilters:
rules:
- name: "block-request-from-ip"
when: { reqProperty: clientIp, equals: "192.168.1.1" }
action:
type: block
Esempio 2
Questa regola blocca le richieste nel percorso /helloworld
al momento della pubblicazione con un agente utente contenente Chrome:
kind: "CDN"
version: "1"
metadata:
envTypes: ["dev"]
data:
trafficFilters:
rules:
- name: "block-request-from-chrome-on-path-helloworld-for-publish-tier"
when:
allOf:
- { reqProperty: path, equals: /helloworld }
- { reqProperty: tier, equals: publish }
- { reqHeader: user-agent, matches: '.*Chrome.*' }
action:
type: block
Esempio 3
Questa regola blocca le richieste che contengono il parametro di query foo
al momento della pubblicazione, ma consente ogni richiesta proveniente da IP 192.168.1.1:
kind: "CDN"
version: "1"
metadata:
envTypes: ["dev"]
data:
trafficFilters:
rules:
- name: "block-request-that-contains-query-parameter-foo"
when:
allOf:
- { queryParam: url-param, equals: foo }
- { reqProperty: tier, equals: publish }
action:
type: block
- name: "allow-all-requests-from-ip"
when: { reqProperty: clientIp, equals: 192.168.1.1 }
action:
type: allow
Esempio 4
Questa regola blocca le richieste al percorso /block-me
al momento della pubblicazione e blocca ogni richiesta che corrisponde a uno schema SQLI
o XSS
. Questo esempio include le regole di filtro del traffico WAF che fa riferimento ai contrassegni WAF SQLI
e XSS
e richiede pertanto una licenza separata.
kind: "CDN"
version: "1"
metadata:
envTypes: ["dev"]
data:
trafficFilters:
rules:
- name: "path-rule"
when:
allOf:
- { reqProperty: path, equals: /block-me }
- { reqProperty: tier, equals: publish }
action:
type: block
- name: "Enable-SQL-Injection-and-XSS-waf-rules-globally"
when: { reqProperty: path, like: "*" }
action:
type: block
wafFlags: [ SQLI, XSS]
Esempio 5
Questa regola blocca l’accesso ai Paesi OFAC:
kind: "CDN"
version: "1"
metadata:
envTypes: ["dev"]
data:
trafficFilters:
rules:
- name: block-ofac-countries
when:
allOf:
- reqProperty: tier
matches: "author|publish"
- reqProperty: clientCountry
in:
- SY
- BY
- MM
- KP
- IQ
- CD
- SD
- IR
- LR
- ZW
- CU
- CI
action: block
Regole del limite di frequenza
A volte è auspicabile bloccare il traffico, se supera una certa frequenza di richieste in arrivo, in base a una condizione specifica. L’impostazione di un valore per la proprietà rateLimit
limita la frequenza delle richieste che corrispondono alla condizione della regola.
Le regole del limite di tasso non possono fare riferimento ai contrassegni WAF. Sono disponibili per tutti i clienti Sites e Forms.
I limiti di tasso vengono calcolati per POP CDN. Ad esempio, supponiamo che i POP a Montreal, Miami e Dublino registrino tassi di traffico rispettivamente di 80, 90 e 120 richieste al secondo. La regola del limite di frequenza è impostata su 100. In tal caso, sarebbe limitato solo il traffico verso Dublino.
I limiti di frequenza vengono valutati in base al traffico che raggiunge il limite, la sorgente o il numero di errori.
Struttura rateLimit ratelimit-structure
Esempi ratelimiting-examples
Esempio 1
Questa regola blocca un client per 5 millisecondi quando supera la media di 60 richieste/secondo (per POP CDN) negli ultimi 10 sec:
kind: "CDN"
version: "1"
metadata:
envTypes: ["dev"]
data:
trafficFilters:
rules:
- name: limit-requests-client-ip
when:
reqProperty: tier
matches: "author|publish"
rateLimit:
limit: 60
window: 10
penalty: 300
count: all
groupBy:
- reqProperty: clientIp
action: block
Esempio 2
Blocca le richieste per 60 secondi nel percorso /critical/resource quando supera la media di 100 richieste di origine al secondo (per POP CDN) in un periodo di tempo di dieci secondi:
kind: "CDN"
version: "1"
metadata:
envTypes: ["dev"]
data:
trafficFilters:
rules:
- name: rate-limit-example
when:
allOf:
- { reqProperty: path, equals: /critical/resource }
- { reqProperty: tier, equals: publish }
action:
type: block
rateLimit: { limit: 100, window: 10, penalty: 60, count: fetches }
Regole CVE cve-rules
Se WAF è concesso in licenza, Adobe applica automaticamente regole di blocco per proteggerlo da molte Vulnerabilità ed esposizioni comuni (CVE, Common Vulnerabilities and Exposures) note; nuove CVE possono essere aggiunte subito dopo essere state rilevate. I clienti non devono configurare autonomamente le regole CVE.
Se una richiesta di traffico corrisponde a una CVE, verrà visualizzata nella voce di registro CDN corrispondente.
Contatta il supporto Adobe in caso di domande su una determinata CVE o se è presente una particolare regola CVE che la tua organizzazione vorrebbe disabilitare.
Avvisi delle regole di filtro del traffico traffic-filter-rules-alerts
Una regola può essere configurata per inviare una notifica al Centro azioni se viene attivata dieci volte in una finestra temporale di 5 minuti. Una regola di questo tipo avvisa quando si verificano determinati modelli di traffico in modo da poter adottare tutte le misure necessarie. Una volta attivato un avviso per una regola particolare, non verrà attivato nuovamente fino al giorno successivo (UTC).
Ulteriori informazioni sul Centro azioni, tra cui come configurare i profili di notifica richiesti per la ricezione di e-mail.
La proprietà dell’avviso può essere applicata al nodo dell’azione per tutti i tipi di azione (consenti, blocco, registro).
kind: "CDN"
version: "1"
metadata:
envTypes: ["dev"]
data:
trafficFilters:
rules:
- name: "path-rule"
when:
allOf:
- { reqProperty: path, equals: /block-me }
- { reqProperty: tier, equals: publish }
action:
type: block
alert: true
Avviso predefinito di picco nel traffico all’origine traffic-spike-at-origin-alert
Una notifica e-mail Centro azioni verrà inviata quando viene rilevata una quantità significativa di traffico inviato all’origine, dove una soglia elevata di richieste proviene dallo stesso indirizzo IP, suggerendo quindi un attacco DDoS.
Se questa soglia viene raggiunta, Adobe bloccherà il traffico da tale indirizzo IP. Tuttavia si consiglia di adottare misure aggiuntive per proteggere l’origine, tra cui la configurazione delle regole del filtro del traffico del limite di frequenza e bloccare i picchi a soglie più basse. Per una procedura guidata, consulta Tutorial sul blocco degli attacchi DoS e DDoS tramite le regole del traffico.
Questo avviso è attivato per impostazione predefinita, ma può essere disattivato utilizzando la proprietà defaultTrafficAlerts e impostandola su false. Una volta attivato, l’avviso non si riattiverà fino al giorno successivo (UTC).
kind: "CDN"
version: "1"
metadata:
envTypes: ["dev"]
data:
trafficFilters:
defaultTrafficAlerts: false
Registri CDN cdn-logs
AEM as a Cloud Service fornisce accesso ai registri CDN, utili per i casi d’uso tra cui l’ottimizzazione del rapporto hit della cache e la configurazione delle regole del filtro del traffico. I registri CDN vengono visualizzati nella finestra di dialogo di Cloud Manager Scarica registri durante la selezione del servizio di authoring o di pubblicazione.
I registri CDN possono subire un ritardo fino a 5 minuti.
La proprietà rules
descrive le regole del filtro del traffico corrispondenti e presenta il seguente pattern:
"rules": "match=<matching-customer-named-rules-that-are-matched>,waf=<matching-WAF-rules>,action=<action_type>"
Ad esempio:
"rules": "match=Block-Traffic-under-private-folder,Enable-SQL-injection-everywhere,waf="SQLI,SANS",action=block"
Le regole si comportano nel modo seguente:
- Il nome delle regola dichiarato dal cliente di tutte le regole corrispondenti è elencato nell’attributo
match
. - L’attributo
action
determina se le regole bloccano, consentono o registrano. - Se WAF è concesso in licenza e abilitato, l’attributo
waf
elenca tutti i contrassegni WAF rilevati (ad esempio SQLI). Ciò è vero indipendentemente dal fatto che i flag WAF vengano elencati in una qualsiasi regola. Questo serve a ottenere informazioni dettagliate su possibili nuove regole da dichiarare. - Se nessuna regola dichiarata dal cliente corrisponde e nessuna regola waf corrisponde, la proprietà
rules
è vuota.
Come indicato in precedenza, le corrispondenze delle regole WAF vengono visualizzate solo nei registri CDN per CDN miss e pass, non per hit.
L’esempio seguente mostra un esempio cdn.yaml
e due voci di registro CDN:
kind: "CDN"
version: "1"
metadata:
envTypes: ["dev"]
data:
trafficFilters:
rules:
- name: "path-rule"
when: { reqProperty: path, equals: /block-me }
action: block
- name: "Enable-SQL-Injection-and-XSS-waf-rules-globally"
when: { reqProperty: path, like: "*" }
action:
type: block
wafFlags: [ SQLI, XSS ]
{
"timestamp": "2023-05-26T09:20:01+0000",
"ttfb": 19,
"cli_ip": "147.160.230.112",
"cli_country": "CH",
"rid": "974e67f6",
"req_ua": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0.3 Safari/605.1.15",
"host": "example.com",
"url": "/block-me",
"method": "GET",
"res_ctype": "",
"cache": "PASS",
"status": 406,
"res_age": 0,
"pop": "PAR",
"rules": "match=path-rule,action=blocked"
}
{
"timestamp": "2023-05-26T09:20:01+0000",
"ttfb": 19,
"cli_ip": "147.160.230.112",
"cli_country": "CH",
"req_ua": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0.3 Safari/605.1.15",
"rid": "974e67f6",
"host": "example.com",
"url": "/?sqli=%27%29%20UNION%20ALL%20SELECT%20NULL%2CNULL%2CNULL%2CNULL%2CNULL%2CNULL%2CNULL%2CNULL%2CNULL%2CNULL--%20fAPK",
"method": "GET",
"res_ctype": "image/png",
"cache": "PASS",
"status": 406,
"res_age": 0,
"pop": "PAR",
"rules": "match=Enable-SQL-Injection-and-XSS-waf-rules-globally,waf=SQLI,action=blocked"
}
Formato registro cdn-log-format
Di seguito è riportato un elenco dei nomi dei campi utilizzati nei registri CDN, con una breve descrizione.
Indica anche se la corrispondenza ha prodotto un blocco.
Ad esempio, "
match=Enable-SQL-Injection-and-XSS-waf-rules-globally,waf=SQLI,action=blocked
"Vuoto se non corrisponde alcuna regola.
Strumenti dashboard dashboard-tooling
Adobe fornisce un meccanismo per scaricare gli strumenti della dashboard sul computer per acquisire i registri CDN scaricati tramite Cloud Manager. Con questo strumento, puoi analizzare il traffico per scoprire le regole del filtro del traffico da dichiarare, incluse le regole WAF.
Gli strumenti della dashboard possono essere clonati direttamente dall’archivio GitHub AEMCS-CDN-Log-Analysis-Tooling.
È disponibile un tutorial con istruzioni pratiche su come utilizzare gli strumenti della dashboard.
Regole iniziali consigliate recommended-starter-rules
Adobe consiglia di iniziare con le regole del filtro del traffico riportate di seguito e quindi di perfezionarle nel tempo. Le regole standard sono disponibili con una licenza Sites o Forms, mentre le regole WAF richiedono una licenza Sicurezza avanzata o Protezione WAF-DDoS.
Regole standard consigliate recommended-nonwaf-starter-rules
Inizia con queste regole:
- limite di frequenza (modalità registro):
- registra quando il traffico da un determinato IP supera un limite di frequenza. Passa alla modalità di blocco dopo aver verificato che non vengono ricevuti avvisi; se gli avvisi fossero stati ricevuti, avrebbe indicato che il valore limite era troppo basso.
- paesi specifici (modalità blocco):
- blocca il traffico da alcuni Paesi (modifica i codici paese in base ai requisiti aziendali)
kind: "CDN"
version: "1"
metadata:
envTypes: ["dev", "stage", "prod"]
data:
trafficFilters:
rules:
# Block client for 5m when it exceeds an average of 100 req/sec to origin on a time window of 10sec
- name: limit-origin-requests-client-ip
when:
reqProperty: tier
equals: 'publish'
rateLimit:
limit: 100
window: 10
count: fetches
penalty: 300
groupBy:
- reqProperty: clientIp
action: log
# Block client for 5m when it exceeds an average of 500 req/sec on a time window of 10sec
- name: limit-requests-client-ip
when:
reqProperty: tier
equals: 'publish'
rateLimit:
limit: 500
window: 10
count: all
penalty: 300
groupBy:
- reqProperty: clientIp
action: log
alert: true
# Block requests coming from OFAC countries
- name: ofac-countries
when:
allOf:
- { reqProperty: tier, in: ["author", "publish"] }
- reqProperty: clientCountry
in:
- SY
- BY
- MM
- KP
- IQ
- CD
- SD
- IR
- LR
- ZW
- CU
- CI
action: block
Regole WAF consigliate recommended-waf-starter-rules
Aggiungi le seguenti regole alla configurazione esistente:
-
Flag ATTACK-FROM-BAD-IP (modalità blocco):
- Blocca immediatamente il traffico che corrisponde a pattern sospetti (inclusi diversi nell’elenco dei flag WAF) e che proviene da indirizzi IP noti per essere dannosi.
- Il flag ATTACK-FROM-BAD-IP soddisfa intrinsecamente entrambe le condizioni (corrispondenza pattern e IP dannosi noti), riducendo al minimo il rischio di falsi positivi. Pertanto, puoi applicare questa regola in modalità di blocco in modo sicuro e immediato.
-
Flag ATTACK (modalità registro):
- Inizialmente registra (anziché bloccare) il traffico che corrisponde a pattern sospetti ma non proviene da indirizzi IP dannosi noti. Questo approccio prudente di registrazione, anziché di blocco, consente di evitare il blocco involontario del traffico legittimo (falsi positivi).
- Dopo aver distribuito questa regola, analizza attentamente i registri CDN per verificare che le richieste legittime non vengano contrassegnate in modo errato. Se hai la certezza che non è interessato alcun traffico legittimo, passa alla modalità di blocco.
# blocks likely attack traffic, which also comes from suspected IPs
- name: attacks-from-bad-ips-globally
when:
reqProperty: tier
in: ["author", "publish"]
action:
type: block
wafFlags:
- ATTACK-FROM-BAD-IP
# log likely attack traffic, and later switch to block mode if false positives aren't observed
- name: attacks-from-any-ips-globally
when:
reqProperty: tier
in: ["author", "publish"]
action:
type: log
wafFlags:
- ATTACK
Regole precedenti WAF consigliate previous-waf-starter-rules
Prima di luglio 2025, Adobe consigliava le regole WAF elencate di seguito, ancora valide ed efficaci nella difesa contro il traffico dannoso. Per considerazioni sulla migrazione alle nuove regole consigliate, visualizza il tutorial.
code language-none |
---|
|
Tutorial tutorial
Esercitati con una serie di tutorial per acquisire conoscenze pratiche e generali ed esperienza sulle regole del filtro del traffico, incluse le regole WAF.
I tutorial includono:
- Una panoramica delle regole del filtro del traffico standard e WAF
- Configurazione delle regole del filtro del traffico standard e WAF consigliate per bloccare attacchi, inclusi Denial of Service (DoS, attacco di negazione del servizio) e altre minacce
- Implementazione delle regole tramite la pipeline di configurazione di Cloud Manager
- Test delle regole tramite strumenti per simulare il traffico dannoso
- Analisi dei risultati mediante lo strumento di analisi dei registri
- Best practice