1. 进场先别急着碰服务器定边界、留授权、记现场接到求助电话的时候通常已经是攻击发生之后了。有人在凌晨两三点打过来说数据库被拖了网站被人挂马了或者干脆就是一句“我们服务器好像被黑了你快来看看”。真正做过电子取证的人都知道这时候最危险的其实不是攻击者还在里面而是自己一上来就手忙脚乱地关机、重启、杀毒、改密码。这些操作每一个都是正义的但每一个也都在毁证据。先明确一个基本概念服务器取证是电子取证在服务器场景下的具体落地核心目标只有一个——把服务器上能够反映违法或违规行为的数据以合规、完整、可追溯的方式固定下来并从中还原出事件经过。这个目标决定了它和普通运维排障有本质区别。运维求的是系统恢复取证求的是证据保全这两个目标很多时候是冲突的。1.1 为什么“授权”不只是形式流程很多人觉得授权就是一张纸签字盖章而已。但干过这一行的人都清楚授权是整个取证行为合法性的地基。尤其是在处理企业内部服务器、云主机或者第三方托管的服务器时如果取证人没有明确的操作授权采集到的数据哪怕再完整在法律上也可能被视为非法证据最终被排除。在动手之前必须确认三件事一是有没有明确的书面授权写明取证范围、对象服务器、时间段和操作人二是如果服务器属于云平台或托管机房是否有对应的平台操作许可和管理员账号授权三是如果事件已经涉及违法犯罪或行政执法是否已经获得相应的法律文书或由有权机关介入。别觉得这个环节婆婆妈妈我见过不止一个案例因为取证人员是外部临时请来的没签授权文件最后连证据资格都被对方律师质疑。1.2 现场状态记录的最小清单授权确认之后不要着急登录系统。先记录现场状态这是很多新手最容易跳过的部分。所谓“现场”对于服务器取证来说包括物理环境和逻辑环境两层。物理层面如果是自有机房或办公场所的物理机需要拍摄服务器的机柜位置、设备型号、序列号、网线连接情况、电源状态、指示灯状态。有条件的话记录服务器上的时间显示屏幕上有登录界面就把画面拍下来。别小看这张照片后面做时间线对齐时它可能成为确认服务器当前时钟的关键依据。逻辑层面记录你进场时看到的一切系统当前是开机还是关机状态有没有正在运行的终端会话屏幕上有没有可疑输出控制台有没有外接设备。如果通过远程方式介入同样需要记录连接时间、连接方式、账号来源。1.3 区分“业务恢复”与“取证保全”的双线模式进场的第一个现实问题服务器还在对外提供服务业务部门要求尽快恢复但取证需要保留现场。怎么办我的经验是把这两件事拆开从时间上切分。先做“最小干预保全”在前5到15分钟内把内存、进程列表、网络连接、登录会话等易失性数据采集完成之后再根据实际情况决定是否进行磁盘镜像最后才允许业务方进行恢复操作。但凡业务侧的恢复动作涉及重启、拔盘、重装系统都必须放到所有取证工作完成后。有些时候业务恢复和取证保全确实无法兼顾比如数据库被加密勒索业务方要求立刻恢复备份。这时候需要做的不是在现场争执而是把“哪些数据因为业务恢复而无法获取”这个风险以书面形式记录清楚让业务方签字确认。这不是推卸责任而是职业习惯。2. 证据固定顺序背后的逻辑先易失数据再磁盘镜像服务器取证的顺序问题本质上是一个“证据价值衰减”的问题。数据所在的介质越易失其证据价值随时间衰减得越快。反过来磁盘上的数据如果不被人为破坏放在那里一年半载也还是那些数据。所以取证操作的最基本原则就是先采集最容易消失的数据再处理相对稳定的数据。这个原则在国际上有一个非常经典的操作指引——RFC 3227它给出的收集顺序大约是寄存器/缓存、内存、网络状态、进程信息、临时文件、磁盘、其他介质。虽然这个文档年代久远但它的排序逻辑到今天依然是所有取证人员入门必修的第一课。2.1 易失性数据的价值衰减曲线用一个生活类比来解释内存就像一张草稿纸上面写满了当前正在计算的内容、临时记录、涂改痕迹。而磁盘像一本已经装订好的笔记本内容相对固定。如果你想了解一个人在某个时刻正在思考什么看草稿纸远比看笔记本来得准确。服务器也一样攻击者正在内存里运行的恶意程序、刚刚建立的网络连接、当前登录的可疑账号这些信息只存在于内存和工作状态中一旦关机或重启基本就再也找不回来了。相反磁盘上的文件、日志、数据库记录哪怕服务器关机了只要存储介质没有被破坏后续随时可以镜像分析。所以要不要立刻关机答案非常明确只要这台服务器还在运行第一优先级永远是采集易失性数据而不是关机拔硬盘。2.2 正在运行的服务器上优先采集什么如果你面对的是一台还在运行的Linux服务器优先采集的内容至少包括以下几项当前时间和系统运行时间date、uptime内存使用情况和进程列表ps aux、ls -l /proc/[pid]/exe网络连接和端口监听状态netstat -tnp、ss -anp、lsof -i当前登录用户、历史登录记录who、w、last、lastlog打开的文件列表lsof、ls -l /proc/[pid]/fd计划任务、服务状态crontab -l、systemctl list-units内核模块列表lsmodWindows服务器对应的则是date /time、tasklist /v、netstat -ano、query user、wmic process list full、schtasks /query 等。这里有一个常被忽略的关键点采集命令必须从干净介质上运行而不是直接使用服务器本机的命令。因为攻击者有可能替换了系统命令本身——你敲的ps可能是一个假的ps输出是攻击者想让你看到的。所以取证U盘里要放好静态编译的工具集或者用挂载只读方式使用自定义工具包。这一点我在后面“容易翻车的细节”里还会专门展开。2.3 已经关机了怎么办另一种常见场景是进场时服务器已经被运维人员关掉了。这时候千万别做一件事为了采集内存而重新开机。原因很简单。第一重新开机会在磁盘上写入大量临时文件改变磁盘的原始状态第二如果是全盘加密的服务器开机后必须输入密钥才能进入系统而密钥这东西一旦因为输入错误触发锁定策略整块盘都可能无法解锁第三攻击者如果早有准备可能在系统启动链路里植入引导级恶意代码一开机又会造成新的数据变更。正确的做法是把服务器已经关机这个事实记录下来直接进入磁盘镜像阶段。如果条件允许且确实需要内存数据可以通过休眠文件、crash dump、换页文件等间接获取部分内存痕迹但这些都属于“能不能拿到就看运气”的补充手段不能作为唯一指望。2.4 采集命令的“干净介质”陷阱再说一遍这个问题真的太重要了。我曾经见过一个案例应急响应人员用服务器自带的 netstat 做网络连接采集事后发现这台机器上的 netstat 命令早已被替换成一个伪造版本所有输出都被过滤过关键连接一条都没显示出来。这等于白忙活一场还让攻击者有了更充分的清理时间。正确习惯是提前准备一个只读U盘或者取证光盘里面放好静态编译的采集工具在目标机器上以只读方式挂载后执行。工具的输出一定要通过“重定向到外部介质”的方式保存不要写到被测服务器的本地磁盘里否则你采集数据这个动作本身就污染了目标磁盘。采集完成后对每个输出文件都计算并记录哈希值。这些动作看似繁琐却恰恰是电子取证工作“可追溯”的基础。3. 磁盘镜像和文件系统取证不碰原件是底线易失性数据采集完成后才进入服务器取证的真正重头戏——磁盘镜像与文件系统分析。这块做得好不好直接决定后续能否还原攻击路径、找到恶意程序、固定违法证据。3.1 镜像与备份的根本差异很多企业安全工程师习惯用“备份”的思维来理解“镜像”这是两个完全不同的东西。备份通常是通过操作系统层面复制文件拿到的是一份“看得见的数据”而取证镜像是从存储设备最底层按字节进行的完整复制包含文件系统元数据、未分配空间、松弛空间、甚至已经被“删除”但物理上仍然存在的数据碎片。打一个比方备份是把你办公桌上文件柜里的文件全部复印一遍但抽屉夹层里的碎纸片、垃圾桶底下的便签、键盘缝里的纸条这些都不在备份范围内。而镜像相当于把整张办公桌连同抽屉夹层、垃圾桶内胆、地板缝一起原样扫描复制。攻击者删掉的恶意脚本、编辑过的配置文件旧版本、残留的数据库连接串往往就藏在这些“备份看不到”的区域里。3.2 硬件写保护与哈希校验对物理服务器的磁盘做镜像第一原则是“不碰原件”。标准做法是把目标磁盘通过硬件写保护器连接到取证工作站然后在取证工作站上进行镜像。所谓硬件写保护器简单理解就是一个物理层面的“只读开关”它从硬件电路上阻止任何写指令到达目标盘比任何软件层面的只读挂载都可靠。镜像工具方面Windows平台常用FTK Imager、EnCaseLinux平台最常用的还是dd和dcfldd。dcfldd比dd多了实时哈希计算和分块输出能力适合大容量磁盘镜像。对于SD卡、U盘这类小介质也可以先用Linux下的Guymager等工具。无论用什么工具镜像完成后都必须对原始盘和镜像文件分别计算MD5和SHA-256并核对一致。务必理解为什么哈希校验不是可选项哈希是证明“镜像与原盘完全一致”的唯一手段。将来这份证据拿到鉴定机构或者法庭上没有哈希校验记录的镜像其完整性和可信度可以被轻易质疑。3.3 虚拟化服务器的镜像策略现在越来越多的“服务器”其实是一台虚拟机。云主机、VMware虚机、KVM虚机取证方式和物理机有很大区别。针对云主机常用的办法是通过云平台的快照功能创建磁盘快照然后导出镜像文件。这里要注意平台导出的可能是某种特定格式的镜像比如qcow2或者raw分析时需要转换成取证工具能直接识别的格式。另外云平台快照的一致性也不完全等同于物理镜像快照时间点的内存状态往往无法直接获取如果必须拿内存需要借助云平台的控制台或者VNC进行内存采集。针对VMware虚拟机最直接的方法是使用vSphere的“导出OVF”模板或者直接复制vmdk虚拟磁盘文件。关键点是在复制之前确认虚拟机是否处于开机状态如果是开机状态直接复制vmdk可能会拿到不一致的文件系统状态稳妥的做法是先通过快照功能做一次一致性的内存和磁盘快照。另外虚拟化环境下有一个额外的取证金矿——虚拟内存文件。VMware的.vmem文件、KVM的qemu进程内存转储都可能保存着客户机操作系统的完整内存内容这对于内存取证非常有价值。3.4 文件系统层面看什么镜像做完之后就可以用取证工具进行文件系统分析了。工具上Autopsy是一个非常合适的入门选择免费、跨平台、图形界面支持时间线分析、关键字搜索、文件提取商业工具里EnCase和X-Ways Forensics更强大但价格也更高。文件系统取证的重点区域包括用户目录下的文档和下载文件、临时目录/tmp、/var/tmp、C:\Windows\Temp、回收站/Trash目录、浏览器历史与缓存、应用配置文件、近期文件列表。对于服务器来说还要额外关注Web目录通常是/var/www/html、/usr/share/nginx/html、Windows下的IIS目录、FTP上传目录、数据库数据目录、邮件存储目录等攻击者的Webshell和恶意文件最常出现在这些位置。分析的时候有一个容易踩坑的点不要只盯着文件名看。攻击者经常会把恶意文件命名为正常的系统文件名比如“index.php”里混一个带混淆代码的版本或者把二进制伪装成jpg图片。判断文件是否可疑不能只看文件名和扩展名还要看文件头magic bytes、文件哈希是否命中已知恶意库、文件时间戳是否异常、内容中是否包含base64解码后的大段代码等。4. 日志不会自己说话时间线重建与日志拼接拿到磁盘镜像、做完文件系统分析之后接下来的核心工作就是以日志为基础重建整个事件的时间线。服务器取证到这一步才算真正开始“破案”。4.1 哪些日志值得优先看服务器上的日志非常多但不是所有日志都有同等价值。根据发生频率我一般会把日志分成三个优先级第一优先级是认证和登录类日志。Linux的/var/log/auth.logCentOS/RHEL上可能是/var/log/secure、Windows事件日志中的登录日志Security事件ID 4624/4625/4672、数据库账号的连接日志。这些日志能直接告诉我们“谁在这个时间段成功登录了系统”是确定攻击入口的关键。第二优先级是应用类日志。Web访问日志Nginx的access.log、Apache的access_log、数据库查询日志、FTP传输日志、邮件日志。这些日志能反映攻击者在系统内部做了什么也能定位Webshell的上传时间。第三优先级是系统和命令历史。包括shell history每个用户的.bash_history、sudo执行记录、cron任务执行日志、系统启动日志等。这些日志用于补充攻击者具体执行过的命令细节。4.2 从单条日志到完整攻击链的拼接方法单独看一条日志往往什么都说明不了。日志分析的真正价值在于拼接也就是把不同来源、不同时间戳的日志串联成一条完整的攻击链。举个例子一个常见的入侵流程可能是这样的攻击者先对Web服务发起扫描在access.log里会留下大量异常请求包含“union select”、“../”、“/etc/passwd”这些特征的URL接着某个请求成功上传了Webshellaccess.log里对应的就是一条POST请求响应码是200客户端IP来自某个特定地址随后攻击者开始访问Webshell页面网络中会出现GET /uploads/shell.php?cmdwhoami 这样的请求最后攻击者在Webshell里执行下载命令拉下来一个恶意程序auth.log里可能并没有任何登录记录但系统进程列表里多了一个可疑进程。把这几类日志按照时间顺序排开攻击路径就清晰了。实际分析时我习惯先用关键字从Web日志里筛出可疑IP然后以该IP为线索去反查它访问过的所有路径、时间点和响应状态。再根据这些时间点去核对系统登录记录和文件系统里对应时段被创建、修改过的文件。几个角度交叉验证后最初“日志可能没问题”的判断往往会大幅翻转。这里补充一个重要技巧大日志文件不要用编辑器直接打开。一个几百MB甚至几个GB的access.log文本编辑器根本扛不住。先用grep、awk、jq这些命令行工具做筛选把可疑IP、可疑路径、可疑状态码过滤出来再对筛选结果进行分析。原始日志文件始终保持只读任何筛选和统计都在副本上进行。4.3 时间漂移与日志盲区日志拼接最让人头疼的问题是时间漂移。服务器如果长时间没有同步NTP系统时间可能偏差几分钟甚至几个小时。这意味着Web服务器的时间戳、数据库服务器的时间戳、防火墙日志的时间戳三者之间根本对不齐。如果没有先修正时间基准后面的时间线重建全是白搭。处理方法是先确定“基准时间源”以最可信的时间来源为准通常是边界防火墙或集中日志平台的采集时间。然后检查各台服务器的NTP配置和时间偏差把所有日志时间统一换算到同一时区同一基准上。这个过程要写进分析记录避免后面出现争议时说不清楚。另外要清楚日志也有盲区。攻击者如果已经拿到root权限完全可以修改或删除日志文件。很多攻击者入侵后会执行“日志清洗”把/var/log下对应的日志段清空或者用sed删除包含自己IP的行。遇到这种情况可以从备用数据通道找线索bash history、/var/log/wtmp和btmp、系统审计日志auditd、应用自身的操作日志、云平台的API调用记录这些往往不会被全部清理干净。5. 内存取证磁盘上看不到的战场说完了磁盘和日志现在要进入一个很多入门者不怎么接触、但高对抗场景下极为关键的领域——内存取证。对服务器取证来说这一步不是每次必做但一旦做了经常能拿到决定性证据。5.1 为什么内存镜像有时候能直接“破案”磁盘上留下的是“结果”内存里留下的是“过程”。攻击者运行恶意程序时恶意代码必然会被加载到内存中执行攻击者使用明文工具进行横向移动时命令行参数会在内存中留下痕迹攻击者若是用了加密通信密钥也可能在内存的某个角落。这些都是磁盘上找不到的。举一个实际案例某次应急响应中磁盘镜像里没有发现任何恶意文件系统日志也没有异常登录记录但业务方坚持说数据库被脱库了。后来采集了服务器内存镜像用Volatility分析时在处理进程列表中看到一个运行中的PowerShell进程dump下来之后发现内存里明文保存了一段下载执行脚本的远程URL和一段Base64编码的payload。再顺着这个URL去反查才找到了完整的攻击链——攻击者使用的是无文件攻击恶意代码全程没有落盘如果不是内存取证这个案子基本无从查起。5.2 Linux服务器内存采集的实操Linux服务器内存采集的常用工具是LiMELinux Memory Extractor。LiME是一个内核模块需要针对目标内核版本编译采集时通过insmod加载到内核然后把内存镜像输出到指定文件或网络端口。采集命令大致如下# 单行模式加载LiME并采集内存到/mnt/evidence/mem.lime insmod ./lime-$(uname -r).ko path/mnt/evidence/mem.lime formatlime # 如果本地磁盘空间不足可以通过网络输出到远程取证服务器 insmod ./lime-$(uname -r).ko pathnet:192.168.1.100:4444 formatlime实际操作中有几个要点。首先LiME编译需要目标服务器的内核头文件如果服务器内核版本比较老在干净的编译环境里交叉编译更稳妥。其次内存镜像文件非常大通常与物理内存大小相当甚至超过输出位置要有足够空间建议置于单独挂载的取证盘或直接通过网络输出这样不会污染目标磁盘。最后采集完成后马上计算哈希并对镜像文件做只读保护。Windows服务器的内存采集相对简单一些可以用DumpIt、FTK Imager的命令行版本等工具采集后同样要马上哈希固化。5.3 Volatility分析的基本动作拿到内存镜像后主流分析工具当然是Volatility 3。Volatility分析的基本流程是先识别镜像对应的操作系统版本和内存配置文件然后依次执行几个核心插件模块。在Windows内存中我一般先跑windows.psscan和windows.pstree查看进程列表再跑windows.netscan查看网络连接再用windows.malfind扫描隐藏或可疑的进程内存区段最后对可疑进程执行windows.dumpfiles导出完整进程内存。在Linux内存中对应的插件是linux.pslist、linux.netstat、linux.malfind等。分析时要特别注意“隐藏进程”现象。rootkit级别的恶意程序会通过直接内核对象操作把自己从进程链表中摘除在系统进程列表和常见工具中完全看不见。但Volatility的psscan是基于物理内存扫描的可以绕过进程链表直接发现这些隐藏进程。如果你在进程扫描里看到某个进程有正在监听的网络端口、命令行参数中还带着可疑URL或下载路径那基本就可以锁定嫌疑了。内存取证的另一个重要用途是提取加密密钥和凭据。比如BitLocker全盘加密的服务器如果开机状态下采集到了内存就可以用Volatility的相应插件尝试提取完整卷加密密钥。这意味着就算磁盘本身是加密的只要内存镜像在手照样可以解密分析。这在实际的案件处理中经常成为突破口。6. 恶意程序与持久化排查别让攻击者留在原地服务器取证的最终目的之一是搞清楚攻击者有没有在系统内留下后门以及这些后门是通过什么方式实现“持久化”的。所谓持久化就是恶意程序能够跨越重启继续存活的能力。排查持久化是整个恶意程序分析中最核心的部分。6.1 持久化机制清单不同操作系统下持久化机制各有不同排查时心里要有一张完整的清单。Linux服务器上常见的持久化手段包括计划任务crontab、/etc/cron.*、系统服务systemd服务单元、init.d脚本、启动脚本/etc/rc.local、profile文件、bashrc、可加载内核模块、SSH授权信任文件authorized_keys、动态库预加载/etc/ld.so.preload、LD_PRELOAD环境变量、PAM模块替换等。Windows服务器上常见的则包括注册表自启动项Run键、计划任务、服务服务名伪装成系统服务、启动文件夹、WMI事件订阅、COM组件劫持、DLL搜索路径劫持、启动时加载的驱动等。对照清单逐一排查基本上能覆盖90%以上常规恶意程序的持久化方式。但真正高水平的攻击者不会用这些“普通”方式他们会选择更隐蔽的持久化手段比如修改系统固件、替换Bootkit引导程序或者直接以无文件方式内存常驻。针对这类高对抗场景文件系统取证可能已经不够需要配合内存取证和启动链路分析。6.2 从时间戳和启动链路上找破绽排查持久化的时候我特别看重两个维度时间戳和对象启动关联。时间戳分析在取证领域叫timestomping对抗虽然攻击者可以伪造文件时间戳但伪造得完全一致很难。你可以把系统中所有可疑目录/tmp、/var/tmp、Web上传目录、用户目录里最近几天被创建或被修改过的文件全部列出来再和攻击时间窗口做交叉比对。如果一个系统文件的时间戳正好落在攻击发生的时间段那它就有重大嫌疑。启动链路的分析则是一条很实际的路径。通过systemctl list-unit-files查看服务状态和启用时间然后对每个新出现的systemd服务查看它的ExecStart指向的二进制文件路径、文件哈希和时间戳。如果某个服务的可执行文件位于/tmp或者/home下而且服务描述信息明显混淆那基本可以判定为恶意持久化。Windows系统上有一个很实用的技巧查看每个自启动项对应的可执行文件路径和签名信息。攻击者经常把恶意程序放在%APPDATA%、%TEMP%等非常规路径下而且文件名会伪装成“winupdate.exe”这类看似正常的名字。面对这类情况一定要把文件名和路径结合起来看再配合文件数字签名检查能拦下绝大多数伪装。6.3 高对抗场景下的rootkit排查再往上走一层如果攻击者使用了rootkit技术常规的文件和进程排查都会失效。rootkit的常见特征是在用户态或内核态拦截系统调用把自身相关的进程、文件、网络连接从查询结果中隐藏。排查rootkit的思路是交叉验证。比如用ls命令查看某个目录时看不到什么可疑文件但直接用取证工具解析磁盘镜像的目录项却能发现这个目录下面有多余的文件或者用ps看不到某个进程但netstat显示某个未知端口正在监听而sysctl查询不到对应该端口的进程PID。对于已知rootkit特征可以用工具检测比如Linux下的chkrootkit、rkhunter以及专门的主机入侵检测系统。但这些工具依赖特征库对新型rootkit效果有限。更可靠的方式还是把整块磁盘镜像和内存镜像拿走在隔离环境中进行细致的二进制分析和内核模块逆向。这里要特别提醒一点一旦确认服务器存在内核级rootkit这台机器的可信度就完全丧失了。在这个前提下继续在这台机器上收集“它自己报告给你的信息”都没有意义因为所有系统调用都可能在撒谎。此时的重点不再是修复这台机器而是把它当作一个证据源并在可信的备用硬件上重建业务环境。对系统进行重装或从备份恢复之前务必先完成全部证据保全流程。7. 实战中容易翻车的几个细节最后这部分我把这些年做服务器取证踩过的坑、栽过的跟头挑几个典型的写出来。每一件都算不上技术难题但都是现实中真实发生过且足以影响结论的“小事”。7.1 取证介质本身不干净证据直接作废第一次独立出外勤接服务器取证任务时我拿自己的笔记本插上服务器就开始采集采集完直接在笔记本上分析。直到后来补做记录时才发现我这台笔记本上当时运行着微信、浏览器、开发环境各种进程都在联网。理论上这些进程可能对采集到的数据进行过读写完全无法满足证据链的干净性要求。正确的做法是准备一台专门的取证工作站系统纯净所有分析工具经过哈希校验和版本记录平时不连接业务网络不安装不明软件。外出时带一套只读U盘工具包所有采集动作从只读介质发起。记录保存介质也必须是新的或者经过完全擦拭的避免旧数据残留造成交叉污染。7.2 中文日志编码问题有一回接手一台运行了七八年的老业务服务器日志分析刚开始就卡住了——grep中文乱码日志里凡是包含中文的请求全显示成“锟斤拷”。原因很简单这台服务器上的Web日志用的是GBK编码而我的分析环境默认UTF-8。遇到这种情况不要急着改系统区域设置正确处理方式是在分析阶段做编码转换# 查看日志文件编码 file access.log # 将GBK编码日志转换为UTF-8副本再分析 iconv -f GBK -t UTF-8 access.log access_utf8.log所有转换操作都在副本上进行原始日志文件保持不动。这条经验看着很小实际工作中碰到老旧Windows服务器、部分国产Linux发行版服务器时非常常见。处理不好轻则浪费时间重则把正常的中文业务请求当成异常特征误判整个分析方向。7.3 服务器时间不准时间线全乱另一件让我印象深刻的事是在一次跨多台服务器的取证中两台服务器的系统时间居然差了整整1小时47分钟。原因是其中一台服务器的CMOS电池没电了。如果没发现这个问题直接按日志时间排序做时间线重建攻击路径就会被拼接成完全错误的样子。所以每到一个现场第一件事就是把当前时间和NTP标准时间对比记录下偏差值。如果服务器本身就是NTP客户端还需要检查它最近一次同步成功是什么时候。只有把所有相关服务器的时间基准统一之后日志分析才能成立。这个核对过程要写进最终报告作为时间线可信度的依据。7.4 证据保管链记录最后说说证据保管链的问题。取证人员在现场采集到的每一个文件、每一块镜像、每一个U盘都应当有完整的保管记录。记录内容至少包括证据编号、名称、来源设备、采集时间和人员、移交时间和接收人员、存放位置、访问记录、拷贝记录。这不是为了应付审核而是自我保护。案件过了几个月甚至几年之后对方律师质证的时候会问“你手里这块移动硬盘怎么证明里面内容从采集那天到现在没被动过”如果拿不出一份完整、连续、签名的保管链记录再完整的数据也可能失去证据资格。我现在的外出标准流程是准备一个证据封套采集完的介质当面贴上标签写上编号和日期放入封套并用封条封口需要运输时由指定人员签字交接。这个流程看起来老派但确实是电子取证这行最可靠的护身符。说起来做了这些年服务器取证最大的体会反而和“技术”无关。设备再好工具再新如果进场时不尊重流程、操作时不留下记录、分析时不保持怀疑拿到手的“证据”也只是一堆随时会被推翻的数据。服务器确定是相对程式化的工作难就难在每个环节都要经得起时间、逻辑和法律的推敲。这大概也是电子取证这个领域最迷人的地方——它要求你在技术上做侦探在程序上做律师在细节上做匠人。