从零搭建渗透测试沙箱：基于Apache Tomcat与Shiro漏洞的哥斯拉实战环境

1. 项目概述：为什么我们需要一个可控的渗透测试环境？

在网络安全领域，无论是进行安全研究、漏洞复现，还是企业内部的红蓝对抗演练，一个稳定、可控且贴近实战的渗透测试环境都是至关重要的。很多新手朋友拿到一个工具，比如哥斯拉（Godzilla），直接往公网靶场或者自己公司的测试服务器上丢，结果要么是操作不成功一头雾水，要么是操作成功了却引发了一系列意想不到的“事故”，比如把服务搞挂了，或者触发了安全设备的告警。这背后的核心原因，就是缺少一个安全的“沙盒”环境来练手和调试。

哥斯拉作为一款功能强大的WebShell管理工具，其本身的使用，特别是与MSF（Metasploit Framework）等工具的联动，涉及到复杂的通信、编码和会话维持机制。这些机制在理想化的教程里可能一笔带过，但在真实的网络环境中，会受到防火墙策略、中间件配置、系统权限、网络延迟等多重因素的影响，从而产生诸如Shell不稳定、命令执行无回显、文件上传失败等一系列“玄学”问题。如果直接在目标环境上调试这些问题，无异于在雷区里学排雷，风险极高。

因此，我们今天要做的，就是在本地或隔离的网络中，从头搭建一个专用于渗透测试技术学习和工具验证的“训练场”。这个环境将包含一个存在漏洞的Web应用（例如集成了Shiro框架的应用）、一个可控的Web服务器，以及我们的主角——哥斯拉WebShell。通过在这个封闭环境里复现操作、触发错误并逐一解决，你不仅能熟练掌握哥斯拉的各项功能，更能深刻理解WebShell与中间件、操作系统交互的底层原理，从而在未来的实战中做到心中有数，游刃有余。接下来，我将以一个典型的“Apache Tomcat + 存在Shiro反序列化漏洞的Web应用”为例，带你一步步搭建环境，并重点剖析那些教程里不常提，但实际一定会遇到的坑和解决方案。

2. 环境整体设计与核心组件选型

搭建一个用于渗透测试学习的环境，核心思路是模拟一个尽可能真实但绝对无害的“靶标系统”。我们需要几个关键组件：一个运行Web应用的服务器、一个存在已知漏洞的应用程序、以及我们的攻击管理工具链。这里的选择背后都有其考量。

2.1 服务器与中间件选型：为什么是Apache Tomcat？

我选择Apache Tomcat作为Web服务器（更准确说是Servlet容器），原因有三点。首先，普及性高：Tomcat是Java Web应用最常用的部署容器之一，在互联网和企业内网中保有量巨大，学习它的环境配置具有很高的实战价值。其次，环境单纯：相比集成度高的PHP环境（如LAMP），Tomcat环境变量相对清晰，便于我们定位问题，例如后续涉及的Java版本、ClassPath等问题。最后，便于漏洞复现：许多经典的Java反序列化漏洞（如Shiro、Fastjson）都在Tomcat环境下有成熟的复现案例和利用方式。

注意：请务必在虚拟机或物理隔离的网络中搭建此环境。推荐使用VirtualBox或VMware创建一台纯净的Linux虚拟机（如Ubuntu 20.04 LTS），这能保证你的实验操作不会影响任何真实系统。

2.2 漏洞应用选型：为何选择集成Shiro的应用？

为了练习哥斯拉的使用，我们需要一个“入口”。一个存在漏洞的Web应用就是这个入口。Shiro（Apache Shiro）是一个强大的Java安全框架，但其历史上存在的反序列化漏洞（CVE-2016-4437等）利用方式成熟，且与哥斯拉的内存马注入技术结合紧密，是学习“漏洞利用 -> WebShell植入 -> 权限维持”完整链条的绝佳案例。网络上有很多集成了Shiro漏洞的演示项目，例如一些开发者故意留出漏洞的“若依（RuoYi）”框架版本，或者专门的漏洞靶场项目。选择这类应用，能让我们聚焦于工具使用和问题排查，而不是花费大量时间在漏洞挖掘上。

2.3 工具链选型：哥斯拉与配套工具

