前言

Apache Druid 作為一個(gè)高性能的實(shí)時(shí)分析數(shù)據(jù)庫(kù)，憑借其出色的數(shù)據(jù)攝取和查詢(xún)能力，在海量數(shù)據(jù)分析領(lǐng)域占據(jù)了重要地位。然而，其自帶的監(jiān)控頁(yè)面 (/druid/index.html) 在提供強(qiáng)大管理功能的同時(shí)，也帶來(lái)了一個(gè)嚴(yán)重的安全隱患：未授權(quán)訪問(wèn)漏洞。默認(rèn)情況下，任何能夠訪問(wèn)服務(wù)端口的人都可以直接進(jìn)入 Druid 的監(jiān)控后臺(tái)，查看集群狀態(tài)、數(shù)據(jù)源信息、執(zhí)行查詢(xún)、甚至提交任務(wù)，這無(wú)疑是將系統(tǒng)的核心腹地暴露給了潛在的攻擊者。

許多開(kāi)發(fā)者嘗試通過(guò)修改應(yīng)用層面的配置文件（如 web.xml 或 application.yaml）來(lái)為 Druid 監(jiān)控頁(yè)面添加認(rèn)證和授權(quán)。然而，在復(fù)雜的部署環(huán)境和多變的框架版本中，這些修改往往因?yàn)榕渲貌簧А⒈桓采w或存在疏漏而宣告失敗。本文將另辟蹊徑，從網(wǎng)絡(luò)接入層入手，介紹一種更為徹底和普適的解決方案：利用 Nginx 作為反向代理，在流量到達(dá) Druid 服務(wù)之前，直接攔截并禁止對(duì)監(jiān)控頁(yè)面的訪問(wèn)。這種方法與應(yīng)用層配置解耦，部署簡(jiǎn)單，效果立竿見(jiàn)-影，能夠?yàn)槟闾峁┮坏缊?jiān)實(shí)可靠的安全防線。

1. Druid 未授權(quán)訪問(wèn)漏洞深度解析

在探討解決方案之前，我們必須深刻理解這個(gè)漏洞的本質(zhì)、危害以及傳統(tǒng)修復(fù)方案為何會(huì)失敗。

1.1 漏洞的成因與風(fēng)險(xiǎn)

Druid 的設(shè)計(jì)初衷是為了在可信的內(nèi)部網(wǎng)絡(luò)環(huán)境中運(yùn)行，因此其 Web 控制臺(tái)默認(rèn)并未強(qiáng)制開(kāi)啟用戶(hù)認(rèn)證。這意味著，一旦 Druid 的服務(wù)端口（如 8888 或 8080）暴露在公網(wǎng)或不受信任的網(wǎng)絡(luò)環(huán)境中，攻擊者只需在瀏覽器中輸入 http://<your-druid-host>:<port>/druid/index.html，即可長(zhǎng)驅(qū)直入，獲取對(duì)整個(gè)集群的控制權(quán)。

該漏洞帶來(lái)的風(fēng)險(xiǎn)是多方面的，具體可歸納為以下幾點(diǎn)：

1.2 傳統(tǒng)應(yīng)用層修復(fù)方案的局限性

社區(qū)和官方文檔中提到了多種在 Druid 應(yīng)用層面增加安全性的方法，主要集中在修改配置文件。

• 修改 web.xml：在早期的 Servlet 容器部署模式中，可以通過(guò)配置 security-constraint 來(lái)限制對(duì)特定 URL 的訪問(wèn)。但隨著 Druid 版本的演進(jìn)和內(nèi)嵌式服務(wù)器（如 Jetty）的普及，這種方式變得不再通用，且容易因版本不匹配而配置失敗。
• 修改 application.yaml 或 runtime.properties：新版本的 Druid 提倡通過(guò)其自身的安全擴(kuò)展（Security Extensions）來(lái)配置認(rèn)證和授權(quán)。這需要引入 druid-basic-security 等擴(kuò)展，并詳細(xì)配置 Authenticator 和 Authorizer。這個(gè)過(guò)程相對(duì)復(fù)雜，涉及多個(gè)節(jié)點(diǎn)的配置同步，任何一個(gè)環(huán)節(jié)出錯(cuò)都可能導(dǎo)致安全策略不生效。

