一、负载均衡反向代理下的webshell上传

1、nginx 负载均衡

负载均衡策略	策略
轮询	请求顺序逐一分配
权重	按照权重大小分配
ip_hash	根据客户端IP分配
URL_hash	根据URL分配
least_conn	根据连接数分配

下来我简单介绍几种负载均衡的策略

1. 轮询
   轮询：nginx默认就是轮询其权重都默认为1，服务器处理请求的顺序：ABABABABAB…

upstream mysvr { server 192.168.137.131; server 192.168.137.136;       
}

注意：

• 在轮询中，如果服务器down掉了，会自动剔除该服务器。
• 缺省配置就是轮询策略。
• 此策略适合服务器配置相当，无状态且短平快的服务使用。

2. weight
   跟据配置的权重的大小而分发给不同服务器不同数量的请求

upstream mysvr { server 192.168.137.131 weihet = 100; server 192.168.137.136 weihet = 200;
}

3. ip_hash
   ip_hash:nginx会让相同的客户端ip请求相同的服务器

upstream mysvr { server 192.168.137.131; server 192.168.137.136;ip_hash;
}

2、搭建环境

github下载

cd /ant/loadbalance/loadbalance-jsp
docker-compose up  -d

这里我搭建环境的时候出了点问题，不知道为什么dockers-compose up -d 执行不了， 然后我我把docker-compose 删了重新安装发现还是不行，然后我恢复快照重新搭建环境，最后解决办法是卸载docker 重新安装docker和docker-compose。

cd /usr/local/bin/
#下载docker-compose
wget https://github.com/docker/compose/releases/download/1.14.0-rc2/docker-compose-Linux-x86_64
#重命名
rename docker-compose-Linux-x86_64 docker-compose docker-compose-Linux-x86_64
#给执行权限
chmod +x /usr/local/bin/docker-compose

上述下载方式有问题，由于compose更新了，Docker Compose V2 是 Docker Compose 的主要版本碰撞版本。它在Golang中完全重写了（V1是用Python编写的）。撰写 V2 的安装说明与 V1 不同。V2 不再是独立的二进制文件，必须调整安装脚本。

#在 Linux上 安装 Docker
curl -sSL https://get.daocloud.io/docker | sh
#安装 Docker Compose
curl -L https://get.daocloud.io/docker/compose/releases/download/v2.16.0/docker-compose-`uname -s`-`uname -m` > /usr/local/bin/docker-compose
#给予执行权限
chmod +x /usr/local/bin/docker-compose

环境搭建完成，现在我们的整体框架如下图
nginx 反向代理到两台内网服务器上，Node1 和 Node2 均是 tomcat 8 ，在内网中开放了 8080 端口，他们两个之间可以互相通信，我们在外部是没法直接访问到的。

然后我们进入docker-nginx 查看一下nginx 配置。
做了轮询的负载均衡策略。

假定在真实的业务系统上，存在一个 RCE 漏洞，可以让我们获取 WebShell。
我们上传了我们的一句话木马。
尝试用蚁剑登录

成功连接目标，因为两台节点都在相同的位置存在 ant.jsp，所以连接的时候也没出现什么异常。

3、负载均衡下的 WebShell连接的难点总结

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

假如说node1上有ant.jsp，node2上没有，这就会出现一会连接失败，一会连接正常的问题
我们进入node2删除ant.jsp

一旦有一台机器上没有，那么在请求轮到这台机器上的时候，就会出现 404 错误，影响使用。还好负载均衡的策略是轮询，还存在一定的规律，如果是其他策略，更难以把控。

难点二、无法预测下次的请求交给哪台机器去执行。

由于难点一测试时删除了 node2的ant.jsp，我们重新copy一下
docker cp ant.jsp 46c0af8b0ca3:/usr/local/tomcat/webapps/ROOT/ant.jsp
由于nginx服务器上配置了 轮询负载均衡，所以我们无法下次的请求交给哪台机器去执行，有点飘忽不定。

难点三、下载文件时，可能会出现飘逸，导致下载失败。

