关键在于将auditd日志结构化后再集成：用rsyslog+imaudit转JSON或audispd直连，Logstash用dissect/kv/date/mutate标准化字段，Kibana按ECS建索引、做TOP10分析与告警，同时审计规则需精简并配置日志轮转。
auditd 日志集成到 ELK 实现安全分析可视化，关键不在“能不能连”，而在于“怎么连得准、看得清、查得快”。auditd 本身输出的是结构松散的文本日志（或二进制流），直接丢给 Logstash 用 grok 解析既慢又易错。真正稳定高效的做法是：先让 auditd 事件变成结构化数据，再由 Logstash 做轻量增强，最后在 Kibana 构建可操作的安全视图。
让 auditd 输出结构化日志（不是原始 audit.log）
默认的 /var/log/audit/audit.log 是面向人工阅读的文本格式，字段无固定顺序、嵌套深、含空格和括号，不适合机器解析。必须转换为 JSON 或类 JSON 格式：
- 推荐方式：用 rsyslog + imaudit 模块 转发。安装
rsyslog-audit（RHEL/CentOS）或rsyslog-module-gssapi（Ubuntu 需额外启用），在/etc/rsyslog.d/20-audit-json.conf中配置模板，将 kernel 日志中含audit(的行提取并转成标准 JSON，写入独立文件（如/var/log/audit/audit-structured.json） - 替代方式：启用 audispd 插件（如
af_unix），配合 Logstash 的unix input插件直连，避免文件 I/O 瓶颈，适合高吞吐场景 - 不推荐：直接监控
audit.log并用 grok 解析整行——规则极易断裂，且无法可靠提取comm、exe、key等关键上下文字段
Logstash 配置：聚焦字段提取与标准化
结构化日志进来后，Logstash 不需要重写复杂正则，重点做三件事：拆解 message 字段、补全时间戳、统一字段命名：
- 用 dissect 提取
type=SYSCALL、msg=audit(1747599124.123:1234)中的时间戳和事件类型 - 用 kv 过滤器 解析
message字段内 key=value 对（如uid=0、comm="ls"、key="privileged-commands"），自动转为扁平字段 - 用 date 过滤器将 Unix 时间戳（如
1747599124.123）转为@timestamp，确保时序准确 - 用 mutate 重命名关键字段（如把
uid→user.id，comm→process.name），对齐 Elastic Common Schema（ECS），方便 Kibana 关联分析
Kibana 安全大屏：从事件到风险线索
数据进 Elasticsearch 后，Kibana 不只是画图，而是构建可响应的安全视图：
- 创建索引模式匹配
audit-*，启用 ECS 字段映射（如event.action、user.name、file.path） - 仪表板必备看板：特权命令执行TOP10（
filter: event.action : "exec" and process.name : ("sudo","su")）、敏感文件修改记录（filter: file.path : ("/etc/passwd", "/etc/shadow", "/etc/sudoers")）、异常登录失败聚合（结合pam和audit日志交叉比对） - 设置告警：例如 5 分钟内同一用户触发 3 次
key="identity"规则（监控 /etc/passwd 写入），自动触发 Slack 或邮件通知 - 利用 Lens 或 TSVB 快速下钻：点击某条 sudo 执行记录 → 查看该 pid 的完整进程树（通过
ppid递归关联）→ 定位是否来自可疑 shell
规则与性能平衡：别让审计拖垮系统
auditd 规则写得太宽，日志量爆炸；写得太窄，关键行为漏掉。生产环境建议：
- 按需监控：只对
/etc/、/bin/、/usr/bin/、/var/log/等关键路径加-w，避免递归监控整个/home - 用
-F uid!=0过滤 root 行为（除非特别关注提权链），大幅降低日志量 - 设置
auditctl -e 2锁定规则，防止运行时被绕过；同时配置max_log_file = 50M和max_log_file_action = rotate，避免磁盘打满 - ELK 端做冷热分离：最近7天热数据存 SSD 节点，历史数据自动迁移至 HDD 归档节点
