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 初始扫描范围。因此，没有万能方法，组合使用、交叉验证才是正道。