基于隨機響應隊列的ActiveMQ安全應用①

龔建華

(武漢科技大學 城市學院,武漢 430083)

1 引言

消息中間件是大型系統中的重要組件,它具有松耦合、異步消息、流量削峰、可靠投遞、廣播、流量控制、最終一致性等一系列功能,已經成為異步RPC的主要手段之一.目前常見的消息中間件有ActiveMQ、RabbitMQ、Kafka、RocketMQ 等[1].消息中間件在大型系統和分布式系統中應用非常廣泛[2-18],因此消息中間件應用的安全性應該得到足夠重視.

2 共享響應隊列安全風險分析

面對分布式應用的信息安全問題,ActiveMQ 采取了一些必要的安全措施,主要有兩種安全訪問策略[19],一是簡單認證策略,二是Java 認證與授權(JAAS)策略.由于消息中間件在多用戶應用中通常采用共享響應隊列應用模式,導致上述ActiveMQ 安全措施仍然不能防止合規用戶的越界訪問和違規獲取信息.

2.1 簡單認證策略及其安全風險

簡單認證策略中,需要在ActiveMQ 服務器的activemq.xml 文件中配置允許訪問消息隊列的用戶,具體說就是在簡單認證插件(SimpleAuthenticationPlugin)中配置用戶名、密碼和分組.然后在客戶端建立到消息隊列連接時,填寫用戶名和密碼即可.這種策略的本質是經過授權用戶的可以使用消息隊列,類似于用戶名/密碼的登錄機制.

這種策略的優點是使用起來比較方便簡單,但也存在安全風險,合法用戶對消息隊列的操作沒有限制,可以管理、讀、寫任何消息隊列.在此策略基礎上,如果采取常用的共享請求隊列(即各客戶端的請求發送到一個隊列中)或共享響應隊列模式,合法用戶可以利用第三方工具軟件從共享請求隊列中或共享響應隊列中非法讀取他人請求信息.

2.2 Java 認證與授權策略及其風險

Java 認證與授權策略中,也需要配置用戶名、密碼和分組,并將這3 項配置內容分散在3 個文件中[19],如在login.config 文件中配置用戶名密碼管理文件和用戶分組管理文件,在user.properties 文件中設置用戶名和密碼,group.properties 文件中設置分組和用戶名.

與簡單認證策略不同,JAAS 策略中增加授權機制,即每一個隊列只有指定的分組才可以管理或讀或寫,對合法用戶可以訪問的消息隊列進行限制,比如只能向公共請求隊列發送消息而不能讀取消息,從而保證發送到公共請求隊列的消息不被合法用戶違規讀取.在這種授權機制中,上行方向單向應用消息隊列是安全的,即客戶端向服務器端發送請求信息時采用共享請求隊列可以保證安全性.如果下行方向也采用分組共享響應隊列,不能保證其安全性.

Wireshark 是非常流行的網絡封包分析軟件,可以抓取各種網絡封包,顯示網絡封包的詳細信息.

圖1是利用該軟件分析得到的訪問消息列隊的用戶名和密碼,利用該軟件分析出得到的響應隊列名稱,同樣利用該軟件還可以分析出消息中間件服務器的IP 地址、端口號等,有了這些分析信息,合法用戶可以通過第三方軟件違規獲取其他用戶的響應信息.

由此可見,雖然JAAS 策略比簡單認證策略有所改進,但是下行方向采用常見的共享響應隊列時仍然存在安全風險.

圖1 利用Wireshark 抓包分析用戶名和密碼

3 基于隨機響應隊列的安全機制

3.1 系統基本架構

消息中間件應用中,共享響應隊列模式是影響系統安全性的關鍵因素,為了提高系統安全性,每個客戶端應該獨立使用一個響應隊列.在ActiveMQ 中,如果給每個客戶端單獨配置用戶名、密碼和響應隊列,當客戶端很多時,配置工作量將會非常大,而且動態增減用戶時,必須更新配置文件并重啟消息中間件服務器,這會影響系統的連續運行.

