La settimana scorsa un cliente mi ha contattato chiedendomi di valutare la dismissione di alcuni apparati considerati obsoleti. Si trattava di un trio di server di 6-7 anni fa, dotati di un sistema operativo proprietario e con scarsa possibilità di essere scalati. Il responsabile dei sistemi informativi gli aveva consigliato una dismissione completa ma pochi sanno che questi sistemi possono diventare un’importante risorsa difensiva.

Alla base della cybersecurity c’è un paradigma molto semplice: per ogni attacco, ci deve essere un sistema che può essere attaccato. Questa relazione, che in passato era uno-ad-uno, oggi è divenuta uno-a-molti. Ad ogni attacco, possono soccombere diverse versioni di sistema operativo ma, attenzione, non tutte.

Non esiste, infatti, una minaccia in grado di oltrepassare tutti i sistemi operativi sul mercato e, in modo particolare, il paradigma uno-a-molti si è sviluppato con il progressivo sviluppo tecnologico. Questo significa che i sistemi informatici più datati, possono essere paradossalmente considerati più sicuri davanti ad attacchi troppo elaborati.

L’idea è quella di impiegare i sistemi più vecchi, per creare una honeypot di tipo difensivo. Cominciamo con il chiarire cosa è una honeypot.

L’orso va sempre dal miele, anche quando non sa che è marcio

L’idea alla base di una honeypot è quella di creare una piccola rete che finge di essere quella di produzione. L’hacker, convinto di voler lanciare un attacco verso il finto ambiente di produzione, si ritrova a creare pochissimi danni, se non addirittura ad essere contrattaccato. Il contrattacco, in Italia, è una pratica poco usata anche per motivi legali. Ma la honeypot si basa sul principio che l’hacker non sa esattamente come è fatta la vostra rete.  Cerchiamo di capire come è fatta una rete che implementa al suo interno una honeypot.

Come è possibile notare, la configurazione della rete ricalca quelle che abitualmente si trovano negli ambienti di lavoro. Dietro ad internet c’è un firewall che protegge i comuni server su cui siamo abituati a lavorare: server web, server FTP, server DNS. In realtà viene aggiunto un ulteriore server, che ha il compito di esporre dati, sistemi e piattaforme “fittizie”, utili però ad incuriosire l’hacker. L’hacker è un individuo che non ha tempo infinito per portare a termine i suoi attacchi. Deve muoversi rapidamente e con precisione, navigando in sistemi che non conosce, la honeypot non deve essere troppo “semplice”. Di seguito riporto uno schema più articolato dell’implementazione di una honeypot.

Come potete notare, la seconda configurazione non è più riferita ad un singolo sistema ma ad una rete (honey-net). Questo perchè la honeypot è da considerarsi un principio teorico. Una trappola con la quale distrarre l’attaccante. Lo scopo della honeypot è quindi:

• Riproporre l’ambiente di produzione.
• Ingannare l’attaccante con dati fittizi.
• Tracciare le attività svolte con sistemi di logging.

La honeypot difende sistemi, reti, dati, e può essere creata anche attraverso un’infrastruttura relativamente economica. Parliamo di un sistema linux-based con Apache, PHP e MySQL che è sufficiente per emulare un web server oggetto di attacco. Per un istante spostiamoci nei panni dell’hacker: durante un attacco, che generalmente viene condotto da linea di comando, l’hacker cercherà dati rilevanti in base al nome, alla data e alla dimensione. Per questo motivo, sarebbe auspicabile che i file della honeypot siano in grado di ingannare l’attaccante.

Una honeypot è in grado di fornire un contrattacco quando, al suo interno, vengono inseriti file pericolosi. L’hacker generalmente non sa come è strutturata la vostra rete interna. Segue alcuni criteri basati sulla sequenza: apro una falla, seguo i dati e vedo cosa raggiungo. Molte aziende produttrici di software che hanno implementato la honeypot, hanno creato versioni modificate dei loro software. L’installazione, ad esempio, viene alterata per inserire tracker, logger, o addirittura virus ma questo ultimo caso è chiaramente da considerarsi illegale.

Catena probatoria: differenza tra prova ed evidenza

È opportuno specificare che i logging raccolti in fase di attacco non sono considerate delle prove fino a quando non vengono certificati nella loro autenticità e correttezza. Questo avviene, spesso, tramite confronto con i dati dell’ISP su richiesta del magistrato. C’è quindi una sottile differenza tra prova ed evidenza una differenza che credo sia opportuno chiarire. Semplificando all’inverosimile, potremmo dire che l’evidenza è una prova che non è stata ancora, ufficializzata dall’iter processuale. Questo dettaglio procedurale però apre dei fronti importantissimi. L’alterazione di una evidenza può essere disastrosa per l’utente attaccato, può inquinare l’efficacia probatoria fino all’inverosimile. L’alterazione di una prova è altrettanto grave ma apre fronti di responsabilità diverse. Alterare una prova spesso comporta intervenire sui sistemi in possesso della Polizia Postale.

Conclusioni

L’implementazione della honeypot richiede una discreta conoscenza delle reti e una buona politica di gestione del traffico dati. Prima di tutto, tuttavia, è fondamentale capire cosa proteggere e come. Ricordate che una honeypot è fatta per essere violata, se non distrutta, abituatevi a questa eventualità.