This post is also available in: Spanish
Honeypots, find out what they are, monitor them and hunt the hunter
Nowadays, most computer attacks come from individuals who try taking control of different systems or damage them. They are able to perform these attacks by finding vulnerabilities in the devices, so, to avoid these events, the best defense that exists is installing honeypots in our network.
What are honeypots?
There is an old idiom that goes “more flies are caught with a drop of honey than with a bowl of vinegar” and this suits all this topic perfectly, since honeypots are precisely about attracting the most requests to analyze their intentions. We may wonder, “Who is going to attack me if I belong to a small business, a speck of dust on the Internet?” But the truth is that many years have passed since hackers were personally engaged in the cyberspace, surfing for victims. Today’s threats are the attacks performed by automated programs, taking control of thousands of online devices (webcams, refrigerators, televisions, routers, etc.) to get an army of clones ready and listening to the commands of their master. They can be used, for example, to massively attack a web domain – which is known as a denial-of-service or DoS attack – or to keep this troop occupied in its spare time by putting it to snoop into all that gets in their way.
Here we will discuss the latter: it doesn’t matter if your fixed IP address has spread or that your Internet provider has assigned you a dynamic IP address (which changes over time). You can be attacked mercilessly, just like this expert discovered when monitoring his own modem, given to him by his Internet provider. There he illustrates what would happen if an attacker took over our router by force: That is why the best defense is a good attack and hence the reason for having honeypots. We can define a honey pots as: “a systematic resource of information whose value rests on the illegal or unauthorized use of those resources” (according to “SecurityFocus ™”).
How do honeypots work?
At first sight, honey pots seem unprotected lambs in the middle of the field at the mercy of the marauding wolves that swarm through the net. They record every action and interaction with those users, and just because they don’t offer any legitimate service, all that activity is unauthorized and therefore, possibly malicious. Meaning, for example, opening a port commonly used for MySQL databases, could offer similar responses to this database management system, without having such software installed. Thus, it is possible to observe the behavior of the attacker and to be able to terminate at any moment the connection with any excuse like “server is shutting down” when the programmed target has been reached. Monitoring a honeypot involves first, understanding what the dangers are and how each of them works. This article aims to be a flash of light on the subject and we include links for anyone who wants to go deeper into their study.
Honeypots are NOT a solution
It is a warning that we must clarify, in case of doubts: honeypots are tools that we will use depending on our objectives, they are not oriented to give solutions. A pragmatic case may be to place a copy of our database server but full of invented data, in order to make a follow up.
Overwhelmed with information? Go grab a coffee – and a breath of fresh air – because here comes the best part.
In the previous paragraph we talked about a specific example of what low-interaction honeypots are: we want to investigate how it would affect an attack on our database server with fake data called “token honeypot” which can then be traced. Here are also included honeypots in production for very specific cases.
The other type of honeypot is the high-interaction: allowing the attacker to interact with the operating system to know their global skills and capture that information. It is widely used in research, but what the heck does this have to do with monitoring?
No data must be kept in our honeypots! If the attacker could have access to them, he could use them against us. Honeypots monitoring must be done in real time by removing the data immediately. There are several ways to do this.
If our honeypot is a virtual machine, we can create an external virtual hard disk with which we can backup from time to time with the configuration that we have decided to save there.
Another option: if our honeypot is a real machine, we could have another real machine (server collector) in the same local area network and create data requests from time to time, the important thing would be that the collecting server can not receive connection requests from the honeypot (assuming that the attacker has taken complete control of the honeypot). Needless to say, the data collected will be isolated from each other for later analysis and to discard at a certain point those that may have contaminated by the attacker.
Since the combinations are practically endless let’s see a practical case.
“Artillery” practical example
“Artillery” is a fork of the code created by TrustedSec, although BinaryDefense is in charge of it now, and it is based on a BSD open source license. It also includes the installation instructions for a Ubuntu server, which you can find in this link.
It is written in Python and these are the main characteristics:
- It opens multiple common ports used by a variety of applications and it includes the IP address of the attacker in a denial list located in “/var/artillery/banlist.txt” (We have our first file to monitor ready: download with a written script in bash with a frequency of 5 minutes and rename it adding time and date to the filename).
- By default, “Artillery” monitors the “/var/www” directories (where a web page would be stored if we had Apache web server installed) and “/etc” (crucial for every GNU/Linux server). There is a configuration file where we can add other folders that are interesting for us to monitor.
- Artillery monitors SSH and looks for forceful access attempts.
- It also gives you the option of sending an email when an attack occurs and lets you know what the attack consisted of (which is a form of integrated monitoring by default).
- For us to configure this, we must access a “/var/artillery/config” and establish our preferences.
- It is important that we add ourselves to a list of allowed IP addresses to prevent the honeypot from blocking all access, in case of, for example, misspelling the password by SSH. If it is necessary to “unblock” an IP address, there is the module “remove_ban.py”, specially designed for this purpose.
- It works in GNU/Linux and Windows, being necessary some installation peculiarities for the latter, but the curious thing is that our attackers will always think they’re dealing with a Linux computer!
Other ways of creating honeypots
For years, there have been venerable tools in the marke that can be used to penetrate this field, considering that the attackers may have foreseen their application (we’ll see later the advantages and disadvantages of honeypots). Some of those tools are:
- Honeyd, created by Niels Provos. Although it is a single honey pot in GNU / Linux or Windows the attacker will see multiple honeycomb servers. What’s the trick? Honeyd creates virtual IP addresses, each one with the ports and services that we want to emulate. To help understand the concept, imagine a router device connected by a modem to the Internet and with a hard disk connected to several virtual machines running, each one with different ports and services open. A basic tutorial on how to install and start using Honeyd can be read in this link.
- HoneyBOT,which is made for Microsoft Windows and has its own integrated graphical interface, which makes it a wise choice for anyone who’s starting in the world of honeypots. It is known by its level of detail, and it even saves every byte received from the attacker. It includes interesting charts that will allow you to see the most relevant attacks at a single glance. It is a private software (there is an academic version too) and it belongs to “Atomic Software Solutions”.
- Specter is more powerful, since it has profiles of various operating systems preconfigured, it injects encrypted data to the attacker that can be used later as proof It opens custom and cumulative profiles for each intruder. We won’t be monitoring this program ourselves, instead, it has predefined reports with data to safeguard the software house and we don’t know how to take care of them because it is closed source.
- Kippo is written in Python and it’s hosted in GitHub with free license. It is described as a medium interaction honeypot, an intermediate category compared to those we previously described, since it focuses on SSH. You can install it by clicking on this link.
Advantages and Disadvantages of Honeypots
- Works in isolated environments.
- Since it uses non-legitimate services it produces very few false positives.
- The data are concise and specific to non-legitimate activity.
- It can potentially be discovered by the attacker and used against us.
- It can be used by the attacker against other systems apart from ours (see previous point).
- It only detects direct attacks on the honeypot, it doesn’t detect the local area network environment (except Honeyd that creates its own private virtual network). However, we will address an approximate solution to this problem.
Honeypot farms and honeypot networks
Both cluster honeypots and are differentiated by centralized administration. The idea is to divert attention from a real potential target for the attacker and channel it to another honeypot specialized in the assigned task (later we will see the different applications that are desirable to monitor).
By means of a GNU / Linux computer that properly executes iptables, we will be able to establish rules where any request that is not related to our work environment, can be redirected to a honeypot. Any other system administrator would simply deny traffic and go, but you should always be open to how the world evolves.
A very personalized honeypot model
How about modernizing ourselves and make totally public the intrusions to our honeypots by means of Twitter and even keep our monitoring in Dropbox? Welcome to the 21st century. This is possible thanks to Professor Sam Bowne of City College of San Francisco, in the United States. His project is to create an Apache web server in Ubuntu and installing tcpdump to send that large amount of network traffic to Dropbox and save all shell commands to a syslog via a script created he created. A scheduled task is in charge of uploading the data in 50 pieces of 10 megabytes in a regular and constant manner.
It also uses tripwire to keep a detailed log of the modified files (warning, you must start with a “clean” system before exposing it in order to start with a good base) and a client called speedtest-cli, written in Python, that measures Internet speed.
In another server that monitors the files stored in Dropbox, it extracts the keywords and through a script written in PHP, it publishes them on Twitter, which is not a good idea because it gives clues to the attackers about what they do (there appears the IP address associated with the attack). Then he modified the PHP script to send direct messages on Twitter, away from the public view (we can configure it so that direct messages are also sent to our email, best monitoring, impossible!).