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

admin 2023年3月10日21:24:02评论22 views字数 4864阅读16分12秒阅读模式

如何安全部署蜜罐;安全告警处置的制度及规范| 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:
我们是会有升级情况的,事件信息先到值班人,再到整个团队。告警应该要抽查,定期处理,这种就是聚合规则了。
如何安全部署蜜罐;安全告警处置的制度及规范| FB甲方群话题讨论
A13:
这个我知道,应该是按照生产事件走的,大差不差吧。都是差不多的。这些都是已经定性是真实的事件了,不管是安全攻击还是运维事故。
A14:
也不是,我们这边还是以告警规则进行的初步判断,还要考虑告警规则的准确程度。
A15:
比如你表上的较大事件中有一个GetShell,首先,他肯定是一个安全告警,但是告警是有误报情况的,你只有明确了这个GetShell是真实的,才有根据你这个要求进行,那么,从这个GetShell告警到确定是真实的,这个过程,如何要求和把控呢?
A16:
主要目的就是为了规范我们设备告警的级别,参考这个梳理各种规则。
A17:
前期应该规范了应急制度,确定事件的大概级别和方案确定时间(比如一小时)好像就可以了吧?
A18:
我们每天有值班人,对应级别的告警会推送到值班人IM里面,如果5分钟内没有响应,会打电话到整个团队,告警的基本信息会在IM里展示出来,如果要详细分析的话就要开电脑看了,值班人研判如果是误报的话会标记成工单,回头进行规则优化,如果是真实情况,联动处置就是另一个故事了。
A19:
你们的告警也是有级别的吧,对于不同级别的告警,要求应该是不一样的。
A20:
设备告警会根据规则聚合成事件信息,基本的告警看的就不多了。

FreeBuf 观点总结

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

所以进一步,蜜罐该如何伪装并保证安全,尤其是高交互蜜罐。群友认为要看部署蜜罐的目的,被动型蜜罐就单纯的检测是否存在横向扩展,不存在高交互。主动诱捕型安全风险大,但这就是对抗的本质。如果单独强调安全性,则需要注意网段的隔离。
至于蜜罐被攻击或者被绕过时的检测告警,群友认为可以从网络和日志侧入手,比如未知的网络包,主机心跳异常,日志文件异常,互联网监测服务不可用等,也可增加研判,根据统计、带外数据进一步确定准确的告警。
在安全告警处置的制度及规范讨论中,本着越快越好的原则,可以参照运维告警机制,在安全运营团队内进行分级处理。
本期话题讨论到此结束啦~此外,FreeBuf甲方社群每周开展不同的话题讨论,快来扫码加入我们吧!
如何安全部署蜜罐;安全告警处置的制度及规范| FB甲方群话题讨论
【申请流程:扫码申请-后台审核(2-5个工作日)-邮件通知-加入社群】
注:目前1群、2群已满,如有疑问,也可添加Kiki群助手微信:freebuf2022,备注:甲方会员
“FreeBuf甲方群”帮会已建立,该帮会以三大甲方社群为基础,连接1100+甲方,持续不断输出、汇总各行业知识干货,打造网安行业甲方专属资料留存地。现“FreeBuf甲方群”帮会限时开放加入端口,让我们一同加入,共同建设帮会内容体系,丰富学习交流地。
如何安全部署蜜罐;安全告警处置的制度及规范| FB甲方群话题讨论

FreeBuf甲方群成员(因篇幅限制仅展现部分行业成员):

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

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

互联网:云畅游戏 信息安全总监、飞点网络 技术总监、聚水潭科技 信息安全总监、诺亚控股 业务安全中心总监、哥伦比亚中国 信息安全总监非夕科技信息安全总监、赫基国际 信息安全部负责人、熵通科技 信息安全负责人、建发集团 信息安全经理
其他:大学长教育 数据安全与合规总监、温州城市大学 信息技术服务中心科长、作业帮 安全负责人、同程艺龙 安全总监、新奥集团 安全总监、中译语通 安全总监、集贤科技 安全总监、德邦快递 安全总监、盒子科技 安全总监、猎豹移动 安全总监、蚂蚁集团 实验室负责人、结行科技 数据安全负责人、苏宁 网络安全经理、新浪 网络安全经理、吉利汽车 信息安全经理

精彩推荐

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

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

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

原文始发于微信公众号(FreeBuf):如何安全部署蜜罐;安全告警处置的制度及规范| FB甲方群话题讨论

  • 左青龙
  • 微信扫一扫
  • weinxin
  • 右白虎
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2023年3月10日21:24:02
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                   如何安全部署蜜罐;安全告警处置的制度及规范| FB甲方群话题讨论http://cn-sec.com/archives/1597596.html

发表评论

匿名网友 填写信息