linux内核日志缓冲区清空操作无法被auditd直接监控，但可通过监控/usr/bin/dmesg执行及对/dev/kmsg的write等系统调用实现可靠捕获，因所有清空本质均经由此设备文件写入。
Linux 内核日志缓冲区（即 dmesg 所读取的 ring buffer）本身不支持直接通过 auditd 监控“清空”操作，因为 dmesg -c、dmesg -C 或写入 /dev/kmsg 清空缓冲区的行为，不经过典型的文件系统路径或标准系统调用审计点。auditd 无法像监控 /var/log/audit.log 那样对内核 ring buffer 做路径级 -w 监控。
但你可以通过以下间接但可靠的方式捕获所有尝试清空 dmesg 缓冲区的行为：
一、监控关键命令的执行（最实用有效）
几乎所有清空操作都依赖以下命令或其变体：
-
dmesg -c（clear once） -
dmesg -C（clear all） -
echo 1 > /proc/sys/kernel/printk（重置 console_loglevel，间接影响可见性，但非清空） -
真正清空动作本质是向
/dev/kmsg写入控制消息 —— 这才是核心切入点。
✅ 推荐规则（加入永久规则文件，如 /etc/audit/rules.d/dmesg.rules）：
# 监控 dmesg 命令执行（含参数） -a always,exit -F arch=b64 -S execve -F path=/usr/bin/dmesg -F key=dmesg_exec # 监控对 /dev/kmsg 的写入（清空操作实际发生在此） -w /dev/kmsg -p w -k kmsg_write # 补充：监控可能绕过 dmesg 的直接写操作（如 echo > /dev/kmsg） -a always,exit -F arch=b64 -S write,writev,pwrite64,pwritev -F path=/dev/kmsg -F key=kmsg_direct_write
加载规则：
sudo augenrules --load sudo systemctl restart auditd
✅ 验证方式：
sudo dmesg -c sudo ausearch -k dmesg_exec -i | head -5 sudo ausearch -k kmsg_write -i | head -5
二、为什么不能用 -w /proc/kmsg 或 -w /dev/kmsg 单独靠路径监控？
-
/proc/kmsg是只读接口（仅用于读取），不可写，清空不走它； -
/dev/kmsg是字符设备，auditd 的-w路径监控对设备文件支持有限，且write()系统调用触发更稳定； - 实际清空逻辑由内核在
drivers/tty/sysrq.c和kernel/printk/printk.c中处理，最终落在sys_write()对/dev/kmsg的调用上 —— 所以*必须结合 `-S write+-F path=/dev/kmsg`**。
三、补充防御建议（防绕过）
攻击者可能用 strace、gdb 或自定义二进制绕过 dmesg 命令，但仍需调用 write() 到 /dev/kmsg。因此上述系统调用规则比单纯监控命令更健壮。
你还可以加一条兜底规则，捕获所有对 /dev/kmsg 的任意写入尝试（不限定进程）：
-a always,exit -F arch=b64 -S write,writev,pwrite64,pwritev -F path=/dev/kmsg -F perm=w -k kmsg_any_write
四、日志分析提示
清空行为在 audit.log 中典型特征：
-
comm="dmesg"+exe="/usr/bin/dmesg" -
path="/dev/kmsg"+syscall=write或syscall=writev -
a0=...（fd）、a3=...（buffer内容，有时含"clear"字样，但不保证）
用 ausearch 快速定位：
sudo ausearch -m write -f /dev/kmsg -i --start today
不复杂但容易忽略：/dev/kmsg 是唯一可写入并触发内核缓冲区重置的接口，盯住它就抓住了所有清空行为的源头。
