Home Blogs Sintonizzazione WAF semplificata
Applications

About The Author

Outline

Le piccole e le nuove imprese si trovano ad affrontare una sfida cruciale per la sicurezza. Hanno bisogno di una soluzione di sicurezza sofisticata per mantenere al sicuro le loro applicazioni Web riducendo al minimo i costi di assunzione di specialisti di sicurezza dedicati o di servizi gestiti di terze parti. Con i nuovi vettori di attacco sempre più diffusi, la sicurezza delle applicazioni web sta diventando sempre più cruciale e impegnativa.

L’Edgecast, ora Edgio, WAF è la soluzione. Offre una soluzione robusta e sofisticata che semplifica la gestione. I dashboard in tempo reale e la distribuzione dei log forniscono visibilità aggiornata, consentendo agli amministratori di identificare rapidamente le minacce e di agire.

In questo blog, ci concentreremo su come le aziende possono identificare ed eliminare i falsi positivi e creare soluzioni personalizzate per la loro applicazione web senza incorrere in costi di supporto aggiuntivi.

Se non conosci questo spazio e non hai ancora lavorato con Edgio WAF, guarda questo breve tutorial per capire l’interfaccia utente e come funziona.

Se hai già un account, sentiti libero di fare questo esercizio con me.

1. Iniziamo andando alla dashboard in tempo reale e filtrando gli eventi WAF in base al tempo. Questo è il periodo di tempo per il quale si desidera analizzare il traffico Web. (Nota: Se hai già eseguito alcune regolazioni delle regole prima, assicurati di scegliere un intervallo di tempo dopo l’ultima regolazione).

Figura 1: Eventi WAF verificatisi nelle ultime 6 ore.

2. Osservare i 10 ID regola principali attivati da questo traffico. Gli ID regola sono un ottimo modo per filtrare ulteriormente il traffico e osservare i payload per vari eventi WAF. Detto questo, iniziare a filtrare il traffico in base a questi ID regola uno per uno per un’ulteriore analisi.

Figura 2: Le prime 10 regole che sono state create dagli eventi WAF.

3. Successivamente, esaminare i valori del carico utile che hanno attivato questa regola osservando il campo corrispondente.

Figura 3: Valori del carico utile nella colonna corrispondente.

4. Analizzare i valori del payload per identificare se sono dannosi. Non sei sicuro di come siano? Di seguito sono riportati alcuni potenziali valori dannosi che potrebbero trovare nel payload.

  • Traversale del percorso: http://some_site.com.br/../../../../some dir/parte file¹ http://testsite.com/get.asp?f=/etc/passwd²‍
  • Vulnerabilità LFI: Un utente malintenzionato sta tentando di accedere a file sensibili sul server, come .ini. Per impostazione predefinita, Edgecast WAF blocca questa e molte altre estensioni critiche del filesystem.³‍
  • Cross-Site Scripting: http://testsite.test/<script>Alert(“TEST”);</script>⁴ <img src=”http://url.to.file.which/not.exist” onerror=alert(document.cookie);>⁵‍
  • SQL injection: SELEZIONARE * DAGLI elementi DOVE “a”=”a”;⁶ SELEZIONARE 1;⁷‍
  • Esecuzione di codice in modalità remota: eval(“\$$user = ‘$regdate’);⁸‍
  • Attacchi basati sul tempo: Select 1 and sleep(2);⁹ Select BENCHMARK(2000000,MD5(«A»));¹⁰

5. Se non sei ancora sicuro che il payload fosse dannoso, un ottimo modo per capirlo è guardare l’elenco degli IP client che hanno avviato le richieste con il payload corrispondente. Se gli IP del client sono distribuiti, vale a dire diversi, vi è una buona probabilità che il payload sia un falso positivo. Tuttavia, se tutti gli IP client hanno lo stesso valore, ciò indicherebbe un potenziale attacco volumetrico, classificandolo come payload dannoso. Per dimostrarlo, facciamo riferimento al passaggio 3 e scegliamo questo valore corrispondente– {“iata”:[“TGZ”,”mex”]} e lo usiamo come esempio. Per trovare l’elenco degli IP client che hanno inviato questo payload, aggiungere il valore corrispondente come filtro come segue:

Figura 5: IP client che hanno inviato il valore payload: {“iata”:[“TGZ”, “mex”]}.

In questo caso, data la varietà di indirizzi IP che fanno questa richiesta, c’è un’alta probabilità che queste richieste siano state originate da utenti reali, rendendo questo un buon candidato per un falso positivo.

