Honeypots could be categorized according to the level of interaction with the system into three main categories: low level of interaction, medium level of interaction, and high level of interaction. I will discuss the low level of interaction honeypots in this article.
When using these type of honeypots, it is not possible to receive a large amount of data from such a honeypot system compared to the other systems where more and more amounts of data could be collected from them. The advantages of this type of honeypots are given neatly in the following points:
- They have very limited interaction with the system. This implies that there is no high risk that could arise from an attacker from dealing with this honeypot type of system. To illustrate, there is no operating system in place for an attacker can interact with.
- The main usage of this type of honeypots is that any traffic coming into the network could be easily identified and captured by such honeypots. Also, new viruses and new worms are identifiable by such honeypots as well.
- Getting this type of honeypot configured and installed into the network is a simple task. Understanding this type of honeypots and dealing with them from the organization’s perspective is equally easy.
- The most used honeypot in this category of low-level interaction honeypots is what is referred to as Honeyd. This is considered as a really important honeypot when it comes to the low level of interaction honeypots. The latest and most stable version is 1.5c, which was released back in 2007. I will talk about Honeyd more in detail. This will include how to use them in practice and modern approaches to using them in another article to be published soon. So stay tuned! 😊
In a nutshell, through this type of honeypots, there are only one or more services that have to be simple and available for the attacker to interact with. All communication attempts with any particular services such as a web or SSH server are logged and investigated afterward. These types of honeypots are considered as simple daemons that help a network administrator get to monitor any attempts of attacks on the system in a passive manner. The host operating system, in this case, is for sure free of any vulnerabilities that could be possibly exploited by an attacker. Thus, this makes such kinds of honeypots safe and secure from the organization point of view. On the other hand, this type of honeypots cannot be used for the sake of simulating a complex environment where interaction is a must, such as a Simple Mail Transfer Protocol (SMTP) server.
Security risks of using the low level of interaction honeypots?
When dealing with low interactive honeypots like Honeyd, there are some security risks. These risks mainly lie in the fact that it is really simple to get to know that a Honeyd is a trap. A Honeyd is easy to detect even when we do not configure our honeypot with our settings. The reason for that is a honeyd drops all the connections until it becomes impossible for it to deal with them anymore. Even when SYN package is not that good, the connections get terminated.
This information could assist any attacker in finding out that the targeted system is not a real one but a honeypot trap system. When an attacker checks the connections of the system, he will be capable of discovering that he fell into a trap, not a real system. Things are very clear in this case. Dropped connections are easily detected by the monitoring tools which an attacker uses, and these dropped connections imply the fakeness of such honeypot systems.
Low interaction honeypots get services emulated by an operating system, yet they are not real services. This very basic information becomes of valuable use for an attacker who wants to draw his conclusions about the fakeness of a website. Complicated services cannot get handled using such low interaction honeypots as well. Hence, breaking the system with the use of this technique becomes powerful. What an attacker needs to do is to merely look for information throughout the network. This is because, in the case of low interaction honeypots, the network stack is the one which we deal with.
Another major problem of low level of interaction honeypots is the fact that they depend on the resources of the system that they are deployed on. Removing such resources, as a result, leads to a great notable feature which is latency. This could be checked through a ping test where the response will occur much later than how it was before getting the resources of the system removed. The system will hardly reply with an answer to our ping. This could indicate that the attacker is dealing with a Honeyd or Nepenthes. We can even use these approaches to detect the type of honeypot which we just deployed.
Leaving the deployed low interaction honeypot open for several days in a row is also a great way to come up with some important conclusions. The requests that are received by our honeypot should be greatly taken care of such that any responses by our system should be believable and make sense to the attacker. The attacker should be fooled by the responses to the extreme that they believe that it is an actual running system. Nevertheless, when it comes to low interaction honeypots, SSH server is up and running while there are no generated replies or answers when talking to port 22. This trivially indicates that the system is not a real one because its responses are not appropriate, making the system not secure in the first place.