应急处置原则：电子证据的挥发性

前篇 《事件处置（续）：我的WIRTK》 原则部分，忘了写一条很重要的原则：电子证据的挥发性。

但是，从工具整理的顺序上来看，其实也是体现出了这条原则的 —— 不知道看过上篇文章的朋友是否发现了其中的奥秘。

这条忘掉的原则来自 RFC3227。

这篇RFC的题目是《Guidelines for Evidence Collection and Archiving》

挥发性原则来自2.1部分的Order of Volatility

不想去翻的就听我说两句也是一样的。

这条原则讲的就是，电子证据是有挥发性的，也就是说 —— 有些数据不马上去取的话，很可能一两分钟之后就没了。

比如，netstat -an 的结果，这个我们都知道，网络连接一旦断开，这里的结果也只会保存2-5分钟而已。

挥发性极强的证据还有很多，比如，很多内存里产生的数据都会转瞬即逝，这也是为什么我以前都会推荐现场处置的人，一旦发现异常进程先dump内存再做分析，甚至可能直接dump整个内存。

而有最强挥发性的证据，当然也有挥发性最弱的。

比如，硬件本身，一般不会无故的凭空消失，所以关于硬件的信息，相对来说是最不着急获取的，所以在取证过程中可以放到最后。

当然还有一些居中的，比如，缓存、临时文件、日志等，这些都是可能是随着时间推移以及系统的运转而被覆盖掉的，但时效性要求上上不如netstat、内存等，所以可以放到第二位。

RFC3227 给出了一个顺序，可以参考：

• registers, cache

• routing table, arp cache, process table, kernel statistics,memory

• temporary file systems

• disk

• remote logging and monitoring data that is relevant to the system in question

• physical configuration, network topology

• archival media

  
  

总的来说，场景不同，可能有些顺序是需要微调的。

所以最好的方式是这样，对于挥发顺序上排前两名甚至前三名的电子证据，最好通过自动化脚本的方式进行批量采集，再怎么说，这样的方式也会比手动更快 —— 我曾经就遇到过一个悲催的经历，一台Linux被入侵，上来习惯性的 netstat -antp，看到一个可疑进程，还有那端有个IP刚刚断开，结果转身被叫出去，十多分钟后回来发现terminal被人关了、关了、关了、关了 ……

每当想起，仍想哭泣 … 这篇就补充到这里吧。

RFC3227链接在这里：http://www.faqs.org/rfcs/rfc3227.html

（扫码关注）

本文始发于微信公众号（Piz0n）：应急处置原则：电子证据的挥发性