蜜罐建设的一些思考

蜜罐可以理解为安全攻防中的陷阱，通过在信息系统中的各个环境或者网络中部署一些特定协议服务或者组件来诱导恶意行为对其进行探测或利用，从而达到发现恶意攻击、横向移动、内网失陷事件的目的。常见的蜜罐类型一般会包括以下几种：

针对系统服务的：smb; rdp; ssh……

应用级的：Spring; tomcat; mysql; redis; mongo……

受特定漏洞影响的组件版本：st2; thinkphp; fastjson; jboss; Jenkins……

一个没打补丁的smb协议，一个未授权的redis服务或者是一个可以rce的thinkphp应用仿佛就像是在对黑客招手说：你过来呀～而当黑客乐呵呵的跑了进去得到的却是一句：对不起，其实我是警察。在留下悔恨的泪水后这名黑客也明白了一个道理：安全攻防，不讲武德。

蜜罐的思想在于更多的发现可能存在的安全风险或者一些难以发现的攻击行为。传统的安全防护产品可能更多的希望在事前阶段达到阻断攻击的目标。而蜜罐则更着眼于在黑客绕过了一系列安全防护进入内部区域后如何第一时间发现并响应攻击。相比于边界防护例如防火墙，waf等，它通常在攻击事件发生过程中发挥作用。相比于ids/ips等，又具备更加轻量，部署灵活，快速反馈的优点。可以说，蜜罐的存在就是为了被发现和被攻击，是安全防护理念上另一种思维方式的体现。

i.  蜜罐的搭建需要符合逻辑性。逻辑性包括所处环境符合逻辑，服务组件符合逻辑等。所处环境符合逻辑理解起来很简单。你所部署的应用应该处于正确的信息系统应该所在的位置中。比如说一个harbor不会被办公网环境直接访问到;内部的后台系统正常情况下也不会直接暴露在公网而没有任何访问控制。如果真的有那不是测试环境就是蜜罐啦;

ii.组件的逻辑性在于系统，服务，功能的组合部署应该符合逻辑和常识。比如说一台蜜罐同时部署了ssh蜜罐和rdp蜜罐这就很奇怪了。同样的道理：在不同系统，不同业务场景下的各个蜜罐部署的组合应具备基础逻辑性。

iii. 这也就是所说的蜜罐的逻辑性，在部署蜜罐时你需要先思考你想要部署的蜜罐类型应该所属的网络环境同时也需要思考清楚对应的配套系统，端口，其他蜜罐服务是否符合常规应用类型：这是一台生产网络的数据组件的服务器，还是一台内网的lb服务器亦或是一台办公网的dc服务器。

i. 真实性指的是蜜罐的真实性，也即其所模拟服务是否具备真正服务的特性或让人难以区分。而蜜罐的真实性又依据蜜罐的特性不同。我们简单的把蜜罐的交互类型分为低交互蜜罐和高交互蜜罐两种。

ii.低交互蜜罐你可以只响应简单的链接请求甚至仅仅开放端口，这种蜜罐主要针对于入侵性质特别明显的蜜罐，例如455，3389这类端口。员工的正常行为不太可能会触碰到其他机器的这些端口。因此如果有任意来源踩点到这些蜜罐我们就可以把它归为可以的行为进而排查而不需要你的蜜罐服务去正常的返回每一个接收到的数据包。当然为了取证和溯源，你可以在服务端记录这些端口蜜罐所接受到的完整数据以便进行分析这是一次误踩，真实的扫描行为还是漏洞利用。

iii. 高交互蜜罐相对来说较难度上要更高，因为你需要解释用户所发来的各种千奇百怪的数据包并模拟返回正常的响应。在我们的构建中提供了三种思路。

1. 直接在后端提供真实的服务组件。这种方案简单且粗暴但是安全性有待考究。攻击者在踩到蜜罐的同时可能也可以具备服务的控制权，那么他的行为将变得更加不可控：提权，内网漫游等行为可能带来极大的危害。因此如果使用这种方案需要对蜜罐服务做更强的权限限制和网络隔离策略；

2. 通过一个proxy来代理后端真实的蜜罐服务。你可以通过docker轻松的构建各种服务作为蜜罐并通过proxy与攻击者交流。proxy在代理过程中转发数据包。通过这种方法，真实的服务对于攻击者来说是完全透明的，他并不知道服务的背后是什么。

