自学建设网站杭州 高端网站建设

当前位置： 首页 > news >正文

自学建设网站,杭州 高端网站建设,网站做拓扑图编辑,北京律师网站建设1.应用场景 负载均衡作为现今解决web应用承载大流量访问问题的一种方案#xff0c;在真实环境中得到广泛的部署。实现负载均衡的方式有很多种#xff0c;比如 DNS 方式、HTTP 重定向方式、IP 负载均衡方式、反向代理方式等等。 比如基于dns的负载均衡#xff1a; 当然还有…1.应用场景 负载均衡作为现今解决web应用承载大流量访问问题的一种方案在真实环境中得到广泛的部署。实现负载均衡的方式有很多种比如 DNS 方式、HTTP 重定向方式、IP 负载均衡方式、反向代理方式等等。 比如基于dns的负载均衡 当然还有nginx的经典的基于反向代理实现的负载均衡。用户在通过单一IP地址访问服务器时永远不会知道自己的处理服务器是那一台。对于这部分内容我在前面的《NGINX反向代理实现负载均衡》中有详细谈过它的分类以及配置方法。我们再来回顾以下nginx支持的负载均衡的方式 轮询 默认方式 weight 权重方式 ip_hash 依据ip分配方式 least_conn 最少连接方式 fair第三方 响应时间方式 url_hash第三方 依据URL分配方式 可以看到支持的负载均衡模式很多。无论时什么样的负载均衡模式都可以以这样的规则进行划分即是否可以确定地访问某一台固定的服务器。 为什么这样说呢因为在渗透测试的过程中有一个比较固定的思维就是所有的攻击都围绕着拿到webshell获取服务器权限而进行。不管是漏洞利用也好暴力破解也罢。都是为了拿到webshell提权渗透内网。整体的流程就是这样但是一旦遇到负载均衡隐藏掉后端真实服务器IP后就会出现一大堆的问题无法解决。本文就是要理清楚这样一种环境下上传webshell的思路。 2.面临的困难 总体来说面临着四个难点webshell上传命令执行工具投放内网渗透做隧道。下面我们用蚁剑作者提供的docker镜像来演示遇到的问题。 https://github.com/AntSwordProject/AntSword-Labs 下载后上传至服务器进行解压到指定目录下启动环境 [rootblackstone loadbalance-jsp]# pwd /home/batman/AntSword-Labs-master/loadbalance/loadbalance-jsp [rootblackstone loadbalance-jsp]# docker-compose up -d 我们查看它的compose文件可以看到 nginx的80端口被映射到主机的18080端口之上访问http://192.168.2.169:18080 就可以访问到我们的web服务了。Node1 和 Node2 均是 tomcat 8 在内网中开放了 8080 端口我们在外部是没法直接访问到的。 此时打开蚂蚁剑我们尝试连接先前在node12上均插入了的webshell 2.1 shell文件上传问题 尝试多次刷新十分流畅 我们进入一个节点服务器尝试让webshell失效 [rootblackstone loadbalance-jsp]# docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES c549f819e15e nginx:1.17 “nginx -g daemon of…” 36 minutes ago Up 36 minutes 0.0.0.0:18080-80/tcp loadbalance-jsp_nginx_1 bab0805650c1 loadbalance-jsp_lbsnode2 “catalina.sh run” 36 minutes ago Up 36 minutes 8080/tcp loadbalance-jsp_lbsnode2_1 59bf661c6b83 loadbalance-jsp_lbsnode1 “catalina.sh run” 36 minutes ago Up 36 minutes 8080/tcp loadbalance-jsp_lbsnode1_1 [rootblackstone loadbalance-jsp]# docker exec -it bab0805650c1 /bin/bash rootbab0805650c1:/usr/local/tomcat# find / -name ant.jsp find: ‘/proc/1/map_files’: Operation not permitted find: ‘/proc/37/map_files’: Operation not permitted find: ‘/proc/41/map_files’: Operation not permitted /usr/local/tomcat/webapps/ROOT/ant.jsp rootbab0805650c1:/usr/local/tomcat# cd /usr/local/tomcat/webapps/ROOT/ rootbab0805650c1:/usr/local/tomcat/webapps/ROOT# mv ant.jsp ant 2.2 命令执行时的漂移 对你没听错在这样的环境下我们发出去的webshell执行命令时会发生严重的漂移现象。你永远不知道命令在哪台服务器上执行。 假设我们解决了第一个难点webshell均匀的出现在了后端节点服务器上。 我们将先前失效的webshell复活 rootbab0805650c1:/usr/local/tomcat/webapps/ROOT# mv ant ant.jsp 到命令执行界面尝试执行命令 执行查看IP地址的命令 2.3 大工具投放失败 当我们解决了上面两个难点想要进一步渗透时此时投放一些工具是很必要的工作。但是碍于 antSword 上传文件时采用的分片上传方式。把一个文件分成了多次HTTP请求发送给了目标所以尴尬的事情来了两台节点上各一半而且这一半到底是怎么组合的取决于 LBS 算法。也就是说我们的工具一旦大于这个最小分片大小。就会被拆分成碎片传递给节点服务器。 2.4 内网穿透工具失效 由于目标机器不能出外网想进一步深入只能使用 reGeorg/HTTPAbs 等 HTTP Tunnel可在这个场景下这些 tunnel 脚本全部都失灵了。 3.一些解决方案 要解决第一个难点其实比较简单就一个词重复疯狂上传多次webshell肯定可以上传到所有的节点服务器上去。接下来我们得想办法解决剩下的难点。 3.1 关机 这个方案虽然看着是个方法但是实际环境中先不说权限够不够。就是够这样的操作也是十分危险的。虽然关闭节点服务器后节点服务器会被踢出nginx代理池内部。最终可以做到每次请求都落到同一台服务器上。但是暴露风险大还要承担相应的法律责任。故不建议使用这种方法。 3.2 基于IP判断执行主机 要是在每一次执行命令前可以判断以下主机的IP地址那不就可以解决命令漂移问题了嘛。 这里需要用到一个shell #执行命令前进行ip判断注意执行的命令写到then后else前即可。 if [ hostname -i “172.19.0.2” ];then echo “node1 i will execute command.\n\n”; hostname -i;else echo “other.tryagain”; f rootbab0805650c1:# if [ hostname -i “172.19.0.2” ];then echo “node1 i will execute command.\n\n”; hostname -i;else echo “other.tryagain”; fi node1 i will execute command.\n\n 172.19.0.2 rootbab0805650c1:# if [ hostname -i “172.19.0.3” ];then echo “node1 i will execute command.\n\n”; hostname -i;else echo “other.tryagain”; fi other.tryagain 这样一来确实是能够保证执行的命令是在我们想要的机器上了可是这样执行命令不够丝滑。甚至其在蚁剑的中断内运行会出问题。在真机上测试正常。 这样的方案确实很麻烦并且并不能解决我们内网穿透的需求所以不推荐使用。