nginx反向代理

nginx 負載均衡

負載均衡的策略
1、輪詢：nginx默認就是輪詢其權(quán)重都默認為1，服務(wù)器處理請求的順序：ABABABABAB…

upstream mysvr { server 192.168.137.131; server 192.168.137.136;       
}

2、weight：跟據(jù)配置的權(quán)重的大小而分發(fā)給不同服務(wù)器不同數(shù)量的請求

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

3、ip_hash：ip_hash:nginx會讓相同的客戶端ip請求相同的服務(wù)器

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

搭建環(huán)境

github下載

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

這里我搭建環(huán)境的時候出了點問題，不知道為什么dockers-compose up -d 執(zhí)行不了， 然后我我把docker-compose 刪了重新安裝發(fā)現(xiàn)還是不行，然后我恢復(fù)快照重新搭建環(huán)境，最后解決辦法是卸載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
#給執(zhí)行權(quán)限
chmod +x /usr/local/bin/docker-compose

上述下載方式有問題，由于compose更新了，Docker Compose V2 是 Docker Compose 的主要版本碰撞版本。它在Golang中完全重寫了（V1是用Python編寫的）。撰寫 V2 的安裝說明與 V1 不同。V2 不再是獨立的二進制文件，必須調(diào)整安裝腳本。
然后我們采用下列方式重新安裝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
#給予執(zhí)行權(quán)限
chmod +x /usr/local/bin/docker-compose

進入docker-nginx 查看一下nginx 配置。
做了輪詢的負載均衡策略。

假定在真實的業(yè)務(wù)系統(tǒng)上，存在一個 RCE 漏洞，可以讓我們獲取 WebShell。
上傳我們的一句話木馬。
嘗試用蟻劍登錄

負載均衡上傳webshell重難點

1、需要在每一臺節(jié)點的相同位置都上傳相同內(nèi)容的 WebShell

假如說node1上有ant.jsp，node2上沒有，這就會出現(xiàn)一會連接失敗，一會連接正常的問題我們進入node2刪除ant.jsp。

一旦有一臺機器上沒有，那么在請求輪到這臺機器上的時候，就會出現(xiàn) 404 錯誤，影響使用。還好負載均衡的策略是輪詢，還存在一定的規(guī)律，如果是其他策略，更難以把控。

2、無法預(yù)測下次的請求交給哪臺機器去執(zhí)行。

由于難點一測試時刪除了 node2的ant.jsp，我們重新copy一下
docker cp ant.jsp 46c0af8b0ca3:/usr/local/tomcat/webapps/ROOT/ant.jsp
由于nginx服務(wù)器上配置了 輪詢負載均衡，所以我們無法下次的請求交給哪臺機器去執(zhí)行，有點飄忽不定。

3、下載文件時，可能會出現(xiàn)飄逸，導(dǎo)致下載失敗

由于 antSword 上傳文件時，采用的分片上傳方式，把一個文件分成了多次HTTP請求發(fā)送給了目標(biāo)，導(dǎo)致兩臺節(jié)點上，各一半，而且這一半到底是怎么組合的，取決于 LBS 算法

4、目標(biāo)機器不能出外網(wǎng)

目標(biāo)機器不能出外網(wǎng)，要想深入，只能使用 reGeorg/HTTPAbs 等 HTTP Tunnel，但隧道隨時可能斷開連接，tunnel 腳本全部都會失效。

apache漏洞

1、Apache HTTPD 換行解析漏洞

Apache HTTPD 換行解析漏洞（CVE-2017-15715）
影響版本：2.4.0~2.4.29
影響說明：Apache HTTPD是一款HTTP服務(wù)器，它可以通過mod_php來運行PHP網(wǎng)頁。在解析PHP時，1.php\x0a將被按照PHP后綴進行解析，導(dǎo)致繞過一些服務(wù)器的安全策略。

在1.php后面插入一個\x0A,php會解析成1.php%0a,從而成功解析。

2、Apache HTTPD 多后綴解析漏洞

Apache HTTPD 支持一個文件擁有多個后綴，并為不同后綴執(zhí)行不同的指令。比如，如下配置文件：

AddType text/html .html
AddLanguage zh-CN .cn

其給.html后綴增加了media-type，值為text/html；給.cn后綴增加了語言，值為zh-CN。此時，如果用戶請求文件index.cn.html，他將返回一個中文的html頁面。
意思就是說只要文件后綴中包含了 html、php的文件,他就可以被解析成相應(yīng)的文件.
以上就是Apache多后綴的特性。如果運維人員給.php后綴增加了處理器：
AddHandler application/x-httpd-php .php
那么，在有多個后綴的情況下，只要一個文件含有.php后綴的文件即將被識別成PHP文件.
漏洞復(fù)現(xiàn)
環(huán)境運行后，訪問http://192.1`68.137.131/uploadfiles/apache.php.jpeg即可發(fā)現(xiàn)，phpinfo被執(zhí)行了，該文件被解析為php文件。
我們就可以利用Apache解析漏洞進行g(shù)etshell。

3、Apache Solr 遠程命令執(zhí)行漏洞

