Honeypots and Honeynets

This tutorial explains what honeypots and honeynets are and how they work, including a practical implementation example.

Part of the work of security IT specialists is to learn about the types of attacks or techniques used by hackers by collecting information for later analysis to evaluate the attack attempts characteristics. Sometimes this collection of information is done through bait or decoys designed to register the suspicious activity of potential attackers who act without knowing their activity is being monitored. In IT security, these baits or decoys are called Honeypots.

What are honeypots and honeynets:

A honeypot may be an application simulating a target which is really a recorder of attackers’ activity. Multiple Honeypots simulating multiple services, devices, and applications are denominated Honeynets.

Honeypots and Honeynets don’t store sensitive information but store fake attractive information to attackers to get them interested in the Honeypots; Honeynets, in other words, are talking about hacker traps designed to learn their attack techniques.

Honeypots give us two benefits: first, they help us learn attacks to secure our production device or network properly. Second, by keeping honeypots simulating vulnerabilities next to production devices or networks, we keep hackers’ attention out of secured devices. They will find more attractive the honeypots simulating security holes they can exploit.

Honeypot types:

Production Honeypots:
This type of honeypot is installed in a production network to collect information on techniques used to attack systems within the infrastructure. This type of honeypot offers a wide variety of possibilities, from the location of the honeypot within a specific network segment in order to detect internal attempts by network legitimate users to access unallowed or forbidden resources to a clone of a website or service, identical to the original as bait. The biggest issue of this type of honeypot is allowing malicious traffic between legitimate ones.

Development honeypots:
This type of honeypot is designed to collect more information on hacking trends, desired targets by attackers, and attack origins. This information is later analyzed for the decision-making process on security measures implementation.
The main advantage of this type of honeypots is, contrary to production; honeypots development honeypots are located within an independent network dedicated to research; this vulnerable system is separated from the production environment preventing an attack from the honeypot itself. Its main disadvantage is the number of resources necessary to implement it.

There are 3 different honeypot subcategories or classification types defined by the interaction level it has with attackers.

Low Interaction Honeypots:

A Honeypot emulates a vulnerable service, app, or system. This is very easy to set up but limited when collecting information; some examples of this type of honeypots are:

• Honeytrap: it is designed to observe attacks against network services; contrary to other honeypots, which focus on capturing malware, this type of honeypot is designed to capture exploits.
• Nephentes: emulates known vulnerabilities in order to collect information on possible attacks; it is designed to emulate vulnerabilities worms exploits to propagate, then Nephentes captures their code for later analysis.
• HoneyC: identifies malicious web servers within the networking by emulating different clients and collecting server responses when replying to requests.
• HoneyD: is a daemon that creates virtual hosts within a network that can be configured to run arbitrary services simulating execution in different OS.
• Glastopf: emulates thousands of vulnerabilities designed to collect attack information against web applications. It is easy to set up, and once indexed by search engines; it becomes an attractive target to hackers.

Medium Interaction Honeypots:

In this scenario, Honeypots aren’t designed to collect information only; it is an application designed to interact with attackers while exhaustively registering the interaction activity; it simulates a target capable of offering all answers the attacker may expect; some honeypots of this type are:

• Cowrie: A ssh and telnet honeypot which logs brute force attacks and hackers shell interaction. It emulates a Unix OS and works as a proxy to log the attacker’s activity. After this section, you can find instructions for Cowrie implementation.
• Sticky_elephant: it is a PostgreSQL honeypot.
• Hornet: An improved version of honeypot-wasp with fake credentials prompt designed for websites with public access login page for administrators such as /wp-admin for WordPress sites.

High Interaction Honeypots:

In this scenario, Honeypots aren’t designed to collect information only; it is an application designed to interact with attackers while exhaustively registering the interaction activity; it simulates a target capable of offering all answers the attacker may expect; some honeypots of this type are:

• Sebek: works as a HIDS (Host-based Intrusion Detection System), allowing to capture information on system activity. This is a server-client tool capable of deploying honeypots on Linux, Unix, and Windows that capture and send the collected information to the server.
• HoneyBow: can be integrated with low interaction honeypots to increase information collection.
• HI-HAT (High Interaction Honeypot Analysis Toolkit): converts PHP files into high interaction honeypots with a web interface available to monitor the information.
• Capture-HPC: similar to HoneyC, identifies malicious servers by interacting with clients using a dedicated virtual machine and registering unauthorized changes.

Below you can find a medium interaction honeypot practical example.

Deploying Cowrie to collect data on SSH attacks:

As said previously, Cowrie is a honeypot used to record information on attacks targeting the ssh service. Cowrie simulates a vulnerable ssh server allowing any attacker to access a fake terminal, simulating a successful attack while recording the attacker’s activity.

For Cowrie to simulate a fake vulnerable server, we need to assign it to port 22. Thus we need to change our real ssh port by editing the file /etc/ssh/sshd_config as shown below.

Edit the line, and change it for a port between 49152 and 65535.

Restart and check the service is running properly:

Install all needed software for next steps, on Debian based Linux distributions run:

Add an unprivileged user called cowrie by running the command below.

On Debian based Linux distributions install authbind by running the following command:

Run the command below.

Change ownership by running the command below.

Change permissions:

Login as cowrie

Go into cowrie’s home directory.

Download cowrie honeypot using git as shown below.

Move into cowrie directory.

Create a new configuration file based on the default one by copying it from the file /etc/cowrie.cfg.dist to cowrie.cfg by running the command shown below within cowrie’s directory/

Edit the created file:

Find the line below.

Edit the line, replacing port 2222 with 22 as shown below.

Save and exit nano.

Run the command below to create a python environment:

Enable a virtual environment.

Update pip by running the following command.

Install all requirements by running the following command.

Run cowrie with the following command:

Check the honeypot is listening by running.

Now login attempts to port 22 will be logged in the file var/log/cowrie/cowrie.log within cowrie’s directory.

As said previously, you can use the Honeypot to create a fake vulnerable shell. Cowries include a file in which you can define “allowed users” to access the shell. This is a list of usernames and passwords through which a hacker can access the fake shell.

The list format is shown in the image below:

You can rename the cowrie default list for testing purposes by running the command below from the cowries directory. By doing that, users will be able to log in as root using password root or 123456.

Stop and restart Cowrie by running the commands below:

Now test trying to access through ssh using a username and password included in the userdb.txt list.

As you can see, you will access a fake shell. And all activity done in this shell can be monitored from the cowrie log, as shown below.

As you can see, Cowrie was successfully implemented. You can learn more on Cowrie at https://github.com/cowrie/.

Conclusion:

Honeypots implementation isn’t a common security measure, but as you can see, it is a great way to harden network security. Implementing Honeypots is an important part of data collection aiming to improve security, turning hackers into collaborators by revealing their activity, techniques, credentials, and targets. It is also a formidable way to provide hackers fake information.

If you are interested in Honeypots, probably IDS (Intrusion Detection Systems) may be interesting for you; at LinuxHint, we have a couple of interesting tutorials about them:

• Configure Snort IDS and create rules
• Getting started with OSSEC (Intrusion Detection System)

I hope you found this article on Honeypots and Honeynets useful. Keep following Linux Hint for more Linux tips and tutorials.