安全防護系統構設計與實踐

0x01 概要

本篇是關於，構建安全防護與大資料日誌分析系統的一篇實踐文章，我們想發現系統中的威脅和異常行為，就要構建安全系統，來定義和分析什麼是業務的異常，安全演算法和策略是思想，而思想需要載體來落地實現，讓威脅行為可以浮出水面。為此目地，我們建立各種安全系統，並在系統間建立聯絡。在業務系統的外圍，加上圍牆、加上護城河、加上哨卡，風險來時，起烽煙，點戰火。系統也如人一樣，用眼去看，耳去聽，大腦去思考。 

防護系統和業務系統之間的互動關係，我們分為下圖幾種。

第一種方式： 拿到業務系統相同的流量，威脅蘊藏在正常流量中，給業務系統同時，防護系統也複製到一份，比如，核心路由分光，WAF等系統。

第二種方式： 拿到業務相關有價值的日誌，日誌標記了業務關鍵的資料，日誌中標記了正常的資料，也記載了威脅行為的存在。比如，日誌收集系統，大資料智慧分析系統。

第三種方式： 系統嵌入到被保護業務的相同平臺上，監控所在平臺的狀態。比如：各種系統Agent和資料代理Agent。

第四種方式： 通過主動發起應答互動，來判斷業務系統特定輸入的輸出是否正常。比如：Zabbix WEB監控，主動掃描，埠掃描。

下面介紹的各種系統，覆蓋了大多數的互動方式，我們就是通過構建不同的安全系統，並建立其聯絡，進行安全防護的，分為以下幾個具體的流程例子：

1. 雲WAF威脅防護：流量串並連線同時存在。

2. 雲WAF系統構成解析：一種系統的多種形態。

3. 安全閘道器案例實踐：資料聚合系統的門戶。

4. 負載均衡與自動運維：服務質量和安全同樣重要。

5. 埠掃描與日誌分析匯聚：主動發起探測互動感官觸角。

6. Agent與大資料聚合：面對異構系統日誌的複雜性。

7. 日誌系統資料遷移：讓數據流動的更順暢。

8. 日誌監聽與威脅分析：威脅就隱藏在資料中。

9. CH大資料系統日誌接入：舉個栗子。

0x02 雲WAF威脅防護：流量串並連線同時存在

WEB系統最常用的防護方式就是使用WAF，WAF有多種形態，有基於流量和規則定義的軟WAF，也有基本流量分光日誌落地，基於大資料分析的防護系統。下圖我們初期構建的WAF形態，雲WAF。關於雲WAF有一個常見的議題是，基於集中日誌分析的WAF方案好，還是基於實時流量規則攔截的雲WAF比較好? 兩種WAF各有所長，排除效能的差異，基於流量分析的WAF可以實施更具體的攔截措施，如，針對POST請求的過濾，針對cookie注入的攔截等，實時攔截有其好處，基於大資料演算法統計分析系統的方案，可以更好的溯源和發現群體性攻擊。

隨著技術的演進，突破了常見序列或是並接的連線方式，可以直接串接流量的現時，並接流量實時分析。爲了可以加長威脅判斷的生命週期，一般同時採用基於流量分析和日誌分析的兩種結合方式的WAF防護。因為採用了，基於流量映象WAF同時將WAF和蜜罐關聯協同，更好的收集威脅情報，具體的實施策略可能每家公司的方案都不太一樣。

對WAF系統來說，WEB日誌同質化，而對於內網環境來說，日誌的形態各種和樣，採用一種好的日誌收集組織形式，更能有效組織起資料，上面的圖，真正的把日誌收集邏輯化，概念化，就有了Stream和Input這種高抽象的定義。落實到實際上，logstash、filebeat、nxlog、syslog、flume各種形式的收集都可以存在。

0x03 雲WAF系統構成解析：一種系統的多種形態

有了WAF系統和日誌分析系統，我們自然的就會想到如何將這兩種系統協同工作，既複製了實時流量進行檢測，又將日誌落進行日誌分析。

