FIREWALL (r)EVOLUTION

FIREWALL (r)EVOLUTION

il firewalling di ieri, oggi e forse domani…

Questo articolo presenta un breve excursus sulle novitá  tecniche che hanno caratterizzato la storia del firewalling, presenta la situazione attuale e analizza un possibile futuro.

Non intendo fare pubblicitá  a nessun produttore e neanche entrare nella diatriba opensource/vendor.

In principio erano i packet filter.

Chiudere le porte, questo era l’obiettivo degli amministratori di rete che per primi sentirono la necessitá  di avere un punto di controllo (poi chiamato firewall) del traffico all’interno delle loro reti.

Filtrare il traffico, lasciando passare solo i protocolli, gli IP e le porte necessarie.

Successivamente le esigenze aumentarono, e nacquero i primi firewall statefull inspection, i quali non solo fanno passare il traffico secondo protocollo/porta/IP, ma tengono anche traccia della sessione.

Seguirono gli anni in cui i firewall iniziarono a diffondersi pesantemente, riconosciuti come elementi fondamentali non solo della sicurezza, ma delle reti stesse. Questo perché il firewall per poter analizzare i flussi di traffico tra i vari network deve necessariamente avere una posizione centrale.

Una volta che le reti si sono riempite di apparati di firewalling é nata una nuova esigenza: la gestione.

E tutti i produttori si sono mossi per fornire agli staff tecnici interfacce di management, monitoring e analisi centralizzata capaci di gestire una multitudine di macchine da una postazione centrale.

E fin qui siamo arrivati all’anno 2002.

Facendo il punto della situazione, possiamo gestire da una postazione centrale multipli firewall che filtrano il traffico capendo se il pacchetto appartiene ad una sessione giá stabilita o meno.

A questo punto é sorto peró un problema.

Un firewall posto a protezione del web server aziendale puó bloccare tutto il traffico ad esclusione delle sessioni destinate alla porta 80/TCP, necessaria per l’utilizzo del web server.

Ma in questo modo abbiamo la porta 80/TCP esposta ad ogni sorta di attacchi, e il firewall non puó essere il nostro unico strumento di difesa.

Ma vediamola anche in un’ottica diversa: un’azienda con migliaia di computer consente ai propri dipendenti la navigazione internet (porte 80/TCP e 443/TCP) e il protocollo di trasferimento file FTP (porta 21).

Tutte le altre porte sono chiuse, impedendo ai dipendenti l’utilizzo di tutta una serie di applicazioni che, secondo le policy aziendali, vanno contro la produttivitá.

Una politica di filtraggio del traffico in uscita di questo tipo era considerata un buon livello di sicurezza, fino a qualche annetto fa.

Ma con lo sviluppo delle applicazioni é diventato facile aggirare un firewall semplicemente cambiando la porta utilizzata per le comunicazioni.

Facciamo il caso del nostro amato software di istant messaging (IM): ICQ. (www.icq.com)

In questa pagina https://www.icq.com/icqtour/firewall/https.html troverete come far passare tutto il traffico di ICQ sulla porta HTTPS (443/TCP).

Se gli IM fanno perdere produttivitá, i software di P2P e file sharing rischiano di far perdere credibilitá ad un’azienda.

Basti pensare alla campagna che si sta sollevando proprio in questo periodo contro il file sharing a protezione dei diritti d’autore, con la discussa legge Urbani che anche se non verrá approvata evidenzia molto bene la strada che si sta tracciando contro la diffusione di materiale illegale in Internet.

Non voglio assolutamente entrare nel merito di questo decreto perché non é l’obiettivo di questo articolo, il punto casomai é un altro.

Chi gestisce una rete aziendale si DEVE porre il problema del P2P e di come difendere la propria azienda.

Basta che un utente su 100 si mette a scaricare film protetti dai diritti d’autore per compromettere tutta la societá.

Tornando ai nostri cari firewall, come possono difenderci?

Ci vengono in aiuto i firewall con content inspection quelli cioé che fanno analisi del protocollo.

Questi prodotti non si accontentano piú di analizzare una sessione basandosi sulle porte utilizzate, ma verifica che la SEMANTICA del protocollo sia quella corretta.

Facendo l’esempio del traffico HTTP, verificherá che il traffico che passa sulla porta 80/TCP siano GET, POST, HEAD… cioé traffico effettivamente HTTP.

Spostare un server FTP dalla porta 21/TCP alla porta 80/TCP non basta piú per raggirare il firewall, perché il protocollo FTP ha una sintassi differente (fatta di LS, PUT, GET parametrizzare in un certo modo) rispetto al protocollo HTTP.

Questo é un passo fondamentale nelle tecnologie di firewalling: spostarsi dal livello di rete ai livelli piú alti addentrandosi sempre di piú nei pacchetti ispezionati.

