Semplice Honeynet con OpenBSD

Christopher J. Reining
creining@packetfu.org

Versione originale @ http://www.packetfu.org/hnd.html
Traduzione a cura di Daniele Muscetta

Bene, mi sono finalmente deciso a metter su una honeynet. Questo e'stato un mio intresse per gia' qualche tempo ormai, specialmente dopo aver visto il lavoro fatto da Lance Spitzner e gli altri con il Progetto Honeynet. Il mio scopo con la honeynet e' quello di rafforzare ed affinare le mie skills di analisi forense dopo che un sistema sia stato compromesso e quello di imparare quali strumenti e metodi gli attaccanti stiano correntemente usando. Prima che partissi avevo realizzato che avere una honeynet e'una cosa seria, dal momento che la honeypot, quando compromessa, puo' poi essere usata per entrare in altre macchine, effettuare attacchi D/DoS, o comunque usata per altri scopi infami. Ho preso precauzioni per limitare le possibilita' che le forze dell'ordine vengano a trovarmi. Spero che funzionino bene ;)

Il Progetto

Il setup della rete per questo progetto e' piuttosto semplice:

Il bridge e' completamente trasparente per gli attaccanti - essi non sanno di passare attraverso questa macchina. Pertanto, questa e'una macchina ottima dove effettuare tutto il logging del traffico tra la honeypot e Internet. Usero' pf, il packet filter nativo di OpenBSD 3.1, per permettere le connessioni in entrata verso la honeypot e per permettere solo connessioni verso l'esterno di tipo icmp echo, tcp porta 21 (ftp), tcp/udp 53 (dns), tcp 80 (http) e tcp 6667 (irc). Prendo questa misura di sicurezza per ridurre la mia responsabilita' e allo stesso tempo cercare di non destare sospetti nell'attaccante. La seconda misura di logging attiva sul bridge (il logging di pf e' la prima), sara' Snort, un potente sniffer e IDS. La terza ed ultima misura di logging sara' il fidato tcpdump. Questo catturera' tutti i pacchetti con massimo dettaglio da e verso l'IP della honeyopt.
Sul bridge viene anche controllato il flusso di dati. Fate riferimento al paper sul 'data control' per le honeypot che si trova su Honeynet Project.
Grazie al team brasiliano dell'Honeynet Research Alliance posso usare un tool sviluppato appositamente per pf di openbsd, che serve allo scopo del 'data control' che si chiama sessionlimit. Dopo che la honeypot e' stata compromessa questo interagira' con pf per contenere le attivita' dell'intruso. Non c'e' alcun modo in cui io possa garantire che gli intrusi non si metteranno a svlgere attivita' dannose ma spero di poter limitare questa loro possibilita' tramite questo tool. L'interfaccia sul bridge con l'indirizzo IP pubblico sara' usata strettamente per ragioni di gestione remota. Questa interfaccia verra' filtrata per permettere solamente connessioni SSH da specifici IP e solo permettere traffico http in uscita allo scopo di aggiornare le regole di snort e per poter notificare via mail di tali aggiornamenti.

La Configurazione

Prima di tutto ho configurato il bridge OpenBSD. Quando mi riferisco alle interfacce sono configurate cosi' - rl0 e' l'interfaccia senza indirizzo ip connessa ad Internet, rl1 e' l'interfaccia senza indirizzo IP connessa alla honeypot, e rl2 e' l'interfaccia con un indirizzo IP pubblico usata a scopi di gestione, connessa ad Internet.

Modificere a /etc/rc.conf:

pf=YES portmap=NO inetd=NO ntpd=NO

Abiliare il packet forwarding in /etc/sysctl.conf cosi' che sia attivo al prossimo reboot:

net.inet.ip.forwarding=1 # 1=Permette l'inoltro di pacchetti (routing)

Creare /etc/hostname.rl0:

# echo up > /etc/hostname.rl0

Creare /etc/hostname.rl1:

# echo up > /etc/hostname.rl1

rl2 otterra' il proprio indirizzo IP assegnato via DHCP dall'Internet Service Provider:

# echo dhcp NONE NONE NONE /etc/hostname.rl2

Creare /etc/bridgename.bridge0:

# echo add rl0 add rl1 up /etc/bridgename.bridge0

Il file di configurazione di pf, /etc/pf.conf, deve essere creato, ed ecco come l'ho fatto io:

# pf.conf Set di Regole per pf # # Per vedere il log: # tcpdump -n -e -ttt -r /var/log/pflog # # Per vedere i pacchetti che vengono loggati in tempo reale (una effetto tipo 'tail -f' del logfile): # tcpdump -n -e -ttt -i pflog0 # VARIABILI # La mia interfaccia di gestione. pf puo' automaticamente usare le interfacce al posto degli IP # molto comodo se si hanno IP dinamici mgmtif="rl2" # Queste interfacce non avranno uno indirizzo ip outif="rl0" inif="rl1" # Indirizzi IP abilitati a fare gestione remota mgmtips ="{ x.x.x.x/32, x.x.x.x/32 }" # Indirizzo IP pubblico della honeypot honeypot ="x.x.x.x/32" # Servizi in uscita autorizzati dalla honeypot (TCP) allowed_svcs_tcp="{ ftp, domain, www, ircd }" # Servizi in uscita autorizzati dalla honeypot (UDP) allowed_svcs_udp="{ domain, bootps }" # http://www.iana.org/assignments/ipv4-address-space # http://rfc.net/rfc1918.html # IP range che non possono essere su Internet - Se provenienti da 'fuori' saranno sicuramente spoofati reserved ="{ 0.0.0.0/8, 10.0.0.0/8, 20.20.20.0/24, 127.0.0.0/8, 169.254.0.0/16, 172.16.0.0/12, 192.0.2.0/24, 192.168.0.0/16, 204.152.64.0/23, 224.0.0.0/3, 255.255.255.255 }" # SPOOFERS # Non permettere che indirizzi riservati vengano spoofati block in quick on $outif from $reserved to any block out quick on $outif from $honeypot to $reserved # blocca e logga i pacchetti in uscita che non hanno l'IP della honeypot come sorgente block out log quick on $outif from ! $honeypot to any # DEFAULT POLICY # il filtraggio sul bridge verra' fatto sulla interfaccia esterna (rl0) # La honeypot verra' autorizzata a connettersi in uscita solo a servizi pre-determinati block out log on $outif all # Tutto il traffico puo' entrare sull'honeypot pass in on $outif all keep state # ssh sara' l'unico traffico autorizzato verso l'interfaccia di gestione block in log on $mgmtif all # solo smtp, dns, e http saranno autorizzati ad uscire dalla interfaccia di gestione block out log on $mgmtif all # NOISE # rumore (broadcast, etc) che arriva al mio cable modem viene droppato silenziosamente block in quick on $mgmtif inet from any to { 255.255.255.255, 224.0.0.1 } # Connessioni in uscita dalla Honeypot pass out log quick on $outif inet proto tcp from $honeypot to any \ port $allowed_svcs_tcp flags S/SA keep state pass out log quick on $outif inet proto udp from $honeypot to any \ port $allowed_svcs_udp keep state pass out log quick on $outif inet proto icmp from $honeypot to any \ icmp-type 8 code 0 keep state # Connessioni per Gestione Remota pass in log quick on $mgmtif inet proto tcp from $mgmtips to $mgmtif \ port ssh keep state pass out quick on $mgmtif inet proto tcp from $mgmtif to any \ port { smtp, domain, http } flags S keep state pass out quick on $mgmtif inet proto udp from $mgmtif to any \ port domain keep state

Snort era il prossimo passo. Primo, ho creato un utente snort con login /sbin/nologin. Poi ho scaricato Snort 1.9.0, compilato, e modificato snort.conf per adattarsi ai miei bisogni. Ho anche installato Oinkmaster. Oinkmaster e' uno script in perl che permete di aggiornare le regole di snort con le ultime regole disponibili su snort.org. Ho scompattato il tar.gz in /home/snort e aggiunto una entry in crontab per far aggiornare le regole di snort ogni giorno alle 3:00 PM. L'output di Oinkmaster, cioe' ogni regola che venga cancellata, aggiunta o modificata, mi viene mandato in mail se ci sono cambiamenti.
Ecco la mia entry in crontab:

0 15 * * * cd $HOME/oinkmaster-0.6 ; TMP=`mktemp /tmp/oinkmaster.XXXXX` && (./oinkmaster.pl -o $HOME/rules/ -q -c > $TMP 2>&1; if [ -s $TMP ]; then mail -s "Snort Oinkmaster Update `date +%m-%d-%Y`" me@foo.bar < $TMP; fi; rm $TMP)

IL passo successivo e' il data control con sessionlimit. Monitorera' la state table (Nota: traffico in uscita devono mantenere lo stato) e blocchera' le connessioni in uscita dalla honeypot quando 1) il numero di entri nella state tables incremente troppo velocemente, 2) quando la honeypot effettua piu' di 20 connessioni, e 3) quando il numero di bytes associati con una connessione ICMP ha raggiunto un limite predefinito - il default e' 65k (un banale ping of death). Tenete in mente che la sessione interattiva dell'attaccante con la honeynet non verra' influenzato, ma solo le connessioni in uscita. Dopo 30 minuti, le regolo aggiunte da sessionlimit a pf scadranno. Tutto questo viene loggato su syslog. Dal momento che intendiamo andare 'in diretta', starteremo sessionlimit manualmente:

