单靠一个工具无法可靠发现后门，必须组合使用底层检查、多工具交叉验证与人工研判；所有自动化工具都可能被绕过或误报，真正有效的检查依赖对/proc、内核模块、网络连接原始数据的比对能力。
直接结论：单靠一个工具无法可靠发现后门，必须组合使用底层检查 + 多工具交叉验证 + 人工研判。所有自动化工具都可能被绕过或误报，真正有效的检查依赖对 /proc、内核模块、网络连接原始数据的比对能力。
为什么 ps 和 netstat 输出不可信
攻击者常通过 LD_PRELOAD 或直接 hook 系统调用（如 sys_getdents64、sys_kill）让 ps、ls、netstat 过滤掉特定进程或端口。例如：
-
ps aux看不到 PID 1234，但ls /proc/1234存在且可读 —— 表明该进程被用户态工具隐藏 -
netstat -tulpn不显示监听 4257 端口，但ss -tulpn显示了，且对应/proc/57704/fd/下有 socket 链接 —— 说明netstat被劫持 -
/proc/PID/cmdline内容是/bin/bash\x00，但ps显示为sshd—— 进程名被篡改
chkrootkit 和 rkhunter 的实际效用边界
这两个工具不是“查杀引擎”，而是特征匹配器，对已知 rootkit 有效，但对新型或定制化后门基本无效：
-
chkrootkit检查ps、ls等命令二进制是否被 patch，输出INFECTED仅表示文件被修改，不等于存在后门（可能是管理员手动替换） -
rkhunter --check默认只校验 /etc/passwd、/bin/ls 等固定路径，若后门放在/tmp/.X11-unix/或/dev/shm/，它根本不会扫描 - 两者都不检查内核模块是否伪造
author字段，也不解析/proc/net/tcp中的 inode 并反查归属进程
真正能暴露后门的三个原始检查点
绕过所有用户态 hook，直击内核暴露的数据接口：
- 遍历
/proc/[0-9]*/，对每个 PID 执行：
–readlink /proc/PID/exe：若返回(deleted)或指向不存在路径，立即标记
–cat /proc/PID/cmdline | tr '\0' ' '：与ps输出比对，不一致即可疑
–grep PPid /proc/PID/status：PPid 不是 1 却自称systemd，大概率伪造 - 检查
/proc/net/{tcp,tcp6,udp,udp6}：提取第 10 列（inode），再用find /proc/[0-9]*/fd/ -lname "socket:[<inode>]" 2>/dev/null</inode>反查归属进程 - 运行
lsmod后，重点看author为空或含hide、acpi、nv等仿冒词的模块；再确认cat /proc/sys/kernel/modules_disabled是否突变为1
Lynis 和 GScan 这类审计工具该怎么用
它们的价值不在“发现后门”，而在暴露系统脆弱面，间接缩小排查范围：
-
lynis audit system报出[WARNING] SSH port is default (22)或[SUGGESTION] File integrity checking not enabled，提示你该加固 SSH 并部署 AIDE -
GScan.py --port可列出所有监听端口及对应 PID，但它不验证 PID 是否真实 —— 必须手动去/proc/PID/下确认exe和cmdline - 不要依赖
debsecan或rpm -q --changelog判断某个包是否含后门：CVE 编号只代表漏洞，不代表当前二进制已被篡改
最易被忽略的是：后门往往不单独存在，而是和定时任务、服务单元、环境变量加载链耦合。比如 ~/.bashrc 里一句 nohup /tmp/.logd &，或 systemctl cat update-checker.service 中的 ExecStart=/usr/local/bin/.updater —— 这些路径本身不会被任何扫描工具默认纳入哈希校验范围。
