OpenClaw 在一次服务器入侵应急中的实战复盘

前言

很多人聊 AI Agent 时，喜欢谈"自动化办公""内容生产""信息检索"，但我一直觉得，真正能拉开差距的，是它在真实线上事件里的表现。

这次我想复盘的，不是一次普通的自动化小任务，而是一场比较完整的服务器安全应急：从发现异常 SSH 登录，到定位被污染的公钥信任链；从识别木马落地目录，到发现伪装进程和对外扫描行为；再到后续清除、补巡检、修告警链路，基本走完了一次比较典型的 Linux 主机入侵处理闭环。

而这次最值得讲的，不只是"服务器被入侵了"，而是：

在这次事件里，OpenClaw 不只是一个会说话的助手，而是一个真正参与排查、执行、验证、整理和持续治理的 Agent。

如果只看结果，可以简单概括成一句话：

• 发现了异常 root 公钥登录；
• 找到了活跃木马与伪装进程；
• 清掉了恶意样本与残留；
• 补上了更有针对性的安全巡检；
• 顺手还发现并修复了多条 cron 告警链路里"会制造噪音"的结构性问题。

但如果只说结果，就低估了 OpenClaw 在这件事里的价值。

这篇文章想重点讲的，是：

1. OpenClaw 在这类真实应急中，到底发挥了什么作用；
2. 它为什么不只是"帮忙执行命令"，而是真正改变了处理节奏；
3. 它适合接管哪些环节，不适合接管哪些环节。

---

一、这次事件里，OpenClaw 做的不是"问答"，而是"连续作战"

很多人对 AI 助手的想象，还是停留在这种模式：

• 你问一句，它答一句；
• 你让它给个命令，它给你一条命令；
• 最多帮你写个脚本，剩下的你自己做。

但这次事件里，真正有价值的不是"它知道某个知识点"，而是它能在一个持续变化的问题里做这些事：

• 读取日志和配置文件；
• 追查 SSH 登录来源；
• 对比 authorized_keys 与可疑指纹；
• 执行系统命令核对进程和外联；
• 根据发现继续深入排查；
• 在清理后再次复查，避免只做半截；
• 把零散的调查结果整理成结构化结论；
• 最后再反过来改进定时巡检和告警链路。

这其实已经不是"聊天"，而是很接近一个真正的应急协作者了。

从体感上说，这和传统自己手动做排障最大的差别是：

你不需要每一步都重新把上下文装回脑子里。

人在应急时最耗精力的，不只是执行命令，而是：

• 记住上一轮看到了什么；
• 想清楚下一步该往哪里追；
• 不要在各种日志和目录之间丢失主线；
• 清理完之后还能记得回来做复查和补洞。

OpenClaw 在这次事件里的价值，很大一部分就在这里：

它把一场本来容易"查着查着就散掉"的排障，尽量维持成了一个有主线的连续流程。

---

二、OpenClaw 是怎么帮我一步步坐实"这不是误报"的

这次最开始并不是直接拿到"服务器已入侵"的结论，而是从一些碎片信号开始的。真正把这些线索串起来，恰恰是 Agent 最适合做的部分。

1. 它先从 SSH 异常登录开始收口

通过日志排查，最终确认存在 root 账号的成功 SSH 公钥登录记录，来源 IP 为：

• 213.136.70.167

这一步看起来平常，但它的重要性非常高。因为它把问题从"可能有异常"升级成了"已经有人进来过"。

OpenClaw 在这里的价值不是"知道 Accepted publickey 的含义"，而是：

• 主动去查日志；
• 从日志里抓关键证据；
• 把"成功登录"和后续的文件、进程问题关联起来。

这一步一旦坐实，后面的排查方向就会非常明确：

• 不是在猜"是不是误报"；
• 而是在追"对方进来之后做了什么"。

2. 它继续往 authorized_keys 追

随后，OpenClaw 继续核查 root 的 authorized_keys，确认其中存在可疑公钥，指纹为：

• SHA256:MkYY9qiVsFGBC5WkjoClCkwEFW5iSjcGQF7m4n4H7Cw

并且进一步追查到该 key 曾通过远程命令写入 SSH 信任链。

在真实安全事件里，这一步非常关键。

因为真正危险的不是单次登录，而是：

SSH 信任链被污染后，对方可以反复回来。

OpenClaw 在这里的作用，是把"异常登录"继续推进成"异常持久化入口"。

这也是我越来越觉得 Agent 适合做安全排查的原因：

它不是只回答"公钥是什么"，而是会沿着这条线继续追下去。

---

三、OpenClaw 不只是会读日志，它还能把文件、进程和网络行为串成一条链

