Equilibrio tra registrazione e blocco nel WAF

Informatec Digital » Risorse » Equilibrio tra registrazione e blocco nel WAF

Trovare il giusto equilibrio tra registrazione e blocco in un WAF è diventato uno dei grattacapi più comuni per i team di sicurezza e operativi. Un firewall per applicazioni web può bloccare attacchi molto gravi, ma se configurato in modo troppo aggressivo, può bloccare acquisti, accessi o chiamate API legittimi. Se configurato in modo troppo permissivo, finisce per essere quasi puramente decorativo. La chiave è regolare attentamente quando registrare, quando contare, quando consentire e quando bloccare.

In questo articolo, analizzeremo come raggiungere questo equilibrio utilizzando le moderne funzionalità dei WAF (liste di autorizzazione, regole basate sulla frequenza, modalità di apprendimento, integrazione SIEM, machine learning, ecc.), supportate da esempi concreti tratti da AWS WAF, ModSecurity, WAF basati su cloud e soluzioni on-premise . Scoprirete come limitare i falsi positivi senza ridurre il livello di protezione, come organizzare le policy per applicazione e come utilizzare i log come alleato, non come fonte costante e incontrollabile di rumore.

Cos'è un WAF e perché la registrazione è così importante?

Un firewall per applicazioni web (WAF) funge da livello intelligente tra l'utente e il server , analizzando il traffico HTTP/HTTPS in tempo reale. A differenza di un firewall di rete tradizionale, che monitora porte e indirizzi IP, un WAF va più in profondità: analizza URL, parametri, corpi delle richieste, intestazioni, cookie, metodi HTTP e altro ancora.

La sua missione è rilevare e bloccare i tipici attacchi di Livello 7 : SQL injection, XSS, LFI/RFI, attacchi al controllo degli accessi, abuso delle API, scraping aggressivo, attacchi brute force e persino alcuni schemi DDoS a livello applicativo. Per fare ciò, si basa su una serie di regole, firme e politiche di sicurezza che vengono costantemente aggiornate.

La registrazione dei log è l'altra faccia della medaglia. Ogni decisione del WAF (consenti, blocca o solo conteggia) può essere accompagnata da un evento dettagliato nei log . Questi log consentono di:

• Indagare sugli incidenti: ricostruire l'accaduto e come si è tentato di sfruttare una vulnerabilità.
• Regola le regole: rilevare i falsi positivi verificando quali richieste legittime vengono bloccate dal WAF.
• Rispettare le normative: dimostrare l'esistenza di controlli attivi (PCI DSS, GDPR, audit interni, ecc.).
• Alimentazione di un SIEM: correlare gli attacchi alle applicazioni con eventi di rete, di sistema, di identità, ecc.

Il problema è che un WAF mal configurato può riempire i log con migliaia di eventi irrilevanti , rendendo impossibile trovare ciò che è importante e, per di più, causando il blocco ingiustificato di traffico legittimo. È qui che entra in gioco l'arte di giocare con le modalità di registrazione, conteggio e blocco.

Modelli di sicurezza nei WAF: liste di blocco, liste di autorizzazione e un approccio ibrido

La maggior parte dei WAF moderni combina diversi approcci di filtraggio, il che influisce direttamente sul modo in cui le richieste vengono registrate e bloccate . In linea generale, possiamo individuare due filosofie classiche, oltre a un modello ibrido molto comune.

Un WAF basato su una lista nera segue un modello di sicurezza negativo. Il suo principio fondamentale è: "Permetto tutto tranne ciò che so essere dannoso". Funziona utilizzando le firme di attacchi noti (SQL injection, XSS, pattern di bot, ecc.) e regole che definiscono ciò che è considerato sospetto. È più facile da implementare inizialmente, ma affidarsi esclusivamente a questo modello rischia di consentire a nuovi vettori di attacco o varianti di eludere i controlli.

