Pystinger实战：从Webshell到内网穿透的端口映射与隧道技术详解

1. 项目概述与核心价值

最近在和一些做安全研究的朋友交流时，发现一个挺有意思的现象：很多刚入门的朋友，在拿到一个Webshell后，对于如何稳定、隐蔽地维持访问权限，特别是如何打通内网，常常感到无从下手。他们要么是直接暴露Webshell的端口，风险极高；要么是尝试各种复杂的隧道工具，配置起来又容易出错。这让我想起了几年前我们团队内部经常使用的一个“老伙计”——Pystinger。它虽然不像一些商业工具那样功能花哨，但胜在轻量、稳定，尤其是在从Webshell到端口映射这条路径上，堪称“瑞士军刀”。今天，我就结合自己踩过的无数个坑，来聊聊Pystinger的完整使用流程，目标是让你看完之后，能独立、安全地完成从上传到建立稳定通道的全过程。

简单来说，Pystinger是一个用Python编写的、用于实现端口映射和流量转发的工具。它的核心价值在于，当你通过某种方式（比如文件上传漏洞）在目标Web服务器上获得了一个Webshell后，Pystinger能帮你在这个Webshell环境中，快速建立一个通往你本地机器的隧道。这样，你就可以像访问本地服务一样，去访问目标内网的其他机器，或者将目标内网的端口映射出来，进行更深度的探测。整个过程，流量是封装在正常的HTTP/HTTPS协议里的，对于只做基础流量检测的防护设备来说，隐蔽性相对较好。当然，任何工具的使用都伴随着风险，尤其是配置不当导致的暴露。所以，这篇文章的重点不仅是“怎么做”，更是“怎么安全地做”，以及“为什么这么做”。

2. Pystinger工作原理与方案选型考量

2.1 核心工作模式解析

Pystinger之所以能在特定场景下发挥作用，源于其巧妙的工作模式。它主要包含两个组件：服务端（stinger_server）和客户端（stinger_client）。但这里需要特别注意，它的“服务端”是运行在你的攻击机器（即你控制的VPS或本地主机）上的，而“客户端”则是要上传到目标Web服务器、并在Webshell环境中执行的。这个命名可能和直觉相反，但理解这一点是避免后续配置混乱的关键。

其工作原理可以类比为一个“反向代理”或“端口转发器”。你的攻击机（运行stinger_server）监听一个端口，等待连接。目标服务器上的Webshell执行stinger_client，这个客户端会主动向外连接你的攻击机服务器，建立一个稳定的、长连接的通道。一旦通道建立，你就可以在你的攻击机上，通过连接本地监听的端口，将流量通过这个加密通道转发到目标内网的任意IP和端口。整个数据流被封装在看似正常的HTTP POST请求体中，响应则封装在HTTP响应体中，从而实现了流量的伪装。

2.2 为什么选择Pystinger？与其他工具的对比

在Webshell后渗透阶段，可选的隧道工具很多，比如reGeorg、Tunna、Neo-reGeorg等。选择Pystinger，主要是基于以下几个实战角度的考量：

1. 协议伪装与抗检测能力：Pystinger的流量完全基于HTTP/HTTPS，数据包特征相对固定，且支持自定义请求路径和头部，更容易绕过基于简单特征匹配的WAF或IDS。相比之下，一些基于原始TCP或自定义协议的工具，流量特征更明显。
2. 稳定性与资源占用：Pystinger使用长连接，避免了短连接频繁建立断开带来的开销和不稳定。其Python实现本身也比较轻量，在资源受限的Web服务器上运行时，对CPU和内存的占用远低于一些功能庞大的综合性C2框架。
3. 配置与使用的便捷性：Pystinger的配置相对直观，服务端和客户端的参数对应关系清晰。一旦理解其工作模式，排错和调整都比较方便。对于需要快速建立通道进行下一步内网横向移动的场景，效率很高。
4. 适用场景明确：它非常专注于解决“从Webshell到内网”这个单一问题，不掺杂其他复杂功能。这种专注使得它在特定任务上非常可靠。

当然，它也有局限性。例如，它主要解决的是TCP端口的转发，对于UDP或ICMP协议的支持需要额外处理。另外，其流量虽然经过伪装，但在高级威胁检测系统（如NDR、全流量分析）下，长时间、固定模式的通信依然可能被识别。因此，它更适合作为初期突破后快速建立据点的手段，而非长期、高隐蔽性的持久化通道。

