Linux 内核提权漏洞实战排查与 eBPF 监控方案

核心要点（TL;DR）

内核提权漏洞多源于未修补的 CVE 与不当 capability 授权，先核查版本再谈防护。
SUID 文件、可写内核模块与宽松 sudo 配置是本地提权最常见的三个入口。
eBPF 可在内核态捕获 setuid、commit_creds 等行为，实现低开销提权告警。
容器环境需同时检查 privileged、hostPID 与挂载宿主机目录三类高危配置。

很多运维第一次意识到内核提权漏洞的严重性，往往是在主机已经失守之后：一个低权限 Web 账户突然拿到 root，随后被植入挖矿或后门。本地提权不像远程漏洞那样显眼，它依赖的是未修补的内核版本、过宽的 SUID 权限、错误的 capability 授权这些长期存在的配置债。本文面向需要动手排查的运维与站长，给出一套从版本核查到 eBPF 实时监控的可执行方案，帮你把提权检测从「事后看日志」变成「事中能告警」。

一、内核提权漏洞为什么难防

内核提权漏洞的本质是内核态代码存在缺陷，使普通进程能越权修改凭证结构。常见成因有三类：内核版本长期未更新导致公开 CVE 未修补；内核模块加载权限过宽；以及 namespace、io_uring 等新子系统引入的攻击面。

难点在于：这类漏洞利用后往往不留明显日志，攻击者通过 commit_creds 直接改写进程凭证，传统基于文件完整性的检测很难发现。因此排查要同时覆盖「版本是否安全」和「行为是否异常」两条线。

二、第一步：核查内核版本与补丁状态

先确认你跑的是什么内核，再对照发行版安全公告判断风险。

uname -r
cat /etc/os-release
# Debian/Ubuntu
apt list --upgradable 2>/dev/null | grep -i linux-image
# RHEL/CentOS
yum check-update kernel 2>/dev/null || dnf check-update kernel

检查清单：

内核版本是否与发行版当前安全版本一致，是否存在被标记为 Security 的待更新包；
是否启用了自动安全更新（unattended-upgrades 或 dnf-automatic）；
是否存在自行编译、来源不明的内核或第三方 DKMS 模块。

注意：不要凭记忆判断某个 CVE 是否影响自己，务必以发行版公告中的受影响版本区间为准。

三、第二步：排查本地提权的三类配置入口

相比内核漏洞，配置问题被利用的概率更高。按下面三条逐一核查。

1. SUID/SGID 文件

find / -xdev -perm -4000 -type f -ls 2>/dev/null
find / -xdev -perm -2000 -type f -ls 2>/dev/null

对照白名单核对，重点看 /tmp、/home、/opt 下出现的 SUID 文件，这类几乎可以判定为异常。

2. sudo 与 capability 授权

sudo -l
cat /etc/sudoers | grep -v '^#'
getcap -r / 2>/dev/null

警惕 NOPASSWD: ALL、可执行的 vi/find/tar 等可逃逸命令，以及 cap_sys_admin、cap_setuid 被授予普通二进制的情况。

3. 可写路径与定时任务

ls -la /etc/cron* /var/spool/cron 2>/dev/null
find / -xdev -writable -type d 2>/dev/null | grep -Ev '^/(proc|sys|tmp|var/tmp)'

容器环境补充检查

风险项	检查方式	处置
privileged 模式	`docker inspect --format '{{.HostConfig.Privileged}}' 容器名`	改为最小权限
hostPID/hostNetwork	检查 HostConfig 字段	非必要不开启
挂载 docker.sock	`docker inspect --format '{{.Mounts}}'`	移除挂载

四、第三步：用 eBPF 监控提权行为

配置排查是静态的，eBPF 补的是动态检测。核心思路是挂载 kprobe 到凭证变更函数，捕获「谁在什么时候把权限提上去了」。

以 bpftrace 快速验证为例：

# 监控 commit_creds 调用，打印进程与新旧 UID
bpftrace -e 'kprobe:commit_creds {
  printf("%s pid=%d uid=%d->%d\n", comm, pid, uid, ((struct cred *)arg0)->uid.val);
}'

生产环境建议固化为常驻程序，关注以下事件源：

commit_creds：凭证变更，提权成功的直接信号；
sys_setuid/sys_setresuid：非预期账户切换；
security_file_open：敏感文件如 /etc/shadow 的异常读取；
init_module/finit_module：内核模块加载，rootkit 常见入口。

告警规则建议：非白名单进程从非 root 变为 root、非包管理进程加载模块、短时间内多次失败提权尝试。落地时可用 AegisX 的主机入侵检测能力对接这类内核事件，把 eBPF 采集到的提权行为直接纳入统一告警与响应流程，减少自建管道的维护成本。

五、上线检查清单与行动建议

确认内核与安全补丁状态，开启自动安全更新；
导出 SUID/SGID 与 capability 基线，纳入每周差异比对；
收紧 sudoers，禁用可逃逸命令的 NOPASSWD 授权；
容器统一禁用 privileged，启用 seccomp 与只读根文件系统；
部署 eBPF 提权监控，配置告警通道并演练一次响应流程；
为关键主机保留进程树与文件哈希快照，便于事后取证。

提权防护没有一劳永逸的开关，只有「补丁及时、权限最小、行为可观测」三件事持续做。建议今天就从 uname -r 和 SUID 清单开始，先把基线摸清楚，再逐步补齐监控。

常见问题（FAQ）

怎么快速判断我的服务器是否存在内核提权风险？

先执行 uname -r 确认内核版本，再对照发行版官方安全公告核对是否有未修复的高危 CVE。同时检查 SUID 文件、sudo 配置与 capability 授权，这三类配置问题往往比内核漏洞更容易被本地用户利用。建议把版本核查与配置巡检固化为每周任务。

eBPF 监控提权行为会不会影响服务器性能？

正常配置下开销很低。eBPF 程序运行在内核态，通过 kprobe 挂载到 commit_creds 等关键函数，只在事件触发时向用户态推送数据，不做全量日志采集。实践中建议只挂载必要探针、设置环形缓冲区上限，并用 bpftool 观察丢包计数，通常 CPU 占用可控制在个位数百分比。

普通用户没有 root 权限也能提权吗？

可以。提权漏洞的利用前提通常只是一个普通 shell。攻击者会寻找带 SUID 位的程序、配置错误的 sudo 规则、可写的 cron 任务或存在漏洞的内核版本，从普通用户提升到 root。因此不能假设低权限账户无害，应把每个可登录账户都视为潜在攻击起点。

容器里的提权风险要不要单独处理？

要。容器共享宿主机内核，内核提权漏洞可直接导致容器逃逸。需重点检查 privileged 模式、hostPID/hostNetwork、挂载 docker.sock 或宿主机根目录等配置，并启用 seccomp 与 AppArmor。容器内也应避免以 root 运行，配合只读根文件系统降低影响面。

发现可疑提权行为后应该怎么处置？

先保留证据再动手：导出 eBPF 告警记录、进程树与相关文件哈希，避免直接 kill 破坏现场。随后隔离主机网络、吊销可疑账户与密钥，核查是否有持久化项如 cron、systemd 服务与 SSH 公钥。最后修补对应漏洞并复盘监控盲区，必要时重装系统。

资讯中心