Un WAF con una lista di elementi consentiti funziona in modo opposto: "blocca tutto tranne ciò che è esplicitamente permesso". Si basa su un modello di sicurezza positivo. Viene accettato solo il traffico che corrisponde al comportamento legittimo definito (percorsi, metodi, parametri, formati, dimensioni, ecc.). È molto più sicuro, ma richiede una messa a punto accurata e inizialmente può generare falsi positivi se non adeguatamente configurato.

Considerati i vantaggi e gli svantaggi di ciascun approccio, un modello ibrido che combina liste consentite e liste bloccate sta diventando sempre più comune . In questo scenario, vengono definiti i profili di traffico previsti (ad esempio, cosa costituisce un normale accesso o una richiesta di pagamento) e vengono applicate simultaneamente firme ed euristiche per rilevare i tipici schemi dannosi. Ai fini della registrazione, questo approccio ibrido consente di:

• Marcare come evento ad alto rischio ciò che viola l'elenco degli articoli consentiti.
• Trattare come avvisi di priorità media/bassa Modelli generali di liste di blocco.
• Utilizza la modalità "conteggio" per vedere cosa violerebbe una regola prima di attivare il blocco.

WAF in rete, on-host e nel cloud: impatto sulla registrazione e sul blocco

Il modello di implementazione del WAF influenza notevolmente la gestione della registrazione e del blocco del traffico. Registrare le richieste su un dispositivo di rete non è la stessa cosa che registrarle su un agente all'interno del server o su un servizio cloud gestito.

Un WAF basato su rete viene in genere implementato come appliance fisica o virtuale all'interno dell'infrastruttura, tra Internet e le applicazioni. Questo è l'approccio classico utilizzato da produttori come F5. Offre il vantaggio di prestazioni elevate e controllo granulare , ma la configurazione e la gestione possono risultare complesse. I log vengono solitamente inviati a syslog o a un SIEM centralizzato, ed è importante filtrare attentamente i dati salvati per evitare di sovraccaricare lo storage e gli strumenti di analisi, nonché per diagnosticare problemi nelle reti IP e DNS.

I WAF basati su host vengono eseguiti sugli stessi server (o container) in cui risiede l'applicazione, in genere come modulo o agente (ad esempio, ModSecurity integrato in Nginx o Apache; la sua combinazione con l'hardening di Linux tramite SELinux migliora il livello di sicurezza). Questo modello consente un contesto applicativo più ampio e regole altamente specifiche per servizio, a costo di un maggiore consumo di risorse locali e di una gestione dei log più distribuita. I log possono essere archiviati in file locali e quindi inoltrati, oppure integrati con servizi di logging centralizzati.

I WAF basati su cloud (Cloudflare, Akamai, Imperva Cloud, AWS WAF, ecc.) si integrano con bilanciatori di carico, CDN o reti virtuali. I provider in genere offrono dashboard ed esportazione dei log su S3, BigQuery, syslog remoti o SIEM. Sono generalmente più facili da configurare, ma è necessario adattare le proprie policy di logging al modello del provider: tipi di evento, periodi di conservazione, filtri di gravità, ecc.

La scelta tra un modello e l'altro non è solo una decisione tecnica, ma anche una questione di equilibrio tra registrazione e blocco dei log: un servizio gestito in cloud semplifica molti aspetti, ma potresti voler avere il controllo assoluto su dove vengono archiviati i log per motivi di conformità o riservatezza, il che ti spinge verso modelli on-premise o ibridi.

Termini, regole e ACL web: come il WAF decide se bloccare, consentire o solo registrare

Indipendentemente dal produttore, tutti i WAF moderni si basano sul concetto di condizioni di accesso, regole e politiche . Comprendere questo concetto è fondamentale per utilizzare con successo le modalità di conteggio, registrazione e blocco in ambiente di produzione.

Le condizioni descrivono quale parte della richiesta viene ispezionata: indirizzo IP di origine, intestazioni HTTP specifiche (Host, User-Agent, Accept, Content-Type…), parametri di query, corpo della richiesta, cookie, metodo HTTP, paese di origine, ecc. Ad esempio, in AWS WAF Classic è possibile definire una condizione IP con un massimo di 10.000 indirizzi o intervalli, oppure una condizione di corrispondenza di stringa su una porzione dell'URL.

