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

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

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

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

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

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

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

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

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

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

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

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

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

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

用软路由部署个蜜罐。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 话题二：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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