如何安全部署蜜罐；安全告警处置的制度及规范| FB甲方群话题讨论

▎各位 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甲方群”帮会限时开放加入端口，让我们一同加入，共同建设帮会内容体系，丰富学习交流地。

FreeBuf甲方群成员（因篇幅限制仅展现部分行业成员）：

金融行业：贝宝金融 安全负责人、成都农商银行 信息安全负责人、晋商银行 安全负责人、北京银行 安全负责人、君龙人寿 技术负责人、合合信息 合规负责人、合生 信息安全负责人、航天产业投资基金IT负责人、工银金融 信息安全负责人、前海联合基金 信息安全负责人、天弘基金 安全负责人、阳光保险 信息安全部负责人、南京证券 安全负责人、宝马金融 信息安全经理  

运营商：中国联通 网络安全主管、中国电信 信息安全技术主管、上海电信 网络安全主管、天津电信SOC主管、太平洋电信 研发总监

互联网：云畅游戏 信息安全总监、飞点网络 技术总监、聚水潭科技 信息安全总监、诺亚控股 业务安全中心总监、哥伦比亚中国 信息安全总监非夕科技信息安全总监、赫基国际 信息安全部负责人、熵通科技 信息安全负责人、建发集团 信息安全经理 

其他：大学长教育 数据安全与合规总监、温州城市大学 信息技术服务中心科长、作业帮 安全负责人、同程艺龙 安全总监、新奥集团 安全总监、中译语通 安全总监、集贤科技 安全总监、德邦快递 安全总监、盒子科技 安全总监、猎豹移动 安全总监、蚂蚁集团 实验室负责人、结行科技 数据安全负责人、苏宁 网络安全经理、新浪 网络安全经理、吉利汽车 信息安全经理 

精彩推荐