在进行事件响应之前，你应该非常明白一个道理，就是事件处理时不能违背你制定的响应目标，不能在处理过程中避重就轻。例如，本来是要尽快恢复系统运行的，你却只想着如何去追踪攻击者在何方，那么，就算你最终追查到了攻击者，但此次攻击所带来的影响却会因此而变得更加严重，这样一来，不仅不能给带来什么样成就感，反而是得不偿失的。但如果你事件响应的目标本身就是为了追查攻击者，例如网络警察，那么对如何追踪攻击者就应当是首要目标了。
事实证明，按照事先制定的处理步骤来对事件进行响应，能减少处理过程当中的杂乱无章，减少操作及判断失误而引起的处理不及时，因此，所有事件响应小组的成员，不仅要熟习整个事件响应计划，而且要特别熟练事件处理时的步骤。
总体来说，一个具体的事件响应步骤，应当包括五个部分：事件识别，事件分类，事件证据收集，网络、系统及应用程序数据恢复，以及事件处理完成后建档上报和保存。现将它们详细说明如下：
1、事件识别
在整个事件处理过程当中，这一步是非常重要的，你必需从众多的信息中，识别哪些是真正的攻击事件，哪些是正常的网络访问。
事件识别，不仅要依赖安全软件及系统所产生的各种日志中的异常记录项来做出判断，而且也与事件识别者的技术水平及经验有很大的关系。这是因为，不仅安全软件有误报和漏报的现象，而且，攻击者往往会在成功入侵后，会用一切手段来修改这些日志，以掩盖他的行踪，让你无法从日志中得到某些重要的信息。这时，一个有着丰富经验的事件识别者，就可以通过对网络及系统中某种现象的判断，来决定是否已经受到了攻击。
有了可靠的日志，再加上在受到了攻击时会出现各种异常现象，我们就可以通过分析这些日志文件中的记录项，以及对各种现象的判断来确定是否受到了真正的攻击。因此，如果日志中出现了下面列出项中的记录，或网络和主机系统出现了下面列出项中的现象，就一定表明你所监控的网络或主机已经或正在面临着某种类别的攻击：
（1）、日志文件中记录有异常的没有登录成功的审计事件；
（2）、日志文件中有成功登录的不明账号记录；
（3）、日志文件中存在有异常的修改某些特殊文件的记录；
（4）、日志文件中存在有某段时间来自网络的不正常扫描记录；
（5）、日志文件中存在有在某段时间启动的不明服务进程的记录；
（6）、日志文件中存在有特殊用户权限被修改或添加了不明用户账号的记录；
（7）、日志文件中存在有添加了某种不明文件的记录；
（8）、日志文件中存在有不明软件主动向外连接的记录；
（9）、查看日志文件属性时，时间戳不对，或者日志文件大小与你的记录不相符；
（10）、查看日志文件内容时，发现日志文件中的某个时间段不存在或被修改；
（11）、发现系统反应速度变慢，或在某个时间段突然变慢，但已经排除了系统硬件性能影响的原因；
（12）、发现系统中安全软件被停止，正常服务被停止；
（13）、发现网站网页被篡改或被删除替换；
（14）、发现系统变得不稳定，突然死机，系统资源占用过大，不断重启；
（15）、发现网络流量突然增大，查看发现对外打开了不明端口；
（16）、发现网卡被设为混杂模式；
（17）、某些正常服务不能够被访问等等。
能够用来做出判断异常记录和异常现象还有很多，笔者就不在这里全部列出了。这要求事件响应人员应当不断学习，努力提高自身的技术水平，不断增加识别异常现象的经验，然后形成一种适合自己的判断方法后，再加上日志分析工具以及安全监控软件的帮助，就不难在这些日志记录项和现象中找出真正的攻击事件来。
到目前为止，通过分析各种日志文件来识别事件性质，依然是最主要的方法之一。你可以重新设置这些安全软件的日志输出格式，使它们容易被理解；你也可以重新详细设置安全软件的过滤规则，减少它们的误报和漏报，增加可识别强度；你还可以使用一些专业的日志文件分析工具，例如OSSEC HIDS，来加快分析大体积日志文件的速度，提高识别率，同时也会减轻你的负担。至于担心日志会被攻击者删除或修改，你可以将所有的日志文件都保存到受防火墙保护的存储系统之中，来减少这种风险。总之，为了能从日志文件中得到我们想要的信息，就应该想法使日志文件以我们需要的方式来工作。
所有这些，都得要求事件响应人员在平时经常检查网络及系统的运行情况，不断分析日志文件中的记录，查看各种网络或系统异常现象，以便能及时真正的攻击事件做出正确的判断。另外，你应当在平时在对网络系统中的某些对象进行操作时，应当详细记录下你所操作过的所有对象的内容及操作时间，以便在识别时有一个判断的依据。在工作当中，经常用笔记录下这些操作是一个事件响应人员应当养成的好习惯。
当发现了上述出现的异常记录或异常现象，就说明攻击事件已经发生了，因而就可以立即进入到下一个环节当中，即对出现的攻击事件的严重程度进行分类。
2、事件分类
当确认已经发现攻击事件后，就应当立即对已经出现了的攻击事件做出严重程度的判断，以明确攻击事件到达了什么地步，以便决定下一步采取什么样的应对措施。例如，如果攻击事件是涉及到服务器中的一些机密数据，这肯定是非常严重的攻击事件，就应当立即断开受到攻击的服务器的网络连接，并将其隔离，以防止事态进一步的恶化及影响网络中其它重要主机。
对攻击事件进行分类，一直以来，都是没有一个统一的标准的，各安全厂商都有他自己的一套分类方法，因此，你也可以自行对攻击事件的严重程度进行分类。一般来说，可以通过确认攻击事件发展到了什么地步，以及造成了什么样的后果来进行分类，这样就可以将攻击事件分为以下几个类别：
（1）、试探性事件；
（2）、一般性事件；
（3）、控制系统事件；
（4）、拒绝服务事件；
（5）、得到机密数据事件。
对网络中的主机进行试探性扫描，都可以认为是试探性质的事件，这些都是攻击者为了确认网络中是否有可以被攻击的主机，而进行的最基本的工作。当攻击者确认了要攻击的目标后，他就会进一步地对攻击目标进行更加详细，更加有目的的扫描，这时，所使用的扫描方式就会更加先进和不可识别性，例如半连接式扫描及FIN方式扫描等，这种扫描完成后，就可以找到一些是否可以利用的漏洞信息，由于现在的一些整合性防火墙和IDS也能够识别这些方式的扫描，因此，如果在日志文件中找到了与此相应的记录，就表明攻击已经发展到了一般性事件的地步了。当攻击者得到可以利用的漏洞信息后，他就会利用各种手段对攻击目标进行渗透，这时，如果你没有及时发现，渗透的成功性是非常大的，网络中已经存在有太多的这类渗透工具，使用这些工具进行渗透工作是轻而易举的事，在渗透成功后，攻击者就会想法提高自己在攻击目标系统中的权限，并安装后门，以便能随心所欲地控制已经渗透了的目标，此时，就已经发展到了控制系统的地步。到这里，如果你还没有发现攻击行为，那么，你所保护的机密资料将有可能被攻击者完全得到，事态的严重性就可想而知了。攻击者在控制了攻击目标后，有时也不一定能够得到机密数据，由此而产生一些报复性行为，例如进行一些DOS或DDOS攻击等，让其他正常用户也不能够访问，或者，攻击者控制系统的目的，就是为了对其它系统进行DOS或DDOS攻击。
此时的你，就应该从日志文件的记录项中，迅速对攻击事件发展到了哪种地步做出明确的判断，并及时上报小组领导，以及通报给其他小组成员，以便整个小组中的所有成员能够明确此次攻击事件的严重程度，然后决定采取什么样的应对方法来进行响应，以防止事态向更加严重的程度发展，或者尽量减小损失，及时修补漏洞，恢复网络系统正常运行，并尽快收集好所有的证据，以此来找到攻击者。
3、攻击事件证据收集
为了能为析攻击产生的原因及攻击所产生的破坏，也为了能找到攻击者，并提供将他绳之以法的证据，就应该在恢复已被攻击的系统正常之前，将这些能提供证据的数据全部收集起来，妥善保存。
至于如何收集，这要视你所要收集的证据的多少及大小，以及收集的速度要求来定。如果只收集少量的数据，你可以通过简单的复制方法将这些数据保存到另外一些安全的存储媒介当中；如果要收集的数据数量多且体积大，而且要求在极少的时间来完成，你就可以通过一些专业的软件来进行收集。对于这些收集的数据保存到什么样的存储媒介之中，也得根据所要收集的数据要求来定的，还得看你现在所拥有的存储媒介有哪些，一般保存到光盘或磁带当中为好。
具体收集哪些数据，你可以将你认为能够为攻击事件提供证据的数据全部都收集起来，也可以只收集其中最重要的部分，下面是一些应该收集的数据列表：
（1）、操作系统事件日志；
（2）、操作系统审计日志；
（3）、网络应用程序日志；
（4）、防火墙日志；
（5）、入侵检测日志；
（6）、受损系统及软件镜像。
在进行这一步之前，如果你的首要任务是将网络或系统恢复正常，为了防止在恢复系统备份时将这些证据文件丢失，或者你只是想为这些攻击留个纪念，你应当先使用一些系统镜像软件将整个系统做一个镜像保存后，再进行恢复工作。
收集的数据不仅是作为指证攻击者的证据，而且，在事件响应完成后，还应将它们统计建档，并上报给相关领导及其它合作机构，例如安全软件提供商，合作伙伴，以及当地的法律机构，同时也可以作为事后分析学习之用。因此，这个事件响应操作步骤也是必不可少的，收集到的数据也应当保存完整。
4、网络、系统及应用程序数据恢复
在收集完所有的证据后，就可以将被攻击影响到的对象全部恢复正常运行，以便可以正常使用。是否能够及时的恢复系统到正常状态，得依靠另一个安全手段，就是备份恢复计划，对于一些大型企业，有时也被称为灾难恢复计划，不管怎么说，事先对所保护的重要数据做一个安全的备份是一定需要的，它直接影响到事件响应过程中恢复的及时性和可能性。
在恢复系统后，你应当确保系统漏洞已经被修补完成，系统已经更新了最新的补丁包，并且已经重新对修补过的系统做了新的备份，这样，才能让这些受到攻击恢复正常后的系统重新连入到网络当中。如果当时还没有最新的安全补丁，而又必需马上恢复系统运行的话，你可以先实施一些针对性的安全措施，然后再将系统连入到网络当中，但要时刻注意，并在有补丁时马上更新它，并重新备份。
恢复的方法及恢复内容的多少，得看你的系统受损的情况来决定，例如，系统中只是开放了一些不正常的端口，那就没有必要恢复整个系统，只要将这些端口关闭，然后堵住产生攻击的漏洞就可以了。如果系统中的重要文件已经被修改或删除，系统不能正常运行，而这些文件又不能够被修复，就只能恢复整个系统了。恢复时，即可以通过手工操作方式来达到恢复目的，也可以通过一些专业的备份恢复软件来进行恢复，甚至，在有些大中型企业，由于数据多，而且非常重要，对系统稳定性和连续性有很高的要求，例如一些网站类企业，就会使用一个备用系统，来提供冗余，当一套系统遭到攻击停运后，另一套系统就会自动接替它运行，这样，就能让事件响应小组人员有足够多的时间进行各项操作，而且不会影响到网络系统的正常访问。
恢复在整个事件处理步骤当中是比较独特的，将它放在哪一步来执行，你应当以你的保护目标来决定，例如，当你保护的首要目标是为了尽快恢复网络系统或服务能够正常访问，如果有备用系统的，因为备用系统已经接替受攻击的系统运行了，就可以按上述步骤中的顺序来进行操作，而对于只有备份文件的，如果想要系统最快速度地恢复正常运行，可以先将整个受损系统做一个镜像，然后就可以迅速恢复备份，投入运行。
其实，任何处理步骤，说白了，就只是让你养成一种对某种事件处理过程的通用习惯性思维和工作流程而已。
5、事件处理过程的建档保存
在将所有事件都已调查清楚，系统也恢复正常运行后，你就应当将所有与这次事件相关的所有种种都做一个详细的记录存档。建档的目的有二点，一是用来向上级领导报告事件起因及处理方法，二是用来做学习的例子，用来分析攻击者的攻击方法，以便以后更加有效地防止此类攻击事件的发生。具体要记录保存的内容涉及到整个事件响应过程，要记录的内容比较多，而且响应过程有时比较长，因此，这就要求安全事件响应人员在事件处理过程当中，应当随时记录下响应过程中发现的点点滴滴和所有的操作事件，以便建档时能使用。
建档格式是可以由你自行来规定，没有具体的标准的，只要能够清楚地记录下所有应该记录的内容就可以了。也可以将文档做成一式三份，一份上报领导，一份保存，一份用来分析学习用。也可以将这些文档交给一些专业的安全公司和系统及应用软件提供商，以便它们能够及时地了解这种攻击方法，并发布相应的防范产品和安全补丁包，还可以向一些合作伙伴通报，让它们也能够加强这方面的防范。
具体要建档的内容如下所示：
（1）、攻击发生在什么时候，什么时候发现的，发现人是谁？
（2）、攻击者利用的是什么漏洞来攻击的，这种漏洞是已经发现了的，还现在才出事的，漏洞的具体类别及数量？
（3）、攻击者在系统中进行了哪些方面的操作，有哪些数据或文件被攻击者攻击了？
（4）、攻击的大体发展顺序是怎么进行的？
（5）、造成此次事件的关键因素是什么？
（6）、解决此次事件的具体流程是什么？
（7）、攻击造成了什么后果，严重程度如何，攻击者得到了什么权限和数据？
（8）、攻击者是如何突破安全防线的？
（9）、用什么工具软件解决的？
（10）、此次事件在发现及处理时有哪些人员参与，上报给了哪些部门及人员？
（11）、事件发生后，损失的恢复情况如何？
（12）、此次攻击有了什么新的改变，是否可以预防和应对？
（13）、以后应该如何应对这种安全事件，给出一个具体的方案附后等等。
以上所列出的，都是建档时应当记录的内容。建档人员可以自由安排记录的顺序，但是得和事件处理的顺序相对应，以便让其它人员更好地理解和学习。当然，你还可以记录其它没有在上述项中提到的内容，只要你认为有记录下这些内容的必要，或者是你的响应小组领导要求记录下这些内容。
本文转自 雪源梅香 51CTO博客，原文链接：
http://blog.51cto.com/liuyuanljy/184852
，如需转载请自行联系原作者
