如何安全部署蜜罐;安全告警处置的制度及规范| FB甲方群话题讨论
2023-3-10 13:46:36 Author: www.freebuf.com(查看原文) 阅读量:35 收藏

各位 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甲方社群每周开展不同的话题讨论,快来扫码加入我们吧!

1637910517_61a087f564a8754ee18be.png!small

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

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

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


文章来源: https://www.freebuf.com/articles/neopoints/360038.html
如有侵权请联系:admin#unsafe.sh