本文提出隨機響應隊列應用模式,既不用大量維護配置文件和重啟服務器,又可以使每個客戶端隱蔽地單獨占用一個響應消息隊列,系統架構如圖2所示.

圖2 隨機響應隊列系統架構

在系統架構中,消息中間件服務器中有1 個共享請求隊列和n個隨機響應隊列.各個客戶端對共享請求隊列有寫權限無讀權限,服務端對共享請求隊列有讀權限無寫權限.服務端對所有n個客戶端響應隊列有寫權限無讀權限,各個客戶端對所有n個客戶端響應隊列有管理和讀權限無寫權限.

在設置系統配置文件時,給所有客戶端配置共同的用戶名和密碼,能夠管理和讀取某個固定前綴(如USER.response)的響應隊列.為了保證客戶端i響應隊列只被客戶端i讀取,而不被其他客戶端讀取,將客戶端i響應隊列的名稱設置為：“固定前綴+用戶名+隨機碼”,例如USER.response.useri-xdWE2qUsz4,加入“固定前綴”可以確保所有客戶端都可以創建類似的隊列,加入“用戶名”可以保證隊列名不同重復,加入“隨機碼”可以保證隊列名不可預知從而保證隊列名稱的隱蔽性.雖然各客戶端理論上可以讀取這個隨機響應隊列中的信息,但是由于這個響應隊列名稱的隨機性且只有創建它的客戶端知道,因而事實上這個響應隊列只能被創建它的客戶端使用,從而保證安全性.為了讓服務端也知道這個隨機響應隊列的名稱,客戶端給服務端發送請求時,只需要附帶這個隨機響應隊列名稱即可.

為了完成上述任務,activemq.xml 文件需要增加如下配置[19]：

3.2 系統運行過程

在隨機響應隊列系統架構中,共享請求隊列是固定的,由消息中間件服務器創建.客戶端i發送請求和獲得響應的完整閉環過程如下：

(1)客戶端i啟動時,動態創建客戶端i響應隊列,如USER.response.useri-xdWE2qUsz4.

(2)客戶端i通過共享請求隊列發送請求,請求信息除了業務信息外,還需要附帶客戶i響應隊列名稱,如,textMessage.setStringProperty("queueName","USER.response.useri-xdWE2qUsz4"),以便告知服務端響應信息發送到哪個隊列.

(3)服務端從請求隊列接收消息,解析queueName,如,textMessage.getStringProperty("queueName"),并將業務響應結果發送到USER.response.useri-xdWE2qUsz4響應隊列中.

(4)客戶端i監聽USER.response.useri-xdWE2qUsz4響應隊列,當發現新消息時,從響應隊列中讀取消息,完成業務請求-響應閉環.

(5)客戶端i退出時,刪除隨機響應隊列USER.response.useri-xdWE2qUsz4.

3.3 系統安全性分析

在隨機響應隊列系統架構下,假定合規客戶i想要非法獲取其他客戶端請求和響應信息,在客戶端i啟動時,在本地使用抓包軟件進行分析,他只能獲取消息中間件服務器的IP 地址、端口號、共享請求隊列的名稱、客戶端i響應隊列的名稱等.共享請求隊列是只寫的,因此他不能通過讀取請求隊列的內容,也無法通過此途徑違規獲取有關信息.由于不能獲得客戶端i響應隊列之外的其他隊列的名稱,因此也無法訪問其他響應隊列,無法違規獲取其他客戶有關信息.雖然能夠獲取客戶端i響應隊列的名稱,也可以獲取客戶端i響應隊列的內容,但是此內容已在他自己的客戶端中可以展現,再用第三方軟件抓取已經沒有實際意義.經上述分析,在獨立響應隊列系統架構下,可以保證消息隊列中的信息安全.

消息中間件服務器的安全防護不是本文的研究內容,用戶非法直接攻擊消息中間件服務器,非法獲取或篡改配置信息不在本文研究范圍之內,本文假定消息中間件服務器本身已經采取了防攻擊措施.