如果说 SSH 登录和公钥污染证明了"有人进来过"，那接下来的问题就是：

他进来之后到底做了什么？

这次排查中，OpenClaw 很快把关注点拉到了临时目录和异常路径上，最终确认了一组高度可疑的落地文件：

• /var/tmp/.X7asjj/.rsync/a/init01
• /var/tmp/.X7asjj/.rsync/c/kthreadadd64
• /var/tmp/.kswapd00
• /tmp/.kswapd00
• /tmp/.X23-unix/dota3.tar.gz

光有这些文件，还只能说明"有木马样本痕迹"；

更关键的是，它继续去看：

• 哪些进程还活着；
• 这些进程的真实路径在哪里；
• 它们有没有对外连接。

最后确认到的活跃恶意进程是：

• 实际路径：/var/tmp/.X7asjj/.rsync/c/kthreadadd64
• 进程展示伪装成：/usr/sbin/httpd

并且它还存在对外扫描 SSH 22 端口的行为。

这一段是我觉得 OpenClaw 很像"真正干活的安全助手"的地方。

因为一个人手动做的时候，很容易出现这种断裂：

• 看完日志，忘了继续看文件；
• 看完文件，没回头看进程；
• 杀完进程，没再核网络行为；
• 最后只留下几个零散证据，没能把"入侵 -> 落地 -> 执行 -> 对外扫描"串起来。

而这次 OpenClaw 实际上帮我把它串成了一条完整链条：

1. 异常 SSH 成功登录；
2. authorized_keys 被污染；
3. 临时目录落地恶意样本；
4. 木马进程伪装成系统服务；
5. 进程处于活跃执行状态；
6. 存在对外 SSH 扫描行为。

这已经不是"帮忙查一条命令"的水平了，而是真正开始具备事件理解能力。

---

四、OpenClaw 最大的价值之一：它不只会查，还会顺着查到"该先干什么"

应急处理里，顺序非常重要。

如果顺序错了，很多动作就会变成低效甚至白做。

这次处理过程中，OpenClaw 最有用的一点，是它没有停在"列出问题"，而是一路往前推进到"先止血、再清除、再复查"。

1. 先止血：封禁可疑来源

首先对已识别的可疑来源做封禁，包括：

• 213.136.70.167
• 47.243.13.51

这一步的意义在于：

• 防止对方在你排查时继续连入；
• 减少清理过程中再被重新植入；
• 让后续动作在一个相对静止的环境里完成。

2. 再切断 SSH 信任链

随后直接清空了：

• /root/.ssh/authorized_keys

这一步非常关键。因为不把信任链先切掉，后面删文件、杀进程都有可能只是"暂时清理了表面"。

3. 再清进程和样本

接着是：

• 终止恶意进程；
• 删除恶意目录 /var/tmp/.X7asjj；
• 删除残留 /var/tmp/.kswapd00、/tmp/.kswapd00、/tmp/.X23-unix/dota3.tar.gz；
• 再按 IOC 做复查。

4. 最后回头验证

真正让我觉得 Agent 有用的，不是它会执行命令，而是它不会在"好像差不多了"就停下来。

这次它在清理后又继续核查：

• kthreadadd64
• kthreadadd
• kswapd00

等相关恶意进程是否还存在，以及异常外联是否还在继续。

最终复查结果显示，这一轮已未再看到对应活跃进程和相同模式的异常外联行为。

这个"回头验证"的动作，恰恰是很多人类工程师在疲劳状态下最容易省掉的一步。

---

五、OpenClaw 在这次事件里还有一个被低估的作用：它顺手把后续巡检也补上了

我觉得这次最有意思的地方，不只是它帮我把木马清掉了，而是：

它没有把这件事当成"删完结束"，而是继续往"下次怎么更早发现"推进。

这一步非常重要。

因为单次应急处理如果不沉淀成机制，价值会被打很多折扣。

1. 把健康检查升级成"健康检查 + 入侵巡检"

原本的服务器健康检查更偏传统运维：

• 看服务；
• 看负载；
• 看磁盘；
• 看基础状态。

但这次事件已经证明，这种检查不足以发现真实入侵。

于是后面直接把对应任务升级成更偏安全巡检的版本，新增了：

• IOC 关键字检查；
• 异常 SSH 成功登录检查；
• authorized_keys 异常指纹核查；
• 异常对外 SSH 扫描行为检查；
• 持久化路径与残留文件检查；
• 命中高危特征后的自动止血动作。

这一步其实非常体现 Agent 的价值。

因为它不是只会"执行当前任务"，而是能在处理完当前问题后，顺手把后续防线往前推一格。

