Negli anni ’90 nascono i primi siti di commercio elettronico e fu evidente l’esigenza di misure dedicate alla sicurezza per la loro protezione, nacquero quindi i primi Web Application Firewall, WAF. Per poter proteggere a livello di applicazione.
Come si usa un WAF?
Generalmente i controlli svolti dal WAF si possono classificare in:
- verifica dei protocolli utilizzati, a partire da HTTP;
- verifica dell’assenza di codice nocivo nei dati trasferiti nei linguaggi adottati dal servizio Web. Possono comprendere da HTML a XML, Javascript, JSON ecc., ma anche Java, Php, Python, Ruby ecc., ed infine SQL, no-SQL ecc.
Il sistema con gli antivirus potrebbe apparire molto similare, perché si tratta soprattutto di individuare il codice nocivo ed evitare che venga trasmesso. Infatti il cuore dei servizi WAF è basato, come per gli Anti-Virus, su librerie di “firme” di attacchi.
Ad esempio si assuma che un’applicazione Web sia scritta in Java con un database SQL e che utilizzi pagine HTML con Javascript. Il WAF deve essere configurato con le librerie di firme per attacchi relativi a Java e SQL, HTML e Javascript. Queste librerie devono essere aggiornate frequentemente in modo da disporre subito le firme degli attacchi in corso e delle vulnerabilità appena scoperte. Questo primo livello di sicurezza già rappresenta una protezione base.
WAF tradizionali
I WAF Tradizionali non sono però solo degli strumenti che verificano solo la presenza o meno delle firme degli attacchi nei dati in transito. Verificano anche la correttezza dell’implementazione dei protocolli e della loro sintassi e possono tipicamente applicare delle logiche basate su regole. Permettono sia di concatenare serie di dati e condizioni sia di applicare verifiche solo a particolari tipi di dati. Ad esempio un sistema potrebbe essere valido se riferito ad un linguaggio di programmazione ma non valido o maligno se riferito ad un altro linguaggio.
Per evitare che il WAF blocchi le connessioni ed in pratica effettui un attacco di Denial of Service al servizio Web, si preferisce alle volte utilizzarlo solo in modalità passiva. Intervenire in caso di reale attacco ed intromissione tramite le procedure standard per la gestione degli incidenti di sicurezza informatica.
IPS e ulteriori funzionalità dei WAF
La descrizione che è stata data finora di un WAF non si discosta molto da quella di un Intrusion Prevention System (IPS). Gli IPS sono nati come evoluzione degli Intrusion Detection System (IDS) che hanno solo capacità passive di tracciamento di pacchetti di rete nocivi. Aggiungendo anche la possibilità di blocco del traffico. Gli IPS sono di base dei servizi di sicurezza di rete. Esaminano tutto il traffico a partire di solito dal livello 3 Networking nel modello ISO/OSI ma arrivano ad esaminare anche i più alti livelli applicativi. Anche gli IPS lavorano con “firme” di pacchetti nocivi e possono verificare la sintassi dei protocolli con logiche basate su regole.
Lo scopo dei due strumenti è però molto diverso. Un IPS è uno strumento di sicurezza principalmente a livello rete e generico, che può proteggere contemporaneamente molti servizi e applicazioni di tipo diverso. Un WAF invece è uno strumento di sicurezza a livello applicativo e specializzato che può essere personalizzato per proteggere una specifica singola applicazione. Non è detto che un IPS sia in grado di implementare regole di protezione. Esse dipendono molto profondamente dal linguaggio di programmazione adottato nell’applicazione come invece è naturale che sia per un WAF.
Personalizzazioni dei WAF
La specializzazione e personalizzazione è però un’arma a doppio taglio. Come prima cosa ogni applicazione dovrebbe avere il proprio WAF dedicato, od almeno la propria istanza di WAF personalizzata. Questo, da solo, richiede che ci sia molto lavoro di configurazione e gestione. Ma anche l’utilizzo di risorse umane e applicative adeguate, il che include risorse di rete, di calcolo, di memoria. Senza dimenticarsi dei costi delle licenze delle applicazioni, middleware e sistemi operativi (o appliance fisiche o virtuali) necessarie.
Come sempre quando si progetta un sistema di sicurezza, bisogna decidere quale approccio adottare. Bloccare solo il traffico che è noto essere nocivo, o permettere solo il traffico che è considerato lecito. Come ben noto le due logiche sono opposte. La prima è riassumibile in “blocca eventi specifici e permetti tutto il resto” (default-permit). La seconda in “permetti eventi specifici e blocca tutto il resto” (default-block). Tipicamente la logica default-block è utilizzata dai firewall mentre gli IPS utilizzano spesso la logica default-permit. Nell’accezione più avanzata, un WAF dovrebbe adottare la logica default-block. Ma questo richiederebbe di specificare esattamente tutti i contenuti leciti che possono transitare alla e dall’applicazione.
WAF di nuova generazione
Come abbiamo indicato, la gestione di un WAF non è sempre cosa facile e per questo ormai da tempo sono sorte soluzioni Cloud. Ovvero servizi WAF erogati in modalità Software-as-a-Service (SaaS). I punti di forza di un servizio WAF SaaS sono molteplici e simili in generale a quelli di altri servizi SaaS:
- la gestione dell’infrastruttura (network, hardware, software) è in carico al fornitore;
- gli aggiornamenti continui del WAF e la sua manutenzione sono in carico al fornitore. Che sfrutta notevoli economie di scala garantendo al contempo che l’aggiornamento delle firme e delle configurazioni sia molto più veloce e comprensivo per tutti i clienti;
- tipicamente il fornitore offre modalità di scalabilità delle prestazioni non possibili quando il WAF è on-premises in appliance hardware, e non facilmente replicabili o così velocemente implementabili per appliance software;
- il fornitore ha visibilità diretta del traffico di tutti i clienti e quindi ha la possibilità di valutare se anomalie di traffico sono eventi locali e veramente anomali o se invece sono nuove campagne di attacco che vengono man mano indirizzate a tutti i servizi Web;
- il fornitore è tipicamente in grado anche di offrire servizi anti-Distributed-Denial-of-Service (DDoS) specifici per i servizi Web protetti dai WAF, protezione difficilmente replicabile per i singoli servizi Web con le soluzioni WAF on-premises.
Aspetti negativi del Cloud SaaS
Ovviamente valgono anche i comuni aspetti negativi delle soluzioni Cloud SaaS, a partire dalle a volte limitate possibilità di personalizzazione del servizio. Una delle principali difficoltà di gran parte delle misure di sicurezza attiva è quella di fronteggiare gli zero-days. Ovvero il periodo di tempo tra la scoperta di una vulnerabilità e la disponibilità di una misura per contrastarla, tipicamente aggiornando l’applicazione. Come già descritto, un WAF è utile contro gli zero-days come soluzione di Virtual Patching. Ma solo se è in grado di individuare gli attacchi che sfruttano la vulnerabilità. Oltre alla velocità nella creazione e distribuzione delle firme, i WAF più recenti adottano alcuni ulteriori approcci.
Il primo consiste nella classificazione del traffico che normalmente viene gestito dall’applicazione e dalla creazione di una policy o di un profilo che lo descrive. In altre parole, osservando il traffico ritenuto “normale” e quindi lecito, il WAF ne crea automaticamente una descrizione. Che traduce in regole che ne permettono il traffico. Viene bloccato tutto il traffico che non rispetta questa descrizione o che fa scattare una regola che descrive traffico maligno.
Analisi del blocco del traffico maligno
Questo approccio rende automatica la creazione della soluzione descritta nella sezione precedente e che dovrebbe essere ottimale. Dovrebbe infatti permettere solo il traffico lecito, desunto dal traffico noto, e bloccare tutto il resto. Il problema è che quasi sempre il traffico noto è un sottoinsieme molto ridotto del traffico lecito, e questo per molteplici motivi tra cui:
- il modo in cui gli utenti interagiscono con l’applicazione;
- può essere molto vario sia nei contenuti sia nell’ordine delle azioni e nelle modalità;
- gli utenti possono connettersi all’applicazione Web con strumenti software diversi. Anche solo una nuova versione di un Browser Web può introdurre modifiche al comportamento del client rispetto all’applicazione;
- le applicazioni sono in costante evoluzione (si pensi solo ai metodi Agile di sviluppo). Introducono costantemente e continuamente nuove funzionalità e dati, il che può in breve tempo rendere superata la descrizione del traffico fatta dal WAF.
Conseguenza di tutto ciò è un alto rischio di blocco di traffico lecito (ovvero di falsi positivi). Per alcune, poche, applicazioni di nicchia e ad alti requisiti di sicurezza, il blocco di traffico lecito può anche essere accettato (se in limitate quantità). Ma non può essere accettato per nulla nella maggioranza delle applicazioni di business, dal commercio elettronico ai siti finanziari, di informazione ecc. E’ questo il principale motivo per cui i WAF spesso sono utilizzati solo in modalità passiva. Ovvero di tracciamento di eventuali attacchi ma non di loro blocco.
Efficacia reale dei WAF
Quanto efficaci sono i WAF realmente? Il costo e la complessità di gestione sono anche indicati come fattori negativi. Infine solo 1/5 utilizza i WAF in modalità di blocco, in quanto ritiene che il rischio di falsi positivi sia troppo alto.
D’altro canto, sarebbe interessante avere statistiche su quanti attacchi sono stati bloccati o segnalati correttamente dai WAF. Quindi quanti incidenti o intrusioni siano state evitate. Non c’è dubbio che i WAF non sono strumenti perfetti. Come tutti gli strumenti di sicurezza informatica, e che sono difficili e spesso costosi da gestire. E’ pertanto difficile fare un rapporto costo benefici, o meglio tra costi e potenziali danni, per l’utilizzo dei WAF. I WAF sono comunque uno strumento molto utile per la sicurezza delle applicazioni Web esposte in Internet. I continui sviluppi li stanno rendendo sempre più efficaci e più semplici da utilizzare.
Fonte: ictsecuritymagazine.com
