被动防御之蜜网实践（一）

转载请注明出处并附上源链接

版权所有，侵权必究

我们专注于威胁感知与检测方向：X-SPRing、半饱和 、byteway（不分先后）

提示：文章主要介绍甲方蜜网整体架构的设计与实现框架，提出基于复杂网络情况下的蜜网系统产生误报的解决方案，全文大约阅读15分钟

较为成熟的传统攻击检测和防御思路有IDS、IPS、WAF、主机层面的杀毒软件等主动检测能力建设，但是对于被动防御的安全监控能力实战建设却较为少见，接下来我们就从蜜网的如下几个构建历程逐步展开我们的分享：

构建蜜网防御能力的意义和价值

传统蜜罐技术栈的优缺点分析

新一代蜜网的基础架构

蜜网的扫描感知能力与误报优化

高交互蜜网的初步建立

1

构建蜜网被动防御能力的意义和价值

在甲方安全应急工作中，时常有一些因为人员安全意识不足或者配置失误造成的漏洞，比如SSRF、匿名外部代理，还有部分不定期产生的0day RCE等漏洞，黑客时常可以通过这些漏洞长驱直入，漫游内网，对于企业造成很大的损失。在这类攻击场景中，大部分传统的攻击检测与防御能力都被绕过或者无法发挥作用，从而无法阻止黑客的入侵，这个时候传统安全防御体系的短板就暴露出来。

我们开始反思如何在内网中发现这些漏网之鱼？一个比较好的思路就是“姜子牙钓鱼，愿者上钩”！我们知道黑客的一些习性就是会寻找一些有漏洞的内网服务，进一步横向攻击，因此我们可以撒一些面包屑一样的弱点服务，引诱攻击者到我们布置好的口袋里来，这样一来不但可以拖延攻击者时间、迷惑攻击者做出错误判断，还可以感知攻击者的整个攻击意图、随时收网，避免真实业务数据损失，这就是被动防御的雏形。

2

传统蜜罐技术栈的优缺点分析

早期的蜜罐有Kippo、Dionaea、专门针对web系统的Glastopf等，还有一些honeynet、honeyfarm的设计思路，这些程序设计各有优缺点，共同奠定了开源蜜罐的基础。比如Glastopf、Dionaea这类蜜罐开源项目，虽然近几年都有docker集成版本，但是还是存在无法批量集中管理和高效运维更新等问题，并且这类单机版蜜罐的指纹信息也较为明显，一般不具备深度交互能力；像一些honeynet、honeyfarm的设计中就提出来一些相对高效的方案解决部署问题，网络上也有些CERNET等实际部署蜜罐文章的分享，比如MHN这类相对较复杂的C/S架构蜜罐，相对单机版蜜罐来说进步了一个层次，有简单的集中报警收集平台，方便集中管理并且具备多服务模拟功能，但是同样存在一些缺点，MHN是融合的各种开源单机蜜罐，一方面在维护更新上同样存在无法高效自动化运维的问题；另一方面，既然是各类开源产品的拼凑，同样存在虚拟服务易被识别，仿真度低等问题。

3

新一代蜜网的基础架构

根据我们以上的分析，我们的目的是整合各个传统蜜罐的功能优点，即可以实现系统化的管理功能，又让部署的多个蜜罐联动形成一个虚拟网络，给黑客一个可以畅游的类似真实的深度交互虚拟环境，解决传统蜜罐的诸多缺点，形成一个动态陷阱，这样的一款对企业高度适配的蜜网防御系统该如何实现呢？先看下面这张示意图：

蜜网系统示意图

如图，整体的思路就是蜜网体系分为：蜜网agent、蜜网云端、虚拟环境三部分，各个agent的联动、攻击转移的实现等细节下面会分别展开。

构建蜜网安全系统的架构是第一个问题，只有走出传统蜜罐的误区，在各个蜜罐节点之间建立高效的联动机制才是更理想的满足蜜网功能的架构体系，对应的架构层面显而易见就是C／S架构（客户端服务器架构）：

蜜网基础架构

然而仅仅是C／S架构就能搞定吗？答案是远远不够的，之所以选择基础架构是分布式是因为蜜网系统需要一个中心化的控制、决策、联动平台，而通过一个实时的策略下发可以实现对蜜网节点的批量动态控制，从而为后面的动态蜜网奠定基础。

4

蜜网的扫描感知能力与误报优化

