4、操作系统审计日志（Linux/Windows）归纳总结
很多人刚接触审计日志时，容易陷入“只知其一不知其二”的困境。Linux 和 Windows 的日志机制从底层设计到上层工具，完全是两套哲学。我当年第一次跨平台做安全巡检时，就差点被 Windows 的事件 ID 和 Linux 的 auditd 规则搞晕。下面我把这两个系统的审计日志核心要点总结出来，方便你快速对照和上手。
4.1 Linux 审计日志核心机制
Linux 下审计日志主要来自两大块：系统日志（syslog/rsyslog） 和 内核审计子系统（auditd）。
- rsyslog：负责收集系统日志，比如用户登录、sudo 执行、SSH 连接。配置文件在
/etc/rsyslog.conf，规则清晰。 - auditd：内核级审计框架，可以监控文件访问、系统调用、网络连接。规则通过
auditctl配置，日志写入/var/log/audit/audit.log。
我个人的习惯是：先看 /var/log/secure（或 /var/log/auth.log），快速筛出异常登录行为；如果发现提权或文件篡改嫌疑，再翻 audit.log 细查系统调用记录。
避坑指南： 我曾经在 CentOS 7 上排查过一次漏洞，明明改动了关键文件，但 audit.log 里什么都没有。查了半天才发现 auditd 服务没启动——默认安装后需要手动 systemctl enable auditd 并重启。这是新手最容易忽略的坑。
| 日志文件 | 主要用途 | 典型事件 |
|---|---|---|
/var/log/secure |
安全认证日志 | SSH 登录、sudo 使用、用户切换 |
/var/log/auth.log |
Debian/Ubuntu 认证日志 | 与 secure 类似，但文件名不同 |
/var/log/audit/audit.log |
内核审计日志 | 文件修改、系统调用、网络连接 |
/var/log/messages |
通用系统日志 | 服务启动、内核消息、硬件事件 |
/var/log/wtmp |
登录记录（二进制） | 历史登录用户、时间、来源 IP |
技巧： 巡检时除了看文本日志，别忘了用 last、lastb、ausearch -ui 用户名 这类工具，它们能直接解析二进制文件，比 grep 快得多。
4.2 Windows 审计日志核心机制
Windows 把所有日志都统一在 事件查看器（Event Viewer） 里，核心分类是：系统、安全、应用程序。但真正的审计能力靠的是“高级审计策略”或“组策略”。
- 系统日志：记录驱动程序、服务启动/停止、系统错误等。
- 安全日志：记录登录成功/失败、权限使用、对象访问、账户管理。这是审计的重点。
- 应用程序日志：应用程序自行写入的事件，比如 IIS、SQL Server。
Windows 的事件用 Event ID 来标识。同一个动作可能有多个 ID，比如登录成功是 4624，登录失败是 4625。我建议你务必记熟下面这张表，这是巡检的基本功。
| Event ID | 事件说明 | 审计类别 |
|---|---|---|
| 4624 | 成功登录（包含本地和远程） | 登录/注销 |
| 4625 | 登录失败 | 登录/注销 |
| 4634 | 用户注销 | 登录/注销 |
| 4648 | 使用显式凭据登录（如 RunAs） | 登录/注销 |
| 4672 | 分配给新登录的特权（如管理员） | 特权使用 |
| 4688 | 新的进程创建 | 详细跟踪 |
| 4732 | 将成员添加到安全组 | 账户管理 |
重要提示： 默认 Windows 安全日志只记录最简单的成功/失败。要想拿到进程创建、对象访问这些细节，必须在组策略里手动开启“审核进程创建”“审核对象访问”等子类别。这块配置很多人忘记做，导致出事时根本查不到。
4.3 审计日志结构对比
说白了，Linux 日志是文本流，一行一个事件，用 syslog 标准格式；Windows 日志是结构化二进制，用 WEL (Windows Event Log) 格式。下面这张表我经常拿出来给团队培训，看完你就知道跨平台巡检需要什么。
| 对比维度 | Linux | Windows |
|---|---|---|
| 日志格式 | 纯文本（RFC 5424 / 传统 syslog） | 二进制 EVTX 文件（需 API 解析） |
| 默认存储 | /var/log/ 下多个文件 | %SystemRoot%\System32\winevt\Logs\ |
| 日志轮转 | logrotate 按大小/时间切分 | 按大小（20MB 默认上限），可配置策略 |
| 事件唯一标识 | 无全局 ID，依赖时间戳+主机名 | 有 EventID + 时间戳 + 计算机名 |
| 查询工具 | grep、awk、ausearch、journalctl | wevtutil、Get-WinEvent (PowerShell) |
| 实时采集 | tail + syslog/syslog-ng 转发 | Windows Event Forwarding (WEF) |
4.4 巡检方法归纳
日常巡检不要哪里都想查，抓住下面这几个步骤就够了。我自己在运维中发现，90%的问题都能通过前三个步骤暴露出来。
- 检查服务健康状态：Linux 用
systemctl status rsyslog auditd，Windows 用Get-Service -Name *EventLog*。服务没跑，日志就是空的。 - 检查日志完整性：有没有出现“日志文件被截断”“审计日志轮转失败”之类的错误？我见过一次日志文件被某个脚本写满磁盘，直接导致系统 hang 死。
- 扫描高频异常事件：Linux 重点看
Failed password、authentication failure；Windows 重点看4625（登录失败）、4672（特权分配）、4732（组变更）。 - 检查时间同步：日志时间不准，后续溯源全乱套。NTP 和 W32Time 必须确认同步。
- 验证日志轮转与保留策略：日志被提前覆盖是重大隐患。Linux 看
/etc/logrotate.d/，Windows 在事件查看器里设置最大日志大小和保留天数。
实战经验： 我曾遇到一次客户说“审计日志找不到了”，结果发现 auditd 日志因为 logrotate 配置错误被删空了。从那以后我每次部署都会加一条 cron 任务定时检查日志文件的存在性和大小，防患于未然。
4.5 审计日志体系全景图
下面这张 SVG 图概括了 Linux 和 Windows 审计日志的产生路径、存储形式以及巡检切入点。你可以把它当作操作手顺图来用。
好了，以上就是操作系统审计日志的核心归纳。日常巡检时把这张图放在手边，对着 Linux 和 Windows 两边关键的日志文件、事件 ID 逐个检查，基本不会漏掉重要告警。记住，日志不会说谎，但前提是你得知道它在哪、长什么样、怎么查。习惯用工具而不是用眼睛硬刷，你会省下很多精力。嗯，这部分先聊到这。