基于反向代理技術的高校Web 安全管理方案研究

摘要：隨著信息化和在線應用的普及，高校使用大量基于BS架構的應用管理系統。然而，由于缺乏統一的安全管理平臺，這些系統的管理后臺存在嚴重的安全隱患，威脅業務的安全性和可靠性。文章深入研究高校Web安全管理，提出基于反向代理技術的管理方案，在保障高校的Web安全管理需求的同時，提高了運維和管理效率，從而更好地服務于高校教學和科研工作。

關鍵詞：反向代理；安全運維；網絡安全

中圖分類號：TP3 文獻標識碼：A

文章編號：1009-3044（2024）32-0089-03 開放科學（資源服務）標識碼（OSID） ：

1 現狀分析

近年來，高校網絡安全事件頻發，高校承載了教學和科研等重要工作，存在較多的敏感數據。隨著信息化的高速發展和在線應用的廣泛普及，高校的信息系統規模呈現爆發式增長，業務管理系統也隨之大量增加。高校的業務系統大多采用B/S架構，為了確保系統的安全性，通常會將管理和業務服務相分離，后臺管理通過單獨的服務端口或IP運行，對外僅開放業務服務，以實現安全隔離，確保核心數據和信息系統的安全穩定。隨著業務量的增長，服務器的數量也快速增加，為方便運維管理，服務器通常配備了面向Web的IPMI帶外管理功能[1]。盡管帶外管理的使用頻率相對較低，但在需要重裝系統或檢查硬件狀態時發揮了巨大的便利性。特別是在遭遇意外宕機或配置錯誤導致系統無法進行遠程運維時，帶外管理功能能夠顯著降低運維人員現場操作的開銷，從而更快地恢復業務。此外，高校中還存在大量的需要通過Web管理的硬件設備，包括攝像頭、門禁、交換機等。在日常管理中，這些基于Web 的管理后臺存在如下安全問題。

1）應用數量多，但沒有統一的管理入口，導致了資產不清，容易存在安全盲區。

2）管理復雜，安全性差，雖然可以通過防火墻策略進行訪問控制，但配置繁雜，限制訪問區域的同時也降低了運維的及時性和靈活性。

3）公司等第三方人員參與運維工作，不利于安全管控。

4）大多系統管理日志保存不全或保存日期較短，關鍵時刻無法完成溯源工作。

5）業務管理系統較多使用HTTPS協議，明文傳輸數據，存在較高的安全風險。

6）部分管理后臺使用的是舊版本的TLS協議，并且升級困難，主流的瀏覽器已經不支持，兼容性差。

7）使用HTTPS協議的管理的設備使用自簽名證書，傳輸內容加密，WAF和流量監控設備無法識別內容，難以進行安全防護。

8）設備存在較多的管理弱口令或默認口令，容易被爆破。

9）管理登錄缺乏多因子驗證，安全性較低。

根據等級保護要求，高校的服務器系統都采用了專用的堡壘機[2]進行安全運維，堡壘機以SSH、RDP、VNC等遠程管理為主，Web安全運維功能薄弱，或者缺乏安全管控機制，無法和其他安全設備進行聯動。本文研究了基于反向代理技術的高校Web安全管理方案，通過Web代理技術實現對Web管理服務的統一安全管理。這種方案旨在提高學校業務的安全性和穩定性，更好地滿足業務的安全和管理需求，提高運維和管理效率，從而保障教學和科研的順利進行。通過該方案，可以有效地防止惡意攻擊、數據泄露等安全問題的發生，為學校業務提供更加可靠、高效的支撐。

2 相關技術介紹

2.1 反向代理

反向代理是指通過代理服務器接收用戶請求，由代理服務請求后端服務數據，返回給用戶的技術方法。由于代理服務器處于用戶和真實服務之間，請求和響應數據均會經過代理，故代理服務器可以做大量的其他工作，包括負載均衡、訪問控制、安全檢測、用戶驗證、數據脫敏等。反向代理目前已經大量運用于各大企業和高校[3]。反向代理的關鍵技術是要區分不同的服務請求，才能將請求數據轉發到對應的后端服務上面，常用的代理方式主要有以下幾種：1）基于域名的代理，為每個服務單獨分配一個域名，對外將域名解析到代理服務器對應的IP地址，代理服務器通過用戶請求的域名轉發到對應的后端服務器。2）基于子目錄/參數的代理，將每個站點映射為一個子目錄或在請求數據中增加站點參數，代理服務器通過目錄名或參數進行數據轉發。3）基于端口的代理，每個服務分配一個獨立的端口，代理服務器通過端口來確定轉發服務。

