1. Auditbeat 的前世今生（它到底是干嘛的）

1）Beats 家族的背景

Auditbeat 属于 Elastic 的 Beats 系列（轻量级采集 Agent）。

Elastic 最早是做 Elasticsearch + Logstash + Kibana（ELK），后来发现 Logstash 太重，部署成本高，所以推出 Beats：

• Filebeat：采集日志文件
• Metricbeat：采集系统指标
• Packetbeat：采集网络流量
• Heartbeat：探活
• Winlogbeat：Windows 事件日志
• Auditbeat：Linux 审计 / 文件完整性监控（FIM）

Beats 的理念就是：轻量、单一职责、边缘采集、集中分析。

---

2）Auditbeat 的诞生原因

在 Linux 运维安全领域，有两件事特别关键：

A. 谁在系统里干了什么？

比如：

• 谁执行了 useradd？
• 谁改了 /etc/passwd？
• 谁打开了某个敏感文件？
• 谁执行了某个二进制文件？

Linux 原生解决方案是 auditd（Linux Audit Framework）。

B. 系统文件有没有被篡改？

比如：

• /bin/ls 被替换成后门
• /etc/ssh/sshd_config 被修改
• /usr/bin/sudo 被注入

传统方案是 Tripwire、AIDE。

Auditbeat 就是 Elastic 把这两种能力结合起来：

• auditd 审计日志采集
• FIM 文件完整性监控 并输出成 Elasticsearch 能理解的结构化事件。

---

3）Auditbeat 的定位（运维视角）

一句话：

Auditbeat = Linux 审计 + 文件完整性监控（HIDS 的关键组成部分）+ 统一输出到 ELK。

它本质是一个 Host-based Security Telemetry Agent。

在安全产品里，它经常被当成 HIDS（主机入侵检测）的一部分。

---

2. Auditbeat 的核心模块（你到底采集了啥）

Auditbeat 主要两大类模块：

---

2.1 auditd 模块（系统行为审计）

基于 Linux 内核 audit 子系统（不是自己造轮子）。

它能记录：

• execve（进程执行）
• 用户登录、身份切换
• 文件访问
• 网络相关系统调用（部分）
• 权限修改、SELinux 事件等

它能做到的效果类似：

• “谁执行了什么命令”
• “谁动了关键文件”
• “是否发生可疑行为”

运维上它很重要，因为这属于 行为取证。

---

2.2 file_integrity 模块（FIM 文件完整性）

通过监听文件系统变化（Linux 上可能用 inotify / fanotify / 扫描）。

典型用途：

• 监控 /etc、/bin、/usr/bin
• 监控 web 目录防篡改（/var/www/html）
• 监控容器宿主机关键目录

输出事件会包含：

• 文件 hash（sha1/sha256/md5）
• 文件权限变更
• owner/group
• 修改时间
• 新增/删除/修改动作

运维上这属于 防篡改检测。

---

3. Auditbeat 常见运维操作命令（重点）

下面这些是你日常排障、上线、巡检一定会用的。

---

3.1 查看版本与基本信息

auditbeat version
auditbeat --help

看它支持哪些模块：

auditbeat modules list

---

3.2 配置文件语法检查（最常用）

这是运维最重要的命令之一：

auditbeat test config -c /etc/auditbeat/auditbeat.yml

如果你想更严格检查（会尝试加载模块）：

auditbeat test config -e

-e 表示日志输出到 stderr（前台输出，方便你看）。

---

3.3 测试输出（能不能连上 ES / Logstash）

如果你配置了 output.elasticsearch：

auditbeat test output -c /etc/auditbeat/auditbeat.yml

这会显示：

• DNS 是否解析成功
• TLS 是否正常
• 用户密码是否正确
• ES 是否返回响应

排错时非常有用。

---

3.4 测试配置是否能正常加载 index template / pipeline

如果你用的是 Elasticsearch output，并希望检查 setup：

auditbeat setup -e

一般生产环境会这么做：

auditbeat setup --index-management -e
auditbeat setup --pipelines -e
auditbeat setup --dashboards -e

---

3.5 前台运行调试（必备）

如果你 systemd 启动失败，你一定要用这个：

auditbeat -e -c /etc/auditbeat/auditbeat.yml

如果你想 debug 级别：

auditbeat -e -d "*"

只看某些模块：

auditbeat -e -d "auditd"
auditbeat -e -d "file_integrity"
auditbeat -e -d "publisher"
auditbeat -e -d "output"

推荐用法：

auditbeat -e -d "auditd,file_integrity,output"

---

3.6 导出最终生效配置（配置合并后长什么样）

这对于排查变量、include、默认值非常有用：

auditbeat export config -c /etc/auditbeat/auditbeat.yml

---

3.7 导出 template / ilm policy / dashboard

如果你不想直接写入 ES，想先看看它会生成什么：

auditbeat export template > auditbeat-template.json
auditbeat export ilm-policy > auditbeat-ilm.json

---

3.8 systemd 运维操作（生产最常用）

