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.

Resources:

http://www.diva-portal.org/smash/get/diva2:327476/fulltext01

https://www2.cs.arizona.edu/~collberg/Teaching/466-566/2012/Resources/presentations/2012/topic12-final/report.pdf

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.

1. Low level of interaction:

An example is Honeyd. I talked about this in another article titled “low level of interaction honeypots.”

2. 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.

3. 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.

Resources:

http://www.diva-portal.org/smash/get/diva2:327476/fulltext01

https://www2.cs.arizona.edu/~collberg/Teaching/466-566/2012/Resources/presentations/2012/topic12-final/report.pdf

Honeypots are unique because they allow a security researcher to see and record what actions a malicious user takes on a compromised computer without necessarily interfering or revealing to the attacker that they are being monitored. Because of this invisibility, valuable intelligence can be gathered about the actual strategies of an attacker. A honeypot can be configured to be either proactive or reactive to attacks, depending on the needs of the person who set it up.

What are the real advantages of a honeypot?

There are several benefits that a company can basically get out of configuring a honeypot inside their system. While there are many solutions to security problems that are available in the software market, honeypots still have unique benefits and really useful purposes. The benefits could be summarized in the following points:

Ø  Any attacks could be easily captured using honeypots. Also, information about the attack type could be recognized such that weakness points become well known to the security administrators. This could be discovered using the logs which are created by a honeypot. In addition to that, if the laws do not interfere with it, additional information about the source of the attack and the attacker could be identified by using the honeypot technology.

Ø  Administrators become practically familiar with new threats and modern methods of attacks. They take notice of the new attacks and further gain knowledge of how to defend a system against these attacks. Many solutions become practically possible even before the attack infects a machine in the organization. By looking at the behavior of malicious activity in the system, and through examining them well, many more attacks become understandable by the time they get their effect on the network in the very first place.

Ø  When a honeypot captures traffic, it does not capture the entire traffic such that it becomes bulky and tedious to analyze and investigate through its captured traffic. On the other hand, it merely takes care of the incoming malicious traffic and notifies the network administrator of it. This is much easier for the investigation process when analyzing any malicious traffic is a must. This aspect, in fact, makes honeypots extremely useful in practice.

Ø  From the above-mentioned point where we discussed that only malicious traffic gets captured by a honeypot, there is no need for a huge amount of storage at all. In practice, any dedicated computer could become the honeypot system without an urgent need to buy many more resources and allocate budget to deploy the honeypot technology within an organization.

Ø  The configuration of honeypots is very easy and installing it does not have any complications. This is basically complemented with a simple algorithm that does not have any complexity. Moreover, for the installation purposes on a system, there is no need to get some other software programs updated, installed, or modified by the time a honeypot gets installed.

Ø  We should know by now that any malicious activity is recognizable by a honeypot. However, in addition to that, new tools for detecting attacks are also captured by honeypots. Deploying a honeypot in a system gives the administrator a solid idea of how there are various points of view that they could look at the same problem to find several security solutions for the same problem according to each perspective.

Are there any disadvantages of a honeypot?

Everything in life has advantages and disadvantages, and we have to find the balance between them both before deciding if it is worth for or not. In fact, there are some points that could be simply considered as pitfalls for using honeypots in general. The following points give us an intuition of how many problems we can use after using honeypots.

Ø  Information is only captured when an attack is performed. On the other hand, if there is no attack occurring on the system, then there will be no captured data at all.

Ø  The captured malicious traffic is only collected when the attack is targeted at the honeypot machine. Nonetheless, if the target of the attack was another machine rather than the honeypot machine, then we are in really big trouble. Such systems will get infected by the malicious code without having the honeypot notifying us about such activity in the first place.

Ø  Honeypots are sometimes distinguishable from other real systems that we have in our system. Of course, this is a big problem that could be tackled such that even experienced hackers cannot distinguish between honeypot systems and real systems using fingerprinting.

Ø  A very unwanted result is that a not careful organization could end up having lies really in the fact that an attacker may depend on a honeypot and exploit it as a zombie to attack other systems within the network and get them compromised, causing really big trouble for the entire organization.

What is the system configuration for using a honeypot?

First of all, let’s agree with the idea that a honeypot has the capability to either work on its own or work in a group with some other honeypots in the system. In the case that there are several honeypots, we basically refer to this group of honeypots as a honeyfarm. It may be suggested to configure a honeypot alone without having to configure other many honeypots because this will make things much easier in the configuration and installation process.

