{"id":55733,"date":"2020-01-27T00:00:00","date_gmt":"2020-01-26T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/evolyutsiya-web-application-firewall-ot-setevyh-ekranov-do-oblachnyh-sistem-zashhity-s-mashinnym-obucheniem"},"modified":"2020-02-18T14:03:52","modified_gmt":"2020-02-18T11:03:52","slug":"evolyutsiya-web-application-firewall-ot-setevyh-ekranov-do-oblachnyh-sistem-zashhity-s-mashinnym-obucheniem","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/evolyutsiya-web-application-firewall-ot-setevyh-ekranov-do-oblachnyh-sistem-zashhity-s-mashinnym-obucheniem","title":{"rendered":"L'evoluzione del Web Application Firewall: dai firewall di rete ai sistemi di protezione cloud con machine learning","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Nel nostro precedente articolo sulla tematica cloud abbiamo parlavano<\/a><\/noindex>, come proteggere le risorse IT nel cloud pubblico e perch\u00e9 gli antivirus tradizionali non sono del tutto adatti a questi scopi. In questo post continueremo a parlare di sicurezza cloud e discuteremo dell'evoluzione del WAF e di cosa sia meglio scegliere: hardware, software o cloud.\u00a0<\/b><\/p>\n

\"L'evoluzione
\n<\/p>\n

Cos'\u00e8 un WAF<\/h3>\n

\nOltre il 75% degli attacchi hacker \u00e8 volto a vulnerabilit\u00e0 delle applicazioni web e dei siti: tali attacchi sono generalmente invisibili per l'infrastruttura di sicurezza informatica e i servizi di sicurezza informatica. Le vulnerabilit\u00e0 delle applicazioni web comportano, a loro volta, rischi di compromissione e frode su account e dati personali degli utenti, password e numeri di carte di credito. Inoltre, le vulnerabilit\u00e0 di un sito web possono servire come porta d'ingresso per i malintenzionati nella rete aziendale.<\/p>\n

Il Web Application Firewall (WAF) \u00e8 uno schermo di protezione che blocca gli attacchi alle applicazioni web: iniezioni SQL, cross-site scripting, esecuzione di codice remoto, brute force e bypass dell\u2019autenticazione. Include anche attacchi che sfruttano vulnerabilit\u00e0 zero-day. I firewall per applicazioni forniscono protezione monitorando il contenuto delle pagine web, inclusi HTML, DHTML e CSS, e filtrando le richieste potenzialmente dannose tramite HTTP\/HTTPS.
\n<\/a><\/noindex><\/p>\n

Quali erano le prime soluzioni?<\/h3>\n

\nI primi tentativi di creare un Web Application Firewall risalgono all'inizio degli anni '90. Si conoscono almeno tre ingegneri che hanno lavorato in questo campo. Il primo \u00e8 il professor di informatica Gene Spafford della Purdue University, che ha descritto l'architettura di un firewall per applicazioni basato su proxy e nel 1991 ha pubblicato un libro \u00abSicurezza UNIX in pratica\u00bb<\/a><\/noindex>.<\/p>\n

Il secondo e il terzo erano gli esperti di sicurezza informatica William Cheswick e Marcus Ranum di Bell Labs. Hanno sviluppato uno dei primi prototipi di firewall per applicazioni, distribuito da DEC con il nome SEAL (Secure External Access Link). <\/p>\n

Tuttavia, SEAL non era una soluzione WAF completa. Rappresentava un classico firewall di rete con funzionalit\u00e0 avanzate \u2014 la possibilit\u00e0 di bloccare attacchi su FTP e RSH. Per questo motivo, la prima soluzione WAF \u00e8 considerata oggi il prodotto della Perfecto Technologies (poi Sanctum). Nel 1999 hanno ha presentato<\/a><\/noindex> lanciato il sistema AppShield. All'epoca la Perfecto Technologies si dedicava allo sviluppo di soluzioni di sicurezza informatica per l'e-commerce, e il pubblico target del loro nuovo prodotto erano i negozi online. AppShield era in grado di analizzare le richieste HTTP e bloccava gli attacchi sulla base di politiche di sicurezza informatica dinamiche.<\/p>\n

Circa nello stesso periodo di AppShield (nel 2002) \u00e8 apparso il primo WAF open source, ModSecurity<\/a><\/noindex>. \u00c8 stato creato con l'intento di promuovere le tecnologie WAF e viene ancora supportato dalla comunit\u00e0 IT (ecco il suo repository su GitHub<\/a><\/noindex>). ModSecurity blocca attacchi alle applicazioni, basandosi su un insieme standard di espressioni regolari (firmware) \u2014 strumenti per l'ispezione delle richieste in base a modelli \u2014 OWASP Core Rule Set<\/a><\/noindex>.<\/p>\n

Alla fine, i sviluppatori sono riusciti a raggiungere il loro obiettivo: sono comparse nuove soluzioni WAF sul mercato, comprese quelle costruite sulla base di ModSecurity.<\/p>\n

Tre generazioni \u2014 sono gi\u00e0 storia<\/h3>\n

\nSi distinguono tre generazioni di sistemi WAF, che si sono evoluti con lo sviluppo delle tecnologie.<\/p>\n

Prima generazione<\/b>. Funziona con espressioni regolari (o grammatiche). Include ModSecurity. Il fornitore del sistema studia i tipi di attacchi alle applicazioni e crea modelli che descrivono le richieste legittime e potenzialmente dannose. Il WAF si confronta con queste liste e decide come agire in una certa situazione \u2014 bloccare il traffico o meno.<\/p>\n

Un esempio di rilevamento basato su espressioni regolari \u00e8 il gi\u00e0 citato progetto Core Rule Set<\/a><\/noindex> open source. Un altro esempio \u00e8 , anch'esso open source. I sistemi basati su espressioni regolari presentano diversi svantaggi, in particolare, al momento del rilevamento di una nuova vulnerabilit\u00e0, l'amministratore deve creare manualmente ulteriori regole. Nel caso di una grande infrastruttura IT, le regole possono essere diverse migliaia. Gestire un numero cos\u00ec elevato di espressioni regolari \u00e8 abbastanza complicato, per non parlare del fatto che la loro verifica pu\u00f2 ridurre le prestazioni della rete.<\/a><\/noindex>Inoltre, le espressioni regolari presentano un livello di falsi positivi piuttosto alto. Il famoso linguista Noam Chomsky ha proposto una classificazione delle grammatiche in cui le ha suddivise in quattro livelli di complessit\u00e0. Secondo questa classificazione, le espressioni regolari possono descrivere solo le regole del firewall che non prevedono deviazioni dal modello. Ci\u00f2 significa che i malintenzionati possono facilmente \"ingannare\" il WAF di prima generazione. Uno dei metodi per contrastare ci\u00f2 \u00e8 l'aggiunta di simboli speciali nelle richieste alle applicazioni, che non influiscono sulla logica dei dati dannosi, ma violano la regola di firma.<\/p>\n

Anche le espressioni regolari hanno un livello piuttosto elevato di falsi positivi. Il famoso linguista Noam Chomsky ha proposto una classificazione delle grammatiche, suddividendole in quattro livelli di complessit\u00e0. Secondo questa classificazione, le espressioni regolari possono descrivere solo le regole del firewall che non prevedono deviazioni dal modello. Ci\u00f2 significa che gli aggressori possono facilmente \"ingannare\" le WAF di prima generazione. Uno dei metodi per contrastare questo \u00e8 aggiungere ai richieste alle applicazioni caratteri speciali che non influenzano la logica dei dati dannosi, ma infrangono la regola di firma.<\/p>\n

\"L'evoluzione
\n
\nSecondo genere<\/b>. Per affrontare le problematiche legate alle prestazioni e all'accuratezza dei WAF, sono stati sviluppati i firewall per applicazioni di seconda generazione. Questi includono parser progettati per identificare tipi specifici di attacchi (come HTML, JS, ecc.). I parser lavorano con token speciali che descrivono le richieste (ad esempio, variabile, stringa, sconosciuto, numero). Le sequenze di token potenzialmente dannose vengono raccolte in un elenco separato, che viene regolarmente confrontato dal sistema WAF. Questo approccio \u00e8 stato presentato per la prima volta alla conferenza Black Hat 2012 in forma di C\/C++\u00a0librerie libinjection<\/a><\/noindex>, che consentono di individuare le SQL injection.<\/p>\n

Rispetto ai WAF di prima generazione, i parser specializzati possono funzionare pi\u00f9 rapidamente. Tuttavia, non hanno risolto le difficolt\u00e0 legate alla configurazione manuale del sistema quando appaiono nuovi attacchi malevoli. <\/p>\n

\"L'evoluzione
\n
\nTerzo genere<\/b>. L'evoluzione nella logica di rilevamento del terzo genere si basa sull'applicazione di metodi di machine learning, che consentono di avvicinare al massimo la grammatica di rilevamento alla grammatica reale di SQL\/HTML\/JS dei sistemi protetti. Questa logica di rilevamento \u00e8 in grado di adattare la macchina di Turing per coprire grammatiche ricorsivamente enumerabili. In precedenza, il compito di creare una macchina di Turing adattabile era insolubile, fino alla pubblicazione delle prime ricerche su macchine di Turing neuronali.<\/p>\n

Il machine learning offre un'opportunit\u00e0 unica di adattare qualsiasi grammatica per coprire qualsiasi tipo di attacco senza dover creare manualmente liste di firme, come era necessario per il rilevamento di prima generazione, e senza sviluppare nuovi tokenizzatori\/parser per nuovi tipi di attacchi, come le iniezioni di Memcached, Redis, Cassandra, SSRF, come richiedeva la metodologia di seconda generazione. <\/p>\n

Combinando tutti e tre i generi di logica di rilevamento, possiamo tracciare un nuovo diagramma, nel quale il terzo genere di rilevamento \u00e8 rappresentato da un contorno rosso (fig. 3). Tra questo genere si trova una delle soluzioni che implementiamo nel cloud insieme a \u00abOnsec\u00bb, sviluppatore della piattaforma di protezione adattativa per applicazioni web e API Valarm. <\/p>\n

Ora, nella logica di rilevamento, si utilizza il feedback dell'applicazione per l'auto-regolazione. Nel contesto del machine learning, questo ciclo di feedback \u00e8 chiamato \u00abrinforzo\u00bb. In genere, ci sono uno o pi\u00f9 tipi di tale rinforzo:<\/p>\n