{"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":"Evoluzione del Web Application Firewall: dai firewall alla protezione cloud con machine learning","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Nel nostro precedente materiale sul tema del cloud abbiamo parlato<\/a><\/noindex>, come proteggere le risorse IT nel cloud pubblico e perch\u00e9 i tradizionali antivirus non sono del tutto adatti a questi scopi. In questo post continueremo il tema della sicurezza nel cloud e parleremo dell'evoluzione del WAF e di cosa sia meglio scegliere: hardware, software o cloud.\u00a0<\/b><\/p>\n

\"Evoluzione
\n<\/p>\n

Che cos'\u00e8 il WAF<\/h3>\n

\nOltre il 75% degli attacchi informatici \u00e8 indirizzato alle vulnerabilit\u00e0 delle applicazioni web e dei siti: tali attacchi, di norma, sono invisibili per l'infrastruttura di sicurezza informatica e per i servizi di sicurezza informatica. Le vulnerabilit\u00e0 delle applicazioni web comportano, a loro volta, rischi di compromissione e frode per gli account e i dati personali degli utenti, come password e numeri di carte di credito. Inoltre, le vulnerabilit\u00e0 nel sito web rappresentano un punto di accesso per i criminali nella rete aziendale.<\/p>\n

Il Web Application Firewall (WAF) \u00e8 uno schermo protettivo che blocca gli attacchi alle applicazioni web: iniezioni SQL, cross site scripting, esecuzione remota di codice, attacchi di forza bruta e bypass dell'autenticazione. Include anche attacchi che sfruttano vulnerabilit\u00e0 zero-day. I firewall delle applicazioni forniscono protezione monitorando i contenuti delle pagine web, inclusi HTML, DHTML e CSS, e filtrando 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 ai primi anni '90. Si conoscono almeno tre ingegneri che hanno lavorato in questo campo. Il primo \u00e8 il professor di informatica Gene Spafford dell'Universit\u00e0 di Purdue. Ha descritto l'architettura di un firewall per applicazioni con proxy e nel 1991 ha pubblicato il suo lavoro nel libro \u00abSicurezza UNIX in pratica\u00bb<\/a><\/noindex>.<\/p>\n

Il secondo e il terzo erano i professionisti della sicurezza informatica William Cheswick e Marcus Ranum dei Bell Labs. Hanno sviluppato uno dei primi prototipi di firewall per applicazioni. La sua diffusione \u00e8 stata gestita dalla societ\u00e0 DEC, che ha lanciato il prodotto sotto il nome SEAL (Secure External Access Link). <\/p>\n

Ma SEAL non era una soluzione WAF completa. Rappresentava un firewall di rete classico con funzionalit\u00e0 estese \u2014 in grado di bloccare attacchi su FTP e RSH. Per questa ragione, la prima soluzione WAF \u00e8 considerata oggi il prodotto della Perfecto Technologies (poi Sanctum). Nel 1999 ha ha presentato<\/a><\/noindex> il sistema AppShield. All'epoca, Perfecto Technologies era impegnata nello 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 di bloccare attacchi sulla base di politiche di sicurezza informatica dinamiche.<\/p>\n

Circa nello stesso periodo di AppShield (nel 2002) \u00e8 apparso il primo WAF con codice sorgente aperto. Questo \u00e8 diventato ModSecurity<\/a><\/noindex>. \u00c8 stato creato con l'obiettivo di promuovere le tecnologie WAF e viene ancora supportato dalla comunit\u00e0 IT (ecco il suo il repository su GitHub<\/a><\/noindex>). ModSecurity blocca gli attacchi alle applicazioni basandosi su un set standard di espressioni regolari (signature) \u2014 strumenti per controllare le richieste secondo un modello \u2014 Set di Regole Core OWASP<\/a><\/noindex>.<\/p>\n

In definitiva, gli sviluppatori sono riusciti a raggiungere il loro obiettivo \u2014 sono cominciate a sorgere nuove soluzioni WAF sul mercato, incluse quelle basate su ModSecurity.<\/p>\n

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

\nSi tende a distinguere tre generazioni di sistemi WAF, evolutisi con lo sviluppo della tecnologia.<\/p>\n

Prima generazione<\/b>. Funziona con espressioni regolari (o grammatiche). \u00c8 il caso di ModSecurity. Il fornitore del sistema studia i tipi di attacchi alle applicazioni e forma schemi che descrivono le richieste legittime e potenzialmente dannose. Il WAF confronta queste liste e decide cosa fare in una situazione specifica, \u2014 bloccare il traffico oppure no.<\/p>\n

Un esempio di rilevamento basato su espressioni regolari \u00e8 gi\u00e0 stato menzionato nel progetto Set di Regole Core<\/a><\/noindex> con codice sorgente aperto. Un altro esempio \u00e8 Naxsi<\/a><\/noindex>, che \u00e8 anch'esso open source. I sistemi basati su espressioni regolari presentano una serie di svantaggi, in particolare, quando viene scoperta una nuova vulnerabilit\u00e0, l'amministratore deve creare manualmente regole aggiuntive. Nel caso di un'infrastruttura IT di grandi dimensioni, il numero di regole pu\u00f2 arrivare a diverse migliaia. Gestire un numero cos\u00ec elevato di espressioni regolari \u00e8 piuttosto complicato, per non parlare del fatto che la loro verifica pu\u00f2 ridurre le prestazioni della rete.<\/p>\n

Le espressioni regolari hanno anche 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 condizionali. 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 combattere questo \u00e8 aggiungere simboli speciali nelle richieste alle applicazioni, che non influiscono sulla logica dei dati dannosi, ma violano la regola di firma.<\/p>\n

\"Evoluzione
\n
\nSeconda generazione<\/b>. Per superare i problemi legati alle prestazioni e all'accuratezza del WAF, sono stati sviluppati firewall per applicazioni di seconda generazione. Questi hanno introdotto parser responsabili dell'individuazione di tipi di attacco specifici (su HTML, JS, ecc.). Questi parser lavorano con token speciali che descrivono le richieste (ad esempio, variabile, stringa, sconosciuto, numero). Le sequenze di token potenzialmente dannose vengono riportate in un elenco separato, che viene verificato regolarmente dal sistema WAF. Questo approccio \u00e8 stato mostrato per la prima volta alla conferenza Black Hat 2012 attraverso la libreria C\/C++\u00a0libinjection<\/a><\/noindex>, che consente di rilevare le SQL injection.<\/p>\n

Rispetto al WAF di prima generazione, i parser specializzati possono funzionare pi\u00f9 velocemente. Tuttavia, non hanno risolto le difficolt\u00e0 legate alla configurazione manuale del sistema con l'emergere di nuovi attacchi dannosi. <\/p>\n

\"Evoluzione
\n
\nTerza generazione<\/b>. L'evoluzione nella logica di rilevamento della terza generazione si basa sull'applicazione di metodi di apprendimento automatico, che consentono di avvicinare al massimo la grammatica di rilevamento alla grammatica reale dei sistemi SQL\/HTML\/JS protetti. Questa logica di rilevamento \u00e8 in grado di adattare la macchina di Turing per coprire le grammatiche ricorsivamente enumerabili. Infatti, in precedenza, il compito di creare una macchina di Turing adattabile era irrisolvibile, finch\u00e9 non sono stati pubblicati i primi studi sulle macchine di Turing neuronali.<\/p>\n

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

Combinando tutte e tre le generazioni di logica di rilevamento, possiamo tracciare un nuovo diagramma, in cui la terza generazione di rilevamento \u00e8 rappresentata con un contorno rosso (fig. 3). A questa generazione appartiene una delle soluzioni che implementiamo nel cloud insieme a \"Onsec\", sviluppatore della piattaforma di protezione adattiva per applicazioni web e API Valarm. <\/p>\n

Ora la logica di rilevamento utilizza il feedback dall'applicazione per auto-regolarsi. Nell'ambito dell'apprendimento automatico, questo ciclo di feedback \u00e8 chiamato \"rinforzo\". In genere ci sono uno o pi\u00f9 tipi di tale rinforzo:<\/p>\n