VoIP and Hacking | Consulenza Documentazione

L’ interesse nei confronti degli honeypots è recentemente cresciuto. Vediamo che cosa essi siano, come allestirne uno, e cosa bisognerebbe considerare prima di farlo.
Un honeypot è un server connesso ad Internet che agisce da esca, attirando potenziali infezioni (o anche hackers) per poter studiare i loro comportamenti e come siano in grado di prendere il controllo di un sistema.
Col termine honeynets ci si riferisce invece ad intere reti di honeypots.
Gli honeypots hanno molteplici utilizzi, compresa la pura ricerca. Molti nuovi tipi di attacchi e di malware possono venire studiati in un ambiente isolato nell’ambito di tali sistemi.
Un honeypot può essere qualsiasi tipo di server o applicazione inteso a catturare un attaccante.
Honeypots possono venire classificati in base al loro scopo (production, research, e honeytokens) ed il livello di interazione (low, medium, ed high).

La funzione primaria dei research honeypots è studiare il modo in cui gli attaccanti portano avanti le loro linee di attacco. Sono tipicamente usati da organizzazioni quali università, governi o grandi corporations. Un production honeypot è usato nell’ambito aziendale per proteggere l’azienda stessa e ridurre i rischi.
Inoltre gli honeypots possono anche venire catalogati in base al livello di interazione permesso tra l’incursore ed il sistema. Tali categorie sono: low-interaction, medium-interaction e high-interaction.
Un honeypot low-interaction simula solamentey servizi che non possono essere violati per ottenere pieno accesso allo honeypot. Su un low-interaction honeypot, non vi è alcun sistema operativo per l’attaccante con cui interagire. Può essere paragonato ad un IDS passivo dal momento che non modifica il network traffic in alcun modo, e non interagisce con l’ attaccante. Sebbene ciò minimizzi il rischio normalmente associato agli honeypots, li rende piuttosto limitati. I low-interaction honeypots sono più semplici da allestire e gestire.
Molti tools sono disponibili, sia commerciali che opensource, con cui allestire un honeypot su UNIX/Linux. Buoni esempi, anche se un pochino datati, di packages di questo tipo sono LaBrea Tarpit (http://labrea.sourceforge.net/labrea-info.html), Tiny Honeypot (http://alpinista.dyndns.org/thp), Honeyd (http://www.honeyd.org/), SMTarPit e TarPop (http://www.fresh.files2.serveftp.net).
Una caratteristica interessante di questi honeypots è che differiscono in maniera notevole, offrendo diverse opzioni alla scelta. Per esempio, LaBrea Tarpit è più un tool di diversione, che fa sembrare che vi siano più devices in una rete di quanti ve ne siano realmente, mentre honeyd è un tool di mascheramento che può oscurare il vero sistema operativo e confondere gli attaccanti.

I medium-interaction honeypots sono più sofisticati dei low interaction honeypots, ma meno sofisticati di quelli high
interaction. Rispetto ai primi i servizi simulati sono più complessi tecnicamente. Sebbene la probabilità che l’ attaccante trovi una falla di sicurezza
aumenti, rimane ancora piuttosto improbabile che il sistema venga compromesso. I medium-interaction honeypots forniscono all’attaccante una più profonda illusione di aver raggiunto un sistema operativo dal momento che vi è maggiore interazione. Attacchi più complessi possono perciò essere registrati e  analizzati.
Esempi di medium-interaction honeypots sono nepenthes (http://nepenthes.carnivore.it/) e honeytrap (http://linux.softpedia.com/get/Security/Honeytrap-18436.shtml).  Possono essere usati per catturare malware.
Tali daemons possono registrare attacchi automatici, ed estrarre informazioni su come ottenere i binari del malware in modo da poterlo automaticamente raccogliere.

Gli high-interaction honeypots sono quelli più avanzati, più complessi da progettare, e che implicano un alto livello di rischio a causa del fatto che coinvolgono un reale sistema operativo. Lo scopo di un high-interaction honeypot è di fornire all’attaccante un sistema operativo reale con cui interagire, dove nulla sia simulato o limitato. Le possibilità di raccogliere grandi quantità di informazioni sono pertanto maggiori.
Dal momento che l’ attaccante ha maggiori risorse a sua disposizione, un high-interaction honeypot deve essere costantemente monitorato per assicurare che non divenga una minaccia o una breccia nella sicurezza. Viene tipicamente utilizzato a scopo di ricerca.

LaBrea Tarpit
LaBrea Tarpit è un honeypot opensource creato da Tom Liston in grado di operare su ogni genere di OpenBSD, Linux, Solaris, o Windows. LaBrea descrive sè stesso come uno “sticky honeypot” (un honeypot appiccicoso). LaBrea assume degli indirizzi Ip non assegnati nella rete in cui risiede e agisce come agirebbero gli hosts corrispondenti a tali indirizzi in risposta a tentativi di connessione. LaBrea usa una tecnica in grado di rallentare i tentativi di connessione tanto da “ingessare” la macchina attaccante. L’obiettivo principale di un honeypot di tale tipo è di rallentare hackers e worms mantenendo le connessioni attive per un periodo di tempo indefinito.

Tiny Honeypot
Tiny Honeypot è stato scritto da George Bakos. Si tratta di un programma simile nella concezione a LaBrea e che opera in abbinamento col software di intrusion detection Snort. Esso si pone in ascolto su porte che non sono in uso e risponde con informazioni contraffatte. Giusto per fare un po’ di confusione.

Honeyd
Honeyd è un versatile honeypot opensource che si presenta come un differente sistema operativo a livello di stack TCP/IP. Altre features che include sono la simulazione di molti hosts virtuali in maniera concorrente, la simulazione di servizi arbitrari la cui personalità può venire adattata in modo che possano apparire eseguiti da certi sistemi operativi, così come la simulazione di varie topologie di routing. E’ anche possibile impostare servers Web o ftp fasulli in un ambiente virtuale. Honeyd è leggero ed opera come un daemon nel sistema operativo che lo ospita (BSD, GNU Linux e Solaris).

SMTarPit
SMTarPit è la combinazione di un SMTP honeypot ed un tarpit (rallentatore). E’ scritto in Perl e quindi dovrebbe operare virtualmente su qualsiasi piattaforma che supporti Perl (ad eccezione di Windows). Utilizza xinetd che monitorizza la porta 25 e quando qualcuno la contatta, smtarpit viene lanciato e quindi effettua il chrooting di se stesso. Stabilisce poi se vi sia un umano oppure una macchina all’altra estremità. Ogni volta che arriva una richiesta di connessione sulla porta 25, xinetd avvia una copia di questo server.
Quando il server viene avviato, esso risponde col normale messaggio di benvenuto e quindi attende che il client risponda. Quando il client risponde, misura quanto tempo ci impiega e cerca di stabilire se si tratti di un umano o di una macchina (è possibile aggiustare questi parametri del programma).
Se il server ritiene che si tratti di un interlocutore macchina, entra in tarpit mode, rallentando enormemente ogni successiva fase della connessione. Nel protocollo SMTP, i codici server response hanno un codice di tre cifre che se seguito da un carattere dash (-), obbligano il client ad attendere di riceverne uno con uno spazio di seguito. Questo può impiegare anche un’ora.
In altre parole, questo server permette di mettere in stallo diversi processi di spamming contemporaneamente (fino al limite definito nel programma e nei files di configurazione di xinetd) per ore e ore, con un minimo dispendio di risorse.

TarPop
Similmente a SMTarPit (l’autore è il medesimo, Paul Grosse) TarPop è la combinazione di un honeypot POP3 ed un tarpit, scritto in Perl.
E’ pensato come complemento di SMTarPit per presentare al cracker una porta 110 open che sembra corrispondere ad un server POP3 e potenzialmente, ad un mucchio di appetitosi accounts da sfruttare. Oltre che rallentarlo a morte è anche possibile fornirgliene moltissimi fasulli.

Honeytrap
Un classico approccio nella tenologia degli honeypot consiste nell’ emulare servizi che sembrino presentare delle ben note vulnerabilità, ed è seguito da molti, eccellenti tools (ad es., nepenthes). Tuttavia, un simile approccio non funzionerebbe nel caso si fosse interessati a intercettare anche attacchi di tipo completamente ignoto.
Se il daemon honeytrap rileva una richiesta ad una porta TCP non associata, avvia un processo server per gestire la connessione in ingresso. Questo rende possibile maneggiare gli attacchi proprio quando si verificano. Non vi è alcuna necessità di mantenere migliaia di porte associate per essere sicuri che nuovi attacchi siano catturati. Invece, honeytrap estrae i tentativi di connessione TCP a partire da un network stream usando i cosiddetti “connection monitors”. Due differenti tipi di connection monitors sono attualmente disponibili:
Uno sniffer basato su libpcap cattura i pacchetti RST generati localmente con un sequence number uguale a zero e indicanti una richiesta di connessione respinta. Normalmente – tanto più nel caso di un reale attacco – il sistema remoto tenterà nuovamente e questa volta con successo. Questo è il monitor di default in ragione della sua portabilità.
Sui sistemi Linux è possibile agganciarsi alla interfaccia ip_queue di netfilter/iptables e creare una regola iptables per inoltrare i pacchetti SYN  relativi alle nuove connessioni a honeytrap. Questo monitor ha il vantaggio di catturare un attacco non appena si presenti.

Nepenthes
Nepenthes, il cui progetto è attualmente frutto della fusione dell’originario nepenthes e di mwcollect, un altro software per honeypot molto famoso, è disegnato per emulare le vulnerabilità che gli worms utilizzano per propagarsi, e per catturare tali worms. Mandando in esecuzione gli worms catturati in una reale macchina vulnerabile è possibile ottenere nuove informazioni sull’ exploit. Dato che esistono molti possibili modi di infezione, Nepenthes è modulare. Vi sono moduli per risolvere il dns in modalità asincrona, emulare varie vulnerabilità, scaricare files, maneggiare shellcodes.

Prima di allestire un honeypot, occorre considerare cosa si vuole ottenere da esso. Se si è esclusivamente interessati ad aspetti di ricerca, non è raccomandabile farlo in ambiente lavorativo, a meno che la ricerca non faccia parte del vostro incarico.
Determinato l’obiettivo, occorre concentrarsi su come impostare l’ambiente di rete dell’ honeypot. Può essere molto pericoloso lasciare un sistema intenzionalmente fasullo nella DMZ tra la rete aziendale e la rete pubblica esterna. Se l’ honeypot venisse compromesso, si correrebbe il rischio di compromettere gli altri sistemi della DMZ, o peggio, tutta la rete aziendale. Se la honeynet fosse una rete isolata e l’ honeypot  compromesso, il rischio invece sarebbe minimo. Il segreto per implementare correttamente un honeypot è assicurarsi che la sua architettura sia attentamente progettata. Anche quando si implementa un honeypot domestico, occorre considerare attentamente una architettura sicura perché si potrebbero violare le condizioni di utilizzo del proprio ISP se un honeypot compromesso attaccasse altri utenti. Gli honeypots non sono una cosa da prendere alla leggera.
Prima di implementare un honeypot, bisognerebbe considerarne le implicazioni legali. Due packages menzionati sono stati oggetti di limitazioni distributive a causa dell’adozione negli U.S.A. della legislazione DMCA. Neils Provos, il creatore di honeyd, è stato costretto a trasferire le proprie ricerche nel campo della steganografia e degli honeypots fuori degli Stati Uniti a causa delle leggi del Michigan. Tom Liston, il creatore di LaBrea Tarpit, residente in Illinois, ha dovuto interrompere la distribuzione del proprio software per la stessa ragione.
Almeno negli Stati Uniti non è ancora chiaro se gli honeypots nei fatti violino la legge.
E’ anche importante realizzare che simili restrizioni variano a seconda del posto in cui si vive. In alcune legislazioni, gli honeypots potrebbero essere considerati alla stregua di trappole.

Send post as PDF to