Rilevamento intrusioni: configurare honeyd per simulare una rete

Rilevamento intrusioni: configurare honeyd per simulare una rete marzo 31, 2008

Inviato da davide in : Informatica, Linux, Tecnologia , trackback

(No Ratings Yet)

Loading ...

Gli honeypot sono strumenti molto utilizzati oggi, solitamente in reti di medie e grandi dimensioni, per “distrarre l’attenzione” degli hacker dalle macchine di produzione e dai veri server, consentendo al contempo un efficace rilevamento delle intrusioni.

Un honeypot non è altro che una macchina “fasulla” il cui unico scopo è di simulare uno o più servizi che possono essere attaccati da un malintenzionato. Tipicamente un honeypot può essere una macchina dedicata o un host virtuale, simulato su una macchina reale. Non sto qui ad approfondire l’argomento, che è ampio e piuttosto complesso. Per chi fosse interessato, alla fine dell’articolo troverà una lista di link a pubblicazioni molto interessanti.

Configureremo honeyd, un software open source (http://www.honeyd.org) in grado di simulare host virtuali di ogni tipologia su una rete. Il progetto è molto usato anche in ambito di ricerca, e permette di simulare diversi sistemi operativi e router in commercio, simulando ad esempio i fingerprint di nmap. Inoltre, ogni host può esser configurato per rendere disponibili all’esterno diversi servizi, ad esempio HTTP, SMTP, SSH che potranno poi essere sfruttati da un eventuale attaccante. Con honeyd si può simulare un intera topologia di rete, impostare route, tempi di latenza e altro…

Vediamo un po’ come configurare honeyd (sotto linux chiaramente) per avere un funzionamento di base. Non sono un esperto, e non è scopo di questo articolo mostrare l’uso di servizi o funzionalità avanzate. Per chi ne avesse bisogno, può sempre riferirsi alla documentazione o agli esempi che si trovano sul sito di honeyd. Al contempo, però, dato il tipo di argomento trattato, l’articolo dà per scontate certe conoscenze di networking.

Riporto qui le prove fatte sulla rete di casa mia: tutti gli apparati di rete sono sulla sottorete 192.168.2.X, e creo quattro host sugli indirizzi da 192.168.2.100 a 192.168.2.103

1) Sui sistemi debian-based, ci servono i pacchetti honeyd e farpd, oltre ai quali sono consigliati honeyd-common e rrdtool.
Dopo averli installati, bisogna configurare honeyd e farpd.
farpd (fake ARP daemon) serve per redirigere le richieste ARP relative agli host della honeynet sulla macchina che esegue honeyd.

per farpd, basterà nel nostro caso invocarlo con:

farpd [-d] 192.168.2.100/30 -i eth0

Usate -d per non “daemonizzare” il programma, e vedere in tempo reale le richieste ARP. Chiaramente il range di indirizzi ip specificato è quello degli host, e l’opzione -i indica l’interfaccia di rete sulla quale operare.

Volendo, su ubuntu , si può inserire la configurazione di default per farpd in /etc/default/farpd (verrà usata lanciando farpd da /etc/init.d/farpd )

Passiamo a configurare honeyd .

editiamo /etc/honeypot/honeyd.conf con la nostra configurazione (ho fatto solo poche modifiche a una di quelle di default). Chiaramente sta qui il cuore del sistema, io non ho modificato quasi nulla solo perchè volevo fare un test. Sul sito di honeyd inoltre potete trovare diversi esempi di configurazione, molto utili.

create template
set template personality “Microsoft Windows XP Professional SP1″
set template uptime 1728650
set template maxfds 35

# le connessioni alla porta 80 e 22 verranno collegate ai seguenti script:
add template tcp port 80 “sh /usr/share/honeyd/scripts/win32/web.sh”
add template tcp port 22 “/usr/share/honeyd/scripts/test.sh $ipsrc $dport”

#azioni di default
set template default tcp action reset
set template default udp action reset
set template default icmp action open

add template tcp port 135 open
add template tcp port 139 open
add template tcp port 445 open

create default
set default default tcp action block
set default default udp action block
set default default icmp action block

create router
set router personality “Cisco 1601R router running IOS 12.1(5)”
set router default tcp action reset
add router tcp port 22 “/usr/share/honeyd/scripts/test.sh”
add router tcp port 23 “/usr/share/honeyd/scripts/router-telnet.pl”