I firewall diventano sempre piú intelligenti.

I firewall analizzano livelli del modello ISO/OSI sempre piú elevati.

Ma l’evoluzione non si é fermata a questo traguardo, perchå le minacce hanno fatto di nuovo evolvere le esigenze dei clienti.

Gli attacchi e le vulnerabilitá infatti si sono sempre piú spostate verso il livello applicativo.

Torniamo al nostro esempio del firewall che protegge il nostro web server aziendale.

Un buon firewall content inspection puó per esempio consentire solo alcuni “comandi”forniti dal protocollo HTTP, ad esempio puó permettere che client remoti su Internet richiedano delle pagine (GET HTTP) oppure richiedano informazioni su una pagina (HEAD HTTP) ma non possano inviare dei dati al web server (POST HTTP).

Non puó peró proteggerci da tutte le vunlerabilitá del nostro web server, e da tutti gli attacchi a livello applicativo.

E, neanche a farlo apposta, é proprio in questa direzione che si stanno muovendo tutte le recenti tipologie di attacco informatico. La minaccia ormai viaggia a livello applicativo, proprio dove i firewall non possono agire…

Ma in aiuto del firewalling é arrivato un altro strumento da anni a disposizione degli amministratori di rete: l’intrusion detection.

Il 2003 infatti ha fatto fiorire una nuova frontiera per il firewalling: l’intrusion prevention (IPS).

L’intrusion prevention nasce come evoluzione dell’intrusion detection.

Mentre l’intrusion detection permette di monitorare l’attivitá di rete e delle macchine al fine di rilevare eventuali anomalie e/o attacchi, l’intrusion prevention si spinge oltre tentando di bloccare tale traffico.

E’ un compito molto arduo, che non amette errori, perché bloccare traffico LECITO puó essere piú grave che lasciar passare un tentativo di intrusione che sfrutta un exploit a cui i nostri sistemi non sono vulnerabili.

