Honeypots could be categorized according to their aims such as prevention, detection, and of course response. In addition to that, we can categorize them according to their level of interaction with the real systems. This level of interaction determines the intensity of the interaction between an attacker and the systems of an organization’s network. To elaborate more on this point, if a honeypot has a high level of interaction, then this implies that the attacker can interact much more critically with the system, opposed to low levels of interaction where the attacker will not interact with the real systems in a critical manner. If we need to collect much more amounts of data, then a high level of interaction is recommended. On the contrary, this aspect comes with its risks which make the high levels of interactions really dangerous parts of the network. This is, of course, an undesirable feature which we need to abolish. In general, we have three categories for the levels of interaction: low interaction, medium interaction, and high interaction.
The most common type of classification is based on the level of interaction which is provided to the malicious user by the honeypot. The more interactive an environment is presented, the closer the honeypot becomes to the actual targets of an attack. This translates to potentially gathering more accurate information. The downside is that the more realistic honeypots present greater challenges to configure and setup.
An organization should decide on which level of interaction works best for its purposes and goals out of the configured honeypots inside its network. I will explain the three levels of interactions in detail throughout the following three points; I will advise when each level of interaction is useful and when it should be avoided.
Low level of interaction:
An example is Honeyd. I talked about this in another article titled “low level of interaction honeypots.”
Medium level of interaction honeypots:
This is a more advanced type of honeypot where more information could be available if used. Despite the fact these type of honeypots still don’t contain an operating system which could simply get exploited, there is a bigger chance that attacks could get through the system using this sort of honeypots. The problem arises from the fact that there exist many more security holes through which an attacker could simply get into the system and exploit it. Obtaining much more information and more attacks from the hackers that are complicated is possible in this case. The following honeypot names could be used to exemplify the medium level of interaction honeypots that are infamously in use nowadays: Mwcollect, honeytrap, and Nepenthes. I will also talk about some of these honeypots in another article and implement them in practice.
To summarize what was mentioned regarding medium interaction honeypots, they are used to get some collections of software-emulated such that an attacker could become more convinced that it is, in fact, the actual system while he just accessed a honeypot system. In this case, the host operating system is still shielded. Nevertheless, getting a collection of software-emulated through the honeypot as we desire is not, in fact, a simple task at all. The reason for that lies in the fact that the response of such emulated collection of software should be almost identical to the response of the same actual programs. Still, we, of course, do not need to raise any real security issues here for these programs; otherwise, there is a real danger. Finally, the possibility of comprising the system exists here in fact with a higher percentage. This is basically because the vulnerable points that are kept for the attackers are considerable, and he can exploit a hole in the actual system to perform his malicious activity.
High level of interaction honeypots:
This type of honeypots is considered the most advanced type of honeypots in general. First of all, these types of honeypots contain an operating system. What does this imply? We can simply infer that an attacker can possibly undertake anything on such an advanced honeypot system. However, an organization, in this case, is capable of getting more and more data about the attack type, source, and nature indeed.
This type of honeypots allows the user to have no restrictions to perform whatever tasks and actions that are desired by him. From this point comes the real danger of using such honeypots inside an organization. They are also very time-consuming honeypots to configure and implement. Moreover, it is much more difficult to be able to maintain such type of honeypots for a long time. The most common name in this category of honeypots is Honeywell. This is a very important high level of interaction honeypot. I will also come back to it in another article and see how it could be configured in practice.
So, as I just mentioned, in this type of honeypots, actual instances of programs are used, not merely the emulations of them. An administrator has to choose this type of honeypots if he needs to grant an attacker root access to the machine and analyze how he will react then, and what actions he wished to do. The risk of implementing this type of honeypots is high. It is, in fact, the riskiest type of honeypot, yet it grants an administrator the greatest potential to get data collected about the attack and the attacker as well. Supervision of such honeypots is a must since such types of honeypots could become a zombie or a jumping point to perform more attacks on the systems inside the network.