目录
一、环境准备
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的转发包，资源中我已上传 ，改一下转发地址，然后替换先前蚁剑上传的文件
怎么上传？
蚁剑
会分片，别传，那怎么办，还记得我们第二个方法的新建文件吗？这里就有作用了，去新建吧，多次保存，两个机子上就都有了
接下来换掉连接数据：
我们的刷新不再跳转，可见流量是被转发走的
至此，我们对于负载均衡下漏洞上传文件，讨论完毕