3.通过代码来模拟各种各样的数据包。在这种模式下你的所有蜜罐服务其实都是一个又一个的socket server。在后端接受攻击者数据，做语法解析并模拟正常返回。这种方式的难度较大但是安全性较高。因为它实际上并不是真实的服务，所以完全不存在真的rce或者提权的风险。技术实现上以reids来举例。我们使用redis-cli交互远程服务端并使用wireshark来抓包。可以发现针对正常的赋值类请求如set，hmset，lpush等语法。在语句合法的情况下会返回+OKrn。而对于get类请求将返回特定的数据格式。形如:*3 $4 test $5 test2 $6 test22。这种类型。其中*3 代表返回3个数据，$4,$5,$6分别代表着数据长度，分别对应着：len(test),len(test2),len(test22)因此，只需要覆盖足够多的语法类型，就可以伪造一个类似真实redis服务的蜜罐了。例如keys ，服务端demo代码大致如下：

4.同样可以使用这种方式的还有类似mysql，ftp的服务。而相比较redis，他们复杂得多。例如mysql,通过官方文档可以梳理出mysql的客户端与服务端在交互阶段需要完成这些步骤：

a.     server greeting [server à client]  握手

b.     login request (user + password) [client à server] 认证

c.     return login result (ok or fail) [server à client] 返回认证结果

d.     request mysql version  [client à server] 查询mysql版本

e.     return version [server à client] 返回版本信息

f.      request curd and return 查询操作

5. 使用这种方式基本可以模拟出大部分类型的蜜罐系统。但是如何模拟尽可能多的数据包，如何智能识别是否是扫描器行为或错误的探测语法是开发中的一个难点，需要持续的运营和研究。

 i.  前文提到，蜜罐的目的在于及时发现和响应攻击行为。因此溯源和取证的能力一定也是蜜罐所需要具备的。溯源包括坑包括攻击者的设备信息，IP地址，地理位置，社交账号等。而取证则在于记录攻击者的行为链路和操作历史。

ii. 对于攻击IP的反制主要包括反向的扫描和机器识别来判断这是一台已被黑客攻陷的肉鸡还是一台萌新黑客自己的pc电脑。同时对其地理信息做溯源和定位。设备信息其实有很多，通过各种web类型蜜罐可以抓到相关浏览器或curl版本。同时构造精确的js探针甚至可以分析出黑客所使用计算机的部分硬件信息（不过我目前浅薄的认为这部分数据在攻防对抗方面没有特别多的价值，不过研究研究还是蛮有意思的）。

iii. 通过一些服务特性和特殊手段做溯源也是现在很多蜜罐在用的技术。这里也说几个蜜罐中可以使用的奇技淫巧：一个是通过mysql任意文件读取的特性来获取攻击者机器的本地文件。一个是通过文件水印来溯源泄露数据的流转过程和可能存在的交易链。

iv.任意文件读取是mysql的一项功能。当LOAD DATA INFILE标示存在时，允许服务端读取客户端上的本地文件。我们也可以在蜜罐中实现这个功能。读取文件的数据包格式为：[]byte{byte(len(file_path) + 1), 0x00, 0x00, 0x01, 0xfb} + file_path。当客户端接收到该数据包时将会读取该文件内容并返回给服务端。这种功能对于攻击者的威慑力还是很大的。如果黑客的攻击机器为一台linux，那么读取etc/shadow,bash_history或者known_hosts没准能发现一些有意思的信息。而如果是Windows机器那么你没准可以获得更加多的信息，比如微信账号或者浏览器记录等等：）

v.文件溯源的思路是参考不可见水印和17年CIA所披露出的一款名叫scribbles的项目。核心思想在于在服务器上发放置蜜罐文件（2020财务.xlsx，xxx项目合同.docx等）。同时在文件中增加一些不可见的水印。水印中包含请求我们服务器上资源的请求。将文档和请求资源的url做唯一映射。这样我们就可以通过简单的监控服务器access.log来及时发现那些文件遭到了泄漏，泄漏者的IP以及后续的流转过程。这种方案主要针对office系列的文件。以word举例，将其转化为xml或html格式之后我们可以很容易的嵌入图片资源并将资源的url修改为我们服务器上特定资源的url。完成之后再将其转化为word文件。Demo代码如下：随机生成资源字符串并记录映射到文件中，最终通过log中的访问记录溯源源IP和泄漏的文件以及服务器：