应急响应那些不一样事儿

莫慌搞安全

已于 2024-08-06 10:13:42 修改

阅读量510

点赞数 26

分类专栏：应急响应文章标签：应急响应

于 2024-08-06 10:10:10 首次发布

本文链接：https://blog.csdn.net/u014247926/article/details/140944462

版权

应急响应专栏收录该内容

1 篇文章 0 订阅

订阅专栏

前言

应急响应的概念较大，本文的应急响应专门指信息安全事件应急响应。其实应急响应完全可以扩展到极多的方面，都可以作为自己拔高的手段，前提是你能接触到老板。当前主流的应急响应流程是PDCERF法（Prepare准备）、Detection(检测)、Containment(抑制)、Eradication(根除)、Follow-Up(跟踪)）。或者是六大阶段：准备 —— 检测 —— 抑制 —— 根除 —— 恢复 —— 总结。其实我不认同。

作为职业安全员，首先是时刻准备着，当收到设备告警的时候，第一步就是完成检测。所以是没有准备阶段的。其次处理外部事务，安全员收到客户公司告警的时候，也意味着客户公司已经发现并完成了他们认为他们能处理的事情，所以这事更可能是一种复盘式检查，从抑制或者根除阶段你开始，根本没有跟踪阶段。当然作为提供的一种服务，这样会显得专业。

不过今天不是来挑这些刺，我只是想说说有些时候，应急响应事件的情况会复杂到超出这些阶段之外。我说几个小事儿，各位领导听听：

注释：基于一些因素，没有任何截图

贼喊捉贼

曾经在某人X局处理一起应急响应。该局的主业务系统数据库文件被删导致系统无法使用，代运维公司人员上报后，该局领导要求代运维公司自己出费用找专业安全公司。

背景交代完毕，到达用户第一现场，并不是直接处理问题，而是了解情况。经过确认，用户现场没有流量层监测设备，没有虚拟机快照，双活，数据库备份机制（好家伙，代运维公司估计也是低成本人力），业务实属无法恢复了。局领导要求找出问题原因。

按照常规黑客攻击进入主机进行痕迹收集，是一台centos,收集了尽可能的收集的日志。最终发现数据库log日志没异常，web日志没异常，近期变化文件无异常，近期新增文件无异常，无可疑计划任务，history日志没有发现啥问题，ssh日志有疑似爆破记录，但是没有爆破成功记录。发现2个最近登录IP均为代运维IP，没有堡垒机记录运维操作（我又凸了）。

事情僵住了，转头跟运维要了他们内部沟通的qq记录，给了三个截图：有3个重要的点：

代运维人员在事发前几个小时打算升级系统数据库
代运维人员按照SOP升级数据库后，业务系统起不来了，求助其他人员
代运维人员在该局人员的群里上报疑似黑客攻击导致数据库被删

最后一条不用信，这不符合黑客的行为逻辑，攻击你的系统，就是为了删你的数据，为啥不rm -rf /。所以到这里我有一个大胆的猜测，代运维人员升级数据库之前，没有备份数据，导致数据表被重置！我回头重新审计histroy日志，发现确实没什么稀奇的，这里与centos的history机制有关，确实不一定看到别人的命令记录。不管了，直接去看业务数据库db，发现大小确实很小，只有几kb，确实没数据，表还在！

根据聊天记录里面的时间线，对比ssh日志时间戳，再对比系统受攻击的可能性。这其实就是代运维公司一次误操作，导致主业务系统数据被删。我将结论上报给领导，领导说请我们来的是代运维公司（金主）。懂懂懂！

我编写了一份真实的报告，结论是代运维公司操作失误，一个假的报告，被黑客攻击导致。两份报告我同时交给领导，同时我自己备份了2个报告和我与领导的沟通记录以备不测。后面就不由我决定了。此事完毕！

所以我很想警告某些企业负责人，请第三方做审计，一定要自己掏钱！！！

应急了也没有办法

还有一次，局里接到用户报案，说受到黑客攻击，公司销售派我去对接，跟着各位铁饭碗去了现场。通过现场了解，被攻击的公司是做游戏代理的，被DDOS（懂的都懂），铁饭碗一听也就明白了，毕竟这类案件也不是第一次遇到。现场问询了一下，有没有高防，回答说没有。希望我们能找到攻击者。立案也没有完成，老板不在，老板在另外一个公司打工（励志的老板），我就说给我日志，我们先回去分析了。拿到日志就走了，全程半个小时不到。

不是消极对待这种事件，只是在现场也没有好办法，回来看日志，确实都是CC流量，受攻击用户那边好解决，建议他们临时搞个防D，剩下的就是销售的事情了。但是铁饭碗那边我还想有一个完美的交代，就是找到攻击者（通过情报类寻找攻击者不能作为实际证据使用），各种情报分析，啥也没发现，这其实也是大概率情况，跟销售说了下，没有进一步结论。这事就到这了。毕竟铁饭碗也没给服务费。