• 哥斯拉（Godzilla）：本项目核心。它是一个基于Java开发的WebShell管理平台，支持多种脚本类型（JSP、PHP、ASPX等），提供文件管理、命令执行、数据库管理、内网穿透等丰富功能，且加密通信特性较好。
• Java Development Kit (JDK)：运行Tomcat和Web应用的基础。需要特别注意版本兼容性。
• Metasploit Framework (MSF)：可选，但强烈建议安装。用于模拟高级攻击场景，如生成反向Shell负载、与哥斯拉进行联动。这也是网络搜索中提到的“Shell不稳定”问题的典型场景。

这个选型组合，覆盖了从基础环境搭建、漏洞利用、到后渗透阶段工具管理的完整流程，是一个经典且高效的学习路径。

3. 详细搭建步骤与关键配置解析

接下来，我们进入实操环节。请跟随步骤一步步操作，并特别注意我标注的“关键点”和“避坑指南”。

3.1 基础系统与Java环境准备

首先，在我们的实验虚拟机中，更新系统并安装必要软件。

# 更新软件包列表 sudo apt-get update # 安装编译工具和网络工具 sudo apt-get install -y wget curl net-tools

安装JDK。这里有一个极易踩坑的点：Tomcat和很多Java应用对JDK版本有要求。对于较新的漏洞环境（如某些Shiro利用链），可能需要JDK 8u191以下版本，因为高版本JDK限制了某些反序列化利用。但为了环境通用性，我们安装JDK 11（一个长期支持版本），它兼容大部分场景。

# 安装OpenJDK 11 sudo apt-get install -y openjdk-11-jdk # 验证安装 java -version

输出应类似openjdk version "11.0.xx"。请记下你的具体版本号。

3.2 部署Apache Tomcat

我们不使用系统包管理器安装Tomcat，而是手动下载并配置，这样拥有更高的控制权，便于理解目录结构和后续的调试。

1. 下载与解压：

   # 进入临时目录 cd /tmp # 下载Tomcat 9（一个稳定且广泛使用的版本） wget https://archive.apache.org/dist/tomcat/tomcat-9/v9.0.68/bin/apache-tomcat-9.0.68.tar.gz # 解压到 /opt 目录 sudo tar -xzf apache-tomcat-9.0.68.tar.gz -C /opt # 创建软链接方便使用 sudo ln -s /opt/apache-tomcat-9.0.68 /opt/tomcat

2. 配置环境变量与用户： 为了安全，我们不建议使用root用户运行Tomcat。

   # 创建一个专门运行Tomcat的系统用户 sudo useradd -r -m -U -d /opt/tomcat -s /bin/false tomcat # 将Tomcat目录的所有权赋予该用户 sudo chown -R tomcat: /opt/tomcat # 设置执行权限 sudo chmod +x /opt/tomcat/bin/*.sh

3. 创建Systemd服务（关键步骤）： 使用Systemd管理Tomcat服务，可以实现开机自启、日志集中管理，更重要的是，可以方便地查看服务状态和错误日志，这对后续排查问题至关重要。

   sudo vim /etc/systemd/system/tomcat.service

   将以下内容粘贴进去，注意JAVA_HOME的路径可能需要根据你的java -version输出进行调整。可以使用update-alternatives --config java查看JAVA安装路径。

   [Unit] Description=Apache Tomcat 9 Servlet Container After=network.target [Service] Type=forking User=tomcat Group=tomcat Environment="JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64" Environment="JAVA_OPTS=-Djava.security.egd=file:///dev/urandom -Djava.awt.headless=true" Environment="CATALINA_BASE=/opt/tomcat" Environment="CATALINA_HOME=/opt/tomcat" Environment="CATALINA_PID=/opt/tomcat/temp/tomcat.pid" Environment="CATALINA_OPTS=-Xms512M -Xmx1024M -server -XX:+UseParallelGC" ExecStart=/opt/tomcat/bin/startup.sh ExecStop=/opt/tomcat/bin/shutdown.sh RestartSec=10 Restart=always [Install] WantedBy=multi-user.target

   保存退出后，启动服务：

   sudo systemctl daemon-reload sudo systemctl start tomcat sudo systemctl enable tomcat sudo systemctl status tomcat

   如果状态显示为active (running)，恭喜你，Tomcat已成功启动。打开浏览器访问http://<你的虚拟机IP>:8080，应该能看到Tomcat的欢迎页面。

