I was recently asked about the network configuration I use for my honeyd sensor. I had thought I’d already written about this so initially went to find the article on honeyd configuration; but my memory was wrong and the original post only covered configuring the guest systems, not the honeyd host itself. So, as I now have a pretty(ish) network diagram showing my setup I may as well correct the earlier omission.
<DISCLAIMER: This may not be the best network design for running honeyd, this is merely how my environment is configured and it works for me as a research platform. As usual, your mileage may vary, especially if your use-case differs from my own>
As can be seen, the design has three distinct network segments:
- Publicly route-able IPs
- Internal network for honeypot hosts
- Virtual network for honeyd guest systems. These IP addresses sit on loopback interface on the host, with a static route on the firewall to pass all virtual traffic to the honeyd host.
Using a perimeter firewall with NAT/PAT capabilities allows easy switching between emulated systems and services if your public IP resources are limited; a large network of guests can be configured in advance and left static, then a quick firewall change is all that is required to expose different systems to the world.
Additionally, as much as honeypot systems are designed to be compromised and collect information of malicious attacks (or perhaps more correctly, because of this) , low-interaction systems like honeyd is designed to avoid full compromise. If something goes wrong and the host system gets fully compromised, a (sufficiently configured) perimeter firewall provides some control of outgoing traffic, limiting the attackers options for using the honeypot sensor to attack other systems.
Not much to it really; if you use an different setup and/or can suggest ways to improve the setup let me know, always looking to improve my systems where possible.
— Andrew Waite
<UPDATE>Live download mirror: carnivore.it</UPDATE>
Mercury Live DVD was initially (I believe) announced in a post to the Nepenthes Mailing list. It is a remastered Ubuntu distribution with pre-installed honeypot applications and malware analysis tools created by John Moore. From the ReadMe:
This live DVD is a remastered version of Ubuntu 10.0 Beta LTS x86_32. It was designed due to my being disappointed with another reverse engineering malware live CD that was released recently. I have decided to call my creation MERCURY, which is an acronym for Malware Enumeration, Capture, and Reverse Engineering.
The Mercury live DVD contains tools used for digital forensics, data recovery, network monitoring, and spoofing. It should primarily be used as a honeypot or network monitoring platform as well as a laboratory and teaching aid. There are three honeypots installed – honeyd, nepenthes, and dionaea. Four, if you include netcat.
The majority of the additional applications reside in /opt:
- Dionaea (0.1.0) – Dionaea is a malware collection honeypot focusing primarily on SMB emulation, covered on InfoSanity numerous times before.
- FFP – Fuzzy Fingerprinting is a util to aid SSH MitM attacks.
- Kippo (svn rev.169) – Kippo is an low-medium interaction SSH honeypot, Also covered
- mitm-ssh – Unsurprisingly, a utility for aiding man in the middle attacks against SSH connections.
- Origami & pdftools – Two frameworks for analysing malicious PDF files.
- Volatility – an excellent memory analysis toolkit
- Zerowine-vm – A malware behavior analysis platform. I’ve covered ZeroWine here before, and whilst I find it useful for initial analysis I found it a pain to setup and get running. The fact this works out of the box on Mercury is enough reason alone to keep the .iso handy.
Other tools are installed on the system as started, access from standard locations (/etc, /usr/bin, etc.). I won’t try to list them all, but some highlights include:
- Nepenthes – Dionaea’s predecessor
- Honeyd – Honeypot system, perfect for emulating multiple different systems from one platform. Covered in more depth here.
- John – John the Ripper, password cracker
- ircd-hybrid – irc server daemon, useful for analysis irc-based malware’s interaction with command and control systems.
- Snort – de-facto intrusion detection system.
- Wireshark – Packet capture and network analysis tools.
I could go on, but I’m sure you get the idea.
Setting up a honeypot, and analysing the results, has never been easier. And I’m sure the toolkit’s functionality will also be useful in other scenarios; incident response, general network administration or as a safe learning platform. So what are you waiting for?
N.B. there have been several mirror’s and downloads established, the most reliable download source I’ve used is Markus’ mirror at carnivore.it
InfoSanity’s honeyd-geoip.py script has been useful for analysing the initial findings from a HoneyD installation, but one of weaknesses identified in the geolocation database used by the script was that a large proportion of the source IP addresses connecting to the honeypot environment weren’t none within the database. Markus pointed me in the direction of the cymruwhois (discussed previously)python module as an alternative. I’ve re-written the initial script, below:
#!/usr/bin/python from cymruwhois import Client import sys logfile = open('/var/log/honeypot/honeyd.log', 'r') source =  for line in logfile: source.append(line.split(' ')) src_country =  src_count =  c=Client() results=c.lookupmany_dict(set(source)) for res in results: country = results[res].cc try: pos = src_country.index( country ) src_count[pos] += 1 except: src_country.append( country ) src_count.append( 1 ) for i in range( 0, ( len( src_country ) - 1 ) ): sys.stdout.write( "%s:\t%i\n" %( src_country[i], src_count[i] ) )
So far this has resulted in far fewer unknown source locations, 249 using geoip compared to 3 using cymruwhois. The downside unfortunately is performance, the cymruwhois communicates with a remote host to gather information compared with the geolocation database that is already stored locally on the machine. Both perform some local caching of results/data however so I would expect the performane difference to decrease as larger datasets are analysed.
Using the newer script, based on the same 24hr data set, the top ten host countries communicating with InfoSanity’s honeyd environment are:
RU: 397 US: 234 TW: 179 BR: 158 CN: 123 RO: 107 DE: 101 IT: 96 JP: 91 AR: 86
— Andrew Waite
a tool written in Perl designed to generate a text summary from Honeyd logs. The summaries may be produced using different parameters as filters, such as ports, protocols, IP addresses or networks. It shows the top source and port access and the number of connections per hour, and supports input from multiple log files. The script can also correlate events from several honeypots.
Using the script from the commandline is straightforward; simple invoke with a config file and pass the honeyd log to be analysed. In addition to the usual textual output honeydsum is also capable of generating HTML results providing a quick and easy visual. The download site also includes some sample output files, both text and html (tgz archive).
Usage: honeydsum.pl -c honeydsum.conf [-hVw] log-file1 log-file2 … log-filen
-c honeydsum.conf file.
-h display this help and exit.
-V display version number and exit.
-w display output as web page (HTML).
The bulk of the text based output provides a list of connections made from external sources to the systems emulated by the HoneyD instance. Using the provided sample output as an example provides the information below; on a live and publically accessible system this output will be significantly longer:
-------------------------------------- Honeypot: 10.0.0.70 -------------------------------------- Source IP Resource Connections 192.168.50.20 21/tcp 1 192.168.100.130 21/tcp 1 192.168.177.253 11/icmp 1 192.168.139.133 11/icmp 1 -------------------------------------- IPs Resources Connections 4 2 4 --------------------------------------
The end of the output contains the information that I find most useful. It provides several different summaries of all the traffic captured by the whole HoneyD environment. Summaries include:
The most frequent remote sources:
Top 10 Source Hosts Rank Source IP Connections 1 192.168.100.130 3 2 192.168.139.133 2 3 192.168.50.20 1 4 192.168.131.157 1 5 192.168.217.41 1 6 192.168.207.84 1 7 192.168.177.253 1
Most requested emulated services/resources:
Top 10 Accessed Resources Rank Resource Connections 1 21/tcp 4 2 11/icmp 4 3 53/udp 2
— Andrew Waite
After getting a working HoneyD environment I wanted to better dig into the information provided by the system. First up was a quick script to get a feel for where the attacks/connections originate from. For location functionality GeoIP is the package for the job, as we’re using both Debian and Python installing the required tools is as simple as ‘apt-get install python-geoip’.
At first glance I really like the log format that is used by honeyd.log, it is nice an easy to parse from. From this I quickly knocked up a python script to parse the honeyd.log file, collect a list of unique source addresses and finally use GeoIP to determine (and count) the county of origin. The script (below) is basic, and most likely full of bugs but shows the ease with which tools can be forged to quickly gain the full value from the information collected by the HoneyD environment.
Version 0.01 is below; ignoring any likely bugs that need fixing the one thing that it definitely needs is to order the output, although I’m undecided if this should be alphabetically by country or by hit-count. Source Code:
#log file location hard coded, change to suit environment
logfile = open(‘/var/log/honeypot/honeyd.log’, ‘r’)
source = 
for line in logfile:
gi = GeoIP.new(GeoIP.GEOIP_MEMORY_CACHE)
src_country = 
src_count = 
for src in set(source):
country = gi.country_name_by_addr( src )
pos = src_country.index( country )
src_count[pos] += 1
src_country.append( country )
src_count.append( 1 )
for i in range( 0, ( len( src_country ) – 1 ) ):
sys.stdout.write( “%s:\t%i\n” %( src_country[i], src_count[i] ) )
Russian Federation: 43
Hong Kong: 3
United States: 54
United Kingdom: 12
Moldova, Republic of: 1
Antigua and Barbuda: 1
United Arab Emirates: 1
Korea, Republic of: 4
South Africa: 1
Costa Rica: 1
Iran, Islamic Republic of: 2
— Andrew Waite
After first getting HoneyD up and running previously for a proof of concept I’ve begun a wider implementation of HoneyD to function as the backbone for an upgraded research environment.
HoneyD’s key strength is it’s flexibility, HoneyD’s website contains some sample configuration files that show HoneyD emulating multiple systems running different OSes and applications, a large multi-site network and even a config file to create a honeypot environment for a wireless network. I’ve found these samples immensely useful references for developing custom templates for my own implementation.
At a bare minimum a HoneyD configuration file requires a defined default template, the current default template for this environment is borrowed from one of the sample files and is a tarpit, designed to slow down network sweeps and automated worms; similar to LaBrea tarpit.
set default personality “Microsoft Windows XP Professional SP1”
set default default tcp action tarpit open
set default default udp action block
set default default icmp action open
HoneyD can emulate both Windows and ‘nix systems (and many less common systems), for initial deployment we’re going with an even mix of Windows and Linux host template, each each with a template for a e-mail, web and development server.
# Linux Mail
set linux_mail personality “Linux 2.4.20”
set linux_mail default tcp action reset
set linux_mail default udp action block
set linux_mail default icmp action open
set linux_mail uptime 73921
add linux_mail tcp port 110 “sh scripts/unix/linux/suse8.0/qpop.sh $ipsrc $sport $ipdst $dport”
add linux_mail tcp port 143 “sh scripts/unix/linux/suse8.0/cyrus-imapd.sh $ipsrc $sport $ipdst $dport”
add linux_mail udp port 161 “perl scripts/unix/linux/suse8.0/fake-snmp.pl public private –config==scripts/unix/general”
bind 10.x.y.x linux_mail
# Linux Web
set linux_web personality “Linux 2.4.20”
set linux_web default tcp action reset
set linux_web default udp action block
set linux_web uptime 13282
add linux_web tcp port 21 “sh scripts/unix/linux/suse8.0/proftpd $ipsrc $spor$ipdst $dport”
add linux_web tcp port 80 “sh scripts/unix/linux/suse8.0/apache.sh $ipsrc $sport $ipdst $dport”
add linux_web udp port 161 “sh scripts/unix/general/snmp/fake-snmp.pl $ipsrc $sport $ipdst $dport”
bind 10.x.y.z linux_web
# Linux Development Box (EVERYTHING installed)
set linux_dev personality “Linux 2.4.20”
set linux_dev default tcp action reset
set linux_dev default udp action block
set linux_dev default icmp action open
set linux_dev uptime 8324
add linux_dev tcp port 21 “sh scripts/unix/linux/suse8.0/proftpd.sh $ipsrc $sport $ipdst $dport”
add linux_dev tcp port 22 “sh scripts/unix/linux/suse8.0/ssh.sh $ipsrc $sport $ipdst $dport”
add linux_dev tcp port 23 “sh scripts/unix/linux/suse8.0/telnetd.sh $ipsrc $sport $ipdst $dport”
add linux_dev tcp port 25 “sh scripts/unix/linux/suse8.0/sendmail.sh $ipsrc $sport $ipdst $dport”
add linux_dev tcp port 79 “sh scripts/unix/linux/suse8.0/fingerd.sh $ipsrc $sport $ipdst $dport”
add linux_dev tcp port 80 “sh scripts/unix/linux/suse8.0/apache.sh $ipsrc $sport $ipdst $dport”
add linux_dev tcp port 110 “sh scripts/unix/linux/suse8.0/qpop.sh $ipsrc $sport $ipdst $dport”
add linux_dev tcp port 111″perl scripts/unix/general/rpc/bportmapd –proto tcp –host scripts/unix/general/rpc/hosts/debian –srcip $ipsrc –dstip $ipdst –srcport $srcport –dstport $dport –logfile /var/log/honeyd –logall”
add linux_dev tcp port 143 “sh scripts/unix/linux/suse8.0/cyrus-imapd.sh $ipsrc $sport $ipdst $dport”
add linux_dev tcp port 515 “sh scripts/unix/linux/suse8.0/lpd.sh $ipsrc $sport $ipdst $dport”
add linux_dev tcp port 3128 “sh scripts/unix/linux/suse8.0/squid.sh $ipsrc $sport $ipdst $dport”
add linux_dev tcp port 8080 “sh scripts/unix/linux/suse8.0/squid.sh $ipsrc $sport $ipdst $dport”
add linux_dev tcp port 8081 “sh scripts/unix/linux/suse8.0/squid.sh $ipsrc $sport $ipdst $dport”
add linux_dev udp port 53 proxy 126.96.36.199:53
add linux_dev udp port 111″perl scripts/unix/general/rpc/bportmapd –proto udp –host scripts/unix/general/rpc/hosts/debian –srcip $ipsrc –dstip $ipdst –srcport $srcport –dstport $dport –logfile /var/log/honeyd –logall”
add linux_dev udp port 161 “perl scripts/unix/general/snmp/fake-snmp.pl public private –config=scripts/unix/general”
add linux_dev udp port 514 “sh scripts/unix/linux/suse8.0/syslogd.sh $ipsrc $sport $ipdst $dport”
bind 10.x.y.z linux_dev
# Windows Mail Server
set win_mail personality “Microsoft Windows Server 2003 Standard Edition”
set win_mail default tcp action reset
set win_mail default udp action block
set win_mail default icmp action open
set win_mail uptime 42256
add win_mail tcp port 25 “sh scripts/win32/win2k/exchange-smtp.sh $ipsrc $sport $ipdst $dport”
add win_mail tcp port 110 “sh scripts/win32/win2k/exchange-pop3.sh $ipsrc $sport $ipdst $dport”
add win_mail tcp port 143 “sh scripts/win32/win2k/exchange-imap.sh $ipsrc $sport $ipdst $dport”
add win_mail udp port 161 “perl scripts/unix/general/snmp/fake-snmp.pl public private –config=scripts/unix/general”
bind 10.x.y.z win_mail
# Windows Web Server
set win_web personality “Microsoft Windows Server 2003 Standard Edition”
set win_web default tcp action reset
set win_web default udp action block
set win_web default icmp action open
set win_web uptime 12256
add win_web tcp port 21 “sh scripts/win32/win2k/msftp.sh $ipsrc $sport $ipdst $dport”
add win_web tcp port 80 “sh scripts/win32/win2k/iis.sh $ipsrc $sport $ipdst $dport”
add win_web udp port 161 “perl scripts/unix/general/snmp/fake-snmp.pl public private –config=scripts/unix/general”
bind 10.x.y.z win_web
# Windows ‘Dev’ Server
set win_dev personality “Microsoft Windows Server 2003 Standard Edition”
set win_dev default tcp action reset
set win_dev default udp action block
set win_dev default icmp action open
set win_dev uptime 8826
add win_dev tcp port 21 “sh scripts/win32/win2k/msftp.sh $ipsrc $sport $ipdst $dport”
add win_dev tcp port 25 “sh scripts/win32/win2k/exchange-smtp.sh $ipsrc $sport $ipdst $dport”
add win_dev tcp port 80 “sh scripts/win32/win2k/iis.sh $ipsrc $sport $ipdst $dport”
add win_dev tcp port 110 “sh scripts/win32/win2k/exchange-pop3.sh $ipsrc $sport $ipdst $dport”
add win_dev tcp port 143 “sh scripts/win32/win2k/exchange-imap.sh $ipsrc $sport $ipdst $dport”
add win_dev tcp port 389 “sh scripts/win32/win2k/ldap.sh $ipsrc $sport $ipdst $dport”
add win_dev tcp port 5901 “sh scripts/win32/win2k/vnc.sh $ipsrc $sport $ipdst $dport”
add win_dev udp port 161 “perl scripts/unix/general/snmp/fake-snmp.pl public private –config=scripts/unix/general”
bind 10.x.y.z win_dev
As others have should in the sample configs I’ve linked to above, this config barely scratches the surface of HoneyD’s capabilities but it is sufficient to rapidly get a working honeypot environment working and collecting attack information.
Something that frequently surprises anyone not involved in infosec on a daily basis is the speed at which a newly connected system on the Internet will be targeted by a malicious party. In this case the environment was functioning for under a minute before it received it’s first contact from the outside world, as shown in the timestamps from HoneyD’s log file:
2010-04-17-16:41:09.2549 honeyd log started ——
2010-04-17-16:42:04.9735 tcp(6) – 188.8.131.52 2027 10.3.1.15 445: 48 S [Windows XP SP1]
2010-04-17-16:42:05.4878 tcp(6) – 184.108.40.206 2027 10.3.1.15 445: 48 S [Windows XP SP1]
2010-04-17-16:42:06.0341 tcp(6) – 220.127.116.11 2027 10.3.1.15 445: 48 S [Windows XP SP1]
2010-04-17-16:43:00.3707 tcp(6) – 18.104.22.168 1450 10.3.1.6 445: 64 S [Windows 2000 RFC1323]
2010-04-17-16:43:00.9051 tcp(6) – 22.214.171.124 1450 10.3.1.6 445: 64 S [Windows 2000 RFC1323]
2010-04-17-16:43:01.4310 tcp(6) – 126.96.36.199 1450 10.3.1.6 445: 64 S [Windows 2000 RFC1323]
2010-04-17-16:43:27.1202 tcp(6) – 188.8.131.52 1103 10.3.1.5 445: 48 S [Windows XP SP1]
— Andrew Waite
a small daemon that creates virtual hosts on a network. The hosts can be configured to run arbitrary services, and their personality can be adapted so that they appear to be running certain operating systems. Honeyd enables a single host to claim multiple addresses – I have tested up to 65536 – on a LAN for network simulation. Honeyd improves cyber security by providing mechanisms for threat detection and assessment. It also deters adversaries by hiding real systems in the middle of virtual systems.
My initial experience getting HoneyD running was frustration to say the least. Going with Debian to provide a stable OS, the install process should have been as simple as apt-get install honeyd. While keeping upto date with a Debian system can sometimes be difficult, the honeyd package is as current as it gets with version 1.5c.
For reasons that I can’t explain, this didn’t work first (or second) time so I reverted to compiling from source. The process could have been worse, only real stumbling block I hit was a naming clash within Debian’s package names. HoneyD requires the ‘dumb network’ package libdnet, but if you apt-get install libdnet you get Debian’s DECnet libraries. On Debian and deriviates you need libdumbnet1.
HoneyD’s configuration has the ability to get very complex depending on what you are looking to achieve. Thankfully a sample configuration is provided that includes examples of some of the most common configuration directives. Once you’ve got a config sorted (the sample works perfectly for testing), starting the honeyd is simple: honeyd -f /path/to/config-file. There are plenty of other runtime options available, but I haven’t had time to fully experiment with all of them; check the honeyd man pages for more information.
As well as emulating hosts and network topologies, HoneyD can be configured to run what it terms ‘subsystems’. Basically this are scripts that can be used to provide additional functionality on the emulated systems for an attacker/user to interact with. Some basic (and not so basic) subsystems are included with HoneyD. Some additional service emulation scripts that have been contributed to the HoneyD project can be found here. As part of the configuration, HoneyD can also pass specified IP/Ports through to live systems, either more indepth/specialised honeypot system or a full ‘real’ system to combine low and high interaction honeypot.
I’m still bearly scratching the surface of what HoneyD is capable of, and haven’t yet transfered my system to a live network to generate any statistics, but from my reading, research and experimentation I have high expectations.
— Andrew Waite