节点滥用事件复盘：从完全开放到白名单准入
2026 年 10 月 19 日，Stash Cloud 的 Regtest 测试环境在一天之内出现了两组性质不同的异常流量：一组高频请求测试币 faucet，并以模拟客户端的方式访问节点接口；另一组批量注册账户并批量创建节点。本文记录我们观察到的行为、判断依据、已完成的处置，以及由此对开放平台准入策略做出的调整。
一、事件概述
本次共识别出两个独立的异常来源。二者的行为特征、目标接口与性质判断均不相同：
| 来源 A | 来源 B | |
|---|---|---|
| 来源特征 | 36.148.xx.xx（中国大陆湖南长沙） | 香港 AS38136（Akari Networks）下的三个 VPS 网段 |
| 主要行为 | 高频请求 faucet、模拟钱包客户端访问节点接口 | 批量注册账户、批量创建节点 |
| 目标接口 | /api/v1/faucet/claim、/v3/* | /v3/console/nodes |
| 性质判断 | 倾向于无主观恶意的灰帽测试 | 倾向于有明确目的的黑帽攻击 |
两者虽发生于同一天，但我们未发现共享的客户端指纹、IP、扩展 ID 或账户证据，因此未将二者并案处理。
二、来源 A：faucet 高频请求与客户端模拟
2.1 来源信息
请求来源 IP 前缀为 36.148.xx.xx，归属地为中国大陆湖南长沙。
2.2 请求特征
在 14:29:41–15:53:41（UTC+8） 区间内，该来源向 /api/v1/faucet/claim 发起了 5,265 次请求，且每次请求都使用了一个新的 BTC 收款地址。
该接口用于在 https://stashlabs.io/stash-wallet/ 页面领取 Regtest 测试币。每次更换收款地址的行为表明，这是脚本批量生成地址的结果，而非普通用户的重复操作。
2.3 客户端模拟
14:43:37–15:53:41 期间，该来源使用 python-requests/2.34.2 模拟 Stash Wallet 客户端，操作了四个钱包节点，调用 Stash Cloud 的 v3 接口完成登录、查询、转账等探测，并尝试访问了若干不存在的接口（如 /openapi.json）。
2.4 判断
该客户端是依据 stash-wallet 开源代码模拟实现的，我们倾向于将其理解为一次缺乏主观恶意的灰帽测试，例如用于验证「多钱包自动化操作」能力的实验脚本。
该来源使用了真实的家庭宽带 IP，请求内容模拟真实客户端行为，未对平台造成实质性影响。我们决定暂不进一步追究，仅对该 IP 采取请求限制，并保留后续追究的权利。
三、来源 B：批量注册与批量创建节点
3.1 来源信息
以香港 AS38136（Akari Networks）下的三个 VPS 网段为主，并使用了专业 VPN 工具隐藏真实 IP。
3.2 行为方式
与来源 A 不同，该来源没有模拟 Stash Wallet 客户端，而是直接调用 Stash Cloud 开放平台的 /v3/console/nodes 接口创建节点。
其策略为「单账户单节点 + 无限免费注册」：单个账户的节点数被控制在一个以内，但注册环节没有任何准入门槛，因此自动化脚本可以持续注册新账户、持续创建新节点。
3.3 问题根因
该接口服务于 Stash Cloud 开放平台。在此之前，平台没有任何准入机制：任何用户都可以通过钱包登录注册，并创建和管理节点。这一设计原本面向不希望自行维护节点的中小型开发者，但在缺少准入门槛的情况下，它同样构成了一条零成本的资源获取路径。
3.4 影响与定性
该行为的目的是消耗后端资源、抬高节点运维成本。
我们的服务运行在 Kubernetes 集群上，具备弹性伸缩与临时扩容能力。攻击期间我们持续监测并验证，正常用户的使用未受到影响；仅在打安全补丁升级系统后，用户反馈新的安全管控策略存在误判。
结合攻击路径分析，我们倾向于将其判定为有明确目的的黑帽攻击：Stash Cloud 当时尚未完全开放，该来源仅通过部分已开放的 API 就完成了上述操作，并产生了大量无意义的钱包节点。
四、处置与加固
Stash Labs 安全团队已完成补丁修复，并终止了上述行为。
我们在两个层面收紧了控制：
- 入口层：对异常来源的请求加以限制，避免单一来源持续占用资源。
- 身份层：重新评估开放平台的准入方式，不再默认「注册即可使用」。
五、准入策略调整：从完全开放到白名单
此次事件促使我们重新审视开放的节奏。
我们将暂时中止 Stash Cloud 的完全开放，调整为以合作方式邀请的白名单机制。开发者可通过私信与 Stash Labs 联系，获取开放平台的使用权限。
我们依然认为，RGB 生态需要更低的节点运维门槛——小型团队不应因为无力搭建基础设施而被挡在应用开发之外。但开放的前提是可观测、可约束、可追溯。在白名单机制运行稳定、准入与配额策略经过充分验证之后，我们会重新评估扩大开放范围的时间点。
结语
对任何提供开放 API 的平台而言，被自动化脚本针对只是时间问题。此次事件让我们认识到，安全投入需要与开放程度同步提升。后续我们会持续加强异常检测与准入控制方面的建设，并在策略成熟后逐步恢复开放。