注意：本文所有讨论均基于合法的安全测试、授权渗透测试或教育研究目的。未经授权对任何系统进行测试是非法行为。

3. 环境准备与工具获取

3.1 攻击机环境配置

你的攻击机需要具备一个公网IP地址，或者至少能与目标服务器进行网络通信。通常我们会选择一台云服务器（VPS）。操作系统推荐使用Linux，如Ubuntu或Kali，因为其网络工具链完整，操作方便。

首先，需要在攻击机上安装Python环境。Pystinger服务端通常需要Python 2.7或Python 3.x。为了兼容性，建议同时安装。

# 对于Ubuntu/Debian系统 sudo apt update sudo apt install python python3 python3-pip -y # 对于CentOS/RHEL系统 sudo yum install python python3 python3-pip -y

接下来，获取Pystinger的源代码。你可以从GitHub等开源平台搜索获取。下载后，解压并进入目录。通常目录结构会包含server和client文件夹，分别对应服务端和客户端程序。

wget [Pystinger的发布包下载链接] -O pystinger.zip unzip pystinger.zip cd pystinger ls -la # 你应该能看到类似 stinger_server.py, webshell 目录下的 client 文件等

3.2 Webshell上传与客户端适配

这是整个流程中最容易出错的环节。Pystinger的客户端需要上传到目标服务器并通过Webshell执行。它提供了多种语言版本的客户端，如PHP、JSP、ASPX等，存放在webshell目录下。你需要根据目标服务器的Web中间件和语言环境，选择正确的客户端。

例如，如果目标服务器是Apache + PHP，你就需要上传proxy.php（或类似名称的PHP客户端文件）。上传的方式取决于你最初获得Webshell的漏洞类型，可能是文件上传漏洞，也可能是通过Webshell管理工具（如蚁剑、哥斯拉）的文件管理功能直接上传。

这里有一个至关重要的细节：客户端文件本身需要被Web服务器解析执行。你不能简单地把一个.exe或.py文件传上去，因为Web服务器不会去执行它。必须是对应服务器脚本语言的文件。上传后，你需要通过浏览器或Webshell管理工具访问这个文件的URL，以确保它能正常返回一个页面（通常是空白或简单的“ok”）。这步验证是为了确认文件上传成功且位于Web可访问目录。

3.3 网络与防火墙策略检查

在启动任何服务之前，必须检查双方的网络策略：

1. 攻击机（VPS）：确保你用来监听的服务端端口（例如默认的3478）在防火墙（如iptables、ufw或云服务商的安全组）中是放行的。你需要配置规则允许外部IP访问这个TCP端口。
2. 目标服务器：目标服务器必须能够向外发起连接到你的攻击机IP和端口。这意味着目标服务器的出站防火墙或网络策略不能过于严格。在某些严格的内网环境中，服务器可能只能访问特定的白名单IP或端口，这时Pystinger可能无法直接使用，需要考虑其他跳板方式。
3. 你的本地机器：如果你是在本地电脑上运行攻击程序，还需要确保你的本地网络没有阻止入站连接（对于服务端），并且能访问VPS（如果你用VPS做中转）。

一个快速的检查方法是，从你的攻击机用nc或telnet测试一个已知的、目标服务器可能开放的出站端口（如80、443），反过来则很难测试。更实际的方法是，直接进行后续步骤，通过错误信息来判断网络连通性。

4. 服务端部署与启动详解

4.1 服务端参数解析与配置

进入Pystinger的server目录，查看stinger_server.py的使用帮助：

cd server python3 stinger_server.py -h

你会看到类似如下的参数说明：

-l LISTEN_PORT, --listen LISTEN_PORT Port to listen on (default: 3478) -s SHARED_SECRET, --secret SHARED_SECRET Shared secret for authentication (default: random) -p WEB_PORT, --web-port WEB_PORT The port of target web server (default: 80) --server-ip SERVER_IP The IP address of this server (default: auto detect)

• -l/--listen: 这是服务端监听的端口。客户端将连接这个端口。建议不使用默认的3478，改为一个不太常见的高位端口，比如45678，以减少被端口扫描发现的风险。
• -s/--secret: 共享密钥。这是最重要的安全参数。服务端和客户端必须使用相同的密钥才能建立连接。默认是随机生成，但为了可重复使用，你必须手动指定一个强密码。这可以防止他人恶意连接你的服务端。例如，可以使用-s MySuperSecretKey2024!。
• -p/--web-port:这个参数极其关键且容易误解。它指的是目标Web服务器对外提供Web服务的端口，通常是80或443。Pystinger客户端会利用这个端口来构建HTTP请求。如果你填错了，客户端构造的请求就无法正确到达你的服务端。
• --server-ip: 你的攻击机（服务端）的公网IP地址。如果服务端能自动检测到，可以不用指定。但在某些多网卡或Docker环境中，可能需要手动指定。