Le regole combinano una o più condizioni e assegnano un intento: consentire, bloccare o contare. Quando una regola ha più condizioni, queste vengono in genere valutate con un operatore logico AND : tutte le condizioni devono essere soddisfatte affinché la regola venga attivata. Una regola normale senza condizioni, in pratica, non corrisponde a nulla e la sua azione non viene mai attivata.

Molti WAF, incluso AWS WAF, dispongono anche di regole basate sulla frequenza . Queste regole contano le richieste provenienti da un indirizzo IP (o da un insieme di indirizzi IP che soddisfano determinate condizioni) durante un intervallo di tempo, ad esempio cinque minuti. Se viene superata una soglia, ad esempio 1.000 richieste in cinque minuti, la regola entra in vigore: bloccando o semplicemente contando le richieste. Questo è molto utile per:

• Controllo attacco di forza bruta ai moduli di accesso.
• Limita lo scraping aggressivo o i bot maleducati.
• Attenuare determinate tipologie di attacchi DDoS a livello applicativo.

Il livello successivo è la Web ACL (Access Control List) . Qui, le regole sono raggruppate e vengono definiti un ordine di valutazione e un'azione predefinita (CONSENTI o BLOCCA). Una richiesta attraversa le regole in sequenza; se ne trova una corrispondente, viene applicata la relativa azione e la valutazione delle restanti viene interrotta. Se non trova alcuna corrispondenza, viene applicata l'azione predefinita definita nella ACL.

In termini di equilibrio tra registrazione e blocco, l'ACL è il punto in cui si decide se il sistema deve essere permissivo di default (CONSENTI e blocca solo in base a regole specifiche) o altamente restrittivo (BLOCCA tranne in casi eccezionali). Inoltre, molte soluzioni consentono di impostare regole in modalità "conteggio" all'interno dell'ACL, in modo che registrino le corrispondenze ma non blocchino il traffico, ideale per la fase di ottimizzazione.

Liste bianche e riduzione del rumore nei log

Le allowlist sono uno strumento fondamentale per ridurre i falsi positivi e il rumore nei log . L'idea è semplice: in determinati contesti, si indica al WAF di non applicare una direttiva o un insieme di regole a un traffico specifico che è già stato classificato come attendibile o che si sa essere al di fuori della norma ma legittimo.

Ad esempio, in AWS WAF è possibile creare regole di lista di autorizzazione in modo che, se una richiesta proviene da un indirizzo IP o da un intervallo specifico , oppure se corrisponde a un modello URL e a un metodo HTTP noti, determinate ispezioni della firma non vengano applicate. Questo aiuta a:

• Impedire l'utilizzo di API interne che impiegano schemi "strani". generare costantemente falsi positivi.
• Riduci la latenza introdotta dall'ispezione approfondita del traffico che già consideri affidabile.
• Ridurre il volume di record non necessari nei log del WAF.

Su piattaforme come ModSecurity, l'approccio consigliato non è quello di modificare le regole standard (ad esempio, il set di regole OWASP Core), bensì di creare esclusioni specifiche tramite ID regola per determinati parametri, percorsi o utenti. Questo permette di mantenere una protezione complessiva senza creare enormi vulnerabilità disabilitando intere regole a livello di sito.

