这不是『又一个漏洞』，而是一次基础设施级的信号
如果你看到 Telnet（23 端口）在全球范围的可观测流量出现阶跃式下降，它往往意味着：
- 某些网络层策略开始“默认更严格”（运营商/云边界/骨干链路）
- 旧协议的暴露面正在被外部力量强行压缩
- 攻击者会迁移：从“扫 23”转向“扫你没治理干净的其它入口”
这对企业的启示是：
不要把安全寄托在外部封堵。你需要把这次变化当成一次“资产治理演练”。
你应该立即做的 6 件事（最小闭环）
下面这份清单按“从快到慢”排，目标是让你在 30 分钟内拿到暴露面全貌、在 24 小时内完成收口。
1) 资产发现：你到底有没有 Telnet？
先不要猜。用事实回答三件事：
- 是否有
23/tcp对外开放 - 是否有设备在内网使用 Telnet
- 是否有“例外设备”（工业/老旧网络设备）只能 Telnet
输出物（必须落盘）：
inventory/telnet-public.csv：公网暴露清单（IP/域名/所属系统/负责人/最后验证时间）inventory/telnet-internal.csv：内网使用清单（源/目的/频率/用途）
2) 关停优先：先消灭“公网 Telnet”
原则：公网 23 端口优先级最高。
- 能关就关
- 不能关：先在边界做拦截（见下一条）
验收标准：
- 外部扫描无法再连到
23/tcp - 变更有记录（谁批准、何时生效、如何回滚）
3) 边界收敛：ACL / Security Group / 防火墙策略
这是最容易“做了但没用”的地方，建议按顺序：
- 在云安全组/边界防火墙层做 deny（越靠外越好）
- 数据中心/机房出口做 deny
- 主机本地防火墙作为最后一道兜底
如果必须保留（极少数情况）：
- 只允许固定源 IP（堡垒机/跳板）
- 强制经由 VPN
- 明确到期时间（例外不是永久）
4) 替代方案：用 SSH 替换 Telnet
Telnet 的问题不是“老”，而是：
- 明文传输
- 缺少现代认证/审计
- 很难与最小权限、密钥轮换、审计对齐
替代建议：
- 统一 SSH（配合堡垒机/审计）
- 对网络设备：优先启用 SSH 管理通道，关闭 Telnet 管理通道
5) 监控与告警：把『复发』变成可见事件
建议至少做两类告警：
- 被动告警：边界设备/防火墙命中
23/tcp的 deny 事件 - 主动巡检：每天/每周扫描一次是否出现新的
23/tcp暴露
输出物：
runbooks/telnet-alert.md：告警触发后的处置 SOP（联系谁、如何验证、如何收口）
6) 例外管理：把“不得不 Telnet”的场景关进笼子
例外不可避免，但必须“工程化”：
- 例外必须有：业务理由 + 风险评估 + 负责人 + 到期时间
- 例外必须可观测：连接次数、连接源、变更记录
- 例外必须可替代：给出迁移计划（哪天替换、替换成什么）
你真正要防的：攻击者迁移后的『次优入口』
当 Telnet 变难，攻击者会去找：
- 暴露的管理面（各种 Web 管理后台）
- 弱口令 SSH
- 被遗忘的测试环境
- 内网横向移动的薄弱段
所以这篇文章的价值不是让你“关掉 23”，而是把它当作：
一次把资产、边界、监控、例外管理打通的演练。
最小验收清单（你可以直接复制到变更单）
- 公网无
23/tcp暴露（含云/机房/边缘） - 内网 Telnet 使用场景已盘点并有替代计划
- 边界策略已落地（ACL/SG/防火墙）并可回滚
- 告警与巡检已上线（复发可见）
- 例外有到期时间与负责人
参考链接
- GreyNoise Labs：Telnet 流量异常变化（现象观察入口） https://www.labs.greynoise.io/grimoire/2026-02-10-telnet-falls-silent/