Tuning delle regole di protezione

Utilizzare Web Application Firewall per il tuning delle regole di protezione.

Queste informazioni di base sul tuning WAF illustrano le nozioni di base relative al tuning delle regole, all'ispezione dei log e all'impostazione delle esclusioni delle regole. Il tuning di un criterio WAF può risultare utile per i motivi riportati di seguito.

Riduce la possibilità di bloccare una richiesta legittima.
Protegge dagli attacchi standard alle applicazioni Web.
Protegge da specifici attacchi alle applicazioni Web.
Riduce la quantità di scansione, il che porta a prestazioni migliori.

La tabella seguente mostra i termini e le definizioni delle regole di produzione.

Definizioni regole di protezione
Periodo	Definizione
Tuning	Processo in cui un ingegnere o un analista modifica le regole e le azioni di protezione per consentire all'Application Server di essere protetto ma rimanere funzionale. Esiste un equilibrio tra il blocco dell'Application Server e la possibilità per l'Application Server di eseguire le proprie attività. Il tuning ottimale richiede una conoscenza approfondita dell'Application Server protetto e delle regole di protezione disponibili per proteggere tale Application Server.
Falso positivo	Un falso positivo si verifica quando una regola di protezione viene confrontata con una transazione HTTP e la transazione HTTP è una transazione legittima (non dannosa).
A esclusione	Modifica a una regola di protezione che consente di ignorare il nome valore o valore di un cookie o di un argomento HTTP.
Oracle Recommendation Engine (ORE)	ORE consente di ottimizzare il profilo di sicurezza WAF consentendo di abilitare tutte le regole che non vengono attivate durante un periodo di suggerimento iniziale.

Panoramica delle regole di protezione WAF

WAF protegge le tue applicazioni Web dalle minacce. WAF è basato sul cloud e supporta oltre 500 set di regole e set di regole per l'Open Web Application Security Project (OWASP). Utilizzare queste regole per proteggere le applicazioni Web critiche da attacchi informatici dannosi. Queste regole vengono confrontate con le richieste in entrata per determinare se la richiesta contiene un payload di attacco. Se determina che la richiesta è un attacco, WAF blocca o invia un avviso a tale richiesta. Questi attacchi sono vari e includono minacce come SQL injection, cross-site scripting e HTML injection, che possono essere rilevate e bloccate dai set di regole WAF.

La protezione WAF è un toolkit progettato per il monitoraggio, la registrazione e il controllo degli accessi delle applicazioni Web in tempo reale. Il toolkit ti consente di decidere come sfruttare al meglio tutte le regole di protezione disponibili. Questa flessibilità è un elemento fondamentale delle regole di protezione WAF, poiché spingiamo costantemente gli aggiornamenti per aumentare l'ambito di sicurezza delle nostre regole.

Nota

Le regole di protezione WAF aggiungono cicli CPU aggiuntivi a ogni transazione. È pertanto consigliabile abilitare solo le regole progettate per la topologia dell'applicazione Web.

Per identificare e difendere le applicazioni Web dagli attacchi, le regole di protezione WAF eseguono controlli su qualsiasi richiesta al server Web e tutte le risposte associate dal server rispetto al set di regole. Al termine dei controlli, la richiesta HTTP viene inviata al sito Web per recuperare il contenuto pertinente. Se invece i controlli non riescono, vengono avviate le azioni predefinite appropriate.

Di seguito sono riportati i principi di base delle regole di protezione WAF.