La chiave è rendere le liste di elementi consentiti mirate , non adottare un approccio indiscriminato. È molto meglio escludere una combinazione specifica (regola X + parametro Y nell'URL Z) piuttosto che disabilitare la regola X a livello globale. In questo modo, i log rimangono utili e non si creano punti ciechi inutili.

Regole e limiti del protocollo: quando bloccare, quando avvisare

Molti WAF incorporano una serie di regole di sanificazione del protocollo HTTP che fungono da primo filtro per il traffico non valido o sospetto . Queste regole verificano le intestazioni obbligatorie, i metodi, le dimensioni degli argomenti, ecc., e sono spesso fonte sia di una buona protezione che di falsi positivi se non vengono comprese correttamente.

Alcuni esempi molto comuni:

• Intestazione Accept mancante (Intestazione Accept mancante): Questa non è una violazione in senso stretto delle RFC, ma molte richieste senza questa intestazione provengono da strumenti automatizzati o script scritti male. Può influire su API personalizzate o client che non la inviano. In molti ambienti, la registrazione e il conteggio sono preferibili al blocco diretto.
• Intestazione host mancanteSecondo gli standard HTTP/1.1, l'intestazione Host è obbligatoria. Anche i WAF ne hanno bisogno per determinare quale policy applicare. Il blocco in questo caso è generalmente ragionevole, ma può generare falsi positivi durante i test o a causa di una configurazione errata del traffico interno; si consiglia di monitorare i log prima di abilitare il blocco rigoroso.
• Intestazione User-Agent mancanteQuesta regola tenta di frenare i bot rudimentali e il traffico non identificato. Il problema è che molte API legittime potrebbero non inviare uno User-Agent. L'approccio più sensato è solitamente quello di registrare e, se viene rilevata un'API coerente e legittima, aggiungi il loro IP o pattern a una lista di persone consentite.
• Validazione GET/HEAD con corpoSebbene l'RFC non vieti esplicitamente l'invio del corpo della richiesta con le richieste GET o HEAD, non è una pratica comune e potrebbe indicare tentativi di elusione. In molti casi, un primo passo consiste nel registrare tutte queste richieste e, se vengono individuate come anomalie sospette, procedere al loro blocco.
• Tipo di contenuto mancante con corpoSe è presente un corpo della richiesta ma manca l'attributo Content-Type, è un chiaro segnale di utilizzo improprio del protocollo o di tentativo di eludere l'analisi. In questi casi, un approccio di blocco più aggressivo è generalmente consigliabile, soprattutto in ambienti esposti a Internet.

Oltre a queste regole di protocollo, i limiti degli argomenti vengono spesso utilizzati per proteggere da attacchi di tipo flood a livello applicativo e da attacchi DoS. Ad esempio:

• Numero massimo di argomenti per richiesta (per impostazione predefinita, 255 in alcuni WAF).
• Lunghezza massima di un singolo argomento (ad esempio, 400 caratteri).
• Dimensione totale combinata di tutti gli argomenti (ad esempio, 64.000 byte).

Questi valori sono ragionevoli per molte applicazioni, ma ci sono casi – caricamenti di moduli complessi, filtri avanzati, caricamenti JSON di grandi dimensioni – in cui si verificano falsi positivi. In questi scenari, l'approccio più prudente è iniziare registrando e contando , verificare quali endpoint superano i limiti e modificare solo per quei percorsi, piuttosto che rimuovere tutti i limiti per l'intero sito.

Falsi positivi: come individuarli senza rischiare la vita

Un falso positivo è una richiesta legittima che il WAF identifica come dannosa e blocca o segnala come un attacco. Sono inevitabili, soprattutto quando si utilizzano set di regole completi come OWASP CRS, ma possono essere gestiti professionalmente in modo da non diventare un problema quotidiano.

L'individuazione dei falsi positivi inizia con un'attenta analisi dei log . Ciò implica esaminare quali richieste vengono bloccate, quale regola le attiva e il contesto in cui si verificano (URL, parametri, utente, origine, ecc.). Strumenti visivi e dashboard possono aiutare a identificare picchi di errori 403 o modelli insoliti.

Un approccio altamente raccomandato, sia dai fornitori di servizi cloud che dalla community di ModSecurity, è quello di utilizzare una modalità di simulazione o di conteggio . In questa modalità, le regole che si desidera testare registrano ogni corrispondenza ma non bloccano. Ciò consente di vedere, ad esempio, quante richieste legittime una nuova regola SQLi avrebbe bloccato prima di osare attivarla in produzione.

È inoltre consigliabile testare le regole in un ambiente di staging o di pre-produzione che riceva traffico reale o simulato. Strumenti come OWASP ZAP o script di riproduzione del traffico possono aiutare a simulare schemi legittimi e attacchi noti per testare il comportamento del WAF.

Inoltre, è fondamentale considerare l'impatto operativo e reputazionale dei falsi positivi: interruzioni dei pagamenti, errori di registrazione degli utenti, chiamate API critiche che falliscono senza spiegazione, tutti fattori che possono avere un costo diretto in termini di fatturato e immagine del marchio. Un eccesso di falsi positivi sovraccarica anche il team di sicurezza con avvisi che non aggiungono valore, rendendo difficile identificare gli incidenti reali.

Strategie per l'adeguamento delle regole e l'uso intelligente del registro

Gestire i falsi positivi non significa disattivare le regole finché "tutto funziona", ma piuttosto affinare il WAF con precisione chirurgica . È qui che entrano in gioco buone pratiche come le seguenti:

Innanzitutto, evitate di disabilitare le regole a livello globale. È preferibile creare eccezioni molto specifiche : escludete l'ID della regola solo per un percorso particolare, per determinati parametri o per il traffico interno. In questo modo, la protezione rimane valida nel resto dell'applicazione e si mantengono log utili.

In secondo luogo, sfruttate la modalità di conteggio prima di bloccare. Attivare le nuove regole inizialmente solo in modalità di registrazione consente di misurare quante richieste legittime verrebbero interessate. È possibile integrare questa analisi con avvisi nel SIEM per rilevare rapidamente se una regola sta generando un volume anomalo di corrispondenze.

In terzo luogo, integrate il WAF con un SIEM o una piattaforma di logging centralizzata . Questo semplifica la correlazione degli eventi del WAF con altri indicatori: attività di sistema insolite, tentativi di autenticazione falliti in massa, modifiche sospette alla configurazione, ecc. Aiuta inoltre a stabilire le priorità per la modifica delle regole in base alla gravità e alla frequenza degli eventi.

In quarto luogo, documentate ogni modifica: quale regola è stata perfezionata, per quale endpoint, con quale giustificazione e con quali prove. Consultare i manuali del server può essere utile a questo scopo. Questa documentazione non solo aiuta a mantenere il controllo interno, ma è anche preziosa negli audit e nelle revisioni di sicurezza, dove è necessario dimostrare che i controlli non vengono disabilitati con leggerezza.

Automazione, apprendimento automatico e regole adattive nei WAF

Con la crescita delle applicazioni e la crescente complessità del traffico, la gestione manuale del WAF diventa irrealistica. È qui che entrano in gioco l'automazione, l'analisi avanzata dei log e, in alcuni casi, l'apprendimento automatico.

Innanzitutto, l'integrazione con il SIEM consente di creare regole di correlazione e risposte automatizzate : ad esempio, se un insieme di indirizzi IP attiva ripetutamente le regole di injection o XSS, è possibile generare un'azione automatica per aggiungere tali IP a una blacklist temporanea o rafforzare il livello di ispezione.

In secondo luogo, alcuni WAF integrano modalità di apprendimento automatico che osservano il traffico legittimo per un periodo definito. Sulla base di questi dati, propongono o modificano soglie, modelli e profili di comportamento normale. Ciò contribuisce a ridurre i falsi positivi quando le regole vengono attivate in modalità di blocco e a rilevare successive deviazioni dal traffico.

In ambito di ricerca e laboratorio, le tecniche di apprendimento supervisionato sono state utilizzate per addestrare modelli in grado di distinguere tra traffico legittimo e dannoso, perfezionando le policy che vengono poi impiegate in produzione. Pur non essendo una soluzione miracolosa, questo approccio può contribuire a individuare schemi sottili che le classiche regole basate sulle firme non riescono a rilevare facilmente.

Infine, i test automatizzati continui (utilizzando strumenti come OWASP ZAP, script personalizzati o pipeline CI/CD) consentono di verificare che le modifiche al WAF non compromettano funzionalità critiche o lascino vulnerabilità evidenti. L'integrazione di questi test nel ciclo di implementazione rende la sicurezza parte integrante del flusso di sviluppo, anziché una patch dell'ultimo minuto.

Definizione delle policy per applicazione e delle blacklist per servizio.

In ambienti complessi, ad esempio presso un provider di hosting o un ISP, una singola policy WAF non è sufficiente, soprattutto in presenza di shadow IT . È frequente avere più domini o applicazioni dietro lo stesso bilanciatore di carico, ognuno con esigenze di sicurezza e profili di traffico differenti . In questi casi, la progettazione di policy e liste specifiche per ciascun servizio diventa essenziale.

Un esempio illustrativo è un bilanciatore di carico HTTP/S che funge da proxy inverso per più siti (ad esempio, www.company1.com e www.company2.com) dietro un singolo indirizzo IP virtuale. In questo scenario, il WAF può essere configurato per valutare l'intestazione Host e l'indirizzo IP di origine non appena la richiesta arriva, anche prima che raggiunga il modulo di bilanciamento del carico.

La logica sarebbe più o meno questa: il WAF verifica se la combinazione di SERVER_NAME (Host) e IP del client corrisponde a una blacklist specifica del sito. Se l'IP è presente nell'elenco dei siti bloccati per www.company2.com ma non per www.company1.com, viene inviata una risposta 403 Forbidden solo nel primo caso. Il traffico "pulito" viene quindi passato al modulo di bilanciamento del carico, che decide quale backend deve gestire la richiesta.

Ciò consente di mantenere, ad esempio, blacklist specifiche per dominio , anziché un'unica lista globale per l'intero punto di accesso. A livello di logging, ogni rifiuto viene registrato in syslog con dettagli quali l'ID della regola, la condizione corrispondente, l'URL, l'host e l'indirizzo IP del client, facilitando l'analisi successiva e l'espansione o il debug di queste liste.

La morale della storia è che più le tue politiche sono segmentate (per applicazione, per ambiente, per tipo di utente), più finemente puoi trovare il giusto equilibrio tra registrazione e blocco: puoi essere molto rigoroso sui portali amministrativi e un po' più flessibile sui siti web informativi, ad esempio, avendo sempre la prova nei log del perché ogni decisione è stata presa.

Oltre il classico WAF: WAAP e protezione delle API

Il panorama delle minacce è in continua evoluzione. Oggi, molte applicazioni sono native del cloud, utilizzano architetture a microservizi ed espongono API pubbliche e private , diventando così obiettivi primari per gli aggressori. I WAF tradizionali si sono evoluti in piattaforme più ampie note come WAAP (Web Application and API Protection) o WAAS (Web Application & API Security).

Queste soluzioni non solo rilevano automaticamente le applicazioni web, ma identificano anche gli endpoint API , accettano specifiche come OpenAPI o Swagger e utilizzano tale definizione per verificare la conformità delle richieste: tipi di dati previsti, parametri consentiti, limiti di dimensione, ecc. A seconda dell'endpoint (ad esempio, uno che gestisce dati altamente sensibili), è possibile applicare un livello di controllo e blocco molto più elevato.

A livello di logging, WAAP tende a generare eventi ricchi di contesto : quale endpoint API specifico è stato attaccato, quale operazione (GET, POST, PUT…), quale utente o token è stato coinvolto, quale parte della specifica è stata violata, ecc. Ciò consente di prendere decisioni di blocco più precise, anziché basarsi esclusivamente su modelli di payload generici.

Inoltre, molti strumenti WAAP includono protezione DoS specifica per applicazioni e API, filtraggio della geolocalizzazione, gestione della reputazione IP, rilevamento di bot e scraping e opzioni per personalizzare i livelli di allerta per servizio. Anche in questo caso, si tratta di avere la flessibilità di decidere dove adottare un approccio più robusto e dove dare priorità al funzionamento senza intoppi , senza sacrificare un solido database di log per l'analisi di eventuali incidenti.

Nel complesso, un WAF ben configurato, sia esso classico, basato su WAAP o integrato in un ecosistema cloud, diventa un componente essenziale della moderna difesa di applicazioni e API, in grado di combinare la registrazione dettagliata degli eventi, il blocco intelligente e l'adattamento continuo al panorama delle minacce in continua evoluzione.