È ormai acclarato che la Dmz costituisca il “fossato con i coccodrilli” per il proprio “castello” di informazioni. Se l’attacker la supera, però, ha quasi partita vinta. Ecco perché è utile sapere come va strutturata, consapevoli che, per quanto ben fatta, non è sufficiente.
La zona demilitarizzata (Dmz) è di fatto cruciale per le organizzazioni che forniscono servizi ai clienti, business partner o utenti remoti. Dal punto di vista dell’attacker, invece, compromettere una macchina nella parte di Dmz significa essere a un passo dalla compromissione totale della rete. Uno degli errori che si compiono spesso, infatti, consiste nel credere che la Dmz, in quanto fondamentalmente separata dal resto della struttura, costituisca un limite insormontabile dagli attacker. Questo non è del tutto vero. Ogni organizzazione, quindi, dovrebbe avere una visione chiara del ruolo della Dmz.
Le architetture principali
Negli ultimi anni si sono sviluppate due correnti di design architetturale delle zone demilitarizzate. Sia l’una sia l’altra sono fondamentalmente legate alla letteratura di importanti vendor quali Ibm (la prima) e Check Point la seconda. Uno degli impegni maggiori da parte dei security engineer è proprio quello di valutare i pro e i contro delle due architetture.
La prima vede due livelli firewall in mezzo ai quali vengono posizionati i servizi ad accesso pubblico che costituiscono la zona in argomento. Il primo livello fornisce un primo filtraggio/routing, mentre il secondo si occupa di gestire il colloquio delle macchine direttamente con la rete interna. Nel caso si dovesse optare per questa scelta, si avrà da un lato la possibilità di differenziare il filtraggio (packet filtering o dynamic stateful sul primo perimetro e application proxy "dietro", per esempio) e di gestire le performance in maniera più organica e granulare, anche dal punto di vista dei denial of service. Alcuni, per esempio, gestiscono il primo livello con il software di firewalling contenuto nel router, mentre affidano al secondo strato un esame più approfondito e granulare del traffico. In un mondo perfetto, ove gli standard tecnologici sono rispettati e l’integrazione non dovrebbe, quindi, costituire un problema, un approccio di questo tipo potrebbe anche risultare interessante. Tuttavia il problema consiste proprio nella difficoltà di integrazione tra prodotti di vendor differenti e, nei casi pratici, di problemi addirittura nella fase implementativa. Nella sicurezza informatica, poi, ove lo "scaricabarile" è molto praticato, il cliente potrebbe anche subire dei grossi rallentamenti dei processi produttivi. Questo non significa che detta formula vada scartata a priori, ma che, ovviamente bisogna valutarne in maniera concreta i pro e i contro. Diversa, invece, è la seconda impostazione architetturale che vede la Dmz "relegata" a zone dipendenti da una o più schede di un unico livello di firewalling che gestisce l’intera architettura. Se da un lato i problemi di integrazione verrebbero in parte attenuati, dall’altro si corre il rischio di creare un collo di bottiglia prestazionale, se non è stato previsto un reale sistema di bilanciamento del carico e di gestione proattiva di determinati attacchi, specie quelli rivolti contro i Web server.
Pericoli evidenti e soluzioni
Nelle procedure di analisi del rischio relative alle esposizioni in Dmz si guarda, in prima battuta, alle condizioni dei servizi Web. Questi ultimi, di solito, sono esposti non solo ai Denial of Service ma anche al malicious code. In questo caso, quindi, bisogna aggiungere al posizionamento in Dmz anche un layer ulteriore di sicurezza, del tipo content security. Per la posta in ingresso, invece, una soluzione antispam deve comunque essere contemplata, così come un sistema di strong authentication per gli accessi remoti. Pur se posizionati in Dmz, infatti, molti servizi hanno trust relationship verso l’interno che devono essere corroborate da misure di sicurezza aggiuntive rispetto al discorso firewalling puro. Ecco, quindi, presentarsi un’altra procedura di massima importanza relativa a dette risorse, denominata hardening. Quest’ultima, insieme all’uso di Ids per logging e monitoraggio, è utile per mitigare i potenziali rischi di compromissione, e consiste nel rafforzamento della base installata, consistente altresì nell’aggiornamento e nello "stripping" di servizi inutili prima della messa in produzione delle macchine.
