在Ubuntu系统安全审计中，su和sudo产生的日志记录机制完全不同，这直接决定了它们在安全取证时的价值高低。简单说：sudo会在/var/log/auth.log中记录完整的命令执行信息（谁、什么时候、执行了什么命令），而su切换用户后的操作几乎是"黑箱"，系统默认不记录具体执行了哪些命令。这意味着一旦发生内部威胁或权限滥用，sudo日志能帮你还原攻击链路，su则很难提供有效证据。下面从日志机制、配置差异、取证场景三个维度把这个问题彻底讲透。

一、sudo的审计日志机制：天然的取证利器

sudo的设计理念就是"可追溯"。当一个用户通过sudo执行命令时，Ubuntu默认会在/var/log/auth.log中写入一条完整记录。这条记录包含：时间戳、发起者用户名、目标用户（通常是root）、执行的完整命令、终端信息（TTY）。

你可以直接用以下命令查看sudo日志：

grep sudo /var/log/auth.log

典型的日志条目长这样：

Oct 15 14:23:01 ubuntu-server sudo: admin : TTY=pts/0 ; PWD=/home/admin ; USER=root ; COMMAND=/usr/bin/apt update

这条日志告诉你：用户admin在14:23:01通过pts/0终端，以root身份执行了apt update。每个字段都有取证意义。更关键的是，sudo支持I/O日志记录功能，通过配置sudoers文件可以把命令的输入输出也记录下来：

Defaults log_output
Defaults iolog_dir=/var/log/sudo-io

开启后，每个sudo命令的完整终端会话都会被保存到/var/log/sudo-io目录下，以会话ID命名的文件中。这对于取证来说是核弹级的能力——你能看到攻击者在root权限下到底敲了什么、看到了什么输出。

二、su的审计日志机制：先天不足的记录方式

su命令的日志记录要弱得多。Ubuntu默认情况下，su本身不会在auth.log中记录"用户A通过su切换到了用户B"这种信息。你在auth.log里看到的通常只是su命令被调用时的PAM认证记录，而且往往只有成功或失败的提示，不包含后续操作。

查看su相关日志的方式：

grep "su" /var/log/auth.log

你可能看到类似这样的条目：

Oct 15 14:30:00 ubuntu-server su[12345]: Successful su for root by admin

注意，这条日志只告诉你"admin成功切换到了root"，之后admin以root身份做了什么，系统完全没有记录。没有命令记录、没有时间戳细分、没有输出捕获。这就是su在取证中最大的短板。

要弥补这个缺陷，需要借助PAM模块和进程审计工具。一种常见做法是通过pam_exec模块在su成功时触发自定义脚本记录信息，但这只能记录"切换事件"，仍然无法追踪切换后的具体操作。

三、从进程审计角度弥补su的取证空白

既然su本身不记录后续操作，那就需要在系统层面加一层监控。Linux审计框架（auditd）是解决这个问题的核心工具。通过配置auditd规则，可以监控所有用户的命令执行，不管他是通过sudo还是su获得的权限。

安装和启动auditd：

sudo apt install auditd
sudo systemctl enable auditd
sudo systemctl start auditd

添加监控规则，记录所有用户执行的命令：

auditctl -w /usr/bin/su -p x -k user_switch
auditctl -w /usr/bin/sudo -p x -k priv_escalation
auditctl -a always,exit -F arch=b64 -S execve -k all_commands

第一条规则监控su命令本身的调用，第二条监控sudo，第三条则是全局监控所有命令执行。这样一来，不管攻击者用su还是sudo提权，他之后执行的每一条命令都会被记录在/var/log/audit/audit.log中。

用ausearch查看审计记录：

ausearch -k all_commands -ts recent

这才是真正完整的取证链路。单靠su或sudo自身的日志都不够，必须配合auditd才能实现全覆盖。

四、实际取证场景中的差异对比

场景一：内部人员通过sudo删除关键文件。你在auth.log中可以直接看到：某用户在某时间通过sudo执行了rm -rf /data/backup。命令、时间、用户一清二楚，甚至配合I/O日志能看到他有没有犹豫、有没有先ls查看。这是直接证据。

场景二：内部人员通过su切换到root后删除文件。auth.log只显示"Successful su for root by userX"，之后一片空白。你只能通过auditd的全局命令监控或者事后文件系统取证（比如ext4的日志、文件时间戳分析）来间接推断。难度大得多，证据链也更脆弱。

场景三：攻击者获取了某个低权限账户，先su到root再横向移动。如果没有auditd，你可能只知道"这个账户曾经登录过"，但无法还原他su之后做了什么。而如果他用的是sudo（假设该账户在sudoers里），你至少能看到他sudo了哪些命令。

从合规角度看，等保2.0和ISO 27001都要求对特权操作进行审计。单纯依赖su是无法满足合规要求的，必须配合集中日志和审计框架。

五、最佳实践：构建完整的提权审计体系

第一，限制su的使用范围。在/etc/pam.d/su中配置，只允许特定组（如wheel或admin）使用su，并确保每次调用都触发PAM记录。同时考虑直接禁用su，强制所有提权操作走sudo。

auth required pam_wheel.so group=admin

第二，强制所有管理员使用sudo而非su。修改sudoers配置要求输入密码并记录所有命令：

Defaults env_reset
Defaults mail_badpass
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
Defaults log_output
Defaults iolog_dir=/var/log/sudo-io
root ALL=(ALL:ALL) ALL
%admin ALL=(ALL) ALL

第三，部署auditd并配置持久化规则。将规则写入/etc/audit/rules.d/目录下的文件，确保重启后依然生效：

-w /usr/bin/su -p x -k privilege_escalation
-w /usr/bin/sudo -p x -k privilege_escalation
-a always,exit -F arch=b64 -S execve -k command_log
-w /etc/passwd -p wa -k identity_change
-w /etc/shadow -p wa -k identity_change

第四，集中收集日志。将auth.log和audit.log通过rsyslog或filebeat转发到远程日志服务器，防止攻击者本地清除证据。这一步很多人忽略，但在实际入侵中，攻击者第一件事往往就是清理本地日志。

六、总结：选对工具，证据才站得住脚

回到核心问题：su和sudo在审计日志上的差异是本质性的。sudo天生具备完整的命令级审计能力，是取证的首选提权方式；su则是一个"只记录门、不记录屋内行为"的工具。在安全要求高的环境中，应该从制度层面减少su的使用，全面拥抱sudo+auditd的组合。任何只依赖su做权限管理的Ubuntu服务器，在发生安全事件后都将面临取证困难的局面。把审计体系建好，不是等出事了再补救，而是现在就该做的基本功。