一个典型的启动命令如下：

python3 stinger_server.py -l 45678 -s YourStrongPasswordHere! -p 80 --server-ip 你的VPS公网IP

4.2 服务端启动与后台运行

直接运行上述命令，服务端会在前台运行并输出日志。对于长期测试，我们需要让它后台运行。

在Linux下，可以使用nohup配合&：

nohup python3 stinger_server.py -l 45678 -s YourStrongPasswordHere! -p 80 --server-ip 你的VPS公网IP > server.log 2>&1 &

这样，程序会在后台运行，日志输出到server.log文件。你可以用tail -f server.log来实时查看日志，或者用ps aux | grep stinger查看进程是否在运行。

实操心得：启动服务端后，第一时间用netstat -tlnp | grep 45678命令检查端口是否确实在监听。经常有人因为防火墙或权限问题，服务端进程起来了但端口没监听成功，导致后续客户端一直连不上。

5. 客户端上传、配置与激活

5.1 客户端文件选择与上传

根据目标环境，从webshell目录下选择正确的客户端文件。假设是PHP环境，我们选择proxy.php。这个文件通常需要根据你的服务端配置进行少量修改。用文本编辑器打开它，你会看到开头的配置部分：

$ip = '127.0.0.1'; $port = 3478; $secret = ''; $http_type = 'http'; $path = '/';

• $ip: 修改为你的攻击机（服务端）的公网IP地址。
• $port: 修改为服务端监听的端口（上例中的45678）。
• $secret:必须修改为和服务端启动时-s参数指定的完全一致的密钥（上例中的YourStrongPasswordHere!）。这是认证的关键，大小写敏感。
• $http_type: 根据目标Web服务器是HTTP还是HTTPS，修改为http或https。这影响客户端构造请求的协议。
• $path: 客户端访问自身Webshell的路径。如果你把proxy.php上传到了网站根目录，那么访问URL是http://target.com/proxy.php，这里就填/proxy.php。如果上传到了某个子目录，则需要填写完整路径，如/admin/shell/proxy.php。这个路径用于客户端自检和构造正确的请求URL。

修改完成后，保存。然后通过你的Webshell管理工具（如蚁剑、哥斯拉）的文件管理功能，将这个proxy.php上传到目标Web服务器的一个可写、可执行的Web目录下，例如/var/www/html/。

5.2 客户端激活与连接验证

上传成功后，你需要“激活”这个客户端。激活的方式就是通过浏览器或工具访问这个PHP文件的URL。例如，访问http://目标IP/proxy.php。

如果一切配置正确，页面可能会显示空白，或者简单的“ok”、“stinger client”等字样。更重要的是查看服务端的日志。回到你的攻击机，查看server.log：

tail -f server.log

你应该能看到类似这样的连接成功信息：

[INFO] New connection from [目标IP]:xxxxx [INFO] Client authenticated successfully.

这表示客户端已经成功连接到你的服务端，并且通过了密钥认证。隧道已经建立了一半。

5.3 客户端配置的常见陷阱

这里是我踩过最多坑的地方，总结一下：

1. 密钥不一致：这是最常遇到的问题。服务端的-s参数和客户端文件里的$secret变量必须一字不差。建议使用密码管理器生成并粘贴，避免手动输入错误。
2. IP或端口填错：客户端的$ip必须是服务端的公网IP，$port必须是服务端实际监听的端口。经常有人把内网IP或别的端口填进去。
3. $path配置错误：如果$path填错，客户端在自检或构造请求时会出现问题，可能导致连接不稳定或根本无法建立。务必确认上传后的完整访问路径。
4. Web服务器权限问题：上传的PHP文件必须有执行权限。在某些严格配置的服务器上，可能还需要检查open_basedir或disable_functions限制，确保socket_connect等函数未被禁用。
5. HTTPS配置：如果目标网站是HTTPS，客户端的$http_type必须设为https，否则构造的请求会被服务器拒绝或重定向。

6. 端口映射实战：打通内网服务

隧道建立后，Pystinger服务端就成为了一个通往目标内网的“门户”。我们现在要通过这个门户，访问目标内网的其他机器。