這些方法之所以常常“失靈”，原因主要有以下幾點(diǎn)：

1. 配置復(fù)雜性高：?jiǎn)⒂?Druid 的原生安全特性需要對(duì) Druid 的架構(gòu)有深入理解，配置文件冗長(zhǎng)，參數(shù)眾多，容易遺漏或配錯(cuò)。
2. 版本兼容性問(wèn)題：不同 Druid 版本的安全配置方式存在差異，一個(gè)版本的解決方案可能無(wú)法直接用于另一版本，給升級(jí)和維護(hù)帶來(lái)困難。
3. 環(huán)境差異：在容器化（如 Docker, Kubernetes）部署環(huán)境中，配置文件的管理和分發(fā)更為復(fù)雜，容易因掛載錯(cuò)誤或環(huán)境變量覆蓋問(wèn)題導(dǎo)致安全配置未被正確加載。
4. “黑盒”效應(yīng)：當(dāng)配置不生效時(shí)，排查問(wèn)題變得非常困難。開(kāi)發(fā)者很難直觀地判斷是配置寫(xiě)錯(cuò)了，還是擴(kuò)展沒(méi)加載，或是被其他配置覆蓋了。

正因?yàn)閼?yīng)用層修復(fù)存在諸多不確定性，我們才需要一種更簡(jiǎn)單、更可靠的“外部”解決方案。

2. Nginx：釜底抽薪的終極防護(hù)方案

將安全防護(hù)的陣地前移到 Nginx 反向代理層，就如同在進(jìn)入小區(qū)的門(mén)口設(shè)置了門(mén)禁，無(wú)論小區(qū)內(nèi)部的哪一棟樓忘記鎖門(mén)，非請(qǐng)勿入者都無(wú)法進(jìn)入小區(qū)大門(mén)。這種方式實(shí)現(xiàn)了安全策略與后端應(yīng)用的解耦，具有極高的可靠性和靈活性。

2.1 為什么選擇 Nginx？

使用 Nginx 來(lái)攔截對(duì) Druid 監(jiān)控頁(yè)面的訪問(wèn)，具備以下顯著優(yōu)勢(shì)：

• 普適性強(qiáng)：無(wú)論你使用哪個(gè)版本的 Druid，無(wú)論它是如何部署的（物理機(jī)、虛擬機(jī)、容器），只要你的應(yīng)用通過(guò) Nginx 對(duì)外提供服務(wù)，這個(gè)方案就適用。
• 配置簡(jiǎn)單直觀：只需在 Nginx 配置文件中增加幾行代碼，邏輯清晰明了，無(wú)需重啟后端 Druid 服務(wù)，即可熱加載生效。
• 性能卓越：Nginx 是一個(gè)高性能的 Web 服務(wù)器和反向代理，在網(wǎng)絡(luò)層處理訪問(wèn)控制的性能損耗極低，不會(huì)對(duì)正常的業(yè)務(wù)請(qǐng)求造成影響。
• 集中管理：如果你的系統(tǒng)中有多個(gè)類(lèi)似 Druid 這樣的帶有風(fēng)險(xiǎn)后臺(tái)的應(yīng)用（如 Spring Boot Actuator, Sentinel Dashboard），你可以在 Nginx 層面對(duì)它們進(jìn)行統(tǒng)一的安全訪問(wèn)控制，便于集中審計(jì)和管理。

2.2 Nginx 配置實(shí)戰(zhàn)

假設(shè)你的 Nginx 已經(jīng)配置為 Druid 的反向代理，基本的配置可能如下所示：

Nginx

