端口关闭即安全：分布式追踪视角下的服务器防护实战

　　去年春天那会儿，运维突然在群里喊：“服务被扫出漏洞了，说是有个测试端口没关，被外部IP连了三百多次。” 我原以为又是哪个新同学手滑开了端口，结果一查分布式追踪的链路——好家伙，这端口是半年前某个灰度环境用的，灰度结束后居然没人记得关，活生生在生产环境挂了半年。

　　那天我正对着工单系统里二十条未处理的报警发呆，咖啡凉了都没顾上喝。运维在群里甩了个端口扫描工具的截图，说“这端口连的是你们的XX服务，赶紧查”。我打开追踪系统，输入端口号，瞬间拉出三百多条调用链——全是外部IP的请求，每条链都卡在“端口未授权”的错误日志上。最离谱的是，这些请求的频率从每小时几次慢慢涨到每分钟十几次，明显是扫描工具在试探。

　　我盯着链路里的服务名看了半天，突然想起这端口是去年做灰度时开的。当时为了测新功能，特意在Nginx里加了个临时端口，配了独立的upstream。灰度结束后，前端说“功能没问题”，产品说“可以全量”，运维说“配置我备份了”——结果谁都没提关端口的事。现在倒好，这端口成了生产环境的“后门”，被扫描工具当漏洞报了上去。

　　其实这事儿最气的不是漏洞本身，是分布式追踪里暴露的“管理漏洞”。我原以为端口关闭是运维的基本操作，结果追踪数据告诉我：这端口在灰度结束后还活跃了两天——有内部IP在连它，可能是测试同学没改配置，也可能是某个脚本还在用旧地址。直到两天后，所有内部调用都断了，这端口才彻底“闲置”，但依然开着，像块无人认领的废铁，挂在生产环境的墙上。

　　我跟运维吐槽：“你们扫端口的时候，能不能顺便查查这端口有没有实际流量？” 运维说：“我们只扫开放端口，流量是你们业务的事。” 我又去找测试：“灰度结束后你们不验证端口吗？” 测试说：“我们只测功能，端口是运维配的。” 这时候手机亮了一下，是产品发来的消息：“用户说新功能偶尔卡顿，你们查下？” 我盯着屏幕上的“优胜劣汰”四个字——这词儿是上周开安全会时，领导说的“要淘汰不安全的旧服务”，现在倒成了我吐槽的由头。

　　说白了，端口关闭这事儿，分布式追踪给了个“优胜劣汰”的视角：哪个端口有流量，哪个端口是“活口”；哪个端口没调用，哪个端口是“死口”。我拉了半年的追踪数据，发现生产环境里至少有五个“死端口”——有的是测试用的，有的是旧版本遗留的，还有的是某个同学临时调试开的，用完没关。这些端口平时没流量，一旦被扫描到，就成了安全漏洞的“突破口”。

文章配图，仅供参考

　　其实分布式追踪最狠的地方，是它能把“端口是否该关”这种模糊的问题，变成“有没有实际流量”这种明确的数据。我原以为“关端口”是运维的活，结果追踪数据告诉我：业务方也得参与——因为只有业务方知道哪个端口是临时用的，哪个是长期用的。运维可以扫开放端口，但扫不出“该关的端口”；测试可以验证功能，但验证不了“端口是否冗余”；只有分布式追踪，能通过调用链的流量，给每个端口打上“存活”或“死亡”的标签。

　　现在回头看，那三百多次外部请求，其实是分布式追踪给我们敲的警钟——它用最直接的方式告诉我们：生产环境里有多少“僵尸端口”，在默默消耗着安全资源。我关了那个测试端口后，又查了其他服务的端口，发现有两个服务的旧版本端口还在开，虽然流量极少，但依然是个隐患。我跟运维说：“以后灰度结束后，能不能用追踪数据扫一遍端口？没流量的直接关。” 运维说：“行，但你得把扫的脚本写好。” 我骂了句：“这活儿本来该你们干！” 结果他回：“我们只管扫开放端口，流量是你们业务的事。”

　　咖啡彻底凉了，我起身去倒掉，路过产品工位时，听见他在打电话：“用户说卡顿可能是网络问题...” 我心想：网络问题？说不定是某个“僵尸端口”在偷偷占用带宽呢。不过这话我没说出口——毕竟分布式追踪只能告诉我端口有没有流量，至于流量为什么卡，那得查别的链路了。下一步我打算把所有服务的端口调用情况导出来，做个“端口存活率”的报表，看看到底有多少端口是“该关没关”的。至于结果如何，我也不确定——可能运维会骂我事儿多，可能测试会说我多管闲事，但至少，分布式追踪的数据不会说谎。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!