Up to this point you hopefully have an understanding on how to get honeyd up and running on your preferred hardware while having the ability to run multiple honeypots in either a static or dhcp environment. Now that everything is running smoothly and you’ve successfully tested all connectivity you’ll probably want to start getting alerts from some of the honeypots you’ve setup and deployed. I’ve written a small python script that accomplishes this for me so hopefully my explanation of the setup will get you receiving email alerts as well.

So out of the box honeyd doesn’t natively support getting emails sent to you when your device is port scanned. I really wanted this feature but had to figure out the best way of determining when my honeypot was being scanned. Honeyd has the option of creating a log file so my first idea was to parse this file for items of interest. Below is the command I would use to launch honeyd with the logging option.

You should see similar output as below after running the above command.

So this just created a honeypot with the IP address of 192.168.134.147. From another machine let’s port scan our honeypot, to keep the output simple I’m only going to scan one port.

So port 135 is open so we know our configuration is working properly. Also honeyd will output information to the terminal letting you know that connections are being made to your honeypot. The information below was appended to the output from when we started honeyd.

On line three we see a connection request from 192.168.134.143 to our honeypot at 192.168.134.147 and the “:135″ after the IP address is the destination port so from this output we can verify everything is working and we’re getting the correct response from our port scan. You also see on line six that the connection from 192.168.134.143 to 192.168.134.147 was dropped. Now let’s take a look at our log file to see what kind of information about our port scan shows up. We’ll use the tail command in Linux, by default the tail command only shows the last 10 lines of a file although this can be adjusted.

In the log file we see very similar information on lines 5 and 6 as we did in the standard output of the terminal. Turns out there’s a third location of output that we could tap into. All processes in Linux will probably display some kind of information into one of two system log files. Either the /var/log/messages or the /var/log/syslog file. Different distros of Linux will put this information into different locations but for the backtrack distro I know it goes into /var/log/syslog. Let’s tail this file to see what kind of information it holds.

On lines 7 and 10 we see similar information as we’ve seen in other areas. So when I decided to build an email alert script I had three sources of information I could pull from. I eventually went with combing through /var/log/syslog but I could have easily went a different route. For me /var/log/syslog seem to have more verbosity and better keywords but then again that’s just my opinion. My next step was to write a script that would parse /var/log/syslog then generate an email alert when it saw connections to my honeypot. I wrote my script in Python because I’m most familiar with that language and Python comes installed by default on most Linux distributions so whatever distro you decide to run honeyd on it’s more than likely Python will already be installed on that same operating system.

Before you implement any scripted email solution it’s a good idea to test email functionality with a small email script just to ensure you can properly communicate and receive email alerts. To do this you’ll need to know the name (FQDN) of your SMTP email server. You can usually find them in your email client. For Outlook you can go to File > Account Settings > Account Settings > Email tab > click on Change, there you’ll see the name of your organizations smtp server. Typically it’ll be something simple, if the email of your organization ends in example.com then your smtp server will likely be smtp.example.com. SMTP servers are usually configured to send emails in one of two ways, authenticated or unauthenticated. We’ll look at examples for both. The first example below is a python script of sending authentication credentials along with the request, in this particular I’m sending the alert to my gmail account.

Hopefully some of this script is easy to figure out, the main thing you need to be concerned with is lines 11,12, and 15. Lines 11 and 12 hold the username and password you’ll need to authenticate to your smtp server and line 15 is the name of your smtp server. More than likely your internal smtp server will not require authentication if that’s the case simply remove lines 11,12,16, and 17 from the script above. If you’re not sure first send the test email without authentication and if you get the error message “smtplib.SMTPSenderRefused” then more than likely you’ll need to provide credentials. If everything goes smooth running your test email script then you should see the output below, here I’ve named my script test.py.

Next you can implement the full email alerting script. Simply copy and paste the script below into your text editor of choice and name the script, I’ve named my alert.py.

I’m not a developer and I always mangle my scripts together so this isn’t the prettiest code. I’ll give you a run down of what this script does, if you have any specific questions please feel free to leave a comment I generally respond to comments fairly quickly. Basically the script combs through /var/log/syslog looking for the string “Connection request”. I’ve also confirmed that this script works just as well combing through /var/log/messages, you’ll have to verify which log your Linux distro is dumping this information. To test the script to make sure it works I would first port scan your honeypot from another device then simply run the python script to see if you get no errors and hopefully you get an email in your inbox, just run the following command after you’ve port scanned your honeypot.

This command should only run for maybe 10 seconds then return you to the command line. If you get any errors then you’ll have to trouble shoot the script, contact me if you need help with that. Just to give you an idea of what the email alert would look like I’ve got a screen shot of an alert I got sent to my gmail address below.

Currently the script only looks for “Connection request” in the last five minutes of log files so you’ll need to combo that up with running the script every five minutes, this can be done with Linux’s crontab. Cron can schedule programs to be run at certain frequencies. To set up alert.py to run every five minutes use the crontab command.

This opens up a text file in the terminal where you enter a specific syntax to tell cron which program you want to run and how often. Enter the text below to tell cron to run alert.py every five minutes.

Then use control+w to save your work and control+x to quit the text editor. So in the alert.py script the every five minutes comes from line 33 where 300 is seconds which equals five minutes so if you wanted to modify the time you could do it on that line. Another line in the script you may want to change is line 25, here you can add any IP’s that you want to ignore for whatever reason. You’ll definitely want to change line 55 that has the text of the email you’ll be receiving and customize that to your hearts content. Don’t forget to modify smtp server information and also remove or change the authentication piece as needed. Also in the screenshot you’ll notice that the device is “bt” which is short for backtrack. I implemented this feature because you may want to run honeyd on multiple devices throughout your network and you’ll want to know what device is sending you the email. The name of the device is determined in lines 17-20. You may have to modify that code because not all distros of Linux keep their hostname in that location and you may have to parse the text file that holds that hostname in a different manner. There’s more information that I could go into about the script but hopefully I’ve hit the major points if there’s something I missed or if you have any questions or feedback please leave comments.

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