4 性能分析

前面分析系統的架構、運行過程和安全性,還需要進一步分析系統在點對多點分布式應用中的性能,從定量角度分析探索哪些因素是制約系統運行性能的關鍵因素.在客戶端/服務器計算模式中,系統響應時間是一項重要的指標,可用經典排隊論模型對系統性能進行分析.

系統時間模型如圖3所示,系統運行時間為客戶端發送業務請求到收到請求響應所經歷的時間,設客戶端i的請求到達共享請求隊列的傳輸時間為t1,該請求在共享請求隊列中等待的時間為t2,該請求從共享請求隊列傳輸到服務端的傳輸時間為t3,該請求在服務端業務處理時間為t4,響應從服務端傳輸到客戶端i響應隊列的時間為t5,響應在隊列中等待時間為t6,響應從隊列到達客戶端的時間為t7.

圖3 系統時間模型

(1)設信息在系統中的傳輸時間t傳,則t傳=t1+t3+t5+t7,t傳與系統網絡硬件環境有關,因此隨機響應隊列應用模式不會改變t傳的大小.

(2)設信息在系統中的等待時間t等,則t等=t2+t4+t6,由于客戶端i響應隊列為客戶端i獨享,因此t6=0,最終t等=t2+t4,與系統中的客戶端數量、單位時間內客戶端發送的請求數量以及服務端的處理能力有關,與客戶端i響應隊列無關.

綜上所述,系統運行時間主要受系統網絡硬件環境、客戶端數量、單位時間內客戶端發送的請求數量以及服務端的處理能力有關,采用隨機響應隊列模式不會影響系統運行時間或性能.下面著重討論為保證服務質量應當采取的相關措施.

假設客戶端發送請求為簡單流(泊松流),單位時間內,客戶端平均發送 λ次請求,則單位時間內發送次數服從分布為X～P(λ)[20].

對于n個相互獨立的客戶端,設每個客戶端單位時間平均發送 λi次請求,則到達業務請求隊列的請求次數服從分布為：

假設服務端完成業務處理的時間服從負指數分布,且在單位時間內平均完成μ 條業務處理,則概率密度為：

假設消息隊列長度不受限制,請求響應服從M/M/1[20]排隊系統模型,則平均系統逗留時間為：

為簡便起見,設λi=λ,則：

式(4)中,nλ 表示總的請求強度,只有μ ＞nλ時,業務請求隊列的平均隊長才是一個有限值,請求逗留時間才是一個有限值,否則平均隊長會越來越大趨于無限,使得等待時間也趨于無限,最終請求應答不可完成.

根據條件的限制,當服務端的業務處理能力一定時,即μ一定時,必須滿足nλ ＜μ,也就是說,如果n比較大,那么 λ必須足夠小,其表示物理意義是,如果客戶端數量較多,那么每個客戶端的請求強度不能太高；反過來,如果 λ比較大,那么n必須很小,其表示的物理意義是,如果每個客戶端的請求強度比較大,則客戶端的數量不能太多.

當μ ＞＞nλ 時,wq比較小,當μ →nλ 時,wq迅速增大,假定用戶對逗留容忍的值為Wmax,用戶的操作習慣決定了請求強度為 λ,服務器的性能決定了服務能力為μ,μ和 λ 通過樣本均值統計得到,那么系統可允許的客戶端數量為為了保證服務質量,在線用戶數達到nmax服務端應該拒絕為新用戶提供服務,確保已在線用戶可以得到滿意的服務在質量.

5 結論

圍繞消息中間件安全應用問題,本文提出了基于隨機響應隊列的應用模式,給出了系統架構和運行過程.通過定性分析,隱蔽的隨機響應隊列可以有效防范非法獲取響應信息；通過時間模型分析,隨機響應隊列應用模式不會影響系統運行性能；通過理論計算表明,在請求強度和服務能力確定的情況下,為保證服務質量,在線用戶規模應控制在以下.