进程内存窃取风险，公网推理服务禁止debug接口对外开放

不少团队把大模型推理服务部署到公网后，只关注了显存和并发，却忽略了 debug 接口带来的进程内存窃取风险。
这类接口一旦对外开放，攻击者可以直接读取进程内存中的模型权重、API Key、用户输入等敏感数据。
本文从原理、排查到封禁给出完整操作，跟着做就能把这个隐患处理掉。

为什么 debug 接口会泄露进程内存

debug 接口一般是开发阶段用来查看服务内部状态的后门。
它通常包含动态调试、堆栈查看、内存转储等能力。
以常见的 Python FastAPI 为例，开启 debug=True 后，/docs 和 /redoc 会暴露全部接口定义，而一些框架甚至提供 /debug/vars、/heap、/memory 这类路径。

如果推理服务直接把这类端口映射到公网，攻击者只需向 /heap 或 /memory 发起请求，就能拿到运行进程的内存快照。
这属于进程内存窃取，比读文件更隐蔽，因为内存里可能有临时解密后的密钥、会话 token 或第三方服务凭证。

先检查你的服务是否已经暴露

登录服务器，先确认当前监听端口和对外访问情况。

ss -tlnp | grep -E '(:8000|:8080|:5000)'

然后在本机测试常见 debug 路径：

curl -I http://127.0.0.1:8000/debug
curl -I http://127.0.0.1:8000/debug/vars
curl -I http://127.0.0.1:8000/memory

如果返回 200 或 302，说明接口存在。
再用另一台不在内网的机器访问服务公网 IP 的相同路径，比如 http://你的公网IP:8000/debug。
如果公网也能访问，说明已经暴露，必须立即处理。

也可以在本地用 Nmap 做一次端口扫描，确认哪些端口映射到了公网：

nmap -sT -p 8000,8080,5000 你的服务器公网IP

关闭 debug 并限制访问来源

第一步：关闭框架的 debug 开关

以 FastAPI 启动命令为例，检查是否有 --reload 或 debug=True：

# 错误示例
uvicorn.run(app, host="0.0.0.0", port=8000, debug=True)

# 正确写法
uvicorn.run(app, host="0.0.0.0", port=8000, debug=False)

如果使用 Flask，确保：

app.run(host="0.0.0.0", port=5000, debug=False)
app.debug = False

修改后重启服务。

第二步：在防火墙层直接封禁 debug 路径或端口

即使框架 debug 关闭，也建议在网关层再防一道。
以宝塔面板为例，进入 安全 > 防火墙，删除对外开放的 8000、8080 等端口的放行规则，仅保留 Nginx 转发端口 80/443。

使用命令方式则执行：

firewall-cmd --permanent --remove-port=8000/tcp
firewall-cmd --reload

如果必须保留端口给内网调试，可以用 IP 白名单限制来源：

firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="你的内网IP" port protocol="tcp" port=8000 accept'
firewall-cmd --reload

第三步：用 Nginx 拦截常见 debug 路径

在对外配置的 server 块中增加返回 403 的规则：

location ~ ^/(debug|memory|heap|metrics/process) {
    deny all;
    return 403;
}

重载 Nginx：

nginx -s reload

验证和常见疑问

完成上述操作后，再次公网访问之前的 debug 地址，应返回 403、404 或连接超时。
同时确认服务主流程 POST /predict 等接口仍能正常推理。

如果远程访问已经超时，是不是意味着安全了？ 不一定，需要确认公网端口是否真的没有映射到内部服务。
可以在云控制台的安全组里再检查一遍入方向规则，只保留 80/443 和必要的 SSH 端口。

debug 关闭会影响模型性能吗？ 不会。debug=False 只是关闭调试功能，读取模型权重和推理速度不受影响。

内部想保留调试能力怎么办？ 建议用 SSH 隧道访问内网调试端口，而不是直接暴露到公网。

避坑记录

第一个坑是只改框架配置不重启服务，导致 debug=True 依然生效。
修改后必须重启进程，并确认监听端口的变化。

第二个坑是使用 Docker 部署时，容器内端口映射到 0.0.0.0，外部防火墙规则没覆盖 Docker 的 iptables 链，导致规则失效。
检查 Docker 映射：

docker ps --format '{{.Names}} {{.Ports}}'

如果发现映射成 0.0.0.0:8000->8000/tcp，建议在 docker run 中改成只绑定内网 IP：

docker run -p 127.0.0.1:8000:8000 your_model_image

最终确认清单

按顺序自查一次：

• 框架日志中能看到 Debug mode: off 或 debug=False。
• 公网访问 /debug/vars、/memory 返回非 200。
• 安全组和系统防火墙只放行必要端口。
• Docker 容器端口未直接绑定 0.0.0.0。

确认全部通过后，进程内存窃取风险基本解除。
如果项目里还用到 gunicorn、Ray Serve 或 Triton 等服务，同样要去查看它们的调试接口配置，比如 Triton 的 --allow-metrics、--allow-http 参数，避免换个框架又出现同类问题。

如果你正在处理公网推理服务的 debug 接口风险，建议按上面的步骤先做一遍自查，再根据实际框架调整配置。
遇到不确定的调试路径时，使用 curl 逐个路径探测能在几分钟内得到结论。