Honeypot / honeyd tutorial

Honeypot / honeyd tutorial part 1, getting started

If you’ve somehow found my obscure site then you probably already know a little bit about honeypots and their functionality, if not here is a good breakdown. There are many different types of honeypots and these different types are explained very well in the book Virtual Honeypots which I highly recommend you read if you are serious about deploying a honeypot. This series of articles will focus on honeypots using an application called honeyd. There are a number of honeypot solutions out there but I personally feel like honeyd is a great fit because it can be relatively simple or you can start tweaking it to get a more full featured product. You may think of honeypots as internet facing and it’s true that they can be configured that way but during this series of tutorials I will only be using honeyd on an internal network. Internet facing honeypots are mainly used to research and find new malware, internal honeypots are mainly used as alerting systems that would alert you when other devices / users are connecting to your honeypots. You can also use honeyd when investigating malware which I’ll discuss in a later tutorial.
For this tutorial I will be using one Windows machine and one Linux machine, Backtrack distribution to be exact. Backtrack will be the machine that is running honeyd. Honeyd is available for Windows but I highly recommend that you use honeyd on Linux. If you’re half way interested in information security then I suggest that you get to know Linux as there are a lot of information security tools such as honeyd that use Linux. Sorry for the Linux rant, below is basic diagram of my setup.

The idea here is that we’ll install and configure honeyd on Backtrack then simply test that we have connectivity with our Windows machine. To see if you have honeyd installed on Backtrack (or any Linux system) simply type “honey + TAB”, if “d” is shown right after honey then you know you have honeyd installed as it is an available command if you don’t have honeyd installed on Backtrack run the following command

sudo apt-get install honeyd

This will also work for any Debian based Linux system. To install on other distributions such as Gentoo, Fedora, Slackware, etc I would check their documentation on how to install packages. After honeyd is installed the next thing we’ll need to do is create a configuration file. A honeyd configuration file is the heart of your honeypot. The configuration file tells honeyd what operating system to emulate, what ports to open, what services should be ran, etc. This config file can be tweaked to emulate all sorts setups but for right now let’s look at a simple setup and get that up and running. Below is my config file.

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

create windows
set windows personality "Microsoft Windows XP Professional SP1"
set windows default tcp action reset
add windows tcp port 135 open
add windows tcp port 139 open
add windows tcp port 445 open

set windows ethernet "00:00:24:ab:8c:12"
dhcp windows on eth0

Within Backtrack you can use Kate or nano text editors to create this file. In Backtrack Kate is under the Utilities menu. The “create default” section simply tells honeyd to drop traffic unless it is defined later in the configuration file. I find this section is needed when you let your honeypot acquire an IP address via dhcp. Also it’s probably a good idea to implement this section so that you only answer to network connections that you define later in the config file. Anytime you see “create” within the config file you are creating a template for a honeypot, so you can create as many honeypots as you’d like within the honed.conf config. In the windows template we are defining a number of things. First we are setting the personality, meaning when another device on the network connects to this honeypot it will appear to be a Windows XP Pro SP1 device. This is emulated via network stack fingerprints. In the windows template I’m also opening up three ports (135, 139, and 445). These are common ports that are open on a windows system. The “action reset” statement will drop traffic if it is not aimed at the open ports defined in this config. The “set windows ethernet” sets a MAC address for our honeypot.  This will be needed if you run your honeypot via dhcp. You can simply make up any MAC address you’d like, I usually keep it close to the physical MAC address that I’m running the honeypot off of. Finally the dhcp statement tells the windows template to acquire an IP address from dhcp. Now that we have our honeyd.conf file properly setup it’s time to launch honeyd, below is the command I use when initially getting honeyd up and running.

honeyd  -d  -f  honeyd.conf

Here we use the -d so that it doesn’t run in the background (or doesn’t run as a daemon in Linux terms). This allow for more verbose output so that we can troubleshoot as needed. Running in this mode will also show the IP that was given to our honeypot via dhcp. Below is the type of output you should see after running the honeyd command.

