auditd本身不支持告警，必须配合外部工具实现；永久规则需存于/etc/audit/rules.d/并用augenrules加载，预警需通过ausearch轮询或audispd转发至siem处理。
行为审计预警不能靠 auditd 自己触发告警，必须配合外部工具或脚本做实时解析和响应。 auditd 只负责记录，不带告警能力；直接在 audit.rules 里加规则不会发邮件、不会调 webhook、也不会停服务。
auditctl 临时规则只适合验证，别拿来当预警
用 auditctl -w /etc/shadow -p wa -k shadow_mod 这类命令加的规则，系统重启就丢，且 auditd 不会主动通知你。它只是把日志写进 /var/log/audit/audit.log，后续没人读，等于没预警。
- 临时规则唯一用途：快速确认某个路径或系统调用是否真能被捕获（比如改完
/etc/shadow后立刻跑ausearch -k shadow_mod看有没有记录） - 误以为加了
-k就能自动告警，是新手最常踩的坑 - 生产环境必须用永久规则 + 外部轮询机制，否则“预警”就是空谈
永久规则要写进 /etc/audit/rules.d/ 并用 augenrules 加载
规则存到 /etc/audit/rules.d/10-privileged.rules 才能开机生效，但加载后仍只是“记下来”，不是“报出来”。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 文件名必须以数字开头（如
10-），确保加载顺序；后缀必须是.rules - 每行一条规则，例如：
-a always,exit -F arch=b64 -S execve -F auid!=4294967295 -k user_cmd（捕获非 root 用户的命令执行） - 写完必须执行
sudo augenrules --load，而不是systemctl restart auditd—— 后者可能跳过规则重编译 - 验证是否加载成功：
sudo auditctl -l | grep user_cmd，有输出才说明内核已接收
真正实现预警得靠 ausearch + 脚本轮询或日志转发
auditd 日志是二进制结构化格式，不能用 tail -f 配 grep 做可靠预警 —— 容易漏事件、时间戳难对齐、字段边界模糊。
- 推荐方式：用
ausearch -m SYSCALL -ts today -i -k user_cmd定时拉取新事件，再 pipe 给 shell 脚本判断是否触发条件（比如 1 分钟内出现 5 次sudo rm） - 更稳方案：用
audispd插件把审计事件转发到rsyslog或fluentd，再由 SIEM（如 Elastic、Splunk）做规则匹配和告警 - 别用
inotifywait监控/var/log/audit/audit.log文件变化 —— auditd 写日志是批量刷盘，事件到达和文件更新有延迟，极易漏判 - 关键点：所有预警逻辑必须包含“去重”和“时间窗口”控制，否则一次误操作可能产生几十条重复告警
复杂点在于，auditd 本身不提供事件聚合或阈值判断能力，预警逻辑必须自己补全。最容易被忽略的是日志解析可靠性 —— ausearch -i 输出可读，但字段顺序和换行不固定，直接 parse 容易崩；生产环境建议用 ausearch --raw + Python 的 audit 模块解析，而不是靠字符串匹配。
