SOC异闻录:我和SOC不得不说的故事

作者:安全客 2018-01-20

就像是程序员,运维一样深夜”作案(jiaban)”总会遇到一些奇里古怪的事情,好歹我是经历过“大世面”的人,吓住,不可能的,让我们来数数那些在建设SOC遇到的奇怪事。

目录结构

0x00.关于SOC

0x01.SOC的产生

0x02.SOC开始建设

0x03.SOC稳定运行

0x04.那些奇怪事

0x05.SOC建设全过程

0x06.附录(CheckList)

致谢

0x00.关于SOC

首先,我在这里提到的SOC指的是Security Operation Center,也就是安全运营中心,和网络上说到的SOC安全管理平台不一样,前者是针对一个组织和团队,是一个Team,后者更偏向于一个工具,这是最本质的区别,而安全运营中心里面有一个非常重要的部分就是日志安全,需要对海量日志进行监控,分析,处理,展现等等,而实现这部分操作的架构或者产品,常常被称之为安全管理平台(SOC,我一般把这个叫做/Sao:K/),安全运营中心我一般直接称之为SOC/S:O:C/;本文提到的SOC就是安全运营中心。

所以说安全运营中心究竟是什么?每个公司对于职能都有不同的看法,我这里就简单说说我遇到的SOC:

我的安全运营中心(SOC)是一个团队,一个信息安全团队,建立在一个基本准则之上,负责监督和分析企业的安全状况,处置企业的异常情况,让企业的安全走上正轨,随着技术,业务增长完成安全的更新迭代。SOC团队的目标就是通过技术解决方案和强健的一套流程 检测、分析并且响应网络安全事件。安全运营中心通常充当了安全分析师以及管理者的角色,监督全部安全操作。SOC工作人员同组织结构的事件响应团队紧密合作,确保发现的安全问题迅速得到解决。实际上我们也是事件响应团队的一部分。

安全运营中心监控和分析网络、服务器、终端、数据库、应用、网站和其他的系统,寻找可能代表一个安全事件或者攻击的异常活动。负责确保潜在的安全事件能够被正确识别、分析、防护、调查取证和报告。

 

0x01.SOC的产生

SOC团队负责的是正在进行的企业信息安全运营组件,是否参与制定安全策略、设计安全架构或者实施保护措施。安全运营中心人员主要包含安全分析人员,安全领导,安全专家等,SOC共同探测、分析和反馈报告,防止网络安全事件发生。如果能够高级取证分析、密码分析以及恶意软件逆向工程,那就最好了。

而SOC的产生大概有这么几个特点:

1.公司以前没有SOC,是运维,加开发,监控几个部门协同一起做一些日常的维护和处理,后来遇到无法处理的安全事件时,开始请求SOC帮助,由于没有SOC,那么就开始组建呗;

2.公司是子公司,或者公司本身就把安全职能部门算入到了创建初期的团队之中,这里就是一开始就建设SOC团队,其实也是在建设企业安全,包括SIEM事件管理体系和ISMS信息安全管理体系。

我的Team应该是属于第2种,我是在一个炎热的夏天去面试,唠嗑,最后有幸加入到了SOC团队,接下来就开展了一系列大刀阔斧的建设。

 

0x02.SOC开始建设

建立一个组织的SOC的第一步就是清楚地定义包含具体业务的战略目标,且获得全体相关人员的支持。一旦战略开发,基础设施支持这一战略的实现。典型的SOC的基础设施包括防火墙、IPS/ IDS、漏洞检测解决方案、嗅探、安全信息和事件管理(SIEM)系统。技术应该通过数据流、遥测、数据包捕获、syslog和其他方法来收集数据,这样SOC工作人员可以关联和分析数据和活动。安全运营中心也监控网络和端点漏洞以保护敏感数据和符合行业或政府法规。

SOC的关键优势在于通过持续不断的检测分析数据活动,改善了安全事件的检测。通过夜以继日的分析跨组织网络、终端、服务器和数据库的活动,SOC团队确保及时检测和相应安全事件。SOC提供的24/7监控为组织提供了对抗安全事件和入侵的先机,而且无关资源、时间或者攻击类型。