對於基於流量規則的WAF系統，白名單和黑名單的建立是一個比較常用的場景，最常見的黑白名單就是IP地址的黑白名單。對於WAF的規則系統來說，是否可以有效的攔截，取決於規則的條目，但任何系統都是有特定的服務內容，對於人制定的規則都不一定會覆蓋所有的異常情況，對於通用威脅的WAF規則可以通用，XSS注放，SQL注入。但是針對PHP系統來說，有些Python的系統問題，對PHP來說並不一定存在。如何彌補人為規則覆蓋不完的問題，開啟了黑白名單的另一個思路。

因此，我們可以根據特定的業務，經過一定時間的資料沉澱，來聚類出系統的白名單正常行為，這樣可以都明顯屬於白名單的請求不進行規則判斷，或是修改攔截流程。這種自動化的白名單匯聚是有前提的，白名單是針對特定業務的，業務越複雜匯聚的週期越長，準確性也是和時間成本成正比，並且用人為輔助確認的方式，再確認自動生成的白名單是否不會誤傷請求。這種白名單可以提供異常檢查的效率，對於真正正常的請求給予放行，不再耗時進行異常檢查。

我們現在可以很方便的基於Openresty這種開源專案，建立WAF專案，可以是用Lua寫的，也可以是用C的，採用多種語言可更好靈活性的實現複雜的特性。

對於WAF的使用者來說，幾乎請求中的HTTP資料都是可見的，只是在傳遞到真正的業務系統前，對業務系統將要處理的資料進行初期檢查。異常威脅定義是用DSL或是JSON規則定義，發現請求中的問題。同時，也可以用Lua動態的實現安全策略，比如業務上游切換，同樣用C和Lua都能實現。

對於WAF來說，攔截異常請求是本職工作。但如果很明顯的讓人看出來是一個WAF系統，就很容易的被集中試探繞過。

怎麼辦，所以基於串並同聯的部署方案，我們除了將流量型WAF日誌接入日誌分析系統外，將蜜罐也引入系統聯合使用，收集威脅情報，變成了安全系統與安全系統之間發生協作關聯。當我們明確的識別了請求是客戶的攻擊探測，我們可以將請求引入一個蜜罐系統，並將黑客的攻擊手法記錄下來，集少成多，形成自己的威脅情報庫。

0x04 安全閘道器案例實踐：資料聚合系統的門戶

基於Openresty+Nginx基礎的軟體，提供了多種可能攔截設定，在日常應用了，即使不用其開發一個完整WAF的功能，也可以用其代理的功能，作為一個安全防護閘道器使用，也可以作為一個數據查詢代理人的功能。將日誌收集到日誌容器儲存中，只是作為起始的第一步。爲了資料可以被方便的檢索，實現策略程式碼的高生產性，我們在基礎ES的API上，加入高一層的抽象，在對外提供資料查詢介面時，隱藏原始的索引等裸開源元素的一些概念。

通過提供這麼一套，高度貼合業務的資料閘道器，提供便利的查詢介面，讓程式驅動資料更方便，讓策略落體更容易，這樣我們可儘量的減少冗餘的程式碼量，集中經歷實現我們策略直接相關的內容。

Syslog可以基於UDP協議快速的將業務系統的日誌，集中心傳送給日誌收集中心，syslog在落地本地文字同時，在ES複製一份日誌資料。Splunk、Graylog、ELK這些工具，可快速的查詢原本散落在各個獨立服務應用上的日誌，集中到ES後，集中查詢，這也構成了日誌系統的基礎工作模式。有了syslog和ES的日誌資料中心，纔有了資料中心提供API查詢，才演化出了分析模組，大螢幕可視系統，預警系統，則不只是各種純文字日誌的簡單集合。

0x05 負載均衡與自動運維：服務質量和安全同樣重要

我們在構建安全防護系統時，要考慮被防護系統基本的系統結構，如果我們的系統不能與被防護系統很好的融合，是無法落體實施的。

