1. 为什么我建议每个运维人都要掌握 auditd我做了快十年运维早几年遇到过一件挺憋屈的事。某天早晨到公司开发说测试环境被搞了文件被删、定时任务被加了几条值班同事翻了一上午系统日志最后只能确认“昨晚大概有两三个 IP 登进来过”。至于对方在服务器上执行了哪些命令、改了哪些文件、有没有留后门完全说不清楚。那台机器用的是普通登录日志和 SSH 日志信息碎得根本拼不出完整画面。从那之后我养成了一个习惯所有需要面向外部、或承载重要业务的服务器一律装好 Linux auditd把关键动作先留下来再说。auditd 是 Linux 内核级的安全审计框架。它的工作方式是在内核的系统调用层挂上钩子当用户对特定文件做读、写、属性修改或执行特定命令、发起特定系统调用时把事件记录到独立的审计日志中。它和我们在/var/log/messages、secure里看到的常规日志不同常规日志是应用程序主动写的写得含糊、不全、还容易被攻击者清掉而 auditd 的日志由内核审计子系统的守护进程负责落盘记录维度更底层内容更结构化还原动作的准确度也高得多。这篇文章适合谁我觉得只要管着 Linux 服务器或者有系统安全基础但没有深度用过审计工具的读者都很适合读。全文围绕一条主线展开怎么装好、怎么配好、怎么从一堆日志里翻出真正有价值的信息并且结合一次模拟入侵的完整追踪过程演示如何用 auditd 做溯源。中间会用到我实际踩过的坑和长期积累的排查技巧尽量给到可以直接照着抄的操作。需要提前说明的是下面所有命令我都基于 CentOS 7/8 和 Ubuntu 20.04 两个环境做过验证语法略有差异的地方会在实战小节中单独标注。2. 安装配置把审计先跑起来再说2.1 安装、启用与服务自检在绝大多数主流发行版中auditd 已经预装或位于官方源中。CentOS 上用yumUbuntu 上用apt# CentOS yum install audit audit-libs -y # Ubuntu apt update apt install auditd audispd-plugins -y装完后的第一件事不是写规则而是先把服务拉起来并且确认内核审计已开启。systemctl enable --now auditd systemctl status auditd auditctl -sauditctl -s输出中的enabled字段很关键。正常情况下它显示为1内核审计已使能。如果看到的是0说明内核层面没开审计规则写了也不会生效。另一个值得留意是failure字段它表示因内核或配置问题导致事件丢失的次数如果这个数字一直在涨就说明配置有问题需要回查。我自己的规范是装完 auditd 后第一件事先不加规则跑一个简单的基于文件访问的探测写一个小文件手动读一次再用ausearch尝试检索。确认链路通了再加正式规则否则规则本身可能掩盖了底层故障。2.2 配置文件里那些最容易踩的坑auditd 的主配置在/etc/audit/auditd.conf规则文件一般在/etc/audit/rules.d/目录下通过augenrules合并加载。有些老版本叫/etc/audit/audit.rules需要自己确认。几个我几乎每次都会调一遍的参数参数作用我的建议max_log_file单个审计日志文件大小MB默认 8 太小建议 64 或 128max_log_file_action日志达到上限后的行为默认ROTATE改成 ROTATE 并配合num_logs保留多轮num_logs轮转保留的日志文件数量建议 10 及以上方便溯源space_left磁盘低水位告警阈值MB建议按分区大小留预留比如space_left 1024space_left_action低水位触发的动作我是设置成SYSLOG只记一条告警不中断服务admin_space_left更高一级的紧急阈值远低于 space_left避免彻底写满磁盘flush日志落盘模式INCREMENTAL_ASYNC或DATA别用默认的 NONE有一个很容易被忽视的问题如果日志盘是写满即导致系统异常通常是max_log_file_action被设成了SYSLOG或SINGLE而不是ROTATE。对于安全审计场景我强烈建议用 ROTATE让日志始终滚动保留避免磁盘被写满后系统停摆。若你是合规场景、审计日志不允许覆盖可以把归档命令挂到 rotation 后做压缩迁移而不是直接不轮转。另一个坑是磁盘规划。审计日志增长速度和规则数量、业务体量强相关非常不建议让/var/log/audit和根分区挤在一起。条件允许的话单独挂一个分区或至少把磁盘告警值调低一点让问题能提前暴露。2.3 一套可以直接抄作业的审计规则规则文件内的语法以auditctl命令行为单位。按启动时自动加载我会把规则按类型拆成几个文件放在/etc/audit/rules.d/下让维护的人通过文件名就能猜到每条是干什么的。这是一组经过多台生产服务器验证的基础规则# 一个适合大多数业务服务器的规则集 # 文件操作类关键系统文件与配置目录 -w /etc/passwd -p wa -k system_identity -w /etc/group -p wa -k system_identity -w /etc/shadow -p wa -k system_identity -w /etc/sudoers -p wa -k sudoers_changes -w /etc/ssh/sshd_config -p wa -k sshd_config_changes # 目录类关注持久化后门常用落点 -w /etc/cron.d/ -p wa -k cron_monitor -w /etc/init.d/ -p wa -k service_scripts -w /root/.ssh/ -p wa -k key_persist # 命令执行类监控所有非 root 启动的 shell -a always,exit -F archb64 -S execve -F auid1000 -F auid!4294967295 -k command_exec -a always,exit -F archb32 -S execve -F auid1000 -F auid!4294967295 -k command_exec # 系统管理类识别新增用户、用户组修改 -a always,exit -F archb64 -S setuid -S setgid -S setreuid -S setregid -S chown -S fchown -S fchownat -S chmod -S fchmod -S fchmodat -k permission_changes -a always,exit -F archb32 -S setuid -S setgid -S setreuid -S setregid -S chown -S fchown -S fchownat -S chmod -S fchmod -S fchmodat -k permission_changes # 模块加载内核级操作往往意味着最严重的破坏 -w /sbin/insmod -p x -k modules_load -w /sbin/modprobe -p x -k modules_load我这里故意只放了几组典型规则。如果你逐步尝试会发现规则不在于多而在于精准。-w这类文件监控规则简单直观适合盯关键路径-a always,exit -S execve这类系统调用规则能抓住命令执行但代价是产生大量事件所以一定要加过滤条件。比较稳妥的做法是先用-F auid1000过滤掉系统用户的日常动作把命令执行的监控重点放在普通业务账号上同时用-k给每类规则打标签后面分析时才好按key快速捞日志。2.4 让规则生效与验证写完后先测试再谈正式加载# 检查语法 augenrules --check # 正式加载 augenrules --load # 列出当前所有已生效规则 auditctl -l规则加载有一个很容易混淆的概念auditctl -e 1是启用但可继续动态增删规则auditctl -e 2是锁定规则后续参数包括-e 0都被拒绝只有重启机器才能恢复成可修改模式。有的加固模板喜欢在最后加一行-e 2但如果你还在调规则阶段误加-e 2就很麻烦。我的经验是先加规则、验证、优化全部确认无误后再决定是否进入不可变模式。验证规则是否真正生效不能只看auditctl -l。实战我会按规则类别做几个正向触达比如监控/etc/passwd就手动touch一下监控命令执行就手动ls一次看ausearch里是不是出现了对应 key 的事件。盲目堆规则却不验证等于买保险不看保单条款出事时才发现保险不覆盖。3. 日志分析看懂事件、善用 ausearch 与 aureport3.1 一条审计日志拆开看拿到审计日志第一件事是学会读原始记录。用ausearch -i或直接看/var/log/audit/audit.log典型的事件记录长这样我会把字段拆解说明typeSYSCALL msgaudit(1681468812.384:10045): archc000003e syscall59 successyes exit0 a07f... a17f... ppid10086 pid20001 auid1000 uid1000 gid1000 euid1000 suid1000 fsuid1000 egid1000 sgid1000 fsgid1000 ttypts0 ses1 commbash exe/usr/bin/bash key(null)逐字段拆开说字段含义溯源价值typeSYSCALL事件类型这里表示系统调用后面出现typeEXECVE等需要多行拼接读syscall59系统调用号59 在 x86_64 下是 execve配合ausearch可自动解释为命令执行auid1000登录时的原始用户 ID即使通过 sudo 切换身份这个值也不会变是溯源的锚点uid1000当前有效用户 ID与 auid 不同可判断是否存在提权或切换身份ppid/pid父进程与当前进程号梳理进程树时非常有用ttypts0终端类型与编号pts一般对应 SSH 会话comm/exe进程名/可执行文件路径判断攻击者执行了什么命令augears有几个常见误会我特别说一句一次命令执行在原始日志里可能对应多条 type 记录必须按pid和msg中的时间戳进行关联。直接用文本编辑器去翻日志几乎不可维护正确姿势是用官方配套工具做检索和解码。3.2 ausearch 的组合查询ausearch是定向检索事件的核心工具支持按 key、用户、时间、进程 PID、文件路径组合过滤。我日常最常用的几条命令# 按规则标签查比如查所有命令执行事件 ausearch -k command_exec --start today # 按原始登录用户查 ausearch -au 1000 --start 04/10/2025 20:00:00 --end 04/10/2025 23:59:59 # 按 PID 查进程相关所有记录 ausearch -p 20001 # 查与某个文件相关的所有事件 ausearch -f /etc/passwd # 查今天所有成功/失败的次数 ausearch --start today --success yes组合起来时时间窗口和条件要尽量收窄。我最常用的是先确定auid再确定时间再按key扫一遍。因为同一条事件可能被多个 key 命中按最精确的 key 缩小范围能避免被旁路噪音干扰。另外在线检索大日志时建议--start给到完整MM/DD/YYYY HH:MM:SS只写日期会把整天都查一遍慢且容易误判。需要提醒的是如果你在 CentOS 5/6 时代用过ausearch -k会发现现在版本对空 key 的处理更严格。规则没打-k的事件按 key 查询时查不到只能用-m或其他字段过滤。所以写作规则时就一定要规划好 key 的命名规范。3.3 aureport 的宏观统计如果想快速了解服务器上一段时间内到底“有什么异常动静”先看aureport比看ausearch更高效。它把海量事件汇总成报告我们一眼能看出哪种事件异常多。# 今日审计报告 aureport --start today # 只统计认证失败 aureport -au --start today --failed # 只统计执行过的命令truncate 宽输出 aureport -x --start today | awk {print $NF} | sort | uniq -c | sort -rn | head -30最后这条命令是我在溯源时必用的把执行过的进程名聚合排序高频命令立刻浮出水面。如果一台服务器某天出现大量“bash”“curl”“wget”“python”之类命令而常规业务又用不到那基本可以判断有不速之客了。当然aureport也有局限它偏统计不提供单一事件的完整上下文所以它只做入口锁定可疑窗口后用ausearch做深挖。3.4 日志轮转与归档要注意的事审计日志是“越长越好”和“磁盘有限”这对矛盾的核心。前面说的max_log_file_action ROTATE可以解决增长问题但ROTATE 只是让文件按编号滚动不会自动压缩也不会自动删除太久的历史。建议在cron里挂一个简单的归档任务# 压缩 5 天前的 audit 日志 find /var/log/audit -name audit.log.* -mtime 5 -exec gzip {} \;归档要注意的是权限保持。audit 日志包含极其敏感的命令记录归档后的压缩包依旧不能给普通用户可读权限否则等于把攻击者的完整“操作序列”摆给所有能登录服务器的人看。我见过有公司为了省事直接把整个/var/log/audit目录chmod 777这种方式非常不可取正确的做法是保持root:root且600权限或专门把归档压缩包移到独立的日志审计系统里。4. 入侵溯源实战一次模拟攻击的追踪全记录4.1 场景一台被拿下的内网服务器为了把故事讲清楚我构造一个完全虚拟但非常典型的事件。某公司的一台内网 Web 服务器对外开放着一个老旧的运维管理入口某天监测系统提示那台机器上有异常的定时任务生成。值班同事初步判断可能已经失守找我协助溯源。服务器上已经装好 auditd并且运行了我在第 2 节写的基础规则集。时间线假定是这样的攻击者通过弱口令进入管理入口拿到 shell 后执行了侦察命令同时尝试写入公钥和添加后门账号最终通过计划任务保持权限。整个过程的“案发现场”数据正是 auditd 日志。我要强调一点真正做溯源时我们会用各种系统文件、进程、网络连接配合审计日志。但仅靠一个 auditd仍然可以通过命令序列、文件写入和权限变更信息把整个逻辑链条串起来。4.2 第一时间先看全局失守事件不要急着深挖某一细节。我会先把时间窗口拉开用aureport做一次全局体检# 查看当天所有审计事件摘要 aureport --start 04/10/2025 00:00:00 --end 04/10/2025 23:59:59重点关注哪几类Authentication和Exec是最优先看的。如果日志显示某个时段内认证失败显著增多或者大量来自非业务路径的execve命令那就是第一现场。比如模拟场景里可以看到Exec记录从上午 10:30 开始密集出现bash、id、whoami、cat等侦察命令并且这些命令的auid都指向同一个人账号。这与目标的日常操作模式明显不一致于是我锁定 10:30 到 10:45 作为关键窗口。4.3 还原攻击者的命令序列锁定窗口后用ausearch精确检索命令执行记录# 在时间窗口内查询所有命令执行事件 ausearch -k command_exec --start 04/10/2025 10:30:00 --end 04/10/2025 10:45:00 -i输出一排排命令名依次是id、whoami、cat /etc/passwd、ls -la /tmp、curl、chmod、useradd。useradd出现时我基本可以断定攻击者在做持久化准备。按pid关联命令链还可以看到这些命令都是从一个 SSH 会话进程ttypts0里派生出来的。审计日志有个很重要的细节很多时候不是typeSYSCALL一行就能展示完整命令行。像curl这样带 URL 或参数的命令原始字段里会附带typeEXECVE记录命令行参数被拆分存在。这时需要按同一个pid再查一次# 查看某个进程的所有事件 ausearch -p 12345 -i通过EXECVE中的a0、a1等字段拼接就能还原出完整命令。这一步常被初学者忽略只看 SYSCALL 事件会丢失参数信息看到一半的“案发现场”很容易误导判断。我在实际过程中会用ausearch -p PID -li组合参数配合原始日志逐字核对确保还原出的命令与真实执行一致。4.4 追踪后门与持久化痕迹命令序列中出现useradd直接指向账户持久化。这时需要查system_identity相关文件变更事件# 查 passwd 相关变更 ausearch -k system_identity --start 04/10/2025 10:30:00 --end 04/10/2025 10:45:00 -i日志清楚地展示了useradd新增用户webadmin、修改/etc/passwd和/etc/shadow的时间点。再往下还发现了一个对/root/.ssh/authorized_keys的写入操作。这个动作对应key_persist规则说明攻击者不仅在系统层加账号还想通过密钥免密登录维持访问。两条规则恰好覆盖了两种最常见的后门手法这就是在配置阶段把规则设计好的回报平时不觉得什么出事时每一条规则都在帮你做“不在场证明”或“在场证明”。再看一眼计划任务cron_monitor的 key 下出现了新的 cron 文件写入事件。时间、文件路径、进程来源和前面执行curl的会话完全吻合。至此攻击链已经非常清楚了弱口令进入 → 侦察 → 下载工具或脚本 → 写计划任务 → 写公钥 → 创建新用户。所有环节都有时间戳、有进程关系、有文件路径可以生成一张时间线报告交给处置团队了。4.5 常见的攻击行为审计特征速查结合多次溯源我把高频攻击行为在 auditd 日志里的特征整理成了表格便于以后快速对照攻击行为审计特征对应规则 key命令侦察execve中出现id、whoami、cat /etc/passwd等高频小命令command_exec添加后门账号对/etc/passwd、/etc/shadow的写入事件伴随setuid类系统调用system_identity写入 SSH 公钥authorized_keys文件写入key_persist计划任务持久化cron 目录文件写入且写入进程往往不是系统 cron 自身cron_monitor修改 SSH 配置sshd_config写入常见于开启密码登录或端口转发sshd_config_changes权限提权sudoers变更或对带 SUID 文件执行chmodsudoers_changes/permission_changes这只是一个不完整的清单。真正部署时更重要的是“敏感性”把那些如果被改掉、会直接影响系统信任边界的文件全部加入监控。5. 常见坑与排查技巧实录5.1 规则不生效十有八九是这几种我见过最多的问题是规则文件名写错导致augenrules没加载。augenrules默认扫描/etc/audit/rules.d/下所有.rules后缀文件如果你把规则文件保存成.txt或.conf它是不会自动加载的。检查办法是加载后立刻执行auditctl -l如果期望的规则没出现排查优先级是文件后缀 → 权限 → 语法 → 服务是否重启。还有一类问题看似诡异规则明明列表里有但事件就是不产生。这时先确认内核的 enable 状态auditctl -senabled0就是内核没使能enabled2则是被锁定所有动态增删规则都不生效连auditctl -e 1也会报错。遇到锁定的状态唯一出路是重启系统后再进行调整所以没事不要乱加-e 2。5.2 日志刷屏与性能损耗审计规则越宽写入的日志越多对 IO 的压力也越大。最典型的刷屏来源是对高频访问的目录添加了-w监控或对execve没做用户过滤。我实测过如果对/tmp目录加-p wa业务频繁写临时文件时一天能产生几个 GB 的日志磁盘和 IO 双双告警。应对思路是分层设计-w规则只用于敏感低频路径-a系统调用规则尽量加-F条件收窄范围。比如execve规则只监控交互式用户命令而不是监控所有进程同时对系统启动期间的内核线程做排除。必要时还可以对具体目录使用-F path/xxx -F uidxxx之类的组合条件从源头上降低噪音。5.3 auditd 自身安全和权限控制安全工具自身如果被攻破那整个审计体系就形同虚设。这里有三方面要特别注意。第一审计日志本身必须写保护。/var/log/audit目录建议由 auditd 服务独占写权限普通用户一律只读甚至不可见避免攻击者销毁日志。第二auditd 的配置文件不能被任意用户修改。规则加载后如果担心本地用户覆盖可以在最终状态加入不可变模式-e 2。但不要在生产环境的“排查调试阶段”就急于锁定而是在变更窗口内一次性完成锁定。第三日志的完整性监控。即使 auditd 自身关键文件做了保护也建议把它纳入另一个独立系统的文件完整性检查或者每天对审计日志做哈希校验把原始哈希集中存到单独的日志服务器。否则一旦攻击者获得 root 并逆向清除痕迹后续的溯源就缺乏可信依据了。5.4 与其他安全工具怎么配合auditd 是底层的记录员但它不判断“好坏”。实践中我通常把它的角色定位为对可疑行为提供原始证据。入侵检测系统、Web 应用防火墙或主机安全软件发现告警后再由 analyst 通过 auditd 日志去还原完整操作链路。也就是说auditd 最好配合警报系统使用而不是等攻击结束才回头看日志。如果环境允许可以每天把/var/log/audit同步到集中日志平台既能离线永久保存又方便用搜索引擎式的语法做长周期的大范围检索。另外一点是时间同步。审计日志里的时间戳如果来自失真的系统时钟前后时间线根本无法对齐。所以在部署审计的第一天就应保证chrony或ntpd正常工作并定期检查系统时钟偏差。这一条我把它放在“最容易被忽视但最影响结论”的位置。最后再补充一个小技巧如果你在溯源时发现某个关键时间段的审计日志缺失不要慌先看audit.log是否发生过大跳号。如果检测到大量事件丢失往往说明当时规则过载或磁盘占用已达到admin_space_left阈值。结合系统侧的其他日志比如进程启动时间和登录记录还能大致补出模糊的时间轮廓。真正的完整证据链永远来自平时把配置和轮转都做扎实的那份细心——这套东西锦上添花时不起眼但在关键时刻是能把“说不清”变成“证据确凿”的底气。
1. 为什么我建议每个运维人都要掌握 auditd我做了快十年运维早几年遇到过一件挺憋屈的事。某天早晨到公司开发说测试环境被搞了文件被删、定时任务被加了几条值班同事翻了一上午系统日志最后只能确认“昨晚大概有两三个 IP 登进来过”。至于对方在服务器上执行了哪些命令、改了哪些文件、有没有留后门完全说不清楚。那台机器用的是普通登录日志和 SSH 日志信息碎得根本拼不出完整画面。从那之后我养成了一个习惯所有需要面向外部、或承载重要业务的服务器一律装好 Linux auditd把关键动作先留下来再说。auditd 是 Linux 内核级的安全审计框架。它的工作方式是在内核的系统调用层挂上钩子当用户对特定文件做读、写、属性修改或执行特定命令、发起特定系统调用时把事件记录到独立的审计日志中。它和我们在/var/log/messages、secure里看到的常规日志不同常规日志是应用程序主动写的写得含糊、不全、还容易被攻击者清掉而 auditd 的日志由内核审计子系统的守护进程负责落盘记录维度更底层内容更结构化还原动作的准确度也高得多。这篇文章适合谁我觉得只要管着 Linux 服务器或者有系统安全基础但没有深度用过审计工具的读者都很适合读。全文围绕一条主线展开怎么装好、怎么配好、怎么从一堆日志里翻出真正有价值的信息并且结合一次模拟入侵的完整追踪过程演示如何用 auditd 做溯源。中间会用到我实际踩过的坑和长期积累的排查技巧尽量给到可以直接照着抄的操作。需要提前说明的是下面所有命令我都基于 CentOS 7/8 和 Ubuntu 20.04 两个环境做过验证语法略有差异的地方会在实战小节中单独标注。2. 安装配置把审计先跑起来再说2.1 安装、启用与服务自检在绝大多数主流发行版中auditd 已经预装或位于官方源中。CentOS 上用yumUbuntu 上用apt# CentOS yum install audit audit-libs -y # Ubuntu apt update apt install auditd audispd-plugins -y装完后的第一件事不是写规则而是先把服务拉起来并且确认内核审计已开启。systemctl enable --now auditd systemctl status auditd auditctl -sauditctl -s输出中的enabled字段很关键。正常情况下它显示为1内核审计已使能。如果看到的是0说明内核层面没开审计规则写了也不会生效。另一个值得留意是failure字段它表示因内核或配置问题导致事件丢失的次数如果这个数字一直在涨就说明配置有问题需要回查。我自己的规范是装完 auditd 后第一件事先不加规则跑一个简单的基于文件访问的探测写一个小文件手动读一次再用ausearch尝试检索。确认链路通了再加正式规则否则规则本身可能掩盖了底层故障。2.2 配置文件里那些最容易踩的坑auditd 的主配置在/etc/audit/auditd.conf规则文件一般在/etc/audit/rules.d/目录下通过augenrules合并加载。有些老版本叫/etc/audit/audit.rules需要自己确认。几个我几乎每次都会调一遍的参数参数作用我的建议max_log_file单个审计日志文件大小MB默认 8 太小建议 64 或 128max_log_file_action日志达到上限后的行为默认ROTATE改成 ROTATE 并配合num_logs保留多轮num_logs轮转保留的日志文件数量建议 10 及以上方便溯源space_left磁盘低水位告警阈值MB建议按分区大小留预留比如space_left 1024space_left_action低水位触发的动作我是设置成SYSLOG只记一条告警不中断服务admin_space_left更高一级的紧急阈值远低于 space_left避免彻底写满磁盘flush日志落盘模式INCREMENTAL_ASYNC或DATA别用默认的 NONE有一个很容易被忽视的问题如果日志盘是写满即导致系统异常通常是max_log_file_action被设成了SYSLOG或SINGLE而不是ROTATE。对于安全审计场景我强烈建议用 ROTATE让日志始终滚动保留避免磁盘被写满后系统停摆。若你是合规场景、审计日志不允许覆盖可以把归档命令挂到 rotation 后做压缩迁移而不是直接不轮转。另一个坑是磁盘规划。审计日志增长速度和规则数量、业务体量强相关非常不建议让/var/log/audit和根分区挤在一起。条件允许的话单独挂一个分区或至少把磁盘告警值调低一点让问题能提前暴露。2.3 一套可以直接抄作业的审计规则规则文件内的语法以auditctl命令行为单位。按启动时自动加载我会把规则按类型拆成几个文件放在/etc/audit/rules.d/下让维护的人通过文件名就能猜到每条是干什么的。这是一组经过多台生产服务器验证的基础规则# 一个适合大多数业务服务器的规则集 # 文件操作类关键系统文件与配置目录 -w /etc/passwd -p wa -k system_identity -w /etc/group -p wa -k system_identity -w /etc/shadow -p wa -k system_identity -w /etc/sudoers -p wa -k sudoers_changes -w /etc/ssh/sshd_config -p wa -k sshd_config_changes # 目录类关注持久化后门常用落点 -w /etc/cron.d/ -p wa -k cron_monitor -w /etc/init.d/ -p wa -k service_scripts -w /root/.ssh/ -p wa -k key_persist # 命令执行类监控所有非 root 启动的 shell -a always,exit -F archb64 -S execve -F auid1000 -F auid!4294967295 -k command_exec -a always,exit -F archb32 -S execve -F auid1000 -F auid!4294967295 -k command_exec # 系统管理类识别新增用户、用户组修改 -a always,exit -F archb64 -S setuid -S setgid -S setreuid -S setregid -S chown -S fchown -S fchownat -S chmod -S fchmod -S fchmodat -k permission_changes -a always,exit -F archb32 -S setuid -S setgid -S setreuid -S setregid -S chown -S fchown -S fchownat -S chmod -S fchmod -S fchmodat -k permission_changes # 模块加载内核级操作往往意味着最严重的破坏 -w /sbin/insmod -p x -k modules_load -w /sbin/modprobe -p x -k modules_load我这里故意只放了几组典型规则。如果你逐步尝试会发现规则不在于多而在于精准。-w这类文件监控规则简单直观适合盯关键路径-a always,exit -S execve这类系统调用规则能抓住命令执行但代价是产生大量事件所以一定要加过滤条件。比较稳妥的做法是先用-F auid1000过滤掉系统用户的日常动作把命令执行的监控重点放在普通业务账号上同时用-k给每类规则打标签后面分析时才好按key快速捞日志。2.4 让规则生效与验证写完后先测试再谈正式加载# 检查语法 augenrules --check # 正式加载 augenrules --load # 列出当前所有已生效规则 auditctl -l规则加载有一个很容易混淆的概念auditctl -e 1是启用但可继续动态增删规则auditctl -e 2是锁定规则后续参数包括-e 0都被拒绝只有重启机器才能恢复成可修改模式。有的加固模板喜欢在最后加一行-e 2但如果你还在调规则阶段误加-e 2就很麻烦。我的经验是先加规则、验证、优化全部确认无误后再决定是否进入不可变模式。验证规则是否真正生效不能只看auditctl -l。实战我会按规则类别做几个正向触达比如监控/etc/passwd就手动touch一下监控命令执行就手动ls一次看ausearch里是不是出现了对应 key 的事件。盲目堆规则却不验证等于买保险不看保单条款出事时才发现保险不覆盖。3. 日志分析看懂事件、善用 ausearch 与 aureport3.1 一条审计日志拆开看拿到审计日志第一件事是学会读原始记录。用ausearch -i或直接看/var/log/audit/audit.log典型的事件记录长这样我会把字段拆解说明typeSYSCALL msgaudit(1681468812.384:10045): archc000003e syscall59 successyes exit0 a07f... a17f... ppid10086 pid20001 auid1000 uid1000 gid1000 euid1000 suid1000 fsuid1000 egid1000 sgid1000 fsgid1000 ttypts0 ses1 commbash exe/usr/bin/bash key(null)逐字段拆开说字段含义溯源价值typeSYSCALL事件类型这里表示系统调用后面出现typeEXECVE等需要多行拼接读syscall59系统调用号59 在 x86_64 下是 execve配合ausearch可自动解释为命令执行auid1000登录时的原始用户 ID即使通过 sudo 切换身份这个值也不会变是溯源的锚点uid1000当前有效用户 ID与 auid 不同可判断是否存在提权或切换身份ppid/pid父进程与当前进程号梳理进程树时非常有用ttypts0终端类型与编号pts一般对应 SSH 会话comm/exe进程名/可执行文件路径判断攻击者执行了什么命令augears有几个常见误会我特别说一句一次命令执行在原始日志里可能对应多条 type 记录必须按pid和msg中的时间戳进行关联。直接用文本编辑器去翻日志几乎不可维护正确姿势是用官方配套工具做检索和解码。3.2 ausearch 的组合查询ausearch是定向检索事件的核心工具支持按 key、用户、时间、进程 PID、文件路径组合过滤。我日常最常用的几条命令# 按规则标签查比如查所有命令执行事件 ausearch -k command_exec --start today # 按原始登录用户查 ausearch -au 1000 --start 04/10/2025 20:00:00 --end 04/10/2025 23:59:59 # 按 PID 查进程相关所有记录 ausearch -p 20001 # 查与某个文件相关的所有事件 ausearch -f /etc/passwd # 查今天所有成功/失败的次数 ausearch --start today --success yes组合起来时时间窗口和条件要尽量收窄。我最常用的是先确定auid再确定时间再按key扫一遍。因为同一条事件可能被多个 key 命中按最精确的 key 缩小范围能避免被旁路噪音干扰。另外在线检索大日志时建议--start给到完整MM/DD/YYYY HH:MM:SS只写日期会把整天都查一遍慢且容易误判。需要提醒的是如果你在 CentOS 5/6 时代用过ausearch -k会发现现在版本对空 key 的处理更严格。规则没打-k的事件按 key 查询时查不到只能用-m或其他字段过滤。所以写作规则时就一定要规划好 key 的命名规范。3.3 aureport 的宏观统计如果想快速了解服务器上一段时间内到底“有什么异常动静”先看aureport比看ausearch更高效。它把海量事件汇总成报告我们一眼能看出哪种事件异常多。# 今日审计报告 aureport --start today # 只统计认证失败 aureport -au --start today --failed # 只统计执行过的命令truncate 宽输出 aureport -x --start today | awk {print $NF} | sort | uniq -c | sort -rn | head -30最后这条命令是我在溯源时必用的把执行过的进程名聚合排序高频命令立刻浮出水面。如果一台服务器某天出现大量“bash”“curl”“wget”“python”之类命令而常规业务又用不到那基本可以判断有不速之客了。当然aureport也有局限它偏统计不提供单一事件的完整上下文所以它只做入口锁定可疑窗口后用ausearch做深挖。3.4 日志轮转与归档要注意的事审计日志是“越长越好”和“磁盘有限”这对矛盾的核心。前面说的max_log_file_action ROTATE可以解决增长问题但ROTATE 只是让文件按编号滚动不会自动压缩也不会自动删除太久的历史。建议在cron里挂一个简单的归档任务# 压缩 5 天前的 audit 日志 find /var/log/audit -name audit.log.* -mtime 5 -exec gzip {} \;归档要注意的是权限保持。audit 日志包含极其敏感的命令记录归档后的压缩包依旧不能给普通用户可读权限否则等于把攻击者的完整“操作序列”摆给所有能登录服务器的人看。我见过有公司为了省事直接把整个/var/log/audit目录chmod 777这种方式非常不可取正确的做法是保持root:root且600权限或专门把归档压缩包移到独立的日志审计系统里。4. 入侵溯源实战一次模拟攻击的追踪全记录4.1 场景一台被拿下的内网服务器为了把故事讲清楚我构造一个完全虚拟但非常典型的事件。某公司的一台内网 Web 服务器对外开放着一个老旧的运维管理入口某天监测系统提示那台机器上有异常的定时任务生成。值班同事初步判断可能已经失守找我协助溯源。服务器上已经装好 auditd并且运行了我在第 2 节写的基础规则集。时间线假定是这样的攻击者通过弱口令进入管理入口拿到 shell 后执行了侦察命令同时尝试写入公钥和添加后门账号最终通过计划任务保持权限。整个过程的“案发现场”数据正是 auditd 日志。我要强调一点真正做溯源时我们会用各种系统文件、进程、网络连接配合审计日志。但仅靠一个 auditd仍然可以通过命令序列、文件写入和权限变更信息把整个逻辑链条串起来。4.2 第一时间先看全局失守事件不要急着深挖某一细节。我会先把时间窗口拉开用aureport做一次全局体检# 查看当天所有审计事件摘要 aureport --start 04/10/2025 00:00:00 --end 04/10/2025 23:59:59重点关注哪几类Authentication和Exec是最优先看的。如果日志显示某个时段内认证失败显著增多或者大量来自非业务路径的execve命令那就是第一现场。比如模拟场景里可以看到Exec记录从上午 10:30 开始密集出现bash、id、whoami、cat等侦察命令并且这些命令的auid都指向同一个人账号。这与目标的日常操作模式明显不一致于是我锁定 10:30 到 10:45 作为关键窗口。4.3 还原攻击者的命令序列锁定窗口后用ausearch精确检索命令执行记录# 在时间窗口内查询所有命令执行事件 ausearch -k command_exec --start 04/10/2025 10:30:00 --end 04/10/2025 10:45:00 -i输出一排排命令名依次是id、whoami、cat /etc/passwd、ls -la /tmp、curl、chmod、useradd。useradd出现时我基本可以断定攻击者在做持久化准备。按pid关联命令链还可以看到这些命令都是从一个 SSH 会话进程ttypts0里派生出来的。审计日志有个很重要的细节很多时候不是typeSYSCALL一行就能展示完整命令行。像curl这样带 URL 或参数的命令原始字段里会附带typeEXECVE记录命令行参数被拆分存在。这时需要按同一个pid再查一次# 查看某个进程的所有事件 ausearch -p 12345 -i通过EXECVE中的a0、a1等字段拼接就能还原出完整命令。这一步常被初学者忽略只看 SYSCALL 事件会丢失参数信息看到一半的“案发现场”很容易误导判断。我在实际过程中会用ausearch -p PID -li组合参数配合原始日志逐字核对确保还原出的命令与真实执行一致。4.4 追踪后门与持久化痕迹命令序列中出现useradd直接指向账户持久化。这时需要查system_identity相关文件变更事件# 查 passwd 相关变更 ausearch -k system_identity --start 04/10/2025 10:30:00 --end 04/10/2025 10:45:00 -i日志清楚地展示了useradd新增用户webadmin、修改/etc/passwd和/etc/shadow的时间点。再往下还发现了一个对/root/.ssh/authorized_keys的写入操作。这个动作对应key_persist规则说明攻击者不仅在系统层加账号还想通过密钥免密登录维持访问。两条规则恰好覆盖了两种最常见的后门手法这就是在配置阶段把规则设计好的回报平时不觉得什么出事时每一条规则都在帮你做“不在场证明”或“在场证明”。再看一眼计划任务cron_monitor的 key 下出现了新的 cron 文件写入事件。时间、文件路径、进程来源和前面执行curl的会话完全吻合。至此攻击链已经非常清楚了弱口令进入 → 侦察 → 下载工具或脚本 → 写计划任务 → 写公钥 → 创建新用户。所有环节都有时间戳、有进程关系、有文件路径可以生成一张时间线报告交给处置团队了。4.5 常见的攻击行为审计特征速查结合多次溯源我把高频攻击行为在 auditd 日志里的特征整理成了表格便于以后快速对照攻击行为审计特征对应规则 key命令侦察execve中出现id、whoami、cat /etc/passwd等高频小命令command_exec添加后门账号对/etc/passwd、/etc/shadow的写入事件伴随setuid类系统调用system_identity写入 SSH 公钥authorized_keys文件写入key_persist计划任务持久化cron 目录文件写入且写入进程往往不是系统 cron 自身cron_monitor修改 SSH 配置sshd_config写入常见于开启密码登录或端口转发sshd_config_changes权限提权sudoers变更或对带 SUID 文件执行chmodsudoers_changes/permission_changes这只是一个不完整的清单。真正部署时更重要的是“敏感性”把那些如果被改掉、会直接影响系统信任边界的文件全部加入监控。5. 常见坑与排查技巧实录5.1 规则不生效十有八九是这几种我见过最多的问题是规则文件名写错导致augenrules没加载。augenrules默认扫描/etc/audit/rules.d/下所有.rules后缀文件如果你把规则文件保存成.txt或.conf它是不会自动加载的。检查办法是加载后立刻执行auditctl -l如果期望的规则没出现排查优先级是文件后缀 → 权限 → 语法 → 服务是否重启。还有一类问题看似诡异规则明明列表里有但事件就是不产生。这时先确认内核的 enable 状态auditctl -senabled0就是内核没使能enabled2则是被锁定所有动态增删规则都不生效连auditctl -e 1也会报错。遇到锁定的状态唯一出路是重启系统后再进行调整所以没事不要乱加-e 2。5.2 日志刷屏与性能损耗审计规则越宽写入的日志越多对 IO 的压力也越大。最典型的刷屏来源是对高频访问的目录添加了-w监控或对execve没做用户过滤。我实测过如果对/tmp目录加-p wa业务频繁写临时文件时一天能产生几个 GB 的日志磁盘和 IO 双双告警。应对思路是分层设计-w规则只用于敏感低频路径-a系统调用规则尽量加-F条件收窄范围。比如execve规则只监控交互式用户命令而不是监控所有进程同时对系统启动期间的内核线程做排除。必要时还可以对具体目录使用-F path/xxx -F uidxxx之类的组合条件从源头上降低噪音。5.3 auditd 自身安全和权限控制安全工具自身如果被攻破那整个审计体系就形同虚设。这里有三方面要特别注意。第一审计日志本身必须写保护。/var/log/audit目录建议由 auditd 服务独占写权限普通用户一律只读甚至不可见避免攻击者销毁日志。第二auditd 的配置文件不能被任意用户修改。规则加载后如果担心本地用户覆盖可以在最终状态加入不可变模式-e 2。但不要在生产环境的“排查调试阶段”就急于锁定而是在变更窗口内一次性完成锁定。第三日志的完整性监控。即使 auditd 自身关键文件做了保护也建议把它纳入另一个独立系统的文件完整性检查或者每天对审计日志做哈希校验把原始哈希集中存到单独的日志服务器。否则一旦攻击者获得 root 并逆向清除痕迹后续的溯源就缺乏可信依据了。5.4 与其他安全工具怎么配合auditd 是底层的记录员但它不判断“好坏”。实践中我通常把它的角色定位为对可疑行为提供原始证据。入侵检测系统、Web 应用防火墙或主机安全软件发现告警后再由 analyst 通过 auditd 日志去还原完整操作链路。也就是说auditd 最好配合警报系统使用而不是等攻击结束才回头看日志。如果环境允许可以每天把/var/log/audit同步到集中日志平台既能离线永久保存又方便用搜索引擎式的语法做长周期的大范围检索。另外一点是时间同步。审计日志里的时间戳如果来自失真的系统时钟前后时间线根本无法对齐。所以在部署审计的第一天就应保证chrony或ntpd正常工作并定期检查系统时钟偏差。这一条我把它放在“最容易被忽视但最影响结论”的位置。最后再补充一个小技巧如果你在溯源时发现某个关键时间段的审计日志缺失不要慌先看audit.log是否发生过大跳号。如果检测到大量事件丢失往往说明当时规则过载或磁盘占用已达到admin_space_left阈值。结合系统侧的其他日志比如进程启动时间和登录记录还能大致补出模糊的时间轮廓。真正的完整证据链永远来自平时把配置和轮转都做扎实的那份细心——这套东西锦上添花时不起眼但在关键时刻是能把“说不清”变成“证据确凿”的底气。