许多安全领导人将更加关注人为因素,而非技术因素,不再依赖一个脚本,而是直接评估和减轻威胁。SOC连续工作管理已知威胁,同时识别新的风险,在风险承受能力范围内满足公司和客户的需求,而防火墙、IPS等技术系统可以防止基本攻击,重大事件上则需要进行人为分析。

为达到最佳效果,SOC必须跟上最新威胁情报,并利用这些信息来改善内部检测和防御机制。SOC消耗的数据来自组织内部和相关信息的外部资源,从而提供洞察威胁和漏洞。这个外部网络情报包括新闻提要、签名更新、事件报告、威胁简报和脆弱性警报,这些都有助于SOC跟上不断发展的网络威胁现状。SOC员工必须为SOC监视工具不断注入威胁情报,保持最新的威胁情报信息,而SOC则必须区分真正的威胁和非威胁。

真正成功的SOC利用安全自动化变得更加有效和高效。通过结合高度娴熟的安全分析师与安全自动化,提高组织分析能力,加强安全措施,更好的防止数据泄露和网络攻击。

1.第一阶段:梳理已有的安全防御,整理相关的安全设备管理权限,整理相关的资产;

这里主要是梳理资产,资产应该包括3大部分:组织架构和人员,基础设施资产,应用系统资产

很好理解,组织架构,人员一般前期主要针对经常关联的那些人员,账户信息,变更审核等等,然后人事变更和人事那边做好联系;基础设施资产主要是硬件服务器,网络设备,安全设备等等;应用系统资产就是业务系统,环境划分与安全域,业务流向。这里没有大多的技术含量,处理的越仔细越详细,越有条理越好。

2.第二阶段:进行全网安全状态分析;

这里主要是针对之前的安全措施进行补充,将不足的安全项进行提交,然后开始在监控,运维,系统管理的协助下,对全网的环境开始进行基线扫描,漏洞扫描,数据分级保护,ISMS体系建设等等。

3.第三阶段:持续监控和应急处置

在全网基线合规,漏洞基本修复和处理的情况下,开始对全网的状态进行严苛监控,一般来说,会涉及账户信息管理:特权账户的使用和通告,非工作时间的登陆审查,;变更管理:审计变更合规与否;IPS,IDS,WAF等安全设备状态监控和日志分析,服务器日志分析,这里就是着重使用SIEM安全信息事件管理平台的地方了,这里一般会用上我之前说的SOC/Sao:k/工具,一般有钱就直接买大型互联网安全厂商的产品和服务,没钱就自建日志分析平台,一般采用的是OSSIM或者ELK日志架构。

Elasticsearch是个开源分布式搜索引擎,它的特点有:分布式,零配置,自动发现,索引自动分片,索引副本机制,restful风格接口,多数据源,自动搜索负载等。

Logstash是一个完全开源的工具,他可以对你的日志进行收集、过滤,并将其存储供以后使用(如,搜索)。

Kibana 也是一个开源和免费的工具,它Kibana可以为 Logstash 和 ElasticSearch 提供的日志分析友好的 Web 界面,可以帮助您汇总、分析和搜索重要数据日志。

基本上到这一步,都是对特定的安全需求做精细化处置,开始做安全自动化,不断的调优,然后根据实际情况,反个黑产,反个链接,做点舆情监控,来个威胁模型分析,业务量足够大可以建设一下APT防御,千万别忘记建设安全知识库,不过有些工作还是要从建设初期就开始,就比如自动化和知识库,需要一定的积累才行。

 

0x03.SOC稳定运行

在SOC建设完之后,基本上整个SOC稳定运行,日志想怎么看就怎么看,这样不够精细咋们就调,账户管理,权限变更,变更审计有条不紊,就该对整套SOC团队建设完成的SIEM安全事件管理系统进行定期的巡检和维护,因为所有的安全监控都是基于这一套安全检测和监控系统,如果系统自身出现了问题,如何区保障监测的可靠性,一般的操作有:

1.巡检,定期的巡检检查SIEM系统的运行情况,比如物理状态,服务情况等等。

