企业安全建设—模块化蜜罐平台的设计思路与想法

Posted 2021-04-27 阿里云应急响应

先知安全技术社区独家发文，如需转载，请先联系社区授权；未经授权请勿转载。

Author elknot@360corpsec

Cheat Your Enemies Mean Making More Times For You to Response —— 题记

0x00 前言

年后兑现的承诺来了，由于还有两篇关于威胁情报的稿子，所以更新的节奏会稍微慢一点。
首先这套蜜罐平台呢是16年还在信息安全部的时候丢下来的一个任务，由于现在已经暂时不混甲方安全了，所以这些东西留着也就没啥用了，所以这次放一个Ver2版本的设计出，Ver3版本的暂时还不放，因为猫教老虎上山不教老虎爬树，你懂得。

0x01 为什么需要蜜罐

首先呢，绝大多数甲方没有蜜罐这个需求，因为蜜罐这个东西实际上是为了抓一些新样本或者是一些业务针对型选手而设计的。这玩意儿成本太高，除了服务器、网络等资源成本，软件成本也是一个比较大的问题，因为现在很多蜜罐都已经被人家识别出指纹来了，所以直接套用现有的蜜罐程序一般会被反侦察意识较强的攻击者发现并识破，这样蜜罐也就没有了价值。
那么蜜罐到底是什么呢，其实蜜罐的衍生概念包括蜜网、蜜墙等这些都是为了让攻击者上当，然后套取攻击者的资产信息和工具信息，方便于我们对这些攻击者进行了解和掌握，甚至是对攻击者进行反击，这么看来蜜罐的用处也不小。非要说简单的话，蜜罐就是一种引诱攻击的伪装成正常业务系统的服务基础设施，包含伪装的业务软件、信息记录器和基础环境。
那么蜜罐究竟作用是用来干什么，仅仅是吸引攻击来钓鱼执法么，说清楚这个问题必须要说一下企业安全内部建设的问题。
企业安全内部面临的安全问题也就是所谓的内部安全攻击面一般情况就两种，天灾和人祸，天灾比如说遇到了因为自然环境因素导致的业务中断、使用的软件被人家挖出来了相关的漏洞并且已经有相关的在野利用等，而人祸的原因更多一些，比如说口令过于简单、补丁不及时打、域账号安全管理因素、配置失误等。这么说来的话所谓的找漏洞其实就是看你的IT架构里面是不是包含这些天灾人祸，然后可以小小的利用一下干坏事咯，没错，攻击者也就是这么想的，良心上过得去的会刷你点SRC积分或者rmb，稍微有点坏心眼的会给你来个薅羊毛，心眼坏到一定程度的会考虑使用高级威胁手段对你的操作系统产生持续性的安全影响。
说到这里，你可能觉得以上说的东西和蜜罐都没什么关系，实际上上面的一段话恰好说明了一个蜜罐设计的原则——让攻击者看上去一眼看不出来这是假的，就让他认为这里真的有天灾或者人祸，让后让他慢慢的把武器使出来，等他认为自己攻击得手了之后，我们再来分析他，做出相对性的预防措施和预警，然后把蜜罐还原到初始状态继续钓鱼执法。

0x02 现有蜜罐的问题

现有的蜜罐大问题其实倒是没有，就是因为用的久了，难免会被人手机指纹，指纹匹配上，然后攻击者就放弃攻击了，这样你就没有办法钓鱼执法了，这样的话就容易出现警察蹲了半天小偷却不来的情况。
同时还有一个问题，由于我们的蜜罐更多的是想要捕获一些未知的攻击甚至是漏洞在野利用，这种蜜罐的应用对于安全研究的意义其实更大，所以这个问题我们也应该考虑在内。
由于现在数据驱动安全的问题提的比较多，尽可能收集蜜罐产生的数据也是一个比较重要的环节，并且要保证数据是可用的，可分析的。

0x03 关于蜜罐设计的想法

根据上面产生的问题，我们就有了我们设计蜜罐的一些思路：

• 尽最大的可能模拟完整业务系统的输入输出（包括操作系统、中间件、业务代码）

• 尽最大的可能去收集攻击者产生的数据（资产信息、武器信息）

• 尽最大的可能去捕获较多的新的在野攻击（受影响组件热切换）

• 尽最大的可能去保证蜜罐不对外发起真实的攻击（容易被相关部门查水表）

前面三条我就不说了，最后一条其实是一个很严重的问题，也是绝大部分企业不敢部署大规模蜜罐系统的原因，因为监管部门的存在，有时候会对不定期的对业务系统进行安全性检查，万一一不小心查到了蜜罐，这个对于管安全的领导来说，脸上绝对是挂不住的，所以这些企业要想对蜜罐感兴趣的话，必须得玩blackops或者雇佣兵思路——即打死也不承认这跟我们有关系，但是外面的人大家都知道这是你干的。

