VPS 安全加固:从 0 到三层防御实战记录
一台裸奔的海外 VPS,跑着 new-api、x-ui、Hermes Agent 三个服务,端口审计发现 3000 + 50404 公网监听——我是怎么一步步把它变成铁桶的。
背景:一台裸奔的 VPS
上个月整理 GCP 免费赠金 VPS,发现上面跑着:
- new-api(端口 3000)— AI API 代理网关
- x-ui(端口 50404)— 代理面板
- Hermes Agent(内部端口)— 个人 AI 助理
三个服务全部 0.0.0.0 绑定,直接暴露在公网。用 nmap 扫了一下自己的 IP:
$ nmap -Pn <my-ip>
PORT STATE SERVICE
3000/tcp open ppp
50404/tcp open unknown
更要命的是,new-api 后台后来审计发现了 7 个陌生 bot 账号,说明已经被扫到了。ROOT_PASSWORD 还是默认的弱密码。
这篇文章记录我从"裸奔"到"三层防御"的完整过程,每一步都是真实踩坑后的总结。
第一层:GCP Firewall — 在流量进主机前挡住
核心思路:在 GCP 层面直接拒绝,流量根本不到你的主机。
GCP Firewall 支持按 instance tag 匹配规则。我先创建了一个 tag secure-server,然后写规则:
# 拒绝所有入站,只允许特定端口
gcloud compute firewall-rules create deny-all-ingress \
--direction=INGRESS \
--priority=65534 \
--network=default \
--action=DENY \
--rules=all \
--target-tags=secure-server \
--source-ranges=0.0.0.0/0
踩坑:规则创建后测试 nc -zv <ip> 3000,发现还是通的。排查半小时发现——instance 没打 tag。规则存在但没 target,等于没配。
Hermes-lite 裁剪指南:在 1GB VPS 上跑轻量 AI Agent
为什么要裁剪
完整版 Hermes Agent(Nous Research)功能丰富:多平台网关、浏览器自动化、语音 TTS/STT、多 Agent 协作、Kanban 看板等。但这些功能对资源要求不低——在我的测试里,完整配置更适合至少 2GB 内存的机器。
我有一台 GCP e2-micro(2 vCPU / 954MB RAM),想用它跑一个 24/7 在线的 AI Agent 接入飞书。完整版装不下,于是有了这个裁剪实践。
三阶段渐进式裁剪
裁剪不是一步完成的,而是三阶段递进:
第一阶段:本地 Codex 完成初期核心裁剪
在本地电脑上,利用 Codex(OpenAI) 作为辅助分析工具,对完整版 Hermes 进行全面"解剖":
- 逐一扫描
~/.hermes/目录结构,识别每个模块的职责 - 分析 67 个技能的依赖关系,标记哪些是核心链路的、哪些是边缘功能
- 梳理 config.yaml 中每个配置项的实际作用,搞清楚"关掉会怎样"
- 输出一份裁剪清单:哪些 toolset 可以禁、哪些 skill 可以删、哪些配置可以收紧
这一阶段的核心价值:把"能不能关"这个判断做对。Codex 帮助理解了代码间的依赖关系,避免直接关某个功能导致连锁崩溃。
第二阶段:大 VPS 上跑完整版 + 压测验证
在一台大内存 VPS 上安装完整版 Hermes,作为"对照基准":
- 记录完整版的实际内存占用(idle / 高负载两种状态)
- 逐个关闭非核心功能,观察内存变化和稳定性
- 跑压测:模拟长时间运行、多轮对话、工具调用密集场景
- 确认裁剪后系统在资源充足环境下依然稳定
这一阶段的目的:建立性能基线 + 验证裁剪组合的安全性。在大 VPS 上翻车无所谓,在小 VPS 上翻车就是服务宕机。