Ubuntu系统配置auditd监控/etc敏感文件并实时告警

在Ubuntu服务器环境中，/etc目录下存放着passwd、shadow、sudoers、ssh等核心配置文件。任何对这些文件的非授权修改、读取或删除，都可能导致权限提升、持久化后门或服务中断。单纯依靠文件完整性校验工具无法捕捉到读取行为，而auditd作为Linux内核级的审计框架，能够精确捕获谁、在什么时间、通过什么进程、对哪个文件执行了什么操作，并支持触发实时告警。下面直接进入配置与落地环节。

auditd通常已预装在Ubuntu 20.04/22.04/24.04系统中。若未安装，执行以下命令完成部署并确保服务自启动：

sudo apt update && sudo apt install auditd -y
sudo systemctl enable auditd && sudo systemctl start auditd
sudo systemctl status auditd

确认内核审计框架已启用：

sudo auditctl -s

输出中enabled值为1且flag值为1或2即表示正常。如果enabled为0，需检查内核启动参数中是否包含audit=1，通常Ubuntu默认已开启。

并非/etc下所有文件都需要监控，过度审计会产生海量日志并影响性能。建议优先覆盖以下关键目标：

/etc/passwd —— 账户信息库，篡改可创建隐藏账户

/etc/shadow —— 密码哈希存储，读取即可能被离线破解

/etc/group —— 用户组定义，提权路径之一

/etc/gshadow —— 组密码及管理员信息

/etc/sudoers 及 /etc/sudoers.d/ —— sudo授权配置，直接决定权限边界

/etc/ssh/sshd_config —— SSH服务配置，修改可植入后门或弱化加密

/etc/pam.d/ —— 认证模块配置，单点登录和身份验证的核心

/etc/crontab 及 /etc/cron.*/ —— 定时任务，持久化攻击的常用落脚点

/etc/hosts —— 本地DNS解析，可被用于流量劫持

/etc/resolv.conf —— DNS服务器指向，同样涉及流量劫持风险

/etc/environment 及 /etc/profile —— 全局环境变量，可能被注入恶意路径

可根据实际业务场景增减，但上述清单已覆盖绝大多数Linux安全基线要求。

auditd规则文件通常位于/etc/audit/rules.d/目录，建议创建专门规则文件，例如/etc/audit/rules.d/10-sensitive-etc.rules。规则语法需精确指定系统调用和文件路径。

针对敏感文件的写入、属性变更和删除操作，使用-w参数配合-p wa标记：

# 监控/etc/passwd和/etc/shadow的写入与属性变更
-w /etc/passwd -p wa -k etc_passwd_shadow
-w /etc/shadow -p wa -k etc_passwd_shadow

# 监控/etc/group和/etc/gshadow
-w /etc/group -p wa -k etc_group_gshadow
-w /etc/gshadow -p wa -k etc_group_gshadow

# 监控sudoers文件及目录
-w /etc/sudoers -p wa -k etc_sudoers
-w /etc/sudoers.d/ -p wa -k etc_sudoers

# 监控SSH配置
-w /etc/ssh/sshd_config -p wa -k etc_ssh

# 监控PAM配置目录
-w /etc/pam.d/ -p wa -k etc_pam

# 监控定时任务相关
-w /etc/crontab -p wa -k etc_cron
-w /etc/cron.d/ -p wa -k etc_cron
-w /etc/cron.daily/ -p wa -k etc_cron
-w /etc/cron.hourly/ -p wa -k etc_cron
-w /etc/cron.monthly/ -p wa -k etc_cron
-w /etc/cron.weekly/ -p wa -k etc_cron

# 监控hosts和resolv.conf
-w /etc/hosts -p wa -k etc_network
-w /etc/resolv.conf -p wa -k etc_network

# 监控环境变量配置
-w /etc/environment -p wa -k etc_env
-w /etc/profile -p wa -k etc_env

-p wa表示监控写入和属性变更操作。若同时需要监控读取行为，可改为-p rwa，但务必注意：监控读取会产生极大量日志，尤其在系统认证频繁时。对于shadow文件，读取监控具有较高安全价值，可单独设置：

-w /etc/shadow -p rwa -k etc_shadow_read

上述规则中的-k参数定义了审计事件的过滤键值，后续查询和告警将依赖这些键值进行筛选。

部分文件可能位于挂载点边界或符号链接指向的位置，-w规则可能失效。此时需使用系统调用级规则。例如监控所有对/etc目录下文件的权限变更操作：

-a always,exit -F dir=/etc/ -F perm=wa -F key=etc_syscall_monitor

此规则捕获任何进程对/etc目录内文件执行的写入和属性修改系统调用，覆盖面更广但资源消耗也更大，建议仅在-w规则无法覆盖时使用。

规则文件编写完成后，重启auditd服务加载新规则：

sudo systemctl restart auditd

或直接使用auditctl加载：

sudo auditctl -R /etc/audit/rules.d/10-sensitive-etc.rules

验证规则已生效：

sudo auditctl -l

输出应列出所有已配置的监控项。此时可进行测试，例如使用touch或echo修改/etc/passwd的时间戳或内容，然后查看审计日志：

sudo ausearch -k etc_passwd_shadow

日志中应包含进程名、PID、用户ID、时间戳、操作类型等详细信息。确认日志正常生成后再进入告警环节。

