The network setup for this project is fairly simple:

The bridge is completely transparent to the attacker – they have no knowledge that they are passing through this machine. Therefore, it makes for an excellent machine to carry out the network logging between the honeypot and the internet. I will use the OpenBSD 3.1 native packet filtering tool, pf, to allow all inbound
connections to the honeypot and only allow outbound icmp echo requests, tcp 21 (FTP, active), tcp/udp 53 (DNS), tcp 80 (HTTP), and tcp 6667 (IRC). I take the previous measures to bring down my liability yet try not to raise suspicion from the attacker. The second logging facility on the bridge, pf being the first, will be Snort, a powerful sniffer and IDS. The third and final logging facility will be the trusty tcpdump. It will capture full packet dumps going to and from the ip of the honeypot. Data control from the honeypot is also controlled on the bridge. Refer the paper about data control for honeypots at The Honeynet Project. Thanks to the Brazil team of the Honeynet Research Alliance I can use a tool specifically developed for OpenBSD’s pf for data control calledsessionlimit. After compromise of the honeypot it will interact with pf in order to contain activity of the intruders. There is no way I can guarantee that the intruders will not indulge in malicious activity but I hope to limit that possibility with this tool. The interface on the bridge with the public ip will be used strictly for remote management purposes. This interface will be packet filtered to only allow SSH connections from specific ips and only allow outbound HTTP traffic to update Snort rules and email notification of said updated rules.
The Configuration
First I configured the OpenBSD bridge. When I refer to interfaces they are set up as follows – rl0 is the interface without an ip connected to the internet, rl1 is the interface without an ip connected to the honeypot, and rl2 is the interface with a public ip for remote management purposes connected to the internet.
Changes to /etc/rc.conf:
pf=YES
portmap=NO
inetd=NO
ntpd=NO

Enable packet forwarding in /etc/sysctl.conf so upon reboot it is enabled:

net.inet.ip.forwarding=1 # 1=Permit forwarding (routing) of packets

Create /etc/hostname.rl0:

# echo up > /etc/hostname.rl0

Create /etc/hostname.rl1:

# echo up > /etc/hostname.rl1

rl2 will get its public address assigned via DHCP from the ISP:

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

Create /etc/bridgename.bridge0:

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

The pf configuration file, /etc/pf.conf, needs to be created, here’s my end result:



 

Snort was next. First, I created a user snort with a login of /sbin/nologin. Then I downloaded Snort 1.9.0, compiled it, and tweaked the snort.conf file to fit my needs. I also installed oinkmaster. Oinkmaster is a perl script to update Snort rules from the latest ruleset available on snort.org. I unpacked the tar.gz in /home/snort and then added an entry to snort’s crontab to update the rules every day at 3:00 PM. The output from oinkmaster, which is any rule that is deleted, modified, or added, is then emailed to me if there are any changes. Here is the crontab entry:

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)

Next is data control with sessionlimit. It will monitor the state table (Note: outgoing traffic needs to have keep state) and block honeypot connections outbound when 1) the number of states associated with the honeypot increases too fast, 2) when the honeypot makes more than 20 connections, and 3) when the number of bytes associated with an ICMP state has reached a predefined limit – the default is 65k (a la lame ping -f DoS). Keep in mind the attacker’s interactive session with the honeypot won’t be affected, only new outbound connections. After 30 minutes, the sessionlimit rule added to pf will expire. All of this is logged to syslog. Since we are about to go live, we will start up sessionlimit manually:

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

Enable packet forwarding now:

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

Manually initialize interfaces, bring up the bridge, and grab an ip for rl2:

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

Make sure all of the interfaces and the bridge are up and configured correctly:

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

Enable pf and load rules:

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

Manually start Snort:

# /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

Lastly, I run tcpdump by hand on rl1 to capture all traffic from my honeypot’s ip. A useful switch that was added in tcpdump 3.7.1 is -C which rotates the saved file every optarg * 1,000,000 bytes. This way I won’t have to load up an enormous file in ethereal, just makes analysis a little more manageable:

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

For easy startup of Snort, tcpdump, and sessionlimit, I created a wrapper script called honeypot-wrapper. This way I only have to call the wrapper script and pass the honeypot ip as an argument to start these three services:



 
The Deployment
The OS I chose for my first honeypot is OpenBSD 3.1 vanilla. There isn’t much to explain here – just install the OS and connect the honeypot to the bridge. With everything up and humming along now, all I have to do is sit back and wait for someone to take the bait. I have ssh access to the bridge’s management interface so I can log in from my management ip’s and look at the alert file in /home/snort/log/alert. I actually created a quick and dirty script in the ~snort directory to see a summary of attacks:
#!/bin/sh
grep -v 'spp' ~snort/log/alert | grep '[**]' | sort | uniq -c

Here is the 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 [**]

Sure enough, someone took the bait after just 2 days, compromising the honeypot using the Gobbles SSH exploit.

Conclusion
This complete setup, which included getting the right hardware together, took me a few hours here and a few hours there over the course of a weekend. I am using old hardware – a Pentium 133MHz for the OpenBSD bridge and a Pentium 166MHz as the honeypot. After my setup was up and running smoothly I was overall pretty pleased with the honeynet design I had chosen, both in its simplicity and elegance.
To Do
Run Snort under DJB’s daemontools. chroot() Snort. chroot() and run as non-root tcpdump.

RELATED ARTICLESMORE FROM AUTHOR

What Do You Think on This ? Say Here