6. Una volta identificato un falso positivo, è possibile creare un’eccezione nella sezione regole gestite, ma prima di farlo è necessario scoprire dove è stato trovato questo payload: Stringa di query, intestazione della richiesta, URL o altra posizione. Questa operazione può essere eseguita facilmente osservando la colonna corrispondente nella stessa pagina del passaggio 5. In questo caso di utilizzo, il payload è stato trovato nell’argomento di query “dati”, come mostrato di seguito:

Figura 6: Ubicazione del valore del carico utile: {“iata”:[“TGZ”,”mex”]}.

7. Una buona regola pratica consiste nel filtrare queste specifiche corrispondenze nei campi che contengono il payload falso positivo e verificare quindi che non vi siano altre richieste con questa corrispondenza sul parametro che trasporta un payload dannoso effettivo. In altre parole, il payload nel campo specifico abbinato non è mai dannoso. Ciò si ottiene aggiungendo un filtro sulla corrispondenza su un campo in questione. Esaminando il nostro caso di utilizzo, possiamo confermare che non vi è alcun payload dannoso trovato in questo argomento di query:

Figura 7: Tutti i valori di payload inviati nell’argomento query: Data.

8. Il passaggio finale prima di creare un’eccezione è trovare gli ID regola attivati dal campo corrispondente a. Stiamo cercando di notare tutte le regole (ID regola) che sono state attivate da questo falso positivo. In base al nostro caso d’uso, queste informazioni sono disponibili nella stessa pagina dal punto 5.

Figura 8: Elenco delle regole attivate dal valore del carico utile: {“iata”: [“TGZ”,”mex”]}.

9. È tempo di creare l’eccezione. Accedere alla sezione regole gestite e fare clic sulla regola gestita a cui si desidera aggiungere queste eccezioni.

Figura 9: Regole gestite esistenti create per la configurazione WAF.

10. Andare alla scheda eccezioni e fare clic su Aggiungi nuova condizione. Scegliere il tipo di corrispondenza nel campo, ad esempio Args, Request_cookies o URL in cui è stato trovato il payload. Quindi immettere il nome del parametro, ad esempio query o cookie. Infine, inserire l’elenco di tutti gli ID regola attivati dal payload.

Figura 10: Scheda eccezioni nella configurazione delle regole gestite.

11. Andate avanti e create quella condizione. Entro 30 secondi dal salvataggio della regola gestita, sarà possibile vedere questo falso positivo che passa attraverso il WAF in futuro

12. Ora che sapete come funziona, tornate al passaggio 3, filtrate il traffico con un altro ID regola e ripetete questo processo per eliminare il maggior numero possibile di falsi positivi.

CE l’hai fatta. Hai appena personalizzato la soluzione WAF per il tuo traffico.

Qualche suggerimento finale

Se si utilizza Edgio WAF per la prima volta, si consiglia di eseguire 2-3 cicli di questo esercizio prima di attivare la modalità blocco. E in base al volume di traffico, è possibile ripetere questo esercizio ogni 2-7 giorni. Per i clienti esistenti di Edgio WAF, si consiglia di eseguire questo esercizio di messa a punto ogni 3-4 settimane. Un’altra cosa da considerare è abbassare il valore di soglia della regola gestita a meno di 10, raggiungendo gradualmente il valore ottimale di 5. In questo modo si ottiene un set di regole più preciso e nitido. Tenere presente che Edgio WAF offre un WAF doppio, un ambiente di staging effettivo (la modalità di controllo) per il traffico in tempo reale. È possibile utilizzare la modalità di controllo per tutti gli aggiornamenti ricorrenti e le ottimizzazioni del set di regole senza preoccuparsi di eliminare il traffico legittimo.

Contattateci oggi stesso per saperne di più su tutte le nostre tecnologie di sicurezza che proteggono le vostre applicazioni Web.

Risorse:

¹⁻² OWASP, “Path Traversal”, owasp.org, owasp.org/www-community/attacks/Path_Traversal.

³ Offensive Security, “file Inclusion vulnerabilities”, offensive-security.com, offensive-security.com/metasploit-unleashed/file-inclusion-vulnerabilities/.

⁴⁻⁵ OWASP, “Cross Site Scripting“, owasp.org, owasp.org/www-community/attacks/xss/.

⁶⁻⁷OWASP, “SQL injection“, owasp.org, owasp.org/www-community/attacks/SQL_Injection.

⁸ Netsparker, “vulnerabilità di valutazione del codice in modalità remota (Execution)“, netsparker.com, netsparker.com/blog/web-security/remote-code-evaluation-execution/.

⁹⁻¹⁰ Ashraff, Ahmad, “Timing-based Attacks in web Applications“, owasp.org, owasp.org/www-pdf-archive/2018-02-05-AhmadAshraff.pdf.