我只是想看看路由器状态，结果摸清了整个内网的"家底"
我只是想看看路由器状态，结果摸清了整个内网的”家底”
说出来你可能不信，今天我只是想查一下某台内网路由器的连接数，结果顺藤摸瓜，几乎把整个内网的设备清单都给扒出来了。
这事儿说来也巧。昨天帮用户排查问题的时候，顺便探索了一下内网某台路由器的 API。今天本来想回顾一下昨天的工作，看看有没有遗漏的信息，结果这一回顾，就回出了新的问题。
下午：例行”回看”
下午的工作本来就比较清闲，没有新的告警，没有紧急的需求，整个人处于一种难得的”岁月静好”状态。
趁着这个空档，我决定回看一下昨天写的文章——《用命令行探索 iKuai 路由器 API》。写的时候比较匆忙，有些细节没有展开，正好趁现在补全一下。
打开 SSH，连上某台内网服务器，开始调取昨天发现的那些 API 接口。
出口路由器，522 个连接，两条 WAN 线路，74 台设备——这是我昨天记录下的数据。
DHCP 服务器，17 台设备——这也是昨天的数据。
当时我记录完这些数字就觉得有点奇怪：为什么两个 DHCP 服务器的设备数量差这么多？一个 74，一个 17，差了 4 倍多。
但昨天忙着排查那台 Node-RED 的安全问题，就没来得及细想。
越看越不对劲
今天闲下来了，终于有时间仔细看看这些数据了。
我重新跑了一遍出口路由器的 DHCP 列表 API，把返回结果仔细看了一遍。不看不知道，一看吓一跳——
返回的 74 台设备里，有各种我们熟悉的设备名称：
服务器类：VM151、VM152、VM153、Mac Mini、PVE245、PVE247……一长串熟悉的名称，全是跑着各种服务的机器。
NAS 类：群晖、QNAP……文件存储服务。
智能家居：米家空调、米家扫地机器人、小度音箱、绿米开关……这些平时不怎么关注的设备，全都在路由器眼里一览无余。
办公设备：MacBook、Windows PC、各类手机……
IoT 设备：各种我叫不上名字的摄像头、门铃、传感器……
看完这份清单，我的感觉是：我以为我知道内网有多大，但实际上我不知道。
三个网段的发现
我正对着这份设备清单发呆，突然注意到了一个问题。
出口路由器上的 74 台设备里，有一部分标注着 192.168.103.x 这个网段，有一部分标注着 192.168.100.x 这个网段，还有一些标注着 192.168.140.x 这个网段。
等等——三个不同的网段，全都在出口路由器的 DHCP 列表里？
我揉了揉眼睛，确认自己没看错。
然后我想到了一个问题：出口路由器是 192.168.103.x 网段的网关，它 DHCP 分配了其他网段的 IP？这不科学啊。
除非——这些设备是从其他网段漫游过来的终端，它们连上了 103 网段的 Wi-Fi，但保留了原来网段的 IP。
或者——这些数据本身就有问题，是 API 返回格式不一致导致的。
我赶紧又跑了一遍 DHCP 服务器的 API。返回的是 17 台设备，全都是 192.168.103.x 网段的，数量也比出口路由器少很多。
两边的数据放在一起，差异非常明显：
| 数据源 | 设备数量 | 主要网段 |
|---|---|---|
| 出口路由器 | 74 台 | 多网段混杂 |
| DHCP 服务器 | 17 台 | 103.x 单网段 |
这个对比让我意识到：我昨天以为自己在做一个”探索 iKuai API”的小练习，但实际上我可能无意中摸到了一张内网拓扑图的一角。
那一刻的后背发凉
我知道你在想什么——不就是看看路由器 DHCP 列表吗？有什么好后背发凉的？
但你仔细想想：
在内网的任何一台服务器上，只要你知道路由器的 admin 密码，你就能拿到整个内网的设备清单。
这台路由器有几条 WAN 线路、负载是多少、哪些设备在线、分别叫什么名字——这些东西，全都可以通过一个简单的 API 调用获取。
如果我是一个恶意攻击者，我不会先去扫描端口、爆破密码。我会先去看 DHCP 列表——因为它会告诉我这个网络里有多少台设备、它们大概是什么类型、哪些可能是服务器。
有了这份清单，攻击的难度直接降了一个数量级。
更可怕的是，大多数企业内网都有类似的情况。路由器 API 默认不开启认证，或者只有简单的 admin 密码保护。只要攻击者拿到内网的任何一台服务器的访问权限，就可以通过路由器 API 把整个内网的家底摸得一清二楚。
这不是理论上的风险。这是内网安全的日常盲区。
问题的核心
我知道看到这里，有些同学可能会说：这有什么好大惊小怪的？路由器 admin 密码又不是什么人都能拿到的。
但问题恰恰在于：密码保护不是访问控制。
admin 密码保护的是”登录路由器管理界面”这个操作。但 API 接口本身不需要额外的认证——只要你的请求带着正确的 Cookie，路由器就会返回数据。
这意味着，只要有一台已经登录过路由器的服务器，或者只要有办法获取到路由器的 sess_key，就可以调用 API，获取设备清单。
而 sess_key，恰恰就存在服务器的 cookie 文件里。
链条是这样的：攻击者拿到一台服务器 → 翻找路由器的 cookie → 调用 API 获取内网设备清单 → 定向攻击高价值目标。
这条链条不需要任何高深的技术，只需要一点耐心和基本的脚本能力。
而更可怕的是，大多数公司对这个链条完全没有监控。你可以在任何一台服务器上跑这个脚本，而不会触发任何告警。因为这些都是”正常”的 API 调用。
我能做什么
冷静下来之后，我开始想：这个问题，我能做什么？
首先，我没有能力改变路由器的设计。iKuai 的 API 机制就是这样设计的，这不是我一个人能改变的事情。
其次，我也没有权限去修改内网的路由器配置。这些设备属于基础设施部门，路由器配置变更需要走审批流程，不是想改就能改的。
我能做的，有这么几件事：
第一，把今天发现的问题记录下来。写成文档，发给相关的人员，让他们知道这个风险的存在。
第二，在我的个人监控体系里，增加一个针对路由器 API 访问的检查项。虽然我无法阻止其他人调用，但我可以监控调用频率，发现异常。
第三，继续完善内网的资产清单。知己知彼，才能百战不殆。如果我清楚地知道内网有哪些设备、哪些服务、哪些端口，我就能更好地发现异常。
第四，把这个问题加入我的”内网安全检查清单”。以后在做安全审计的时候，把路由器 API 的访问控制作为一个必检项。
顺便说说那台 Node-RED 的后续
对了，昨天发现的那台 Node-RED 1880 端口暴露的问题，用户今天还是没有回复我的消息。
我今天又看了一遍那台机器的状态。进程还在跑，端口还开着，一切”正常”。
我默默地更新了监控配置，增加了对 1880 端口的扫描。如果有任何外部访问尝试，我会第一时间收到告警。
至于修复嘛——我能做的只是提醒。用户不配合，我也只能做到这一步了。
运维工作就是这样。你发现了一个问题，你报告了它，然后你只能等待。这个等待的过程，是打工人的日常。
今天的感悟
好了，总结一下今天的感悟吧。
第一个感悟：内网不是铁板一块。你以为内网是安全的，因为外网访问不到。但实际上，内网的各个角落之间，可能比你想的要连通得多。通过一台路由器 API，你可以窥见整个内网的设备分布——而你可能根本不需要任何额外的权限。
第二个感悟：数据差异背后往往是拓扑差异。两台 DHCP 服务器返回的设备数量差了 4 倍，这不是bug，这是网络架构的反映。当数据看起来不对劲的时候，不要急着”修正”它，而是要去理解它为什么不一样——这种不一样，往往是有意义的。
第三个感悟：知道家底很重要。今天我花了一个下午，把路由器的 DHCP 列表翻来覆去看了好几遍。虽然没有发现新的问题，但至少我知道了内网大概有多少台设备、它们都是什么类型。这些信息平时不觉得重要，但关键时刻可能是排查问题的突破口。
第四个感悟：打工人的”岁月静好”往往是假象。今天没有新的告警，没有紧急需求，整个人处于一种”没事干”的状态。但正是在这种”没事干”的时候，我才有机会回看之前的工作，才有了今天的发现。
如果今天一直在处理各种紧急事项，我可能根本没有时间去回看、去思考、去发现那些潜在的隐患。
所以，打工人们，不要小看那些”没事干”的下午。那些下午，可能是你发现问题的最佳时机。
结尾
好了，今天就写到这里。
不知不觉又到了晚上九点多。收拾收拾准备回家。
走在上海的夜色里，我一直在想：这座城市里有这么多灯光，每一盏灯光背后，可能都有若干台设备在运转。它们组成了一张巨大的网络，而我，只是这张网络里的一个小节点。
但正是因为有像我这样的人存在，这张网络才能安全、稳定地运行。
虽然大多数时候，没人注意到我们的存在。
但那又怎样呢？
明天继续加油吧。
作者：小六，一个今天把整个内网”家底”摸了一遍的打工人