Il crepuscolo dei firewall?È un po' di tempo che trovo il panorama dei prodotti firewall piuttosto monotono e deprimente. A peggiorare le cose, in questi giorni, sulla mailing-list "firewall-wizards", sono apparsi alcuni messaggi sul confronto fra due diversi prodotti; uno di questi messaggi diceva più o meno: "I parametri per il confronto sono quattro: costo, prestazioni, assistenza, tecnologia. Come prestazioni e come assistenza di due prodotti sono equivalenti, entrambi usano stateful inspection e quindi sono blindati, uno costa di più. " Immaginiamo un confronto del genere fra due DBMS che dica: "entrambi prodotti gestiscono database relazionali e quindi sono equivalenti ". Mentre pochi di noi prenderebbero sul serio che facesse la seconda affermazione, a quanto pare molti invece sono disposti a prendere in considerazione la prima. In effetti, sembra che i dettagli delle funzionalità di sicurezza dei firewall interessino sempre meno, come se, in fondo, tutti firewall funzionassero allo stesso modo. Vorrei innanzi tutto ricordare che cos'è un firewall. Non è un semplice problema accademico di definizioni, perché dietro molte definizioni sbagliate che si possono sentire in giro, si vede in realtà una percezione realmente sbagliata di cosa sia un firewall e di cosa possa o debba fare. Per evitare inutili dubbi, non darò una definizione mia, ma riporterò quelle che si trovano in alcuni testi fondamentali. La prima la prendo dal libro " Firewalls and Internet Security", di Cheswick e Bellovin; è un libro del 1994, quando ancora concetto di stateful inspection era poco più che teoria (la traduzione è piuttosto libera): "un firewall è un insieme di componenti messi fra due reti, che, collettivamente, hanno le seguenti proprietà:
La seconda definizione viene da "Building Internet Firewalls, 2nd. ed.", di Zwicky, Cooper, Chapman. Il libro è stato pubblicato nel giugno del 2000, ed è probabilmente il miglior libro sui firewall attualmente disponibile. In effetti non sono riuscito a trovare una vera definizione di firewall: c'è piuttosto un paragrafo che cerca di darne una descrizione. Anche qui traduco liberamente: "... In pratica, un firewall assomiglia al fossato di un castello medievale... Ha diverse funzioni:
...Un firewall raramente è un unico oggetto fisico, anche se alcuni prodotti commerciali cercano di mettere tutto in un'unica scatola. Normalmente, un firewall è composto da più parti e alcune di queste parti possono avere altre funzioni oltre a quelle del firewall." Come si vede, nessuna delle due definizioni stabilisce quale tecnologia debba essere utilizzata o quante siano le componenti del firewall; tendono anzi a sottolineare sia la generalità del termine, sia la molteplicità delle componenti. Proviamo adesso a tornare al 1994 (se ben ricordo), quando Firewall-1 e la stateful inspection non c'erano. Allora le tecnologie disponibili erano sostanzialmente due: filtraggio statico o proxy. I proxy erano considerati generalmente superiori perché potevano ispezionare i dati a livello applicativo, seppure con la difficoltà, che stava per essere in parte superata con i proxy trasparenti, di indicare il servizio destinatario della connessione. A porsi problemi di sicurezza su Internet erano ancora relativamente pochi, ma quei pochi erano sicuramente più interessati alla sicurezza che alle prestazioni. L'attenzione per i firewall si stava però diffondendo, e la banda disponibile stava aumentando; pian piano è così nato il panico da prestazioni, con il timore che il firewall potesse costituire il collo di bottiglia della connessione con Internet. Nel frattempo, e come sempre è difficile capire quale sia la causa e quale sia l'effetto, Checkpoint proponeva Firewall-1 e la stateful inspection, che prometteva, almeno in teoria, un controllo da proxy e prestazioni da packet filter. Da allora è passato parecchio tempo, almeno secondo la scala di Internet. Adesso le prestazioni sembrano essere di gran lunga la preoccupazione maggiore, mentre le caratteristiche di sicurezza sembrano essere in secondo piano, anche perché l'uso di firewall si è diffuso in ambienti meno specializzati, e la selezione fra i prodotti è fatta secondo un'ottica più commerciale e meno tecnica; mentre le prestazioni sono facili da vendere e da capire, distinguere fra le diverse caratteristiche di sicurezza richiede una preparazione più specifica. Per verificare questa affermazione basta vedere la documentazione, tecnica o commerciale che sia, dei vari prodotti: difficilmente si riuscirà a capire cosa e come controlli effettivamente il firewall, salvo poche funzionalità di base comuni a tutti; si troveranno invece abbondanti informazioni sulla banda del prodotto è in grado di gestire. Devo dire che io sono un fautore dei proxy: lo ero nel 1994 e lo sono rimasto. La mia preoccupazione tuttavia è più per la scarsa attenzione alle funzionalità di sicurezza dei firewall in generale che per la tecnologia utilizzata. Il problema è che adesso, dicendo "stateful inspection", sembra che si sia detto tutto il massimo possibile dal punto di vista della sicurezza e delle prestazioni. In compenso, sembra che alcuni ritengano che filtri statici (come si possono trovare su un router) e proxy non siano nemmeno tecnologie di firewall. Cerchiamo invece di capire come stanno realmente le cose dal punto di vista tecnico, premesso che non voglio generalizzare criticando la qualità dell'uno dell'altro prodotto, e che per ogni mia affermazione sicuramente esisterà un qualche prodotto che la smentisce; a me però interessa un discorso generale, dato che nessun prodotto che io conosca si salva dalla gran parte delle critiche. Per prima cosa dividiamo grossolanamente i controlli di un firewall in quattro categorie (non sta considerando le funzionalità di autenticazione o vpn ): - selezione dei pacchetti, per evitare attacchi ai livelli più bassi come pacchetti malformati, spoofing, scan e simili; - selezione delle connessioni e dei servizi, con particolare attenzione alle porte aperte dinamicamente; - verifica della correttezza sintattica dei protocolli e dell'ordine corretto dei comandi; - esame dei dati a livello applicativo, dalla ricerca dei virus, alla selezione delle URL, alla rilevazione di attacchi noti. Per la categoria più bassa, tutte le tecnologie andrebbero potenzialmente bene, con l'eccezione forse degli scan, la cui rilevazione richiederebbe comunque di mantenere uno stato, il che escluderebbe i filtri statici. I proxy però non hanno bisogno di nessuna regola o precauzione particolare per proteggere una rete da questi atti, in quanto la protezione è insita nel meccanismo del proxy. I controlli effettuati da molti prodotti di packet filtering sono però inferiori a quelli possibili, e generalmente sono anche poco personalizzabili. Un altro punto a sfavore dei packet filter è che su questo tipo di problematiche devono utilizzare una politica di default permit, ovvero devono riconoscere un’anomalia pericolosa nel pacchetto per bloccarlo, altrimenti lo lasciano passare. Un punto a loro favore è invece che trattano i pacchetti come router e non come host, e quindi in generale rischiano meno di essere essi stessi vittima del pacchetto che devono bloccare. Arrivati alla seconda categoria i filtri statici ci abbandonano, a meno di trascurare le porte aperte dinamicamente, e nella maggior parte dei casi si comincia ad avere bisogno di analizzare i protocolli per capire quali siano le porte implicate; già a questo punto ci rimangono solo la stateful inspection e i proxy. Questo vuol dire che un prodotto che sia in grado di esaminare il traffico ftp per capire quali porte si trovi la connessione dati si può già fregiare del titolo di "firewall basato stateful inspection"; tutti i controlli che si possono fare da questo livello in poi, quindi, ricadono sotto la stessa buzzword, indipendentemente da quanti sono implementati. Notate che non sto dicendo che i filtri statici siano inutili: in molte architetture, accuratamente progettate, possono comunque risolvere moltissimi problemi; in questi casi però la protezione deriva molto più dalla topologia della rete e dalla distribuzione dei servizi sui sistemi che dalla tecnologia firewall utilizzata. I packet filter statici sono poi generalmente parte di qualsiasi firewall un po’ più complesso del singolo bastion host. Giungiamo quindi all'ultima categoria; basta seguire una qualsiasi mailing-list che si occupi di sicurezza per capire che la maggior parte degli attacchi è realizzata a questo livello. Almeno in teoria, sia proxy che stateful packet filter dovrebbero essere in grado di gestire questo livello. È qui però che i firewall mostrano i loro limiti, siano essi proxy o meno. Per prima cosa una precisazione: prodotti come Firewall-1, che vantavano la superiorità delle prestazioni dello stateful packet filtering, sono di fatto passati a un controllo a livello applicativo per i protocolli per i quali vengono effettuati controlli più approfonditi (i cosiddetti Security Server); magari le prestazioni saranno un po' migliore in conseguenza dell'architettura ottimizzata, ma in fondo quello che si ottiene non è poi tanto diverso da un proxy. Parte del flusso di dati viene infatti ricostruito e passato ad applicazioni che lavorano in aree utente; inoltre, dato che i controlli sono più complessi, e quindi richiedono un certo tempo, ci si può chiedere se il tempo risparmiato dal non utilizzo di un vero proxy vale la complessità del meccanismo; il dubbio è tanto più valido quando i security server passano addirittura i dati da analizzare a un sistema esterno, come può succedere per i controlli antivirus. Quali sono i controlli che sono effettivamente realizzati a livello applicativo, indipendentemente dalla tecnologia? In realtà sono ben pochi: un po' di filtraggio delle URL, qualche controllo sul virus e trojan horse, ed eventualmente l'eliminazione del contenuto attivo delle pagine, cosa che è sempre più difficile proporre dato che rende inutilizzabili una buona parte dei siti Internet. Nel migliore dei casi, un controllo sul MIME type. Il tutto esclusivamente su tre protocolli: HTTP, FTP, SMTP. La prima ovvia domanda è: cosa viene effettivamente controllato sugli altri protocolli, meno utilizzati e quindi seguiti con meno attenzione dagli utenti di questi prodotti? Difficilmente si troverà qualche cosa nella documentazione o nella manualistica dei prodotti. Prendete un qualsiasi firewall che dica, ad esempio, di "trattare" il protocollo IMAP, o SNMP, o ICQ, e cercate di capire cosa controlli di quel protocollo, a parte eventuali autenticazioni aggiuntive eppure tutti sono stati oggetto o tramite di numerosi attacchi. Di fatto, è molto probabile che controlli siano praticamente nulli; la maggior parte dei firewall, pur affermando di gestire decine di protocolli, tutto quello che fa è selezionare la porta corrispondente. Questo è proprio quanto di peggio ci si potrebbe aspettare da un firewall: affermare di gestire un servizio ma in realtà lasciarlo passare così com'è, aggravando il già eccessivo senso di sicurezza degli utenti meno smaliziati. I firewall che affermano di fare stateful filtering sono proprio quelli che, principalmente per motivi commerciali, ma grazie al tipo di tecnologia utilizzata, sfruttano più spesso questo tipo di ambiguità (naturalmente ci sono prodotti e prodotti, ma mi sembra inutile sottolineare per l'ennesima volta questo fatto): quando si lavora a livello di pacchetti e non si sa cosa fare, c'è sempre l'opzione di lasciar passare del traffico senza controllarlo, cosa che con i proxy è possibile solo in alcuni casi. Purtroppo temo che sia questo il principale motivo del grande successo di questa tecnologia: fare dei "buchi" in un packet filter è molto più semplice che farli in un proxy. Questo non vuol dire che i firewall basati su proxy siano scomparsi: non mi sembra però che controlli effettuati dei prodotti attuali siano in qualche modo migliori, almeno a livello applicativo. Perché non vengono effettuati controlli più approfonditi? Non che manchi la richiesta di maggiori verifiche; semplicemente, queste non sono effettuate sui prodotti firewall. Tipicamente a questo scopo sono utilizzati dei sistemi di intrusion detection. La domanda successiva, ovvia, è perché questi controlli non siano effettuati sui firewall. Esiste una (e per quello che ne so io, una sola) ha ragione valida: minori sono i controlli, più semplice è il prodotto, più difficile è introdurre difetti: dato che per certi controlli il firewall si dovrebbe comportare come un client nei confronti dei server e come un server nei confronti dei client, un controllo approfondito potrebbe portare una complessità paragonabile a quella delle applicazioni che cerca di proteggere, con un’equivalente possibilità di errore. Spostare questi controlli su un sistema di intrusion detection permette di mantenere il firewall molto più semplice. È una ragione sufficiente? Non credo, o almeno non del tutto: il problema esiste, ma è diverso a seconda della tecnologia utilizzata, e non è detto che un sistema di intrusion detection sia una soluzione migliore. Vediamo perché. Esiste una differenza fondamentale fra un controllo effettuato su un firewall e un effettuato dal sistema di intrusion detection: se controllo è effettuato dal firewall, questo può immediatamente impedire il passaggio del traffico; se il controllo è fatto da un sistema di intrusion detection, intanto l'attacco passa, e poi forse, con i dovuti limiti, il sistema di intrusion detection potrà prendere qualche provvedimento. Vediamola dal punto di vista della politica di sicurezza: se questa dice che il traffico non è permesso, il traffico non deve passare: rilevare il fatto che stia passando non è in se è sufficiente. Non che stia dicendo che controlli di un sistema di intrusion detection siano inutili: vanno utilizzati nei giusti contesti e non sono alternativi a quelli che dovrebbe effettuare un firewall. Perché allora i firewall non implementano gli stessi controlli? Io credo che la ragione principale sia come sempre la paura delle prestazioni: se un controllo è complesso e viene effettuato su un firewall, il firewall potrebbe essere sovraccaricato e quindi bloccare il traffico che non è in grado di gestire, compreso quello legittimo; se un sistema di intrusion detection viene sovraccaricato, perde dei pacchetti ma il traffico non viene fermato. Incredibilmente, la seconda situazione, molto meno sicura, è considerata più tranquillizzante da molti responsabili della sicurezza, che si trovano spesso a dover giustificare le proprie attività nei confronti delle esigenze di servizi e utenti, a quanto pare tutte con priorità più alta della sicurezza; in particolare, tutti temono il famigerato spreco di banda. Torniamo quindi al problema delle prestazioni: il firewall effettua pochi controlli e li demanda ai sistemi di intrusion detection principalmente perché così le prestazioni sono migliori e non c'è spreco di banda. Questa preoccupazione si vede anche in alcuni prodotti che in origine erano basati solo su proxy, ma che poi sono passati a un’architettura mista proxy/packet filter, dove i proxy sono disponibili solo per (indovinate) FTP, HTTP, SMTP La domanda a questo punto è: se il firewall e il sistema di intrusion detection in serie riescono a effettuare tutti i controlli necessari, un sistema con le prestazioni dei due sommati non dovrebbe riuscire a fare gli stessi controlli? Prendiamo il caso di un proxy: per gestire la connessione, anzi le connessioni visto che nel caso di proxy sono due, deve separare il traffico delle diverse connessioni, ordinarlo ed analizzarlo. A parte l'analisi, le stesse operazioni devono comunque essere effettuate sia da un firewall che faccia stateful inspection, sia dal sistema di intrusion detection: questa attività quindi è ripetuta due volte. Dal punto di vista delle prestazioni quindi, posto che non si sia disposti a lasciar passare del traffico illegittimo, parrebbe quasi che i controlli effettuati su un singolo sistema debbano essere più efficienti di quelli effettuati su due sistemi separati. E la complessità? Utilizzando un proxy le attività di assemblaggio dei pacchetti e selezione delle connessioni sono effettuate dal kernel, mentre controlli a livello applicativo sono effettuati, appunto, da un'applicazione, che per sua natura è particolarmente adatta a lavorare a questo livello. La complessità delle due operazioni e quindi comunque separata. Diverso è il discorso quando si parla di stateful packet filtering, dove effettivamente la complessità potrebbe essere maggiore. Un'altra motivazione che si sente spesso per la separazione fra ids e firewall è che la configurazione di un firewall dell'essere semplice e cambiare il meno spesso possibile, mentre i controlli a livello applicativo richiedono aggiornamenti frequenti; a me sembra che la selezione dei servizi, piuttosto statica, e i controlli a livello applicativo, da aggiornare frequentemente, possano essere separati con facilità anche sul singolo sistema. Tutti discorsi già sentiti dai sostenitori dei proxy, vero? Ma se le cose non sono fatte così ci sarà un motivo... vediamo. Negli ultimi tempi, almeno per il protocollo HTTP, sono stati presentati una serie di nuovi prodotti e di nuove configurazioni. Alcuni prodotti, come (a puro titolo di esempio) Entercept, cercano di effettuare proprio quei controlli che mancavano al firewall, anche se il controllo è effettuato sul server Web. Al centro delle nuove configurazioni c'è invece il concetto di reverse proxy, ovvero un proxy posto davanti a un server anziché davanti a un client. La cosa interessante è che questi prodotti e configurazioni, nel complesso, realizzano proprio i controlli basati su proxy di cui sembrava che sui firewall non ci fosse bisogno; e questi controlli sono effettuati proprio sul traffico a HTTP, cioè su quello che, nella maggior parte dei casi, occupa la maggior parte della banda disponibile. Dove va a finire allora il problema delle prestazioni? Forse non era così reale e drammatico, almeno in molti casi... Il fatto è che questi strumenti sono genralmente utilizzati per proteggere server Web, spesso anche grossi o con seri requisiti di sicurezza: situazioni nelle quali quindi le problematiche di banda e di prestazioni sono (si spera) studiate e dimensionate realmente, e quindi la paura per la mancanza di banda è affrontata quando necessario e con una certa razionalità. La situazione si farà ancora interessante con lo sviluppo sempre più incalzante delle applicazioni basate su XML. I motivi sono sostanzialmente due: - ancora più applicazioni utilizzeranno il protocollo http per portare ogni genere di traffico, e quindi, a parte protocolli storici come ftp o altri protocolli con usi particolari come quelli per audio/video, la selezione del traffico in base alle porte diventerà sempre meno utile e interessante: i controlli dovranno necessariamente essere effettuati a livello applicativo; - l'uso di XML renderà molto più evidente all'interno del flusso dei dati la semantica delle informazioni trasmesse, rendendo i filtri e i controlli molto più efficaci di quelli attuali che, come informazione sui dati, spesso hanno al massimo il MIME type. Quello che mi aspetto quindi, è che applicazioni proxy per i controlli a livello applicativo del traffico HTTP diventino sempre più diffuse. Mentre quindi i firewall come sono spesso intesi adesso, ovvero semplici stateful packet filter con limitati controlli sui dati, saranno sempre più integrati in apparecchiature come router e modem, per i controlli più significativi si utilizzeranno proxy, il che renderà evidente ancor più che adesso che un firewall non è un semplice prodotto software ma un insieme di componenti. Con l'occasione forse, si vedrà finalmente sviluppare qualche prodotto public domain che non sia il solito packet filter, dato che al momento il panorama è piuttosto desolante. Dopo tanti anni nei quali lo sviluppo dei firewall è stato praticamente nullo, se non consideriamo funzionalità come le vpn o funzionalità non strettamente di sicurezza, mi sembra quindi che prossimamente ci potrà essere un balzo in avanti di questa tecnologia che continua ad essere fondamentale per la sicurezza di una rete. O forse è solo una mia speranza Un'ultima considerazione: i firewall sono una realtà della quale ormai tengono conto anche coloro che si occupano della sperimentazione di nuovi protocolli. Due casi recenti come esempio: le discussioni, parte delle quali avvenute su firewall-wizards, sull'invio improprio di TCP RST e sul filtraggio di SOAP/XML in base all'header SOAPAction (basta una ricerca sugli archivi di maggio della mailing-list). |
NovitàIn questo spazio metto informazioni più estemporanee e quindi anche meno verificate. 01/06/2001
20/06/2001 Saro' a Ischia al
|
Si declina ogni responsabilità per danni derivanti dall'accesso a questo sito o per l'uso delle informazioni in esso contenute.
Questa pagina è stata realizzata con Amaya e fa uso di Style Sheets.