# /usr/local/bin/sessionlimit -H x.x.x.x -i rl1 &

Ora abilitiamo il packet forwarding:

# sysctl -w net.inet.ip.forwarding=1

Inizializzaimo le interfacce manualmente, tiriamo su il bridge, e lasciamo che rl2 prenda un indirizzo ip:

# ifconfig rl0 delete # ifconfig rl1 delete # brconfig bridge0 add rl0 add rl1 up # dhclient rl2

Accertiamoci che tutte le interfacce del bridge siano up e configurate correttamente:

# ifconfig rl0 # ifconfig rl1 # ifconfig rl2 # brconfig bridge0

Abilitiamo pf e carichiamone le regole:

# pfctl -e # /sbin/pfctl -R /etc/pf.conf

Startiamo Snort a mano:

# /home/snort/snort-1.9.0/src/snort -i rl1 -deq -h x.x.x.x/32 -l /home/snort/log -c /home/snort/rules/snort.conf -D

Infine, faccio girare tcpdump a manu su rl1 per catturare tutto il traffico proveniente dall'ip della mia honeypot. Un utile modificatore della riga di comando che fu aggiunto in tcpdump 3.7.1 e'-C che ruota il file salvato ogni n * 1000000 bytes.
In questo modo non dovro'poi caricare un file enorme in ethereal, lo rende un po' piu' gestibile:

