Debian服务器安全之安装chkrootkit定期检查后门

chkrootkit 这个工具名字本身就透露了它的用途——Check Rootkit。在 Debian 服务器维护中，很多人以为装个防火墙、改个 SSH 端口就万事大吉，但 rootkit 这类工具恰恰能绕过常规的安全检测。rootkit 一旦植入成功，它会替换系统命令、隐藏进程、隐藏网络连接，甚至篡改内核模块，让你在服务器上执行 ls、ps、netstat 这类基础命令时根本看不到攻击者的痕迹。chkrootkit 就是专门用来揪出这些隐藏威胁的轻量级工具，它通过一系列脚本检查系统中是否存在已知 rootkit 的签名特征。

安装 chkrootkit 本身很简单，Debian 仓库里就有现成的包。登录服务器后执行 apt update 然后 apt install chkrootkit -y，几秒钟就能装好。但真正关键的不是安装这一步，而是装完之后怎么用、怎么读懂它的输出、怎么把它变成定期自动运行的检查机制。很多人装完跑一次，看到一堆输出就慌了，或者看到全是 not infected 就觉得没事了，这两种反应都不够。

安装完成后，直接执行 chkrootkit 命令就能启动扫描。它会逐个检查几十个已知 rootkit 的特征，包括 lrk3、t0rn、ambient 这些经典变种，还会检查网络接口是否处于混杂模式、日志文件是否被篡改、关键系统二进制文件是否被替换。扫描过程会输出大量信息，每一行都值得认真看。如果出现 INFECTED 字样，那就说明高度疑似被植入，需要立刻断网排查。如果出现 not found 或者 not infected，表示该项检查通过。还有一些输出是 warning 或者 nothing deleted，这类提示需要结合实际情况判断，不一定是安全问题。

chkrootkit 的输出分为几个主要类别。第一类是检查系统命令是否被替换，它会对比 ls、ps、top、netstat 等命令的校验和，如果发现异常就会报警。第二类是检查特定 rootkit 留下的文件和目录，比如 /dev/.init、/usr/lib/.fx 这类隐藏目录。第三类是检查网络层面的异常，比如网卡是否被设置为混杂模式，这通常是嗅探工具在运行。第四类是检查内核模块是否被篡改，这部分需要 root 权限才能完整执行。

有个常见的误区是看到 checking "ifconfig'... 后面出现 eth0 is not promisc 就以为网卡有问题，实际上 not promisc 是正常的，表示网卡没有处于混杂模式。如果显示 promiscuous mode enabled，那才需要高度警惕。另外 checking "bindshell'... 这一项如果显示 INFECTED，说明系统上可能存在绑定 shell 的后门端口，需要立即用 netstat -tunlp 排查异常监听端口。

chkrootkit 还有一个容易被忽略的功能是检查 wtmp 和 lastlog 日志文件是否被篡改。攻击者入侵后通常会清除自己的登录记录，chkrootkit 会检测这些日志文件的时间戳和内容是否异常。如果发现日志文件被清空或者时间戳对不上，即使没有检测到已知 rootkit，也应该引起重视。

手动跑一次 chkrootkit 只能确认当前时刻的状态，rootkit 可能在几分钟后就被植入。所以必须设置定期自动检查，让系统每天甚至每小时跑一次扫描，并把结果通过邮件发送给管理员。Debian 安装 chkrootkit 包时会自动在 /etc/cron.daily/ 目录下放置一个脚本，但这个默认配置需要调整才能正常工作。

首先检查 /etc/chkrootkit.conf 文件，这是 chkrootkit 的主配置文件。里面可以设置 RUN_DAILY="true" 来启用每日自动扫描，设置 RUN_DAILY_OPTS 来指定扫描参数，比如 -q 参数可以让输出更精简，只显示异常项。DIFF_MODE="true" 这个选项非常实用，开启后 chkrootkit 只会发送与前一次扫描结果有差异的内容，避免每天收到重复的正常报告。

邮件通知是关键。在 /etc/chkrootkit.conf 里找到 MAILTO 这一行，把 root 改成你的实际邮箱地址。但光改这个还不够，服务器必须能发送邮件。Debian 上可以安装 mailutils 和 postfix 或者 msmtp 来配置邮件发送。如果不想搭建完整邮件系统，用 msmtp 配合外部 SMTP 服务器是最轻量的方案。安装后配置 /etc/msmtprc，填入发件服务器信息，然后在 chkrootkit 的 cron 脚本里确保邮件发送路径正确。

# 安装邮件发送工具
apt install msmtp msmtp-mta mailutils -y

# 配置 msmtp，编辑 /etc/msmtprc
# 内容示例：
defaults
auth           on
tls            on
tls_trust_file /etc/ssl/certs/ca-certificates.crt
account        default
host           smtp.example.com
port           587
from           server@example.com
user           server@example.com
password       yourpassword

配置完成后，可以手动执行 /etc/cron.daily/chkrootkit 脚本来测试是否能正常发送邮件。如果收不到邮件，检查 /var/log/syslog 里的 msmtp 相关日志，通常能定位到问题。另外要注意，chkrootkit 的 cron 脚本默认只在检测到异常时才发邮件，如果一切正常就不会发。如果想每天收到确认报告，需要在配置里调整相关参数。

chkrootkit 虽然经典，但它的检测能力集中在已知 rootkit 的签名匹配上，对新型变种或者定制化的后门可能漏报。rkhunter 是另一个同类型的工具，检测维度更广，包括系统文件属性对比、隐藏进程检测、端口监听异常等。两个工具一起用，可以互相补充。Debian 上安装 rkhunter 同样简单，apt install rkhunter -y，装完后先执行 rkhunter --propupd 更新系统文件属性数据库，然后运行 rkhunter --check 做全盘扫描。