create sticky set sticky personality “Mac OS X 10.1 – 10.1.4″
#l’opzione tarpit è usata per rallentare le comunicazioni
set sticky default tcp action tarpit open
set sticky default udp action block

#assegno ai 4 ip i vari template definiti sopra
bind 192.168.2.103 sticky
bind 192.168.2.100 router
bind 192.168.2.102 template
bind 192.168.2.101 template

Anche in questo caso se si vuole usare il daemon, bisogna editare il file /etc/default/honeyd, abilitando esplicitamente honeyd su una certa interfaccia di rete etc… nel mio caso il file è:

RUN=”yes”
INTERFACE=”eth0″
NETWORK=192.168.2.100/30
OPTIONS=”–disable-webserver “

Ora siamo a posto… o quasi!
Se volete usare nmap c’è un problema: se chi fa lo scan e l’honeypot sono sulla stessa rete (e questo è il caso, siccome io provavo dall’interno della mia rete casalinga, e ho gli honeypot sulla stessa rete), nmap non funziona: gli host non vengono trovati. La soluzione, legata al modo di operare di arpd, è quella di patchare arpd. Per non dilungarmi troppo e non ripetere cose già dette da altri metto qui il link all’articolo:

Honeyd and nmap – the solution?

Tra l’altro i file diff per il patch proposti nel link sopra, con la versione di farpd che ho trovato io, non funzionano (le righe dei sorgenti non combaciano). Niente paura, tanto sono solo 2 righe, possiamo farlo a mano

Ora possiamo eseguire e fare tutti gli scan che vogliamo:

Prima di lanciare honeyd, ricordiamoci di fare partire farpd come abbiam visto sopra, (chiaramente, se avete patchato farpd fate partire la versione patchata – probabilmente l’eseguibile si chiamerà arpd), dopodichè:

sudo /usr/bin/honeyd -d -l /var/log/honeypot/honeyd.log -s /var/log/honeypot/services.log -p /etc/honeypot/nmap.prints -x /etc/honeypot/xprobe2.conf -a /etc/honeypot/nmap.assoc -0 /etc/honeypot/pf.os -f /etc/honeypot/honeyd.conf -i eth0 –rrdtool-path /usr/bin/

Nota: non sono necessarie tutte queste opzioni, e di solito la maggior parte di esse sono sottintese se si lancia honeyd da /etc/init.d/honeyd start, ma qui, per lo stesso motivo spiegato per farpd, uso l’opzione -d per vedere direttamente l’output del programma (utile x il debug!)
Infine, se lanciate così honeyd noterete probabilmente errori di permessi nell’accedere alla cartella dei log: in realtà honeyd è impostato per essere eseguito dall’utente honeyd, io per risolvere il problema alla spicciola me la sono cavata con:

chmod -R 777 /var/log/honeypot/*

Ovviamente a meno che non siano dei test casalinghi come i miei, non fate così anche voi

Una volta in esecuzione honeyd, l’attaccante può tentare di “attaccare” i vari servizi che avete preparato sull’honeypot (è possibile collegare ad ogni porta lo script che volete, ma anche, ad esempio, un vero webserver o shell SSH). La cosa importante è che:

Nella maggior parte dei casi, l’attaccante dopo aver “bucato” l’honeypot non può fare nulla, in quanto esso non è altro che una macchina fasulla. Qui si apre però il problema di collegare servizi reali quali per esempio vere shell ad un honeypot… un attaccante che ne prende il possesso potrebbe usarle per attaccare altri sistemi all’esterno.
La vera forza degli honeypot sta nella capacità di logging e monitoraggio delle attività illecite. Un honeypot, in quanto sistema “inutile” per la rete reale, è fatto per attrarre hacker e worm, e quindi a prescindere tutto il traffico che gli arriva deve essere considerato sospetto. L’amministratore non starà quindi a perdere ore di tempo per capire dai log quali siano le attività illecite svolte e quali invece siano nella norma: tutti i contenuti dei log (come abbiamo visto sopra ne sono presenti diversi, e inoltre ogni servizio configurato su honeyd tipicamente ha il suo) sono attività illecite!

Spero che l’articolo possa servire a qualcuno…soprattutto la parte relativa agli errori di nmap, prima di trovare la soluzione sul forum di honeyd, mi aveva fatto perdere un bel po’ di tempo!

Letture consigliate (da SecurityFocus.com):

Segnala presso: