代码审计里的内网隧道：六个检查点

多级跳会让溯源变难，测试记录里必须写清每一跳落在哪台机器上

正着读代码容易漏，因为入口太多；反着找危险点，数据流只有那么几条。

先说结论

先列危险点，再回溯入口，最后确认校验与权限。

• 检查点一：所有外部入口是否都过统一校验
• 检查点二：危险函数是否集中封装
• 检查点三：校验是否只做一次、是否白名单
• 检查点四：权限判断是否在服务端
• 检查点五：错误信息是否泄露内部细节
• 检查点六：是否有兜底日志

检查点一：入口

SOCKS5 代理本身不做身份鉴别，任何能连上这个端口的人都可以借道，来源与口令都不校验。

把入口列全：HTTP 参数、请求头、上传、消息队列、定时任务的外部输入。漏一个就白审。

检查点二：危险点

隧道流量在网关看来只是一条长连接，可用的特征只有字节数与持续时长，包内容看不到。

检查点三：校验逻辑

跳板机的转发规则要按源、目标、端口三元组登记，出现越权组合就告警，这是最有效的一层。

看到「先替换再校验」「只在一个接口校验」这两种写法，基本可以直接标红。

这个问题的几个审计细节

实际代码里最容易漏的几处：

• 多级跳会让溯源变难，测试记录里必须写清每一跳落在哪台机器上

检查点四到六

多级跳会让溯源变难，测试记录里必须写清每一跳落在哪台机器上。

越权是审计里性价比最高的方向：少一行判断，就是一个中高危。错误信息要统一，日志要记入口摘要。

再补充几点

这几条不改变结论，但会改变你评估风险时的顺序。

• SSH 的 -L 与 -R 方向相反，参数配反会变成把内网端口主动暴露到公网
• 收工后要回收隧道与临时账号，遗留的转发规则是最常见的一种后门
• 把 -R 绑到 0.0.0.0，内网端口直接对公网开放
• 隧道建完不做记录，事后自己也说不清走过哪条路
• 用生产跳板机做测试中转，把业务日志污染了

审计的产出不是「找到几个洞」，是「知道这类洞在哪个模式里反复出现」。