你的服务器被人动过。配置被改了，文件被删了，但没人承认。你翻日志，看到一堆时间戳和IP，但理不清顺序。你不知道谁先做了什么，后做了什么——日志是散的，事件是连的。
操作审计就是把这些碎片拼成一条完整的时间线。
审计日志的三大来源
操作审计需要回答三个问题：谁干的？什么时候干的？干了什么？对应的日志来源也分三类。
登录日志记录谁在什么时候连上了服务器。/var/log/auth.log（Ubuntu）或/var/log/secure（CentOS）记录SSH登录成功与失败。要排查异常登录，两条命令足够：
bash
# 最近的登录成功记录 last -n 20 # 最近的登录失败记录 lastb -n 20
last显示成功登录的历史，lastb显示失败的尝试。如果lastb里有大量来自同一IP的记录，说明有人在暴力破解。如果last里出现你从未见过的IP，说明账号可能已经泄露。
命令历史记录用户登录后执行了什么。每个用户的主目录下都有.bash_history文件，记录该用户执行过的命令。
bash
cat /home/用户名/.bash_history
但有个问题：用户可以执行history -c清空自己的历史记录，也可以直接删除.bash_history文件。只靠这个做审计，攻击者清理痕迹后你什么都看不到。
系统日志记录系统的底层事件。用户切换身份（sudo）、服务启动停止、文件访问——这些事件记录在/var/log/auth.log和/var/log/syslog中。sudo操作会留下COMMAND=记录，即使攻击者清除了.bash_history，sudo日志仍会保留。查看sudo日志的命令：
bash
grep "sudo" /var/log/auth.log | grep "COMMAND"
审计的难点：日志可能被清理
.bash_history只能看到用户做了什么，但它本身是用户可控的文件。攻击者登录后会执行history -c清空历史，或者直接rm ~/.bash_history。你查不到他执行过什么。
系统日志默认只有root可写，普通用户无法直接删除/var/log/auth.log。但攻击者如果有root权限，仍然可以清理这些日志。这就是为什么审计需要在日志产生的同时发往外部存储——一旦本地日志被清理，你至少还有一份副本。
配置日志远程转发：在/etc/rsyslog.conf中配置*.* @远程日志服务器IP:514，所有日志实时发送到另一台服务器。
用auditd做更精细的审计
如果.bash_history不可靠，需要用更底层的工具来记录命令执行。
auditd是Linux内核级别的审计系统，可以监控系统调用、文件访问、用户登录等事件。它的记录不会因为用户清空.bash_history而丢失，因为auditd在日志写入前就记录了事件。
安装并启动auditd：
bash
apt install auditd -y systemctl start auditd
监控关键文件：auditctl -w /etc/passwd -p rwxa -k passwd_changes。这条命令监控/etc/passwd文件的读写和执行操作，记录所有访问和修改该文件的行为。
监控sudo命令：auditctl -a exit,always -S execve -F uid=0 -k root_commands，记录所有root执行的命令。
审计日志分析的顺序
按时间顺序构建完整事件链。例如某台服务器配置被篡改的审计过程：
- 用
last确认异常登录时间（攻击者从哪来、什么时候进来的） - 用
lastb检查是否有大量失败记录（是否是通过暴力破解入侵的） - 用
grep查系统日志，确认这个IP在登录前后的活动模式（是否执行了可疑操作） - 用
ausearch查auditd日志，追踪后续操作（攻击者访问了哪些文件、执行了什么命令）
一个真实案例
一台服务器配置被篡改，网站首页被挂广告。通过last定位到三天前凌晨3点有一个来自陌生IP的登录记录，用户名是admin（一个长期不用的账号）。登录日志显示该账号从陌生IP连续尝试了5次才成功——密码被暴力破解。通过ausearch -k passwd_changes发现攻击者在登录后修改了/etc/passwd，添加了一个隐藏用户。清理该用户、禁用admin账号、强制所有用户使用密钥登录，问题解决。
最后一句
审计的核心不是你记录了所有日志，是你知道去哪里找答案。登录日志告诉你谁进来了，命令历史告诉你他做了什么，系统日志告诉你他有没有拿到更高权限，auditd在你需要的时候提供了更细的证据。这四层信息配合起来，你才能重建出完整的事件经过。下次服务器出事了，你不必在日志里大海捞针。按“登录→命令→系统事件”的顺序走一遍，事情的脉络自然浮现。