One of the things that continues to grow in popularity is the deployment of honeypots and decoys on networks. Therefore, we want to deploy these in our architecture so that we can see how they react and what indications we can use to identify them when we encounter them.

There are a number of different honeypots that we might encounter, so we need to look at the characteristics that they exhibit. The best way to think of these is that there will be a number of ports that are shown as open; however, when you connect to them, they will not respond as expected.

The first honeypot that we will look at was created by Marcus Ranum many years ago when the Back Orifice tool was infecting machines around the Internet. The tool is no longer available, but you can search around on the Internet and you should be able to discover it. The tool is called BackOfficer Friendly, and it has a small footprint, but it is very effective in the role of a honeypot. The tool allows you to select a number of ports that it will listen on for connections. An example of these options is shown in the following screenshot:

As the previous screenshot shows, we have several of the ports set to listen on the honeypot. We do not have the Fake Replies option selected; this is because if this option is set, the banner will give the honeypot away. Now that we have the honeypot listening on this range of ports, we will scan it and see what it looks like when scanned.

An example of the results after scanning the machine with Nmap is shown in the following screenshot:

As the previous screenshot shows, we have these ports open on the machine, so we would want to explore this further. The preferred method is to connect to the ports manually and grab the banner of these ports, because if we scan the ports, they will report back as tcpwrapped; therefore, we will look at the ports manually. We have a number of methods we could use to connect to this port, and for the example in the book, we will use netcat. In the terminal window, enter nc -v <target> 25 to connect to the SMTP server; an example of this result is shown in the following screenshot:

As shown in the previous screenshot, the connection is not successful, so when we scan a target and get an indication of an open port as we did in the Nmap scan previously, then when we try to connect we cannot get a connection, then we have a pretty good indication that something is not right, so we need to explore further. So, we will try Telnet next, enter telnet <target> 25. An example of this is shown in the following screenshot:

As the screenshot shows, we have the message that the connection was closed, so we have more information and again we cannot connect to an open port, so we are leaning toward the fact that we have a honeypot, but we still do not know it for sure. So, as before we will try even harder to see what we can discover about this target. Enter nmap -sV <target>. An example of this is shown in the following screenshot:

Again, as a recap, when we scan the machine, we see that there are open ports; yet, when we attempt to connect to these identified open ports, we are not successful. This should not happen and, as such, is suspicious. It is important to remember that if it does not behave normally even though it has open ports, there is a good chance that you have encountered a honeypot. What about the honeypot itself? An example of this is shown in the following screenshot:

As the previous screenshot shows, the tool shows the connection attempts; even though the user does not get a connection, the honeypot still records it.

The next honeypot we will look at is the Labrea honeypot. Labrea provides a number of mechanisms that can be used if a malware communicates with the machine. The Labrea tool is available as a Debian package. As we have used Debian a number of times throughout the book, we will use it now to configure and set up the Labrea honeypot so that we can identify what it will look like if we encounter it when we are doing our testing.

In the terminal window of the Debian machine, enter apt-get install labrea to install the package. Once the software has installed, you can view the configuration file if you like. As it might not be located in the same place when you install the package, you can enter find / -name labrea.conf to locate the file and then open it in the editor of your choice. There is no need to change any configuration as it is set and ready to run once you install the package; however, as a note of caution, the Labrea tool will take up any IP address that is not used on the network. Therefore, you might want to configure a range of IP addresses as being excluded from the configuration file. Let us explore how this is done; open the conf file in your editor of choice, and locate the line for the exclusion of IP addresses. An example with a configured range of this is shown in the following screenshot:

Once you are ready to run the tool in the terminal window, enter labrea -v -i eth0 -sz -d -n <target> -o. We will not review the options, but you are encouraged to review them on your own. We have set the output to be written to the screen, so we will see the output of anything that the Labrea tool intercepts. An example of the output of the command is shown in the following screenshot:

One thing to note in the previous screenshot is the fact that the configuration file has been set to only respond to 1-3000 ports. Next, we need to see how the honeypot will respond on the network. We will use the Kali Linux machine; in a terminal window in Kali, enter fping -c 7 <target> where the target is any IP address of your target network.

An example of this for the 192.168.177 network is shown in the following screenshot:

As the previous screenshot shows, the first ping request comes back as unreachable. Therefore, there is no host there. The machine responds on the fourth ping; this is a response that is coming from the Labrea honeypot. We can verify this by referring to the terminal window where we started the program. An example of this is shown in the following screenshot:

To see the real power of the Labrea honeypot, we will use one of the tools in the Kali Linux distribution to ping a range of IP addresses. In the Kali Linux terminal, enter fping -g <target IP block>. An example of a portion of the results of this command is shown in the following screenshot:

This shows that the Labrea honeypot has created a decoy presence of all of the possible machines on the 192.168.177 subnet that are not in the exclusion list; these machines will appear to be live machines. This is to solicit connections to these IP addresses as they would be malicious.

The Labrea honeypot uses a technique called tarpitting, which causes the connections to take a very long time. As we have shown that there are a number of decoy machines out there, we will scan one of them now. In the Kali machine, enter nmap -sS <target ip address> -Pn.

An example of the results of a scan of one of the decoy machines is shown in the following screenshot:

Another response that we want to note is that of connecting to the machine using netcat; we will attempt this now. In the Kali machine, enter nc <target IP address> 445. An example of the results when we manually connect is shown in the following screenshot:

As the previous screenshot shows, every connection is detected by the honeypot and placed into the tarpit, making it take more time and trapping the communications to the machine.

You might be wondering, how can we detect that we are scanning a honeypot and not a real machine? One of the methods for this is shown in the following screenshot:

As the previous image shows, the machines that Labrea is pretending to respond for all have the same MAC address as a NEXT computer. This is one method that might assist us in the determination that we are talking to a honeypot and a decoy computer.

To research and learn more about Labrea, refer to http://sourceforge.net/projects/labrea/.

The next honeypot we will look at is the commercial product KFSensor. You can find out more about it at http://www.keyfocus.net/kfsensor/. The site will require that you register on it to download the tool. Once you have downloaded it, you need to install it on a Windows system. An example of the interface of the tool is shown in the following screenshot:

As the previous screenshot shows, we have numerous ports that are open via the honeypot, so the next step is to check and see what it would return once it is scanned. Remember that we want to perform our testing so that we know what to expect when we encounter a network with this honeypot. Furthermore, we want to ensure that we note the artifacts that can help us identify whether KFSensor is deployed on the network.

An example of an Nmap scan directed at the honeypot is shown in the following screenshot:

As the previous screenshot shows, we have the ports open, but Nmap is reporting them as script execution error. This is what it looks like when we do the Nmap scan, so what does it look like on the target? Moreover, what does the honeypot show? An example of this is shown in the following screenshot:

An added benefit of the tool is the fact that it also has numerous UDP ports open, and as such provides a very effective honeypot; furthermore, we can emulate ICMP as well.

An example of these options is shown in the following screenshot:

This is just a look at some of the many different honeypots that are available, and as such, you should practice with the different ones on your testing range and document how each of them behave once they are deployed.