Linux系统审计日志开启与入侵检测规则维护建议

Linux系统审计的核心工具是auditd，但很多运维人员只是把它装上了事，没有根据实际业务场景去定制规则，导致关键文件被篡改时日志里毫无记录，或者日志里塞满了无意义的噪音，真正出事时排查起来像大海捞针。审计日志的价值不在于“开没开”，而在于“记了什么”。默认配置通常只记录一些系统层面的基础调用，对于Web目录、数据库配置文件、敏感脚本的变动往往处于盲区。所以，开启审计后第一件事就是评估你的资产，明确哪些文件、目录、系统调用是必须监控的，然后把这些监控项转化为精确的audit规则。

在绝大多数Linux发行版中，auditd由audit包提供。安装通常很简单，以RHEL/CentOS系为例，执行yum install audit，Debian/Ubuntu系则用apt install auditd。安装完成后，立即启动服务并设为开机自启：systemctl enable auditd && systemctl start auditd。但此时它记录的只是默认规则下的内容，远不能满足安全需求。关键配置文件位于/etc/audit/auditd.conf，这里控制日志轮转、磁盘空间预警和响应动作。你需要重点关注的参数包括num_logs（保留日志文件数量）、max_log_file（单个日志文件最大容量，建议设为100MB以上）、max_log_file_action（当磁盘满时执行的动作，务必设为ROTATE而非IGNORE或SUSPEND，否则可能导致审计服务挂起或丢失日志）。还有一个容易忽略的细节是日志存储路径，默认在/var/log/audit/，这个目录必须挂载在独立分区或有足够容量的逻辑卷上，防止日志撑爆根分区导致系统不可用。

审计规则分为控制规则、文件系统规则和系统调用规则三类。控制规则用于调整审计系统自身行为，比如设置缓冲区大小和失败模式。文件系统规则也叫监视规则，用于监控文件或目录的访问、修改、属性变更。系统调用规则则用于追踪特定进程的系统调用。实际运维中，文件系统规则最常用也最易出错。比如监控/etc/passwd文件，很多人会写一条-w /etc/passwd -p wa -k identity，意思是监控写操作和属性变更，并打上identity标签。但这还不够，因为攻击者可能通过硬链接或重命名来绕过。更严谨的做法是同时监控/etc目录下的相关文件创建和删除动作，以及/etc/shadow、/etc/group、/etc/gshadow等关联文件。对于Web应用，通常需要监控/var/www/html或自定义的Web根目录，规则可以写为-w /var/www/html -p rwa -k web_changes，但要注意，如果Web目录下文件读写非常频繁，这条规则会产生海量日志。此时需要做精细化裁剪，比如排除读取操作，只记录写入和属性变更：-w /var/www/html -p wa -k web_changes，或者进一步用-F auid>=1000来过滤掉系统服务账户产生的噪音。

系统调用规则的威力在于可以捕获更底层的行为，比如跟踪某个特定用户执行的所有命令。假设要监控用户oracle的所有操作，可以添加规则-a always,exit -F arch=b64 -S execve -F auid=1001 -k oracle_activity。这里arch字段必须匹配系统架构，b64代表64位，b32代表32位，如果系统是64位但运行了32位程序，两条规则都要加。execve系统调用能捕获命令执行，但无法捕获shell内置命令，这是它的局限性。更全面的做法是结合pam_tty_audit模块，在/etc/pam.d/system-auth或/etc/pam.d/password-auth中添加session required pam_tty_audit.so enable=*，这样能记录所有终端输入，不过日志量会非常庞大，通常只在对特定用户做深度调查时临时启用。

审计规则可以通过命令行auditctl临时添加，但重启后失效。永久规则存储在/etc/audit/rules.d/目录下的.rules文件中，主规则文件通常是audit.rules。规则文件的加载顺序按文件名排序，所以如果你有自定义规则，建议创建一个如/etc/audit/rules.d/99-custom.rules的文件，确保它在默认规则之后加载，避免被覆盖。规则文件中的语法与auditctl命令一致，但不需要前面的auditctl前缀。写完规则文件后，用auditctl -R /etc/audit/rules.d/audit.rules来测试加载，或者直接重启auditd服务。这里有一个常见的坑：如果规则中有语法错误，auditd可能启动失败且不给出明显提示。务必在修改规则后用auditctl -l查看当前生效的规则列表，确认所有规则都已正确加载。对于大规模服务器集群，规则管理应该纳入配置管理系统，通过Ansible、Puppet或SaltStack来统一下发和校验规则文件，并定期执行auditctl -l比对，防止规则被意外篡改或丢失。

