各位 Buffer 晚上好，FreeBuf 甲方群话题讨论第 209期来了！FB甲方社群不定期围绕安全热点事件、前沿技术、运营体系建设等话题展开讨论，Kiki 群助手每周整理精华、干货讨论内容，为您提供一手价值信息。

上期精彩内容请点击：Docker镜像漏洞怎么破；云桌面开发与安全如何平衡

话题抢先看

1. 和外网相比，蜜罐更适合部署在内网？外网有什么别的应用场景吗？

2. 一般伪装得好的蜜罐该如何设置？高交互蜜罐如何保证能够更加逼真且保证蜜罐本身安全？

3. 蜜罐如何保证在出现攻破或者绕过时进行检测告警？

4.安全告警处置时效要求相关的制度和规范（不是安全事件，而是安全告警，比如SOC系统触发的告警事件，明确规定了处置时效）

话题一：内网的正常用户不会去扫描或者攻击，一旦内网的蜜罐捕获到可疑连接尝试，那就可以认为出现了攻击行为，将蜜罐技术应用到内网的攻击感知，就不用担心过多的误报，让问题更聚焦。这是否意味着和外网相比，蜜罐更适合部署在内网？外网有什么别的应用场景吗？

A1：

这个内网和外网面太大了，可以聚焦一下。其实蜜罐的作用在于诱捕不在于攻击感知，大部分场景是为了诱捕和分析，所以蜜罐部署在内网还是外网是看具体需求的，并不是说适合部署在内网。那另外蜜罐的分析也需要部数量，跟业务分布。一般都是根据业务分布按比部署的。这个类似于抽样。外网的部署场景很多，比如我们以前为了捕获云的攻击事件，就在全球区域都进行和蜜罐部署，然后结合SOC做攻击和攻击预警。

A2：

我们之前也搞过，伪装工作量挺大的，还有个问题就是，怎么样能装得像一点，才能诱捕到鱼呢？

A3：

蜜罐也分很多种的，工作量挺大，很麻烦。一般的低交互蜜罐感知和分析有限，高交互蜜罐成本又太大了 。

A4：

低交互现在就是Fofa之类的平台都能帮你排除了，要是想起效果，还是要真实环境，当然可以低高蜜罐都布置上。

A5：

最简单的高交互实体蜜罐可以用真实系统+Sisdig等来开发一下，现在市场的蜜罐都很难满足需求。如果有强大的SOC+SOAR结合起来效果回更好。我当时还专门开发了一个，用了开源蜜罐和这个结合起来，又调用了微步的接口做分析，感觉效果还不错。对安服有帮助。

A6：

一般来说，低交互蜜罐适合布在互联网出口，用于信息和情报收集，高交互蜜罐适合布在内网抓取真实攻击。

A7：

不过最大的难点还是存储跟流量成本，还有数据分析。为了解决这些问题我买了一堆的书，每天几T的数据无论是存储和分析都是很恶心的。

A8：

我们整了一个蜜罐，直接把以前废弃的业务跑起来，再做了点假数据，每天一堆告警，笑死。

A9：

我当时遇到最大的问题就是存储，数据跨境传输、数据标准化、数据清洗、指纹识别、聚类、模型输出等。反正踩了不少坑，大家有兴趣可以找时间交流。

Q：一般伪装得好的蜜罐该如何设置？高交互蜜罐如何保证能够更加逼真且保证蜜罐本身安全？

A10：

我感觉有点悖论，既要安全，又要高交互，还要高仿真，如果是我，我会把蜜罐独立出来，在每个预设的交互节点上做好埋点，通过网络将埋点的日志信息定时上报，同时，为了确保蜜罐被黑后，黑客顺腾摸瓜，接收信息的服务器也同样独立于内网，上报数据的接口只能是文本格式的报文。

A11：

这就要看部署蜜罐的目的是啥了。被动型蜜罐就单纯的检测是否存在横向扩展，不存在高交互。主动诱捕型的总觉得不安全，对抗的本质。当然风险的付出跟收益也成正比，诱捕型的在HVV的时候可以溯源得分。

