Hacking Book | Free Online Hacking Learning


design of honeypot system based on docker

Posted by herskovits at 2020-03-26

0x00 Preface

The last article talked about the unauthorized access vulnerability of docker's remote API, so I wanted to make something with docker. Before, I also made a vulnerability environment replication system based on docker, but for various reasons, I abandoned the system after half of it. After some thinking, I decided to make a honeypot system by using the quick opening and destruction of docker container. I found some articles on the Internet and found that someone has implemented this system. But I still decided to make one myself, named kokkuri, from the divination in urara, which means that it's up to the gods whether visitors visit the system or not.

0x01 overall architecture

The idea is relatively simple:

Now it only implements a demo, and many functions are not perfect. If there is extra energy in the future, it will write a little bit of code. The code is open-source in GitHub: here

0x02 server side implementation

As mentioned before, the main work of the server side is to collect and analyze the logs sent by each agent. Rsyslog is preferred.

First, open the receiving port of rsyslog by modifying the file / etc / rsyslog.conf, and modify the following line:

/etc/rsyslog.conf # provides UDP syslog reception module(load="imudp") input(type="imudp" port="10514") # provides TCP syslog reception module(load="imtcp") input(type="imtcp" port="10514")

Here, I simply open the port to port 10514 of UDP and TCP.

Then, another thing to do is to receive the specified syslog and add a file / etc / rsyslog.d/kokkuri-server.conf. The content is as follows:

/etc/rsyslog.d/kokkuri-server.conf local6.* /path/to/rsyslog/received/log.log

Local6 is the facility name of syslog used by the agent side, and the specific configuration of agent will be discussed later.


Now what we need to do in the server-side demo code is to keep the tail log file (utils / watch_log. Py), then send the log to the parser (core / sshd_parser) to parse out useful information, and then send the information to the guard (core / sshd_guard) to generate rules. In demo, only SSH is implemented, and the rule is very simple. In the past two minutes, if an account fails to log in to the same host more than 5 times, it is decided to send the IP access SSH traffic to the honeypot.

The following figure is part of the parser code:

After determining a malicious IP, you need to open a honeypot for the IP. If all attacker's traffic is sent to the same honeypot, it will cause trouble to the later data analysis, and it is not easy to extract the characteristics of the attacker, so try to give each attacker an independent honeypot environment, get the attacker's attack techniques, attack techniques and other contents as much as possible, and then it can be used by threat intelligence. The following code simply opens a honeypot and records it in the database.

As far as my demo is concerned, the server only does this.

0x03 agent side implementation

In fact, this part of the demo is not finished, so I brazenly took it out and wrote it. In fact, the agent side also needs to configure some syslog related functions. Here is an example of sshd.

Modify syslogfacility [facility [name] in the / etc / SSH / sshd_config file, just specify local6 on the server side, and write local6 here, anyway, both sides are unified. It should be noted that this facility name only has several kinds of regulations, and it is not written casually.

/etc/ssh/sshd_config SyslogFacility [Facility_name]

Then create a new file, / etc / rsyslog.d/kokkuri-agent.conf, to send the syslog on the agent side to the server.

/etc/rsyslog.d/kokkuri-agent.conf :syslogtag,contains, "sshd" @@

There are many ways to write this. Here we use to check whether the tag contains sshd. If it does, it will be sent to the server.

The code of agent is violent. There are three parts: receiving strategy, modifying iptables and converting syslog. The part of converting syslog has not been considered. It is mainly to collect the logs of applications that cannot write syslog, and then convert them to syslog and send them to the server through rsyslog. It is said that MySQL does not seem to support syslog (XD) directly

Receiving the code of policy, I wrote a socket to listen to the local port 12666, which is violent and direct.

Then it is the part of executing the command to modify iptables, which is still under development XD

0x04 follow up

After all, it's just a demo. It's just a way of thinking. In fact, many pits are not considered. It's uncertain how feasible it is and how wide it can be used on machines. I can only study 233333 slowly when I'm free.