Effettuare una schermatura profonda dei siti Internet può aiutare gli amministratori di sistema a proteggere i server dagli attacchi di worm. Una cura alle insicurezze può essere la soluzione basata sul “proxy opposto”, posizionato tra il firewall e la Dmz, come spiega Ubizen.
Irecenti fatti legati ai malicious code del tipo Nimda hanno nuovamente focalizzato l’attenzione sulla protezione dei server Web, non solo dai tentativi di defacement in generale, ma anche dalle violazioni di tipo automatizzato.
Tranne alcuni esempi "suicidi" di architecture designer che fanno tutto il contrario di quello che, anche a buon senso, si dovrebbe fare, i server Web vengono solitamente posizionati all’interno della cosiddetta Dmz (De-militarized zone). Il motivo di ciò risiede nel fatto che, qualora dovesse verificarsi una violazione di un sistema residente in questa sorta di zona neutrale, non dovrebbero essere possibili delle pericolose interazioni con il ben più importante back-end.
A ogni modo, per evitare a priori qualsiasi problema, parte della letteratura consiglia l’utilizzo dei cosiddetti "reverse proxy".
Un reverse proxy è un dispositivo che si occupa di effettuare uno "store and forward" del traffico diretto verso una delle risorse a lui date in gestione. L’obiettivo principale è quello di fungere da punto di controllo nei confronti delle chiamate provenienti dall’esterno su determinati obiettivi a rischio, come, per esempio, un Web server.
L’uso di un reverse proxy si basa sul presupposto fondamentale che, molto spesso, alcuni attacchi portati contro i server Web avvengono a livello applicazione e, a prescindere da questo, oltrepassano il firewall o per motivi di cattiva configurazione dello stesso, o proprio perché il firewall non è stato implementato con il fine di uno screening del traffico di basso livello.
Un altro motivo per cui, nonostante la presenza di un firewall, un attacco a livello di applicazione sia in grado di fare danni riguarda la cronica mancanza di un rafforzamento delle piattaforme esposte sulla rete pubblica. Uno degli obiettivi paralleli di questo tipo di protezione, quindi, è proprio quello di sopperire a questo tipo di mancanza.
Il posizionamento di un reverse proxy è tra il firewall e la Dmz. In pratica il sistema si pone come unico punto di transito e controllo delle chiamate alle varie applicazioni poste in zona demilitarizzata. Il forwarding bilaterale è consentito solo se la chiamata è lecita.
Un’implementazione pratica
Per esempio, partendo dal principio generale di funzionamento degli attacchi a livello di applicazione (la maggior parte di questi, portata contro i Web server, opera mediante il browser dell’attacker), i tecnici di Ubizen, hanno creato DmzShield, un advanced reverse proxy che lavora nel modo in seguito descritto.
Dapprima viene effettuato un controllo generale sulla congruità delle richieste pervenute dall’esterno verso i Web server sottoposti a tutela.
In seguito, se le richieste di cui sopra non risultano rientrare né in un’ipotesi di malicious pattern recognition and matching (riconoscimento di una "firma" di un attacco già catalogato in precedenza), né in un range di richieste convenzionali (standard) effettuate nei confronti del Web server, la transazione viene autorizzata.
Infine, tutte le transazioni sono sottoposte ad una procedura di logging. Questo può risultare utile in caso di successive operazioni di "computer and network forensics" la cui riuscita dipende fortemente dalla granularità delle registrazioni di questi eventi.
Il prodotto in questione è nato da un’idea di alcuni accademici dell’Università belga di Leuven e ha, inoltre, la caratteristica di centralizzare le transazioni basate su Secure socket layer (Ssl), le quali sono ovviamente sottoposte a screening, anche dal punto di vista della congruità della sintassi cui abbiamo testé fatto menzione. Inoltre è possibile effettuare un’amministrazione remota della soluzione, cosa sicuramente utile per chi si trova a dover gestire questo tipo di strumento.
Visto che abbiamo parlato di congruità, non possiamo fare a meno di evidenziare alcuni fattori decisamente importanti da valutare prima di decidere un investimento di questo tipo. Il primo dei due è sicuramente quello delle performance "pure", cioè sul traffico non crittografato.
Benché non si sia mai sentito un Isv ammettere che i proxy siano un potenziale collo di bottiglia, uno strumento di questo genere non può non girare su un sistema operativo di indiscutibile scalabilità e su un hardware all’altezza della situazione. Questa è davvero una condizione senza la quale la cosa non può funzionare a dovere. Altro tema da valutare, poi, riguarda la gestione delle prestazioni nella gestione delle sessioni protette da crittosistema. Il seguente, quindi, è un messaggio destinato agli amministratori di sessioni Ssl. Bisogna verificare prima, anche interloquendo direttamente con il vendor, come la tecnologia di quest’ultimo approcci al rapporto (notoriamente di inversa proporzionalità) tra performance e volume di crittografia generato. Queste sono solo alcune delle cose da valutare. È ovvio che si effettueranno degli approfondimenti anche sulla metodica di scansione della correttezza delle richieste verso i Web server (sinonimi compresi), così come la gestione della "trasparenza" del reverse proxy utilizzato, sia dal lato server sia da quello client.
Bisogna controllare la granularità, insomma. Del resto queste verifiche è meglio farle prima dell’acquisto di qualsiasi soluzione di sicurezza.