auditd本身不具备告警推送功能，但可通过其dispatcher组件audisp或直接使用插件将事件转发至外部处理。推荐两种成熟方案：audisp-af_unix结合自定义脚本，或使用audisp-remote发送至集中日志平台。这里以最直接的自定义脚本方式说明。

首先创建告警脚本，例如/usr/local/bin/audit-alert.sh：

#!/bin/bash
# 接收auditd通过pipe传递的事件
while IFS= read -r line; do
    # 提取键值字段
    key=$(echo "$line" | grep -oP 'key="\K[^"]+')
    timestamp=$(echo "$line" | grep -oP 'msg=audit\(\K[0-9.]+')
    comm=$(echo "$line" | grep -oP 'comm="\K[^"]+')
    uid=$(echo "$line" | grep -oP 'uid=\K[0-9]+')
    
    # 根据键值分类处理
    case "$key" in
        etc_passwd_shadow|etc_group_gshadow|etc_sudoers|etc_ssh|etc_pam|etc_cron|etc_network|etc_env|etc_shadow_read)
            # 构造告警消息
            message="[auditd告警] 敏感文件操作 - 键值: $key, 时间: $timestamp, 进程: $comm, 用户ID: $uid"
            # 发送告警，可替换为webhook、邮件、短信等
            echo "$message" >> /var/log/audit-alert.log
            # 示例：通过webhook发送至钉钉/企业微信/飞书
            # curl -H "Content-Type: application/json" -d "{\"msgtype\":\"text\",\"text\":{\"content\":\"$message\"}}" https://your-webhook-url
            ;;
    esac
done

赋予执行权限：

sudo chmod +x /usr/local/bin/audit-alert.sh

接下来配置audisp插件。编辑/etc/audit/plugins.d/af_unix.conf，确保active为yes。然后创建/etc/audit/audisp-remote.conf（若使用远程方案）或直接利用syslog插件。更轻量的方式是使用auditd的dispatcher直接调用脚本，需修改/etc/audit/auditd.conf中dispatcher项：

dispatcher = /usr/local/bin/audit-alert.sh

重启auditd后，所有审计事件将逐行传递给该脚本。脚本内部通过键值过滤出敏感文件相关事件，并执行告警动作。若事件量极大，建议改用audisp-af_unix结合专用守护进程，避免脚本处理成为瓶颈。

在上述脚本的告警发送部分，替换为对应平台的Webhook URL即可。以企业微信机器人为例：

curl -H "Content-Type: application/json" \
-d "{\"msgtype\":\"text\",\"text\":{\"content\":\"$message\"}}" \
https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=YOUR_KEY

钉钉机器人需注意加签或关键词匹配，飞书类似。建议将Webhook URL和密钥存储在独立配置文件中，权限设为600，避免泄露。

审计日志默认写入/var/log/audit/audit.log，文件增长迅速。需配置logrotate避免磁盘写满。创建/etc/logrotate.d/auditd：

/var/log/audit/audit.log {
    daily
    rotate 30
    compress
    delaycompress
    missingok
    notifempty
    postrotate
        /usr/sbin/service auditd restart > /dev/null 2>&1 || true
    endscript
}

同时调整/etc/audit/auditd.conf中的日志保留策略：

max_log_file = 256
max_log_file_action = rotate
num_logs = 10

可根据磁盘容量适当调整。对于高安全需求环境，建议将审计日志实时转发至远端集中日志平台，如ELK、Graylog或Loki，既保证日志完整性又便于长期检索。

审计规则会消耗CPU和I/O资源，尤其在大量文件操作的场景下。优化建议：

1. 避免使用-p rwa监控高频读取文件，除非确有必要。对shadow的读取监控可保留，但需评估认证频次。

2. 使用-F arch=b64限定64位系统调用，减少无关事件。

3. 善用键值分类，告警脚本中仅处理目标键值，其余事件快速丢弃。

4. 定期审计规则集，移除不再需要的监控项。

5. 考虑使用auditd的缓冲机制，在auditd.conf中调整q_depth和freq参数以平衡实时性与吞吐量。

配置完成后务必进行端到端测试。使用非特权用户尝试读取/etc/shadow：

cat /etc/shadow

检查/var/log/audit-alert.log或Webhook接收端是否收到告警。再尝试修改/etc/passwd：

sudo sed -i '1s/^/#test/' /etc/passwd

确认告警触发并包含正确的进程名（sed）和用户ID。若未收到告警，排查auditd日志是否生成、脚本是否有执行权限、Webhook URL是否可达。

攻击者获得root权限后可能会停止auditd或删除规则。可通过设置不可变规则增加对抗难度。在规则文件末尾添加：

-e 2

该指令使规则集不可变，任何修改或删除规则的尝试都会被拒绝，且auditd无法停止。重启系统后规则自动生效。注意：启用不可变规则后，修改规则需重启并进入单用户模式，务必在确认规则无误后再添加此指令。

auditd文件监控是主机入侵检测体系的重要一环，但不应孤立使用。建议配合以下措施：

- 使用aide或tripwire进行文件完整性基线校验，定期对比哈希值。

- 通过AppArmor或SELinux实施强制访问控制，限制进程对/etc的访问权限。

- 配置auditd监控用户提权行为（sudo、su），与文件监控形成关联分析。

- 将审计事件接入SIEM系统，结合网络流量和登录日志进行多维度威胁检测。

通过上述组合，Ubuntu服务器对敏感配置文件的非授权操作将具备实时发现、精准溯源和快速响应的能力。