LVS是分擔了原本發一臺機器的流量，分散給多臺機器同時處理，是提高系統響應時間的最常用的系統結構。通過智慧域名線路選擇解析，NAT、DR等負載均衡方式，不同的模式，會影響日誌收集中的具體關聯欄位。同一種系統結構，會有不同的防護系統部署方案，區別體現在部署成本的不同。正因為有這種因果聯絡，我們爲了日誌分析，在選擇負載均衡方式時，也是要考量的。

明確了系統結構，找到影響業務正常運轉的關鍵點，在關鍵點部署監控。

系統安全同時，也要保證系統服務的正常，所我們不僅僅要關注安全問題，同樣不能拋開業務質量，基於負載均衡的系統，我們不僅僅要探活主要服務本身，還要監控服務所依賴的上下連服務。這就是我們所面臨的，將服務質量和安全結合在一起考慮。

監控只是自動化運維的觸角，我們通過監控業務服務的本身狀態，和相關服務態，來自動變更業務配置，通過改變服務的狀態，切換安全等級，當外部發生異常時，做降級，當外部服務恢復時，做自動升級，不需要人蔘與切換。

0x06 埠掃描與日誌分析匯聚：主動發起探測互動感官觸角

日誌系統通過閱讀業務系統的日誌發現問題，是一種被動接受資料推送的過程。 針對某些場景，我們嘗試主動與系統互動，收集相關資料，埠掃描適用這種場景。我們通過掃描程式，收集內網伺服器埠資料，形成指紋，然後通過對這些資料進行聚合，發現數據的變化和異常，構建數據結構和異常鑑別模型直接影響探測效果。

關於指紋採集儲存與指紋儲存，我們開始時採用了ES的儲存方案， 有版本控制，之後採用了Clickhouse儲存方案，使用SQL做後期資料聚合發現異常量的突變。

在實際的儲存過程中，資料的邏輯關係不變，IP和PORT作為基礎屬性，關聯附加機房資訊，業務資訊，服務型別，負責人等資訊，更準確的定位，異常發生的具體位置。

圖只是簡單的示意，最具體的邏輯展現，是通過SQL或 抽象化的程式碼邏輯流程。關於聚合具體演算法，完全可以另開一文介紹。這裏只是展現了一個基本的處理思路。

視覺化是威脅現展現的一種手段，現在很流行，但有時，某些圖的裝飾意義可能會大於實際使用的意義，但是，我們還是可以通過桑吉圖或是埠IP關聯圖，展示埠的變化異常趨勢。讓視覺化圖表真正的起到有價值的作用。

0x07 Agent與大資料聚合：面對異構系統日誌的複雜性

對網站型業務來說，日誌形式相對單一，而實際的過程中，我們不可能只是單純收集nginx服務日誌。我們需要一種更高階的日誌模式，可以把零散的工作，概念化，把資料的匯聚模式化。

ES儲存模式是現在普遍被認可的方案：爲了更集中業務數據處理，使用Graylog這種開源的軟體，用更高階抽象出Stream的方案，把index管理等底層工作交給Graylog，把時間和索引，封裝到Stream裡。基於Stream，Graylog提供了資料API暴露方案。

當Graylog和ES為容器的方案，不能滿足我們某些場景的需求時，我們把資料引入到Clickhouse，在這個過程中,Kafka起到了一般佇列服務應該起動的典型作用。在資料儲存和實時分析方面，才用什麼樣的方案才能達到理想的效果，要根據具體的業務量和系統規模而定，ClickHouse是獨立於Hadoop這種生態的大資料解決方案，我們基於Clichouse模式的實踐也是一個漸進發展的過程。

基於ClickHouse我們針對不同的資料來源，進行各種視覺化資料匯聚。從這個階段開始，我們將資料，每日的變化以威脅日報的形式，郵件傳送出來，我們相關於每天都可以視覺化的看到內網的威脅充數化趨勢。面對每天的海量威脅日誌，匯聚只是工作的開始，自動化安全的運維的關鍵是，我們利用這些軟件系統，自動自發的發現威脅，纔是我們構建自動化安全系統初衷。

