Category: network security

So this is the final article in this series of honeypots and honeyd and before I wrap it up I’ve gotta give big shout outs to Neils Provos the creator of honeyd. Neils has done an excellent job with the honeyd program and his book Virtual Honeypots is hands down the best book about honeypots and I highly recommend picking up a copy. While writing some of these tutorials Neils was even kind enough to answer some of my emails.

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.

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.

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.

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

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.

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

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.