server {
    listen       80;
    server_name  druid.yourcompany.com;

    location / {
        proxy_pass http://<your_druid_coordinator_host>:8888;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

現(xiàn)在，我們的目標(biāo)是禁止所有對(duì) /druid/ 路徑的訪問(wèn)。我們需要在上述配置中，在 location / 塊之前，增加一個(gè)專(zhuān)門(mén)匹配 /druid/ 的 location 塊。

Nginx

 禁止訪問(wèn)Druid監(jiān)控頁(yè)面
location ~* ^/druid/ {
    return 403;
    access_log off;
    log_not_found off;
}

下面我們來(lái)詳細(xì)解讀這幾行配置的含義：

• location ~* ^/druid/
  • location：Nginx 用于匹配請(qǐng)求 URI 并為其指定處理指令的塊。
  • ~*：這是一個(gè)修飾符，表示進(jìn)行不區(qū)分大小寫(xiě)的正則表達(dá)式匹配。這意味著無(wú)論是 /druid/、/Druid/ 還是 /DRUID/ 都會(huì)被匹配到，增強(qiáng)了規(guī)則的健壯性。
  • ^/druid/：這是正則表達(dá)式本身。^ 表示匹配 URI 的開(kāi)頭，確保只有以 /druid/ 開(kāi)頭的請(qǐng)求才會(huì)被此規(guī)則捕獲，避免誤傷如 /my/druid/path 這樣的正常路徑。
• return 403;
  • 這是此規(guī)則的核心。return 指令會(huì)停止處理請(qǐng)求，并直接向客戶(hù)端返回指定的 HTTP 狀態(tài)碼。403 Forbidden（禁止訪問(wèn)）是一個(gè)非常明確的狀態(tài)碼，它告訴客戶(hù)端“服務(wù)器理解你的請(qǐng)求，但拒絕執(zhí)行它”。相比于返回 404 Not Found，403 更能準(zhǔn)確地傳達(dá)這是一種訪問(wèn)控制策略。
• access_log off;
  • 這是一個(gè)優(yōu)化指令。由于所有對(duì) /druid/ 的訪問(wèn)都是我們主動(dòng)禁止的非法訪問(wèn)，記錄這些訪問(wèn)日志的意義不大，反而會(huì)產(chǎn)生大量無(wú)用的日志信息。此指令可以關(guān)閉這條規(guī)則匹配到的請(qǐng)求的訪問(wèn)日志記錄。
• log_not_found off;
  • 當(dāng) Nginx 找不到某個(gè)文件時(shí)，默認(rèn)會(huì)在錯(cuò)誤日志中記錄一條信息。雖然我們這里返回的是 403 而非 404，但關(guān)閉這個(gè)選項(xiàng)可以進(jìn)一步減少不必要的日志記錄。

將這段代碼添加到你的 Nginx 配置文件中，完整的配置示例如下：

Nginx

server {
    listen       80;
    server_name  druid.yourcompany.com;

     ------------------- 新增規(guī)則開(kāi)始 -------------------
     禁止訪問(wèn)Druid監(jiān)控頁(yè)面
     這個(gè) location 塊必須放在通用的 location / 塊之前
     因?yàn)?Nginx 會(huì)優(yōu)先匹配更精確的 location 規(guī)則
    location ~* ^/druid/ {
        return 403;
        access_log off;
        log_not_found off;
    }
     ------------------- 新增規(guī)則結(jié)束 -------------------

    location / {
        proxy_pass http://<your_druid_coordinator_host>:8888;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }

     其他配置...
}

配置修改完成后，使用 nginx -t 命令檢查語(yǔ)法是否正確，然后執(zhí)行 nginx -s reload 平滑地重新加載配置?，F(xiàn)在，再次嘗試訪問(wèn) http://druid.yourcompany.com/druid/index.html，你將看到瀏覽器顯示一個(gè) “403 Forbidden” 的錯(cuò)誤頁(yè)面，而你的 Druid 服務(wù)本身毫發(fā)無(wú)傷，正常的 API 請(qǐng)求依然可以暢通無(wú)阻。

2.3 更進(jìn)一步：允許特定 IP 訪問(wèn)

在某些情況下，你可能希望完全禁止公網(wǎng)訪問(wèn) Druid 監(jiān)控頁(yè)面，但允許公司內(nèi)網(wǎng)的特定 IP（如運(yùn)維、開(kāi)發(fā)人員的 IP）進(jìn)行訪問(wèn)。Nginx 的 allow 和 deny 指令可以輕松實(shí)現(xiàn)這一需求。

你可以修改 location 塊如下：

Nginx

 限制訪問(wèn)Druid監(jiān)控頁(yè)面，僅允許特定IP
location ~* ^/druid/ {
     允許的IP地址或IP段
    allow 192.168.1.100;       允許單個(gè)IP
    allow 10.0.0.0/8;          允許整個(gè)IP段
    
     禁止所有其他IP
    deny all;

     如果允許訪問(wèn)，則將請(qǐng)求代理到后端
    proxy_pass http://<your_druid_coordinator_host>:8888;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

這個(gè)配置的邏輯是：

1. Nginx 檢查訪問(wèn)者的 IP 地址。
2. 如果 IP 地址匹配 allow 規(guī)則中的任何一條，則允許訪問(wèn)，并繼續(xù)執(zhí)行 proxy_pass 等指令，將請(qǐng)求轉(zhuǎn)發(fā)給后端的 Druid。
3. 如果 IP 地址不匹配任何 allow 規(guī)則，deny all 規(guī)則將生效，Nginx 會(huì)返回 403 Forbidden。

這種基于 IP 的白名單策略，為你提供了一種在安全性和可管理性之間取得平衡的靈活方案。

3. 建立縱深防御體系

雖然 Nginx 提供了一道堅(jiān)固的外圍防線，但真正的安全從不是單點(diǎn)的。我們應(yīng)該建立一個(gè)“縱深防御”（Defense in Depth）體系，即使某一層防護(hù)被繞過(guò)，后續(xù)的層次依然能起到保護(hù)作用。

• 網(wǎng)絡(luò)隔離：始終將 Druid 集群部署在內(nèi)部網(wǎng)絡(luò)中，通過(guò)防火墻或安全組策略，嚴(yán)格限制可以訪問(wèn) Druid 服務(wù)端口的源 IP。這是最基本的網(wǎng)絡(luò)安全準(zhǔn)則。
• 應(yīng)用層加固：盡管配置復(fù)雜，但在條件允許的情況下，仍然建議啟用 Druid 的 druid-basic-security 擴(kuò)展，為 API 和 UI 設(shè)置用戶(hù)認(rèn)證和角色授權(quán)。這可以防止來(lái)自?xún)?nèi)部網(wǎng)絡(luò)但未授權(quán)的訪問(wèn)。
• 最小權(quán)限原則：為 Druid 運(yùn)行的用戶(hù)配置最小的文件系統(tǒng)權(quán)限，確保即使發(fā)生遠(yuǎn)程代碼執(zhí)行漏洞，攻擊者能夠造成的破壞也有限。
• 定期審計(jì)與更新：關(guān)注 Apache Druid 官方發(fā)布的安全公告，及時(shí)升級(jí)到修復(fù)了已知漏洞的版本。定期審計(jì)你的網(wǎng)絡(luò)和應(yīng)用配置，確保安全策略依然有效。

結(jié)語(yǔ)

面對(duì) Druid 未授權(quán)訪問(wèn)這一高危漏洞，依賴(lài)時(shí)常“失靈”的應(yīng)用層配置已非萬(wàn)全之策。通過(guò)在 Nginx 反向代理層增加一個(gè)簡(jiǎn)單的 location 規(guī)則，我們可以構(gòu)建一道與應(yīng)用無(wú)關(guān)、堅(jiān)不可摧的外部防線，以一種優(yōu)雅且高效的方式徹底屏蔽對(duì) Druid 監(jiān)控頁(yè)面的未授權(quán)訪問(wèn)。這種“釜底抽薪”式的解決方案不僅操作簡(jiǎn)單、立竿見(jiàn)影，更體現(xiàn)了將安全控制左移到流量入口的現(xiàn)代安全理念。

然而，我們必須牢記，安全是一個(gè)系統(tǒng)工程。在享受 Nginx 帶來(lái)的便捷與高效的同時(shí)，也應(yīng)結(jié)合網(wǎng)絡(luò)隔離、應(yīng)用層認(rèn)證、權(quán)限控制等多種手段，構(gòu)建多層次、縱深化的安全防御體系。只有這樣，才能在享受 Druid 強(qiáng)大數(shù)據(jù)分析能力的同時(shí)，確保我們的數(shù)據(jù)和系統(tǒng)固若金湯。

以上就是Nginx徹底解決Druid未授權(quán)訪問(wèn)漏洞的方法的詳細(xì)內(nèi)容，更多關(guān)于Nginx Druid未授權(quán)訪問(wèn)漏洞的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！