如果一台Linux服务器被人入侵了你手头最可靠的证据是什么我入行前几年一直以为答案是shell history和应用日志直到真碰上事才发现攻击者会在几分钟内清掉.bash_history或者干脆用webshell执行命令根本不经过shell。那些看似丰富的应用日志往往只记录业务请求根本不关心系统层面发生了什么。真正在这种时刻靠得住的是Linux自带的auditd——一套从内核层面记录系统安全事件的审计框架。这篇文章围绕auditd的安装配置、日志分析和入侵溯源展开把我自己在生产环境里摸出来的配置思路、查询方法和踩过的坑一起写出来。适合运维、安全工程师、SRE也适合那些想搞清楚自己服务器上到底发生过什么操作的个人站长。auditd不会阻止攻击者但它在内核里留下的记录是事后还原攻击链最可靠的一条线索这句话我会在后面的案例里反复印证。1. auditd 到底是什么和普通日志有什么本质区别1.1 从“日志失效”说起应用日志和shell历史为什么靠不住先说最常见的两类日志为什么在溯源时容易翻车。第一类是应用日志比如Nginx访问日志、Java业务日志。它们记录的是“应用层面发生了什么请求”攻击者通过Web漏洞上传一个webshell后应用日志可能只留下一条“POST /upload 200”的记录。你根本看不到这只webshell后续执行了什么命令、改了什么文件。第二类是shell history也就是用户执行过的命令历史。攻击者只要在第一个命令里带上unset HISTORY HISTFILE或者干脆rm ~/.bash_history这一条线索就断了。更麻烦的是这两类日志都属于应用层或用户态日志内容由进程自己决定是否记录、记录什么。进程一旦被入侵者控制日志的完整性和可信度都打折扣。这也是我后来坚持上auditd的核心原因——它的数据来源不是某个进程而是Linux内核的审计框架只要内核本身没有被攻破审计事件就会产生。1.2 内核态审计与用户态日志的区别auditd 的核心机制auditd由多个部分组成内核里的审计模块充当事件采集源头用户态守护进程auditd负责接收和落盘auditctl用来配置规则ausearch和aureport用来查询和分析日志。整个链路从内核态出发经过netlink机制传给用户态auditd最后写入/var/log/audit/audit.log。这种架构带来的直接优势是事件不由应用程序主动上报而是由内核根据auditd配置的规则自动生成。举个例子某个进程即使不写任何日志只要它试图打开/etc/passwd内核在完成这个系统调用时就会顺带生成一条SYSCALL审计记录。进程根本感知不到自己在被审计也就很难在操作的同时把这条记录抹掉。当然要说明白auditd并不是什么不可篡改的金钟罩。拥有root权限的攻击者如果及时发现审计服务依然可以尝试停止auditd或删除日志文件。但停止服务、删除文件这些动作自身会留下其他痕迹而且后面我会说到通过远程日志同步和不可变规则完全可以把这个缺口补上。1.3 auditd 能监控什么文件、命令、系统调用的边界auditd监控范围可以从两个维度理解。从对象维度看它主要覆盖三类目标文件与目录的访问和属性变化、系统调用的执行记录、内核和用户空间的各类事件比如登录、身份切换、时间变更。从事件维度看它可以记录某个进程在什么时间、以什么身份、调用了哪个系统调用、访问了哪个文件、最后是否成功。把这些信息组合起来基本可以在事后回答这几个问题谁在什么时间执行过什么命令、改过哪些文件、访问过哪些敏感资源。我经常用一句话向同事解释auditd的能力边界它监控的是“哪个主体在哪个客体上做了什么动作”主体是进程和用户客体是文件和系统资源动作就是系统调用和文件操作。理解了这个模型后面写规则和分析日志都会顺手很多。2. 安装与基础配置从零把审计服务跑起来2.1 安装不同发行版包名和服务名容易踩的坑auditd在主流发行版都有打包但包名略有不同。Debian/Ubuntu系安装包叫auditdRHEL/CentOS系的包名是audit两者的服务名都叫auditd。安装命令分别如下。# Debian / Ubuntu apt-get update apt-get install -y auditd audispd-plugins # RHEL / CentOS / Rocky yum install -y audit装完之后启动并设置开机自启systemctl enable --now auditd systemctl status auditd启动后第一件事是用auditctl -s看内核审计模块的状态返回结果里enabled如果是1说明审计功能已经开启。再用auditctl -l看当前已加载的规则列表。我见过不止一个同事装完服务就以为万事大吉结果一看规则列表是空的等于白装了。新装系统后如果没有加载任何默认规则auditd只是空转不会记录任何有价值的东西。2.2 auditd.conf 核心参数日志大小、磁盘策略与 backlog配置文件在/etc/audit/auditd.conf几个参数直接决定了审计服务在磁盘压力和突发流量下的表现。max_log_file控制单份审计日志文件的大小单位是MBnum_logs是在max_log_file_action设为ROTATE时保留的历史文件个数space_left和admin_space_left分别设置磁盘剩余空间警告阈值和严重阈值单位是MBdisk_full_action和disk_error_action处理磁盘满了或出错误时怎么办。这里必须重点说一个常识性坑很多早期教程把disk_full_action配成HALT意思是一旦磁盘满就系统停机。这在理论上是出于审计完整性考虑但在生产环境一次突发的日志风暴就可能把整个业务搞挂代价实在太大。我自己的建议是把磁盘相关动作尽量配置成告警通知而不是直接停机让运维人员先保住业务再处理审计问题。一个相对稳妥的配置示例max_log_file 64 num_logs 6 max_log_file_action ROTATE space_left 500 space_left_action SYSLOG admin_space_left 300 admin_space_left_action SYSLOG disk_full_action SYSLOG disk_error_action SYSLOG另一个容易被忽略的参数是backlog。它是内核向auditd发送审计事件时使用的缓冲队列如果短时间内事件量暴增而auditd来不及消费backlog满了就会丢记录。高并发服务器建议在规则文件开头设置一个较大的值比如-b 8192这比事后发现日志缺失要省心得多。2.3 规则文件加载机制rules.d 目录与 augenrules现代发行版把auditd规则放在/etc/audit/rules.d/目录下系统会读取该目录下所有.rules文件通过augenrules工具合并生成一份完整的运行时规则再交给内核加载。手动加载规则用augenrules --load临时修改规则用auditctl直接操作即可比如auditctl -w /etc/passwd -p wa -k file_passwd。但必须注意这种临时规则在重启auditd或执行augenrules --load后会被清掉。想长期生效必须写进rules.d下的规则文件。有一种比较危险的操作是auditctl -e 0临时禁用审计因为一下子会丢失所有后续记录。如果要临时禁用务必立刻恢复并且心里要清楚这个时间窗口内的操作是溯源盲区。规则文件里最后还可以加入-e 2把内核审计规则设为不可变此时即便root也不能轻易修改或关闭审计只有重启系统后才能改规则这个特性后面讲对抗攻击者时再展开。3. 规则设计真正实用的监控策略3.1 确定监控范围先做一次系统“资产盘点”配规则前我会先给服务器做一次快速盘点把需要重点盯防的对象列出来。这不是随手乱写的清单越精确规则越有效日志噪音越低。我通常按这几类来列用户身份与权限文件/etc/passwd、/etc/shadow、/etc/group、/etc/sudoers、/etc/sudoers.d/登录相关文件/var/log/lastlog、/var/run/utmp、/var/run/btmp、/etc/ssh/sshd_config计划任务相关/etc/crontab、/var/spool/cron/系统启动项/etc/init.d/、systemd的unit文件目录、/etc/rc.local网络配置与主机名等/etc/hosts、/etc/hostname、网卡配置文件为什么盯这些文件因为它们对应的是“账号被人塞进去”“SSH配置被改”“计划任务被植入”“开机启动项被替换”这些典型的入侵持久化手法。审计的优先级应该围绕这些敏感改动而不是追求监控所有文件。3.2 文件监控规则写法-w 路径 -p 权限 -k 标记文件规则的典型写法是-w /etc/passwd -p wa -k file_passwd -w /etc/shadow -p wa -k file_shadow -w /etc/sudoers -p wa -k file_sudoers -w /etc/crontab -p wa -k file_crontab -w /etc/ssh/sshd_config -p wa -k file_sshd_config-w指定监控路径-p指定监听哪些操作r读、w写、x执行、a属性变更。-k是自定义标记字符串后续用ausearch -k可以按标记快速过滤。我强烈建议每条规则都带一个有意义的key没有key的规则在日志爆炸时就是灾难。要注意-p wa只监控写和属性变更不监听读操作。对/etc/passwd这种文件读操作太频繁监控读会带来大量低价值日志。但如果是需要追踪敏感信息泄露的场景才需要考虑对某些文件记录读操作比如Shadow文件的批量读取。3.3 系统调用规则命令审计与关键syscall文件规则能覆盖“文件被改”但回答不了“谁执行了什么命令”。要回答这个问题需要监控execve系统调用-a always,exit -F archb64 -S execve -k exec_command -a always,exit -F archb32 -S execve -k exec_command这里的写法拆解一下-a always,exit表示在系统调用退出时无条件记录-F archb64限定为64位系统调用后面再补一条-F archb32以兼容32位程序。-S execve指明要监控的系统调用号。在x86_64架构下execve的系统调用号是59ausearch的日志里会直接体现这个数字不需要自己换算。execve是每个新程序执行时必经的系统调用监控它基本等于拿到了全系统的命令执行记录。代价是日志量会明显上升尤其在有用户频繁执行命令的机器上。稳妥做法是先记录几天观察日志量再决定是否要按用户或路径缩小范围。3.4 一段可以直接抄的完整规则集结合前面的思路给出一个生产环境可以直接改改就用的基础规则文件放在/etc/audit/rules.d/audit.rules## 缓冲队列防丢事件 -b 8192 ## 用户与权限文件 -w /etc/passwd -p wa -k file_passwd -w /etc/shadow -p wa -k file_shadow -w /etc/group -p wa -k file_group -w /etc/gshadow -p wa -k file_gshadow -w /etc/sudoers -p wa -k file_sudoers -w /etc/sudoers.d/ -p wa -k file_sudoersd ## 登录与SSH配置 -w /etc/ssh/sshd_config -p wa -k file_sshd_config -w /var/log/lastlog -p wa -k file_lastlog -w /var/run/utmp -p wa -k file_utmp ## 计划任务 -w /etc/crontab -p wa -k file_crontab -w /var/spool/cron/ -p wa -k file_cron ## 启动项 -w /etc/init.d/ -p wa -k file_initd -w /etc/rc.d/ -p wa -k file_rcd ## 命令执行审计 -a always,exit -F archb64 -S execve -F auid!4294967295 -k exec_command -a always,exit -F archb32 -S execve -F auid!4294967295 -k exec_command-F auid!4294967295这里要解释一下auid等于4294967295表示没有关联登录用户通常是内核线程或系统启动早期进程把它们排除可以避免大量无意义记录。这个过滤条件在生产服务器上非常实用。3.5 性能与覆盖度取舍监控得多不等于监控得好刚开始用auditd的人很容易进入一个误区——把能监控的全部-w一遍系统调用规则也写成对所有文件访问都记录结果日志以每分钟几百条的速度增长真正关键的事件淹没在噪声里。我的经验是从小到大地加先加敏感文件规则和execve规则跑一周用aureport --summary看看整体分布再根据实际情况补充。如果担心命令审计噪音大可以只对特定uid或特定目录加限制比如-a always,exit -F archb64 -S execve -F uid0 -k root_exec -a always,exit -F dir/tmp -F archb64 -S execve -k tmp_exec第一条只记录root用户执行的命令适用于大多数只需要关注特权操作的场景第二条监控/tmp目录下出现的程序执行防止攻击者把恶意文件落到临时目录后运行。这种针对性规则比全量监控在性能和可用性上平衡得多。4. 日志分析从一行原始日志到完整行为还原4.1 原始日志字段拆解读得懂才能查得准/var/log/audit/audit.log里的原始日志长这样typeSYSCALL msgaudit(1720000000.123:81234): archc000003e syscall59 successyes exit0 a0... a1... ppid1234 pid5678 auid1000 uid0 gid0 commbash exe/usr/bin/bash keyexec_command第一次看这行记录会有点懵但拆开就很简单。msgaudit(1720000000.123:81234)里括号内是事件发生时间和事件序列号。archc000003e表示x86_64架构syscall59对应execve说明这是一个程序执行事件。successyes和exit0表示系统调用执行成功。ppid和pid是父进程和当前进程号auid和uid是关键中的关键。auid是审计用户ID它标识的是最初登录系统时分配的身份即使之后用su切到rootauid也保持原样。uid则是当前进程的有效用户ID此时如果已经提权到rootuid就是0。一个日志里如果同时出现auid1000 uid0基本可以直接推断有个uid 1000的普通用户切到了root执行操作。这组字段在溯源时价值极高。comm是程序名默认只保留15个字符可能被截断exe是程序的完整路径两个字段配合起来能准确识别实际启动的程序。key就是我们在规则里自定义的标记例如exec_command。4.2 aureport 快速总览先看全局再下钻日志分析第一步不是翻原始文件而是用aureport生成汇总报表快速找出异常点。# 今日登录报告 aureport --start today --login -i # 今日命令执行报告 aureport --start today --comm # 今日文件访问报告 aureport --start today --file # 今日用户活动汇总 aureport --start today --user -i # 总体统计 aureport --summary -i-i参数会把uid转换成用户名、把时间戳转换成易读格式强烈建议每次都用。aureport输出的价值在于它会按登录、命令、文件、用户等多个维度列出统计结果让分析者快速定位到“今天有哪个用户登录过”“哪个命令被频繁执行”“哪些敏感文件被访问过”这些宏观异常。看到异常点之后再进入ausearch做精确检索。4.3 ausearch 精确查询多条件组合检索ausearch是精确查询的主力工具。基础用法是按key、时间、用户、进程名组合过滤。# 按监控标记查询 ausearch -k file_passwd -i # 按时间段查询 ausearch -ts 14:00 -te 15:00 -k exec_command -i # 查询指定用户的审计事件 ausearch -ui 1000 -i # 查询特定程序名的事件 ausearch -c bash -i组合查询是实战中最常用的比如我想知道下午两点到三点之间用户1000执行过哪些命令ausearch -ts 14:00 -te 15:00 -ui 1000 -k exec_command -i如果想看原始日志里某个完整程序路径的活动直接把exe/usr/bin/python3作为grep条件grep exe/usr/bin/python3 /var/log/audit/audit.log | grep keyexec_command | head -504.4 时间线分析把零散事件串成故事分析日志最终要输出的是时间线而不是一堆零散记录。我的做法是先用aureport --login定位登录异常然后用ausearch把该时间段内所有exec_command事件拉出来按时间排序最后再对照file_标记的事件看同一进程是否还改过敏感文件。这里有个非常实用的习惯拿到一段命令序列后先关注exe字段和comm字段看实际是什么程序在跑再关注ppid和pid推断进程父子关系。攻击者的操作链通常是有逻辑的先探测、再提权、然后改文件、最后启动恶意程序。这几类操作在审计日志里会以不同key的事件分别出现分析时要串着查不能只看单一标记。5. 入侵溯源实战案例一次模拟攻击如何被完整还原5.1 模拟攻击场景设定这个案例基于我早年间帮一家公司处理过的真实情况细节做了脱敏但排查思路完全一致。场景是这样某公司一台测试服务器运行着内部使用的Web应用平时只有运维偶尔登录。某天下午负责监控的同事发现这台服务器CPU占用异常升高有个进程名奇怪的程序一直在跑初步判断是中招了。好在这台服务器在部署时用auditd做了常规监控关键文件规则和execve命令规则都在生效审计日志还完整保留着。5.2 第一步用登录报告发现“隐身账户”排查从登录视角开始。执行aureport --start today --login -i发现系统当天出现了一个从未见过的SSH登录账户sysadmin2登录时间正好在CPU异常之前的几分钟来源是一个内网IP。这个账户名字看起来很像系统管理员但运维团队根本没有这个账号。马上用grep sysadmin2 /etc/passwd核实发现/etc/passwd末尾多了一行uid为0竟然是root权限账户。到这里已经确认系统被入侵并且攻击者建立了持久化账号。5.3 第二步从文件标记追溯账户被写入的过程有了时间线索接着查/etc/passwd是怎么被修改的ausearch -k file_passwd -ts 15:30 -te 15:50 -i结果里出现一条关键记录某个进程以root身份写入了/etc/passwdauid是1002对应的exe是/usr/bin/python3。结合Web应用的目录结构可以判断这个写入动作不是运维操作而是通过Web应用上传的恶意脚本执行的。攻击者很聪明没有直接用useradd而是用Python脚本直接修改文件就是为了避开部分shell命令监控但文件监控规则没有漏掉它。5.4 第三步用命令审计还原完整操作链下一步是把这台服务器在异常时间窗口内执行过的命令全部拉出来。执行ausearch -k exec_command -ts 15:30 -te 16:30 -i | grep -E comm|exe梳理出来的关键时间线如下15:32 左右python3执行了id、uname -a、cat /etc/passwd典型的探测动作。15:38 左右从一个临时目录执行了一个名为exploit的编译程序随后进程的uid变成了0提权成功。15:43 左右修改了/etc/passwd也就是创建了后门账户那个动作。15:47 左右通过crontab写入了一条计划任务把某个脚本放入/var/spool/cron/root。15:52 左右从外部地址下载了一个二进制文件到/tmp并执行这个进程就是当时CPU飙高的元凶。整个攻击链被完整还原Web入口 → webshell → 系统探测 → 本地提权 → 创建后门账户 → 计划任务持久化 → 下载恶意程序。每一步都有对应的审计日志exec_command标记负责命令序列file_passwd标记负责文件篡改file_cron标记负责计划任务写入三个标记交叉印证形成了闭环。5.5 第四步剔除干扰噪音输出证据链分析过程中也踩了个小坑命令审计日志里有大量来自监控脚本的定期执行记录刚开始以为是恶意行为后来发现是系统正常的健康检查脚本被-w规则也捕获进来了。处理方法是直接用grep排除掉这些已知命令grep exe/usr/bin/python3 audit.log | grep -v monitor_health | head -20把干扰项剔除后剩下的记录全部与攻击行为相关。最终把攻击时间线、涉及进程、改动的文件三项信息整理成表格既用于清理加固也留作复盘。5.6 溯源之后加固清单事件结束时除了删除后门账户、清理计划任务和恶意程序外还做了几件针对性加固修复Web应用上传功能的权限校验缺陷这是初始入口。升级存在漏洞的内核组件堵住本地提权路径。限制SSH登录来源IP并要求账号使用密钥登录。把审计规则加上对/var/spool/cron/的单独监控标记细化计划任务告警。审计日志开始通过日志采集工具实时转发到集中存储防止本地日志被清。6. 常见问题与排查技巧实录6.1 auditd 服务没生效症状和排查思路装了auditd以后发现/var/log/audit/audit.log里什么都没有或者规则不生效先按这个顺序排查systemctl status auditd auditctl -s auditctl -l augenrules --loadservice is active但auditctl -s返回enabled 0说明内核审计模块没开手动执行auditctl -e 1即可。规则文件写了但auditctl -l看不到多半是改动规则文件后没有执行augenrules --load。这类问题几乎都是“忘了重新加载”导致的我的习惯是每次改完规则文件后立刻加载并查看列表确认无误再离开终端。6.2 事件风暴与磁盘爆满的应急处理审计日志在短时间内暴增最常见原因是规则范围太宽。比如写了-w / -p wa这种试图监控整个根目录的规则或者对高频文件加了读监控都会让auditd在几分钟内产生海量日志。处理方法是先停止当前规则对系统的影响临时清空规则用auditctl -D然后重新加载窄化后的规则集。同时清理体积膨胀的审计日志文件。我个人的生产经验是发生事件风暴时先删掉宽规则保留敏感文件规则和execve规则不要贸然停掉整个auditd否则风暴过后日志是空的后续分析无从下手。6.3 auid 显示为 unset 或 4294967295 是什么情况aureport或ausearch的结果里auid显示为无值或4294967295表示该进程没有关联任何登录用户通常来自系统启动阶段、内核线程或通过某些服务拉起的进程。这类事件不一定是攻击行为Filters排除它们可以大幅降低噪音。但反过来也要注意如果发现某个执行了敏感操作的进程auid全为空且时间在异常窗口内说明该进程可能是从服务进程中直接派生出来的这本身就是一条需要追查的线索。6.4 攻击者尝试清理日志的对抗策略攻击者一旦获取root权限很可能直接停止auditd或删除/var/log/audit/audit.log。应对思路有三层。第一层是权限和不可变规则规则文件末尾加-e 2后审计规则进入不可变状态此时攻击者即使拿到root执行auditctl -e 0或-D也会失败只有重启系统才能调整规则。这个特性对阻止临时关闭审计很有效但配置后如需修改规则也只能在重启后操作生产上要提前规划维护窗口。第二层是日志实时外发通过日志采集工具把/var/log/audit/audit.log实时转发到集中存储或对象存储。本地文件被删不影响远端记录这一层是溯源兜底。第三层是保留周边记录即使auditd日志被清了/var/log/messages里关于auditd服务停止的日志、系统登录记录、进程时间线都还在。攻击者“清理得很干净”往往是错觉周边痕迹足以辅助确定事件发生窗口。6.5 常见坑速查表现象原因处理建议audit.log 为空规则未加载或审计模块未开启执行auditctl -e 1augenrules --load确认auditctl -l规则重启后丢失规则只写在命令行没进 rules.d把规则写入/etc/audit/rules.d/*.rules日志量爆炸规则范围过宽或加了读监控用auditctl -D清规则改窄范围后重载auid 全是空值进程由系统服务拉起无登录用户按需排除或重点分析异常时间窗磁盘被审计日志塞满max_log_file 和轮转配置不合理调大num_logs确认ROTATE动作定期清理攻击者停止 auditd未配置不可变规则规则文件加-e 2配合日志远程转发7. 实操心得与进阶思路7.1 哪些监控规则最“加得不冤”从实际效果回看我认为最值得优先配置的规则有三类一是/etc/passwd和/etc/shadow的写监控它能盯住后门账号创建这条最常见的持久化路径二是execve系统调用规则没有它几乎无法还原命令时间线三是计划任务目录的写监控攻击者非常喜欢用cron做持久化。这三类规则覆盖了入侵链路上出现频率最高的几个动作性价比远高于监控一堆不敏感的文件。7.2 告警联动从被动查询到主动发现auditd本身不做告警但它的事件可以联动脚本。最简单的方案是写一个定时脚本统计最近5分钟是否有某个key的新事件一旦发现就推送到企业IM或邮件。核心逻辑是定期执行类似下面的命令ausearch -k file_passwd -ts today -i如果结果非空且不在已知操作清单内就推送告警。这种方案不复杂但能把auditd从“事后查询工具”变成“实时预警系统”。更精细的做法是接开源SIEM或日志平台让审计日志在平台侧做规则匹配这属于进阶方向。7.3 日志异地同步与长期留存审计日志是安全事故复盘的重要依据建议至少留存半年以上。本地磁盘有限实际做法是把/var/log/audit/整个目录交给日志采集器或脚本定时同步到集中存储。这里提醒一句同步方案一定要做数据完整性校验比如校验文件行数或哈希只做简单复制的话日志在传输中被截断或篡改可能不容易发现。7.4 进阶学习路径想深入掌握auditd可以继续研究这几个方向内核审计模块的参数调整、用户态audispd事件分发与插件机制、规则条件的更多组合写法比如按目录、按进程ID、按文件哈希、审计日志字段在不同系统调用类型下的差异。把这些吃透后你基本能在任意一台Linux服务器上快速搭建一套适合业务场景的审计体系。我在实际使用中最大的体会是auditd不是防火墙它不能阻止攻击者进来但它能在系统内核层面给每一次关键操作留下不可忽略的记录。配好一套合理的规则只需要半小时真正到了需要溯源的那天你会庆幸当初没有偷懒。上手时宁可从小而精的规则集开始也不要贪多求全先把最核心的文件、命令、计划任务盯住再慢慢扩展。这是我从几台被入侵服务器里学到的最实在的一课。