Nevertheless, it turned out that having only one honeypot is not that effective nor powerful when compared to having a honeyfarm although it may be hard to configure this honeyfarm of honeypots. Furthermore, having only one honeypot is prone to have some unintended failures, many more than the number of such failures when having a honeyfarm. The reason for that lies in the fact that there is no ability for one honeypot on its own to load balance and also, they lack the redundancy of a group of cooperating servers.

Resources:

http://www.diva-portal.org/smash/get/diva2:327476/fulltext01

https://www2.cs.arizona.edu/~collberg/Teaching/466-566/2012/Resources/presentations/2012/topic12-final/report.pdf

How can we define honeypots?

A honeypot is essentially a computer system. In this computer system, there exists files and directories just like any other usual computer system. A honeypot aims to attract an attacker to fall into its trap for it to investigate his actions and follow his behavior. In fact, a honeypot is not an actual system yet; it is a fake system. The difference between a honeypot and other security systems lies in the fact that a variety of security problems could be tackled at once using diverse approaches available on honeypots. On the contrary, other usual security systems are used to tackle one certain problem through a proposed solution. An instance of this point could be simply seen in the scenario when a compromised system could be investigated after having a log of malicious activity. At the same time, new threats could be recognized through implementing a honeypot in a network and hence attempt to tackle these problems and overcome them effectively.

Honeypots are indistinguishable from the actual production servers to an outside attacker. Thus, they will not behave any differently when attacking them. However, the network security team can monitor the honeypots for recorded attacks and later analyze them. The honeypots can also help to absorb attacks directed against the real server.

What is the motivation behind a honeypot?

The honeypot idea is mainly derived from a great interest in the field of computer security. The implementation of a honeypot requires that one is interested to know the workflow of security systems and to build a solid knowledge of how the protection of a company could be achieved and how security flaws in a system can be very risky for the entire system and organization. A network administrator shall be ready for great work ahead while implementing the honeypot system in a network. Being aware of the system and network architecture and the modifications that could be applied to them is a very crucial step beforehand. The output is examined through some reliable forensic science tools. In the meanwhile, several problems will be encountered, and the administrator has to make sure he can solve them before putting the honeypot in the system. Facing such problems beforehand will be very important for the administrator. This ensures that at a later that time, although the conditions may be intense, the system will be handled quickly, and losses will be easily recovered. Therefore, good knowledge of examining security problems and forensic science information is a must.

What should be done before applying a honeypot to the real production system?

A network administrator should carry out some research by the time he thinks of applying the honeypot concept in the network. He has to be sure that the created honeypot is secured such that it has no leaks into the actual system. Otherwise, it will make a real disaster. On the other hand, he has to make sure that a hacker has no knowledge about being trapped into a honeypot. He has also to be aware of the maximum amount of information available for an attacker to get through the honeypot implementation. Also, it is good to know the behavior of an attacker when he knows that he is in a trap. Will that attacker just give up hacking and stop his actions? It is also really important for a network administrator to be knowledgeable of the location where the honeypot should be deployed in the network and the amount of information he can get.

Laws always play a role in everything in life. Therefore, it is also advisable that a network administrator should be aware of the restrictions applied on implementing honeypots; especially if his organization is in the European Union (EU) or the United State of America (USA). There are certain rules and regulations which govern the process of obtaining information of an attacker or tracking him back. Therefore, a network administrator should abide by these rules by not fully tracking the attacker, and at the same, he should be respectful of the laws in every single way.

What is the description of our problem?

 When we build a good honeypot, we expect to attract several attackers into the fake system and let them take control over the intentional flaws left in there. When we trace the hacker, it is not guaranteed for sure whether we will be the ones who have the control. Thus, we don’t know that much about the security of a honeypot. We are not sure whether the attacker, in fact, knows that it is a fake system. We also doubt whether the attacker is aware of the great importance of acquiring information about the system flaws. We need to be very specific and certain about the actual limits that an attacker has whenever he gets the control over the honeypot system. It will be disappointing if the attacker can even exploit the honeypot itself and seize a flaw in it to get to the system and do what he wants in the system. The entire system will be compromised when an attacker gets to this devastating point. Another entitled problem is that an attacker may recognize that it is a trap and then stop hacking or pretend that he is hacking. In that time, it is no longer beneficial to have the installed honeypot anymore, and it is not useful either to use our forensics tool to investigate the system. A very important aspect to consider when using honeypots is to be sure about the answers for all these questions and attempt to get our honeypots to be more secure and be assured that hacking the honeypot by the attacker will not yield any useful data for him about the actual system. A good network administrator should play the role of a hacker once and of a forensic examiner on another occasion or simultaneously do the same of course with his own team. Very accurate results could be acquired depending on various tools used for hacking and forensics.

Resources:

