渗透攻防实战：授权测试中排查 Linux sudo 权限边界与日志留痕

发布于4小时前4小时

背景

在授权内网渗透测试中，拿到普通 Linux 账号后，常见的下一步不是直接尝试提权，而是先核实该账号实际拥有的权限边界：sudo 是否被过度授权、规则是否允许执行可改写系统文件的程序，以及相关操作能否在日志中还原。本文以一台测试环境中的普通运维账号为例，重点放在低影响验证、证据留存和修复闭环，不执行破坏性提权操作。

问题定位

假设测试账号为 ops-audit，授权范围仅包含一台 Linux 主机。现场发现该账号可执行部分 sudo 命令，但资产清单没有记录授权依据。此时要回答三个问题：规则来自哪里、命令参数是否受限、执行痕迹是否进入系统日志。

先记录主机名、当前账号、时间和授权范围，避免把测试结果扩展到未授权资产。随后检查 sudo 的有效规则及配置来源；不要仅凭 sudoers 文件中的单一条目下结论，因为规则也可能来自 /etc/sudoers.d/。

技术分析

sudo 规则的风险不只取决于允许执行的程序，还取决于程序能否调用子进程、加载外部配置、写入敏感路径或接受可控参数。例如，允许执行带有文件编辑能力的工具，风险可能高于允许执行固定参数的只读命令。验证时应结合实际规则、程序行为和文件权限判断，不能把“sudo -l 有输出”直接等同于已获得更高权限。

另一个常见遗漏是日志链路：sudo 可能记录到 systemd journal 或传统认证日志，但集中日志平台未必采集对应文件。建议把命令执行时间、账号、规则输出和日志查询结果一并留存，必要时使用测试窗口内的低风险只读命令验证日志是否到达。

操作步骤与命令示例

以下命令用于授权主机上的只读核查。输出可能包含敏感路径和账号信息，提交报告前应按组织要求脱敏。

# 记录主机与当前身份，作为测试证据的一部分
hostname -f
id
 date -Is

# 查看当前账号的 sudo 有效授权；按提示输入当前账号密码
sudo -l

# 检查主配置及分配置中的规则文件权限与内容
sudo stat -c '%A %U:%G %n' /etc/sudoers /etc/sudoers.d/* 2>/dev/null
sudo visudo -c

# 仅筛查常见的宽泛授权写法，仍需人工结合上下文复核
sudo grep -RniE 'NOPASSWD:|ALL[[:space:]]*=|ALL[[:space:]]*$' /etc/sudoers /etc/sudoers.d 2>/dev/null

# 按发行版查询近期 sudo 留痕
sudo journalctl --since '2 hours ago' _COMM=sudo --no-pager
sudo grep -i 'sudo' /var/log/auth.log 2>/dev/null | tail -n 50
sudo grep -i 'sudo' /var/log/secure 2>/dev/null | tail -n 50

命令中 auth.log 与 secure 通常分别见于不同发行版，文件不存在不代表没有记录，应继续检查 journald 和集中日志配置。核对 sudoers 时，重点关注是否存在面向普通用户或用户组的全量授权、免密授权，以及可变参数是否造成规则范围扩大。若需要验证规则是否确实生效，只执行授权清单中明确允许且无副作用的只读命令，并与主机管理员约定测试时间。

日志留痕与证据核对

将 sudo -l 的结果与 sudo 日志按时间、账号、主机名进行对应。sudo 日志通常可提供执行用户、目标用户、终端和命令等信息；具体字段受系统版本及日志配置影响。若测试命令已执行但本机日志和集中平台均查不到，应记录为审计链路缺口，而不是继续扩大操作验证范围。

报告中建议保留：授权工单编号、测试时间段、目标主机、测试账号、有效 sudo 规则、对应日志查询结果，以及规则文件属主和权限。不要收集与测试无关的用户数据，也不要在报告中粘贴完整密钥、口令或敏感业务参数。

风险与修复建议

按最小权限原则收紧 sudoers：将全量授权拆成明确的命令路径和必要参数，避免无必要的 ALL 或 NOPASSWD。
优先使用专用管理账号或受控自动化流程，并定期复核用户组成员变化；离职、转岗账号应及时撤销授权。
sudoers 变更通过 visudo 校验，保持配置文件由 root 所有且不可被普通用户写入；分配置目录也应纳入配置管理和变更审计。
确认 sudo 相关日志被本地可靠保存并转发到集中日志平台，设置时间同步，避免主机时间偏差影响事件关联。
修复后使用原测试账号重复执行只读授权检查，确认越权规则已撤销；同时核对变更记录和日志采集状态，形成闭环。

总结

渗透测试中的权限边界验证，关键是把“账号能做什么”与“规则如何配置、行为是否可追溯”放在一起判断。通过只读枚举、规则校验和日志关联，可以在不执行破坏性操作的前提下发现 sudo 授权过宽及审计缺口，并给出可复核的修复结果。

3小时前3小时

这类授权测试建议把“规则允许什么”和“实际留下什么证据”分开核对。sudo -l 只是入口，不能仅凭出现 NOPASSWD 就判定可提权。

权限边界：先以被测账号查看完整规则，再由管理员核对配置与目标文件权限：

# 被测账号执行；可能触发认证并产生记录
id
sudo -ll

# 管理员执行
visudo -c
grep '^sudoers:' /etc/nsswitch.conf
namei -l /实际允许执行的程序路径
namei -l /该程序读取的配置或脚本路径

重点看 RunAs 是否限定用户、参数是否受约束，以及获准程序是否会加载当前用户可写的配置、插件或脚本。程序本身归 root 所有，不代表调用链安全；父目录可写、脚本引用相对路径也需要检查。若接入 SSSD/LDAP，不能只审 /etc/sudoers.d/，还要核对集中下发的规则。

日志闭环：选一条规则本来就允许、无副作用的命令验证，记录账号、时间、终端、完整参数和退出码，再由管理员对照日志：

# 使用实际测试时间窗口
journalctl _COMM=sudo --since "2026-03-01 10:00:00" \
  --until "2026-03-01 10:10:00" --no-pager

# 传统日志按发行版及日志配置检查
grep 'sudo:' /var/log/auth.log
grep 'sudo:' /var/log/secure

注意：sudo 的命令日志不等于完整操作审计。允许启动 shell、解释器或交互式工具时，默认日志通常不能还原其后续子命令。若验收要求覆盖这部分，需要另行配置并验证 I/O 日志或 auditd 执行审计，同时确认远端汇聚、留存权限和敏感输出保护。报告里建议把“规则风险、依赖文件可写性、验证结果、日志证据”逐项对应，避免只贴一张 sudo -l 截图就下结论。

登录