基于 docker 的蜜罐系统设计

1 整体架构

kokkuri
思路是比较简单的：
每台主机中装有 agent，这个 agent 负责收集各个应用的日志，例如 MySQL、Redis、SSH 等，RSYSLOG 的方式获取优先。
agent 负责接收 server 端下发的策略，下发的策略通常是将来自某个 IP 的某些请求，转发到后端的蜜罐中，这个转发使用 iptables 来实现。例如将来源是 1.1.1.1，访问当前机器的 22 端口的流量，转发到蜜罐 2.2.2.2 的 2222 端口。
server 端负责收集各个 agent 上报来的日志，并进行分析，然后制定相应的策略并下发给 agent。
HoneyPot Server 暂时还没有实现，使用了一台主机来代替，考虑后期如果开启的蜜罐数量过多，可以搞一个蜜罐集群，由 HoneyPot Server 维护整个蜜罐集群。
现在只是实现了一个 demo，很多功能还没有完善，如果后面有额外精力的话会稍微写一点代码的，代码开源在 github：这里
2 Server 端实现

前面已经说过了，server 端的主要工作就是收集各个 agent 传来的日志并进行分析，rsyslog 方式优先。
首先通过修改/etc/rsyslog.conf文件，开启 rsyslog 的接收端口，修改以下行：
1
里只是简单的把端口开到了 UDP 和 TCP 的 10514 端口上。
然后还有一件要做的事情就是接收指定的 syslog，添加一个文件/etc/rsyslog.d/kokkuri-server.conf，内容如下：
1
其中local6是 agent 端使用的 syslog 的 facility name，agent 的具体配置后面再讨论。
现在的 server 端 demo 代码中要做的就是，不停的 tail log 文件 (utils/watch_log.py)，然后将日志送到解析器中(core/sshd_parser) 解析出有用的信息，然后将信息送到 guard(core/sshd_guard)中生成规则。demo 中只实现了 SSH 的部分，规则也是很简单的，即在过去两分钟内，如果某个账户对同一台主机登录失败 5 次以上，则决定将这个 IP 访问 SSH 的流量送到蜜罐中去。
下面这图是解析器的部分代码：
1
确定出一个恶意 IP 后，还需要为该 IP 开启一个蜜罐。如果将所有攻击者的流量都送到同一个蜜罐中，会对后期的数据分析造成困扰，也不易提取攻击者的特征，所以尽量给每个攻击者一个独立的蜜罐环境，最大可能的获取攻击者的攻击手法、攻击技术等内容，以后还能交给威胁情报使用。下面这段代码是简单的开启了一个蜜罐，并记录到数据库中。
1
就我的 demo 来讲，server 端只干了这么点事情。
3 Agent 端实现

这部分其实连 demo 都没写完，就厚脸皮的拿出来写了。
Agent 端其实也需要配置一些 syslog 相关的功能，这里还是用 SSHD 举例。
修改/etc/ssh/sshd_config文件中的SyslogFacility [Facility_name]，刚刚 server 端指定的 local6，这里也写 local6，反正两边统一就行了。有一点要注意的是，这个 facility name 只有规定的几种，并不是自己随便写的。
接着新建一个文件/etc/rsyslog.d/kokkuri-agent.conf，目的是把 agent 端的 syslog 发送到 server 去。
1
这个写法就比较多了，这里采用的是检查 tag 中是不是包含 sshd 的，如果包含就发送到 server 去。
agent 这边的代码写的就比较暴力了，主要有三个部分：接收策略、修改 iptables、转换 syslog。
其中转换 syslog 的部分还没有考虑，主要是为了把那些没法写 syslog 的应用的日志收集起来，再转换成 syslog 通过 rsyslog 发送给 server，据说 MySQL 好像就不能直接支持 syslog（XD
接收策略这部分代码，我直接写了个 socket 监听本地的 12666 端口，暴力直接。
1
这个写法就比较多了，这里采用的是检查 tag 中是不是包含 sshd 的，如果包含就发送到 server 去。
agent 这边的代码写的就比较暴力了，主要有三个部分：接收策略、修改 iptables、转换 syslog。
其中转换 syslog 的部分还没有考虑，主要是为了把那些没法写 syslog 的应用的日志收集起来，再转换成 syslog 通过 rsyslog 发送给 server，据说 MySQL 好像就不能直接支持 syslog（XD
接收策略这部分代码，我直接写了个 socket 监听本地的 12666 端口，暴力直接。
1
然后就是执行命令修改 iptables 的部分了，这部分依然在开发中 XD
4 后续

毕竟这只是个 demo，纯粹是提出了个思路，很多坑这里面其实都没有考虑到。具体可行性如何、能用在多大范围的机器上都是不确定的，只能等我有空的时候慢慢研究了 233333。