Ubuntu服务器日志审计中最容易忽略的往往不是日志丢失，而是日志被篡改后依然保持“表面正常”。多数运维人员习惯用tail和grep翻看/var/log/auth.log，但攻击者一旦拿到root权限，第一件事就是清理或伪造这些文本日志。所以真正有效的安全审计，必须建立在日志不可变、集中存储和异常行为基线之上，而不是单纯依赖系统默认的rsyslog输出。

先确认日志写入链路是否完整

在Ubuntu 20.04及之后的版本中，journald承担了大部分系统日志收集工作，rsyslog仍然作为兼容层存在。执行systemctl status systemd-journald和systemctl status rsyslog，确认两个服务都处于active状态。如果rsyslog没有运行，auth.log、syslog等传统文本日志将停止更新，但journald仍会保留二进制日志。很多安全事件中，攻击者会停止rsyslog服务来制造日志空窗期，所以建议同时检查journald的持久化配置。编辑/etc/systemd/journald.conf，确保Storage=persistent，这样journald日志会写入/var/log/journal目录，重启后不会丢失。

快速定位暴力破解和异常登录

auth.log中记录了大量登录尝试，但直接grep "Failed password"会得到海量噪音。更有效的做法是按来源IP聚合统计。使用以下命令可以快速找出尝试次数最多的前20个IP：

grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -nr | head -20

注意不同Ubuntu版本中IP字段位置可能略有差异，如果输出为空，先手动查看几行原始日志确认字段位置。对于暴力破解来源IP，不要只做临时封禁，应当进一步检查这些IP是否曾经成功登录过。攻击者有时会先爆破成功一个弱口令账号，再清理日志。比对/var/log/auth.log中"Accepted"记录与失败记录的时间线，如果某个IP在大量失败后突然出现成功记录，该账号应立即冻结并强制改密。

检测日志文件是否被手动篡改

文本日志的致命弱点是可被root用户直接编辑。攻击者常用sed -i删除特定时间段或特定IP的日志行。要发现这种痕迹，可以对比journald与rsyslog文本日志的记录差异。journald的二进制格式难以手工修改，而auth.log是纯文本。执行journalctl _COMM=sshd --since "2 days ago"查看sshd服务日志，再与/var/log/auth.log中同一时间段记录数对比。如果文本日志明显少于journald记录，说明auth.log被清理过。另一种方法是检查日志文件的mtime和ctime。正常日志文件mtime会随写入持续更新，但ctime只在文件元数据变化时更新。如果发现auth.log的mtime远早于当前时间，而系统仍在产生登录事件，说明写入链路可能被重定向或文件被替换。

开启auditd监控关键文件和命令

Ubuntu默认不安装auditd，但它是安全审计的核心工具。安装后配置规则监控/var/log目录、/etc/passwd、/etc/shadow、/etc/sudoers等敏感文件。以下规则可以记录任何对auth.log的写入、删除或属性修改操作：

apt install auditd
auditctl -w /var/log/auth.log -p wa -k auth_log_tamper
auditctl -w /etc/passwd -p wa -k passwd_change
auditctl -w /etc/shadow -p wa -k shadow_change

规则生效后，任何对auth.log的修改都会在/var/log/audit/audit.log中留下记录，包括修改者进程、用户和时间。即使攻击者删除了auth.log，audit.log中仍会保留删除动作的审计条目。注意auditd日志本身也可能被篡改，建议将audit日志实时转发到远程日志服务器。

用inotify实现日志实时告警

对于没有条件部署集中日志系统的小型环境，可以用inotifywait监控日志目录的异常操作。安装inotify-tools后，编写一个简单的监控脚本，当auth.log被删除、重命名或权限变更时立即发送告警：

#!/bin/bash
inotifywait -m -e delete -e move -e attrib /var/log/auth.log |
while read file event; do
    echo "ALERT: auth.log event: $event at $(date)" | mail -s "Log Tamper Alert" admin@example.com
done

这个方案虽然简陋，但能捕捉到攻击者清理日志的瞬间动作。更推荐的做法是将inotify事件写入系统日志并触发告警系统，避免邮件通知被拦截。

集中日志与远程备份