3.3 部署存在漏洞的Web应用

这里以部署一个包含Shiro漏洞的WAR包应用为例。你可以在GitHub上搜索 “shiro vulnerability sample war” 或使用一些开源靶场提供的WAR包。

1. 获取WAR包：假设我们下载到的文件名为vuln-app.war。
2. 部署到Tomcat：Tomcat的Web应用默认部署在webapps目录下。只需将WAR包复制过去，Tomcat会自动解压部署。

   # 将你的 vuln-app.war 上传到虚拟机，然后复制到webapps目录 sudo cp /path/to/vuln-app.war /opt/tomcat/webapps/

   稍等片刻，Tomcat会自动解压。访问http://<IP>:8080/vuln-app/即可看到应用界面。具体路径取决于你的WAR包内容。

3.4 配置与启动哥斯拉管理端

哥斯拉分为服务端（一个JAR包）和WebShell（各种脚本马）。我们首先启动服务端。

1. 下载哥斯拉：从GitHub官方仓库或可靠来源下载最新版本的Godzilla.jar。

2. 运行哥斯拉：哥斯拉服务端需要图形化界面。

   # 在虚拟机有图形界面的情况下，直接运行 java -jar Godzilla.jar

   如果你的虚拟机是纯命令行，或者你希望在宿主机（比如你的Windows/Mac电脑）上运行哥斯拉客户端去连接虚拟机的靶场，也是完全可以的。只需在宿主机安装Java环境，然后运行Godzilla.jar。这里的关键在于网络要互通：确保你的虚拟机网络设置为桥接或NAT，并且宿主机能ping通虚拟机的IP。

3. 哥斯拉界面初识：启动后，你会看到一个管理界面。首次使用需要设置一个连接密码。记住这个密码，以后启动都需要。

至此，我们的渗透测试实验环境骨架已经搭建完毕。接下来，我们将进入最核心的部分：利用漏洞上传WebShell，并连接哥斯拉。

4. 利用Shiro漏洞上传WebShell并连接哥斯拉

这是将理论转化为实践的关键一步。我们假设目标应用vuln-app存在Shiro默认密钥（kPH+bIxk5D2deZiIxcaaaA==）的反序列化漏洞。

4.1 生成哥斯拉WebShell载荷

在哥斯拉客户端界面中：

1. 点击左上角的“+”号，新建一个“Payload”。
2. 类型选择：根据目标环境选择。我们的Tomcat是Java环境，所以选择JSP。这是第一个关键选择，选错类型会导致WebShell无法执行。
3. 设置连接参数：
   • 密码：这是WebShell连接时的认证密码，在哥斯拉和服务端通信时使用，需要复杂一些。
   • 密钥：选择加密方式，如AES。哥斯拉的通信是加密的，这能帮助绕过一些简单的流量检测。
   • 其他选项：保持默认即可。
4. 点击“生成”，会得到一个.jsp文件（例如godzilla.jsp）。这个文件就是我们要上传到目标服务器的WebShell。

4.2 利用Shiro漏洞上传WebShell

我们需要一个利用工具来触发Shiro反序列化漏洞并执行命令，实现文件上传。常用的有shiro_attack、ShiroExploit等。这里以命令行工具为例，演示思路。

1. 探测漏洞：使用工具检测目标是否存在Shiro漏洞以及默认密钥。

   python3 shiro_exploit.py -u http://192.168.1.100:8080/vuln-app/login -p

   （假设工具检测到可用密钥）

2. 构造上传命令：我们的目标是将godzilla.jsp文件内容写入到目标服务器的某个可访问目录，例如webapps/vuln-app/目录下。

   • 在Linux下，可以用echo命令配合Base64编码来写入复杂内容，避免特殊字符问题。
   • 首先，在本地将godzilla.jsp文件进行Base64编码：

     base64 -w 0 godzilla.jsp > godzilla.b64

   • 然后，构造一个通过漏洞执行的命令，该命令将解码Base64内容并写入文件：

     bash -c {echo,YmFzZTY0X2NvbnRlbnRfb2ZfZ29kemlsbGEuanNwCg==}|{base64,-d}|{tee,/opt/tomcat/webapps/vuln-app/godzilla.jsp}

     注意：上面的YmF...Cg==应替换为你实际生成的Base64字符串。tee命令用于写入文件。

