完整性监控有一个让人别扭的性质：它需要一个取自确知干净的系统的基准。如果服务器已经跑了三年，而入侵这个问题今天才被提出来，那么取这个基准已经太晚了——你会把现在有的东西当成正常记录下来。

但在 Debian 和 Ubuntu 上这个基准本来就存在，而且它不是你的：每一个已安装的软件包都带着自己文件的校验和。与它们比对既不需要配置也不需要事先的快照，而且在任何系统上任何时刻都能用。这个工具叫 debsums。

怎么用

sudo apt install debsums
sudo debsums -c

-c 这个标志只打印与基准不符的文件。没有它，输出就是对系统里每一个文件逐行的报告，好几万行。

这项检查要花几分钟并给磁盘带来负载，所以在跑着业务的服务器上值得降低优先级来运行：

sudo ionice -c3 nice -n19 debsums -c

怎么读结果

输出为空意味着每一个被检查的文件都与发行版所安装的一致。非空的输出需要细看，而这些发现会分成截然不同的两类。

/etc 里的配置文件。改动它们是正常工作：你改过 sshd_config、配过 nginx、加过内核参数。这类差异是预期之中的。为了让它们不碍事，有一个单独的模式：

sudo debsums -e -c

-e 只检查配置文件——偶尔用来看看你在这台机器上都改过些什么，挺方便。

可执行文件与库。/usr/bin、/usr/sbin、/bin 或 /usr/lib 里的差异，正是跑这项检查的目的所在。合理的原因是有的，但不多：排障时手动改过、打过第三方补丁、检查期间软件包正在升级。如果哪一条都对不上，那就该认真查一查了。

被替换的经典目标是 ls、ps、netstat、ss、find、sshd。被替换的版本会把要紧的那些行从自己的输出里藏掉，而此后你所做的每一项检查都不再说真话。

覆盖并不完整——这一点必须知道

通常不被提及的一个限制：并非每个软件包都附带校验和。来自这类软件包的文件根本不会被检查，也永远不会出现在报告里，无论什么情况。清单可以这样看：

sudo debsums -l

因此一份干净的 debsums 报告意味着「在被检查的那部分里一切正常」，而不是「系统没有被改动过」。对一切在软件包管理器之外安装的东西同理：从源码编译的、以二进制下载的、用开发者站点的脚本装的——debsums 按定义就不监视它们中的任何一个，而正是在那里才需要 AIDE。

定期运行

这个软件包自带一个现成的任务，在 /etc/default/debsums 里启用：

CRON_CHECK=weekly

每周一次是合理的频率：这项检查对磁盘的负载是可感的，而系统文件在两次更新之间很少变化。每天跑除了负载什么也不增加。

如果文件真的被替换了

第一冲动是重装软件包把原件找回来：

sudo apt install --reinstall coreutils

这条命令是对的，但不该作为第一个动作。系统二进制文件被替换意味着有人拿到过 root，而恢复文件并不能解决那个问题——它只是毁掉了痕迹。顺序应当反过来：先保存可疑文件的副本及其修改时间，看看同一时期还有什么变了，检查 cron 任务、SSH 密钥和用户列表。之后再恢复。

这个方法的边界也值得记住：如果系统被深度攻陷，那么 debsums 本身以及它所用的库，也可能已经和其他一切一起被替换了。从内部做的检查给不出绝对保证——那要靠从外部介质启动来做。不过对日常工作来说这已经够了：绝大多数攻击是自动化的，并没有那么精巧。

它在全局中的位置

debsums 的好处在于它什么都不需要、立刻就能用——这使它成为一台你不了解其历史的服务器上很方便的起点。它的弱点是覆盖不完整，以及对软件包之外安装的东西一无所知。「debsums 加 AIDE」这一对把两侧都补上了：系统文件用发行版现成的基准，其余的用你自己的快照。

照例，关键不在于运行它，而在于让它最新的结果连同日期摆在眼前。它是什么样子，见下面的演示。