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

  • A+
所属分类:安全文章

前篇 《事件处置(续):我的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):应急处置原则:电子证据的挥发性

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: