[点晴永久免费OA]内网穿透与隐蔽隧道:从FRP到DoH(dns over Https)
|
admin
2026年7月17日 15:43
本文热度 68
|
攻防技术 · 深度科普 内网穿透与隐蔽隧道:从 FRP 到 DoH 隧道借一条被允许的出站通道,把内网"翻"出来——原理、工具横评与蓝队检测 |
边界防火墙—入站严防死守、出站几乎不设防,这是绝大多数企业网络的常态。而内网穿透和隐蔽隧道技术,吃的就是这口“不对称”的饭。
无论是运维人员用 FRP 在家访问公司内网服务器,还是攻击者在内网建立 C2 控制通道,底层逻辑完全一样:让内网机器主动向外“打”一条通道,再把内网的访问能力顺着这条通道“暴露”到外面来。 |
01 · 为什么需要隧道:出站才是软肋典型企业网络的边界策略是入站默认拒绝、出站默认放行。内网主机藏在 NAT 之后没有公网 IP,外部无法主动连入;但内网主机访问外网(DNS 解析、HTTP 浏览、软件更新)几乎畅通无阻。
攻击者拿下一台内网机器后的第一个问题就是:如何稳定控制它、并以它为跳板访问内网其他资产?答案就是让被控主机主动向外建立连接(反向连接),再在这条连接上反向传输控制指令与转发流量。 |
02 · 基础:端口转发与代理正向 vs 反向。正向连接是攻击者主动连被控机(要求被控机有可达端口,内网几乎不可用);反向连接是被控机主动连攻击者——绕开入站限制,是内网穿透的默认姿势。
端口转发。把某端口的流量透明转发到另一台主机的某端口。本地转发把本机端口映射到远端服务,远程转发把远端端口映射回本地服务。
SOCKS 代理。端口转发是"一对一",每加一个目标就要配一条规则;SOCKS 代理提供"一对多"的动态隧道,配合 proxychains 让任意工具的流量都经隧道进入内网,是横向移动的关键能力。 |
03 · FRP:最流行的反向代理穿透FRP(Fast Reverse Proxy)是开源跨平台的内网穿透工具,运维和红队都在用。模型是 frps(服务端,公网)+ frpc(客户端,内网):frpc 主动连接公网 frps 绕开 NAT 与入站限制,frps 在公网监听端口把外部访问转发回 frpc 暴露的内网服务,支持 TCP/UDP/HTTP/HTTPS/STCP/SOCKS5 等多种代理类型。 |
frpc.ini —— 把内网 3389 暴露到公网 frps 的 7001
[common] server_addr = 1.2.3.4 server_port = 7000 token = SecretToken
[rdp] type = tcp local_port = 3389 remote_port = 7001 |
默认配置特征明显
FRP 支持 tls_enable 加密控制连接、use_encryption 加密代理流量。但 frps 的固定监听端口、心跳包节奏、未改造的 TLS 指纹,都是检测抓手。 |
04 · SSH 隧道:机器上本就有的瑞士军刀目标机上通常本就装着 SSH 客户端,无需投递额外文件,这让 SSH 自带的转发能力成为最低调的隧道工具。 |
| | |
| ssh -L 8080:intranet:80 ... | |
| ssh -R 7001:127.0.0.1:3389 ... | |
| ssh -D 1080 ... | |
动态转发(-D)配合 proxychains 是内网横向的经典组合。但 SSH 出站到非常规外部地址的长连接,本身就值得告警。
Ligolo-ng 近年很受青睐:在攻击端创建 TUN 虚拟网卡,内网网段直接作为本地路由可达,无需逐条转发也无需 proxychains,体验接近"内网就在本地"。
06 · 协议隧道:当端口转发也被掐断当出站策略严格到只放行特定应用协议时,攻击者把数据封装进被允许的协议里,这就是协议隧道。
▸ ICMP 隧道:把数据塞进 ping 的载荷(icmptunnel、ptunnel)。许多网络放行 ICMP 却不深检,但 ICMP 流量本身较易识别。
▸ HTTP/HTTPS 隧道:把流量伪装成正常 Web 请求/响应。这是绝大多数现代 C2 框架的默认信道,配合域前置与合法 CDN 可进一步隐藏真实地址。
▸ DNS 隧道:利用"几乎没有网络会封 DNS",把数据编码进子域名查询与 TXT/NULL 响应。 |
DNS 隧道:数据 Base32 编码进子域名
aGVsbG8gd29ybGQ.tunnel.evil.com → 权威服务器(攻击者)解码取数据 ← TXT 记录回传下行数据 |
iodine 与 dnscat2 是两个经典 DNS 隧道实现。带宽低、延迟高,但穿透力极强——在只能解析 DNS 的访客网络里往往是唯一可用的出口。

▲ 反向连接:内网主机主动向外建链,控制流量沿同一通道回传
07 · DoH 隧道:藏进 443 的加密 DNSDNS-over-HTTPS(DoH)把 DNS 查询封装进 HTTPS 请求,走 443 端口、TLS 加密。它本为保护隐私而生,却给隧道带来了最难检测的一种形态:
• 流量是标准 HTTPS,与普通网页浏览混在一起,端口、TLS 指纹都不异常
• 内容被 TLS 加密,传统基于明文 DNS 的检测规则(超长域名、TXT 集中查询)全部失效
• 公共 DoH 服务商的普遍存在,让"连向 DoH 端点"看起来完全合理 |
💡 检测重心因此从"看 DNS 内容"被迫转向"看连接行为"——哪些主机在向 DoH 端点发起异常高频、长时的请求。 |

▲ 恶意载荷藏进正常协议流量,最终都汇入常开的 443 端口
08 · 蓝队视角:流量特征与检测隧道再隐蔽,也要在"通信行为"上留下统计学痕迹。 |
| |
| |
| |
| 超长子域名、TXT/NULL 激增、单域名高频随机子域名、熵值高 |
| 固定 URI、规律 beacon 间隔、UA 异常、自签证书 |
| |
通用方法论:为每台主机建立出站基线并对偏离告警;用 Beacon 分析捕捉规律心跳;对加密流量用 JA3 指纹区分工具家族;DNS 维度看域名长度、查询类型分布与子域名熵;最有效的是出站收敛——强制出站经受控代理,只放行白名单。
🛡 网络层:出站默认拒绝、白名单放行;强制 DNS 走内部解析器并禁用客户端自带 DoH;对 443 出站做 TLS 检查或代理收敛。 |
🛡 检测层:部署支持 Beacon 分析与 JA3 指纹的 NDR/IDS;DNS 启用熵与频率告警;监控异常长连接与非常规端口出站。 |
🛡 主机层:EDR 监控可疑隧道进程(frpc、chisel、ssh -R/-D 等)与异常网络行为;最小化跳板机的出站权限。 |
结语:内网穿透与隐蔽隧道的攻防,归根结底是一场围绕"出站通道"的拉锯。攻击者不断把载荷藏进更"正常"的协议——从裸 TCP 到 HTTP,再到混入 443 的 DoH;防守方则从"看内容"被迫升级到"看行为"。没有哪一条规则能一劳永逸,真正的防线是最小化出站面:能不放行的端口不放行,能收敛的协议就收敛。 |
阅读原文:点击这里
该文章在 2026/7/17 15:43:56 编辑过