Debian系统上配置Tripwire关键文件的完整性检查

在Debian系统上部署Tripwire，本质上是在构建一套“文件系统指纹库”。Tripwire通过计算文件的数字签名（哈希值）并与其基准数据库进行比对，来检测文件是否被篡改、添加或删除。配置的核心难点不在于安装软件包，而在于如何精准地编写策略文件（twpol.txt），以平衡安全性与日志噪音。如果策略过于宽泛，你会被海量的日志淹没；如果过于严苛，系统正常的日志轮转或包管理器更新都会触发告警，导致“狼来了”效应。因此，本文的重点将直接切入如何定制一套适用于Debian生产环境的高性能、低误报策略。

在Debian 12/11上，直接通过apt安装即可，但默认的交互式配置界面往往会生成一个极其臃肿且不切实际的基准库。建议跳过向导，手动初始化。

sudo apt update && sudo apt install tripwire -y

安装过程中，系统会提示你创建站点密钥（site key）和本地密钥（local key）。务必记住这两个密码短语，它们是加密策略文件和数据库的核心凭证。安装完成后，不要急于初始化。默认的策略文件位于/etc/tripwire/twpol.txt，这个文件针对的是上古时代的Debian系统，直接使用会导致大量“文件未找到”的错误。我们需要先清理它。

Tripwire的核心逻辑是：只监控那些被攻破后会造成严重后果的文件，以及那些本不该发生变化却发生变化了的文件。对于Debian系统，我们应聚焦于以下四类关键资产：

1. 系统二进制文件与库： /bin, /sbin, /usr/bin, /usr/sbin, /lib 等目录。这些是rootkit最常替换的目标。

2. 系统配置文件： /etc目录，但需要排除经常变动的文件（如mtab、resolv.conf、网络接口状态文件等）。

3. 可执行脚本与守护进程： /etc/init.d, /etc/cron.* 以及systemd的服务文件目录。

4. Setuid/Setgid文件： 这是权限提升攻击的重灾区，必须严格监控其权限和内容变化。

编辑/etc/tripwire/twpol.txt，建议将原有的规则组全部注释掉，重新构建。以下是一个经过优化的策略片段示例，它直接定义了针对Debian特性的检查点：

# 定义关键系统二进制文件的严格规则
(
  rulename = "Critical System Binaries",
  severity = 100,
  recurse = true
)
{
  /bin           -> $(ReadOnly) ;
  /sbin          -> $(ReadOnly) ;
  /usr/bin       -> $(ReadOnly) ;
  /usr/sbin      -> $(ReadOnly) ;
}

# 针对Debian包管理器的豁免规则
(
  rulename = "Package Manager Exclusions",
  severity = 80
)
{
  /var/lib/dpkg/info   -> $(Dynamic) ;
  /var/cache/apt       -> $(Dynamic) ;
  /var/lib/apt/lists   -> $(Dynamic) ;
}

# 监控/etc，但排除易变文件
(
  rulename = "System Configs",
  severity = 90,
  recurse = true
)
{
  /etc                                   -> $(ReadOnly) ;
  !/etc/mtab                             ;
  !/etc/hostname                         ;
  !/etc/resolv.conf                      ;
  !/etc/adjtime                          ;
  !/etc/udev/rules.d/70-persistent-net.rules ;
  !/etc/selinux/config                   ;
}

# 严格监控权限提升相关文件
(
  rulename = "SUID/SGID Files",
  severity = 100,
  recurse = true
)
{
  /bin        -> $(ReadOnly) (recurse=1) ;
  /sbin       -> $(ReadOnly) (recurse=1) ;
  /usr/bin    -> $(ReadOnly) (recurse=1) ;
  /usr/sbin   -> $(ReadOnly) (recurse=1) ;
}

这里的$(ReadOnly)是一个预定义变量，代表文件属性不可变（包括权限、大小、修改时间、哈希值等）。$(Dynamic)则用于那些内容会变化但权限不应变化的关键目录。这种写法比默认策略清晰得多，也更容易维护。

