理解 auditd 审计框架与日志位置
Linux 内核内置了强大的审计子系统，其核心能力在于能够在内核态拦截系统调用（System Calls）并生成原始审计事件。auditd 作为用户态守护进程，扮演着“翻译官”与“记录员”的角色：它接收内核抛出的原始事件，根据预定义的审计规则进行过滤、格式化，最终将结构化日志写入磁盘。理解这一数据流向——“内核事件 → auditd 规则匹配 → 写入日志 → 工具查询”——是开展安全审计的基础。默认情况下，审计日志存储在 /var/log/audit/audit.log。运维人员可通过 systemctl status auditd 检查服务状态，或使用 tail -f /var/log/audit/audit.log 进行基础查看。
编写与加载 auditd 审计规则
编写 auditd 规则主要依赖 auditctl 命令或规则文件。常用语法中，-w 用于监控特定文件或目录的访问与修改，例如 -w /etc/passwd -p wa -k passwd_changes 表示监控密码文件的写和属性变更并打标签；-a 用于将规则追加到指定列表（如 always,exit），配合 -F 可过滤特定字段，例如 -a always,exit -F arch=b64 -S execve -F euid=0 -k root_exec 用于记录所有以 root 权限执行的程序。规则分为临时与持久化两类：通过 auditctl 直接添加的规则重启后失效；需持久化则应写入 /etc/audit/rules.d/audit.rules，并执行 augenrules --load 加载。加载后可用 auditctl -l 验证规则是否生效，确保关键系统调用、敏感文件及提权操作均被准确捕获。
查询审计日志并定位安全事件
审计日志产生后，需借助专用工具进行高效检索。ausearch 支持多维度筛选：使用 -ts 和 -te 限定时间范围，-ui 按用户 ID 过滤，-p 指定进程 PID，-m 匹配事件类型（如 USER_LOGIN、EXECVE），-k 则用于检索规则中定义的键值。例如执行 ausearch -k passwd_changes -ts recent 可快速定位近期密码文件修改记录。对于宏观分析，aureport 能自动生成汇总报告，如 aureport --summary 展示事件总量，aureport --login 统计登录行为。在实际排查中，可先用 aureport --failed 发现大量失败登录尝试，再通过 ausearch -m USER_LOGIN -sv no 提取具体 IP 与账号，从而精准定位暴力破解或异常提权事件，实现从海量日志到安全线索的快速收敛。
建立日志监控与告警机制
静态查询无法满足实时防御需求，必须建立持续的日志监控与告警链路。可通过 tail -f 或 inotifywait 实时监听 /var/log/audit/audit.log 的新增内容，但更推荐将日志接入集中式平台（如 ELK、Splunk 或 Graylog）。部署 Filebeat 或 Fluentd 等采集器，配置多行解析以处理 auditd 的长日志格式，并转发至 SIEM 系统。在告警策略设计上，应聚焦高风险事件：如 /etc/shadow 被非授权修改、sudo 提权失败、关键二进制文件被替换、以及异常内核模块加载。在 SIEM 中配置规则匹配对应的事件类型与关键字，一旦命中即触发邮件或 Webhook 告警。通过采集、解析、规则匹配与告警的闭环，可实现对敏感操作的分钟级响应。
验证效果与规避常见审计陷阱
规则上线后必须通过实际操作验证命中情况。例如配置了 /etc/hosts 监控后，执行 echo "127.0.0.1 test" >> /etc/hosts，随后用 ausearch -f /etc/hosts 确认是否生成对应记录。在长期运行中，需警惕常见陷阱：一是规则过多导致 CPU 与 I/O 开销激增，应遵循最小必要原则，避免全量记录所有系统调用；二是规则冲突或重复加载引发冗余日志，需定期用 auditctl -l 清理冗余条目；三是日志未配置轮转导致磁盘占满，必须确保 /etc/logrotate.d/audit 生效，并设置 max_log_file 与 space_left_action 参数；四是规则未持久化导致重启失效，务必使用 augenrules 管理。通过定期执行 auditctl -s 检查审计状态与磁盘阈值，可有效平衡安全可见性与系统性能。
