nginx反向代理
nginx 负载均衡
负载均衡的策略
1、轮询:nginx默认就是轮询其权重都默认为1,服务器处理请求的顺序:ABABABABAB…
upstream mysvr {
server 192.168.137.131;
server 192.168.137.136;
}
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;
}
搭建环境
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 不再是独立的二进制文件,必须调整安装脚本。
然后我们采用下列方式重新安装docker
#在 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
进入docker-nginx 查看一下nginx 配置。
做了轮询的负载均衡策略。
假定在真实的业务系统上,存在一个 RCE 漏洞,可以让我们获取 WebShell。
上传我们的一句话木马。
尝试用蚁剑登录
负载均衡上传webshell重难点
1、需要在每一台节点的相同位置都上传相同内容的 WebShell
假如说node1上有ant.jsp,node2上没有,这就会出现一会连接失败,一会连接正常的问题我们进入node2删除ant.jsp。
一旦有一台机器上没有,那么在请求轮到这台机器上的时候,就会出现 404 错误,影响使用。还好负载均衡的策略是轮询,还存在一定的规律,如果是其他策略,更难以把控。
2、无法预测下次的请求交给哪台机器去执行。
由于难点一测试时删除了 node2的ant.jsp,我们重新copy一下
docker cp ant.jsp 46c0af8b0ca3:/usr/local/tomcat/webapps/ROOT/ant.jsp
由于nginx服务器上配置了 轮询负载均衡,所以我们无法下次的请求交给哪台机器去执行,有点飘忽不定。
3、下载文件时,可能会出现飘逸,导致下载失败
由于 antSword 上传文件时,采用的分片上传方式,把一个文件分成了多次HTTP请求发送给了目标,导致两台节点上,各一半,而且这一半到底是怎么组合的,取决于 LBS 算法
4、目标机器不能出外网
目标机器不能出外网,要想深入,只能使用 reGeorg/HTTPAbs 等 HTTP Tunnel,但隧道随时可能断开连接,tunnel 脚本全部都会失效。
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,从而成功解析。
2、Apache HTTPD 多后缀解析漏洞
Apache HTTPD 支持一个文件拥有多个后缀,并为不同后缀执行不同的指令。比如,如下配置文件:
AddType text/html .html
AddLanguage zh-CN .cn
其给.html后缀增加了media-type,值为text/html;给.cn后缀增加了语言,值为zh-CN。此时,如果用户请求文件index.cn.html,他将返回一个中文的html页面。
意思就是说只要文件后缀中包含了 html、php的文件,他就可以被解析成相应的文件.
以上就是Apache多后缀的特性。如果运维人员给.php后缀增加了处理器:
AddHandler application/x-httpd-php .php
那么,在有多个后缀的情况下,只要一个文件含有.php后缀的文件即将被识别成PHP文件.
漏洞复现
环境运行后,访问http://192.1`68.137.131/uploadfiles/apache.php.jpeg即可发现,phpinfo被执行了,该文件被解析为php文件。
我们就可以利用Apache解析漏洞进行getshell。
3、Apache Solr 远程命令执行漏洞
Apache Solr 远程命令执行漏洞(CVE-2019-0193)
影响版本:Apache Solr < 8.2.0 的版本
影响说明:Apache Solr 是一个开源的搜索服务器。Solr 使用 Java 语言开发,主要基于 HTTP 和 Apache Lucene 实现。此次漏洞出现在Apache Solr的DataImportHandler,该模块是一个可选但常用的模块,用于从数据库和其他源中提取数据。它具有一个功能,其中所有的DIH配置都可以通过外部请求的dataConfig参数来设置。由于DIH配置可以包含脚本,因此攻击者可以通过构造危险的请求,从而造成远程命令执行。
在Apache Solr < 8.2.0 的版本中, DataImportHandler的dataConfig参数为用户可控,攻击者可通过构造恶意的dataConfig脚本交由转换器(Transformers)进行解析,而Solr在解析的过程中并未对用户输入的脚本进行检查,导致攻击者可在Solr服务器上执行任意代码。
solr 工作机制
1、solr是在lucene工具包的基础之上进行了封装,并且以web服务的形式对外提供索引功能
2、业务系统需要使用到索引的功能(建索引,查索引)时,只要发出http请求,并将返回数据进行解析即可
Solr DataImportHandler
Solr DataImportHandler可以批量把数据导入到索引库中。
DataImportHandler有如下功能:
1、读取关系数据库中数据或文本数据
2、根据配置从xml(http/file方式)读取与建立索引数据
3、根据配置聚合来自多个列和表的数据来构建Solr文档
4、使用文档更新Solr(更新索引、文档数据库等)
5、根据配置进行完全导入的功能(full-import,完全导入每次运行时会创建整个索引)
6、检测插入/更新字段并执行增量导入(delta-import,对增加或者被修改的字段进行导入)
7、调度full-import与delta-import
8、可以插入任何类型的数据源(ftp,scp等)和其他用户可选格式(JSON,csv等)
4、Apache HTTP 服务器的路径穿越和文件泄露漏洞
Apache HTTP 服务器 2.4.49 中的路径穿越和文件泄露漏洞 (CVE-2021-41773)
影响版本:2.4.49
影响说明:在 Apache HTTP Server 2.4.49 中对路径规范化所做的更改中发现一个缺陷。攻击者可以使用路径遍历攻击将 URL 映射到预期文档根目录之外的文件。
如果这些目录之外的文件不受通常的默认配置“要求全部拒绝”的保护,则这些请求可以成功。如果还为这些别名路径启用了 CGI 脚本,则可能允许远程执行代码。
漏洞复现
curl -v --path-as-is http://your-ip:8080/icons/%2e%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd
5、Apache SSI 远程命令执行漏洞
影响说明:在测试任意文件上传漏洞的时候,目标服务端可能不允许上传php后缀的文件。如果目标服务器开启了SSI与CGI支持,我们可以上传一个shtml文件,并利用<!–#exec cmd=“id” -->语法执行任意命令。
漏洞复现
环境启动后,访问http://192.168.137.140:8080/upload.php,即可看到一个上传表单。然后上传一个1.shtml文件。
<!--#exec cmd="id" -->
然后用burpsuite 测试一下:
然后我们修改post 改成我们的1.shtml 运行后成功执行了<!–#exec cmd=“id” -->命令
SSI(服务器端包含)是放置在 HTML 页面,并在页面 被服务。它们允许您将动态生成的内容添加到 现有 HTML 页面,而不必提供整个页面 通过CGI程序或其他动态技术。
例如,您可以将指令放入现有 HTML 中 页面,例如:
<!--#echo var="DATE_LOCAL" -->
并且,当页面投放时,将评估此片段并将其替换为其值:
Tuesday, 15-Jan-2013 19:28:54 EST
各个服务器对SSI命令的支持各有不同,但 #include 和 #exec 是通用的。使用 SSI 的页面文件通常都使用扩展名.shtml,而不是.html 或 .htm,这样以便服务器能够辨认出哪些页面包含SSI指令,这些页面需要先经过服务器处理,翻译执行其中的SSI指令,然后才发送给客户端浏览器。 (当然有些服务器还是支持.html,.htm文件中有SSI指令的)。