0x04 详细的架构设计

话不多说，直接上图，上了之后我们再来挨个解释

首先我们先把这张图分为四个部分：Sensor资产部分，命令下发及管控部分，数据收集及分析部分和检测攻击部分。
Sensor资产部分：这里包含资源（网络、服务器）、操作系统环境、Agent部分、QEMU虚拟化部分，操作系统环境部分我们将SSH端口修改为65522（因为NMAP在扫描端口时候如果不添加-p T:1-65535或者是-p U:1-65535参数时，不会对60000端口以后的端口进行探测和扫描，最起码低端黑产不会干这种事儿）并同时部署SSH蜜罐（这里是为了伪造业务系统中的弱口令环境，可以选择Kippo或者是自己使用libopenssl编写），并且使用Rootkit隐藏Agent的进程，同时要保证SSH蜜罐的环境和真实SSH环境相似程度越高越好。QEMU虚拟化部分主要是用来部署业务系统的，同时讲蜜罐业务系统和真实系统做端口映射，保证攻击者在扫描时不会发现该服务是运行在QEMU上的虚拟环境（这里不要用VirtualBox，原因以后有机会再扯）。
命令下发及管控部分：这部分包含命令下发服务器、蜜罐模板服务器、控制台，这一部分命令下发部分和之前Agent那篇文章中的作用类似，主要是为了给服务器下发对应的配置文件，然后让Sensor部分主动地去蜜罐模板服务器去获取对应的虚拟机配置模板，such as：

[cve-2017-10271-weblogic]
name = "Weblogic 远程执行漏洞（CVE-2017-10271）"
file_path = "/home/ubuntu/Desktop/qemu_model_path/weblogic/cve-2017-10271.qcow2"
vul_name = "CVE-2017-10271"
original_port = 8000
mirror_port = 9001

这样的话我们把这个配置文件通过命令下发服务器，通过Sensor端Agent执行对应的部署就可以实现一个蜜罐系统的“伪”热切换。，当然这一部分必须通过日志记录在案，你懂得。
数据收集及分析部分：这里的话取决于你的蜜罐系统的规模，蜜罐系统其实一般使用EL+Django后台就可以实现性能较强的后台管理，如果实在有需求的话，可以考虑ELK+第三方后台（因为有些团队分析和运维是两拨人，你懂得）
攻击检测部分：这里主要是从流量入手，因为有些黑产不地道，一般都是拿来当肉鸡或者是挖矿，我们可以通过流量阈值和矿池情报等一系列流量规则来检测蜜罐中真实发生的攻击，这部分可以考虑引入snort规则、yara规则等，当然二进制匹配其实我也做了，只是这里不写出来了。当然，如果你的蜜罐做的足够的话，这一部分实际上没什么卵用，主要是怕你的资产由于某些原因发起了真的攻击导致别人找过来心平气和的想把你砍一顿的场景，以防万一。

0x05 蜜罐日志分析

如果你把蜜罐系统上线之后，这时候我们一段时间之后就会收集到一些相关的攻击信息了，肯定会有人爆你的ssh菊花，然后放点什么其他的东西进去打别人，你懂的我这里就不说了。
其实我想说的是，蜜罐系统可以收集到何种类型的信息，一般来讲针对不同的蜜罐来说，收集的东西都是类似的，我们以下面的场景作为模拟演练，当然下面的场景是真实发生的：

ssh爆破-》检测安全措施-》关闭安全措施-》下载攻击程序-》执行攻击程序-》退出-》对外发起DDoS攻击。

这个时候攻击者走了，我们就可以看一下攻击者到底留下了什么，我们按照资产类情报和武器类情报将产生的攻击数据进行归类：
资产类情报：SSH爆破字典、SSH连接客户端、病毒分发服务器IP/域名、远程控制域名/IP
武器类情报：使用的病毒样本、攻击时执行的命令、攻击时对系统产生的影响。
这样的话我们大概就能够获取到更多的攻击者情报，当然更多的数据有很多需要大家去挖掘，这时候我就不说了，众所周知的原因哈。

0x06 总结

蜜罐这东西其实就是一种网络安全的钓鱼执法，就是在那里模拟一个环境让攻击者来打一下，然后我们反击一把梭。蜜罐是一种非常有效而且好的研究攻击者的基础设施，但是蜜罐设计的过程一定要尽最大的努力模拟真实的环境和场景，防止被攻击者发现然后穿帮。最后友情提醒大家，一定要在合理合法的情况下部署蜜罐和处置攻击者，防止被人家抓住小辫子。

更多话题 相关 探讨，点击下方“ 阅读原文 ”查看。