对于很多企业来说，安全事件处理都算是传说中的事情。很多企业对于安全事件处理没有经验，再往深了说都不知道自己是否受到了攻击。乌云安全峰会现场，来自百度云安全部安全架构师&技术负责人王宇分享了百度处理安全事件的经验——《安全事件处理二三事》。
以下是王宇的演讲全文：
大家下午好。首先感谢大家来。我今天跟大家分享的是百度在安全响应方面的经验以及一些事情的处理，这方面之前也没看到对外进行分享过，但是这个对于大多数企业来说，我个人觉得这个还是蛮有意义的。这是我讲的Agende，我的网名叫小宇，目前我是百度云安全部安全架构师。
什么是应急响应?这跟大家刚才看的猪猪侠的演讲感同身受，图片上的人是美国国土安全部部长，他叫切尔托福。他讲过，世界上有两种人，一种被黑过，一种被黑了不知道的。
我想说的是一个企业安全做的好，安全事件处理的好的话，很多不是事情发生以后才处理的，包括事前的建设，当时事情真正发生的时候我们才能有条不紊地去处理好它。
先不说什么是应急响应?我站在这个角度说一下应急响应的范围。第一个是国内叫的SRC，它对外叫应急中心。应急响应要干的事情?
第一，它不是比谁找出的后门多，和黑客捉迷藏。因为本身来说，特别是刚开始处理安全事件的同学，很容易陷入这样的矛盾，我要把所有黑客后门找出来。第二，不是把系统黑一遍，然后说黑客就是这样入侵的。
我看到网上有很多分享，关于应急响应的案子来说的话，他说我这个网站被黑了，我拿我的扫描器扫了一遍这个网站，我发现漏洞，通过这个漏洞拿到了分享。这是你的一个思路，但是并不代表事实的真相是这样。
第三，应急响应和计算机取证时的关系。其实计算机取证和应急响应有不同的目标，虽然有很多技术重叠，我这里强调慢慢做研究。第四，可能、也许、应该，这有好处，我认为攻击者是这样的，但是真的是这样吗?
我说的是大胆猜测，小心取证。我列出了我们内部对应急响应的定义范畴，这里列出六条，首先，控制事情的影响范围，我们保证线上业务正常运转，是我们最终的目的。第二，还原攻击场景，攻击者到底做了什么事情，包括他是怎么样进来的，以及他进来以后都做了哪些事情，通过哪些漏洞进来的。第三，明确攻击意图。
就是说我一个人为什么黑你，当然不排除我在互联网大网扫描黑一个机器，这个站在我们角度我们并不太担心，我们担心的是针对企业的APT，或者有针对性的搞你的。第四，找到问题并改进。
就是为了避免错误一而再，再而三犯的话，这里我们需要还原他进来的场景，然后找到自己根本问题的。第五，反思自己不足。我们现有的监控体系有什么不足。第六，在中国情况下用的不多，但是也是范围之内，就是司法追究。
接下来聊聊应急响应需要做什么方面的技术储备?应急响应是一个比谁更全面系统的过程。还有一些业务专业知识。不管怎么说，小说里传的是黑客无所不能，他甚至可以打败管理员，这个打败实际上是有一定限制的，我们至少有优势，这里我列出两点：
第一，我们是坐前面的人，最次的是把业务下线，这是没有办法的办法，为了保住其他业务。
第二，我们对业务的了解，我们可能之前没有接触过业务，但是应急响应会有开发运维的同学来问，首先一个很重要的观点，如果你不了解业务和系统，第一时间去找开发和运维的同学了解。
第三，我们自己必须做应急响应很广博的知识，我们需要去了解攻击手法的局限性。
刚才也说了不要想当然，A五可能被黑了，他告诉运维的说被黑了，运维的说我们这儿出现一个被黑事件，他告诉上级部门，可能最后跨了几个级别到了处理安全的，这对信息的描述可能完全变味，所以我们处理问题一定要找到第一手的人员，比如这个系统的开发人员，或者这个系统运维人员问清楚。
大胆猜测，小心求证，我在后面会具体举例子说。
说到黑客入侵会带来系统变化，我在这里说一些tips。大家可以看到这里unix的一个输出，可以看到对于一个默认安装的系统，大多数，用发行版的系统，它的Inode分布是集簇化的。
还有安装包情况，我们可以看到系统默认安装完成后会有逆序的管理在这儿。这样装的话很明显的可以看到系统被更改了。
还有在系统中有一个很重要的事情，就是确定这个事件发生的时间，这里的MAC是指的修改时间，还有访问时间，这不是文件的创建时间。
还有关于删除的，比如说我在Unix下做一个事情，我可能删除sislog，真删除了吗?我直接去访问它的kad，我看这里打开的文件句柄的话，这是简单的事情，复杂的也不提了。
默认的Tips还有很多，像代码造成的特征，比如以前的驱动的引用，可能会加在一些不常用的驱动，必然会在Log里打出来。刚说到有些事情功夫在事外了。
下面我分享一下案例。应急响应对时间的要求非常重要的，要求处理事件的同学，在第一时间对事件进行一些定性和定量的分析，能做出判断，比方说我要下线，还是重装机器，还是进一步观察入侵者。我举的第一个案子，这都是实际发生的。
比如我们这里有运维的同学，自己系统的用户目录会周期性的丢文件，但是又没有丢所有文件，怀疑是有人故意破坏或者入侵事件。第一的反映，肯定先给同学安全意识点个赞，就是有什么问题，安全相关的东西会提交到我这儿，这是安全相关教育的，是我们非常需要的。
第二个，这个好嚣张啊。但是反过来想会有这么二的吗?然后沟通发生的时间。我在这里进行了简单的操作，我们看了一下用户的Root，大家看一下，看到这个东西的话，第一反映是什么?
我花了五分钟把这个问题破了。我第一时间看了一下Crontab App，这个它删不了我们root输入的东西，紧接着我在Crontab跑的东西搜，前面是Rm，然后后面变成删除根目录的行为。这个案子告诉我们，企业日常报过来的案子，根据我的经验是70-80%是带双引号的。这就是第一个议题，先定性再干活。
第二个案例，某一日收到Webshell报警，也确认了是一次入侵事件，这个实际上可以记录在我们系统中执行的命令，我们看了一下，非常熟练。可是这是台linux，我们就不便提了，最终我们是盯下了这个人。
我们通过分析这个东西能得出一个结论，当然这个结论可能需要你结合其他东西判断，当然猛地一看，正确评估你的对手，实际上是一个后续工作的指导。当然我们这里相对于小白性质的入侵者。
当然我们也遇到特别资深的黑客，结果是我们也是和其他的厂商一起合作，因为攻击的也有其他厂商，我们一块儿把这个同学处理了，目前还没有结案，所以具体细节也不便透露。
第三个，一个综合性的例子，第二条说的是大家要正确评估你的对手，第三个是结合我们的平台出现的异常，给大家说一下，分析问题发生的思路。也是某日，编译平台接到了报告，说出现了异常。
根据前面的准则，先定性。真的像说的那样严重吗?BAE部分网站访问跳转，第一义反应是被撞库了。BAE负责人的网站也受影响，调了密码帐户的近期登陆无记录，无异常，检查了网站的配置文件，也没有被修改，确实是出现问题了。
我去实际的应用机器测了一下反馈，如果知道的就知道了，不知道的话我也不会具体说这个网站是什么。我们要做的就是像攻击者一样思考，攻击者处理我们的网站或者对我们的劫持，他的目的是什么?
首先他是跳转到这个网站，比如说Exxxtimes，最主要导致的结果是BAE整体被封禁，这是触底线的事。攻击者是谁呢?宣传XX的，略傻的。是不是炫耀?这也不是炫耀，也没有重定向到某个个人的网站。
那么我们确定问题到底发生在哪儿了?我们结合自己了解到的BAE整体框架，这是我们引用了一些内部的，比如BVS大家可以理解为附带均衡，上面跑的CJI，后面挂了一个封闭式系统在这儿。
它的报告问题全出现在Python环境，一个机器上有两个lightpd环境，只有一个受到影响。即使受到影响的实例，并不是100%都产生跳转，任意看了几个空间的根目录conf也无异常。
我们的目光转向了CGI，BAE多租户特性，同一个cgi会运行多个不同的网站代码，我们做了sandbox的防护，如果出问题，最大可能是Phthon代码对于进程的运行状态进行了改变。
Python设计之初并不是作为Web的CGI语言开发的，必然导致实现上针对CGI接口暴露过多底层的东西，发现了CGI的CORE文件，简单的Strings了下，发现了大量的exxxtimes，证实了CGI问题的猜想。
这样就是定性问题，兵分两路，Phthon环境是经过测试的，能够宽网站影响的接口应该就几个类型，还有动态的执行环境，我会在代码中搜索。另外一个层面上接着去分析，就是说这种攻击实际上是不稳定的，而且它影响其他网站，正常的CGI网站都有运行Max time，在运行完毕后就会被清出内存，攻击者为了规避自身的风险都用国外的，我结合这几个条件对日志进行了分析，发现了几个可疑的运维，当然前面说的我就直接抛掉了。
因为那个不影响，先看我当时找到的这样的一个文件，目前看这个地方看不出是什么东西，当然这种正常的写不会这样写，那种写法其实很不单纯的，我和BEA的沟通过，这样的写是某某同学所有的，这个空间多次被封的经历，实际上这与我们最初的猜想蛮像的。我调了一这个同学的测试，名字很明显，Passtest。
对可疑网站做过滤的话，因为这个攻击是持续的，很快的我们通过流量系统，把它的一个包被劫出来了，当然有一些解压的过程，我们这里可以看到，实际上是一个攻击代码了。
不同的网站用CGI的时候，受到的次数会很多。通过案例三我们得到什么?就是不要盯着技术，特别是对攻击的细节完全没头绪的时候，解决问题但不要局限于问题。当然还有学到一个新的劫持技术。
声明一下，最后说一点，目前的BAE架构早就已经更新换代了，我这里只是介绍了当时问题处理的思路。BAE当前的架构不会存在此类的问题。
总结一下：未知攻，焉知防;先定性，再干活;正确的评估你对手的水平;大胆猜测，小心求证;跳出纯粹的技术对抗的圈子，以解决问题优先。现在很多事件处理过程中，看似神秘的东西，可能需要一点即破的思路。下面推荐几本书，我是站在共享的角度，不是卖书。