# tcpdump -i rl1 -n -s 1500 -C 2 -w /var/log/tcpdump/tcpdump.log host x.x.x.x &

Per un avvio facile di Snort, tcpdump e sessionlimit, ho creato un wrapper script chiamato honeypot-wrapper. in questo modo tutto quello che ho da fare e' lanciare lo script passandogli come parametro l'indirizzo IP della honeypot, per startare questi tre servizi:

#!/bin/sh #Startup di snort, tcpdump, sessionlimit per la honeynet SNORT=/home/snort/snort-1.9.0/src/snort CONFIG=/home/snort/rules-1.9.0/snort.conf SNORTLOG=/home/snort/log TCPDUMP=/usr/local/bin/tcpdump TCPDUMPLOG=/var/log/tcpdump/tcpdump.log SESSIONLIMIT=/usr/local/bin/sessionlimit if [ -n "$1" ]; then ip=$1 else echo -n "Usage: `basename $0` (honeypot ip)\n" exit fi if [ -x $SNORT ]; then echo -n " Snort starting...\n" $SNORT -i rl1 -g snort -u snort -deq -h $ip/32 \ -l $SNORTLOG -c $CONFIG -D >/dev/null 2>&1 fi if [ -x $TCPDUMP ]; then echo -n " Tcpdump starting...\n" $TCPDUMP -i rl1 -n -s 1500 -C 2 -w $TCPDUMPLOG host $ip & \ >/dev/null 2>&1 fi if [ -x $SESSIONLIMIT ]; then echo -n " Sessionlimit starting...\n" /usr/local/bin/sessionlimit -H $ip -i rl1 & \ >/dev/null 2>&1 fi

La messa in Produzione

Il sistema operativo che ho scelto per la mia prima honeypot e'OpenBSD 3.1 vanilla. Non c'e' molto da spiegare qui - installte il S.O. e connettete l'honeypot al bridge. Con tutto funzionante come appena descritto, tutto cio' che rimane da fare e' sedersi ed aspettare che qualcuno abbocchi all'amo. Io mantengo accesso ssh sull'interfaccia di management del bridge. di modo che posso loggarmi dal mio IP di management e guardarmi i file di alert in /home/snort/log/alert. HO anche creato uno script 'quick & dirty' nella directory ~snort per vedere un riassunto del numero di attacchi:

#!/bin/sh grep -v 'spp' ~snort/log/alert | grep '\[\*\*\]' | sort | uniq -c

Ed eccone l'output:

# ./summary 9 [**] [1:1227:4] X11 outbound client connection detected [**] 3 [**] [1:1394:3] SHELLCODE x86 NOOP [**] 5 [**] [1:1418:2] SNMP request tcp [**] 4 [**] [1:1420:2] SNMP trap tcp [**] 4 [**] [1:1421:2] SNMP AgentX/tcp request [**] 1 [**] [1:1810:1] MISC Successful Gobbles SSH exploit [**] 1 [**] [1:1812:1] MISC Gobbles SSH exploit attempt [**] 1 [**] [1:249:1] DDOS mstream client to handler [**] 5 [**] [1:469:1] ICMP PING NMAP [**] 7 [**] [1:474:1] ICMP superscan echo [**] 1 [**] [1:498:3] ATTACK RESPONSES id check returned root [**] 1 [**] [1:587:2] RPC portmap request status [**] 1 [**] [1:598:5] RPC portmap listing [**] 9 [**] [1:618:2] SCAN Squid Proxy attempt [**] 3 [**] [1:628:1] SCAN nmap TCP [**]

Ed infatti, qualcuno abbocco' all'esca dopo appena due giorni, compromettendo la macchina usando l'exploit SSH di Gobbles.

Conclusioni

Questo setup completo, incluso il tempo necessario a mettere insieme l'hardware necessario, mi ha tenuto impegnato per qualche ora qui e qualche ora li' nel corso di un finesettimana. Uso hardware antico - un Pentium 133MHz per il Bridge OpenBSD e un Pentium 166MHz come Honeypot. Dopo aver visto che il mio setup era in piedi e stava funzionava correttamente ne ero molto felice, ed ero contento in genere con il design della Honeypot che avevo scelto, per la sua semplicita' ed eleganza.

Da Fare

Far girare Snort sotto i daemontools di DJB. Far girare Snort in ambiente chroot(). Far girare tcpdump in ambiente chroot() e con utente non-root.