Honeyd V1.5c Copyright (c) 2002-2007 Niels Provos
honeyd[1870]: started with -d -f honeyd.conf
Warning: Impossible SI range in Class fingerprint "IBM OS/400 V4R2M0"
Warning: Impossible SI range in Class fingerprint "Microsoft Windows NT 4.0 SP3"
honeyd[1870]: listening promiscuously on eth0: (arp or ip proto 47 or (udp and src ...
honeyd[1870]: [eth0] trying DHCP
honeyd[1870]: Demoting process privileges to uid 65534, gid 65534
honeyd[1870]: [eth0] got DHCP offer: 192.168.99.135
honeyd[1870]: Updating ARP binding: 00:00:24:c8:e3:34 -> 192.168.99.135

In this verbose output we see that dhcp gave our honeypot the address of 192.168.99.135. From our windows machine let’s ping that IP address and make sure that we have connectivity. You should see output on the terminal similar to below.

honeyd[1870]: arp reply 192.168.99.135 is-at 00:00:24:c8:e3:34
honeyd[1870]: Sending ICMP Echo Reply: 192.168.99.135 -> 192.168.99.128
honeyd[1870]: arp_send: who-has 192.168.99.128 tell 192.168.99.135
honeyd[1870]: arp_recv_cb: 192.168.99.128 at 00:0c:29:7e:60:d0
honeyd[1870]: Sending ICMP Echo Reply: 192.168.99.135 -> 192.168.99.128
honeyd[1870]: Sending ICMP Echo Reply: 192.168.99.135 -> 192.168.99.128
honeyd[1870]: Sending ICMP Echo Reply: 192.168.99.135 -> 192.168.99.128

So congrats you’ve successfully deployed honeyd. We can now ping our honeypot but we need to make sure the ports we’ve configured to be open are open. Let’s us the cadillac of port scanners nmap to detect open ports on our honeypot. You can scan for all 65,535 ports on our honeypot but to keep the verbose output of honeyd low let’s just scan for a handful of ports. Below is the nmap command I used.

nmap -p 135,139,445,1337 192.168.99.135

The output of this command should look similar to below.

Starting Nmap 5.00 ( http://nmap.org ) at 2011-05-06 13:13 EDT
Interesting ports on someone (172.20.73.77):
PORT     STATE  SERVICE
135/tcp  open   msrpc
139/tcp  open   netbios-ssn
445/tcp  open   microsoft-ds
1337/tcp closed waste
MAC Address: 00:00:24:26:C4:ED (Connect AS)

Nmap done: 1 IP address (1 host up) scanned in 0.37 seconds

So honeyd appears to be working correctly. If you’ve reached this point then you are on your way to doing even more with honeypots and honeyd. The main purpose of this article was to get you up and running. In the next series of articles we’ll configure more honeypots, set static IP’s, get alerts on devices port scanning our honeypots, investigate malware, etc. If you have any questions, catch errors, or have any feedback please comment below.

Honeypot / honeyd tutorial part 2, multiple honeypots

Part one of this series was to mainly get honeyd up and running. Hopefully you also took away from part one that the configuration file, honeyd.conf, is the key to making things work smoothly and properly. Now that you’ve got honeyd up and running let’s tweak honeyd.conf so that we have multiple honeypots running on one installation of honeyd. One honeypot is great but having three or four is even better. Part two is dedicated to showing you how to properly setup multiple honeypots in honeyd. In part one we only emulated a Windows device via the line below in honeyd.conf

set windows personality "Microsoft Windows XP Professional SP1"
set windows default tcp action reset

The personality tries to emulate what device you are trying to pretend to be. There are plenty of other personalities we could choose from so when setting up multiple honeypots you may want to emulate other devices besides a standard Windows device. Maybe you’d like to emulate a Solaris box, PBX system, or if you are going to emulate a Windows device make it real juicy to an attacker by making it a Windows 98 device. You’ve got plenty of options when choosing a personality for your honeypot. Honeyd takes advantage of nmap and the way it fingerprints devices. The list of personalities is located in the nmap.prints file, you should be able to find this file by using the following command

locate nmap.prints

You can view this file using less, for me I issued the following command.

less /usr/share/honeyd/nmap.prints

Nmap has a version of this file as well named “nmap-os-db”. The nmap.prints and the nmap-os-db may or may not match up depending on your versions of nmap and honeyd. My nmap-os-db is in the following location.

/usr/share/nmap/nmap-os-db

Within nmap.prints anything that follows the word “Fingerprint” is available as a personality. As an example below the string “Avaya G3 PBX version 8.3″ can be used as a personality in honeyd.conf

In my example I will emulate this Avaya PBX device and I will also emulate a Soalris device. So a diagram of my setup looks like the following.

So now that I’ve decided to also emulate a Solaris and Avaya device I’ll need to add both of these do honeyd.conf. Basically all you’ll need to do is copy and paste from the Windows device you’ve already setup in honeyd.conf then make some minor modifications such as the personality. My honeyd.conf for all three of these honeypots is below.

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

create windows
set windows personality "Microsoft Windows XP Professional SP1"
set windows default tcp action reset
add windows tcp port 135 open
add windows tcp port 139 open
add windows tcp port 445 open

create avaya
set avaya personality "Avaya G3 PBX version 8.3"
set avaya default tcp action reset
add avaya tcp port 4445 open
add avaya tcp port 5038 open

create solaris
set solaris personality "Avaya G3 PBX version 8.3"
set solaris default tcp action reset
add solaris tcp port 22 open
add solaris tcp port 2049 open

set windows ethernet "00:00:24:ab:8c:12"
set avaya ethernet "00:00:24:ab:8c:13"
set solaris ethernet "00:00:24:ab:8c:14"
dhcp windows on eth1
dhcp avaya on eth1
dhcp solaris on eth1

After you’ve added this information to honeyd.conf go ahead and run honeyd with the options discussed in part one, you should see the following.

root@bt:~# honeyd -d -f honeyd.conf
Honeyd V1.5c Copyright (c) 2002-2007 Niels Provos
honeyd[2697]: started with -d -f honeyd.conf
Warning: Impossible SI range in Class fingerprint "IBM OS/400 V4R2M0"
Warning: Impossible SI range in Class fingerprint "Microsoft Windows NT 4.0 SP3"
honeyd[2697]: listening promiscuously on eth1: (arp or ip proto 47 or (udp and src port 67 and dst port 68) or (ip )) and not ether src 00:0c:29:88:e6:db
honeyd[2697]: [eth1] trying DHCP
honeyd[2697]: [eth1] trying DHCP
honeyd[2697]: [eth1] trying DHCP
honeyd[2697]: Demoting process privileges to uid 65534, gid 65534
honeyd[2697]: [eth1] got DHCP offer: 192.168.99.159
honeyd[2697]: Updating ARP binding: 00:00:24:c5:59:29 -> 192.168.99.159
honeyd[2697]: [eth1] got DHCP offer: 192.168.99.160
honeyd[2697]: Updating ARP binding: 00:00:24:02:ac:73 -> 192.168.99.160
honeyd[2697]: [eth1] got DHCP offer: 192.168.99.161
honeyd[2697]: Updating ARP binding: 00:00:24:68:0c:45 -> 192.168.99.161
honeyd[2697]: arp reply 192.168.99.159 is-at 00:00:24:c5:59:29
honeyd[2697]: arp reply 192.168.99.160 is-at 00:00:24:02:ac:73
honeyd[2697]: arp reply 192.168.99.161 is-at 00:00:24:68:0c:45
honeyd[2697]: Sending ICMP Echo Reply: 192.168.99.159 -> 192.168.99.254
honeyd[2697]: arp_send: who-has 192.168.99.254 tell 192.168.99.159
honeyd[2697]: Sending ICMP Echo Reply: 192.168.99.160 -> 192.168.99.254
honeyd[2697]: Sending ICMP Echo Reply: 192.168.99.161 -> 192.168.99.254
honeyd[2697]: arp_recv_cb: 192.168.99.254 at 00:50:56:ec:10:84

If everything has gone smooth up to this point you’ve gotten output similar to above. So currently we’ve got three honeypots running on one installation of honeyd. Now the proof is in the pudding by port scanning these devices and see if the ports are open and what OS nmap claims it to be. DHCP gave our Avaya device an IP address of 192.168.99.160, let’s port scan for the two open ports and a port we know to be closed and see what results we get.

travis@tht:~/documents$ nmap -p 4445,5038,5555 192.168.99.160

Starting Nmap 5.00 ( http://nmap.org ) at 2011-06-15 01:25 EDT
Interesting ports on 192.168.99.160:
PORT     STATE  SERVICE
4445/tcp open   unknown
5038/tcp open   unknown
5555/tcp closed freeciv

Nmap done: 1 IP address (1 host up) scanned in 1.18 seconds

Looks like everything is on the up and up with our Avaya device. Port 5555 is closed because we did not define it in honeyd.conf. I’ll spare you with the nmap scan of the Solaris device but everything was operating as normal for it as well. So the ports are open but how well is this personality thing working? Nmap can try and determine the OS of a device through a number of TCP exchanges. Honeyd tries to use the nmap fingerprint database to send the appropriate TCP responses to a nmap scan so that the personality you’ve assigned to your template will respond as it should. This doesn’t always work properly. New versions of nmap are constantly coming out which means the nmap fingerprint database is changing as well. So nmap may respond properly or it may not, this will just depend on the version of nmap you or an attacker is scanning with. It will also depend on the nmap.prints that honeyd uses as well. You can perform an OS detection in nmap by providing it the -O option, let’s try scanning our Solaris device and see what it returns.

Seeing how this might happen you don’t want to totally rely on the personality in honeyd. The best idea is to open up ports that are common to a particular device. For instance most Linux and Solaris devices have port 22 open while routers and switches will probably have port 161 open (SNMP). The configuration is totally up to you but trying to make your honeypot as sweet as possible is the main goal.
So adding multiple honeypots to your honeyd install is fairly straightforward but there are some things to consider when setting it up. Other topics such as email alerts are coming but for now make sure you can get multiple honeypots running via honyed.

Honeypot / honeyd tutorial part 3, static IP’s

In the past two tutorials I’ve used DHCP to obtain IP’s for our honeypots running honeyd. Using dhcp is fine when testing honeyd and getting familiar with how honeyd works but a static IP may be more suitable for your environment. In my case I initially fooled around with honeyd via dhcp but when I wanted to implement in a more production environment I realized that static IP’s are more stable and less maintenance. In order to ping our honeypot the router / switch has to know what IP and MAC address our honeypot has so it can update it’s information, going through dhcp does this automatically. I’ll touch on how to add the static IP configuration later but first let’s go over our layout. I’ll be using the same simple layout as in the first tutorial as seen below.

There may need to be some clarification in that diagram. Backtrack is what is actually running honeyd, the address of 192.168.99.135 (labeled Honeyd) which is the honeypot honeyd created can be configured to emulate any operating system. Now for the honeyd config file.

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

create windows
set windows personality "Microsoft Windows XP Professional SP1"
set windows default tcp action reset
add windows tcp port 135 open
add windows tcp port 139 open
add windows tcp port 445 open

set windows ethernet "00:00:24:ab:8c:12"

bind 192.168.99.135 windows

So the only real difference between dhcp and a static IP is the last line of the config. If you go back to the first tutorial you’ll notice the last line is the only difference as well. As a side I’ve used some configs that do not have the MAC address defined in their config but when I did not include the “set windows ethernet” line honeyd would complain and not start. So after you’ve set your config simply start honeyd.

honeyd  -d  -f  honeyd.conf

After running honeyd you should get similar output to below.

Honeyd V1.5c Copyright (c) 2002-2007 Niels Provos
honeyd[27305]: started with -d -f honeyd.conf
Warning: Impossible SI range in Class fingerprint "IBM OS/400 V4R2M0"
Warning: Impossible SI range in Class fingerprint "Microsoft Windows NT 4.0 SP3"
honeyd[27305]: listening promiscuously on eth0: (arp or ip proto 47 or (udp and src port 67 and dst port 68) or (ip )) and not ether src 00:00:24:ca:6b:08
honeyd[27305]: Demoting process privileges to uid 65534, gid 65534

The difference in output between static and dynamic is that you’ll see the IP address your honeypot gets when using DHCP. With static IP configuration you’re not going to get that in your output because you already know the IP you’re using. So the output via DHCP will the lines below included.

honeyd[1870]: [eth0] trying DHCP
honeyd[1870]: Demoting process privileges to uid 65534, gid 65534
honeyd[1870]: [eth0] got DHCP offer: 192.168.99.135

So now you’ve take care of properly setting up honeyd to use a static IP address but now you’ll have to configure the network to use your static IP. In my enterprise production environment I’ve configured this via the DHCP server. I went into the DHCP server and made a static reservation. I also had to configure the switch I plugged my computer into and tell what VLAN that port needed to be assigned to. If you’re trying to get this set up in your work production environment you may have to work with your network team that manages DHCP / DNS / routers & switches. Networks may be managed differently so check with your local team on how you would get a static IP. Now if you’re doing this on a home network for testing then you probably have a wireless router such as Linksys. Inside all of these home wireless routers you can configure static IP’s. Each wireless router will have different steps for configuring static IP’s so refer to your manufacturers documentation on how to do that.
Next in this tutorial is what to run your honeypot / honeyd on? Laptop, desktop, server? These questions will be tackled in future articles.

Honeypot / honeyd tutorial part 4, hardware

So up to this point you’ve probably only ran honeyd on your laptop or desktop machine. If you want to get the most out of honeyd then you’ll probably want to run it on either a server or an embedded device. In the beginning of this series I mentioned you could run a honeypot in a number of ways. Two of the ways I mentioned was to attract malware to a vulnerable system so that you can analyze the latest and greatest malware. The other way was to attract attackers on your network. In my series I’m going to keep the focus on detecting attackers on the local network and not trying to find new malware. The honeynet project already does a great job of tracking down the latest and greatest malware so check that project out.
If you’re going to use honeyd to detect attackers on your local network then you’ll need to place your honeypot as close to your networking equipment as possible. This being the case a racked server or small device with numerous network interfaces will likely be the best solution. A racked server didn’t make much sense for my solution mainly due to the cost but a small embedded device would need good specs to make a good solution. I found a couple of solutions.
First the option that I went with to implement my honeypot running honeyd. The Soekris Net5501.


The great thing about the Soekris is that it has four network interfaces. This allows you access to four different vlans within your environment. Out of the box it comes with the ability to load an OS on compact flash, which is the option that I went with. You could also get a PCI extension that could be fitted with a hard drive. If your install of a honeypot would require large data storage then you’ll need to think about that option. I did not care about data storage, I simply wanted an alert when honeyd saw something come across the wire. Besides even if you needed storage you could have honeyd ship off that data / logs to a centralized location. For $250 bucks this is a great solution. You won’t find to many small devices like this that have four network interfaces. Now you could get a full rack system with plenty of network interfaces but then your cost goes up. More network interfaces would mean that you have access to more vlans so if that’s important to you then you’ll have to plan accordingly. This is setup is not meant to cover your entire organization just a handful of important vlans. Below is a diagram of a potential setup.

In this setup you can place a honeyd host on four different vlans looking for any devices that connect to your honeypot when they should have no business connecting to your honeypot. Keep in mind this is not meant to be an intrusion detection replacement. This solution will ride on top of your existing intrusion detection. Besides most intrusion detection setups that I’ve seen don’t monitor activity inside a particular vlan much less traffic between vlans. The setup I’ve described here is meant to monitor vlans with important assests and data. So in the scenario above you would have to connect your Soekris device to a “core” router that has the vlans you want to monitor. You could also connect the Soekris device to multiple routers if those vlans are mananged by different routers. There are numerous ways to tackle a problem that I’ve described but this is just one of those ways.
There is another device that I believe is very handy in these types of situations and that’s the Alix boards by PC Engines. If you want to buy one I would recomend NetGate which also has other options such as enclosures and lots of other wireless goodness. The Alix board plus enclosure is very small, about the same size of a home wireless router. Below is an Alix board without the enclosure.

You can buy them with a number of configurations, the one above has three network interfaces, one compact flash, one mini pci, plus a cpu and RAM. So no hard drive but you can easily run your OS on the compact flash. Of course the OS of choice should be Linux. Hopefully this answers the question as to what hardware you might could use for your installation of a honeypot in your organization’s environment. Unless you do everything at your organization this type of work will require you to work closely with your network engineering team. That’s all I have, I’d love to hear from others on how they have their honeypots setup and what hardware is powering that setup. Please comment if you have a question.