A12：

能够根据攻击者的行为自主的去创建场景，比如创建ECS，虚拟运维终端，而且能保证这些环境的真实性，比如规模足够大，网段划分合理，系统内存在下个系统的密钥或登陆方式，层层递进，将蜜罐及其所能管控的资源进行物理隔离，能保证攻击者可以从边界出口访问即可。

A13：

用软路由部署个蜜罐。

A14：

路由黑洞可能达不到蜜罐的级别。

A15：

我的线上环境就是蜜罐，谁打捉谁，就是代价有点大。

A16：

保证安全那就是要么网段隔离，要么厂商加油了，要求投入都不小。

A17：

现在没法溯源得分了吧，已经并没有专属加分内容了，20年开始我们反控的大佬们都是用全新电脑了，啥都查不出来。

A18：

我们比较怂，就被动防一下横向渗透了事，发现横向拔网线。

A19：

我们也是，内网多做隔离+蜜罐+微蜜罐做检测，发现就在网络上禁止横向，互联网上放很多蜜罐，纯粹为了浪费攻击者的时间，而且做的都很假，为的就是他们知道这边有准备，不好打。

A20：

十年前的“屎山”网络架构，微隔离的代价太大。只做了安全域的隔离，蜜罐也只是在安全域内检测。你们在互联网上放蜜罐会有自身的信息么？

A21：

总的来说，三十多个服务器吧，看到之后只感觉令人兴奋，Logo+假信息，而且我们总重置，黑客大哥们一般看就不感兴趣了，毕竟还有更软的柿子。

A22：

我这遇到了新“屎山”，为了一个三五百人在线的业务，后边部署了一套低代码平台，低代码平台依赖一套业务中台，业务中台是基于K8S的。

A23：

有Logo信息，存在一些看似明显的漏洞，脚本大佬们不会上报到某单位发文给一把手，让你们整改么？

A24：

会。收到上级单位发来的某某问题，我单位高度重视，立即协调，最后截图+结果。有固定模板了，一年几十次。

A25：

那蜜罐是不是也经常响？这基本只能当做攻击预警了吧。

A26：

该关就关，内网外网不同，外网不看都行，内网的也没几个响。外网的全部撤掉，现在没人管了，溯源也有风险，还是做运维轻松。硬件都有维保，业务都有高可用，数据都有CDP，只需要看看告警，偶尔排个小故障。

A27：

运维能不能接手下堡垒机，我痛苦的不行。

A28：

让厂家定制一下，可以做的很真实，蜜罐保障不了多安全，做个隔离网出来专门搞蜜罐，被拿了也没事，反正随时可以重置。

Q：蜜罐如何保证在出现攻破或者绕过时进行检测告警？

A29：

蜜罐正常情况下，部署在内网应该都是独立的，理论上只要碰到就触发告警了，肯定会发现异常的。

A30：

能检测出被绕过就是已经知道的剧本，如果有未知的剧本，那就没办法触发告警，这块我认为还是要从网络和日志侧入手，比如未知的网络包，主机心跳异常，日志文件异常，互联网监测服务不可用。

A31：

我们打算联动EDR RASP，异常流量直接指到蜜罐上，从行为层面做防护。

A32：

这种情况还挺多的，内网服务复杂，有些服务会探活误触非交互蜜罐。最好增加研判，根据统计、带外数据进一步确定准确的告警，不然误报会很多。

话题二：谁了解安全告警处置时效要求相关的制度和规范？不是安全事件，而是安全告警，比如SOC系统触发的告警事件，明确规定了处置时效

A1：

只有四个字：越快越好，比如你说你看到告警1小时内处理。

A2：

有安全运营团队的话，就分级处理，和运维告警机制一样。

A3：

有些告警，也并不是一时半会就可以调查完的，这就尴尬了，闭环不了。

A4：

SLA，五分钟内开始应急，不写结束时间，结束时间不可控，依赖运维和别人的。

A5：

是的，就是跟运维告警机制一样，但是我在想，设置到什么程度是适时的。

