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:
- Each host is equipped with an agent, which is responsible for collecting logs of various applications, such as mysql, redis, SSH, etc. rsyslog is preferred.
- The agent is responsible for receiving the policy issued by the server side, which is usually to forward some requests from an IP to the honeypot at the back end, which is implemented by iptables. For example, if the source is 1.1.1.1, the traffic accessing port 22 of the current machine will be forwarded to port 2222 of honeypot 2.2.2.2.
- The server is responsible for collecting the logs reported by each agent, analyzing them, and then making the corresponding policies and sending them to the agent.
- The honeypot server has not been implemented yet, and a host is used instead. If there are too many honeypots opened in the later stage, a honeypot cluster can be built, and the honeypot server maintains the whole honeypot cluster.
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.
local6
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" @@192.168.198.130:10514
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.