2.2 Openresty

OpenResty是國內基于Nginx開發的高性能 Web 應用平臺，具有較強的自主可控性，它將 Nginx 與Lua 編程語言相結合，通過輕量級的 Lua 腳本，提供了豐富的功能和靈活性，如圖1所示。OpenResty 的設計目標是充分利用 Nginx 的事件驅動、高并發和低內存消耗的特性，同時發揮 Lua 腳本易用性和擴展性，為開發者提供一種高效構建和擴展 Web 應用程序的方式。作為代理使用，OpenResty不僅在HTTPS協議代理方面表現優異，同時也對TCP端口提供了出色的支持。目前OpenResty平臺已被我國許多大型互聯網公司采用，在高校中也廣泛應用于資源訪問[4]、資源發布、軟件WAF[5]等多種應用場景。

3 方案設計

3.1 基本架構

整個系統圍繞著HTTPS請求，充分利用了Open?Resty提供的擴展接口，當用戶的請求到達代理服務器后，會被準確到調度到后端真實服務。為了提高系統的運行效率，系統將OpenResty使用的數據緩存到re?dis數據庫中，并與態勢感知平臺進行聯動，以確保Web應用的安全。基本架構圖如圖2所示。

3.2 初始化

在OpenResty的啟動階段，需要執行初始化程序。初始化程序從數據庫中讀取基礎配置信息，并根據這些信息完成OpenResty的配置初始化工作。這一過程確保了全局變量的正確設置，為后續的應用運行提供了堅實的基礎。確保了OpenResty能夠按照預定的配置參數高效、穩定地運行。

3.3 用戶認證管理

代理服務器會攔截用戶請求，并對用戶請求進行準入控制和身份校驗。校驗失敗會將用戶請求重定向到代理服務器的認證頁面。驗證通過后會為用戶設置session，并將其引導至應用入口頁面。由于Nginx本身的限制，我們在某些特定階段無法直接利用cosocket與Redis進行交互。因此，為了獲取存儲于Redis中的策略配置，我們在驗證階段完成這些策略數據的獲取。這些數據將保存在ngx.ctx變量中，供后續模塊在需要時進行調用和使用。這樣的設計確保了整個認證和校驗過程的高效性與連貫性，同時也大大增強了系統的安全性和可靠性。

3.4 請求調度管理

當用戶請求抵達代理服務器時，至關重要的任務便是確保用戶的請求數據被準確無誤地調度到對應的后端服務器，并將獲取的數據高效回傳給用戶。為了達成這一目標，我們的調度管理系統充分運用了OpenResty的卓越代理特性，通過請求的端口以及特定的參數，實現了對應用的準確識別。與此同時，借助強大的管理后臺，我們能夠靈活地設置和優化負載調度策略，以確保應用在各種場景下都能實現負載均衡和高效調度。

3.5 內容替換管理

為了確保應用的廣泛兼容性和流暢的用戶體驗，我們必須對應用所返回的數據進行適當的調整。在實際應用中，有些系統使用的是絕對路徑或在響應體中直接返回真實服務器的請求地址，這會導致用戶的請求無法正確到達代理服務器，從而導致應用訪問失敗。為了有效應對這一問題，我們需要對服務器返回的內容進行修改。通過精確匹配用戶的請求鏈接，并運用正則表達式技術，對返回的內容進行有針對性的替換，從而實現了鏈接級別的內容管理。

由于后端Web服務器可能會對數據進行壓縮以提高傳輸效率，這意味著程序無法直接對壓縮后的數據內容進行識別和處理。為了解決這個問題，我們引入了zlib庫，它提供了強大的數據解壓縮和重壓縮功能。通過zlib庫，我們可以輕松地對數據包進行解壓，完成必要的內容修改后，再重新進行壓縮，確保數據的完整性和準確性。

3.6 Header 信息修正

