提权审计要看三处
sudo 是最常见的提权路径，审计要覆盖三件事：一是 sudoers 文件本身的变更（谁改了谁能提权），二是 sudo 的使用记录（谁在什么时候提权执行了命令），三是进程执行底账（execve 记录的命令行）。只做其中一项都不完整：sudoers 被改过而没人知道，等于控制清单已经失真；只看 sudo 日志则可能因为版本差异漏掉命令内容。排查提权事件时，三处要交叉对照。
基本信息
| 加固项 | 提权行为与配置变更审计 |
|---|---|
| 适用平台 | Linux（RHEL 系、Debian/Ubuntu，使用 sudo） |
| 权限要求 | root |
| 达标判据 | sudoers 变更与 sudo 使用均可追溯 |
| 相关文件 | /etc/sudoers、/etc/sudoers.d/、/var/log/sudo.log |
典型使用场景
- 安全事件排查中确认谁在何时获得了提权并执行了什么
- 等保“安全审计”条款取证，需要可追溯的提权记录
- 变更管控：确认 sudoers 修改都走了审批流程
- 多人共用运维账号时区分具体操作人
- 梳理权限过宽的 sudo 规则并逐步收敛
sudoers 变更监控与日志开启
sudoers 变更监控与日志开启
# 审计规则：sudoers 文件与目录的写入与属性变更都记录
# -w /etc/sudoers -p wa -k sudoers_change
# -w /etc/sudoers.d/ -p wa -k sudoers_change
# 记录 sudo 会话内容（Debian/Ubuntu 常见做法，加到 /etc/sudoers）
# Defaults logfile=/var/log/sudo.log
visudo -c # 改完必须做语法校验
ausearch -k sudoers_change --start today | head -30 # 查变更事件
grep -c '' /var/log/sudo.log 2>/dev/null # 确认会话日志确实在增长使用记录与命令底账
使用记录与命令底账
grep -E 'COMMAND=' /var/log/sudo.log 2>/dev/null | tail -20 # sudo 会话内容
grep -i 'sudo:' /var/log/secure /var/log/auth.log 2>/dev/null | tail -20 # 系统认证日志
ausearch -m EXECVE --start today | grep -i 'sudo\|su ' | head -20 # 进程执行底账
journalctl -t sudo --since today | tail -20 # systemd 系统上的取法三处记录的分工
| 记录来源 | 回答什么问题 | 局限 |
|---|---|---|
| sudoers 变更审计 | 谁改了提权配置、什么时候改的 | 只能说明配置变了，不反映具体使用 |
| sudo.log 会话日志 | 谁执行了哪些命令及其输出 | 需额外开启；并非所有版本默认生成 |
| 认证日志 | 提权成功与失败的时间点与账号 | 不含命令内容 |
| execve 底账 | 实际执行的命令行与参数 | 记录量大，需搭配关键词过滤 |
| sudo -l 输出 | 某账号当前被授予哪些权限 | 是现状快照，不含历史 |
sudo 日志里是否包含命令内容取决于版本与配置：不同发行版的默认行为并不一致，验收时应当用一次真实的 sudo 操作验证日志里有没有对应的 COMMAND 记录，而不是只看配置文件写了什么。审计规则记录的 execve 才是不可绕过的底账。
改 sudoers 前必须用 visudo 编辑并做语法校验：语法错误的 sudoers 会让 sudo 完全不可用，严重时连修复都只能靠单用户模式。同时建议把 /etc/sudoers.d/ 纳入版本管理与变更审计，避免出现“某台机器上多了一行 NOPASSWD”这类难以发现的漂移。