由于 antSword 上传文件时，采用的分片上传方式，把一个文件分成了多次HTTP请求发送给了目标，导致两台节点上，各一半，而且这一半到底是怎么组合的，取决于 LBS 算法

难点四、目标机器不能出外网

目标机器不能出外网，要想深入，只能使用 reGeorg/HTTPAbs 等 HTTP Tunnel，但隧道随时可能断开连接，tunnel 脚本全部都会失效。
1、reGeorg内网渗透工具
eGeorg可以称为内网代理。实际上，它可以起到代理的作用

模拟上图的场景
主机A、主机B、攻击者
假如主机A上运行了Web服务，且IP或者端口映射到公网，可以被外部人员访问，主机B是在外网访问不到的。攻击者通过漏洞在主机A上传了Webshell，但同时又出于某些限制并未能得到主机A的主机权限也无法反弹shell，那么他这个时候，也是无法通过常规方法反弹shell或者直接登录主机A从而访问到主机B的。

ReGeorg就在这个时候起了作用，攻击者已经有了主机A的webshell权限（即可以在web服务器中上传文件），而主机A可以和主机B通信。那么在主机A上安装reGeorg工具，使得攻击者发出的请求以及目标机器的响应经过A的http转发，达到攻击者可以和主机B进行通信的效果。
2、ab（http）与abs（https）压测工具
ab全称为：apache bench
ab是Apache超文本传输协议(HTTP)的性能测试工具。其设计意图是描绘当前所安装的Apache的执行性能，主要是显示你安装的Apache每秒可以处理多少个请求。

总结

看似四个难点，归根结底是由于nginx,上配置了负载均衡的问题，我们无法预测，管控下一次请求在那台服务器上，所以导致了这一系列问题，下面我们介绍一些解决办法。

4、解决方法

方法一、关机/停服

关掉其中一台机器，这种行为最不推荐，但如果你不在乎关掉服务器的损失当我没说。这种方法影响业务，不建议尝试，测试除外。

方法二、判断是否执行

既然无法预测下一次是哪台机器去执行，我们可以在Shell 执行 Payload 之前，判断要不要执行。
创建shell 脚本

蚁剑不知道出现莫名的问题

方法三、在Web层做 HTTP 流量转发

我们用 AntSword 没法直接访问 LBSNode1 内网IP(172.23.0.2)的 18080 端口，但是有人能访问呀，除了 nginx 能访问之外，LBSNode2 这台机器也是可以访问 Node1 这台机器的 18080 端口的

我们的目的是：所有的数据包都能发给「LBSNode 1」这台机器。
如上图所示，我们可以在node2上做数据转发，整合数据后转发给node1
首先：我们通过nginx,直接访问node1，
其次：我们把请求发给Node2,Node2 上面的 /antproxy.jsp 把请求重组之后，传给了 Node1 的 /ant.jsp，成功执行。

1.创建 antproxy.jsp 脚本

修改数据转发的目标地址

注意：
不要使用上传功能，上传功能会分片上传，导致分散在不同 Node 上。
要保证每一台 Node 上都有相同路径的 antproxy.jsp，保证每一台都上传了脚本

2.修改 Shell 配置, 将 URL 部分填写为 antproxy.jsp 的地址

第一次改成172.18.0.2:18080,出现蚁剑连接不上的问题，然后改成172.18.0.2:8080，就可以连接成功。

3. 测试执行命令, 查看 IP

这个方法有个缺点，需要「目标 Node1」和「其它 Node2」 之间内网互通，如果不互通，就无法解决问题。

二、apache漏洞

1、Apache HTTPD 换行解析漏洞(环境没搭建成功)

Apache HTTPD 换行解析漏洞（CVE-2017-15715）
影响版本：2.4.0~2.4.29
影响说明：Apache HTTPD是一款HTTP服务器，它可以通过mod_php来运行PHP网页。在解析PHP时，1.php\x0a将被按照PHP后缀进行解析，导致绕过一些服务器的安全策略。

在1.php后面插入一个\x0A,php会解析成1.php%0a,从而成功解析