rkhunter 的配置文件在 /etc/rkhunter.conf，里面可以设置邮件通知、白名单规则、检测项开关等。和 chkrootkit 一样，rkhunter 也支持 cron 定期运行，安装后会自动添加 /etc/cron.daily/rkhunter 脚本。两个工具的扫描时间可以错开，比如 chkrootkit 在凌晨 2 点跑，rkhunter 在凌晨 4 点跑，这样能覆盖更多时间窗口。

chkrootkit 的核心是一系列 shell 脚本和 C 语言编写的小程序。它的检测逻辑并不复杂，主要依赖字符串匹配和文件特征比对。比如检测 t0rn rootkit 时，它会检查 /usr/sbin/nscd 文件是否包含特定字符串，检查 /dev/.lib/lib 目录是否存在。这种检测方式的优点是速度快、资源占用低，缺点是对未知 rootkit 无能为力，而且攻击者如果知道 chkrootkit 的检测逻辑，可以刻意绕过。

chkrootkit 还有一个容易被误读的检测项是 checking "sniffer'...，它会检查 /proc/net/packet 来查看是否有进程在监听原始套接字。但正常服务比如 DHCP 客户端也会使用原始套接字，所以这一项出现警告不一定就是嗅探器在运行。需要结合 ps 和 lsof 命令进一步排查具体是哪个进程在使用原始套接字。

# 查看哪些进程在使用原始套接字
lsof -i -n -P | grep raw

# 检查网卡混杂模式
ip link show | grep PROMISC

对于 checking "chkutmp'... 这一项，它检查的是 utmp 和 wtmp 日志文件中的异常条目。如果显示 The tty of the following user process(es) were not found in /var/run/utmp，说明有进程的终端信息在 utmp 中找不到对应记录，可能是后台运行的隐藏进程，也可能是正常的守护进程。这类输出需要逐个排查，不能一概而论。

chkrootkit 只能检测已知 rootkit，对于零日漏洞植入的定制后门基本无效。而且 rootkit 技术也在进化，从用户态 rootkit 发展到内核态 rootkit，甚至硬件级 rootkit，chkrootkit 这类工具能覆盖的范围越来越有限。所以它应该作为安全体系中的一个环节，而不是全部。配合文件完整性监控工具比如 aide 或者 tripwire，可以在系统文件被篡改的第一时间发现异常。再配合审计框架 auditd，记录关键系统调用，能追踪到入侵者的操作轨迹。

aide 的用法值得单独说一下。在 Debian 上安装 aide 后，先执行 aideinit 初始化数据库，这会在 /var/lib/aide/ 目录下生成基准数据库。然后设置 cron 定期运行 aide.wrapper 脚本，它会对比当前文件状态和基准数据库的差异。如果 chkrootkit 发现某个系统命令被替换，aide 能告诉你这个文件具体什么时候被改过、改了什么属性。两个工具的输出可以互相印证。

# 初始化 aide 数据库
aideinit

# 手动运行检查
aide.wrapper --check

# 更新数据库（确认系统干净后执行）
aide.wrapper --update

当 chkrootkit 报告 INFECTED 时，第一反应不应该是恐慌，而是先确认是不是误报。chkrootkit 的误报率不算低，尤其是在系统更新后，某些系统文件的校验和变化会触发报警。排查步骤应该是：先把报警信息完整记录下来，然后用 debsums 或者 dpkg -V 验证相关文件的完整性。如果文件确实被篡改，dpkg -V 会显示校验和不匹配。接着检查相关进程、网络连接、计划任务、启动项，看有没有其他异常迹象。

如果确认是真实入侵，服务器应该立即断网但不断电，因为内存中的证据断电后会丢失。然后通过带外管理或者物理控制台登录，用静态编译的 busybox 等工具做取证分析，避免使用系统自带的命令，因为它们可能已经被替换。chkrootkit 本身也有静态编译版本，可以在安全环境下编译好传到服务器上使用，避免依赖被篡改的动态库。

安全运维不是一次性的工作，chkrootkit 的定期检查应该成为服务器上线后的标准配置。在服务器初始部署阶段，就应该把 chkrootkit、rkhunter、aide 这些工具装好、配置好、测试好邮件通知。然后把这些步骤写成文档或者自动化脚本，确保每台新服务器都有一致的安全基线。定期检查的周期可以根据服务器的重要性和暴露面来调整，核心服务器可以设置为每小时检查一次，边缘服务器每天检查一次即可。

另外，chkrootkit 本身也需要保持更新。Debian 仓库里的版本通常比上游滞后，如果对安全性要求极高，可以从 chkrootkit 官网下载最新源码自行编译。新版本会增加对新型 rootkit 的检测规则，保持更新才能跟上威胁的演变。可以用 apt list --upgradable | grep chkrootkit 来检查是否有可用更新，然后通过 unattended-upgrades 配置自动安全更新。

最后要强调的是，chkrootkit 检测的是入侵后的痕迹，属于事后发现手段。真正的安全防线应该前移，包括最小化安装、最小权限原则、及时打补丁、关闭不必要的服务、配置严格的防火墙规则、使用密钥认证替代密码登录、限制 SSH 访问来源 IP 等。chkrootkit 是最后一道保险，不能替代前面的安全措施。把基础安全做好，chkrootkit 报警的概率自然会大幅降低，偶尔报警时也能更有把握地判断是不是误报。