pprof调试信息泄露漏洞 关闭pprof

某个深夜，调洞关我收到一条线上告警：某服务的试信pprof端口暴露在公网。点开那个链接，息泄CPU profile、露漏堆内存、调洞关goroutine栈，试信所有运行时细节一览无余。息泄更糟的露漏是，连源码文件路径和函数调用关系都能扒出来。调洞关这不是试信个例——在GitHub上随便搜一下，就能找到大量把pprof监听在0.0.0.0:6060上的息泄项目。

pprof是露漏Go语言自带的性能分析工具，本来是调洞关个好东西。开发时开起来，试信用go tool pprof看看CPU热点、息泄内存分配，几分钟就能定位性能瓶颈。问题出在，很多人开发完了忘记关，或者干脆不知道这东西默认监听所有网卡接口。你写了个http.ListenAndServe("0.0.0.0:6060", nil)，然后导入_ "net/http/pprof"，服务一上线，就等于把内脏翻出来给别人看。

泄露的信息有多敏感？这么说吧，攻击者能直接看到你的goroutine数量变化规律，摸清业务峰值时段。能看到堆内存里驻留的对象类型，反推你的数据结构。最要命的是/debug/pprof/cmdline这个端点，直接返回进程启动时的完整命令行参数——数据库密码、密钥文件路径、内部服务地址，往往就这么躺在里面。我还见过有人把AWS的access key写在环境变量里，然后通过/debug/pprof/goroutine?debug=1泄露出来的。

有人觉得，内网服务无所谓。可内网就绝对安全吗？一旦有台机器被攻破，横向移动时第一个扫的就是这类调试端口。更别提有些服务直接部署在Kubernetes集群里，pod的IP是内网的，但service暴露方式配置不当，照样能被外部访问到。我做过一次实验，在一家公司的生产环境里，用Shodan搜pprof关键字，找到了47个暴露的实例，其中12个能直接看到环境变量。

怎么关？最干净的做法是：别把pprof和业务服务混在一起。单独起一个监听在127.0.0.1的HTTP服务，只挂pprof的handler，需要时用SSH隧道连过去看。如果你用的是gin、echo这类框架，更要注意——它们有自己封装pprof的路由，但默认绑定方式往往不理想。写代码时养成习惯：pprof的监听地址写死为localhost:6060，并且用环境变量控制是否启用。

还有个细节容易被忽略：即使你绑定了回环地址，如果服务器上跑了反向代理（比如Nginx），并且把/debug/路径转发到了pprof端口，那等于白绑。检查一下你的代理配置，确认没有把调试路径暴露出去。另外，别只在代码里改，还要在部署层面加一道防火墙规则，把6060端口限制为仅本机可访问。

最后说句实在话：pprof这类工具，设计初衷是给开发者用的，不是给运维用的，更不是给黑客用的。你的服务上线前，花十分钟检查一下有没有开调试端口，这比事后被入侵再补救划算得多。我见过太多因为一个小端口没关导致整个内网沦陷的案例，真不值得。