A6：

安全是个大环，闭起来得其他得环带进来，时间自然是不确定得了。

A7：

看看你们运维的事件应急时效？基本对齐也可以的吧？

A8：

我的想法是，把安全事件和安全告警区分，我目前想写的是对于安全预警的处置，如果是真实事件了，就是直接走运维的事件应急时效。

A9：

告警不需要写进去吧？告警的接收人是安全团队，是否升级为安全事件可以自己判断？

A10：

这么说吧，到风险遏制就算结束了。

A11：

我们这边也是参考运维的告警级别，分了Info Warning，Error和Critical的告警，Critical的告出来就约等于比较风险的。确认是真实攻击就摇人开始一起处理了。

A12：

我们是会有升级情况的，事件信息先到值班人，再到整个团队。告警应该要抽查，定期处理，这种就是聚合规则了。

A13：

这个我知道，应该是按照生产事件走的，大差不差吧。都是差不多的。这些都是已经定性是真实的事件了，不管是安全攻击还是运维事故。

A14：

也不是，我们这边还是以告警规则进行的初步判断，还要考虑告警规则的准确程度。

A15：

比如你表上的较大事件中有一个GetShell，首先，他肯定是一个安全告警，但是告警是有误报情况的，你只有明确了这个GetShell是真实的，才有根据你这个要求进行，那么，从这个GetShell告警到确定是真实的，这个过程，如何要求和把控呢？

A16：

主要目的就是为了规范我们设备告警的级别，参考这个梳理各种规则。

A17：

前期应该规范了应急制度，确定事件的大概级别和方案确定时间（比如一小时）好像就可以了吧？

A18：

我们每天有值班人，对应级别的告警会推送到值班人IM里面，如果5分钟内没有响应，会打电话到整个团队，告警的基本信息会在IM里展示出来，如果要详细分析的话就要开电脑看了，值班人研判如果是误报的话会标记成工单，回头进行规则优化，如果是真实情况，联动处置就是另一个故事了。

A19：

你们的告警也是有级别的吧，对于不同级别的告警，要求应该是不一样的。

A20：

设备告警会根据规则聚合成事件信息，基本的告警看的就不多了。

FreeBuf 观点总结

本期话题主要聊到了蜜罐，蜜罐似乎在内网的应用场景更多，但实际上，大家在讨论中有群友认为，蜜罐的作用在于诱捕不在于攻击感知，大部分场景是为了诱捕和分析，所以蜜罐部署在内网还是外网是看具体需求。但也需要注意，高、低交互蜜罐在部署及成本上的差异，以及进行伪装带来的工作量。

所以进一步，蜜罐该如何伪装并保证安全，尤其是高交互蜜罐。群友认为要看部署蜜罐的目的，被动型蜜罐就单纯的检测是否存在横向扩展，不存在高交互。主动诱捕型安全风险大，但这就是对抗的本质。如果单独强调安全性，则需要注意网段的隔离。

至于蜜罐被攻击或者被绕过时的检测告警，群友认为可以从网络和日志侧入手，比如未知的网络包，主机心跳异常，日志文件异常，互联网监测服务不可用等，也可增加研判，根据统计、带外数据进一步确定准确的告警。

在安全告警处置的制度及规范讨论中，本着越快越好的原则，可以参照运维告警机制，在安全运营团队内进行分级处理。

本期话题讨论到此结束啦~此外，FreeBuf甲方社群每周开展不同的话题讨论，快来扫码加入我们吧！

【申请流程：扫码申请-后台审核（2-5个工作日）-邮件通知-加入社群】

注：目前1群、2群已满，如有疑问，也可添加Kiki群助手微信：freebuf2022，备注：甲方会员

“FreeBuf甲方群”帮会已建立，该帮会以三大甲方社群为基础，连接1100+甲方，持续不断输出、汇总各行业知识干货，打造网安行业甲方专属资料留存地。现“FreeBuf甲方群”帮会限时开放加入端口，让我们一同加入，共同建设帮会内容体系，丰富学习交流地。