This series is a quick introduction to so-called honeypots, i.e., systems whose sole meaning in life is to be the victim of attacks by techno-anarchists. This series includes a complete recipe for creating your own, fully virtual honeypot that is completely based on Linux or Unix; all other components are publicly accessible on the network. But before we get to that, it’s time for a bit of architecture. The whole installation is shown in the diagram below.
In our case, the honeypot plays the main role in the so-called fully implicit, fully supervised main operating system. The honeypot in our network will first provide a system called GUEST. In fact, in the case of both systems, we get one thing, namely, the system kernel. The main operating system is not at all visible on the network. It will only run the script, which will set the appropriate firewall rules for the system. Its sole task is to monitor and filter traffic that enters and leaves our honeypot. In addition, we monitor the transmission of all packets to some external process. It will be known in the program as “snort.” Its task will be to identify all outgoing attacks and try to prevent them. In our honeypot system, the kernel will create UML (User Mode Linux). This kernel has one major advantage: It can work as a normal user process in the native system. What really is the UML mentioned? UML is a specific type of system kernel. It was created primarily for developers and advanced users of the Linux kernel. UML provides a fully safe way to develop new versions of the kernel system and experiment with them. By using this solution, we can easily create any virtual machine on any hardware, using any system parameters, which allows access to the parameters of any real existing machine selected by us. In our case, if we talk about UML kernel file system, it is contained in a single file system. Thus all the damage to the system that takes place in a fully virtualized environment will never pose any real threat to the system. A UML kernel also has additional educational benefits. Sometimes we do not know what are the effects of a command or program. It may also happen that we are not sure whether newly-installed software will jeopardize the integrity of the computer system. It it then that we should always use a UML kernel. Goals that always justify the means The reason given at the beginning of this article was the desire to learn the methods and behavior of hackers in the operating system; the virtual honeypot system also has other advantages. It can always be treated as an extension of the entire infrastructure of IDS (Intrusion Detection System). The assumptions is that,since the honeypot is to be a really easy target for most hackers, so it will be their first target. Because the honeypot is monitored by us, we very quickly get to know the exact answer to the question: who breaks in, and when, and how it is done. The detection of any activity inside the honeypot usually guarantees one thing: It ensures that in the event of a real threat, we will know immediately that our resources are targeted by hackers. Systems will never suffer from the problem known as false positives, which is persistently associated with all less radical varieties of IDS. Of course, sometimes the attack is an attack on the honeypot only, and very often it is considered that an attack on a honeypot is not a real attack. If we look closely at the situation, we must recognize that any attempt to design a system that will always give reliable results in optics IDS requires experience and a huge sense of the situation. In addition, very often a honeypot is, by less experienced administrators, perceived as a way to divert attention from really valuable goals. Usually, after the initial diagnosis of the system and the network, an intruder almost immediately throws himself blindly to the least secure system. He counts on the idea that taking control of the affected system gives him more opportunities to infiltrate the network. This approach always gives us the necessary time to respond to a potential attack using the information given to the relevant party who has responsibility for a given network infrastructure from which the attack was carried out. Now that we have defined the goals, we can vary the requirements, which need to fit the specific system being used in the real world. Why is that? The answer to this question is very simple. A totally different architecture will be required for a honeypot whose task will be only one service, for example, the Apache web server; a completely different architecture will be required for a honeypot that will be used to research the activities of individual burglars. In the first case we use a machine with Apache, which is susceptible to a number of standard techniques and several hacking exploits and we simply put the working environment completely under the control of the jail services. The second case is really much more complicated and requires a lot more of our attention. In this case, the honeypot should always be installed in a series, which enables compiling a complete history of the burglars. In addition, it should not include any modifications or, if there are any modifications, they must be virtually impossible to detect. If we want to analyze the activities of hackers much more carefully and discreetly, we can install a dozen-honeypot network, running on multiple hardware platforms and systems. In this way, we create something called a Honeynet. A Honeynet has several advantages, two of which are very important.. The first is that the Honeynet feels like a completely natural network environment. A second advantage is that it is essentially devoid of noise information, which manifests itself in the form of normal traffic network utility. The safest honey for your environment In fact, no matter how much attention we give to that honeypot, we must always take into account one thing. A public network almost always increases the risk of security breaches. Even if we assume that the system is absolutely safe, it may be that the risk of attack increases on the computers of other users on the environment. It can also happen that the enemy we face will surpass attempts to trap them with their knowledge and skills. Then they just laugh at us, and we can only he try to raise the bar. Do not place too much trust in software that you install, because it may also contain safety critical errors. How to make a honeypot that is the safest for your environment? First, always set alarm system support for any successful break-in, which is symptomized by outgoing traffic. There is no problem with that today. Let the system send you a text message if there is something that is suspicious and does not fit the rules. You should always try to limit attacks on other systems or try to avoid them altogether. You can do this by simple actions, such as blocking outgoing traffic that matches the patterns of attack and setting rules about anti-spoofing to reduce bandwidth. The next step is certainly to restrict the freedom of a burglar. This can be done by limiting outgoing calls. The next step should be to monitor all actions that are taken by the burglar. In fact, the monitoring should be completely independent of all the techniques used by the network transmission encryption. To do this, just turn on honeypot logging. Another thing that always helps us is to organize a rapid and simple method of deactiving the honeypot by a single operation. One thing you should always check. Well, everything that I mentioned above should be carried out by certain elements of the infrastructure system or network that are completely invisible to the intruder. A hacker must never, ever be aware of the fact that he is being monitored. However, if there is a modification of outgoing traffic that matches all patterns of attack, the attacker must recognize that for some unknown reason, which he can not rationally explain, his attack just failed. The most difficult of all things is to implement the secret recording all keystrokes entered during a remote session. It is highly undesirable to have the honeypot store any information. Now, if a hacker is experienced. obviously he willl sometimes notice the transfer, but thanks to his enormous ego, he will not associate it with the activity of a machine, but with its own activity. Now the question is, what to do? Continue, or just withdraw? Of course, as we all know, there are no problems that cannot be solved. It’s a very interesting idea, therefore, to send data that is cached. It would be ideall to have something in the module that sends data to the network periodically. With this solution, the transmission does not seem at all suspicious. But I want to show in this cycle a solution that is truly superior. Namely, I will show you a full alternative concept approach to the installation of a virtual honeypot.It will log every keystroke, will be completely invisible to the attacker, and will have a fully virtual system supervisor that really will make available only certain virtual resources of the system which is installed on the honeypot. Summary In this article, I have begun a series on honeypots. I hope that at the end of the series each of you will know how to create a system in the system and set it up as a honeypot. This series will definitely increase the powers of each reader in terms of network administration, and basic elements of a well-protected network environment. Also, it will show you that the way to take advantage of all types of virtual machines and the like is to spread all the main services that we provide. If you found the subject really interesting, please “like” and comment. Thanks in advance.