3. 执行漏洞利用：将上述构造的长命令作为Payload，通过Shiro利用工具发送给目标。

   python3 shiro_exploit.py -u http://192.168.1.100:8080/vuln-app/login -k "kPH+bIxk5D2deZiIxcaaaA==" -c "那个很长的bash命令"

   如果成功，工具会返回命令执行的结果。你可以通过访问http://192.168.1.100:8080/vuln-app/godzilla.jsp来验证文件是否成功写入（正常情况下，访问加密的WebShell页面会是空白或返回错误，这是对的）。

4.3 在哥斯拉中添加并连接WebShell

1. 回到哥斯拉客户端，在主界面点击“添加”。
2. 填写连接信息：
   • 地址：目标URL，即http://192.168.1.100:8080/vuln-app/godzilla.jsp
   • 密码：与生成Payload时设置的密码一致。
   • 加密器：选择生成Payload时选择的加密方式（如AES）。
   • 请求头、代理等：根据实际情况填写，内网环境通常不需要。
3. 点击“添加”。如果一切配置正确，左下角的“连接”按钮会变为可用状态。点击“连接”，如果成功，左侧会出现一个树形目录，显示目标服务器的文件系统，这标志着你已经成功通过哥斯拉控制了目标服务器。

5. 常见错误、问题排查与深度解决方案

在实际操作中，从环境搭建到成功连接，几乎不可能一帆风顺。下面我汇总了新手最常遇到的几个“拦路虎”，并给出详细的排查思路和解决方案。

5.1 错误：Tomcat启动失败或8080端口无法访问