6.1 基本端口映射命令解析

Pystinger服务端在接收到客户端连接后，会提供一个简单的命令行交互界面。在服务端日志看到客户端成功连接后，你可以在运行服务端的终端（如果是后台运行，需要重新attach或者通过nc连接管理端口，具体看工具设计）输入映射命令。

典型的命令格式是：

connect [目标内网IP] [目标内网端口]

例如，你想访问目标内网中IP为192.168.1.100的机器的3389端口（Windows远程桌面），则输入：

connect 192.168.1.100 3389

执行后，服务端会告诉你它在本地打开了哪个端口来转发这个连接。比如：

[INFO] Listening on 0.0.0.0:6000 for 192.168.1.100:3389

这意味着，你现在可以在你的攻击机上，连接本地的6000端口，所有发往6000端口的流量，都会被通过Pystinger隧道转发到内网192.168.1.100:3389。

6.2 实战案例：访问内网Web服务与远程桌面

案例一：访问内网Web管理界面假设通过信息收集，发现内网有一台192.168.1.200的机器，开启了8080端口，是一个Jenkins管理界面。

1. 在Pystinger服务端交互界面输入：connect 192.168.1.200 8080
2. 服务端返回：[INFO] Listening on 0.0.0.0:6001 for 192.168.1.200:8080
3. 打开你攻击机的浏览器，访问http://127.0.0.1:6001。此时，你的浏览器流量通过本地6001端口 -> Pystinger服务端 -> 隧道 -> 目标Webshell所在服务器 -> 最终到达192.168.1.200:8080。你就能看到内网的Jenkins界面了。

案例二：连接内网Windows远程桌面假设内网机器192.168.1.100开启了3389端口。

1. 输入命令：connect 192.168.1.100 3389，假设返回本地端口6002。
2. 在你的Windows攻击机上（如果攻击机是Linux，需要用rdesktop等工具），打开“远程桌面连接”工具。
3. 在“计算机”栏输入127.0.0.1:6002，点击连接。你会发现你连接上了内网的192.168.1.100机器。

6.3 多端口映射与流量管理

你可以同时建立多个端口映射。服务端会为每个connect命令分配一个新的本地监听端口（通常是递增的，如6000, 6001, 6002...）。这非常方便，可以同时转发内网的SSH（22）、数据库（3306, 1433）、远程桌面（3389）等多种服务。

要管理这些映射，通常需要查看服务端的输出日志来知道哪个本地端口对应哪个内网服务。一些改进版的Pystinger或同类工具会提供list命令来查看当前所有活跃的转发会话。

当你需要断开某个映射时，通常直接Ctrl+C结束服务端进程会断开所有连接。对于单个连接的断开，取决于工具的具体实现，有些可以通过向管理端口发送特定命令来实现。

注意事项：频繁地建立和断开大量端口映射可能会在目标Web服务器和你的服务端产生明显的网络连接和进程痕迹。在真实的渗透测试中，建议按需使用，用完及时清理，保持低调。

7. 高阶技巧与隐蔽性优化

7.1 流量伪装与特征修改

基础的Pystinger流量仍有被识别的风险。我们可以通过修改客户端和服务端的代码来增强隐蔽性。

1. 修改User-Agent等HTTP头：在客户端的代码中，找到构造HTTP请求的部分，可以修改User-Agent为浏览器常见的字符串，如Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36。也可以添加或修改其他头部，如Accept、Accept-Language等，使其更像正常的浏览器请求。
2. 使用HTTPS隧道：如果目标网站支持HTTPS，务必在客户端配置中将$http_type设为https。这样所有隧道流量都是加密的，能有效防止流量内容被中间节点窥探。服务端也需要相应支持SSL解密（如果工具原生不支持，可能需要自己调整代码或使用反向代理）。
3. 自定义请求路径和参数：默认的请求路径可能比较显眼。可以修改客户端，将数据隐藏在看似正常的API请求或表单提交的路径和参数中。例如，将数据放在/api/v1/user/update的POST表单的某个字段里。
4. 增加随机延迟和抖动：在客户端发送请求的循环中，增加随机的、小幅的延迟，避免流量呈现出完美的、机器般的定时心跳，这有助于规避基于流量时序分析的检测。

7.2 服务端隐藏与抗溯源