Apache Solr 遠程命令執(zhí)行漏洞（CVE-2019-0193）
影響版本：Apache Solr < 8.2.0 的版本
影響說明：Apache Solr 是一個開源的搜索服務(wù)器。Solr 使用 Java 語言開發(fā)，主要基于 HTTP 和 Apache Lucene 實現(xiàn)。此次漏洞出現(xiàn)在Apache Solr的DataImportHandler，該模塊是一個可選但常用的模塊，用于從數(shù)據(jù)庫和其他源中提取數(shù)據(jù)。它具有一個功能，其中所有的DIH配置都可以通過外部請求的dataConfig參數(shù)來設(shè)置。由于DIH配置可以包含腳本，因此攻擊者可以通過構(gòu)造危險的請求，從而造成遠程命令執(zhí)行。
在Apache Solr < 8.2.0 的版本中， DataImportHandler的dataConfig參數(shù)為用戶可控，攻擊者可通過構(gòu)造惡意的dataConfig腳本交由轉(zhuǎn)換器（Transformers）進行解析，而Solr在解析的過程中并未對用戶輸入的腳本進行檢查，導(dǎo)致攻擊者可在Solr服務(wù)器上執(zhí)行任意代碼。

solr 工作機制
1、solr是在lucene工具包的基礎(chǔ)之上進行了封裝，并且以web服務(wù)的形式對外提供索引功能
2、業(yè)務(wù)系統(tǒng)需要使用到索引的功能（建索引，查索引）時，只要發(fā)出http請求，并將返回數(shù)據(jù)進行解析即可

Solr DataImportHandler
Solr DataImportHandler可以批量把數(shù)據(jù)導(dǎo)入到索引庫中。

DataImportHandler有如下功能：

1、讀取關(guān)系數(shù)據(jù)庫中數(shù)據(jù)或文本數(shù)據(jù)
2、根據(jù)配置從xml（http/file方式）讀取與建立索引數(shù)據(jù)
3、根據(jù)配置聚合來自多個列和表的數(shù)據(jù)來構(gòu)建Solr文檔
4、使用文檔更新Solr（更新索引、文檔數(shù)據(jù)庫等）
5、根據(jù)配置進行完全導(dǎo)入的功能（full-import，完全導(dǎo)入每次運行時會創(chuàng)建整個索引）
6、檢測插入/更新字段并執(zhí)行增量導(dǎo)入（delta-import，對增加或者被修改的字段進行導(dǎo)入）
7、調(diào)度full-import與delta-import
8、可以插入任何類型的數(shù)據(jù)源（ftp，scp等）和其他用戶可選格式（JSON，csv等）

4、Apache HTTP 服務(wù)器的路徑穿越和文件泄露漏洞

Apache HTTP 服務(wù)器 2.4.49 中的路徑穿越和文件泄露漏洞 （CVE-2021-41773）
影響版本：2.4.49
影響說明：在 Apache HTTP Server 2.4.49 中對路徑規(guī)范化所做的更改中發(fā)現(xiàn)一個缺陷。攻擊者可以使用路徑遍歷攻擊將 URL 映射到預(yù)期文檔根目錄之外的文件。
如果這些目錄之外的文件不受通常的默認配置“要求全部拒絕”的保護，則這些請求可以成功。如果還為這些別名路徑啟用了 CGI 腳本，則可能允許遠程執(zhí)行代碼。

漏洞復(fù)現(xiàn)

curl -v --path-as-is http://your-ip:8080/icons/%2e%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd

5、Apache SSI 遠程命令執(zhí)行漏洞

影響說明：在測試任意文件上傳漏洞的時候，目標(biāo)服務(wù)端可能不允許上傳php后綴的文件。如果目標(biāo)服務(wù)器開啟了SSI與CGI支持，我們可以上傳一個shtml文件，并利用<!–#exec cmd=“id” -->語法執(zhí)行任意命令。

漏洞復(fù)現(xiàn)
環(huán)境啟動后，訪問http://192.168.137.140:8080/upload.php，即可看到一個上傳表單。然后上傳一個1.shtml文件。

<!--#exec cmd="id" -->

然后用burpsuite 測試一下：

然后我們修改post 改成我們的1.shtml 運行后成功執(zhí)行了<!–#exec cmd=“id” -->命令

SSI（服務(wù)器端包含）是放置在 HTML 頁面，并在頁面 被服務(wù)。它們允許您將動態(tài)生成的內(nèi)容添加到 現(xiàn)有 HTML 頁面，而不必提供整個頁面 通過CGI程序或其他動態(tài)技術(shù)。

例如，您可以將指令放入現(xiàn)有 HTML 中 頁面，例如：

<!--#echo var="DATE_LOCAL" -->
并且，當(dāng)頁面投放時，將評估此片段并將其替換為其值：
Tuesday, 15-Jan-2013 19:28:54 EST

各個服務(wù)器對SSI命令的支持各有不同，但 #include 和 #exec 是通用的。使用 SSI 的頁面文件通常都使用擴展名.shtml，而不是.html 或 .htm，這樣以便服務(wù)器能夠辨認出哪些頁面包含SSI指令，這些頁面需要先經(jīng)過服務(wù)器處理，翻譯執(zhí)行其中的SSI指令，然后才發(fā)送給客戶端瀏覽器。 (當(dāng)然有些服務(wù)器還是支持.html,.htm文件中有SSI指令的)。