从一次“误删”事故复盘：我是如何用AIDE在CentOS 7上快速定位被篡改的/etc/passwd文件
从一次“误删”事故复盘：我是如何用AIDE在CentOS 7上快速定位被篡改的/etc/passwd文件
那天下午3点27分，运维群突然炸出一连串消息："生产服务器上有个开发账号登录失败！"、"sudo权限异常！"、"有人动过passwd文件吗？"。作为值班管理员，我立刻意识到这可能不是简单的密码错误——系统关键文件被篡改的警报在脑海中响起。本文将完整还原这次应急响应过程，展示如何通过AIDE（Advanced Intrusion Detection Environment）在15分钟内锁定异常点，并分享一套可复用的Linux文件完整性监控方案。
1. 事故现场：异常登录引发的连锁反应
问题最初表现为开发团队无法通过SSH登录测试服务器。检查/var/log/secure日志时发现大量认证失败记录：
Jul 15 15:23:01 test-server sshd[12345]: Failed password for dev-user from 192.168.1.100 port 54322 ssh2更可疑的是，该账号前一天还能正常使用。快速执行getent passwd dev-user命令后，终端返回了**"无此用户"**的空白结果——这显然不是密码错误该有的表现。此时需要立即确认：
- 是人为误操作删除账号？
- 还是恶意攻击者篡改了用户数据库？
关键操作节点：
- 优先备份当前
/etc/passwd和/etc/shadowcp /etc/passwd /root/passwd.bak.$(date +%F_%H%M) cp /etc/shadow /root/shadow.bak.$(date +%F_%H%M) - 对比备份服务器上的同名文件
- 检查文件修改时间戳
stat /etc/passwd | grep Modify
2. AIDE快速部署与基准建立
幸好这台CentOS 7服务器早已部署AIDE监控。若需从零开始安装配置，以下是经过实战验证的极简流程：
2.1 安装与初始化
# 安装EPEL源（CentOS 7默认仓库版本较旧） yum install -y epel-release # 安装AIDE yum install -y aide配置文件优化建议：默认的/etc/aide.conf会监控大量非关键路径，建议注释掉以下内容以提升效率：
#/var/log/.* PERMS #/var/spool/.* PERMS2.2 建立基准数据库
# 首次初始化（耗时约2-15分钟，取决于监控文件数量） aide --init # 将生成的数据库设为基准版本 mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz重要提示：基准数据库应存储在只读介质（如CD-ROM）或异地服务器，防止攻击者同时篡改数据库和系统文件
3. 关键分析：定位passwd文件异常
执行快速检测命令后，AIDE输出了令人警觉的结果：
aide --check | grep -A10 '/etc/passwd'输出片段显示：
/etc/passwd: size changed (记录值: 1204 -> 1256) /etc/passwd: sha256校验值不匹配 (原值: a1b2... -> 现值: x9y8...)通过diff对比当前文件与备份，发现攻击者插入了伪装成普通用户的恶意账号：
+attacker:x:0:0:root:/root:/bin/bash入侵时间轴重建：
- 15:05
/etc/passwd被修改（通过stat确认） - 15:08 攻击者通过新增账号获得root权限
- 15:23 开始暴力破解其他账号
4. 应急响应与系统加固
4.1 立即处置措施
- 隔离受影响服务器：
iptables -A INPUT -p tcp --dport 22 -j DROP - 从备份恢复被篡改文件：
cp /root/passwd.bak.2023-07-14 /etc/passwd - 审计所有特权账号：
awk -F: '$3 == 0 {print}' /etc/passwd
4.2 AIDE监控增强方案
修改/etc/aide.conf增加敏感文件监控策略：
# 关键配置文件监控（含属性与内容校验） /etc/passwd$ CONTENT_EX /etc/shadow$ CONTENT_EX /etc/sudoers$ CONTENT_EX自动化巡检脚本（保存为/usr/local/bin/aide_check.sh）：
#!/bin/bash OUTPUT=$(aide --check 2>&1) if [ $? -ne 0 ]; then echo "$OUTPUT" | mail -s "AIDE警报: $(hostname)文件变更" admin@example.com # 自动锁定异常文件 echo "$OUTPUT" | awk -F: '/changed/ {print $1}' | xargs chattr +i fi添加到cron每日执行：
echo "0 3 * * * root /usr/local/bin/aide_check.sh" > /etc/cron.d/aide-check5. 深度防御：构建文件完整性监控体系
单一工具不足以应对高级威胁，推荐分层防护策略：
| 防护层 | 实施工具 | 检测频率 | 响应措施 |
|---|---|---|---|
| 实时监控 | auditd+watch规则 | 持续 | 触发告警并记录操作日志 |
| 定期校验 | AIDE+Tripwire | 每日 | 邮件通知管理员 |
| 基线比对 | Git版本控制 | 提交时 | 阻止非授权修改 |
| 行为分析 | Osquery+FIM | 实时 | 阻断可疑进程 |
高阶技巧：对/etc/passwd启用inotify实时监控：
inotifywait -m -e modify /etc/passwd | while read; do logger -t SECURITY "WARNING: /etc/passwd modified!" aide --check /etc/passwd | mail -s "紧急: passwd文件变更" admin@example.com done这次事件最终确认是某位运维同事误操作导致，但整个过程暴露出我们在变更管理和监控覆盖上的不足。现在团队所有关键服务器都实现了：
- AIDE每日自动巡检
- 关键配置文件版本控制
- 实时inotify监控+auditd日志审计
最深刻的教训是：当AIDE首次报警时，我们曾误以为是正常变更没有及时核查——安全工具的价值取决于响应速度。现在任何AIDE告警都会触发三级响应机制，确保30分钟内必有人工验证。