Figura 1: Eventi WAF verificatisi nelle ultime 6 ore.
2. Esaminare i primi 10 ID regola 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, iniziate a filtrare il traffico in base a questi ID regola uno per uno per ulteriori analisi.
Figura 2: Le prime 10 regole sparate dagli eventi WAF.
3. Successivamente, esaminare i valori del carico utile che hanno attivato questa regola esaminando il campo valore abbinato.
Figura 3: Valori del carico utile sotto la colonna valore abbinato.
4. Analizza i valori del payload per identificare se sono dannosi. Non sei sicuro di come siano? Ecco alcuni potenziali valori dannosi che si possono trovare nel payload.
- Percorso trasversale: http://some_site.com.br/../../../../some dir/alcuni file¹ http://testsite.com/get.asp?f=/etc/passwd²
- Vulnerabilità LFI: Un utente malintenzionato tenta di accedere a file sensibili sul server, come .ini. Il WAF Edgecast blocca questa e molte altre estensioni del file system critiche per impostazione predefinita.³
- 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 IN CUI «a»=’a»;⁶ SELEZIONARE 1;⁷
- Esecuzione di codice in modalità remota: eval(“\$$user = ‘$regdate’);⁸
- Attacchi basati sul tempo: Select 1 e Sleep(2);⁹ Select BENCHMARK(2000000,MD5(«A»));¹⁰
5. Se non sei ancora sicuro se 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 client sono distribuiti, vale a dire diversi, c’è 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 quindi come payload dannoso. Per dimostrarlo, facciamo riferimento al passaggio 3 e scegliamo questo valore corrispondente– {“iata”:[“TGZ”,”mex”]} e lo usiamo come esempio. Per scoprire l’elenco degli IP client che hanno inviato questo payload, aggiungere il valore abbinato 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 provengano 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. Ciò è possibile facilmente osservando la colonna corrispondente sulla stessa pagina dal punto 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 quindi verificare che non vi siano altre richieste con questo parametro corrispondente che trasportano un payload dannoso effettivo. In altre parole, il carico utile nel campo corrispondente non è mai dannoso. Ciò si ottiene aggiungendo un filtro sul campo corrispondente. Guardando il nostro caso d’uso, possiamo confermare che non c’è alcun payload dannoso trovato in questo argomento di query:
Figura 7: Tutti i valori payload inviati nell’argomento query: Dati.
8. Il passaggio finale prima di creare un’eccezione consiste nel trovare gli ID delle regole attivati dal campo corrispondente attivato. 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. È il momento di creare l’eccezione. Accedere alla sezione regole gestite e fare clic sulla regola gestita alla quale 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 la query o il cookie. Infine, inserire l’elenco di tutti gli ID regola attivati dal payload.