部分業務為了安全性考慮，對請求數據中的主機名（host） 和引用來源（referer） 等關鍵信息進行安全驗證。為了完成代理任務，我們需要對請求報文進行重構，以滿足后端服務的校驗。由于我們對請求體的內容進行了修改，為了確保返回數據的頭部信息與實際請求體長度一致，需要將“Content-Length”設置為nil，這樣可以確保頭部數據的準確性，避免潛在的數據不一致問題。此外，如果返回的頭部信息中包含“Loca?tion”字段，我們必須對其進行修改或重寫。錯誤的“Location”設置可能會導致URL逃逸，導致服務不能正常訪問。因此，我們在處理請求時，應特別注意對頭部信息的準確性進行控制，以確保整個服務的正常運行。

3.7 日志管理

通過在標準日志中增加了用戶身份信息，發送到第三方日志分析平臺，日志模塊實現了對用戶請求的安全審計和安全監測。為了減少對業務請求的影響，我們采用了異步傳輸，使用OpenResty的ngx.timer來確保數據的非阻塞返回。用戶的請求日志被發送到ELK日志管理中心[6]，充分地利用ELK強大的數據收集、處理和可視化能力，實現快速定位問題，并提供更好的安全審計功能。

3.8 管理后臺

管理后臺主要負責整個系統的管理工作，完成對用戶的管理，應用端口數據的綁定，用戶授權等操作。管理員可以控制URL級別的header和body內容的優化和替換操作。這些數據將同步到redis數據庫，方便OpenResty快速讀取。后臺管理系統還接收態勢感知系統的訂閱日志，通過外部安全數據來將用戶或IP加入黑名單，從而更好地保障業務的安全性。

3.9 ModSecurity

雖然可以在應用前端加入硬件WAF，解決大多數的Web安全攻擊，但硬件WAF對用戶來說是黑盒，難以對其中的規則進行修改，缺乏可控性和靈活性。故在系統中增加了ModSecurity。ModSecurity是Nginx的主流WAF 模塊，通過與OpenResty 一起編譯，引入OWASP核心規則集，并針對應用對部分規則進行了優化，更好地實現了對應用的安全防護[7]。

4 用戶訪問

用戶使用主要存在兩種業務場景，一種是業務管理員自己使用，可以直接從用戶頁面點擊對應管理業務。另一種是需要提供給第三方人員使用，業務管理員可以通過管理頁面生成帶有時效和使用者身份的管理鏈接，將該鏈接交給第三方公司的維護人員，從而實現業務的管理。這兩種情形均使用JWT技術[8]，通過在請求數據中加入使用者的身份信息，實現用戶認證和授權操作。

5 結束語

本文基于反向代理技術實現了高校的Web安全管理，有效解決了Web資源管理散亂，統一了訪問入口。通過使用HTTPS協議，解決了TLS版本不受支持的問題，提供了更安全的數據傳輸服務，有效防止了數據泄露的風險。通過日志模塊實現了管理日志的集中審計和監控。并使用安全模塊對用戶的請求進行基本的過濾與安全檢測，與安全態勢感知平臺進行聯動，對異常請求進行攔截，有效保障了后端服務安全。為高校的Web安全管理提供了有力的支撐，有效保障了學校老師和同學的學習，生活和科研的順利進行。

參考文獻：

[1] 尹賽超，黃梅.數據中心帶外管理建設研究[J].信息技術與信息化，2023（3）：66-69.

[2] 曹園青，艾麗斯娜，王惠惠.堡壘機系統在高校網絡安全架構中的聯動實踐研究[J].電腦編程技巧與維護，2023（3）：164-167.

[3] 韓紅宇，樊蒙蒙.反向代理技術在高校網絡中的應用[J].漯河職業技術學院學報，2022，21（5）：22-25.

[4] 倪劼.圖書館數字資源訪問統計系統構建研究：基于Open?Resty平臺[J].圖書館工作與研究，2019（10）：75-82，96.

[5] 王明芬，林婷.基于WAF的網絡運維系統設計[J].電信快報，2020（11）：26-29.

[6] 章逢歡，胡敬超，張雯，等.一種基于ELK的反向代理日志分析系統設計[J].電腦編程技巧與維護，2022（6）：24-26.

[7] 張會奇.WAF系統在OpenResty上的構建[J].福建電腦，2020，36（12）：142-144.

[8] 陸婷婷，殷佳庭.基于微服務架構的船貨供求信息平臺的設計實現[J].蕪湖職業技術學院學報，2023，25（2）：36-39.

【通聯編輯：朱寶貴】