基于主動探測的非關系型數據庫風險感知系統設計與實現

孫偉明　張華熊

摘? 要：Elastic數據庫是一款主流的非關系型數據庫，默認安裝時存在潛在的信息泄露風險。本文基于網絡主動探測技術，設計實現了一個Elastic數據庫風險感知系統。系統首先通過協議構造實現Elastic服務器上各類信息的獲取，然后設計了一種基于手機號碼、郵箱地址、身份證號、地名地址等多維數據協同分析的敏感信息檢測方法，從而評估數據庫風險等級并進行預警。本文最后進行了敏感數據檢測測試及總體功能測試，實驗結果表明了本文敏感信息檢測方法及系統設計實現的有效性。

關鍵詞：非關系型數據庫;Elastic;信息泄露;主動探測;風險感知

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

Abstract： Elastic database is a mainstream non-relational database with a potential risk of information leakage when installed by default. This paper proposes to design and implement an Elastic database risk perception system based on network active detection technology. The system first realizes acquisition of various types of information on Elastic server through protocol construction， and then designs a sensitive information detection method based on collaborative analysis of multi-dimensional data such as mobile phone numbers， email addresses， ID numbers， and place-name addresses， so to evaluate risk level of the database and issue early warning. At the end of this paper， sensitive data detection test and overall function test are carried out. Experimental results show the effectiveness of the sensitive information detection method and system design and implementation proposed in this paper.

Keywords： non-relational database; Elastic; information leakage; active detection; risk perception

1? ?引言（Introduction）

當今隨著互聯網的快速發展，海量非結構化數據對系統存儲搜索等實時響應性能要求也相應提高。傳統的關系型數據庫已不能滿足大數據環境下的響應需求，非關系型數據庫[1]（Not Only SQL，NoSQL）應運而生。與傳統的關系型數據庫相比，NoSQL數據庫不預定義數據模式和表結構，存儲類型靈活，并發性能高，可擴展性強。但相較于關系型數據庫遵循嚴格的一致性ACID原則，NoSQL數據庫則遵循CAP理論[2]。NoSQL數據庫專注于性能和靈活性，其極少內置完整的安全機制[3]。同時NoSQL數據庫普遍采用REST的數據接口進行操作，即可通過URL進行數據庫的相關操作，這使得NoSQL數據庫存在數據安全問題的隱患。Elastic是一個基于Lucene的NoSQL數據庫。Elasticsearch是該數據庫的搜索引擎，廣泛應用于海量數據的搜索功能[4]。本文以網絡設備搜索引擎Shodan[5]上可探測的Elastic數據庫為研究對象，以主動探測的方式判別是否存在風險，設計實現Elastic數據庫風險感知系統。

2? ?Elastic數據庫存在的安全風險（Security risks of Elastic database）

Elastic數據庫是一款主流的NoSQL數據庫，其搜索引擎Elasticsearch可提供性能高效的搜索服務，多用于搜索引擎、日志存儲、安全防護[6，7]。Elastic的權限、密碼設置需要通過擴展插件X-pack來實現。該插件將安全、警告、監視、圖形和報告功能捆綁在一個易于安裝的軟件包中以供用戶使用。Elastic可免費使用，但是X-pack收費，免費試用一個月。因此，未安裝X-pack的Elastic應用信息容易被泄露。Elastic以文檔的形式進行存儲，有相應的API可以獲取文檔中的內容。只要獲取Elastic服務器的IP和端口號，即可通過URL進行連接，存在文檔泄漏等安全風險。在Shodan官網上搜索Elastic數據庫設備在線情況，截至2020年5月30日得到全球分布總量26，763 臺及在中國的數量9，731 臺，這些公網上可探測的數據庫可能存在一定的安全隱患。

3? ?系統需求分析（System requirements analysis）

本文設計實現Elastic數據庫風險感知系統，目的是判斷IP主機上是否存在沒有安全機制的Elastic數據庫。如若可以不經過驗證機制連接到Elastic數據庫，則記錄下該IP地址，并從該數據庫中獲取數據進行敏感性檢測。敏感數據包含諸如姓名、身份證號、郵編、住址等敏感信息，由敏感數據檢測結果判斷該Elastic數據庫存在的風險大小。

4? 系統設計與實現（System design and implementation）

4.1? ?感知Elastic數據庫風險的方法

Elastic數據庫使用URL進行交互，其默認端口是9200。本文通過以下命令進行查詢：