2. 它还顺手帮我发现了告警系统本身的问题

这次排查过程中，OpenClaw 还发现了一件很有现实意义的事：

部分 cron 任务采用的是旧设计：

• delivery.mode: none
• 任务内部自己 message(send)

这种设计会带来一个很坑的问题：

• 真实消息已经发了；
• 但框架侧还记成 not-delivered；
• 一旦补跑、恢复、残留 session，就容易再次发同一条消息；
• 最终用户感知就是"怎么老在乱发"。

这类问题后来在 Sub2API 状态推送和 fail2ban 通知里都被实锤了，OpenClaw 又进一步把它们改造成：

• 统一 delivery；
• 脚本只输出正文；
• 增加静默 / 去重逻辑；
• 再恢复原来的定时任务频率。

这一点我特别想强调，因为它说明：

OpenClaw 不只是帮我处理"安全事件本身"，还顺手处理了"处理安全事件时制造噪音的系统问题"。

这就是一个成熟 Agent 跟"脚本执行器"的区别。

---

六、这次我对 OpenClaw 的真实评价：它最适合做什么，不适合做什么

经历完这次事件之后，我对 OpenClaw 在安全与运维场景下的定位更清楚了。

我认为它特别适合做的

1. 长链路排查

它很适合那种不是一步能解决、而是要沿着线索持续推进的问题，比如：

• 登录异常 -> 查信任链 -> 查样本 -> 查进程 -> 查外联 -> 做复查

这类问题特别消耗人的上下文保持能力，而 Agent 在这方面很有优势。

2. 结构化整理结论

排障时人最容易陷入信息碎片。OpenClaw 很擅长把：

• 日志片段
• 文件路径
• 进程证据
• 执行动作
• 当前状态

整理成一条人能读懂的主线。

3. 把一次处理沉淀成后续机制

比如：

• 巡检规则增强
• cron 设计修复
• 去重和静默逻辑补齐
• 技术复盘文档落地

这部分其实非常重要，也很适合 Agent 长时间接力完成。

我认为它不应该单独替代人的

1. 最终风险判断

比如：

• 要不要直接删某个关键文件；
• 要不要立刻重装系统；
• 要不要对外披露某个细节；
• 某条处置是否会影响生产服务。

这些最终决策，我仍然认为应该由人拍板。

2. 高风险外部动作的授权边界

例如：

• 主动对外发送消息；
• 修改关键认证链路；
• 批量封禁或更大规模清理。

Agent 可以执行，但最好还是在边界清晰的前提下做。

所以我的结论不是"AI 以后代替运维工程师"，而是：

在真实应急里，一个好用的 Agent，能把工程师从大量上下文搬运、重复核对和后续收尾中解放出来，让人把精力集中在真正需要判断的地方。

---

七、如果只用一句话总结这次 OpenClaw 的价值

如果让我用一句话总结这次 OpenClaw 的表现，我会写：

它不是帮我"回答了服务器为什么异常"，而是和我一起把一场真实的服务器入侵，从发现、确认、清除、复查，一直打到了巡检和告警治理。

这和传统意义上的 AI 助手，已经不是一个层级的使用方式了。

很多工具只能帮你省一两步；

但在这次事件里，OpenClaw 实际上帮我省掉的是：

• 在杂乱线索之间反复切换的脑力；
• 把半截排查重新接起来的时间；
• 清理后忘了回头验证的风险；
• 以及后续把经验固化成机制的收尾成本。

从这个角度看，它真正带来的不是"会不会一个命令"，而是：

把应急处理从碎片化操作，拉成了一个连续、可追踪、可沉淀的过程。

---

结语

我越来越觉得，AI Agent 真正有价值的地方，不是替你写一段漂亮的介绍文案，也不是给你背几个命令参数，而是当系统开始出问题、上下文开始变乱、线索开始发散时，它还能帮你稳住主线、持续推进、收口结果。

这次服务器入侵事件，最终确实清掉了木马、切断了异常公钥、封禁了来源 IP、补了巡检，也顺手修了一批会制造噪音的定时任务链路。

但对我来说，真正值得记下来的，是另一件事：

OpenClaw 在这次事件里，第一次比较完整地证明了自己不是"会聊天的工具"，而是"能参与真实线上问题处理的 Agent"。

如果以后还有人问我，AI Agent 在运维和安全里到底有没有用，我大概会把这次经历拿出来回答。

不是因为它神奇到能替代人，而是因为它确实让一场本来很容易散掉、漏掉、忘掉的应急处理，变得更连续、更完整，也更像一个真正的作战过程。