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

rpm -va 和 debsums -c 是快速筛查系统文件是否被篡改的首选方法：前者在rpm系系统中校验所有已安装包的文件大小、哈希、时间戳等元数据，后者在debian系中比对预存校验和；输出异常项即提示潜在入侵。

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 上，先装 debsums：sudo apt install debsums，再跑 sudo debsums -c。没输出代表一切正常；有输出则列出所有校验失败或缺失的文件路径。

注意：RPM 的 -Va 默认检查所有已安装包，耗时较长，可加 --filetype binary 只查可执行文件
debsums -c 不检查未启用校验和的包（有些包默认不带 checksum），可用 debsums -a 强制全扫，但更慢
别信 which ls 或 ls --version 的结果——攻击者很可能已经替换了 which 和 ls 本身

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

当怀疑 /usr/bin 下多个命令已被污染（比如 ls、ps、netstat），就不能依赖它们自身来排查——你调用的 ls 可能早就不是原来的 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 文件。

Zynq Linux Hardware Debug

Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。

下载

别用 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 是为长期盯防设计的——它不依赖包管理器，而是自己建一套本地可信快照，后续所有变更都能被捕捉。

安装后立即初始化：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 里的内存文件，或者直接 patch 过的 in-memory 二进制——这些都不会出现在 rpm -Va 输出里，也绕过了 AIDE 的初始扫描范围。