如果該IP端沒有安裝Elastic數據庫，則無法訪問;若Elastic數據庫設置了密碼，則會報錯，報錯信息如圖1所示;若能正常訪問，則說明存在安全風險。判斷Elastic數據庫是否存在風險的流程如圖2所示。正常訪問返回Elastic數據庫相關信息，具體信息如表1所示。表1中health和status描述的是數據庫的狀態;index是索引，可以理解為關系數據庫中的數據庫名;pri、rep分別表示主集群數量、備份集群數量;其后兩個字段表示當前數據庫所存的文檔數和已刪除的文檔數;store.size和pri.store.size分別表示主從數據庫總的大小、主數據庫的大小。在Elastic中，每一個index對應關系數據庫中的一個數據庫，每個index下的文檔類型相似。

4.2? ?整體架構設計

整個系統分為日志模塊、系統配置模塊、IP探測模塊、數據檢測模塊，系統整體流程如圖3所示。

系統采用多線程[8]的設計模式，通過Qt平臺[9]進行系統實現。多線程的并發使用提高了CPU的利用率，處理網絡請求更快，特別有利于網絡應答模式的實現。多線程要處理好共享資源的讀寫，避免產生死鎖。Qt具有優良的跨平臺特性，支持多種操作系統。此外，Qt面向對象，具有良好的封裝性，可重用性好。Qt的信號槽機制（Signals/Slots）代替回調函數，使各個模塊之間的協同工作更加簡單高效。Qt豐富的API為編程提供了極大便利，其中的正則表達式在后續的內容檢測上發揮了很大的作用。

4.3? ?IP探測模塊設計與實現

Elastic數據庫探測分兩步進行：（1）通過式（1）判斷該IP是否存在Elastic數據庫。如果該IP端沒有安裝Elastic數據庫，結束探測，否則進入第二步;（2）抓取index下文檔的內容進行分析。第一步通過式（1）獲得數據庫相關的index及對應的大小;第二步通過第一步所獲得的index值，通過以下命令查詢數據庫內容：

size是設定查詢一次返回的記錄數。通過構造URL把滿足主數據庫特定大小或是包含敏感詞的索引獲取到相應的記錄，并把這些記錄保存在輸出目錄的文件中。

IP探測過程如圖4所示。首先使用首次探測隊列、二次探測隊列來存儲上述兩步分別構造的URL。在探測開始前，需要從外部輸入文件中讀取要探測的IP，構造好URL后壓入首次探測隊列中。探測開始時，基于Qt網絡請求的特性，首先設置連接網絡請求處理的信號槽機制。在處理網絡數據時，為加快請求速度，除了采用多線程技術，還采用了批處理的方式。網絡請求正常返回后，調用多線程處理回復的報文。主進程以最大請求量MaxRequestNum發起探測請求，當返回后的數據流中含有index記錄，且pri.store.size滿足探測最小存儲值時，構造式（1）所示的URL加入二次探測隊列中，以備二次探測。當所有IP均完成第一步探測后，進行第二步探測。二次IP探測請求時，數據庫返回的記錄保存在輸出文件中。二次IP探測時，通常某個IP下存在多個滿足條件的索引index，為了避免Elastic在大并發讀取數據庫時引起的拒絕訪問，本文引入了延時處理機制。一批請求發出后，會延時固定時間后再進行下一批次的訪問請求，延時時間的設定在保證Elastic服務端不被拒絕的同時要保證程序的高效性。綜合這兩種因素本文設定默認延時為2 秒。當二次探測隊列為空時，為保證最后一批請求的數據能順利保存，設定固定延時等待，程序默認延時等待5 分鐘，隨后訪問請求階段結束。

4.4? ?敏感數據檢測模塊設計

從Elastic數據庫中取出數據后，進行相應的敏感檢測，以進一步評估安全風險。檢測數據中是否包含電話號碼、身份證號、郵箱地址、地名地址等相關信息。包含這些信息，證明該數據庫有著較高的安全隱患。前期探測得來的數據以字符串的形式保存在輸出文件中，檢測模塊要在字符串中快速比對出上述四種相關信息。電話號碼、身份證號、郵箱地址均有鮮明可識別的特征，故采用正則表達式的方式進行識別;地名地址識別較前者更為復雜，需單獨設計算法檢測。檢測得出的敏感信息文檔及對應的IP、數據庫索引index均輸出保存在風險數據庫文件夾下。