1. 使用非标准端口：如前所述，避免使用3478等默认端口。
2. 域名与CDN掩护：不要直接用IP连接。可以为你的VPS绑定一个域名，并将客户端中的$ip改为这个域名。更进一步，可以使用CloudFlare等CDN服务来代理你的VPS流量，这样目标服务器连接的是CDN的IP，增加了溯源难度。但需注意，CDN可能不支持转发非HTTP/HTTPS流量到你的自定义端口，需要仔细配置。
3. 定期更换密钥和端口：在长期任务中，定期更换服务端的监听端口和共享密钥，并更新客户端文件。
4. 服务器加固：确保你的VPS本身安全，使用强密码/密钥登录，关闭不必要的端口和服务，及时更新系统，避免成为攻击跳板后被反制。

7.3 与C2框架的结合使用

Pystinger可以作为一个独立的隧道工具，也可以与Metasploit、Cobalt Strike等C2框架结合，作为其流量转发层。通常的做法是：

1. 用Pystinger将内网某个端口（如4444）映射到你的VPS的某个端口（如6000）。
2. 在C2框架中，配置一个reverse_http或reverse_tcp的payload，让其回连到127.0.0.1:6000。
3. 这样，C2的流量就通过Pystinger隧道进行了转发和伪装。

这种方法能利用C2框架强大的后期渗透能力，同时享受Pystinger在协议层带来的隐蔽性提升。

8. 常见问题排查与实战心得记录

即使按照步骤操作，也难免会遇到问题。下面是我在多次实战中积累的排查清单和解决方法。

8.1 连接建立失败排查表

8.2 实战心得与避坑指南

1. “先测试，后上线”：在真正对目标使用前，最好在本地或测试环境搭建一个模拟场景（例如，用虚拟机搭建LAMP/WAMP环境），完整走一遍流程。这能帮你熟悉工具，并提前发现配置问题。
2. 密钥管理是生命线：共享密钥是唯一的安全凭证。务必使用强密码（大小写字母、数字、符号混合，长度大于16位），并且每次任务使用不同的密钥。切勿使用默认或弱密码。
3. 日志就是足迹：无论是服务端的server.log，还是目标Web服务器的访问日志、错误日志，都会留下记录。在授权测试中，这是证明你操作过程的证据；在非授权场景下，这就是暴露你的痕迹。测试完成后，记得清理服务端日志，对于客户端文件，最好能自行实现删除功能。
4. 理解“Webshell”的局限性：Pystinger客户端运行在Webshell上下文，其权限和稳定性受限于Web服务器进程（如www-data, apache用户）。这个用户可能权限很低，无法访问某些系统资源或发起某些类型的网络连接。如果遇到权限问题，可能需要先进行提权。
5. 备选方案：永远要有B计划。Pystinger不是万能的。如果它因为环境原因无法使用，要熟悉其他备用工具，如reGeorg、Neo-reGeorg、DNS隧道、ICMP隧道等。不同的网络环境适合不同的隧道技术。
6. 保持更新：关注工具的GitHub仓库或发布渠道，及时更新版本。旧版本可能存在已知漏洞或兼容性问题。同时，安全产品的检测能力也在进化，工具的免杀和伪装特性需要持续改进。

9. 法律边界与道德自律

最后，也是最重要的一部分，我必须再次强调使用的边界。Pystinger以及文中提及的任何技术、方法，都是一把双刃剑。

• 严格在授权范围内使用：仅在拥有明确书面授权的渗透测试、安全评估、教学实验或自己完全可控的实验室环境中使用这些技术。未经授权访问他人计算机系统是明确的违法行为。
• 明确测试目标：在授权测试中，与客户明确测试范围（哪些IP、域名、系统），不要越界。你的每一个操作都可能对业务系统造成影响。
• 最小化影响原则：尽量使用只读操作进行信息收集，避免对系统数据进行修改、删除。如果必须进行验证性利用，应选择非业务高峰时段，并做好回滚预案。
• 保护数据与隐私：在测试过程中接触到的任何数据，无论是否敏感，都应视为机密，不得复制、传播或用于任何其他目的。测试结束后，应按照要求妥善处理或销毁相关数据。
• 持续学习与合规：网络安全技术日新月异，法律法规也在不断完善。作为一名从业者，持续学习技术的同时，也必须关注《网络安全法》、《数据安全法》、《个人信息保护法》等相关法律法规，确保自己的行为始终在合法合规的轨道上。

技术本身无罪，关键在于使用它的人。希望这篇文章提供的知识，能帮助你在合法的道路上，更好地理解网络攻防的对抗本质，提升安全防御的能力。真正的安全专家，是那些深知如何突破，从而更懂得如何守护的人。