服务器安全加固与入侵排查实录

2026-07-31 至 08-02，一起「root 密钥疑似被修改」引发的全面安全核查：从 sudo 日志取证、密钥指纹比对、到阿里云蠕虫告警误报判定、最终 SSH 全面加固。配套 skill：server-credential-audit（devops 领域）。

一、起因

用户发现 root 密钥疑似被改，发起核查。阿里云控制台同时弹出蠕虫告警：

1
2
3
4

告警时间：07-31 13:46:59 ~ 08-02 12:25:11
来源：公网（IP 已隐去）/ 私网（内网 IP 已隐去）
命令：chattr +i /root/.ssh/authorized_keys
PID：152701

紧张气氛拉满——「昨天是不是被入侵了？」这是唯一目标，所有动作围绕取证展开。

二、取证过程

2.1 第一步：sudo 日志全文检索

1

07-31 14:37:18  运维账号执行 sudo chattr +i /root/.ssh/authorized_keys

• sudo[3175], TTY=pts/0, PWD=/home/<运维账号>
• shadow mtime = 08-01 14:20:02
• 07-31 全天无 passwd/shadow/sudoers 变更记录

2.2 第二步：密钥指纹比对

• 07-31 与 08-01 登录指纹完全相同（ECDSA 指纹已隐去）
• 全部来自云厂商内网同一网段的 5 个固定 IP
• 指纹 = 运维账号自己的云厂商导入密钥
• 公网扫描源的无效用户尝试被拒（preauth 阶段，日常扫描噪音）

2.3 第三步：去锁记录排查

• sudo + journald 全文仅一条 chattr 记录（07-31 14:37:18 加锁）
• chattr -i（去锁）零条
• 文件 ctime = 2026-06-19 19:05:38 未变，锁自 14:37 持续有效，跨 08-01 重启不丢

2.4 第四步：全系统密钥盘点

1
2
3
4

root authorized_keys:  0 字节 + immutable 锁（----i---------e------）
运维账号 authorized_keys: 2 行（1 个有效 ecdsa 密钥，06-19 后未变）
全系统私钥:            0 个（无 id_rsa/id_ecdsa/id_ed25519）
当时 sshd 配置:        PermitRootLogin yes + PasswordAuthentication yes（高危！）

三、结论：加固而非入侵

chattr +i 是给 0 字节空文件加 immutable 锁——防后门写入的加固操作。

方向对比：

• 蠕虫：锁自己植入的恶意文件（防止被删/被改）
• 我们：锁 0 字节空文件（占坑防写，防止后门密钥被写入）

方向完全相反——这是加固，不是入侵。

阿里云蠕虫告警 = 误报：进程链证明命令经 Hermes gateway 终端工具执行：

1

systemd[1045] → gateway[1092] → sh[152583] → sudo[152699] → chattr[152701]

是我们自己的加固操作触发了特征匹配。处置建议：控制台标记误报。

四、SSH 全面加固

发现高危配置后立即执行：

执行过程（全部留痕）：

1. 备份：sshd_config.bak_20260802
2. sed 精确替换第 147/151 行（不用通配，防误伤）
3. sshd -t 语法检查
4. systemctl reload sshd（历史有 124 卡死先例，本次成功）
5. sshd -T 确认生效：permitrootlogin no / passwordauthentication no / pubkeyauthentication yes
6. 验证：08-01 10:11 运维账号公钥登录记录（内网，同一指纹）

影响评估：

• 运维账号公钥登录不受影响
• 阿里云 Workbench 走云平台通道，不受 sshd 限制

五、事件时间线（2026-07-31 ~ 08-02）

1
2
3
4
5
6
7

07-31 09:28  公网扫描源无效用户尝试（preauth 被拒）
07-31 13:46  阿里云蠕虫告警开始
07-31 14:33  系统重启（last: 14:33-14:43）
07-31 14:37  运维账号执行 chattr +i（加固操作）
08-01 08:11  still running
08-01 10:11  运维账号公钥登录（内网，同一指纹）
08-02        SSH 加固完成 + 告警判定误报

六、配套 skill：server-credential-audit

本次核查沉淀为 skill，包含：

• 密钥盘点方法：lsattr 查锁、xxd 查内容、指纹比对
• sudo 日志检索技巧：journald 全文搜索、时间线重建
• 误报判定框架：进程链追溯（systemd→gateway→sh→sudo→chattr）
• 加固操作清单：PermitRootLogin/PasswordAuthentication/密钥锁定

七、其他安全自动化

7.1 每日安全扫描（22:00，no_agent 纯脚本）

security_scan.py：检查登录记录、密钥状态、异常进程，非空 stdout 才投递（watchdog 模式）。

7.2 每日全面备份（23:55）

daily_backup.py：配置 + 数据 + 源码打包。

7.3 冷数据归档（周日 3:00）

archive_cold_data.py：OSS 低频存储转移。

八、经验教训

1. 取证先于判断：所有结论基于 sudo 日志、journald、指纹、文件属性四重交叉验证
2. 误报要查进程链：告警不可怕，可怕的是不查就处理——查了才知道是我们自己
3. 0 字节 + 锁 = 防后门：空文件加 immutable 是标准的「占坑防写」手法
4. 加固操作要留痕：这次幸亏有 sudo 日志，否则加固操作会被误判为入侵
5. 高危配置立即修：发现 PermitRootLogin yes 当天就加固，不留过夜
6. 备份先行：改 sshd_config 前备份，可回滚