2.季度重启,保障SIEM服务器能够满足故障恢复的基本要求。

3.日志存储:定期检查日志保存情况。

此外需要注意的是,如果前期收集日志是一通收,也就是说日志没有做分类,需要后期区进行分类,也就是需要了解你能收到什么类型的日志,然后再SIEM展现的平台做好相关的关联和汇总,越清晰越好,一般来说,按照产品来区分,产品之下再分应用,安全,信息类日志等。

 

0x04.那些奇怪事

4.1.”时间”幽灵


是日,周五也;Duke看到18点左右,就准备收拾东西回去,下班回家,临走之前将之前其他部门申请的权限及时分配下去,以便周末变更之用。就这样Duke按时的回去了。

时间过的很快,周末眨眼间就没了,周一回来之后,Duke对几个监控频道迅速的review,主要是针对特权账户登陆,非工作时间登陆,主频道(高危事件),活动频道(一般事件),查看的时间是从上周五9点-这周一9点,Duke快速review中,忽然,他发现,在特权账户登陆和非工作时间登陆中出现几条鲜红的事件:

20171215 03:34 路人甲 login 192.168.1.1 root 192.168.7.1 ….

20171215 04:10 路人甲 login 192.168.1.1 root 192.168.7.1 ….

20171215 04:22 路人甲 login 192.168.1.1 root 192.168.7.1 ….

Duke瞬间觉得不对劲了,立马咨询了一下周五变更的小伙伴,然后他们都说周五9点左右就离开了,变更早就做完了(一点都不按套路出牌,说好的周末变更);然后Duke就觉得是不是机器被黑了,我的天,然后他开始去查历史登陆记录,last发现在192.168.7.1上发现了上面三个登陆事件,而且都是一个地址,终端,登陆账号的确是root,然后他去查近期的root所有的操作,查看了root的.bash_history发现了一些操作,然后从堡垒机进行进一步的操作分析,发现当时的操作并没有什么不对,都是一些重启服务,打包文件的操作,重启服务?

Duke查看了crontab和checklist

crontab -u <-l, -r, -e>

然后Duke又查看了几个可疑进程:

for pid in $(pgrep进程名称); do echo -n "${pid} " ; ps -p ${pid} -o lstart | grep -v "START" ; done

再查看了几个进程的启动时间:

for pid in $(pgrep async); do echo -n "${pid} " ; ps -p ${pid} -o lstart | grep -v "START" ; done

最后查看了进程的关联IP:

netstat -anp | grep进程ID

没毛病啊,老铁,Duke有点拿这3条事件没办法,但是它的颜色是那么的鲜红,然后他又去堡垒机查看了一下操作录屏,然后,他发现,堡垒机录屏的事件分别是19:34;20:10;20:22;

唉,这个时间好像对的上,然后那这个时间去咨询了一下运维和监控的小伙伴,确定变更时间,的确是这三个时间,那问题是?

服务器的时钟可能没有同步,所以产生的日志源有问题,Duke立马去查看了192.168.7.1的时间,果然,现在的时间比真实时间慢了14h,我的天,然后直接和系统管理员联系,通过NTP对所有的服务器的时间进行同步了。

总结:不论是平时的业务还是办公,或者是SIEM建设,日志和攻防的基础都是时间差,也就是说,时间越同步越精确,你的事件处理越准确越高效。

4.2.死灰复燃的亡魂

Scott大哥来到监控室,悄摸摸的对我们说:

“等会下班有事么?”

“没啊?哥,请吃饭?”

“吃啥啊?服务器中勒索病毒了,快来看!”

“这么新奇?我都没见过中病毒的服务器欸,我要看”

“。。。。。。”


就这样我们下班留了下来,留下来的Duke和Felix看着Feng大佬和其他大佬们,然后我们小脑袋不断的思考,这特么啥玩意,我得看看。

然后,Duke对邮箱地址做了检索,然后去查找最近勒索病毒的一些公告,最后发现,这尼玛好像可以挖矿

“哥,这玩意好像可以挖矿诶?”

“就你话多”

“。。。”