仅仅使用ReadOnly还不够。在Debian系统中，日志文件会增长，配置文件可能被合法修改。我们需要在策略文件头部自定义变量，以实现更精细的控制。例如，针对日志目录，我们通常只关心文件是否被删除或权限是否被篡改，而不关心其内容增长：

# 自定义变量：只检查存在性、权限、inode，忽略大小和内容
LOG_PROP = +pinugsm-sacmct;

在策略中应用：

(
  rulename = "Log Files",
  severity = 50
)
{
  /var/log          -> $(LOG_PROP) ;
  !/var/log/lastlog ;
  !/var/log/wtmp    ;
}

这种配置方式避免了因日志写入而触发的海量告警，同时一旦有人试图用木马替换日志文件或删除日志以掩盖入侵痕迹，Tripwire会立即报警。

策略文件编写完成后，必须进行语法检查，否则生成的数据库可能为空或损坏。这是很多配置失败案例的根源。

sudo twadmin --create-polfile -S site.key /etc/tripwire/twpol.txt

这条命令会生成加密的策略文件/etc/tripwire/tw.pol。接下来，初始化基准数据库。强烈建议加上--init参数的同时，忽略那些在策略中定义了但系统中实际不存在的文件报错，但在首次运行时，最好先做一次测试：

sudo tripwire --init --verbose 2>&1 | tee /tmp/tw_init.log

查看日志，如果出现“No such file or directory”的错误，说明你的策略文件中包含了Debian系统上不存在的路径。返回编辑twpol.txt，将这些路径注释掉或删除，然后重新生成加密策略文件并再次初始化，直到没有致命错误为止。一个干净的基准库是后续监控的基础。

基准库建立后，运行完整性检查：

sudo tripwire --check --reconcile

输出结果直接指向被篡改的文件。Tripwire的报告非常详细，但阅读起来比较晦涩。关键在于理解标记：

- Added: 新增文件。如果是你主动添加的，更新数据库即可；如果是未知的webshell或后门，需立即处置。

- Removed: 文件被删除。可能是误操作，也可能是攻击者清理痕迹。

- Modified: 文件属性或内容改变。需要逐项核对是系统更新导致，还是恶意篡改。

为了不遗漏告警，建议将Tripwire配置为每日通过cron运行，并将报告发送到本地邮箱。在/etc/cron.daily/下创建脚本tripwire-check：

#!/bin/sh
/usr/sbin/tripwire --check --email-report --email-report-level 2

这样，只有严重级别为2以上的违规才会触发邮件，减少干扰。

很多管理员在系统更新后，面对Tripwire的几百条告警，会选择关闭服务或盲目地重新初始化数据库，这完全违背了完整性检查的初衷。正确的做法是，在每次通过apt合法更新系统后，立即更新基准库：

sudo tripwire --update -Z low -r /var/lib/tripwire/report/latest.twr

这条命令会启动交互式界面，让你逐个确认哪些变更属于合法更新，并将其合并到基准库中。务必在更新后立即执行此操作，如果拖延，攻击者可能混入其中进行篡改，而你却将其当作合法更新一并接受了。

在Debian上配置Tripwire，不能只关注软件层面。如果攻击者获得了root权限，他可以轻松修改Tripwire的二进制文件、策略文件甚至数据库，让监控形同虚设。因此，必须采取离线或只读保护措施：

1. 隔离备份： 将站点密钥、本地密钥以及初始基准库备份到U盘或只读介质中，并从系统中删除明文副本。

2. 二进制文件防篡改： 将tripwire二进制文件的哈希值记录在外部介质上，定期比对。

3. 利用文件系统属性： 对Tripwire的配置目录施加chattr +i（不可变）属性，但这会阻碍合法的更新操作。更折中的方案是使用chattr +a（仅追加），保护日志不被删除。

通过这种纵深防御的思路，Tripwire才能真正成为Debian系统安全的最后一道防线，而不是一个自欺欺人的摆设。配置完成后，你拥有的将不仅仅是一个软件，而是一套能够对系统任何细微变化进行回溯审计的完整机制。