• 现象：systemctl status tomcat显示failed，或者浏览器访问IP:8080超时。
• 排查步骤：
  1. 检查端口占用：sudo netstat -tlnp | grep :8080。如果被其他程序（如旧Tomcat实例、其他服务）占用，会启动失败。可以杀死占用进程或修改Tomcat的server.xml中的<Connector port="8080" ...>为其他端口，如8088。
  2. 查看详细日志：这是最重要的手段。运行sudo journalctl -u tomcat -f或查看Tomcat的日志文件/opt/tomcat/logs/catalina.out。错误信息通常会直接打印在这里。
  3. 常见日志错误与解决：
     • java.net.BindException: Address already in use：端口被占用，见步骤1。
     • java.lang.UnsupportedClassVersionError：JDK版本不兼容。Tomcat 9需要JDK 8或以上。确认JAVA_HOME环境变量指向了正确的JDK 11安装路径。可以通过echo $JAVA_HOME和java -version交叉验证。
     • Permission denied：目录权限问题。确保/opt/tomcat及其子目录的所有者是tomcat用户，并且tomcat用户有执行bin/*.sh的权限。回顾我们之前chown和chmod的步骤。

5.2 错误：哥斯拉连接失败，提示“连接超时”或“无法连接到目标”

• 现象：在哥斯拉中添加WebShell后，点击连接，长时间无响应或直接报连接错误。
• 排查步骤：
  1. 网络连通性：这是首要检查项。在运行哥斯拉的机器上（宿主机），ping一下目标虚拟机IP。如果不通，检查虚拟机网络设置（桥接/NAT）、防火墙（虚拟机内部和宿主机防火墙）。
  2. WebShell可访问性：用浏览器直接访问你填入哥斯拉的那个JSP文件地址（如http://IP:8080/vuln-app/godzilla.jsp）。预期行为应该是返回一个空白页、一些乱码、或者一个简单的错误信息（如HTTP 500）。如果返回404，说明文件没上传成功；如果返回403，可能是目录权限问题。如果正常显示了JSP源码，那说明服务器没有执行JSP，可能是文件后缀不对或Tomcat的JSP解析器有问题。
  3. 密码与加密器：99%的连接失败源于此。请像对待保险箱密码一样，确保：
     • 哥斯拉客户端添加连接时填写的“密码”，与生成这个JSP Payload时设置的密码完全一致（区分大小写，注意特殊字符）。
     • 哥斯拉客户端选择的“加密器”（如AES），与生成Payload时选择的加密器完全一致。
     • 最简单直接的验证方法：重新生成一个Payload，并使用最简单的密码（如pass）和默认加密器（AES），然后重新上传并尝试连接。如果这样能成功，说明之前是配置错误。
  4. 防火墙与SELinux：在Linux靶机上，检查防火墙是否放行了8080端口：sudo ufw status。如果是active，需要放行：sudo ufw allow 8080/tcp。对于CentOS/RHEL系列，还需要考虑SELinux：可以临时禁用sudo setenforce 0来测试是否是SELinux导致的问题。

5.3 错误：哥斯拉连接成功但Shell不稳定，执行命令无回显或频繁断开（MSF联动场景）

这正是网络搜索中提到的问题。这通常发生在通过哥斯拉的“虚拟终端”执行命令，或者与MSF联动建立反向Shell时。

• 现象：在哥斯拉的“命令执行”或“虚拟终端”中，执行命令后长时间无输出，或者输出不完整，会话容易断开。
• 原因深度解析：
  1. 流处理问题：Java执行系统命令时，标准输出（stdout）和标准错误（stderr）是两个独立的流。如果命令产生大量输出或错误信息，而读取流的方式不当（如缓冲区未及时清空），就会导致进程挂起，表现为“卡住”无回显。
  2. 会话与进程生命周期：通过WebShell执行的命令，其进程生命周期可能与HTTP请求绑定。如果命令执行时间过长（如ping -t），HTTP请求可能会超时，导致连接断开。
  3. MSF联动特有问题：当使用哥斯拉的“MSF联动”功能生成Payload，并用MSF监听时，Shell不稳定可能源于：
     • Payload类型不匹配：MSF的windows/meterpreter/reverse_tcp和java/meterpreter/reverse_tcp行为不同。对于Java环境（如Tomcat），应优先尝试java相关的Payload。
     • 通信协议与编码：MSF的Stage传输可能被中间件或防火墙干扰。
     • 心跳与超时设置：默认的会话超时时间可能太短。
• 解决方案与实操技巧：
  1. 优化命令执行：
     • 重定向错误输出：在执行命令时，总是将标准错误合并到标准输出：ls -la 2>&1。
     • 使用编码命令：对于复杂或有多行输出的命令，可以先用Base64编码，在目标端解码执行。哥斯拉的“命令执行”模块有时比“虚拟终端”更稳定。
     • 避免交互式命令：不要执行需要终端交互的命令（如vi,top）。如果需要查看进程，用ps aux代替。
  2. MSF联动稳定化配置：
     • 生成更稳定的Payload：在MSF中，使用generate命令生成Payload时，可以添加-e x86/shikata_ga_nai编码器并设置迭代次数，但注意免杀性。对于稳定性，更应关注Payload类型本身。
     • 调整监听器参数：在MSF的exploit/multi/handler模块中，设置更长的超时和心跳间隔：

       set SessionCommunicationTimeout 600 set SessionExpirationTimeout 600 set SessionRetryTotal 10 set SessionRetryWait 10

     • 尝试备用Payload：如果java/meterpreter/reverse_tcp不稳定，可以尝试java/shell/reverse_tcp（功能较少但更稳定），或者尝试windows类型的Payload（如果目标Tomcat运行在Windows上）。
  3. 终极方案：使用哥斯拉的“反弹Shell”功能：哥斯拉内置了多种反弹Shell的方式，其通信机制可能比原始的MSF Payload更适应WebShell环境。在哥斯拉连接成功后，尝试使用其“反弹Shell”功能到你的MSF或Netcat监听端口，稳定性往往更好。

5.4 错误：文件上传失败或上传后无法访问

• 现象：通过哥斯拉的文件管理功能上传文件失败，或者上传后返回404。
• 排查：
  1. 磁盘空间与权限：检查目标目录是否有写权限（ls -ld /path/to/dir）。Tomcat进程用户（tomcat）需要对目标目录有写权限。同时检查磁盘是否已满（df -h）。
  2. 杀毒软件或安全防护：实验环境中通常没有，但真实环境可能遇到。哥斯拉的上传功能会尝试对文件进行编码或分片绕过，如果失败，可以尝试手动将文件Base64编码后，通过命令执行echo 'base64_str' | base64 -d > file.jar的方式写入。
  3. 路径问题：在哥斯拉中操作文件，使用的是目标服务器的绝对路径。确保你操作的路径是真实存在的。

5.5 内存马注入相关问题

内存马（如Filter型、Servlet型、Controller型内存马）是哥斯拉的高级功能，它可以将WebShell注入到Java应用的内存中，不落盘，重启后失效但难以检测。

• 注入失败常见原因：
  1. Java版本过高：高版本JDK（如8u191+）对反序列化利用链增加了限制，可能导致某些内存马注入方式失效。确保实验环境使用合适的JDK版本（如JDK 8u181）。
  2. 中间件类型选择错误：在注入时，哥斯拉需要你选择正确的中间件类型（Tomcat, JBoss, WebLogic等）。选错会导致注入的Filter或Servlet无法正确注册。
  3. 权限不足：内存马注入需要能够操作目标应用的ClassLoader和ServletContext，这需要WebShell拥有足够的权限。如果当前WebShell运行在受限的沙箱或低权限环境中，注入会失败。
• 排查建议：注入前，先用哥斯拉的“基本信息”功能查看服务器环境，确认中间件版本和Java版本。从小功能开始测试，比如先尝试注入一个简单的Filter内存马。如果失败，查看Tomcat的catalina.out日志，通常会有相关的异常堆栈信息，这是最直接的线索。

6. 环境加固与后续学习建议

成功搭建并玩转这个环境后，你已经有了一块宝贵的“自留地”。为了让它更好地服务于你的长期学习，我建议做以下几点加固和拓展：

6.1 环境快照与还原

在虚拟机管理软件（如VirtualBox）中，为当前这个配置好所有环境的虚拟机创建一个“快照”（Snapshot），并命名为“纯净渗透测试环境”。以后每次做破坏性实验或环境搞乱后，都可以一键还原到这个状态，节省大量重复搭建的时间。

6.2 构建内网靶场场景

单一的靶机过于简单。你可以：

1. 克隆当前虚拟机，创建第二台、第三台。
2. 修改它们的IP地址，使其处于同一网段（如192.168.1.100/101/102）。
3. 在其中一台机器上部署一个简单的数据库（如MySQL），并在Web应用中配置连接它。
4. 在哥斯拉中，利用已控制的Web服务器作为跳板，尝试通过“内网穿透”或“端口转发”功能，去访问和攻击内网中的其他机器（数据库服务器）。这能模拟真实的内网横向移动场景。

6.3 安全防护与对抗模拟

在掌握了攻击手法后，可以尝试在环境中引入安全防护措施，学习绕过技巧：

1. 在Tomcat前部署一个WAF（如ModSecurity），尝试上传WebShell，观察被拦截的情况，学习如何通过编码、分片、混淆绕过WAF规则。
2. 在服务器上安装HIDS（主机入侵检测系统）的代理，观察你的操作会触发哪些告警日志。这能让你从防守方视角理解攻击行为特征。

6.4 工具链拓展

哥斯拉只是工具链的一环。尝试将其与其他工具结合：

• 与Cobalt Strike联动：学习如何通过哥斯拉上传Beacon Stager，建立Cobalt Strike会话。
• 与漏洞扫描器结合：使用AWVS、Xray等工具扫描你的靶场应用，验证漏洞，然后用手动（哥斯拉）的方式去利用，体会自动化扫描与手动利用的差异。

搭建渗透测试环境不是目的，而是手段。这个环境的价值在于，它为你提供了一个安全、可反复试错的平台。所有在教程中看到的、在别人文章里读到的技术，你都可以在这里亲手验证、修改、调试，直到完全理解其原理和细节。遇到错误和问题不再是阻碍，而是深入学习的机会。记住，在这个环境里，你既是攻击者，也是防御者，更是整个网络的设计者。这种全方位的视角，是成长为一名资深安全从业者的必经之路。