（1）識別電話號碼。電話號碼在這里主要考慮手機號碼的識別。手機號碼一共有11位數字，前兩位數字只能是13/14/15/16/17/18/19中的一個，后9位為0—9的數字。由此得到手機號碼的正則表達式：

（2）識別身份證號。現在我國的居民身份證號是18位，由17位數字體本體碼和1位校驗碼組成。從左往右排列順序依次是：6位數字地址碼、8位數字出生日期碼、3位數字順序碼和1位數字校驗碼。1—6位為地址碼，首位可取1—8中任意一個，其余5位可取0—9。7—14位為日期碼，前4位是年，后4位分別是月、日。年前兩位只能取18/19/20之一，后兩位為0—9;月是01—12;日期要考慮到2月沒有30，只到28/29。15—17位為順序碼，取0—9;18位為校驗碼，取0—9或X/x。由此得到身份證號碼的正則表達式：

（3）識別郵箱地址。郵箱地址的基本格式為“名稱@域名”。名稱部分，為了檢測的全面性，這部分允許有漢字、字母、數字。漢字用轉義字符表示，正則表達式為：

域名部分允許由字母、數字、英文句號、下劃線、中劃線組成。由此可得出識別郵箱地址的正則表達式：

（4）識別地名地址。由于地名地址的復雜和多樣性，無法通過簡單的正則表達式來完成。為此本文提出了一種簡單高效的地名地址識別方法。該方法在進行地址檢測時，首先對文檔內容以標點符號進行分句，對每個句子進行識別。其次，建立省、市、縣三級行政名稱數據庫，分別存放在省、市、縣三個文件夾下，以備算法識別時匹配使用。判斷是否是地址的標準：包含省、市、縣（區）、鄉鎮（街道）、村組、號室院路等六級地址中的三個以上，至少到鄉鎮一級且順序從大到小不亂序則判定是地址信息。

具體的方法（圖5）思路如下：

（1）查找字符串中是否包含省級名稱，定位其在字符串中的位置，用indexofProvince表示，沒匹配到記為-1，匹配到則記錄其在字符串中的位置，同時匹配成功計數count+1;市縣與此類似，在字符串中的位置分別記為indexofCity、indexofCounty。

（2）鎮或是鄉一級的地址直接按照關鍵字鎮、鄉來匹配，其在字符串中的位置記為indexofCountryside，匹配成功計數count+1;村組或院樓號室等匹配同理。

（3）判斷是否包含地址信息。count大于等于3、最后一級地址不是縣區級、六級地址中存在的幾級地址從大到小在分句中位置依次遞增，這三個條件同時滿足，才判定包含地址信息;否則不包含地址信息。

在識別出敏感信息后，系統會把該IP地址和相應的index、敏感信息的記錄一起輸出到敏感數據文件中，而正常的數據會被輸出到正常的文件中進行保存。

5? ?系統測試（System test）

5.1? ?敏感數據檢測測試

本文通過實驗對敏感檢測方法進行有效性測試。對于以正則表達式方式進行判別的手機號碼、身份證號、電子郵件這三類，檢測的數據充分考慮檢測可能遇到的各種情況（具體的情況已在前文描述），分別以50 條真實數據進行測試，檢測結果是100%識別出了對應的敏感信息。地名地址的種類比較多，本文為了隨機抽取全國各地的標準地址，測試地址由100 個211高校地址、50 個各地醫院地址、50 個酒店飯店地址組成，基本涵蓋了各種類型的標準地址。檢測結果為成功檢測192 個，未成功檢測8 個。四類檢測算法的準確率如表2所示。

地名地址中檢測未成功的地址分為以下四類：（1）市—縣—路—學校名（學校名字中有省名）導致不能識別。例如：鄭州市鄭東新區金水路與博學路交叉口龍子湖高校園區河南中醫學院。（2）省—市—縣—路—號（市名中含有鎮、鄉、村、院、路等關鍵字），導致不能識別。例如：河南省新鄉市牧野區建設路東段46號。例中新鄉市含“鄉”字。（3）未達到三個地址級別的判定條件。例如：鄭州市中原路與大學路交叉口西100米路南黃河飯店。例中只有市和路兩級，算法中未涉及交叉路口的情況。（4）由于中文斷句分詞的誤識別導致把地址方位詞識別成省名。例如：青島市黃島區長江西路66號。算法在長江西路中識別出“江西”這個省名，導致未能準確識別出地址信息。

