引子：没有审计日志，入侵就是一笔糊涂账
在真实的网络安全事件中，最难回答的问题往往不是"漏洞怎么进来的"，而是“进来之后做了什么”。
一台 Linux 服务器被拿下后门，清除干净，重启上线，不到一周再次沦陷。排查了一圈，发现上一次清理根本不彻底——后门换了个路径藏了进去，而当时根本没有任何日志能证明这个后门是什么时候被创建的、是谁创建的。
这类场景在真实运维中极为常见。根本原因不是攻击者多高明，而是防御侧缺少一套完整的操作审计体系。攻击者进来后做的每一步操作——新建用户、修改配置、植入脚本、下载工具——全都没有记录。
auditd 就是来解决这个问题的。它是 Linux 内核级审计系统，能够以不可绕过的方式记录几乎所有关键系统操作，包括文件访问、进程执行、权限变更、用户登录等。与其他安全工具相比，auditd 的独特价值在于它的日志来自内核层，普通用户甚至 root 权限的攻击者都难以完全抹除这些记录（除非同时篡改日志文件本身）。
本文是 Linux 安全监控体系的核心组成部分，建议与用户管理、权限控制、服务加固等基础安全实践配合使用，形成完整的安全防护链条。
一、审计系统核心组件解析
理解 auditd，先理解它的五个组成部分及其分工：
| | | |
|---|
auditd | | | |
auditctl | | | |
augenrules | | | |
ausearch | | | |
aureport | | | |
核心日志文件：
- 路径：
/var/log/audit/audit.log - 格式：结构化文本（每条包含时间戳、PID、UID、Syscall类型、操作对象、返回值等字段）
- 重要性：这是安全事件排查的唯一可靠依据，必须设置严格权限（
chmod 600）并做好备份
💡 与 syslog 的区别：syslog（rsyslog/syslog-ng）记录的是系统服务日志（如 SSH、cron、kernel 的运行时消息），auditd 记录的是内核级审计事件，粒度更细，可追溯到具体的文件访问、进程执行和系统调用。从防御角度，两者互为补充。
二、安装与基础配置
2.1 安装 auditd
Ubuntu / Debian 系列：
# 更新软件源sudo apt update# 安装 auditd 及插件sudo apt install -y auditd audispd-plugins# 验证服务状态sudo systemctl status auditd
正常状态显示 active (running)。Ubuntu 通常默认已预装。
CentOS / RHEL 系列：
# CentOS 7（使用 yum）sudo yum install -y audit audit-libs# CentOS 8/RHEL 8（使用 dnf）sudo dnf install -y audit audit-libs# 启动并设置开机自启sudo systemctl start auditdsudo systemctl enable auditd# 验证服务状态sudo systemctl status auditd
⚠️ 重要区别：CentOS 7 中，auditd 是不可重启型服务，重启会丢失临时规则。CentOS 8+ 支持重启。生产环境强烈建议优先使用永久规则。
2.2 服务配置文件（auditd.conf）
路径：/etc/audit/auditd.conf
| | |
|---|
log_file | /var/log/audit/audit.log | |
max_log_file | 100 | |
max_log_file_action | rotate | |
num_logs | 5 | |
log_rotate | keep_logs | |
disk_full_action | syslog | |
log_format | RAW | |
修改后重启服务（CentOS 7 除外）：
sudo systemctl restart auditd
2.3 审计规则配置
审计规则决定"监控什么"，分为两类：
临时规则（快速测试用）
使用 auditctl 命令添加，重启后失效：
auditctl -w 路径/文件 -p 权限 -k 关键词
参数说明：
示例：临时监控敏感文件
# 监控 /etc/passwd 的写/属性变更sudo auditctl -w /etc/passwd -p wa -k passwd_modify# 监控 sudo 执行行为sudo auditctl -w /usr/bin/sudo -p xa -k sudo_exec# 查看当前所有临时规则sudo auditctl -l# 清空所有临时规则（危险，谨慎执行）sudo auditctl -D
永久规则（生产环境推荐）
写入规则文件，系统启动时由 augenrules 自动加载：
步骤1：编辑规则文件
sudo nano /etc/audit/rules.d/custom.rules
步骤2：添加生产级规则集
# ========== 用户账号审计 ==========-w /etc/passwd -p wa -k passwd_modify-w /etc/group -p wa -k group_modify-w /etc/shadow -p wa -k shadow_modify# ========== sudo 审计 ==========-w /usr/bin/sudo -p xa -k sudo_exec-w /etc/sudoers -p wa -k sudoers_modify-w /etc/sudoers.d/ -p wa -k sudoers_d_modify# ========== SSH 审计 ==========-w /etc/ssh/sshd_config -p wa -k sshd_config-w /var/log/auth.log -p r -k ssh_login # Ubuntu# -w /var/log/secure -p r -k ssh_login # CentOS# ========== 权限变更工具审计 ==========-w /usr/bin/chmod -p xa -k file_perm_change-w /usr/bin/chown -p xa -k file_owner_change-w /usr/bin/setfacl -p xa -k file_acl_change# ========== 系统启动脚本审计 ==========-w /etc/rc.local -p wa -k rc_local_modify-w /etc/init.d/ -p wa -k init_script_modify-w /etc/systemd/system/ -p wa -k systemd_unit_modify# ========== 网络配置审计 ==========-w /etc/hosts -p wa -k hosts_modify-w /etc/resolv.conf -p wa -k dns_config_modify-w /etc/sysctl.conf -p wa -k sysctl_modify# ========== 关键二进制文件审计 ==========-w /usr/bin/passwd -p xa -k passwd_command-w /usr/bin/gpasswd -p xa -k group_management-w /usr/bin/useradd -p xa -k user_creation-w /usr/bin/userdel -p xa -k user_deletion-w /usr/bin/crontab -p xa -k cron_job_modify-w /usr/sbin/nologin -p xa -k shell_change# ========== 日志文件审计 ==========-w /var/log/ -p wa -k log_file_modify# ========== 规则结束标记（必须添加） ==========-D-a always,exit -F arch=b64 -S all -F key=all_syscalls
步骤3：加载并验证规则
# 重新加载永久规则sudo augenrules --load# 验证规则是否生效sudo auditctl -l# 设置规则文件权限，防止被篡改sudo chmod 600 /etc/audit/rules.d/custom.rulessudo chown root:root /etc/audit/rules.d/custom.rules
⚠️ 注意：修改永久规则后，必须执行 augenrules --load 才能生效，无需重启 auditd。
三、审计日志分析方法
3.1 ausearch 按条件查询
原始日志可读性差，使用专用工具查询：
ausearch -k 关键词 -m 事件类型 -ts 开始时间 -te 结束时间 -i
核心参数：
| |
|---|
-k | |
-m | 按事件类型（PATH=文件访问、EXECVE=进程执行、USER_CMD=用户命令） |
-ts | 开始时间（YYYY-MM-DD HH:MM:SS 或 today/yesterday） |
-te | |
-f | |
-i | 人性化输出（将 UID、PID 解析为用户名、进程名） |
高频查询场景：
# 查询账号文件修改记录sudo ausearch -k passwd_modify -i# 查询今天 sudo 执行记录sudo ausearch -k sudo_exec -ts today -i# 查询文件权限变更sudo ausearch -k file_perm_change -i# 查询用户创建事件sudo ausearch -k user_creation -i# 查询失败的系统调用（入侵排查常用）sudo ausearch -m SYSCALL -f exit=-EPERM -i# 查询 SSH 登录事件sudo ausearch -k ssh_login -i
3.2 aureport 生成统计报表
将日志汇总为结构化报表，适合合规汇报：
# 生成总体事件统计sudo aureport# 生成用户操作报表（按 UID 统计次数）sudo aureport -u# 生成进程执行报表sudo aureport -x# 生成文件变更报表sudo aureport -f# 只看失败事件（入侵排查重点）sudo aureport -f --failed# 生成指定时间范围报表sudo aureport -ts 09:00 -te 18:00 -i# 生成登录事件报表sudo aureport -i -l
3.3 应急场景：直接查看原始日志
在紧急排查场景下，直接 grep 日志最快：
# 查看最近 sudo 相关日志sudo tail -50 /var/log/audit/audit.log | grep sudo_exec# 查找所有 passwd 相关事件sudo grep -E "passwd|useradd|userdel" /var/log/audit/audit.log# 查找异常时间段的敏感操作sudo ausearch -ts 02:00 -te 05:00 -k ssh_login -i
💡 审计视角：异常登录时间（如凌晨2-5点）+ 非标准用户 + 敏感命令执行，是内部威胁和外部入侵的典型组合信号。
四、高级场景配置
场景1：监控数据目录（数据防篡改）
监控 /data 及其子目录的所有操作，检测数据被窃取或篡改的行为：
# 添加规则echo "-w /data/ -p rwxa -k data_access" | sudo tee -a /etc/audit/rules.d/custom.rulessudo augenrules --load# 查询所有 /data 访问记录sudo ausearch -k data_access -i
扩展监控：数据库文件（示例 MySQL）
echo "-w /var/lib/mysql/ -p rwxa -k mysql_data" | sudo tee -a /etc/audit/rules.d/custom.rulessudo augenrules --load
场景2：用户生命周期审计（账号安全）
追踪用户创建、修改、删除的完整生命周期：
# 添加规则echo "-w /usr/bin/useradd -p xa -k user_creation" | sudo tee -a /etc/audit/rules.d/custom.rulesecho "-w /usr/bin/userdel -p xa -k user_deletion" | sudo tee -a /etc/audit/rules.d/custom.rulesecho "-w /usr/bin/usermod -p xa -k user_modify" | sudo tee -a /etc/audit/rules.d/custom.rulesecho "-w /usr/bin/passwd -p xa -k password_change" | sudo tee -a /etc/audit/rules.d/custom.rulessudo augenrules --load# 查询所有账号变更sudo ausearch -k user_creation -isudo ausearch -k user_deletion -isudo ausearch -k password_change -i
⚠️ 与 Hydra 暴力破解的关联：暴力破解成功后，攻击者往往会创建新用户作为持久化后门。监控 useradd/usermod 与 ssh_login 失败日志联动分析，可以发现"先大量失败登录→随后出现新用户"的可疑模式。
场景3：SSH 暴力破解监控与联动分析
SSH 是最常见的暴力破解入口，配合 auditd 可以构建完整的登录审计体系：
# SSH 配置审计echo "-w /etc/ssh/sshd_config -p wa -k sshd_config" | sudo tee -a /etc/audit/rules.d/custom.rules# 登录日志审计echo "-w /var/log/auth.log -p r -k ssh_login" | sudo tee -a /etc/audit/rules.d/custom.rules # Ubuntu# echo "-w /var/log/secure -p r -k ssh_login" | sudo tee -a /etc/audit/rules.d/custom.rules # CentOS# 失败登录审计echo "-w /var/log/btmp -p wa -k failed_login" | sudo tee -a /etc/audit/rules.d/custom.rulessudo augenrules --load# 查看暴力破解迹象：短时间内大量失败登录sudo ausearch -k failed_login -ts recent -i | awk '{print $NF}' | sort | uniq -c | sort -nr | head -10
联动分析示例： 当发现异常登录后，可按以下顺序排查：
1. aureport -l -i → 确认登录时间和来源IP2. ausearch -k ssh_login -i → 查看完整的SSH登录日志3. ausearch -k sudo_exec -ts today → 查看登录后的特权操作4. ausearch -k user_creation -i → 排查是否有新增账户5. ausearch -k init_script_modify → 排查开机自启是否被篡改
场景4：容器环境的审计（与 Kali Docker 场景关联）
在使用 Docker 容器做渗透测试时，宿主机层面的审计同样重要：
# 监控 Docker 守护进程配置-w /etc/docker/daemon.json -p wa -k docker_config-w /var/lib/docker/ -p wa -k docker_data# 监控容器运行时行为（需要开启 Docker 日志驱动）-w /var/lib/containerd/ -p wa -k containerd_data-w /run/containerd/ -p wa -k containerd_runtime# 监控 Kubernetes 相关文件（如适用）-w /etc/kubernetes/ -p wa -k k8s_config-w /var/log/pods/ -p wa -k k8s_pods
💡 Kali Docker 场景的特殊性：在 Kali 容器中进行渗透测试时，容器的操作会被宿主机审计系统记录。如果 Kali 容器被用于对外部系统进行扫描，这些行为在宿主机层面是透明的，但容器内的操作日志需要在 Kali 虚拟机内部通过 auditd 单独记录。
五、Linux 日志体系全景图
理解 auditd 在整个 Linux 日志体系中的位置，有助于选择合适的工具：
| | | |
|---|
| /var/log/audit/audit.log | | |
| /var/log/messages | | |
| /var/log/auth.log | | |
| /var/log/wtmp | | |
| dmesg | | |
| | | |
| | | |
💡 最佳实践：建立多层日志体系。应用层日志由各服务独立记录，系统层由 rsyslog 汇总，审计层由 auditd 精细记录。三层互补，缺一不可。生产环境建议将 auditd 日志通过 audisp-remote 或 rsyslog 转发至集中日志服务器（ELK、Graylog），防止本地日志被攻击者篡改。
六、故障排查与注意事项
6.1 常见问题解决
| | |
|---|
| | 执行 sudo auditd -t 测试配置；检查 chmod 600 /var/log/audit/audit.log；查看 sudo journalctl -u auditd 定位原因 |
| | 确认规则文件在 /etc/audit/rules.d/*.rules；执行 sudo augenrules --load；检查 sudo auditctl -l |
| | 调整 auditd.conf 中的 max_log_file 和 num_logs；定期清理 sudo rm /var/log/audit/audit.log.* |
| | 永久规则写入 /etc/audit/rules.d/ 目录；避免使用临时规则 |
6.2 安全加固建议
日志文件本身的安全：
# 设置日志文件严格权限（可能过于严格影响可审计性，需根据实际需要酌情调整）sudo chmod 600 /var/log/audit/audit.logsudo chmod 640 /etc/audit/rules.d/*.rulessudo chmod 750 /var/log/audit/# 将日志实时同步到远程服务器（防止篡改）# 配置 /etc/audisp/audisp-remote.conf 指向集中日志服务器
性能影响控制：
auditd 基于内核审计钩子（audit hook），每条系统调用都经过审计层。规则过多会导致性能下降：
- ✅ 推荐监控：账号文件、sudo、SSH、数据目录、启动脚本（20-30条规则）
定期巡检机制：
# 每天定时执行，输出异常报告sudo aureport -f --failed -i | mail -s "Daily Audit Report" admin@example.com
6.3 与等保/CIS 合规的对应关系
| |
|---|
| 监控 /etc/passwd、useradd、usermod、userdel |
| |
| |
| |
| 监控 /etc/sudoers、/etc/ssh/sshd_config、sysctl.conf |
| |
七、攻防视角总结
审计的不可替代性
从攻击者视角看，auditd 是最难规避的检测机制之一——它工作在内核层，不依赖任何用户态进程。相比之下：
- iptables/netfilter
- syslog
- 进程监控工具
但 auditd 的日志文件本身仍然是可删除的，所以生产环境中实时转发至远程日志服务器是关键。
快速入侵排查清单
遇到安全告警时，按以下顺序排查：
第一步：查失败事件→ sudo aureport -f --failed第二步：查异常登录→ sudo ausearch -k failed_login -ts recent -i→ sudo aureport -l -i第三步：查登录后的操作→ sudo ausearch -k sudo_exec -ts today -i→ sudo ausearch -k dangerous_rm -i第四步：查账户变更→ sudo ausearch -k user_creation -i→ sudo ausearch -k user_deletion -i第五步：查持久化手段→ sudo ausearch -k init_script_modify -i→ sudo ausearch -k systemd_unit_modify -i→ sudo ausearch -k cron_job_modify -i
Linux 安全体系全景
本文覆盖了 Linux 安全监控的核心环节。从整体安全体系来看，各环节相互依存：
用户与权限（/etc/passwd, sudoers）→ 审计日志（auditd）→ 日志分析（ausearch/aureport） ↑ ↓ 账号生命周期管理 与SSH审计、iptables、日志体系联动
审计不是孤立的工具，它需要与账户管理（防止弱口令和后门账户）、防火墙（限制入站访问）、SSH 加固（禁用密码登录、使用密钥）、日志集中（防止篡改）等措施配合，才能形成完整的安全防护体系。
结语
auditd 是 Linux 安全监控的基础设施，从安装到配置再到分析，全流程可操作。
核心三步：
花 30 分钟配好 auditd，等安全事件发生时，才能真正做到"有据可查、有痕可追"。对于 IT 审计人员来说，auditd 日志是合规检查和内部审计的核心证据来源；对于安全工程师来说，它是入侵检测和溯源分析的第一手资料。
建议从账号文件监控起步（/etc/passwd、/etc/shadow、/etc/sudoers），逐步扩展到登录审计、数据目录监控、容器环境审计，形成完整的安全审计体系。
10个月宝宝每天需要喝多少奶粉？
