目录

一、环境准备

1.1ubentu虚拟机一台，docker环境，蚁剑

1.2环境压缩包（文件已上传资源）：

二、开始复原

2.1上传ubentu：

2.2解压缩

2.3版本20没有docker-compose手动下载，包已上传资源

​编辑 2.4问题：下载无法连接

2.5解决方法：ubentu上做代理，或xftp自己上传，我这里使用ubentu做代理 

2.6再次下载：

2.7转移目录

2.8给个权限

2.9成功页面：

三、环境搭建完毕，开始跑负载均衡

3.1此环境原理：前端反向代理为nginx，后端两台机子为Tomcat

3.2远端拉取环境：

 3.3开始制作：

 3.4成功结果：只能访问nginx后端18080对外没有映射

3.5蚁剑进行连接

四、情况映射出难点

4.1难点一：

4.2难点二：

4.3难点三：

4.4难点四：

​编辑 4.5最终实现结果：

五、.在web层做一次流量转发

5.1先看两个后端是否可以互通

5.2我们的原理也是如下图：

5.3操作：

 

---

 

我们以默认的「轮询」方式来做演示。演示的环境包已经上传资源叫AntSword-Labs

dockerfile一次下载一个镜像，docker-compose一次下载多个镜像

 更换完毕，访问谷歌ok

接下来假设我们在真实的业务系统上，存在一个远程连接漏洞，可以让我们获取 WebShell

看一下是否存在，结果自然存在，而且两台机子都已上传

在刷新的情况下，其实我们访问后端Tomcat已经飘逸了好几次了

当我刷新在另一台机子又可以看到：

我们需要在每一台节点的相同位置都上传相同内容的 WebShell

解决方法：多次保存可以解决此问题

我们在执行命令时，无法知道下次的请求交给哪台机器去执行。

虚拟终端明显可以看到,我们的ip通过负载均衡一直在飘逸

解决：多次执行

当我们上传文件时候，一些落第一台机子，一台落第二台

我上传的几MB文件一个在第一个机子一个在第二个机子

我删除也全是分片

由于目标机器不能出外网，想进一步深入，只能使用 reGeorg/HTTPAbs 等 HTTP Tunnel，可在这个场景下，这些 tunnel 脚本全部都失灵了。

好了，任何方法都没用了，那该怎么办呢？

解决方法：

1.关掉对方一台服务器（作死玩法）

关掉一台，无法飘逸，但是后台监控软件直接报警

2.执行前判断要不要执行

以执行bash我们来举例，在执行前判断一下ip,两个docker镜像中都安装nat-tools，以方便可以使用ifconfig

接下来写一个脚本，已到达执行前判断需不需要执行

以这个为基础我们来开始写

勉强能用，可是，上传文件、HTTP 隧道 这些要怎么解决？  又到我们需要思考的地方了

我们先上传一个antproxy.jsp的转发包，资源中我已上传 ，改一下转发地址，然后替换先前蚁剑上传的文件

怎么上传？

蚁剑 

会分片，别传，那怎么办，还记得我们第二个方法的新建文件吗？这里就有作用了，去新建吧，多次保存，两个机子上就都有了

接下来换掉连接数据：

我们的刷新不再跳转，可见流量是被转发走的

 

至此，我们对于负载均衡下漏洞上传文件，讨论完毕