SUID 文件排查是什么
SUID 位让程序在执行时以文件所有者的身份运行，SGID 则让进程继承文件所属组。系统里需要它们的场景不多（例如修改口令、使用 ping），但一旦普通用户能执行一个属主为 root 的 SUID 程序，就等于多了一条提权路径。攻击者植入 SUID 后门后，往往还会删除原始文件或改名混淆，所以排查方法不是「看有没有」，而是「找出全部，再逐个解释它为什么存在」。
基本信息
| 查找命令 | find 加 -perm -4000（SUID）与 -perm -2000（SGID） |
|---|---|
| 常见正常项 | passwd、chsh、sudo、ping、mount、umount、su、newgrp、pkexec |
| 可疑特征 | 位于 /tmp、/home、/var/tmp 等可写目录，属主为 root |
| 归属核对 | RPM 系用 rpm -qf，Debian 系用 dpkg -S 反查文件属于哪个包 |
| 时间线索 | find 结合 -newermt 找最近新增的 SUID 文件 |
| 权限要求 | 全盘查找需 root，否则会因权限不足产生大量报错 |
典型使用场景
- 确认攻击者是否留下 SUID 提权后门
- 处理提权类事件后复查全盘，防止遗漏第二个后门
- 做基线时留存 SUID 文件清单，供日后差异比对
- 合规检查时说明每个 SUID 文件的用途
- 排查业务部署中误设的 SUID 权限
全盘找 SUID 并核对包归属
全盘找 SUID 并核对包归属
sudo find / -xdev -perm -4000 -type f -exec ls -l {} + 2>/dev/null | head -n 40 # SUID
sudo find / -xdev -perm -2000 -type f -exec ls -l {} + 2>/dev/null | head -n 40 # SGID
sudo find /tmp /home /var/tmp -perm -4000 -type f -exec ls -l {} + 2>/dev/null # 可写目录重点看
sudo rpm -qf /usr/bin/passwd 2>/dev/null; sudo dpkg -S /usr/bin/passwd 2>/dev/null # 包归属
sudo find / -xdev -perm -4000 -type f -newermt '2026-09-01' -exec ls -l {} + 2>/dev/null | head # 近期新增
getcap -r / 2>/dev/null | head -n 20 # 顺带看 capabilities判定读法
| 现象 | 含义 | 处理建议 |
|---|---|---|
| 属主 root 且位于系统目录 | 多为包自带 | 用 rpm -qf 或 dpkg -S 确认归属后放行 |
| 位于 /tmp 或家目录 | 几乎可判定异常 | 先复制样本并记录属性，再移除 SUID 位或删除文件 |
| 文件时间在入侵窗口内 | 新植入的可执行文件 | 结合包归属判断，无归属即视为可疑 |
| SGID 且属组为高权限组 | 可读取关键组的文件 | 核对用途，非必要则移除 |
| capabilities 赋予高权限 | SUID 的替代方案 | 与 SUID 一并排查，两者都可能是提权路径 |
脚本文件的 SUID 位通常不起作用：Linux 内核会忽略解释器脚本上的 SUID，实际生效的是被调用的解释器权限。所以看到带 SUID 的脚本，重点应放在它所执行的程序与调用链上。
先建基线再谈异常：容器镜像、自研部署与第三方软件都可能引入额外的 SUID 文件。日常留存一份清单与哈希，出事时对比新增项，比逐个人工判断效率高得多。