固定链接 基于开源组件的蜜罐系统的搭建

基于开源组件的蜜罐系统的搭建

基于开源组件的蜜罐系统的搭建

1. 简介

在目前的攻防对抗中,蜜罐已经是一种很常见的技术,其定义如下:

蜜罐技术本质上是一种对攻击方进行欺骗的技术,通过布置一些作为诱饵的主机、网络服务或者信息,诱使攻击方对它们实施攻击,从而可以对攻击行为进行捕获和分析,了解攻击方所使用的工具与方法,推测攻击意图和动机,能够让防御方清晰地了解他们所面对的安全威胁,并通过技术和管理手段来增强实际系统的安全防护能力。

本文将介绍一种基于开源组件快速搭建蜜罐系统的思路,大家可以以此为基础,根据自己的需求定制自己的蜜罐系统。

行文仓促,若有哪些不对的地方,欢迎大家批评指正。

2. 架构介绍

蜜罐系统的运行流程图如下:

攻击者通过漏洞扫描发现蜜罐服务的漏洞,成功利用漏洞后进行下载木马等操作,在这个过程中会产生两种数据:

  • 行为日志:攻击者在蜜罐中执行的命令、发起的网络连接等
  • 服务日志:蜜罐服务本身的日志

我们收集这两种数据并将其存储到数据库中,后续根据这些数据建立分析模型进行数据分析。

根据这个流程,可以将蜜罐系统分为四部分:

  • 漏洞服务
    • 基于 Docker 搭建的真实漏洞环境
  • 行为监控
    • 基于 Sysdig Falco 的容器行为监控引擎
  • 数据采集
    • 使用 ELK 进行数据采集和存储
  • 数据分析
    • 样本分析、外连 IP 提取、扫描 IP 提取等

本文主要介绍前三部分,通过前三部分可以快速搭建一个简单的蜜罐系统,通过该系统提供的数据,用户可以根据自己的需求定制相关数据分析策略。

3. 漏洞服务

目前网络上的蜜罐系统中的漏洞服务有真实环境协议仿真两种形式,这两种方式各自的优缺点如下:

  • 真实环境
    • 优点
    • 功能完整,对已知漏洞和未知漏洞均可捕获
    • 服务本身自带日志功能
    • 搭建快速,尤其是基于 Docker 来搭建
    • 缺点
    • 资源占用较大
    • 需做好隔离,以防影响同网络内其他服务
    • Docker 逃逸的风险
    • 攻击者的恶意行为可能导致服务无法正常运行
  • 协议仿真
    • 优点
    • 轻量级,资源占用小
    • 可在协议实现的任何地方卡点处理数据
    • 无需考虑隔离的问题
    • 缺点
    • 开发和维护成本较高,需针对不同漏洞服务的协议进行不同程度的仿真
    • 由于只仿真存在漏洞的功能,所以对未知漏洞的捕获可能存在遗漏

我们的目的是快速的搭建可用的蜜罐系统,所以这里选择了使用 Docker 部署真实漏洞环境的方法,至于部署真实环境的缺点,我们可以通过以下方法来克服:

  • 资源占用大:限制每个容器可使用的资源
  • 隔离:通过安全组、VPC 等方式与正常服务隔离
  • Docker 逃逸:暂无完美解决办法,做好隔离,及时更新 Docker,把可能造成的危害将到最低
  • 攻击者的恶意行为可能导致服务无法正常运行:容器外部监控服务可用性或定期重启服务

选择 Docker 主要原因当然是环境搭建简单方便,不过还有一个原因是 Docker 本身的生态比较成熟,我们这里使用 Docker Swarm 来管理蜜罐集群并且通过 Docker Registry 分发服务镜像。所以一个漏洞服务的生成步骤如下:

  1. 编写 Dockerfile 或 docker-compose.yml,构建镜像:

  1. 将镜像推送到自建 Registry中:

  1. 使用 Docker Swarm 在集群中启动蜜罐服务:

使用集群管理的好处就是只需要在 manager 节点上进行操作,在 manager 节点上执行启动服务的命令之后,所有的节点都会启动相应服务,如果节点上没有服务镜像,则自动从 Registry 中获取镜像后再启动服务。

至此一个存在漏洞的服务就已经开始在集群中运行了。

4. 行为监控

由于我们的漏洞服务是使用 Docker 运行的,所以需要一个针对 Docker 的行为监控引擎,所幸已有开源项目完成了这个工作:https://github.com/falcosecurity/falco 。

Falco 是由 Sysdig 团队开发的一个行为监控引擎,同时支持对宿主机和容器的监控。其基于 Sysdig 开发,后者使用内核模块监控系统调用并将系统调用抽象为事件,Falco 根据这些事件制定检测规则。

Falco 的检测规则可读性很高,比如如果想监控所有容器内 root 用户的命令执行情况,具体规则可以这么写:

其中 condition 为核心的过滤语句,evt.type = execve 表示事件类型为执行可执行程序,container 是一个宏,表示监控主体是容器。

output 为命中规则后输出的信息,其中前面带 % 的为变量,在输出时会替换为实际内容,比如 %container.info 在输出时会替换成容器的详细信息。

该规则实际测试的结果如下:

可以看到我们在 Redis 容器内执行的 uname -a 已经被 Falco 成功监控到并输出了详细信息。

Falco 得益于 Sysdig 对系统调用的封装,通过规则可监控的场景非常多,例如监控容器内启动的 shell 进程、ls 等程序发出的网络请求等等。对于蜜罐系统来说,对命令执行的监控是最基本的,各位也可以根据自己的需求定制规则,具体关于如何编写规则可以参考 https://github.com/falcosecurity/falco/wiki/Falco-Rules ,这里就不再赘述了。

5. 数据采集

到目前为止,我们已经有了两个数据源:

  • 漏洞服务本身的日志(docker logs redis
  • Falco 的监控日志(Falco 可配置输出 JSON 格式的日志)

现在的问题来到了如果收集这些数据,同样的,我们还是使用开源的方案来解决,这回用到的是 ELK,这个想必大家都不陌生,由以下三部分组成:

  • Elasticsearch:搜索引擎
  • Logstash:日志采集
  • Kibana:数据可视化

ELK 本身已足够强大,我们需要做的就是为每个漏洞服务和 Falco 编写好 Logstash 的配置即可。

具体 ELK 的使用可以参考 https://www.elastic.co/ ,这里就不再赘述了。

6. 总结

本文并没有介绍很多代码细节,而是主要介绍了一种基于开源组件快速搭建蜜罐系统的思路,可以看到在需求不复杂的情况下,系统的骨架都可以使用开源的组件来搭建,也算是一种“站在巨人的肩膀上”。

不过对于蜜罐系统来说这只是基础,一个完整的系统除了骨架之外还需要有血肉,蜜罐的“血肉”或者“灵魂”在于数据分析,在拥有各种复杂数据的情况下,如何提炼出有效的信息以及如何利用提炼后的信息产生价值是很考验分析人员能力的地方,各位见仁见智,找到符合自己的方法就好。

7. 参考链接

https://docs.docker.com/engine/swarm/

https://github.com/falcosecurity/falco

https://elastic.co

https://github.com/paralax/awesome-honeypots

本文作者:张博

您的留言将激励我们越做越好