Duke查了一下,发现这病毒叫Arena,中文名叫艾瑞娜,好名字,不得不说,然后我们发现了一些东西:Trojan.Gen.2和PUBA.Bitcoinmine病毒,其实一开始我就看成了PUBG挖矿病毒了,嘿嘿嘿,然后进一步查看安全日志和预警信息,发现在C盘还有这玩意:Heur.AdvML.B病毒,路径在user账户appdataroamingmicrosoftwindowsstart,啥都别说了,先干掉这些玩意,然后我建议看下任务管理器,我也觉得这是个好主意:

“占用率不错啊,70%了”

( ̄▽ ̄)”

发现这病毒还通过OneDrive传输文件出去,然后我们发现了一个国外的IP,再查查,看看这个撒比(dalao)还干了啥。然后发现账户区域多了一个奇怪的账户,这里我们可以创建一个类似的账户以便去以假乱真,然后还等着干嘛,干掉那个新账户,接着我们发现最早是一个普通账户,我们把他叫做Disco吧(普通的Disco);出现了异常登陆,登陆地址是美国,

“我们有美国的子公司么?”

“瞎说,不存在的”

“那这个?”

“干掉”

然后我们把病毒处理了,中毒机器的账户密码改了,系统还原了,处理完就回去了。

若干天后(一个礼拜左右吧)

微信传来了一个消息:

“192.168.1.1服务器状态满了”

“这么厉害的吗?我看看”,“卧槽,真满了”,”机器应该是闲着没事做,挖矿了“

”就你话多“

然后我还能怎样?我还怎么样?排查呗,然后经过大佬Feng和我们的排查发现,又是那个普通的Disco在普通的挖矿,哎哟,( ̄y▽, ̄)╭ ,你还死灰复燃了,不对,这次好像换了个机器=。=

我去,这不是机器漏洞,这是弱口令啊。

”对“

”对的“

然后我们又给机器来了一套全面按摩(检查),检查完,发现,账户没有新建,然后就是在挖矿,也没有勒索我(这次低调了),然后OneDrive泥煤还是开着的,然后我们就干掉了它,还原镜像,然后我说:

”要不我们把所有账户全部统计一下,然后把Disco都重置了?“

”工作量有点大“

”=。=“

”搞呗“

就这样,我们把整个区域的Disco全部干掉了,你说你是Disco我会爱你么?干掉。不存在的

总结:账户管理要到位,所有的账户必须通过堡垒机进行管控,特权账户必须申请,审批后授予,然后需要及时收回,同时对操作要按时做审计,最后弱口令一点要干掉。偷偷告诉你们我见过的一些弱口令啊:

1qaz@WSX,qwer1234,1qaz@WSX#EDC,什么嘛,当我没有字典嘛,分分钟给你爆了

4.3.你的能量超乎你的想象

”Duke,去吧SIEM重装一下,然后写一份手册“

”OjbK“

然后我就找包,拷贝,上传,一气呵成,准备开始我的丰功伟业:重装SIEM,并记录过程。

唉,开始呗,在这之间我遇到好多事情的,我跟你们说,最奇葩的在后面

我兴奋的拿着我root账户,噼里啪啦一梭子下去,配置?不存在的,直接回车,然后提示我:

ulimit too small,然后建议我改成4096

然后继续操作,回车到最后设置一个登陆账户,我设置完了后,准备去检查一下我可爱的服务,然后我进入到了/etc/init.d 啥,你告诉我没有这个服务,然后我只能打开我那些user config book啊,然后我找了好久都没有找到相关的故障报错的信息。

我想,我可能需要再来一次,然后我删除了组件,重新开始了安装,然后我发现最上面有一对小字:please install tools through Disco,啊哈?啥,用普通用户啊

我只好用Disco再来一遍,果然,服务起来了

后来我去检查了一下,我们可爱的SIEM(外国血统哦)需要使用普通用户创建服务,这样服务才能创建成功,那是不是root就不行了,不是,只是root不是默认的,我在最后面又看到了一排小字:

作者:安全客

上一篇         下一篇
文章分类
分享
本站推荐