openKylin作为国内开源桌面操作系统，默认集成了Linux内核的审计框架。安全审计的核心是把系统中谁在什么时间对什么对象做了什么操作记录下来，而auditd正是承接这项工作的守护进程。要让它真正发挥作用，关键在于编写合适的审计规则：规则写得太宽松，日志里全是噪音，出事了查不到关键信息；规则写得太细，日志量暴涨还会拖累系统性能。本文系统讲解openKylin上auditd规则的语法结构、常用场景写法和管理方式，帮你搭建一套实用的审计体系。
一、auditd规则的基本语法与过滤器类型
auditd规则通过auditctl命令添加到内核，一条简单的控制规则格式为auditctl -w 路径 -p 权限 -k 关键字，这是最常用的文件监控写法。更底层的系统调用规则格式则复杂一些：auditctl -a 动作,过滤器 -S 系统调用 -F 字段 -k 关键字。其中动作有两个取值，always表示记录，never表示排除；过滤器决定规则在哪个环节生效，常用的有task、entry、exit、user和exclude。
实际编写时最常用的是exit过滤器，它在系统调用退出时触发，能拿到调用的返回值。字段-F用来限定匹配条件，比如-F uid=0表示只关注root用户的操作，-F arch=b64表示限定64位系统调用架构。一条规则可以叠加多个-F参数，各条件之间是与的关系。关键字-k不是必填项，但强烈建议加上，它相当于给规则打标签，后续用ausearch检索时可以直接按关键字过滤，效率高很多。
先看一下基础命令的用法：
# 查看当前已加载的规则 auditctl -l # 查看审计子系统状态，包括启用状态、日志是否丢失等 auditctl -s # 监控/etc/passwd文件的写入和属性修改，打上identity标签 auditctl -w /etc/passwd -p wa -k identity # 删除某条文件监控规则 auditctl -W /etc/passwd -p wa -k identity
权限参数-p后面可以组合四种字母：r代表读，w代表写，x代表执行，a代表属性变更（比如chmod）。-p wa表示写入或属性变更时都记录。需要注意的是，对文件读操作做审计会产生海量日志，一般只在涉密环境下才对特定敏感目录开启r。
二、典型场景的规则编写实战
场景一：监控关键系统文件。openKylin桌面环境下，/etc目录下的配置文件、用户身份相关文件都是重点保护对象。可以针对一组文件分别写规则，也可以用系统调用规则配合路径过滤实现批量监控。
# 监控用户身份相关文件的修改 auditctl -w /etc/group -p wa -k identity auditctl -w /etc/shadow -p wa -k identity auditctl -w /etc/sudoers -p wa -k sudoers_change # 监控整个/etc/ssh目录的变化 auditctl -w /etc/ssh/ -p wa -k ssh_config # 用系统调用规则批量监控目录（64位环境） auditctl -a always,exit -F arch=b64 -F path=/etc -S open -S rename -S unlink -F auid>=1000 -k etc_access
上面最后一条规则的含义是：任何已登录用户（auid大于等于1000，即排除系统账户）对/etc目录下的文件执行打开、重命名、删除操作时都记录日志。auid是login id，即用户最初登录时的身份，即使用户中途su切换了身份，auid依然记录原始登录者，这一点在事后追责时特别有用。
场景二：监控系统调用和特权命令。排查提权行为时，需要重点关注execve调用。可以按UID范围过滤，只记录普通用户执行命令的行为：
# 记录普通用户执行的所有命令 auditctl -a always,exit -F arch=b64 -S execve -F auid>=1000 -F auid!=4294967295 -k user_cmd # 监控sudo的执行 auditctl -w /usr/bin/sudo -p x -k sudo_exec
auid!=4294967295这个条件容易被忽略。4294967295是-1的无符号表示，代表进程没有经过登录会话（比如一些守护进程），排除掉它可以让日志更干净。这种按系统调用编写规则的方式比文件监控更灵活，但要求对Linux系统调用有一定了解，写之前可以用ausyscall命令查询调用号对应的名称。
三、规则的持久化与日志查询
用auditctl添加的规则是临时的，系统重启后就失效了。openKylin上要做到持久化，需要把规则写入/etc/audit/rules.d/目录下的规则文件。auditd服务启动时会用augenrules把rules.d目录下所有以.rules结尾的文件按文件名顺序合并成最终规则加载。注意不要直接改/etc/audit/audit.rules，那个文件通常是自动生成的汇总结果。
# 创建自定义规则文件 vim /etc/audit/rules.d/custom.rules # 文件内容示例（注意持久化规则不带auditctl前缀） -w /etc/passwd -p wa -k identity -a always,exit -F arch=b64 -S execve -F auid>=1000 -F auid!=4294967295 -k user_cmd # 重新加载规则并确认生效 augenrules --load auditctl -l
规则文件末尾通常建议加上-e 2，它会把规则设为不可修改模式，重启前任何人都无法增删规则，能防止攻击者删规则擦痕迹。但启用前一定要反复测试规则，否则锁死后只能进救援模式修改。
日志写下来只是第一步，能快速查到才有价值。ausearch按条件检索原始日志，aureport生成汇总报表，两者配合使用：
# 按关键字查询审计事件，-i把数字ID翻译成可读名称 ausearch -k identity -i # 查今天的登录相关事件 ausearch -m LOGIN --start today -i # 查某个用户的所有操作记录 ausearch -ua zhangsan -i # 生成汇总报表：所有事件统计 aureport # 生成失败操作的报表，常用于发现攻击尝试 aureport --failed # 生成文件操作报表 aureport -f -i
查询时如果发现日志很快被冲掉，检查/etc/audit/auditd.conf中的max_log_file和num_logs参数，必要时调大日志文件上限或调整日志满后的处理策略。另外规则数量不是越多越好，每条规则都会增加系统调用的开销，建议控制规则总数，并定期回顾规则命中率，长期没有命中的规则可以清理掉。
四、编写规则时的常见坑与建议
第一个坑是路径写法。-w监控目录时必须以斜杠结尾，比如-w /etc/ssh/，少了结尾斜杠可能匹配不到目录下的文件。同时被监控的路径必须是真实文件，如果传入的是软链接，auditd监控的是链接文件本身而不是目标文件。
第二个坑是arch不匹配。系统调用规则如果不加-F arch=b64或-F arch=b32限定，同一条规则可能在两种架构下表现不一致，甚至出现加载失败的情况。openKylin运行在飞腾、鲲鹏等国产ARM平台时同样要区分b64和b32，稳妥的做法是成对编写两条规则，分别覆盖64位和32位调用。
第三个坑是忽略登录会话用户。uid记录的是进程当前有效用户，auid才追溯最初的登录身份。如果只按uid过滤，用户su到root后的操作会被当成root的行为，追责链条就断了。安全审计场景下应优先使用auid。
最后给几条实践建议：规则上线前先在测试环境运行一段时间，观察日志量是否可接受；给每条规则都加上清晰的key，命名风格统一，比如按对象加动作的格式；结合auditd自身的轮转策略管理日志留存周期；对监控sudo这类高风险规则，可以配合告警脚本实现实时通知。按这套思路在openKylin上落地，审计系统既不会成为性能负担，又能在关键时刻提供完整的证据链。