从入侵检测的角度看，审计规则应该覆盖攻击链的多个阶段。初始入侵阶段，攻击者可能利用Web漏洞写入Webshell，所以Web目录下的新文件创建和文件内容修改是重点监控对象。规则可以写成-w /var/www/html -p w -k webshell_upload，但更隐蔽的Webshell可能通过修改已有文件的时间戳来混淆视听，所以还需要监控属性变更。提权阶段，攻击者通常会尝试利用SUID二进制文件或内核漏洞，监控SUID位变更和内核模块加载就很有必要：-w /usr/bin/chmod -p x -k suid_abuse和-w /sbin/insmod -p x -k module_load，同时配合-a always,exit -F arch=b64 -S init_module -S delete_module -k kernel_module监控内核模块的加载和卸载。持久化阶段，攻击者会修改启动脚本、crontab或服务文件，因此/etc/cron.d/、/etc/crontab、/var/spool/cron/、/etc/systemd/system/等目录的写操作必须纳入监控。横向移动阶段，ssh密钥和known_hosts文件的变动是关键指标，监控每个用户home目录下的.ssh/目录，规则可以写为-w /home/*/.ssh/ -p wa -k ssh_keys。数据外传阶段，监控异常的网络连接和大量数据读取，可以通过系统调用规则捕获connect和sendto调用，并结合uid和进程名来过滤。

审计日志本身是二进制格式的，需要用ausearch和aureport工具来查询分析。ausearch支持按时间、事件类型、用户、标签等多种条件过滤。比如查找过去一小时内所有标签为web_changes的事件：ausearch -k web_changes -ts recent:1h。aureport则用于生成统计报告，aureport -f可以列出所有文件访问事件并按频率排序，aureport -u列出用户活动摘要。但这些手动分析方式在实时入侵检测场景下效率太低。更有效的做法是将审计日志实时转发到集中日志平台，如ELK Stack或Splunk。auditd本身支持将日志发送到syslog，在/etc/audit/plugins.d/syslog.conf中设置active = yes即可。然后通过rsyslog或filebeat将日志发送到分析平台。在分析平台中，可以基于规则标签和事件类型建立告警，比如当web_changes标签的事件在短时间内激增，或者出现了module_load标签的事件，立即触发通知。更进一步，可以结合响应脚本实现自动化处置，比如检测到某个用户触发了多次权限提升失败的事件，临时冻结该账户。

审计系统对性能的影响主要来自系统调用规则，尤其是高频率的系统调用如read、write。在生产环境中，应尽量避免使用-a always,exit -S read -S write这类大范围规则，除非在极短时间的调试场景下。文件系统规则相对轻量，但如果监控的目录下文件操作极其频繁，比如数据库的数据目录，也会产生可观的性能开销。此时需要评估监控的必要性，或者通过排除特定进程来减少干扰。比如监控/etc目录但排除合法配置管理工具的操作，可以用-F pid!=12345来排除特定进程。另一个噪音来源是系统服务账户，如apache、mysql等，它们的操作通常不是攻击行为，可以用-F auid>=1000或-F uid>=1000来过滤，只记录真实用户的操作。日志轮转策略也要合理设置，避免单个日志文件过大导致分析工具解析缓慢。建议将max_log_file设为100MB，num_logs设为10到20个，这样既能保留足够的历史数据，又不至于占用过多磁盘空间。

审计系统本身也是攻击者的目标。如果攻击者获得了root权限，第一件事可能就是停止auditd服务、删除规则或清空日志。因此需要对审计相关文件和进程进行额外保护。首先，将auditd的配置文件、规则文件和日志目录的权限收紧，只允许root读写。其次，使用-a always,exit -F arch=b64 -S kill -F a0=19 -k audit_tamper来监控auditd进程的终止信号，a0=19对应SIGSTOP信号。同时监控auditctl、ausearch、aureport等审计工具的调用，以及/etc/audit/目录下任何文件的修改。还可以启用auditd的不可变模式，在规则文件中添加-e 2，这会使审计规则在加载后无法被修改，直到系统重启。注意这个操作是不可逆的，必须确保规则完全正确后再启用，否则只能通过重启来修正规则。最后，考虑将审计日志实时发送到远程日志服务器，这样即使本地日志被清除，远程仍然保留有副本，这是防御日志清理攻击的最有效手段。

审计规则不是一劳永逸的配置，需要随着业务变化和威胁情报持续迭代。每季度至少进行一次规则审计，检查是否有新增的关键文件未被监控，是否有规则因业务变更而失效。每次安全事件响应后，都要复盘审计日志是否提供了足够的溯源信息，如果发现关键环节缺失日志，立即补充相应规则。建立规则变更的审批和测试流程，任何规则修改先在测试环境验证，确认不会产生过量噪音或性能问题后再推送到生产环境。同时关注CVE公告和行业安全报告，当出现新的攻击手法时，评估现有规则是否能检测到，如果不能，及时更新规则集。例如，近年来针对容器环境的逃逸攻击增多，就需要增加对容器运行时接口、内核命名空间相关系统调用的监控。只有把审计规则当成活的资产来维护，才能让Linux审计系统真正成为入侵检测和事后溯源的有力武器。