在誤檢測方面，手機號碼、電子郵件、身份證號檢測分別對容易誤識別的數字串、字符串等各50 條進行識別。手機號碼因為如12015700230034112一段數字串里包含類似手機號的數字15700230034，被誤識別。身份證號的誤檢測也存在類似的問題。因為手機號碼和身份證號的長度是固定的，分別是11位和18位，本文在檢測前對每個數字串進行長度判斷，提前判別出不符合要求的數據，避免誤報的情況發生。電子郵件未發生誤檢測的情況。對于地址地名的誤檢測，本文采用隨機真實的數據，分別是：（1）含省、市公司名的句子100 條，如河南新野紡織股份有限公司;（2）只含省-市-縣三級的地址名50 條，如浙江杭州市江干區;（3）易誤識別的文段50 條，如北京中關村軟件園等。檢測結果均能準確識別為非地名地址，未發生誤報的情況。

總體來說，本文設計的敏感檢測方法簡便快捷，準確率在96%以上。

5.2? ?總體功能測試

使用搜索網絡空間在線設備的專用搜索引擎Shodan搜索關鍵字Elastic，得到全球在線Elastic設備共26，763 個，在中國的有9，731 個。統計記錄下在中國的IP后，作為輸入數據進行探測，未輸入賬號密碼就可以獲取到相關的數據即存在安全風險。在數據檢測部分檢測出敏感信息，則設置為高風險預警;若沒有檢測出敏感信息，則設置為低風險預警。

經過上述過程探測得到數據，并對數據進行分析，得到存在Elastic漏洞地區分布統計如表3所示。由探測的結果可知，廣東、北京、浙江、上海等地區存在風險的Elastic數據庫數量最多。未知地區的Elastic數據庫大多是云服務提供商所有的數據庫。測試用的9，731 個Elastic數據庫中存在風險的共有9，665 個，全國各個省（自治區、直轄市）均有分布。測試結果說明系統各功能已實現。

6? ?結論（Conclusion）

Elastic數據庫作為當前主流NoSQL數據庫之一，提供的Elasticsearch搜索引擎是流行的企業搜索引擎，廣泛應用于分布式文檔存儲和搜索服務。Elastic需要收費軟件X-pack進行安全配置。本文設計實現的Elastic數據庫風險感知系統，從主動探測的角度出發，運用簡單的URL請求即可批量判斷目的IP主機上是否存在未進行安全配置的Elastic數據庫，同時通過對抓取數據的敏感性檢測，實現了數據庫風險高低的評估和預警以及對Elastic數據庫的風險感知能力。

參考文獻（References）

[1] 陳忠菊.NoSQL數據庫的研究和應用[J].電腦編程技巧與維護，2020（09）：81-83.

[2] 唐婷.大數據環境下NoSQL數據庫技術[J].信息與電腦（理論版），2019（15）：142-144.

[3] 郎云海.大數據下的NoSQL數據庫安全策略的改進[J].通訊世界，2019，26（08）：29-30.

[4] 楊文杰，倪平波，宋衛平，等.基于Elasticsearch服務化的探究[J].科技資訊，2020，18（24）：64-65;68.

[5] Shodan. Shodan官網[EB/OL].[2020-05-12].https：//www.shodan.io/.

[6] Ruoyu Wang， Daniel Sun， Guoqiang Li， et al. Pipeline provenance for cloud-based big data analytics[J]. Special Issue： Software Tools and Techniques for Fog and Edge Computing， 2020，50（5）：658-674.

[7] Neel Shah， Darryl Willick， Vijay Mago. A framework for social media data analytics using Elasticsearch and Kibana[EB/OL].[2018-12-11]. https：//link.springer.com/article/10.1007/s11276-018-01896-2.

[8] 唐曦文.多線程在儀器控制軟件設計中的研究與應用[J].航空精密制造技術，2020，56（04）：23-25;32.

[9] 夏夢迎，武櫻楠，侯家成，等.基于Linux Qt的動力集中動車組顯示屏設計及實現[J].鐵道機車與動車，2020（01）：18-20;35;5.

作者簡介：

孫偉明（1993-），男，碩士生.研究領域：軟件設計，網絡安全.

張華熊（1971-），男，博士，教授.研究領域：軟件設計，網絡安全.