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.

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.

After running honeyd you should get similar output to below.

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.

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.

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

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

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

The output of this command should look similar to below.

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.

If a malicious user is on the same network as you there are numerous types of attacks they could carry out to compromise your computer and identity. One common attack they might use is called ARP (Address Resolution Protocol) spoofing. Before we get into the details of ARP spoofing it’s helpful to understand how this protocol came about.

The early developers of Ethernet or LAN technology designed the system based upon trust, meaning they never thought anyone using this technology would use it in a malicious way. About thirty years ago, the early stages of Ethernet development, it was hard to imagine a large scale LAN. Hardware was very expensive in those days and only large organizations could afford such technology, even then these large organizations only had a small number of computers that could communicate with one another. So it was hard to imagine that they would ever communicate with someone they didn’t trust. Problem is that Ethernet exists on Layer 2 using a flat addressing scheme (e.g. MAC address). This type of addressing doesn’t scale well for the internet, which uses a hierarchical addressing scheme (e.g. IP). The solution to this problem was ARP.

ARP is used for mapping IP addresses to MAC addresses. A basic diagram for ARP can be seen in figure 1 below.

Figure 1: ARP protocol diagram

So A wants to communicate with B:

1. A checks its local ARP table for B’s info
2. A doesn’t have B’s info so its sends a request
3. Router closet to B adds A’s info to ARP table
4. Router sends B’s info to A so it can update its ARP table
5. ARP info updated, A & B can now communicate

This ARP thing seems to work out nicely, so what’s the problem? In an untrusted environment how does A know that B is who he says he is? Turns out that the ARP protocol has a slew of vulnerabilities.

Vulnerabilities of ARP:

• No authentication! (you cannot be assured who you are talking to)
• ARP tables can be manipulated by anyone on the LAN
• Allows malicious users to pretend to be someone else (the SPOOF)
• Perfect protocol for launching Man in the Middle Attacks (MITM)

Once a malicious user is on your LAN they can easily manipulate ARP tables, spoof who you are trying to communicate with, and launch a MITM attack. A MITM attack allows the attacker to sniff all your traffic and pick up sensitive information (e.g. username, passwords). A diagram of a MITM attack can be seen in figure 2.

Figure 2: Man in the middle diagram

Anytime you are on an untrusted LAN (e.g. Hotel, Public WiFi, University, any large organization) there is the possibility that someone could be listening in on your communications via ARP spoofing. There are plenty of tools available that would allow even the most novice attacker to gain your personal information. So if you are going to communicate on an untrusted LAN here are some tips to stay secure.

• Use encryption (e.g. SSL, SSH, or VPN)
• If unencrypted, don’t communicate private information
• Only visit trusted websites (easier said than done)

For system administrators there are two countermeasures against ARP spoofing.

1. Static ARP tables (difficult to maintain)
2. Arpwatch (will notify if someone is ARP spoofing)

The point of this article is to educate others about how protocols behind the scenes work and how insecure they can be. If you can’t trust everyone on your current LAN, then use encryption and stay away from communicating sensitive information. Now you know, and knowing is half the battle. As always feel free to leave comments if you find any errors within this article.

References:

http://www.grc.com/nat/arp.htm, http://en.wikipedia.org/wiki/ARP_spoofing