Questo tipo di tecnologia é stato accolto con scetticismo nel settore, tanto che un’analisi del Gartner Group (luglio 2003) in cui si dichiarava morta l’Intrusion Detection a tutto favore degli IPS é stata aspramente criticata. (https://www.gartner.com/5_about/press_releases/pr11june2003c.jsp)

Tuttavia i vari produttori hanno raccolto la sfida e si sono prodigati per integrare nei loro prodotti firewall le funzionalità di intrusion prevention.

Torniamo ancora una volta al nostro esempio del firewall a protezione del web server aziendale.

Un client maleducato tenta di accedere al file ROOT.EXE che a suo tempo veniva installato da Code Red (può sembrare strano ma ancora oggi i tentativi di questo tipo non mancano, guardate i log dei vostri web server!):

GET /scripts/root.exe HTTP/1.1

Questo è il comando GET HTTP che invierà, accludendo tutta un’altra serie di informazioni che qui ometto.

Il nostro content inspection firewall verifica che le GET sono autorizzate e lascia passare la richiesta.

Se avessimo avuto un firewall con IPS avrebbe bloccato una richiesta di questo tipo, perchè riconosciuta come illecita.

Oltre a fermare atacchi NOTI, come quello qui mostrato, consente di bloccare anche traffico ritenuto anomalo anche se non associato a nessun attacco già conosciuto.

Per esempio, bloccare le richieste HTTP con header MOLTO lunghi potrebbe salvare il nostro web server da uno zero-day exploit che sfrutta un buffer overflow.

Oppure, potrebbe bloccare l’utilizzo della web-mail di Yahoo, come accade con un famoso firewall con intrusion prevention in configurazione di default…

Qui però nasce un altro punto di riflessione.

Lasciare che un firewall lavori a livello applicativo significa che c’è un livello di collaborazione tra chi si occupa di sicurezza in azienda e chi si occupa delle applicazioni, cosa che è ancora oggi difficile da trovare.

La sicurezza viene ancora vista come attività di competenza di chi si occupa di networking, settore dal quale provengono molti degli attuali responsabili della sicurezza.

Ma la sicurezza è un’attività TRASVERSALE, che DEVE abbracciare ogni settore e vi ci si deve amalgamare…

Siamo arrivati alla fine? Non ancora. Manca l’ultima frontiera, quella che si sta diffondendo in questo periodo: gli application firewall.

La definizione di questo tipo di prodotti è ancora un po’ vaga e fonte di confusione, come sempre accade quando il marketing ci mette lo zampino. 😉

Molti dei prodotti che si presentano come application firewall sono, secondo me, dei firewall con estensioni di Intrusion Prevention, quindi, come abbiamo visto, firewall che lavorano a livello applicativo.

I veri application firewall sono, sempre IMHO, quei prodotti interamente dedicati alla protezione di un’applicazione.

Gli unici che ho avuto modo di vedere lavorano con le applicazioni web, senza dubbio le più minacciate, e con la posta elettronica, altro servizio chiave messo in scacco da virus e spam.

Torniamo per l’ultima volta all’esempio del web server aziendale. Lo avevamo lasciato protetto da un firewall con IPS, sicuramente un ottimo livello di protezione.

Però non ci aiuta se qualcuno prova ad attaccare proprio la nostra applicazione web.

Esempi comuni di attacchi di questo tipo sono la SQL Injection, i Cross Side scripting (XSS), ma anche tutti i tentativi di by-passare i meccanismi di input-validation messi in piedi dagli sviluppatori.

Vedo di fare un esempio di mancata input validation che sia il più banale possibile.

Supponiamo di avere una pagina che contiene un form in cui si specifica un codice numerico.

Inviando il form, l’applicazione restituisce i dettagli del prodotto associato a quel codice: una banale ricerca, in pratica.

Un client cattivo però inserisce invece di un codice numerico la stringa “1 OR 1=1” .

L’applicazione non è scritta a regola d’arte e non verifica che il parametro passato sia numerico, inserendolo nella query al database che può avere una sintassi di questo tipo:

“SELECT * FROM TABELLA WHERE ID=”

quindi nel nostro caso

“SELECT * FROM TABELLA WHERE ID=1 OR 1=1”

Questa SELECT restituirà TUTTI gli elementi contenuti nella tabella di nome TABELLA, perchè è vera per ogni elemento della tabella.

Se non siete pratici di SQL non vi preoccupate, cercate di capire il concetto.

Se abbiamo una tabella grossa, con molti elementi, questa query può creare problemi di performance all’applicazione e al DB, fino a creare dei veri e propri denial of service.

Come può, un firewall, aiutarci contro attacchi di questo tipo?

La risposta che ci forniscono i vendor sono appunto gli application firewall.

Questi apparati sono in grado di capire che “normalmente” QUEL form di QUELLA pagina viene compilato con un codice numerico, e interpreterà l’inserimento di un carattere alfanumerico come una infrazione che va bloccata.

Non entro nel dettaglio dei meccanismi usati, però ci sono prodotti che sono in grado di fare questo tipo di controlli quindi se volete approfondire è sufficiente una ricerca su un motore di ricerca con la chiave “application firewall”.

In definitiva, i firewall sono partiti analizzando i livelli 3-4 (prima IP/porta e poi le sessioni), per arrivare ai più avanzati controlli sul livello 7 (applicazione).

Stando all’attuale implementazione del modello ISO/OSI diremmo che non c’è molto altro da aggiungere.

Eppure sono due i fronti in cui i prodotti stanno evolvendo o si evolveranno nel futuro.

Il primo è l’integrazione. In una rete attuale ci sono, semplicemente, troppi elementi!

In grosse reti con grossi carichi abbiamo router, switch, bilanciatori, firewall, tutti elementi ridondati per avere alta affidabilità.

Questo significa aumentare esponenzialmente la complessità di implementazione e gestione a livello 2 (switch multipli, VLAN, Spanning Tree da gestire) e i costi per ridondare ogni elemento dell’infrastruttura.

Già oggi ci sono alcune soluzioni di integrazione, le quali permettono di raggruppare tutti questi elementi in macchine che utilizzano la tecnologia delle schede “blade” associate ad una gestione del fail-over e del networking integrato nella scheda di controllo.

Altre soluzioni di questo tipo arriveranno di sicuro a breve, considerando anche le partnership che si stanno formando tra i produttori di networking e i produttori di firewall.

Arriveranno tutti a fornire soluzioni integrate di switch/router modulari con schede dedicata al firewalling.

Un altro fronte interessante, molto più legato all’aspetto della sicurezza che non alla gestione, è quello del social engeneering.

E’ assodato che l’utente è l’elemento in assoluto più debole nella catena della sicurezza aziendale, come confermato anche nella nostra “Intervista ad un Gray Hat” dal misterioso BF.

E come riportato da una news comparsa su SecurityFocus proprio nei giorni in cui stavo scrivendo questo articolo: https://www.securityfocus.com/columnists/231

Come ci proteggeranno i firewall di domani da questa crescente insidia?

Forse non ci riusciranno mai, o forse dietro la porta ci sono già nuove fantastiche soluzioni che aspettano di essere utilizzate…

RIFERIMENTI

• Firewall Evolution – Deep Packet Inspection (Ido Dubrawsky)
  https://www.securityfocus.com/infocus/1716

• What is Egress Filtering and How Can I Implement It? (Chris Brenton)
  https://www.sans.org/rr/papers/index.php?id=1059

• The evolution of application layer firewalls
  https://www.nwfusion.com/news/2004/0202specialfocus.html