Linux如何检查系统是否存在被篡改的二进制文件

当系统安全出现疑云，怀疑关键二进制文件可能被动了手脚时，有几个立即可用的排查思路。别慌，咱们一步步来。

用 rpm -Va 或 debsums -c 快速筛查包管理器文件

系统自带的包管理器是排查的第一道防线。它就像一个内置的账本，记录了每个安装文件的原始哈希、权限、大小和时间戳。一旦文件被篡改，这些信息大概率就对不上了。

在 RHEL、CentOS、Rocky 这类 RPM 系系统上，直接运行 sudo rpm -Va。如果输出里出现类似 S.5.T. c /usr/bin/ls 的行，就说明该文件被改动过。这里的字母是关键：S 表示文件大小变了，5 是 SHA256 校验和不匹配，T 是时间戳异常，而最后的 c 标记它是个配置文件（配置文件通常允许修改，但也需要确认改动是否合理）。

在 Debian 或 Ubuntu 这类 Debian 系系统上，需要先安装 debsums 工具：sudo apt install debsums，然后执行 sudo debsums -c。没有输出代表一切正常；如果有输出，则会列出所有校验失败或缺失的文件路径。

这里有几个细节需要注意：RPM 的 -Va 默认会检查所有已安装的软件包，耗时可能较长，可以加上 --filetype binary 参数来只检查可执行文件。而 debsums -c 不会检查那些默认未启用校验和的软件包，如果想强制全盘扫描，可以使用 debsums -a 命令，但速度会更慢。

另外，千万别轻信 which ls 或 ls --version 这类命令的结果——如果系统已被入侵，攻击者很可能已经替换了 which 和 ls 命令本身。

绕过 PATH 污染，用绝对路径调用 sha256sum 验证关键命令

当你怀疑 /usr/bin 等路径下的多个核心命令已被污染（比如 ls、ps、netstat），就不能再依赖这些命令自身来排查了——因为你调用的 ls，可能早就不是原来的那个了。

这时，必须使用绝对路径去调用一个**极难被替换的基础工具**。最可靠的选择通常是 /usr/bin/sha256sum（由 coreutils 包提供，攻击者一般不敢动它，否则连他们自己排查起来都会很麻烦）。然后，用它来计算目标二进制文件的哈希值进行比对：

sha256sum /bin/ls
sha256sum /usr/bin/curl
sha256sum /sbin/ifconfig

拿到哈希值后，需要与官方 ISO 镜像中同版本文件的哈希进行对比（例如，从 CentOS-7-x86_64-DVD.iso 里提取出 /bin/ls 再计算一次），或者查询发行版官网发布的 SHA256SUMS 文件。

这里要提醒一点：避免使用 md5sum，因为 MD5 算法已被证明不具备抗碰撞性，攻击者可以构造出内容不同但 MD5 值相同的二进制文件。

如果连 /usr/bin/sha256sum 自身也报错或行为异常，那就说明系统污染可能已经非常深了，此时需要考虑挂载原始 ISO 进行离线恢复。

排查时，应重点盯住 /bin、/sbin、/usr/bin、/usr/sbin 这四个目录，它们是攻击者最常下手的地方。

查“幽灵二进制”：不属于任何软件包的可执行文件

攻击者经常会把后门程序丢到 /tmp、/dev/shm、/usr/local/bin 甚至用户的 ~/bin 目录下。这些路径通常不在包管理器的管辖范围内，因此 rpm -Va 或 debsums 根本不会扫描到它们。

首先，可以查看哪些正在运行的进程来源不明：使用命令 find /proc/*/exe -exec readlink {} + 2>/dev/null 列出所有运行中进程的真实路径，然后逐个检查其归属：

在 RHEL/CentOS 上：rpm -qf /path/to/binary，如果返回 file /path/to/binary is not owned by any package，就需要人工审查。

在 Debian/Ubuntu 上：dpkg -S /path/to/binary，如果提示 no path found matching pattern，同样非常可疑。

接着，可以再筛查一遍非标准路径下的可执行文件：find /usr/local/bin /opt /tmp -type f -perm /111 2>/dev/null。要特别警惕那些名字看起来像 sshd、update、watch，但却不在 /usr/bin 等标准目录下的文件。

这类“幽灵文件”往往有一些共同特征：没有符号表、体积异常小（可以用 -size -100k 参数过滤）、创建时间接近推测的入侵时间点（用 stat 命令查看 ctime 和 mtime），并且其父进程可能是 sh 或 bash 而非正常的系统服务。

用 AIDE 建立可信基线，避免每次都要手动比对

前面提到的都是临时检查手段，只能发现“已经发生”的篡改。而 AIDE 则是为长期监控设计的——它不依赖包管理器，而是自己建立一套本地的可信文件系统快照，后续所有的变更都能被捕捉到。

安装 AIDE 后，需要立即进行初始化：sudo aide --init。初始化完成后会生成一个数据库文件，通常位于 /var/lib/aide/aide.db.new.gz。需要将它重命名为 aide.db.gz 并移动到正式位置，才算完成基线的建立。

日常检查时，只需要运行 sudo aide --check，它就会报告新增、删除、权限变更、内容修改等所有异常。这里的关键在于：这个基线数据库本身必须进行离线备份（例如拷贝到 USB 设备或设置为只读挂载点），否则攻击者一旦删除了它，就等于清空了所有监控证据。

AIDE 默认会监控 /bin、/sbin、/etc 等关键路径，但可以通过配置文件 /etc/aide.conf 按需增减监控范围，比如加上 /usr/local/bin。

有两点必须注意：第一，不要把 AIDE 数据库存放在被它监控的同一块磁盘上，这是新手最容易忽略的风险点。第二，初始化操作必须在确认系统绝对干净后立刻进行；如果系统已经被控制，那么建立的基线本身就是错误的。

话说回来，真正棘手的篡改往往藏在包管理器的盲区里。比如 /usr/local/bin 下的软链接、/dev/shm 里的内存文件，或者直接对内存中的二进制进行补丁（in-memory patching）——这些操作都不会出现在 rpm -Va 的输出里，也绕过了 AIDE 的初始扫描范围。因此，没有任何一种方法是万能的，组合使用、交叉验证才是王道。