单机日志无论怎么保护，只要root权限沦陷，攻击者总能找到方法清除。真正可靠的方案是将日志实时发送到独立的日志服务器。Ubuntu上rsyslog原生支持TCP/UDP转发，在客户端/etc/rsyslog.d/50-forward.conf中添加：

*.* @192.168.1.100:514

使用@@表示TCP传输，单个@表示UDP。TCP虽然性能略低，但能保证日志传输可靠性，安全审计场景下应优先使用TCP。日志服务器端建议使用rsyslog接收并存储，同时配置严格的防火墙规则，只允许内网特定IP访问514端口。如果日志服务器也被攻破，集中存储的意义就丧失了，所以日志服务器本身应最小化服务、定期更新、限制登录来源。

分析cron和systemd timer异常任务

攻击者常在服务器上植入持久化后门，通过cron或systemd timer定期执行。审计时不要只看/var/log/syslog中的cron执行记录，还要直接检查所有cron配置文件。执行以下命令列出所有用户的crontab和系统cron目录：

for user in $(cut -f1 -d: /etc/passwd); do echo "--- $user ---"; crontab -l -u $user 2>/dev/null; done
ls -la /etc/cron.d/ /etc/cron.daily/ /etc/cron.hourly/ /etc/cron.weekly/ /etc/cron.monthly/

重点关注包含curl、wget、base64、nc、python等可疑命令的cron条目。systemd timer则通过systemctl list-timers --all查看，注意那些没有对应服务文件或指向临时目录的timer。攻击者经常使用/etc/cron.d/下的隐藏文件，文件名可能以点开头或伪装成系统任务。

检查用户账户和sudo配置异常

安全审计中账户检查往往比日志分析更直接。执行grep -v nologin /etc/passwd查看所有可登录账户，确认没有陌生账号。检查/etc/sudoers和/etc/sudoers.d/目录，任何包含NOPASSWD的条目都要逐一核实。攻击者添加sudo权限后，后续操作可能完全不产生失败日志。另外检查/etc/shadow中密码字段为空的账户，以及UID为0的非root账户：

awk -F: '($3 == 0) {print $1}' /etc/passwd
awk -F: '($2 == "") {print $1}' /etc/shadow

这些命令能快速暴露提权后门。同时检查/root/.ssh/authorized_keys和每个用户目录下的authorized_keys文件，确认没有攻击者植入的SSH公钥。

建立文件完整性基线

日志审计的另一个维度是文件系统完整性。安装aide或使用自建脚本，对关键系统文件生成哈希基线。当文件被修改时，即使日志被清理，哈希变化也能暴露入侵痕迹。Ubuntu上安装aide后初始化数据库：

apt install aide
aideinit
mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db

之后定期运行aide --check，将结果与基线对比。建议将aide数据库文件存储在只读介质或远程位置，防止攻击者同时修改数据库和文件。对于/usr/bin、/usr/sbin、/bin、/sbin等二进制目录，任何变化都应触发告警，因为正常系统更新之外的二进制替换几乎都是恶意行为。

日志轮转策略中的安全盲区

Ubuntu默认的logrotate配置会将auth.log轮转后保留4周，但轮转后的日志文件权限和存储位置同样需要审计。检查/etc/logrotate.d/rsyslog配置，确认轮转后的日志仍然只有root可读。攻击者有时会修改logrotate配置，将日志轮转到可写目录或减少保留份数，加速证据销毁。另外注意logrotate使用compress压缩旧日志时，如果攻击者已经获取了日志内容，压缩并不能阻止信息泄露。更隐蔽的做法是检查/var/log目录下是否存在异常的大文件或最近修改时间异常的轮转文件，这些可能是攻击者用来覆盖原始日志的填充数据。

实战中的日志审计优先级

面对一台可能被入侵的Ubuntu服务器，审计顺序应该是：先隔离网络、再备份当前日志和文件系统状态、然后检查账户和sudo配置、接着分析auth.log和journald差异、最后检查cron和启动项。不要一上来就重启服务或更新系统，这会破坏现场。日志审计的核心价值在于还原攻击时间线和入侵路径，而不是简单地找到几条可疑记录。每次审计后，应将发现的问题转化为新的监控规则，形成持续改进的闭环。