http://www.diva-portal.org/smash/get/diva2:327476/fulltext01

https://www2.cs.arizona.edu/~collberg/Teaching/466-566/2012/Resources/presentations/2012/topic12-final/report.pdf

How can we define honeypots?

A honeypot is essentially a computer system. In this computer system, there exists some files and directories like any other usual computer system. A honeypot aims to attract an attacker to fall into its trap and investigate his actions and follow his behavior. In fact, a honeypot is not an actual system yet; it is a fake intentionally made system. The difference between a honeypot and other security systems lies in the fact that a variety of security problems could be tackled at once using diverse approaches by depending on honeypots.

On the contrary, other usual security systems are used to tackle one certain problem through a proposed solution. An instance of this point could be simply seen in the scenario when a compromised system is investigated after having a log of malicious activity. At the same time, new threats could be recognized through implementing a honeypot in a network and hence an attempt to tackle these problems and overcome them effectively.

To an outside attacker, the honeypots are indistinguishable from the actual production servers. Thus, the servers will not behave any differently when attacking them. However, the network security team can monitor the honeypots for recorded attacks and later analyze them. The honeypots can also help to absorb attacks directed against the real server.

What is the motivation behind a honeypot?

The honeypot idea is mainly derived from a great interest in the field of computer security as a whole. The implementation of a honeypot requires that one is interested to know the workflow of security systems and to build a solid knowledge of how the protection of a company could be achieved and how security flaws in a system may be very risky for the entire system and organization. A network administrator shall be ready for a great work ahead of him while implementing the honeypot system in a network. Being aware of the system and network architecture and the modifications that could be applied to them is a very crucial step beforehand.

The output shall be examined through some reliable forensic science tools. In the meanwhile, several problems will be encountered, and the administrator has to make sure he can solve them before putting the honeypot in the system. Facing such problems before actually facing them, in reality, will be very important for the administrator. Of course, at that time, although the conditions may be intense, the system will be handled quickly, and losses will be easily recovered. Therefore, good knowledge of both examination of security problems and forensic science information is a must.

What should be done before applying a honeypot to the real production system?

In fact, there has to be some research carried out by the network administrator by the time he even thinks of applying the honeypot concept in the network. He has to be sure that the created honeypot is secured such that it has no leaks into the actual system. Otherwise, it will make a real disaster. On the other hand, he has to make sure that a hacker has no knowledge about being trapped into a honeypot.

He has also to be aware of the maximum amount of information available for an attacker to get through the honeypot implementation. Also, it is good to know the behavior of an attacker when he knows that he is in a trap. Will that attacker just give up hacking and stop his actions? It is also really important for a network administrator to be knowledgeable of the location where the honeypot should be deployed in the network and the amount of information he can get.

Laws always play a role in everything in life. Therefore, it is also advisable that a network administrator should be aware of the restrictions applied on implementing honeypots especially if his organization is in the European Union (EU) or the United State of America (USA). There are certain rules and regulations which govern the process of obtaining information of an attacker or tracking him back. Therefore, a network administrator should abide by these rules by not fully tracking the attacker, and at the same, he should be respectful of the laws in every single way.

What is the description of our problem? 

When we build a good honeypot, we expect to attract several attackers into the fake system and let them take control over the intentional flaws left in there. When we trace the hacker, it is not guaranteed for sure that we will be the ones who have the control. Thus, we don’t know much about the security of a honeypot. We are not sure whether the attacker, in fact, knows that it is a fake system.

Additionally, we doubt whether the attacker is aware of the great importance of acquiring information about the system flaws. We need to be very specific and certain about the actual limits that an attacker has whenever he gets the control over the honeypot system. It will be disappointing if the attacker can even exploit the honeypot itself and seize a flaw in it to get to the system and do what they want in the system.

The entire system will be compromised when an attacker gets to this devastating point. Another entitled problem is that an attacker may recognize that it is a trap and then stop hacking or pretend that he is hacking. During such a time, it is no longer beneficial to have the installed honeypot anymore, and it is not useful either to use our forensics tool to investigate the system.

A very important aspect to consider when using honeypots is to be sure about the answers for all these questions and attempt to get our honeypots to be more secure and be assured that hacking the honeypot by the attacker will not yield any useful data for him about the actual system. A good network administrator should play the role of a hacker once and of a forensic examiner on another occasion or simultaneously of course with his own team. Very accurate results may be outputted then by depending on various tools for hacking and forensics purposes.

Resources:

http://www.diva-portal.org/smash/get/diva2:327476/fulltext01

https://www2.cs.arizona.edu/~collberg/Teaching/466-566/2012/Resources/presentations/2012/topic12-final/report.pdf