1. 项目概述当RDP遇上内网隔离做内网渗透测试的朋友对“看得见摸不着”的远程桌面RDP服务一定不陌生。目标内网里3389端口就在那里但你和它之间隔着一道又一道的防火墙只允许HTTP/HTTPS流量通行。直接连接门都没有。这时候传统的端口转发工具如lcx、netcat可能因为协议特征明显或端口被禁而失效。我们需要一种更隐蔽、更贴合现有出口策略的方法这就是基于HTTP隧道的端口转发技术。Tunna正是为解决这类场景而生的利器。它不是一个新工具但在特定环境下其简洁高效的设计思路依然极具实战价值。简单来说Tunna能在你控制的Web服务器通常是通过Web漏洞上传的和目标内网服务如RDP之间建立一条基于HTTP协议的“隐形通道”。所有你对RDP的操作数据都被封装在普通的HTTP请求和响应里进行传输从而绕过网络层基于端口的访问控制。最近在解决一些客户的横向移动难题时我发现很多安全人员对这类工具的理解还停留在“会用”层面对其原理、部署细节和排错技巧知之甚少导致在复杂环境中举步维艰。今天我就结合多次实战踩坑的经验把Tunna玩转RDP端口转发的整个流程掰开揉碎从原理到落地从配置到排错给你讲透彻。2. 核心原理与工具选型解析2.1 HTTP隧道为何是它在深入Tunna之前我们必须理解为什么HTTP隧道在内网穿透中如此重要。现代企业网络为了安全和管理便利普遍会实施严格的出口过滤。常见的策略是只允许80HTTP、443HTTPS、53DNS等少数必要端口对外通信像3389RDP、22SSH、445SMB等高危端口一律阻断。这种环境下传统的TCP端口转发如SSH隧道、reGeorg的SOCKS代理如果使用非标端口同样会被拦截。HTTP协议的优势就此凸显普遍放行HTTP/HTTPS是业务必需品防火墙和代理通常不会阻拦。易于伪装隧道流量可以模拟成正常的Web API调用、文件上传下载或静态资源请求特征相对隐蔽。穿透能力强许多中间设备如WAF、反向代理、负载均衡本身就是为了处理HTTP流量而设计隧道流量可以借道而行。Tunna的实现原理就是在Web服务器端我们称之为“代理端”或“server端”运行一个特殊的脚本如proxy.py或tunna.php。这个脚本会监听本地的某个端口例如8888但这个端口并不直接对外服务。当外部攻击者客户端想要连接内网的RDP服务时他会先向这个Web脚本发送一个特殊的HTTP请求。Web脚本收到请求后会解析出其中封装的目标地址和端口即内网RDP服务器的192.168.1.100:3389然后以自身Web服务器的身份去建立一条到目标RDP端口的TCP连接。此后客户端的所有RDP数据包都会被编码后通过HTTP POST请求体发送给Web脚本Web脚本解码后转发给RDP服务RDP的响应数据则被Web脚本编码后通过HTTP响应体返回给客户端。整个过程中防火墙看到的只是一系列普通的HTTP数据交互。2.2 Tunna vs. 其他工具为何选择它提到HTTP隧道很多人会想到reGeorg、Neo-reGeorg、ABPTTS等。它们各有优劣我选择Tunna进行RDP转发主要基于以下几点实战考量针对端口的直接转发reGeorg等工具主要提供的是SOCKS5代理适用于需要动态访问多个内网服务的场景。但如果你只需要稳定、低延迟地访问某一个特定服务如RDPTunna这种直接的端口转发模式更高效。它相当于在本地和远程服务之间建立了一条“专线”省去了SOCKS代理协议转换的开销对于RDP这种对实时性要求较高的协议尤其友好。部署简单依赖少Tunna的服务器端通常就是一个独立的Python脚本或PHP文件几乎不需要额外的库支持。在已经获取Webshell的环境里上传即用非常方便。相比之下一些功能更复杂的工具可能需要特定的运行时环境或编译模块。连接稳定在我的实测中Tunna建立的隧道连接相对持久和稳定适合进行需要长时间交互的RDP远程桌面操作不易出现非预期中断。当然Tunna也有其局限性。它不支持加密隧道内的HTTP流量是明文的虽然可以部署在HTTPS网站后获得传输层加密并且功能相对单一。但对于“打通RDP”这个单一目标它往往是那个最直接、最有效的选择。这里也提一下搜索热词中的guacamole-common rdp demoApache Guacamole是一个强大的无客户端远程桌面网关它本身是一个正经的远程访问解决方案其原理也是在服务端进行协议转换RDP/VNC/SSH - HTML5和渗透测试中的隧道工具是不同维度的产品切勿混淆。2.3 工具准备与环境假设为了完成本次实战我们需要准备以下内容Tunna工具包从GitHub等可信源获取Tunna。攻击机Kali Linux作为客户端IP为10.10.10.1需要能访问目标Web服务器。目标Web服务器我们已经通过某种方式如文件上传漏洞获取了其Webshell权限并且可以上传文件。假设其外网IP为203.0.113.100内网IP为172.16.1.10。服务器上运行着Python环境用于执行proxy.py。内网RDP服务器这是我们最终要访问的目标假设其IP为172.16.1.100开放了默认的3389端口且从Web服务器172.16.1.10可以访问到它。本地RDP客户端攻击机上的rdesktop、xfreerdp或Windows自带的“远程桌面连接”。注意所有操作应在获得明确授权的渗透测试或安全评估环境中进行。未经授权使用这些技术攻击他人系统是违法行为。3. 实战部署一步步构建HTTP隧道3.1 服务端部署上传与启动首先我们需要将Tunna的服务器端脚本上传到目标Web服务器。Tunna通常提供多种语言版本这里我们使用Python版本proxy.py因为它更通用。上传脚本通过已有的Webshell文件管理功能将proxy.py上传到网站可访问的目录例如/var/www/html/uploads/。确保该目录有执行Python脚本的权限通常Web服务器进程用户如www-data或apache有读取和执行权限。启动隧道服务端通过Webshell执行命令。这里的关键是proxy.py需要以Web服务器进程的身份在后台运行并绑定到一个本地端口。这个端口将作为隧道对内网服务的“跳板”。# 通过Webshell执行 cd /var/www/html/uploads python proxy.py --port 8888 --log /tmp/tunna.log --verbose --port 8888指定代理脚本本地监听的端口。这个端口是Web服务器本机上的一个TCP端口用于接收来自proxy.py自身Web接口的转发指令。它不对外网开放。--log /tmp/tunna.log将运行日志输出到指定文件便于排查问题。--verbose输出详细日志。让命令在后台运行避免Webshell会话超时导致进程退出。执行成功后你应该能看到类似Proxy server started on port 8888的日志。你可以用netstat -tunlp | grep 8888或ps aux | grep proxy.py来验证进程是否正常运行。3.2 客户端连接建立隧道服务端准备就绪后我们在攻击机Kali上使用Tunna的客户端进行连接。客户端的作用是连接本地端口并将流量封装成HTTP请求发送给Web服务器上的脚本。假设我们上传的proxy.py可以通过URLhttp://203.0.113.100/uploads/proxy.py访问。在攻击机上执行python proxy.py -u http://203.0.113.100/uploads/proxy.py -l 13389 -r 172.16.1.100:3389 -v-u指定远端Web服务器上Tunna代理脚本的URL。-l 13389在攻击机本地开启的端口。后续我们将用RDP客户端连接这个端口。-r 172.16.1.100:3389指定远端从Web服务器角度看要连接的真实目标即内网RDP服务器的地址和端口。-v显示详细连接信息。如果一切正常客户端会输出Connected to remote host等信息并保持运行。此时一条从你本机13389端口到内网172.16.1.100:3389端口的HTTP隧道就建立好了。本质上本地13389端口被客户端进程监听它将所有收到的数据通过HTTP隧道经由http://203.0.113.100/uploads/proxy.py这个“中转站”最终送达内网的RDP服务。3.3 连接RDP完成最后一跳隧道建立后连接RDP就变得和连接本地服务一样简单。打开你的RDP客户端。如果使用rdesktoprdesktop 127.0.0.1:13389 -u administrator -p YourPassword如果使用更现代的xfreerdpxfreerdp /v:127.0.0.1:13389 /u:administrator /p:YourPassword fonts /floatbar这里的关键是服务器地址填127.0.0.1本机端口填我们隧道客户端监听的13389。你的RDP客户端会像连接普通本地端口一样发起连接而背后的Tunna客户端会默默地将所有流量通过HTTP隧道转发出去。4. 深度配置与高级技巧4.1 应对复杂网络与认证实战环境很少是一帆风顺的。下面是一些常见复杂情况的处理技巧Web路径含认证或隐藏路径有时上传的脚本不在Web根目录或者访问路径需要额外的参数、Cookie。Tunna客户端支持--cookie、--header等参数。例如如果脚本需要通过一个带会话Cookie的接口访问python proxy.py -u http://target.com/admin/interface.php -l 13389 -r 172.16.1.100:3389 --cookie PHPSESSIDabc123def456HTTPS网站如果目标网站使用HTTPS直接将-u参数中的http改为https即可。Tunna客户端会处理SSL/TLS加密。这是非常推荐的做法可以避免隧道中的流量在传输过程中被明文嗅探。目标RDP端口非默认如果内网RDP服务修改了端口例如改为3390只需修改-r参数为172.16.1.100:3390。稳定化与保活长时间不操作隧道可能因HTTP超时或网络波动中断。可以编写简单的脚本定期通过隧道发送一个小数据包如连接一个不存在的TCP端口来保持连接。更优雅的做法是使用autossh之类的工具包装Tunna客户端进程实现断线自动重连。4.2 性能优化与隐蔽性考量数据编码与压缩默认情况下Tunna使用Base64编码隧道数据。虽然这有助于绕过一些简单的关键词检测但也会增加约33%的数据量。在带宽充足的情况下这问题不大。如果追求更低延迟可以研究Tunna是否支持其他编码方式如纯十六进制或者考虑其他支持压缩的隧道工具。但要注意修改编码方式可能增加特征性。流量伪装Tunna的HTTP请求有一定特征。高级的防御设备可能检测到异常的、持续的POST请求模式。为了增强隐蔽性可以修改proxy.py脚本中的USER_AGENT、URL路径等使其更像正常的浏览器或应用请求。将隧道脚本放在一个真实的、存在大量正常API请求的路径下鱼目混珠。控制RDP会话的数据流量避免长时间、高带宽的图形传输引起注意。可以尝试降低RDP连接的颜色深度和分辨率。多路复用与负载均衡对于需要同时转发多个服务或追求极高稳定性的场景单一的Tunna隧道可能不够。可以考虑在Web服务器上部署多个不同端口的proxy.py实例或者使用功能更强大的框架如Metasploit的web_delivery模块配合reverse_httppayload来建立更健壮的通信通道。5. 实战问题排查与深度避坑指南即使按照步骤操作你也可能会遇到各种问题。下面是我在多次实战中总结的“排错树”和独家技巧。5.1 连接建立失败分步诊断如果Tunna客户端无法连接或者连接后RDP无法通信请按以下顺序排查检查Web脚本可访问性这是第一步也是最容易忽略的一步。用浏览器或curl直接访问你设置的-u参数URL例如http://203.0.113.100/uploads/proxy.py。你应该能看到一个简单的Tunna服务页面或者至少不是404/403错误。如果是403检查文件权限如果是404检查上传路径是否正确。检查服务端进程通过Webshell确认proxy.py进程是否在运行ps aux | grep proxy以及是否在监听指定端口netstat -tunlp | grep 8888。有时Web服务器权限不足无法绑定1024以下的端口建议使用8888、8080等高位端口。检查网络连通性从Web服务器到RDP在Web服务器上执行telnet 172.16.1.100 3389或nc -zv 172.16.1.100 3389确认可以连接到目标RDP端口。如果不通可能是内网防火墙规则限制需要先进行内网信息收集寻找可达路径。检查客户端日志运行Tunna客户端时加上-v甚至-vv参数观察输出信息。常见的错误有Error: Remote host returned error通常意味着Web脚本执行出错回去检查服务端日志/tmp/tunna.log。Failed to connect to remote server客户端无法连接到你指定的-uURL检查网络可达性、代理设置等。连接建立后立刻断开可能是目标RDP服务需要特定的网络层协商或者隧道传输的数据包格式有误。尝试使用--no-check参数如果客户端支持跳过某些检查。检查本地端口占用确认你指定的本地端口如13389没有被其他程序占用。使用netstat -tunlp | grep 13389查看。5.2 RDP连接特有难题即使隧道通了连接RDP时也可能遇到怪事。这与热词中提到的rdp远程识别不到usb、rdp wrapper等问题有些关联但场景不同。错误“发生身份验证错误无法连接到本地安全机构”这通常是Windows系统特别是打了某些补丁后的CredSSP加密Oracle修正导致的。在攻击机Linux上可以通过修改xfreerdp的连接参数解决xfreerdp /v:127.0.0.1:13389 /u:user /p:pass /sec:tls /cert-ignore重点是/sec:tls指定安全层/cert-ignore忽略证书警告。在Windows远程桌面客户端中可以在“显示选项” - “高级” - “设置”中将身份验证级别调整为“允许连接使用任何版本的远程桌面”。连接成功但黑屏或立即断开这可能是由于RDP会话所需的虚拟通道如剪贴板、磁盘重定向、打印机在隧道中传输不稳定导致的。尝试禁用所有重定向功能建立一个最基础的会话xfreerdp /v:127.0.0.1:13389 /u:user /p:pass /sec:tls fonts -clipboard -drives -printers /f参数-clipboard -drives -printers禁用了这些功能/f是全屏模式有时能增加稳定性。先保证基础图形桌面能稳定连接再逐步开启所需功能。性能极差卡顿严重HTTP隧道毕竟有封装/解封装的开销且受Web服务器性能和中转网络质量影响。可以尝试在RDP客户端中降低连接设置如将颜色深度改为16位禁用壁纸、字体平滑、动画等视觉效果。确保Web服务器资源CPU、内存充足。如果可能将proxy.py进程的优先级调高。这是HTTP隧道用于图形化协议的固有短板如果对操作流畅度要求极高可能需要考虑其他穿透方案如使用DNS隧道或寻找更直接的漏洞进行权限提升和跳板。5.3 安全设备绕过与痕迹清理WAF/IDS检测一些WAF会检测异常的HTTP POST请求长度和频率。Tunna的流量模式是连续的、大小不一的POST请求这可能触发规则。应对方法包括在客户端或服务端脚本中加入随机延迟jitter将大请求拆分成多个小请求需要修改工具代码或者寻找一个存在合法大流量POST请求的页面来“寄生”你的隧道脚本。日志清理proxy.py默认会生成日志。在测试结束后务必通过Webshell清理掉/tmp/tunna.log以及Web访问日志如Apache的access.log、error.log中与隧道脚本URL相关的条目。上传的proxy.py文件本身也要记得删除。进程隐藏简单的ps aux就能看到Python进程。可以尝试将proxy.py重命名为一个看似正常的系统脚本名或者使用nohup结合重定向让进程更隐蔽。更高级的做法是使用内存执行技术不落盘文件但这超出了Tunna的基本使用范畴。6. 拓展思考与其他技术栈的协同Tunna解决的是“通道”问题。在实际的内网渗透中它往往是整个攻击链中的一环。我们需要思考如何将它与其他技术协同。与端口扫描结合在获取Webshell后先用proxy.py搭建一个SOCKS代理如果Tunna版本支持或者使用reGeorg对内网进行初步扫描发现RDP服务后再改用Tunna建立专线隧道效率更高。与漏洞利用结合可能我们最初上传的Webshell权限很低如www-data用户。在通过Tunna连接内网某台服务器后如果那台服务器存在本地提权漏洞我们可以获得一个更高权限的立足点。然后可以尝试在那台服务器上部署新的隧道端点实现跳板跃进。与横向移动工具结合通过Tunna建立的RDP连接我们可以登录到内网机器。在这台机器上可以运行诸如Mimikatz、BloodHound的采集器SharpHound等工具进一步收集凭证、分析域内关系为下一阶段的横向移动做准备。此时这台通过隧道连接的RDP主机就成了我们在内网中的一个“物理”据点。最后我必须再次强调技术是把双刃剑。Tunna这样的工具在渗透测试人员手中是划开防御缺口的手术刀在攻击者手中则是危险的武器。本文所有内容旨在为安全从业人员提供知识储备和防御视角请务必在合法合规的范围内使用。理解攻击手法才能更好地构建防御。在防守端除了传统的防火墙策略更需要部署能够深度检测HTTP隧道流量异常行为的NIDS/NIPS、以及具备威胁狩猎能力的SIEM平台不放过任何一丝可疑的“正常”流量。