0x08 日誌系統資料遷移：讓數據流動的更順暢

Clickhouse是一個高效能的資料，我們的系統中，可能會存在多種的資料聚合方案，我們需要逐步的將各種資料來源資料，遷入到Clickhouse中，對於要放ES中的資料，我們在syslog接收時，就將資料直接轉放到kafka中，這樣實現一個同資料來源，同時存到ES和Clickhouse中。基於開源軟體的另一個好處時，社羣提供了大量的現成外掛，讓同樣場景的問題，直接用前人的工作成果，就可以輕鬆完成。

0x09 日誌監聽與威脅分析：威脅就隱藏在資料中

我們匯聚了日誌、構建資料API，視覺化展現、整個安全信息系統的實現，只要通過自動化的技術手段，尋找在日常流量和日誌中，隱藏異常攻擊。我們如何收集、如何發現、如何展現威脅的方式，決定了是否可以有效的發現威脅。

對於複雜的運營環境來說，資料來源是多樣性的，資料可以來之針對流量的協議解析資料，可以來至裝置的日誌資料，可以來至WEB服務的日誌資料，各式各樣。對於儲存我們可以放到ES、mysql、Graylo、Clickhouse中。

資料集中後，我們就可以過濾清洗資料，打標記，單純收集資料，只是將資料方便的集中到了一起，遷移資料簡單，可以讓我們有更多的選擇各種資料庫的匯聚生態，歸到本質，無論是WAF系統還是日誌系統，對威脅的定義都是由安全運維人員來制定的，我們發擬定多層次的異常判斷手段。

我們引入了SQL Injection，引入各種語言，語義語法的檢查，實時的發現PHP注入掛馬問題，同時聯動程式碼審計系統，發現類似的問題。一個庫的背後凝聚了一種判斷威脅思想，而面對海量的威脅資料，如論是基於規則，還是基於大資料，還是基於第三方庫，都很難有一勞永逸的方案，可以解決掉所有威脅的發現。業務軟體會隨著需求更新程式碼，就有衍生出新的漏洞或是攻擊手段，威脅也是在動態變化中，於對資料聚合系統數據流流向，系統構成的抽象層面，越抽象越類似，但具體的落地方案實施每一家都是不一樣的，設計不一樣，實施不一樣，效果各有異同。

當基礎資料信息系統建成，就要建立安全策略判別系統，這也是為什麼現在有很多公司建立了自己的演算法團隊。之前的系統設計集中的是軟體工程相關的問題，要提高策略模組實現規模化，程式碼生產效率，使用外掛化分析系統，將策略異常分析模組工廠化，切片化，而具體到每一個外掛內部的實現就是演算法問題，是系統的大腦。

0x10 CH大資料系統日誌接入：舉個栗子

下面是一個實際的閘道器專案，是一個代理程式，也可以理解成一個只有特定攔截功能，基於裝置白名單配置的代理接入系統。

是域名解析和LVS切片展示方案。

我們將系統層次中，產生日誌資料的部分，部署資料收集點，通過syslog、kafka、graylog、Clickhouse的結合使用，同時做到流量分析和日誌威脅分析，資料匯聚，視覺化在一個流程例項中完成。

加入威脅判定的邏輯後，威脅資訊會隨著資料的產生，每天產出威脅情報。

總體上，我們將自動化威脅判定分成幾個階段：

第一階段： 構建第一層的異常定義策略。

第二階段：對黑盒判斷裝置的威脅報告結論進行再確認。

第三階段：關聯確認威脅，多點確認相對威脅。

第四階段：針對特定威脅進行攻擊重放。

第五階段：人工確認。

以上，除了第五，都是自動化分析系統要達成或是已達成的功能，栗子可以放下了。

宣告：本文來自新浪安全中心，版權歸作者所有。文章內容僅代表作者獨立觀點，不代表安全內參立場，轉載目的在於傳遞更多資訊。如需轉載，請聯絡原作者獲取授權。