扫描感知尤其是半连接扫描感知作为蜜网的基本功能，比如TCP在没有建立完整的握手之前，上层应用是无从知晓的。也正是由于半连接扫描不会在应用层留下日志痕迹，因而备受黑客的喜爱，既然应用层甚至传输层都无法感知到半连接扫描，而我们又想获取这部分数据怎么办？受tcpdump抓包的启发，因为所有数据包都经过网卡，所以这些半连接数据可以通过网卡获取，具体框架可以是这样的：

蜜网agent扫描感知模型设计

最上面的网卡过滤器模块负责应用层策略，这里可以限制指定端口、网卡来抓包，可以大大降低agent的性能损耗，Memory logger模块是为了高效、快速的统计临时数据而用，Filter Ctl会把上层策略转换为libpcap可识别的具体规则并应用在抓包进程，最后产生日志采用加密信道上传到蜜网服务端，至此，一个基本的扫描感知功能已经搞定。

在实践过程中，单蜜网节点的决策往往存在较多误报，以黑客攻击的常规步骤端口扫描为例，如何通过高效的控制与联动机制，最大限度的避免因一些复杂的网络条件下各类误操作等造成的误报呐？我们先看一下常规的扫描特征，如图：

横向端口扫描

纵向端口扫描

如图，可以很简单的将扫描行为划分为横向、纵向、横向和纵向结合的三种方式。横向扫描到达端口的数据包特征为：在短期内一个源IP同时向多个蜜网agent的相同固定端口发起探测请求；而纵向扫描特征为：一个源IP同时向一个蜜网agent的多个敏感端口发起探测请求，这些总结的扫描特征足以帮助我们减少复杂网络环境下的大部分误报，利用同一时间段内多个蜜网agent上报的感知数据在蜜网服务器做综合分析，用扫描特征做报警策略即可把一般的网络连接区分为扫描行为和非扫描行为，同时可以根据扫描特征判断攻击者是在网络里横向移动还是定点攻击。

在实际渗透过程中，端口探测环节是搜集主机弱点的重要环节，根据攻击者使用扫描工具、手法的不同，有时还有些前置的主机探活、操作系统类型探测、端口服务类型探测等数据包，甚至还有更奇葩的绕过扫描检测的方式，但是不用失望，纵深感知体系不是只依赖这一种方式，万一在扫描阶段没有触发报警，或者干脆攻击者没有扫描动作，后面还有高交互、高仿真的虚拟环境等着黑客！这里意在提供一种降低误报的思路，如果更深层次的感知攻击者行为，可以分析几款常用渗透扫描工具的发包指纹，这样当蜜网节点收到扫描时，可以直接感知出攻击者所使用的扫描工具类型。

5

高交互蜜网的初步建立

有了扫描感知只是基础，我们的目标是一个蜜网agent应该在具备扫描感知的同时也具有深度交互服务感知能力，因此还需要把高交互的虚拟服务功能引入到蜜网agent上来，这里可以选择使用胖客户端的设计将所有的虚拟环境打包到agent端，也可以采用流量代理转发的方式将攻击流量转发至其他高交互虚拟环境；显然，打包所有虚拟环境到agent的方式会使agent十分臃肿、冗余，而且占用服务器资源量大，因此放弃此类设计；采用流量代理的方式依然有很多具体实现方式，可以简单的使用iptables做Forward链转发，也可以自己实现一款proxy；通过实践发现采用iptables的方式是实现简单，但是对于虚拟环境的自动化运维控制和动态切换可控性差，因此自己实现一项proxy的功能显得更可行。具体的模块设计如下：

蜜网agent流量转发模型设计

蜜网agent通过本地监听敏感端口，当本地端口收到流量后，会同步将流量转发到远端的高交互虚拟环境，在攻击者看来就像是在攻击agent所在的服务器，这样设计即可以动态调整虚拟环境指向，又可以复用虚拟环境资源，减少蜜网agent大小，使蜜网agent更为小巧。

在做流量转发的时候有很多点可以优化，使整个转发时延缩短，这里更多的是考验工程方面的能力，这里不做讨论，如果是整个部署都在同一个IDC内网环境，转发的时延基本可以忽略。

最后，这里只是初步总结了蜜网的整体体系和主要功能，接下来如何构建高可用、高交互的虚拟环境、如何实现蜜网agent的自保护与兼容、如何快速还原一个完整的攻击链路以及蜜网如何变被动为主动等等一系列问题由于篇幅考虑，我们会在接下来的文章里给大家逐步展开!

参考文献：

蜜罐技术研究与应用进展（http://t.cn/RdWWjHS）

MHN现代蜜网（http://t.cn/RdWWRiI）