systemctl status auditbeat
systemctl restart auditbeat
systemctl stop auditbeat
systemctl start auditbeat
systemctl enable auditbeat
systemctl disable auditbeat

看启动失败原因：

journalctl -u auditbeat -xe
journalctl -u auditbeat -f

---

3.9 Auditbeat 自身日志排查

默认日志路径通常在：

• /var/log/auditbeat/auditbeat
• 或 systemd journal

看文件日志：

tail -f /var/log/auditbeat/auditbeat

---

3.10 检查 Auditbeat 是否在正常采集

看进程：

ps aux | grep auditbeat

看是否打开了 audit netlink socket：

ss -xp | grep audit

看是否输出到 ES：

curl -s http://es:9200/_cat/indices?v | grep auditbeat

---

4. auditd 模块运维排错重点（你踩坑一定会遇到）

4.1 auditd 服务冲突（最经典）

很多机器上系统自带 auditd 服务。

auditbeat auditd 模块会直接接管 audit netlink。

如果 auditd 已经占用了，Auditbeat 会报错类似：

• failed to open audit netlink socket
• cannot set audit rules

解决方法通常是：

systemctl stop auditd
systemctl disable auditd
systemctl restart auditbeat

但注意：这可能影响合规审计策略，生产要评估。

---

4.2 audit 权限问题

Auditbeat 必须 root 运行，否则 auditd 模块无法工作。

检查：

id auditbeat

systemd 服务通常会配置成 root。

---

4.3 audit rules 不生效 / 被覆盖

Auditbeat 可以写 rules，但如果系统 auditd 在跑，可能会覆盖。

查看当前 audit rules：

auditctl -l

查看 audit 状态：

auditctl -s

---

5. file_integrity 模块运维排错重点

5.1 inotify 数量限制（典型报错点）

监控目录多时会遇到：

• too many open files
• inotify watch limit reached

检查当前限制：

sysctl fs.inotify.max_user_watches
sysctl fs.inotify.max_user_instances

临时调大：

sysctl -w fs.inotify.max_user_watches=1048576
sysctl -w fs.inotify.max_user_instances=1024

永久写入：

cat >> /etc/sysctl.conf <<EOF
fs.inotify.max_user_watches=1048576
fs.inotify.max_user_instances=1024
EOF

sysctl -p

---

5.2 hash 计算导致 IO 压力

file_integrity 会计算 hash，如果目录大、文件多，会造成磁盘抖动。

你需要控制：

• 监控路径数量
• exclude_files
• scan_rate_per_sec（部分版本支持）
• 不要监控海量动态目录（如 /var/lib/docker）

---

6. 运维常见巡检清单（可直接照抄）

6.1 检查服务健康

systemctl is-active auditbeat
systemctl is-enabled auditbeat

6.2 检查配置是否有效

auditbeat test config -c /etc/auditbeat/auditbeat.yml

6.3 检查输出是否正常

auditbeat test output -c /etc/auditbeat/auditbeat.yml

6.4 检查 audit 规则是否被加载

auditctl -l

6.5 检查 ES 是否收到数据

curl -s http://es:9200/_cat/indices?v | grep auditbeat

---

7. Auditbeat 在 HIDS 中的角色（运维理解版）

如果你把 HIDS（主机入侵检测系统）拆解：

• 采集层：Auditbeat（采集系统行为、文件篡改）
• 分析层：Elasticsearch + Detection rules（关联分析）
• 展示层：Kibana（告警、Dashboard）
• 响应层：SOAR / webhook / 自动封禁

Auditbeat 本身只负责“上报事实”，它不是 IDS 引擎。

它的优势是：

• 轻量
• 数据结构化
• 和 ELK 原生整合

---

8. 生产环境建议（很实际）

8.1 不要全量监控文件系统

file_integrity 监控 / 是灾难。

建议只监控：

• /etc
• /bin /sbin
• /usr/bin /usr/sbin
• /opt/yourapp/config
• /var/www

排除：

• /var/log
• /tmp
• /var/lib/docker
• /proc /sys

---

8.2 auditd 模块不要乱加规则

audit rules 太多会拖慢系统调用性能。

生产建议：

• 监控 execve
• 监控身份变更
• 监控关键文件变更（/etc/passwd /etc/shadow）

---

8.3 输出建议走 Logstash/Kafka 缓冲

生产大规模主机上：

• Auditbeat → Logstash/Kafka → ES 比直写 ES 更抗压、更可控。

---

9. 最常用的 Debug 流程（运维排障模板）

如果 Auditbeat 启动失败，按这个流程走：

# 1. 看 systemd 日志
journalctl -u auditbeat -xe

# 2. 前台 debug 启动
auditbeat -e -d "*" -c /etc/auditbeat/auditbeat.yml

# 3. 检查配置
auditbeat test config -c /etc/auditbeat/auditbeat.yml

# 4. 检查 output
auditbeat test output -c /etc/auditbeat/auditbeat.yml

# 5. 检查 auditd 冲突
systemctl status auditd
auditctl -s
auditctl -l

# 6. 检查 inotify limit（file_integrity）
sysctl fs.inotify.max_user_watches