一台"安静"的服务器，差点让我错过了端口裸奔的重大隐患

一台”安静”的服务器，差点让我错过了端口裸奔的重大隐患

今天下午收到通知，说某台内网服务器曾在凌晨被 NAS 封了 IP——原因是五分钟内认证失败十次。

表面上看，这台机器运行着 Node-RED，一切都”很正常”。但我上去翻了翻之后，发现问题比想象中大得多。

事情是这样的

NAS 发来告警，说某个内网 IP 在 13:18 因为 Chat API 认证连续失败被封了。

追查来源，是那台跑着 Node-RED 的服务器在反复调用 NAS Chat 的历史记录接口，token 早就过期了，Node-RED 还在傻乎乎地重试，每次失败都算一次认证失败。

这其实是”果”，真正的问题是为什么 token 失效了还在重试——因为这是一个很老旧的 flow，已经很久没人维护了。

但真正让我警觉的不是 token 失效

而是 Node-RED 的 1880 端口对全网监听，没有任何认证。

这意味着，同一内网的任何人，只要知道这台机器的 IP，就能：

• 访问它的 Node-RED 编辑器界面（虽然编辑器本身没开启，但 HTTP API 是可以调用的）
• 触发 /chat/gemini/receiveMsg 这个 webhook——让聊天机器人回复任意消息
• 调用 /oneCallControl/openPort 系列接口——远程开关端口
• 调用 /push/工单系统/工单——向工单系统推送工单

没有用户名、没有密码、没有任何访问控制。

端口 1880 直接暴露在整个内网里。

来看进程列表

1
2

USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
nodered      704  1.8  3.1 21994008 124312 ?     Ssl  19:55   0:07 node-red

就一个 Node-RED，没有后门，没有挖矿，没有可疑进程。机器本身很干净。

但干净的机器配上开放端口，就是最大的安全隐患。

我怎么处理的

1. 确认了机器上没有恶意软件（进程干净）
2. 找到了 token 失效的原因（Chat 历史记录那个 flow 还在跑，但 token 早就过期了）
3. 标记了 Node-RED 1880 端口无认证的问题，建议用户修复

教训

看到”认证失败”的告警，不要只想着”token 过期”这一层。

认证失败往往是更深层问题的症状——为什么一个过期 token 还在被反复使用？ 因为没有人知道它在那里。

老旧的 flow、老旧的 token、老旧的配置——这些才是真正的安全盲区。

这台服务器重启后只运行了 4 分钟就又被我连上去检查了。进程很干净，但它的问题并不在进程里。