Passività: Decidi quali regole sono necessarie, quindi hai il pieno controllo.
Flessibilità: le regole di protezione WAF sono state create da un esperto di sicurezza che ha fornito oltre 250 regole e la capacità di introdurre regole di protezione personalizzate.
Qualità non quantità: le regole di protezione WAF sono un modulo dedicato progettato per ispezionare il traffico HTTP che funziona con le altre funzioni WAF (ad esempio, controllo dell'accesso e gestione dei bot).
Prevedibilità: avere il pieno controllo delle regole di protezione WAF ti consente di controllare i risultati previsti. È possibile definire e ottimizzare le regole di protezione e lasciare l'impostazione incustodita, sapendo che continua a funzionare come è stata configurata.

Onboarding e tuning iniziale

In primo luogo, è necessario avere alcune conoscenze sull'applicazione Web per il processo di tuning. In caso contrario, è possibile abilitare regole specifiche di Linux per il server Windows o l'origine e le regole eseguono la scansione inutilmente del traffico causando un deterioramento delle prestazioni. L'ORE ti aiuta fornendo un insieme solido e sicuro di regole di protezione. Il periodo del suggerimento è un'impostazione configurabile con un valore predefinito di 10 giorni. Si consiglia di aumentare questo valore a 15 giorni per ottenere un ampio campione di log per il traffico normale sull'applicazione Web. Circa ventiquattro ore dopo la creazione del criterio WAF, i suggerimenti delle regole di protezione verranno visualizzati nella scheda Suggerimenti. I suggerimenti sono regole scelte dagli esperti WAF per coprire la Top Ten OWASP. Queste regole consigliate sono state selezionate perché in genere producono il minor numero di falsi positivi e forniscono comunque una buona protezione.

Modifica del periodo di raccomandazione e accettazione dei suggerimenti

Attenendosi alla procedura riportata di seguito, è possibile abilitare le regole consigliate in modalità di rilevamento. Dopo che le regole sono in modalità di rilevamento, si consiglia di attendere 15 giorni prima di modificarle in modalità blocco.

Nota

Durante il periodo di valutazione, tutte le regole sono in modalità di rilevamento. Modalità di rilevamento significa che non ci sarà alcun blocco da parte delle regole di protezione. Si consiglia di eseguire test di accettazione degli utenti e uso normale dell'applicazione per facilitare il processo di tuning generando i log. Rivedere i log e verificare la presenza di falsi positivi mentre le regole sono in modalità di rilevamento. Controllando i log che attivano le regole di protezione, ti dà un'idea di quale traffico causerebbe un blocco quando le regole vengono attivate in modalità blocco. Durante il periodo di valutazione, la domanda dovrebbe ricevere il più vicino possibile al traffico normale o simile alla produzione. Il traffico normale mostra quali regole vengono attivate tramite i log e i falsi positivi possono essere filtrati.

Per modificare il periodo dei suggerimenti

Aprire il menu di navigazione e selezionare Identità e sicurezza. In Web Application Firewall, selezionare Criteri.
Fare clic sul nome del criterio WAF per il quale si desidera configurare le impostazioni delle regole. Viene visualizzata la panoramica dei criteri WAF.
Fare clic su Regole di protezione.
Fare clic sulla scheda Impostazioni.
Fare clic su Modifica impostazioni regola.
Nella finestra di dialogo Modifica impostazioni regola, il Periodo suggerimenti è stato aumentato da 10 a 15 giorni.
Fare clic su Salva modifiche.

Per accettare le raccomandazioni

Aprire il menu di navigazione e selezionare Identità e sicurezza. In Web Application Firewall, selezionare Criteri.
Fare clic sul nome del criterio WAF per il quale si desidera configurare le impostazioni delle regole. Viene visualizzata la panoramica dei criteri WAF.
Fare clic su Regole di protezione.
Fare clic sulla scheda Suggerimenti.
Fare clic su Accetta suggerimenti.
Fare clic su Modifiche non pubblicate.
Fare clic su Pubblica tutto.
Nella finestra di dialogo Pubblica le modifiche fare clic su Pubblica tutto.

Utilizzo dell'interfaccia API per eseguire query su log specifici

L'interfaccia API fornisce il maggior numero di opzioni per filtrare le regole. Di seguito sono riportati alcuni esempi di utilizzo dell'interfaccia CLI per filtrare i log.

Per filtrare i log in base all'ID regola di protezione:

oci waas waf-log list --waas-policy-id <WASS Policy OCID> --protection-rule-key <protection rule id number>

Per filtrare i log in base al tipo di regola (ad esempio, i tipi di regole di protezione o di accesso):

oci waas waf-log list --waas-policy-id <WAAS Policy OCID> --log-type PROTECTION_RULES
oci waas waf-log list --waas-policy-id <WAAS Policy OCID> --log-type ACCESS

Per filtrare i log in base all'URL della richiesta:

oci waas waf-log list --waas-policy-id <WAAS Policy OCID> --request-url <request url>

Impostazione di Logging Analytics

Logging Analytics consente di limitare le regole di protezione che richiedono attenzione. Utilizzare le informazioni riportate di seguito per impostare il servizio Logging Analytics con WAF. Per ulteriori informazioni, vedere Security Insights for your web apps with OMC Log Analytics.

Creazione di esclusioni nelle regole di protezione

L'analisi dei log è una parte fondamentale del processo di tuning. I log mostrano a quale regola è stata trovata una corrispondenza e a quale parte della transazione HTTP è stata trovata una corrispondenza. Fare riferimento alla tabella seguente per esempi di log e come utilizzarli per creare un'esclusione.

L'oggetto protectionRuleDetections in WafLog fornisce una mappa delle chiavi delle regole di protezione per rilevare i dettagli del messaggio. La tabella seguente mostra quattro possibili esclusioni che è possibile impostare per una regola di protezione.


Valore di log	Valore esclusione	descrizione;
ARGS	Parametri di richiesta	Utilizzato per i valori di un argomento specifico.
ARGS_NAMES	nomi dei parametri delle richieste	Utilizzato per il nome dell'argomento.
REQUEST_COOKIES	Valori dei cookie della richiesta	Utilizzato per i valori di un cookie specifico.
REQUEST_COOKIES_NAMES	Nomi dei cookie della richiesta	Utilizzato per il nome del cookie.

Esclusioni di esempio con log

Nella sezione seguente vengono forniti esempi di log raw ed esempi del valore di esclusione da utilizzare per ogni regola.

ID regola 9411000 - ARGS
In questo esempio, è stato trovato Dati corrispondenti nell'argomento ARGS:foo. L'esclusione riguarda la regola con ID 9411000. L'esclusione da creare è per Parametri richiesta con il valore foo.
```
"protection-rule-detections": {
 "9411000": {
  "Message": "detected XSS using libinjection.",
  "Message details": "Matched Data: found within ARGS:foo: <script>xss"
},
```

Regola con ID 9411000 - ARGS_NAMES
In questo esempio, l'argomento Dati corrispondenti è stato trovato nell'argomento ARGS_NAMES. L'esclusione riguarda la regola con ID 9411000. L'esclusione da creare è per Nomi parametri richiesta con il valore <script>xss.
```
"protection-rule-detections": {
 "9411000": {
  "Message": "detected XSS using libinjection.",
  "Message details": "Matched Data: found within ARGS_NAMES:<script>xss: <script>xss"
},
```

ID regola 9411100

In questo esempio, l'argomento Dati corrispondenti è stato trovato nell'argomento REQUEST_COOKIES:a. L'esclusione riguarda la regola con ID 9411100. L'esclusione da creare è per Richiedi valori cookie con il valore a.

"protection-rule-detections": {
 "9411100": {
  "Message": "Pattern match \"(?i)([<\\xef\\xbc\\x9c]script[^>\\xef\\xbc\\x9e]*[>\\xef\\xbc\\x9e][\\\\s\\\\S]*?)\" at REQUEST_COOKIES:a.",
  "Message details": "Matched Data: <script> found within REQUEST_COOKIES:a: <script>xss"
},

Per creare esclusioni

Aprire il menu di navigazione e selezionare Identità e sicurezza. In Web Application Firewall, selezionare Criteri.
Fare clic sul nome del criterio WAF per il quale si desidera configurare le impostazioni delle regole. Viene visualizzata la panoramica dei criteri WAF.
Fare clic su Regole di protezione.
Fare clic sulla scheda Regole.
Trovare la regola di protezione a cui si desidera applicare un'azione.
Fare clic sul menu Azioni () e selezionare Esclusioni. Includere le esclusioni utilizzando le informazioni ottenute dalla sezione Esclusioni campione con log precedente.
Fare clic su Salva modifiche.
Fare clic su Modifiche non pubblicate.
Fare clic su Pubblica tutto.
Nella finestra di dialogo Pubblica le modifiche fare clic su Pubblica tutto.

Ulteriori informazioni sulle norme di protezione

Regole di protezione individuali rispetto a regole di protezione collaborativa

Per limitare i falsi positivi, esistono regole di protezione speciali contrassegnate come "collaborative". Questi gruppi di regole funzionano in modo diverso rispetto al resto delle regole di protezione poiché utilizzano un sistema di punteggio e soglia per valutare il traffico. Le singole regole funzionano abbinando gli elementi della transazione HTTP alla firma della regola. Se viene trovata una corrispondenza, la regola esegue la relativa azione, ad esempio il rilevamento o il blocco. Ciascuna delle regole di protezione collaborativa utilizza un gruppo di regole individuali. Le regole di protezione collaborativa richiedono più corrispondenze di elementi della transazione HTTP rispetto a singole regole per eseguire la relativa azione, ad esempio il rilevamento o il blocco. Affinché una regola collaborativa possa eseguire la relativa azione, almeno tre elementi della transazione HTTP devono corrispondere alle singole regole del gruppo collaborativo. Dopo essere stata aggiunta all'interno del gruppo di regole di protezione collaborativa, l'esclusione verrà applicata a tutte le regole al suo interno. Di seguito è riportato un elenco degli ID delle regole di protezione collaborativa.

ID regole di protezione collaborativa

9300000 - Gruppo collaborativo inclusione file locale (LFI) - Categorie filtro LFI
9320000 - Gruppo collaborativo RCE (Remote Code Execution) - UNIX RCE Filter Categories
9320001 - Gruppo collaborativo RCE (Remote Code Execution) - Categorie filtro RCE Windows
9330000 - PHP Injection Attacks Collaborative Group - PHP Filtri Categorie
9410000 - Gruppo collaborativo Cross-Site Scripting (XSS) - Filtri XSS Categorie
9420000 - Iniezione SQL (SQLi) Gruppo collaborativo - SQLi Filtri Categorie

ID regole ispezione corpo richiesta

Le seguenti regole richiedono l'abilitazione dell'ispezione del corpo della risposta. Ricorda che l'ispezione del corpo della risposta ritarda la transazione, poiché analizza tutte le informazioni al suo interno. Abilitare solo le regole richieste.

970014, 90005, 120133, 970008, 970016, 981080, 920020, 920006, 920008, 920010, 920012, 920014, 920016, 920018, 90017, 90018, 90020, 90019, 90014, 90021, 90015, 90016, 920021, 920022, 920023, 90024, 90022, 90023, 970013, 970011, 981177, 981000, 981001, 981003, 970018, 970004, 970904, 970010, 970118, 2100090, 970012, 970903, 970009, 970015, 970902, 981005, 981004, 981007, 981006, 970003, 970002, 950110, 950921, 950922, 90002, 90025, 970021, 970007

Nessuna regola di eccezione

Le regole riportate di seguito creano valori di log raw diversi da ARGS, ARGS_NAMES, REQUEST_COOKIE e REQUEST_COOKIE_VALUE. Per queste regole non esistono esclusioni, poiché le regole si basano se l'elemento è presente o meno. Ad esempio, se è presente l'intestazione content-type, l'unica opzione per escludere questa regola è aprire una richiesta di servizio con My Oracle Support per richiedere una regola WAF personalizzata che esclude una delle seguenti regole.

960020, 960015, 960009, 950103

Queste regole vengono individuate facilmente, poiché i valori di log sono REQUEST_URI, REQUEST_PROTOCOL e REQUEST_HEADERS.

Altre regole di protezione

Di seguito è riportato un elenco di regole di protezione "rumorose", con alcune descrizioni e suggerimenti che consentono di comprendere la corrispondenza della regola. Impossibile applicare le esclusioni ad alcune di queste regole.


ID regola	Nome regola	Note
981318	Fine cessazione/dichiarazione stringa	Questa regola è importante, in quanto avvisa per qualsiasi carattere di escape rilevato all'interno di qualsiasi campo di input e queryString [ARGS] o cookie. Esaminare le convalide eseguite sul lato dell'applicazione e assicurarsi che consenta solo i caratteri di input appropriati, ad esempio lettere e numeri. Se è necessario un altro valore di input, è possibile applicare un'esclusione alla regola in WAF e lasciarla passare.
960015 960021	Intestazione Accept mancante	Anche quando le richieste senza intestazioni di accettazione non significano una violazione del protocollo HTTP, le richieste senza intestazioni di accettazione spesso non sono richieste autentiche. La regola potrebbe ricevere avvisi per richieste API o applicazioni personalizzate. Per evitare la scansione di API o richieste di applicazioni personalizzate, raccogliere una lista delle applicazioni note che inviano traffico e richiedono regole personalizzate. Per ulteriori informazioni, vedere RFC 7231, sezione 5.3.2.
960007 960008	Intestazione host mancante	Come descritto in RFC 7230, sezione-5.4 "Un server deve rispondere con un codice di stato 400 (Richiesta non valida) a qualsiasi messaggio di richiesta HTTP/1.1 che manca di un campo di intestazione host e a qualsiasi messaggio di richiesta che contiene più di un campo di intestazione host o un campo di intestazione host con un valore di campo non valido." Si tratta di un metodo di protezione essenziale e allo stesso tempo garantisce che i server WAF identifichino correttamente il criterio WAF a cui è destinata la richiesta. Poiché WAF richiede un'intestazione host per passare il traffico all'origine corretta, questa regola potrebbe causare un elevato tasso di falsi positivi.
960009 960006	Intestazione User-Agent mancante	Questa regola impedisce agli utenti non identificati di accedere all'applicazione Web. User-Agent è una delle intestazioni di richiesta definite in varie RFC che fornisce informazioni sull'utente. Anche quando una richiesta contiene un user agent, non implica che provenga da un vero essere umano. Questa regola funziona come un primo livello di mitigazione per gli attacchi "fittizi" che provengono da possibili bot o applicazioni "non conformi alla RFC". Nota: alcune API potrebbero non includere l'intestazione User-Agent. Se sono previste richieste API, assicurarsi di aggiungere l'indirizzo IP API alla lista di inclusione o di disporre di una regola WAF personalizzata che escluda l'ispezione di questo traffico. Per ulteriori informazioni, vedere RFC 7231, sezione 5.5.3. Questa regola è un indicatore di traffico errato o dannoso, ma è possibile che le applicazioni legittime non abbiano un agente utente. Chiedere ai proprietari dell'applicazione di utilizzare User-Agents, se applicabile.
960011	Convalida richieste GET/HEAD	Come descritto in RFC 7231, sezione-4.3.1 e sezione-4.3.2, HEAD e GET sono metodi HTTP destinati a recuperare informazioni dal server di origine. Anche quando non è vietato dalla RFC, l'invio di corpo o payload attraverso questi tipi di metodi non è una pratica comune. Di solito è causato da applicazioni impropriamente definite che non seguono le migliori pratiche della RFC e può essere utilizzato da utenti malintenzionati come tecnica di bypass. È anche definito in RFC 2616, sezione 4.3 "se il metodo di richiesta non include la semantica definita per un entità-corpo, allora il messaggio-corpo dovrebbe essere ignorato quando si gestisce la richiesta."
960904	Intestazione Content-Type mancante	Come definito in RFC 2616, sezione 7.2.1, "Qualsiasi messaggio HTTP/1.1 contenente un corpo entità deve includere un campo di intestazione Content-Type che definisce il tipo di supporto di quel corpo." Se questa best practice non viene seguita, potrebbe portare ad attacchi di sniffing di tipo MIME.
960032	Metodo HTTP consentito	I metodi HTTP consentiti predefiniti sono GET, HEAD, POST e OPTIONS. OPTIONS è noto come metodo insicuro perché è altamente utilizzato dagli aggressori per raccogliere informazioni dal server di origine. Questo metodo è richiesto anche da alcune applicazioni per funzionare correttamente. Se questo metodo non è necessario, creare una richiesta di servizio con My Oracle Support per disabilitarla. È inoltre possibile aggiungere altri metodi in base alle esigenze con una richiesta di servizio.
960335	Quantità massima di argomenti	RFC non applica il numero di argomenti che una richiesta deve avere, ma l'utilizzo di molti argomenti potrebbe essere un metodo utilizzato da utenti malintenzionati che tentano di overflow di un'applicazione Web. Per proteggersi da questi tipi di attacchi, si consiglia di limitare il numero massimo di ARG consentiti per ogni richiesta. Il valore predefinito per il server di amministrazione è 255.
960208	Lunghezza massima di un argomento	RFC non applica la lunghezza per argomento che una richiesta deve avere, ma l'utilizzo di una lunghezza di argomento di grandi dimensioni potrebbe essere un metodo utilizzato da utenti malintenzionati che tentano di eseguire il overflow di un'applicazione Web. Per proteggersi da questi tipi di attacchi, si consiglia di limitare la lunghezza massima degli ARG consentiti per richiesta. Il valore predefinito è 400 minuti.
960341	Lunghezza totale argomenti massima	RFC non applica la dimensione totale (combinata) degli argomenti che una richiesta deve avere, ma valori combinati di grandi dimensioni potrebbero essere un metodo utilizzato da utenti malintenzionati che tentano di eseguire il overflow di un'applicazione Web. Per proteggersi da questi tipi di attacchi, si consiglia di limitare il valore massimo di argomenti combinati consentito per ogni richiesta. Il valore predefinito per il server di amministrazione è 64000.
92035032	Intestazione host è indirizzo IP	In genere questa regola non viene attivata poiché WAF richiede un'intestazione host per inviare il traffico all'origine.
941120	Tentativo di cross-site scripting (XSS): filtri XSS - categoria 2	L'elaborazione di questa regola richiede molto tempo se è presente un payload di grandi dimensioni. Ad esempio, un payload con 64.005 byte richiede circa 32 secondi per essere elaborato.

Documentazione di Oracle Cloud Infrastructure