1. 内网隧道蓝队视角下的“隐形通道”与检测挑战大家好我是老张在安全圈摸爬滚打了十几年见过太多因为内网失守而引发的“大事件”。很多时候攻击者拿到边界服务器权限只是第一步真正的“宝藏”往往藏在深不见底的内网里。这时候攻击者就需要一条稳定、隐蔽的通道把内网的数据“运”出来或者把攻击指令“送”进去。这条通道就是我们今天要重点聊的内网隧道。你可以把它想象成一条修建在你家后院内网和外界之间的秘密地铁。攻击者是地铁的建造者和使用者而我们的目标就是成为那个敏锐的安检员能识别出哪些看似正常的“乘客”网络流量其实正在偷偷挖地道、运物资。FRP、NPS、reGeorg、Venom 就是目前市面上最常见的几款“地铁施工队”。它们各有各的施工图纸协议和运输方式加密但只要我们摸清了它们的套路就能在关键路口设卡检查。对于蓝队兄弟来说防守的难点在于这些隧道工具的流量往往会伪装成正常的 Web 访问HTTP/HTTPS或者其他常见协议混杂在海量的业务流量里就像一滴水藏进了大海。传统的基于 IP 和端口的防火墙策略很容易失效。所以我们的防守思路必须升级从“看谁在敲门”变成“听敲门声有什么特别之处”。这篇文章我就结合自己多年的实战踩坑经验带大家深入这些工具的“施工现场”剖析它们的流量特征并给出能直接落地到安全设备如 WAF、IDS、态势感知上的检测规则思路和防御加固建议。咱们不搞纯理论直接上干货让你看完就能用。2. FRP高性能反向代理的流量指纹与识别FRP 是我在应急响应中遇到频率最高的内网穿透工具之一因为它配置简单、性能稳定而且社区活跃。它的工作模式很典型一个部署在公网的frps服务端一个部署在内网的frpc客户端两者之间建立控制通道然后再为具体的服务如 RDP、SSH建立数据隧道。2.1 明文通信下的“身份证”泄露早期版本或未启用加密的 FRP在握手阶段的流量几乎是“明牌”。抓个包你很容易在 TCP 载荷里看到类似下面的 JSON 数据{version:0.44.0,hostname:WIN-7J2A,os:windows,arch:amd64,user:,privilege_key:,timestamp:1646123456,run_id:,metas:{},pool_count:1}这就是 FRP 客户端的“自我介绍”包。几个关键特征像指纹一样明显固定的 JSON 结构包含versionhostnameosarchtimestamp等字段。版本信息version:0.xx.0这个格式非常固定。特定字段run_id:初始为空pool_count:1等。紧接着服务端会回复一个包含run_id的响应。整个握手过程清晰可辨。检测思路可以非常直接在流量中深度检测DPI是否存在这种特定结构的 JSON 字符串特别是匹配version:0\\.\\d\\.0这样的正则表达式。我在实际部署的 WAF 上就加过这样一条规则成功拦截过不少“懒人版”的 FRP 连接。2.2 启用 TLS 加密后的“蛛丝马迹”攻击者当然不傻知道明文传输有风险。所以 FRP 支持启用 TLS 加密在配置文件中设置tls_enable true。一旦启用通信内容被加密上面那些 JSON 明文就看不见了。但这并不意味着无迹可寻。这里有个非常关键且容易被忽略的细节在 TLS 握手之前TCP 连接建立的初期FRP 客户端会先发送一个字节0x17十进制23到服务端。这个0x17其实是 FRP 自定义的一个协议标识用于协商后续是否使用 TLS。你可以把它理解为一个暗号“我要开始说加密的话了你准备好没”检测思路就可以从这里切入检测 TCP 载荷首字节为 0x17 的流量尤其是目标端口为 FRP 常见服务端端口如 7000 7001 7500时。进一步观察在 TLS 握手包Client Hello的Server Name Indication (SNI) 扩展或证书信息中攻击者如果使用自签名证书证书的颁发者或主题可能会包含一些随意或可疑的字符串这可以作为辅助判断点。此外有资料提到 FRP 的 TLS 实现中可能引用了“Gryphon”协议相关的字符串。虽然在实际抓包中不常见但将其作为一个可疑特征纳入威胁情报库进行关联分析也不失为一种深度防御的手段。实战建议在内网边界出口、核心交换机上部署流量审计设备编写检测规则对发送0x17标志且非前往已知合法 TLS 服务的连接进行告警。同时严格限制内网服务器主动向外发起 TLS 连接的目的地和端口实施白名单策略。3. NPS带Web管理的穿透代理特征有何不同NPS 可以看作是 FRP 的一个“增强管理版”它自带一个功能完善的 Web 管理界面对于攻击者来说管理多个隧道更加方便。它的流量特征和 FRP 有相似之处但也有自己鲜明的“个性”。3.1 连接认证阶段的“签名”NPS 的客户端与服务端建立连接时也有一个认证握手过程。在明文传输下这个过程的特征非常固定客户端首先会发送一个包含明文版本号和其MD5 哈希值的数据包。例如你可能会看到version:0.26.10和对应的 MD5 值同时出现。认证成功时服务端会回复字符串sucs而客户端则会回复main。这两个短字符串在正常的应用协议中极少出现因此可以作为高置信度的检测特征。检测规则可以这样设计在 TCP 流中检测是否存在连续的、符合version:x.x.x格式的字符串并伴随一个 32 位的 MD5 字符串。紧接着在后续的几个包内搜索sucs和main这两个关键词。一旦匹配几乎可以断定是 NPS 流量。3.2 隧道建立后的数据格式认证通过后NPS 会为每一个具体的代理服务如转发一个内网网站的 HTTP 流量建立子隧道。在这个阶段传输的控制指令具有固定的 JSON 格式这又是一个强特征{ConnType:tcp,Host:192.168.1.100:8080,Crypt:false,Compress:false,LocalProxy:false,RemoteAddr:,Option:{Timeout:5000000000}}这个 JSON 结构里ConnType连接类型、Host目标地址、Crypt是否加密、Compress是否压缩等字段是固定的。特别是Timeout:5000000000即5秒的超时以纳秒表示这个值在 NPS 的源码中是硬编码的默认值出现在流量中极具标识性。防御策略对于蓝队来说可以在网络层部署下一代防火墙或入侵检测系统编写自定义的入侵检测规则如 Suricata/Snort 规则来匹配上述 JSON 字符串模式。例如可以检测ConnType:后面接tcp、udp、http等值的模式。同时由于 NPS 的管理端默认使用 8080、8024 等端口应定期扫描内网是否有未经授权开放这些端口的服务。4. reGeorgHTTP隧道下的“隐身大师”如果说 FRP/NPS 是修建标准地铁那 reGeorg及其后继者 Neo-reGeorg就是在利用现有的“城市供水系统”HTTP/HTTPS 流量偷偷运货。它特别适用于那些只允许80/443端口出站的环境。它的原理是在内网 Web 服务器上上传一个特殊的脚本jsp php aspx 等所有隧道数据都封装在 HTTP 请求/响应的 Body 里伪装成普通的网页访问。4.1 静态文件特征藏在HTML里的“接头暗号”reGeorg 的隧道脚本本身就是一个特征库。以最常见的tunnel.jsp为例用文本编辑器打开你往往会在文件开头或结尾看到一大段被 HTML 注释包裹的、看似乱码的字符串。例如!-- XXXXXX... --这段注释里的内容实际上是经过编码的密钥或配置信息。因此在 webshell 检测或静态文件扫描时查找包含大量异常、无意义字符的 HTML 注释是一个有效的筛查手段。4.2 动态流量特征Cookie、编码与固定格式在流量层面reGeorg 的通信模式很有规律首次访问无Cookie后续访问带固定Cookie客户端第一次请求隧道脚本时是一个普通的 GET 请求不带 Cookie。脚本执行后会返回一个 Set-Cookie 头通常包含一个固定的键如SESSIONID。此后所有的隧道通信请求都会携带这个 Cookie。这种“首次无后续有”的模式在正常网页浏览中不常见可以作为行为异常点。POST 数据与返回内容均经过编码无论是客户端上传的指令还是服务器返回的内网数据都会经过 Base64、Hex 等编码填充在 HTTP Body 中。因此你会看到大量的 POST 请求其 Body 是长度固定或规律变化的一串编码字符串而服务器的响应也是同样格式的编码字符串。这明显区别于正常的表单提交或 API 调用。固定的 User-Agent某些版本的 reGeorg 客户端会使用一个默认的、不太常见的 User-Agent 字符串这也可以作为辅助检测特征。检测与防御实战WAF/IDS 规则编写规则检测对特定路径如/georg/tunnel的频繁 POST 请求且请求体为 Base64/Hex 编码格式。同时可以检测“请求是否携带一个之前由服务器在相同会话中下发的特定 Cookie”这种上下文关联行为。服务器端加固严格限制 Web 目录的上传和执行权限对可执行脚本目录进行重点监控。部署 RASP运行时应用自我保护产品监测 Web 应用对java.net.Socket或类似网络连接类的异常调用因为 reGeorg 脚本本质上要在 Web 容器内发起对内网其他机器的 Socket 连接。网络层分析虽然流量被封装在 HTTP 里但隧道建立后其心跳包和数据包的交互频率、数据包大小分布可能与正常的 Web 访问有统计学差异。可以通过流量分析平台建立基线对异常会话进行告警。5. Venom多级代理的“俄罗斯套娃”与特征分析Venom 的思路更“高级”一些它追求的是多层跳板多级代理让追踪溯源变得极其困难。它的节点分为 Admin、Agent、Node 等多种角色可以层层嵌套。其流量特征主要体现在其自定义的协议格式上。5.1 协议魔数与指令标识阅读 Venom 的源码如Venom/global/global.go我们可以找到其协议设计的“胎记”协议魔数数据包的开头可能会包含固定的标识字节比如字符串ABCDEFGH。这类似于很多文件格式的“文件头”如PNG图片的\x89PNG用于在字节流中标识一个 Venom 数据包的开始。指令标识在控制指令中会包含特定的命令字符串如VCMD。这用于区分不同类型的控制消息如连接、传输、心跳等。检测思路在原始网络流量中特别是非标准端口的 TCP/UDP 流量进行深度包检测寻找以固定字符串ABCDEFGH开头的载荷。这几乎是一个确凿的证据。同时可以检测载荷中是否包含VCMD等关键字。由于 Venom 支持加密这些特征在加密后可能会被掩盖但在其默认配置或攻击者配置不当的情况下仍有很大概率被捕获。5.2 多级架构带来的行为特征Venom 的多级代理架构从行为上看会形成一条“链式”的出站连接。例如内网机器A连接公网机器B第一级B再连接另一个国家的机器C第二级。从防守方网络边界看会发现内网主机A向一个非常用端口发起了持续的、加密的 TCP 连接而这个连接的对端IPB可能又是一个跳板。这种“内网主机主动、持续连接外部未知IP的非服务端口”的行为本身就是一种高威胁告警。防御策略建议严格的外联控制实施严格的网络出口策略遵循最小权限原则。除了业务必需的域名和IP禁止内网服务器主动向互联网任意地址发起连接。使用下一代防火墙或代理服务器对所有出站流量进行认证和审计。主机层监控在重要的服务器上部署 EDR端点检测与响应 agent监控异常进程的网络连接行为。Venom 的 Agent 端运行后会产生一个进程EDR 可以检测到未知程序监听端口或发起网络连接。全流量分析在网络核心节点部署流量分析平台利用机器学习或规则引擎识别“长连接、低数据量、规律心跳”的加密隧道流量模式以及连接拓扑中出现的多级跳转特征。6. 综合防御从特征检测到体系化防护分析了这么多工具的特征最后我们来聊聊如何构建一个立体的、能有效应对内网隧道威胁的防御体系。光靠一两条检测规则是防不住的需要层层设防。第一层网络边界封堵与监控端口与协议限制在防火墙上严格限制内网服务器主动发起的出站连接。仅开放业务必需的协议如HTTP/HTTPS DNS和目的地址。对于需要访问外部API的业务建议通过统一的出口代理或API网关。TLS/SSL 解密与检测在具备法律合规条件的前提下对出站 HTTPS 流量进行解密审计。这能让你看清那些伪装在 HTTPS 下的 reGeorg 或加密 FRP 流量。检查 SNI、证书异常、JA3/JA3S 指纹等。威胁情报联动将已知的攻击者 C2命令与控制服务器 IP、域名、证书哈希等情报实时同步到防火墙和IDS实现自动阻断。第二层入侵检测与深度包分析自定义 IDS 规则根据我们前面总结的各类工具的特征JSON 结构、特定字符串、握手模式在 Suricata、Snort 或商业 NIDS 中编写高质量的自定义规则。规则要具体减少误报例如精确匹配run_id:这样的字段。行为分析引擎部署能够进行网络行为分析NBA的系统。关注以下异常行为内网服务器在非工作时间产生大量对外流量单个会话持续时间极长但流量很小心跳维持建立连接后长时间无应用层协议识别如未被识别为HTTP MySQL Redis等。第三层主机与终端加固权限最小化确保服务器上的 Web 应用如 Apache Nginx Tomcat以低权限用户运行并严格限制其文件系统访问和网络连接能力。Webshell 检测在 Web 服务器上部署动态 Webshell 检测工具或定期使用静态扫描工具扫描 Web 目录查找 reGeorg 等隧道脚本。EDR 全覆盖在所有重要资产上安装 EDR监控进程创建、网络连接、文件读写等行为。EDR 能有效发现 Venom Agent 等植入物并记录其行为链。第四层主动狩猎与应急响应常态化威胁狩猎蓝队不应只被动告警要主动出击。定期在全流量存储中使用上述特征进行搜索寻找“漏网之鱼”。可以尝试用这些工具的特征码YARA规则在内存或磁盘中扫描。完善的响应流程一旦检测到隧道活动立即启动应急响应。流程应包括网络隔离封禁IP、断开主机、进程内存转储分析、磁盘取证溯源攻击路径、排查横向移动痕迹、修改所有相关密码和密钥。说到底防守是一个持续对抗的过程。攻击工具在不断进化我们的检测手段也要随之迭代。最好的防御是建立一套让攻击者“进不来、藏不住、动不了、跑不掉”的纵深防御体系。希望这篇结合实战特征的分析能给你带来一些直接的启发和可落地的思路。在实际工作中多抓包、多分析、多总结你会逐渐形成自己的“流量直觉”在浩如烟海的数据包中一眼就能认出那些不怀好意的“隐形通道”。