如何用開源工具搭建態(tài)勢(shì)感知系統(tǒng)：從數(shù)據(jù)采集到關(guān)聯(lián)分析實(shí)戰(zhàn))
1. 從零理解態(tài)勢(shì)感知它到底在解決什么安全困境很多剛接觸企業(yè)安全建設(shè)的朋友第一次聽到“態(tài)勢(shì)感知系統(tǒng)”這個(gè)詞腦子里浮現(xiàn)的往往是科幻電影里那種巨大的屏幕墻上面閃爍著世界地圖和各種攻擊線路。但真到自己動(dòng)手搭建時(shí)反而不知道從哪下手。我在過去幾年里幫幾家中小型公司做過安全體系落地發(fā)現(xiàn)一個(gè)很普遍的現(xiàn)象大家買了不少安全設(shè)備防火墻、入侵檢測(cè)、日志審計(jì)都有可一旦出了安全事件排查起來還是靠人肉登錄各臺(tái)設(shè)備翻日志效率極低而且經(jīng)常漏掉關(guān)鍵線索。態(tài)勢(shì)感知系統(tǒng)要解決的核心問題就是把這些分散的安全數(shù)據(jù)統(tǒng)一采集、關(guān)聯(lián)分析、可視化呈現(xiàn)讓你能“看見”網(wǎng)絡(luò)上正在發(fā)生什么。它不是一個(gè)單一的產(chǎn)品而是一套體系包含數(shù)據(jù)采集層、數(shù)據(jù)處理層、分析檢測(cè)層和展示層。對(duì)于預(yù)算有限的中小企業(yè)來說完全基于開源軟件來搭建一套可用的態(tài)勢(shì)感知系統(tǒng)是一條性價(jià)比極高的路徑。這篇文章面向的是有一定Linux基礎(chǔ)、了解基本網(wǎng)絡(luò)概念的安全運(yùn)維人員或技術(shù)負(fù)責(zé)人。我會(huì)從架構(gòu)設(shè)計(jì)、開源工具選型、數(shù)據(jù)采集與解析、關(guān)聯(lián)分析規(guī)則編寫、可視化展示這幾個(gè)維度把整個(gè)建設(shè)過程拆開來講。你不需要有大數(shù)據(jù)背景也不需要采購昂貴的商業(yè)方案跟著思路走就能搭建出一套能實(shí)際運(yùn)轉(zhuǎn)的態(tài)勢(shì)感知系統(tǒng)。在展開具體操作之前先明確一個(gè)認(rèn)知態(tài)勢(shì)感知的價(jià)值不在于“大而全”而在于“準(zhǔn)而快”。你不需要一開始就采集所有類型的日志也不需要追求花哨的3D可視化效果。先把最核心的幾類數(shù)據(jù)接進(jìn)來把最關(guān)鍵的幾個(gè)告警場(chǎng)景跑通讓系統(tǒng)能真正幫你發(fā)現(xiàn)和定位問題這比什么都重要。我見過太多項(xiàng)目一開始貪大求全最后因?yàn)閿?shù)據(jù)量太大、規(guī)則太復(fù)雜系統(tǒng)跑不動(dòng)維護(hù)成本高最終淪為擺設(shè)。2. 開源技術(shù)棧選型為什么是這幾款工具的組合2.1 數(shù)據(jù)采集層的選型邏輯與對(duì)比數(shù)據(jù)采集是整個(gè)態(tài)勢(shì)感知系統(tǒng)的地基。采集層要解決三個(gè)問題從哪里采、怎么采、采完之后怎么傳。常見的開源采集工具主要有Filebeat、Fluentd、Logstash和Vector這幾款。我在不同規(guī)模的項(xiàng)目里都用過下面說說我的選型思路。Filebeat是Elastic公司出品的輕量級(jí)日志采集器用Go語言編寫資源占用極低部署在業(yè)務(wù)服務(wù)器上幾乎感覺不到它的存在。它原生支持多行日志合并、字段添加、TLS加密傳輸配置也相對(duì)簡(jiǎn)單。如果你的日志源主要是文本文件Filebeat是首選。我實(shí)測(cè)過在一臺(tái)4核8G的服務(wù)器上Filebeat處理每秒上萬條日志時(shí)CPU占用不到5%。Logstash功能最強(qiáng)大支持豐富的輸入、過濾、輸出插件但它是JVM應(yīng)用內(nèi)存占用高啟動(dòng)慢不適合部署在每臺(tái)業(yè)務(wù)服務(wù)器上。我的做法是在每臺(tái)業(yè)務(wù)機(jī)上部署Filebeat做采集然后統(tǒng)一發(fā)送到一臺(tái)中心Logstash做二次解析和富化。這樣既保證了采集端的輕量又利用了Logstash強(qiáng)大的處理能力。Fluentd在容器化環(huán)境中用得比較多它的插件生態(tài)也很豐富但配置語法對(duì)新手不太友好。Vector是后起之秀性能極佳配置簡(jiǎn)潔但目前社區(qū)生態(tài)還不如前兩者成熟。綜合來看對(duì)于中小企業(yè)內(nèi)網(wǎng)環(huán)境Filebeat加Logstash的組合是最穩(wěn)妥的選擇。工具語言資源占用配置復(fù)雜度適用場(chǎng)景FilebeatGo極低低業(yè)務(wù)服務(wù)器日志采集LogstashJRuby高中中心化日志解析與富化FluentdRuby/C中中高容器環(huán)境日志采集VectorRust低低高性能采集場(chǎng)景2.2 數(shù)據(jù)存儲(chǔ)與檢索引擎的取舍采集到的數(shù)據(jù)往哪里存直接決定了后續(xù)分析的靈活性和查詢速度。目前開源領(lǐng)域主流的選擇是Elasticsearch、ClickHouse和OpenSearch。Elasticsearch是ELK棧的核心全文檢索能力強(qiáng)與Logstash、Kibana無縫集成生態(tài)最成熟。但它的資源消耗也不小尤其是內(nèi)存官方建議至少分配32G堆內(nèi)存給生產(chǎn)環(huán)境。對(duì)于中小企業(yè)如果日志量每天在幾十GB以內(nèi)單節(jié)點(diǎn)16G堆內(nèi)存也能跑起來但要做好索引生命周期管理定期清理舊數(shù)據(jù)。ClickHouse是列式存儲(chǔ)數(shù)據(jù)庫寫入和查詢速度極快特別適合做大規(guī)模日志的聚合分析。但它不擅長全文檢索而且運(yùn)維復(fù)雜度比Elasticsearch高。OpenSearch是Elasticsearch的一個(gè)分支功能基本一致但許可證更寬松。我的建議是如果你團(tuán)隊(duì)里沒有專門的搜索運(yùn)維人員優(yōu)先選Elasticsearch或OpenSearch因?yàn)橘Y料多、社區(qū)活躍遇到問題容易找到答案。存儲(chǔ)容量規(guī)劃有個(gè)簡(jiǎn)單的估算方法假設(shè)每天產(chǎn)生20GB原始日志Elasticsearch默認(rèn)副本數(shù)為1加上索引開銷實(shí)際占用約60GB。保留30天的話需要準(zhǔn)備約1.8TB的磁盤空間。你可以根據(jù)這個(gè)公式來規(guī)劃硬件。2.3 分析與告警組件的搭配策略數(shù)據(jù)存下來之后怎么從中發(fā)現(xiàn)異常這是態(tài)勢(shì)感知的核心價(jià)值所在。開源方案里Elasticsearch自帶的Watcher可以做一些簡(jiǎn)單的閾值告警但功能有限。更靈活的做法是用ElastAlert2它專門為Elasticsearch設(shè)計(jì)支持多種告警規(guī)則類型比如頻率告警、尖峰告警、基數(shù)告警等配置用YAML文件上手快。如果你需要更復(fù)雜的關(guān)聯(lián)分析比如把防火墻日志和主機(jī)日志關(guān)聯(lián)起來判斷是否發(fā)生了橫向移動(dòng)那就需要引入規(guī)則引擎。Sigma是一種通用的告警規(guī)則描述格式你可以用Sigma規(guī)則定義檢測(cè)邏輯然后用sigmac工具轉(zhuǎn)換成Elasticsearch查詢語句。這樣規(guī)則可以跨平臺(tái)復(fù)用不會(huì)被某個(gè)廠商鎖定。對(duì)于實(shí)時(shí)性要求極高的場(chǎng)景比如檢測(cè)暴力破解可以用Suricata做網(wǎng)絡(luò)流量檢測(cè)它基于規(guī)則匹配能實(shí)時(shí)發(fā)現(xiàn)異常流量并生成告警。Suricata的規(guī)則集可以定期從開源情報(bào)源更新保持對(duì)最新威脅的檢測(cè)能力。3. 數(shù)據(jù)采集與解析的實(shí)操細(xì)節(jié)3.1 Filebeat配置中的關(guān)鍵參數(shù)與避坑點(diǎn)Filebeat的配置文件是YAML格式結(jié)構(gòu)清晰但有幾個(gè)參數(shù)如果配錯(cuò)了會(huì)導(dǎo)致日志丟失或重復(fù)。先看一個(gè)典型的輸入配置filebeat.inputs: - type: log enabled: true paths: - /var/log/nginx/access.log fields: log_type: nginx_access environment: production fields_under_root: true multiline.pattern: ^\d{4}-\d{2}-\d{2} multiline.negate: true multiline.match: after ignore_older: 24h scan_frequency: 10s harvester_limit: 100這里有幾個(gè)參數(shù)值得展開說。fields_under_root: true這個(gè)設(shè)置很重要它把自定義字段提升到事件頂層而不是嵌套在fields子字段下。這樣在Elasticsearch里做查詢和聚合時(shí)更方便比如可以直接用log_type: nginx_access來過濾而不需要寫fields.log_type。multiline配置用于合并多行日志比如Java異常堆棧。pattern指定新日志行的起始特征negate: true表示不匹配該模式的行match: after表示把這些行合并到上一行后面。這個(gè)配置如果寫錯(cuò)了日志會(huì)被拆得七零八落后續(xù)分析根本沒法用。我踩過的坑是pattern里的正則沒有轉(zhuǎn)義反斜杠導(dǎo)致匹配失敗所有多行日志都被當(dāng)成獨(dú)立事件發(fā)送在Kibana里看就是一堆碎片。ignore_older: 24h告訴Filebeat只采集24小時(shí)內(nèi)修改過的文件避免啟動(dòng)時(shí)把歷史歸檔日志全部重新讀一遍。scan_frequency控制掃描新文件的頻率默認(rèn)10秒如果日志目錄文件很多可以適當(dāng)調(diào)大減少IO壓力。harvester_limit限制同時(shí)打開的采集器數(shù)量防止文件句柄耗盡。注意Filebeat的注冊(cè)表文件默認(rèn)在/var/lib/filebeat/registry它記錄了每個(gè)文件的采集進(jìn)度。如果你刪除了這個(gè)文件Filebeat會(huì)認(rèn)為所有文件都是新的從頭開始采集可能導(dǎo)致大量重復(fù)數(shù)據(jù)。遷移或重裝時(shí)一定要備份這個(gè)目錄。3.2 Logstash管道配置的解析技巧Logstash的管道配置分為input、filter、output三段。input段接收Filebeat發(fā)來的數(shù)據(jù)filter段做解析和富化output段寫入Elasticsearch。下面是一個(gè)處理Nginx訪問日志的典型配置input { beats { port 5044 ssl false } } filter { if [log_type] nginx_access { grok { match { message %{IPORHOST:client_ip} - %{DATA:remote_user} \[%{HTTPDATE:timestamp}\] %{WORD:http_method} %{DATA:request_uri} HTTP/%{NUMBER:http_version} %{NUMBER:status_code} %{NUMBER:body_bytes_sent} %{DATA:referrer} %{DATA:user_agent} } remove_field [message] } date { match [timestamp, dd/MMM/yyyy:HH:mm:ss Z] target timestamp } geoip { source client_ip target geo } mutate { convert { status_code integer body_bytes_sent integer } } } } output { elasticsearch { hosts [http://localhost:9200] index nginx-access-%{YYYY.MM.dd} user elastic password your_password } }Grok正則的編寫是Logstash使用中最容易出問題的地方。我的經(jīng)驗(yàn)是先在Kibana的Dev Tools里用Grok Debugger測(cè)試正則確認(rèn)能正確匹配后再寫入配置文件。另外remove_field [message]這步很重要原始日志內(nèi)容解析完之后就沒用了留在索引里白白占用空間。GeoIP插件可以根據(jù)客戶端IP解析出地理位置信息對(duì)于分析異常登錄來源很有幫助。但要注意內(nèi)網(wǎng)IP解析出來是空的可以在配置里加個(gè)判斷只對(duì)公網(wǎng)IP做GeoIP解析。日期解析也是關(guān)鍵一步。Nginx日志里的時(shí)間戳格式和Logstash默認(rèn)的timestamp不一樣必須用date插件轉(zhuǎn)換否則在Kibana里按時(shí)間過濾會(huì)出錯(cuò)。target timestamp表示把解析出來的時(shí)間覆蓋到事件的主時(shí)間戳上。3.3 解析規(guī)則的版本管理與測(cè)試方法隨著業(yè)務(wù)變化日志格式可能會(huì)調(diào)整解析規(guī)則也需要跟著改。如果沒有版本管理改錯(cuò)了很難回滾。我的做法是把所有Logstash管道配置文件放在Git倉庫里管理每次修改都提交一次寫清楚改了什么、為什么改。測(cè)試新規(guī)則時(shí)先用一個(gè)獨(dú)立的Logstash實(shí)例跑輸入用文件模擬確認(rèn)輸出符合預(yù)期后再上線。另外建議在filter段加一個(gè)_grokparsefailure標(biāo)簽檢查。如果grok解析失敗Logstash會(huì)給事件打上這個(gè)標(biāo)簽。你可以在output段加一個(gè)條件判斷把解析失敗的事件單獨(dú)寫到一個(gè)索引里方便后續(xù)排查。output { if _grokparsefailure in [tags] { elasticsearch { hosts [http://localhost:9200] index parse-failure-%{YYYY.MM.dd} } } else { elasticsearch { hosts [http://localhost:9200] index nginx-access-%{YYYY.MM.dd} } } }這個(gè)做法幫我發(fā)現(xiàn)過好幾次日志格式變更導(dǎo)致解析失敗的問題如果沒有這個(gè)隔離機(jī)制這些事件會(huì)混在正常數(shù)據(jù)里很難察覺。4. 關(guān)聯(lián)分析與告警規(guī)則的設(shè)計(jì)思路4.1 從單點(diǎn)告警到關(guān)聯(lián)分析的進(jìn)階路徑剛開始搭建態(tài)勢(shì)感知時(shí)最容易做的就是單點(diǎn)告警比如“5分鐘內(nèi)登錄失敗超過10次就告警”。這種規(guī)則簡(jiǎn)單直接但誤報(bào)率高而且無法發(fā)現(xiàn)復(fù)雜的攻擊鏈。舉個(gè)例子攻擊者可能先在一臺(tái)機(jī)器上嘗試弱口令登錄失敗幾次后換一臺(tái)機(jī)器繼續(xù)試每臺(tái)機(jī)器上的失敗次數(shù)都不超過閾值單點(diǎn)告警根本發(fā)現(xiàn)不了。關(guān)聯(lián)分析的核心思想是把不同來源、不同時(shí)間點(diǎn)的安全事件串聯(lián)起來還原出完整的攻擊場(chǎng)景。比如你可以定義這樣一條規(guī)則如果防火墻日志顯示某IP在短時(shí)間內(nèi)掃描了多個(gè)端口同時(shí)主機(jī)日志顯示該IP嘗試了SSH登錄那就判定為一次有預(yù)謀的入侵嘗試提高告警級(jí)別。實(shí)現(xiàn)關(guān)聯(lián)分析有兩種路徑。一種是用ElastAlert2的compound規(guī)則類型它支持在一條規(guī)則里定義多個(gè)查詢條件只有所有條件都滿足時(shí)才觸發(fā)告警。另一種是用Elasticsearch的percolate功能把規(guī)則反過來讓規(guī)則去匹配數(shù)據(jù)流。前者配置簡(jiǎn)單適合規(guī)則數(shù)量不多的場(chǎng)景后者性能更好適合規(guī)則成百上千的情況。4.2 ElastAlert2規(guī)則編寫實(shí)戰(zhàn)ElastAlert2的規(guī)則文件是YAML格式下面是一個(gè)檢測(cè)SSH暴力破解的規(guī)則示例name: SSH Brute Force Detection type: frequency index: filebeat-* num_events: 10 timeframe: minutes: 5 filter: - term: log_type: ssh_auth - term: event.outcome: failure alert: - email - slack email: - securityexample.com slack: webhook_url: https://hooks.slack.com/services/xxx alert_text: | SSH暴力破解告警 攻擊源IP: {source_ip} 目標(biāo)主機(jī): {host_name} 失敗次數(shù): {num_hits} 時(shí)間范圍: {start_time} - {end_time}這個(gè)規(guī)則的意思是在5分鐘內(nèi)如果同一個(gè)源IP對(duì)同一臺(tái)主機(jī)的SSH登錄失敗次數(shù)達(dá)到10次就觸發(fā)告警。num_events和timeframe的組合決定了檢測(cè)的靈敏度。調(diào)得太低會(huì)誤報(bào)調(diào)得太高會(huì)漏報(bào)。我的經(jīng)驗(yàn)是先按經(jīng)驗(yàn)值設(shè)一個(gè)初始值跑一周后根據(jù)實(shí)際告警情況調(diào)整。alert_text里可以用字段占位符ElastAlert2會(huì)自動(dòng)替換成實(shí)際值。這樣告警郵件里就能直接看到攻擊源IP、目標(biāo)主機(jī)這些關(guān)鍵信息不用再登錄系統(tǒng)去查。對(duì)于關(guān)聯(lián)分析ElastAlert2支持query類型的規(guī)則可以執(zhí)行自定義的Elasticsearch查詢語句。比如下面這個(gè)規(guī)則檢測(cè)的是“同一IP在掃描端口后緊接著嘗試登錄”的行為name: Port Scan Followed by Login Attempt type: query index: filebeat-* query: | { query: { bool: { must: [ {term: {log_type: firewall}}, {term: {event.action: port_scan}} ] } } }這個(gè)查詢會(huì)找出所有端口掃描事件然后你可以在告警文本里提示安全人員去檢查同一IP是否有后續(xù)登錄行為。雖然ElastAlert2本身不直接支持跨索引關(guān)聯(lián)但你可以通過告警文本引導(dǎo)人工研判或者寫一個(gè)腳本定期跑關(guān)聯(lián)查詢。4.3 規(guī)則調(diào)優(yōu)與誤報(bào)抑制的實(shí)操經(jīng)驗(yàn)規(guī)則上線初期誤報(bào)是不可避免的。我在實(shí)際項(xiàng)目里總結(jié)了幾條調(diào)優(yōu)經(jīng)驗(yàn)。第一給規(guī)則加白名單。比如內(nèi)部漏洞掃描器的IP、運(yùn)維人員的跳板機(jī)IP這些正常行為不應(yīng)該觸發(fā)告警。ElastAlert2支持在filter里用must_not排除特定IP。第二設(shè)置告警聚合。如果同一條規(guī)則在短時(shí)間內(nèi)觸發(fā)多次不要每次都發(fā)郵件而是合并成一封。ElastAlert2的aggregation功能可以做到這一點(diǎn)它會(huì)把相同規(guī)則的告警合并減少告警風(fēng)暴。第三定期回顧告警記錄。我每周會(huì)花半小時(shí)看一下過去一周的告警標(biāo)記哪些是誤報(bào)、哪些是真實(shí)事件。對(duì)于誤報(bào)分析原因并調(diào)整規(guī)則對(duì)于真實(shí)事件記錄處理過程作為后續(xù)優(yōu)化的參考。這個(gè)習(xí)慣堅(jiān)持下來規(guī)則的準(zhǔn)確率會(huì)越來越高。提示不要追求零誤報(bào)。安全告警的本質(zhì)是在漏報(bào)和誤報(bào)之間找平衡。寧可多一些誤報(bào)讓安全人員去確認(rèn)也不要因?yàn)橐?guī)則太嚴(yán)導(dǎo)致漏掉真實(shí)攻擊。關(guān)鍵是建立一套快速研判和反饋的流程。5. 可視化展示與日常運(yùn)營5.1 Kibana儀表盤的設(shè)計(jì)原則Kibana是ELK棧的可視化組件用它可以做出各種圖表和儀表盤。但很多人做出來的儀表盤花里胡哨實(shí)際用起來卻找不到關(guān)鍵信息。我的設(shè)計(jì)原則是一屏之內(nèi)回答三個(gè)問題——現(xiàn)在有沒有異常、異常在哪里、異常有多嚴(yán)重。具體來說儀表盤頂部放幾個(gè)關(guān)鍵指標(biāo)卡過去24小時(shí)的總告警數(shù)、未處理告警數(shù)、高危告警數(shù)。中間放一個(gè)時(shí)間趨勢(shì)圖展示告警數(shù)量隨時(shí)間的變化能一眼看出有沒有尖峰。底部放一個(gè)表格列出最近的告警詳情包括時(shí)間、類型、源IP、目標(biāo)IP、嚴(yán)重級(jí)別。對(duì)于態(tài)勢(shì)感知場(chǎng)景地圖可視化很有價(jià)值。用Kibana的Coordinate Map或Region Map可以把攻擊源IP的地理位置展示出來。雖然內(nèi)網(wǎng)IP解析不出位置但公網(wǎng)攻擊源的分布能幫你判斷威脅來源的大致區(qū)域。儀表盤不要做太多三到五個(gè)就夠了。一個(gè)是總覽一個(gè)是告警詳情一個(gè)是特定場(chǎng)景的專項(xiàng)視圖比如Web攻擊分析、暴力破解分析。每個(gè)儀表盤都要有明確的使用場(chǎng)景不要為了好看而堆圖表。5.2 告警降噪與分級(jí)處理機(jī)制告警發(fā)出來之后怎么處理也很關(guān)鍵。如果所有告警都發(fā)到同一個(gè)郵箱或群組安全人員很快就會(huì)被淹沒。我的做法是分級(jí)處理低危告警只記錄到系統(tǒng)里不主動(dòng)推送中危告警發(fā)到安全團(tuán)隊(duì)的群組高危告警除了發(fā)群組還要發(fā)短信或打電話通知值班人員。分級(jí)的標(biāo)準(zhǔn)可以根據(jù)資產(chǎn)重要性和攻擊類型來定。比如針對(duì)核心數(shù)據(jù)庫服務(wù)器的暴力破解嘗試即使次數(shù)不多也應(yīng)該定為高危而針對(duì)測(cè)試環(huán)境的掃描行為可以定為低危。ElastAlert2支持在規(guī)則里設(shè)置priority字段你可以在告警輸出時(shí)根據(jù)這個(gè)字段決定通知方式。另外建議給每條告警生成一個(gè)唯一ID并記錄處理狀態(tài)。安全人員處理完一條告警后標(biāo)記為“已處理”或“誤報(bào)”。這樣后續(xù)統(tǒng)計(jì)時(shí)可以算出告警處理率和誤報(bào)率作為規(guī)則優(yōu)化的依據(jù)。5.3 數(shù)據(jù)保留策略與性能優(yōu)化態(tài)勢(shì)感知系統(tǒng)跑起來之后數(shù)據(jù)會(huì)越來越多如果不做保留策略磁盤很快就會(huì)被寫滿。Elasticsearch提供了Index Lifecycle Management功能可以自動(dòng)管理索引的生命周期。我的配置是熱數(shù)據(jù)保留7天放在SSD上保證查詢速度溫?cái)?shù)據(jù)保留30天放在大容量機(jī)械盤上超過30天的數(shù)據(jù)自動(dòng)刪除。對(duì)于特別重要的告警數(shù)據(jù)比如高危告警的原始日志可以單獨(dú)導(dǎo)出到對(duì)象存儲(chǔ)或歸檔數(shù)據(jù)庫長期保存。這樣既控制了Elasticsearch的存儲(chǔ)成本又滿足了合規(guī)審計(jì)的要求。性能優(yōu)化方面有幾個(gè)參數(shù)值得關(guān)注。Elasticsearch的refresh_interval默認(rèn)是1秒意味著每秒都會(huì)生成一個(gè)新的segment寫入性能會(huì)受影響。對(duì)于日志場(chǎng)景可以把這個(gè)值調(diào)到30秒寫入吞吐量能提升不少。number_of_shards和number_of_replicas也要根據(jù)數(shù)據(jù)量和節(jié)點(diǎn)數(shù)合理設(shè)置分片太多會(huì)增加集群管理開銷分片太少會(huì)影響查詢并行度。Logstash的pipeline.workers參數(shù)控制并行處理線程數(shù)默認(rèn)是CPU核數(shù)。如果發(fā)現(xiàn)Logstash處理有延遲可以適當(dāng)調(diào)大這個(gè)值但不要超過CPU核數(shù)的兩倍否則上下文切換反而會(huì)降低性能。6. 建設(shè)過程中容易忽略的細(xì)節(jié)與個(gè)人體會(huì)6.1 時(shí)間同步這個(gè)小事坑過不少人說出來你可能不信我在三個(gè)不同的項(xiàng)目里都遇到過因?yàn)闀r(shí)間不同步導(dǎo)致態(tài)勢(shì)感知數(shù)據(jù)錯(cuò)亂的問題。業(yè)務(wù)服務(wù)器、日志服務(wù)器、Elasticsearch節(jié)點(diǎn)如果時(shí)間不一致日志的時(shí)間戳就會(huì)對(duì)不上關(guān)聯(lián)分析根本沒法做。明明是先掃描后登錄因?yàn)闀r(shí)間偏差在系統(tǒng)里看變成了先登錄后掃描攻擊鏈完全亂了。解決辦法很簡(jiǎn)單所有服務(wù)器統(tǒng)一配置NTP時(shí)間同步指向同一個(gè)內(nèi)網(wǎng)時(shí)間源。配置完之后用chronyc sources或ntpq -p檢查同步狀態(tài)確保偏差在毫秒級(jí)。這個(gè)事看起來不起眼但它是態(tài)勢(shì)感知系統(tǒng)能正常工作的前提。6.2 日志質(zhì)量比日志數(shù)量更重要?jiǎng)傞_始做的時(shí)候我總想著多接幾種日志覺得數(shù)據(jù)越多分析越準(zhǔn)。后來發(fā)現(xiàn)如果日志本身質(zhì)量不高比如格式不統(tǒng)一、關(guān)鍵字段缺失、時(shí)間戳不準(zhǔn)確接進(jìn)來反而是負(fù)擔(dān)。解析規(guī)則要寫一大堆查詢速度還被拖慢。后來我調(diào)整了策略先把最核心的兩三類日志接好確保解析準(zhǔn)確、字段完整、時(shí)間戳正確。比如Nginx訪問日志、SSH登錄日志、防火墻會(huì)話日志這三類覆蓋了大部分常見的攻擊場(chǎng)景。等這套跑順了再逐步擴(kuò)展其他日志源。寧可少而精不要多而雜。6.3 安全運(yùn)營是持續(xù)過程不是一錘子買賣態(tài)勢(shì)感知系統(tǒng)上線只是開始后續(xù)的運(yùn)營才是重頭戲。我見過一些團(tuán)隊(duì)系統(tǒng)搭好之后就不管了規(guī)則從來不更新告警從來不處理儀表盤從來不看。這樣的系統(tǒng)跟沒有沒什么區(qū)別。我的建議是把安全運(yùn)營納入日常工作計(jì)劃。每天花15分鐘看一下告警面板處理一下未讀告警每周花半小時(shí)回顧一下告警記錄調(diào)整誤報(bào)規(guī)則每月做一次規(guī)則和儀表盤的全面檢查根據(jù)業(yè)務(wù)變化更新配置。這些工作看起來瑣碎但堅(jiān)持下來系統(tǒng)的價(jià)值會(huì)越來越明顯。還有一點(diǎn)安全規(guī)則要跟著威脅形勢(shì)更新。比如出現(xiàn)了新的漏洞攻擊者開始利用你就需要及時(shí)添加對(duì)應(yīng)的檢測(cè)規(guī)則?？梢躁P(guān)注一些開源情報(bào)源定期獲取最新的檢測(cè)規(guī)則轉(zhuǎn)換成Sigma或ElastAlert2格式導(dǎo)入系統(tǒng)。6.4 團(tuán)隊(duì)協(xié)作與知識(shí)沉淀態(tài)勢(shì)感知系統(tǒng)不是一個(gè)人能玩轉(zhuǎn)的。采集配置、解析規(guī)則、告警規(guī)則、儀表盤這些都需要有人維護(hù)。如果只有一個(gè)人負(fù)責(zé)一旦他請(qǐng)假或離職系統(tǒng)就可能停擺。所以從一開始就要做好知識(shí)沉淀把配置文件的用途、規(guī)則的邏輯、常見問題的處理方法都寫成文檔放在團(tuán)隊(duì)共享的地方。另外建議建立值班制度。安全告警需要有人及時(shí)響應(yīng)不能等上班了再看?？梢园才泡喼得總€(gè)人負(fù)責(zé)一段時(shí)間內(nèi)的告警處理。處理完之后在群里同步一下情況讓其他人也知道發(fā)生了什么。這樣既保證了響應(yīng)速度也促進(jìn)了團(tuán)隊(duì)的安全意識(shí)提升。我在實(shí)際項(xiàng)目里還發(fā)現(xiàn)一個(gè)有用的做法定期做模擬攻擊演練。用一些開源的攻擊模擬工具在內(nèi)網(wǎng)里跑一遍看看態(tài)勢(shì)感知系統(tǒng)能不能檢測(cè)到、告警及不及時(shí)、告警信息全不全。通過演練來檢驗(yàn)系統(tǒng)的有效性比單純看規(guī)則數(shù)量更有意義。演練之后根據(jù)暴露出來的問題針對(duì)性地優(yōu)化規(guī)則和流程系統(tǒng)的實(shí)戰(zhàn)能力會(huì)提升得很快。 中小企業(yè)如何用開源工具搭建態(tài)勢(shì)感知系統(tǒng)：從數(shù)據(jù)采集到關(guān)聯(lián)分析實(shí)戰(zhàn)
1. 從零理解態(tài)勢(shì)感知它到底在解決什么安全困境很多剛接觸企業(yè)安全建設(shè)的朋友第一次聽到“態(tài)勢(shì)感知系統(tǒng)”這個(gè)詞腦子里浮現(xiàn)的往往是科幻電影里那種巨大的屏幕墻上面閃爍著世界地圖和各種攻擊線路。但真到自己動(dòng)手搭建時(shí)反而不知道從哪下手。我在過去幾年里幫幾家中小型公司做過安全體系落地發(fā)現(xiàn)一個(gè)很普遍的現(xiàn)象大家買了不少安全設(shè)備防火墻、入侵檢測(cè)、日志審計(jì)都有可一旦出了安全事件排查起來還是靠人肉登錄各臺(tái)設(shè)備翻日志效率極低而且經(jīng)常漏掉關(guān)鍵線索。態(tài)勢(shì)感知系統(tǒng)要解決的核心問題就是把這些分散的安全數(shù)據(jù)統(tǒng)一采集、關(guān)聯(lián)分析、可視化呈現(xiàn)讓你能“看見”網(wǎng)絡(luò)上正在發(fā)生什么。它不是一個(gè)單一的產(chǎn)品而是一套體系包含數(shù)據(jù)采集層、數(shù)據(jù)處理層、分析檢測(cè)層和展示層。對(duì)于預(yù)算有限的中小企業(yè)來說完全基于開源軟件來搭建一套可用的態(tài)勢(shì)感知系統(tǒng)是一條性價(jià)比極高的路徑。這篇文章面向的是有一定Linux基礎(chǔ)、了解基本網(wǎng)絡(luò)概念的安全運(yùn)維人員或技術(shù)負(fù)責(zé)人。我會(huì)從架構(gòu)設(shè)計(jì)、開源工具選型、數(shù)據(jù)采集與解析、關(guān)聯(lián)分析規(guī)則編寫、可視化展示這幾個(gè)維度把整個(gè)建設(shè)過程拆開來講。你不需要有大數(shù)據(jù)背景也不需要采購昂貴的商業(yè)方案跟著思路走就能搭建出一套能實(shí)際運(yùn)轉(zhuǎn)的態(tài)勢(shì)感知系統(tǒng)。在展開具體操作之前先明確一個(gè)認(rèn)知態(tài)勢(shì)感知的價(jià)值不在于“大而全”而在于“準(zhǔn)而快”。你不需要一開始就采集所有類型的日志也不需要追求花哨的3D可視化效果。先把最核心的幾類數(shù)據(jù)接進(jìn)來把最關(guān)鍵的幾個(gè)告警場(chǎng)景跑通讓系統(tǒng)能真正幫你發(fā)現(xiàn)和定位問題這比什么都重要。我見過太多項(xiàng)目一開始貪大求全最后因?yàn)閿?shù)據(jù)量太大、規(guī)則太復(fù)雜系統(tǒng)跑不動(dòng)維護(hù)成本高最終淪為擺設(shè)。2. 開源技術(shù)棧選型為什么是這幾款工具的組合2.1 數(shù)據(jù)采集層的選型邏輯與對(duì)比數(shù)據(jù)采集是整個(gè)態(tài)勢(shì)感知系統(tǒng)的地基。采集層要解決三個(gè)問題從哪里采、怎么采、采完之后怎么傳。常見的開源采集工具主要有Filebeat、Fluentd、Logstash和Vector這幾款。我在不同規(guī)模的項(xiàng)目里都用過下面說說我的選型思路。Filebeat是Elastic公司出品的輕量級(jí)日志采集器用Go語言編寫資源占用極低部署在業(yè)務(wù)服務(wù)器上幾乎感覺不到它的存在。它原生支持多行日志合并、字段添加、TLS加密傳輸配置也相對(duì)簡(jiǎn)單。如果你的日志源主要是文本文件Filebeat是首選。我實(shí)測(cè)過在一臺(tái)4核8G的服務(wù)器上Filebeat處理每秒上萬條日志時(shí)CPU占用不到5%。Logstash功能最強(qiáng)大支持豐富的輸入、過濾、輸出插件但它是JVM應(yīng)用內(nèi)存占用高啟動(dòng)慢不適合部署在每臺(tái)業(yè)務(wù)服務(wù)器上。我的做法是在每臺(tái)業(yè)務(wù)機(jī)上部署Filebeat做采集然后統(tǒng)一發(fā)送到一臺(tái)中心Logstash做二次解析和富化。這樣既保證了采集端的輕量又利用了Logstash強(qiáng)大的處理能力。Fluentd在容器化環(huán)境中用得比較多它的插件生態(tài)也很豐富但配置語法對(duì)新手不太友好。Vector是后起之秀性能極佳配置簡(jiǎn)潔但目前社區(qū)生態(tài)還不如前兩者成熟。綜合來看對(duì)于中小企業(yè)內(nèi)網(wǎng)環(huán)境Filebeat加Logstash的組合是最穩(wěn)妥的選擇。工具語言資源占用配置復(fù)雜度適用場(chǎng)景FilebeatGo極低低業(yè)務(wù)服務(wù)器日志采集LogstashJRuby高中中心化日志解析與富化FluentdRuby/C中中高容器環(huán)境日志采集VectorRust低低高性能采集場(chǎng)景2.2 數(shù)據(jù)存儲(chǔ)與檢索引擎的取舍采集到的數(shù)據(jù)往哪里存直接決定了后續(xù)分析的靈活性和查詢速度。目前開源領(lǐng)域主流的選擇是Elasticsearch、ClickHouse和OpenSearch。Elasticsearch是ELK棧的核心全文檢索能力強(qiáng)與Logstash、Kibana無縫集成生態(tài)最成熟。但它的資源消耗也不小尤其是內(nèi)存官方建議至少分配32G堆內(nèi)存給生產(chǎn)環(huán)境。對(duì)于中小企業(yè)如果日志量每天在幾十GB以內(nèi)單節(jié)點(diǎn)16G堆內(nèi)存也能跑起來但要做好索引生命周期管理定期清理舊數(shù)據(jù)。ClickHouse是列式存儲(chǔ)數(shù)據(jù)庫寫入和查詢速度極快特別適合做大規(guī)模日志的聚合分析。但它不擅長全文檢索而且運(yùn)維復(fù)雜度比Elasticsearch高。OpenSearch是Elasticsearch的一個(gè)分支功能基本一致但許可證更寬松。我的建議是如果你團(tuán)隊(duì)里沒有專門的搜索運(yùn)維人員優(yōu)先選Elasticsearch或OpenSearch因?yàn)橘Y料多、社區(qū)活躍遇到問題容易找到答案。存儲(chǔ)容量規(guī)劃有個(gè)簡(jiǎn)單的估算方法假設(shè)每天產(chǎn)生20GB原始日志Elasticsearch默認(rèn)副本數(shù)為1加上索引開銷實(shí)際占用約60GB。保留30天的話需要準(zhǔn)備約1.8TB的磁盤空間。你可以根據(jù)這個(gè)公式來規(guī)劃硬件。2.3 分析與告警組件的搭配策略數(shù)據(jù)存下來之后怎么從中發(fā)現(xiàn)異常這是態(tài)勢(shì)感知的核心價(jià)值所在。開源方案里Elasticsearch自帶的Watcher可以做一些簡(jiǎn)單的閾值告警但功能有限。更靈活的做法是用ElastAlert2它專門為Elasticsearch設(shè)計(jì)支持多種告警規(guī)則類型比如頻率告警、尖峰告警、基數(shù)告警等配置用YAML文件上手快。如果你需要更復(fù)雜的關(guān)聯(lián)分析比如把防火墻日志和主機(jī)日志關(guān)聯(lián)起來判斷是否發(fā)生了橫向移動(dòng)那就需要引入規(guī)則引擎。Sigma是一種通用的告警規(guī)則描述格式你可以用Sigma規(guī)則定義檢測(cè)邏輯然后用sigmac工具轉(zhuǎn)換成Elasticsearch查詢語句。這樣規(guī)則可以跨平臺(tái)復(fù)用不會(huì)被某個(gè)廠商鎖定。對(duì)于實(shí)時(shí)性要求極高的場(chǎng)景比如檢測(cè)暴力破解可以用Suricata做網(wǎng)絡(luò)流量檢測(cè)它基于規(guī)則匹配能實(shí)時(shí)發(fā)現(xiàn)異常流量并生成告警。Suricata的規(guī)則集可以定期從開源情報(bào)源更新保持對(duì)最新威脅的檢測(cè)能力。3. 數(shù)據(jù)采集與解析的實(shí)操細(xì)節(jié)3.1 Filebeat配置中的關(guān)鍵參數(shù)與避坑點(diǎn)Filebeat的配置文件是YAML格式結(jié)構(gòu)清晰但有幾個(gè)參數(shù)如果配錯(cuò)了會(huì)導(dǎo)致日志丟失或重復(fù)。先看一個(gè)典型的輸入配置filebeat.inputs: - type: log enabled: true paths: - /var/log/nginx/access.log fields: log_type: nginx_access environment: production fields_under_root: true multiline.pattern: ^\d{4}-\d{2}-\d{2} multiline.negate: true multiline.match: after ignore_older: 24h scan_frequency: 10s harvester_limit: 100這里有幾個(gè)參數(shù)值得展開說。fields_under_root: true這個(gè)設(shè)置很重要它把自定義字段提升到事件頂層而不是嵌套在fields子字段下。這樣在Elasticsearch里做查詢和聚合時(shí)更方便比如可以直接用log_type: nginx_access來過濾而不需要寫fields.log_type。multiline配置用于合并多行日志比如Java異常堆棧。pattern指定新日志行的起始特征negate: true表示不匹配該模式的行match: after表示把這些行合并到上一行后面。這個(gè)配置如果寫錯(cuò)了日志會(huì)被拆得七零八落后續(xù)分析根本沒法用。我踩過的坑是pattern里的正則沒有轉(zhuǎn)義反斜杠導(dǎo)致匹配失敗所有多行日志都被當(dāng)成獨(dú)立事件發(fā)送在Kibana里看就是一堆碎片。ignore_older: 24h告訴Filebeat只采集24小時(shí)內(nèi)修改過的文件避免啟動(dòng)時(shí)把歷史歸檔日志全部重新讀一遍。scan_frequency控制掃描新文件的頻率默認(rèn)10秒如果日志目錄文件很多可以適當(dāng)調(diào)大減少IO壓力。harvester_limit限制同時(shí)打開的采集器數(shù)量防止文件句柄耗盡。注意Filebeat的注冊(cè)表文件默認(rèn)在/var/lib/filebeat/registry它記錄了每個(gè)文件的采集進(jìn)度。如果你刪除了這個(gè)文件Filebeat會(huì)認(rèn)為所有文件都是新的從頭開始采集可能導(dǎo)致大量重復(fù)數(shù)據(jù)。遷移或重裝時(shí)一定要備份這個(gè)目錄。3.2 Logstash管道配置的解析技巧Logstash的管道配置分為input、filter、output三段。input段接收Filebeat發(fā)來的數(shù)據(jù)filter段做解析和富化output段寫入Elasticsearch。下面是一個(gè)處理Nginx訪問日志的典型配置input { beats { port 5044 ssl false } } filter { if [log_type] nginx_access { grok { match { message %{IPORHOST:client_ip} - %{DATA:remote_user} \[%{HTTPDATE:timestamp}\] %{WORD:http_method} %{DATA:request_uri} HTTP/%{NUMBER:http_version} %{NUMBER:status_code} %{NUMBER:body_bytes_sent} %{DATA:referrer} %{DATA:user_agent} } remove_field [message] } date { match [timestamp, dd/MMM/yyyy:HH:mm:ss Z] target timestamp } geoip { source client_ip target geo } mutate { convert { status_code integer body_bytes_sent integer } } } } output { elasticsearch { hosts [http://localhost:9200] index nginx-access-%{YYYY.MM.dd} user elastic password your_password } }Grok正則的編寫是Logstash使用中最容易出問題的地方。我的經(jīng)驗(yàn)是先在Kibana的Dev Tools里用Grok Debugger測(cè)試正則確認(rèn)能正確匹配后再寫入配置文件。另外remove_field [message]這步很重要原始日志內(nèi)容解析完之后就沒用了留在索引里白白占用空間。GeoIP插件可以根據(jù)客戶端IP解析出地理位置信息對(duì)于分析異常登錄來源很有幫助。但要注意內(nèi)網(wǎng)IP解析出來是空的可以在配置里加個(gè)判斷只對(duì)公網(wǎng)IP做GeoIP解析。日期解析也是關(guān)鍵一步。Nginx日志里的時(shí)間戳格式和Logstash默認(rèn)的timestamp不一樣必須用date插件轉(zhuǎn)換否則在Kibana里按時(shí)間過濾會(huì)出錯(cuò)。target timestamp表示把解析出來的時(shí)間覆蓋到事件的主時(shí)間戳上。3.3 解析規(guī)則的版本管理與測(cè)試方法隨著業(yè)務(wù)變化日志格式可能會(huì)調(diào)整解析規(guī)則也需要跟著改。如果沒有版本管理改錯(cuò)了很難回滾。我的做法是把所有Logstash管道配置文件放在Git倉庫里管理每次修改都提交一次寫清楚改了什么、為什么改。測(cè)試新規(guī)則時(shí)先用一個(gè)獨(dú)立的Logstash實(shí)例跑輸入用文件模擬確認(rèn)輸出符合預(yù)期后再上線。另外建議在filter段加一個(gè)_grokparsefailure標(biāo)簽檢查。如果grok解析失敗Logstash會(huì)給事件打上這個(gè)標(biāo)簽。你可以在output段加一個(gè)條件判斷把解析失敗的事件單獨(dú)寫到一個(gè)索引里方便后續(xù)排查。output { if _grokparsefailure in [tags] { elasticsearch { hosts [http://localhost:9200] index parse-failure-%{YYYY.MM.dd} } } else { elasticsearch { hosts [http://localhost:9200] index nginx-access-%{YYYY.MM.dd} } } }這個(gè)做法幫我發(fā)現(xiàn)過好幾次日志格式變更導(dǎo)致解析失敗的問題如果沒有這個(gè)隔離機(jī)制這些事件會(huì)混在正常數(shù)據(jù)里很難察覺。4. 關(guān)聯(lián)分析與告警規(guī)則的設(shè)計(jì)思路4.1 從單點(diǎn)告警到關(guān)聯(lián)分析的進(jìn)階路徑剛開始搭建態(tài)勢(shì)感知時(shí)最容易做的就是單點(diǎn)告警比如“5分鐘內(nèi)登錄失敗超過10次就告警”。這種規(guī)則簡(jiǎn)單直接但誤報(bào)率高而且無法發(fā)現(xiàn)復(fù)雜的攻擊鏈。舉個(gè)例子攻擊者可能先在一臺(tái)機(jī)器上嘗試弱口令登錄失敗幾次后換一臺(tái)機(jī)器繼續(xù)試每臺(tái)機(jī)器上的失敗次數(shù)都不超過閾值單點(diǎn)告警根本發(fā)現(xiàn)不了。關(guān)聯(lián)分析的核心思想是把不同來源、不同時(shí)間點(diǎn)的安全事件串聯(lián)起來還原出完整的攻擊場(chǎng)景。比如你可以定義這樣一條規(guī)則如果防火墻日志顯示某IP在短時(shí)間內(nèi)掃描了多個(gè)端口同時(shí)主機(jī)日志顯示該IP嘗試了SSH登錄那就判定為一次有預(yù)謀的入侵嘗試提高告警級(jí)別。實(shí)現(xiàn)關(guān)聯(lián)分析有兩種路徑。一種是用ElastAlert2的compound規(guī)則類型它支持在一條規(guī)則里定義多個(gè)查詢條件只有所有條件都滿足時(shí)才觸發(fā)告警。另一種是用Elasticsearch的percolate功能把規(guī)則反過來讓規(guī)則去匹配數(shù)據(jù)流。前者配置簡(jiǎn)單適合規(guī)則數(shù)量不多的場(chǎng)景后者性能更好適合規(guī)則成百上千的情況。4.2 ElastAlert2規(guī)則編寫實(shí)戰(zhàn)ElastAlert2的規(guī)則文件是YAML格式下面是一個(gè)檢測(cè)SSH暴力破解的規(guī)則示例name: SSH Brute Force Detection type: frequency index: filebeat-* num_events: 10 timeframe: minutes: 5 filter: - term: log_type: ssh_auth - term: event.outcome: failure alert: - email - slack email: - securityexample.com slack: webhook_url: https://hooks.slack.com/services/xxx alert_text: | SSH暴力破解告警 攻擊源IP: {source_ip} 目標(biāo)主機(jī): {host_name} 失敗次數(shù): {num_hits} 時(shí)間范圍: {start_time} - {end_time}這個(gè)規(guī)則的意思是在5分鐘內(nèi)如果同一個(gè)源IP對(duì)同一臺(tái)主機(jī)的SSH登錄失敗次數(shù)達(dá)到10次就觸發(fā)告警。num_events和timeframe的組合決定了檢測(cè)的靈敏度。調(diào)得太低會(huì)誤報(bào)調(diào)得太高會(huì)漏報(bào)。我的經(jīng)驗(yàn)是先按經(jīng)驗(yàn)值設(shè)一個(gè)初始值跑一周后根據(jù)實(shí)際告警情況調(diào)整。alert_text里可以用字段占位符ElastAlert2會(huì)自動(dòng)替換成實(shí)際值。這樣告警郵件里就能直接看到攻擊源IP、目標(biāo)主機(jī)這些關(guān)鍵信息不用再登錄系統(tǒng)去查。對(duì)于關(guān)聯(lián)分析ElastAlert2支持query類型的規(guī)則可以執(zhí)行自定義的Elasticsearch查詢語句。比如下面這個(gè)規(guī)則檢測(cè)的是“同一IP在掃描端口后緊接著嘗試登錄”的行為name: Port Scan Followed by Login Attempt type: query index: filebeat-* query: | { query: { bool: { must: [ {term: {log_type: firewall}}, {term: {event.action: port_scan}} ] } } }這個(gè)查詢會(huì)找出所有端口掃描事件然后你可以在告警文本里提示安全人員去檢查同一IP是否有后續(xù)登錄行為。雖然ElastAlert2本身不直接支持跨索引關(guān)聯(lián)但你可以通過告警文本引導(dǎo)人工研判或者寫一個(gè)腳本定期跑關(guān)聯(lián)查詢。4.3 規(guī)則調(diào)優(yōu)與誤報(bào)抑制的實(shí)操經(jīng)驗(yàn)規(guī)則上線初期誤報(bào)是不可避免的。我在實(shí)際項(xiàng)目里總結(jié)了幾條調(diào)優(yōu)經(jīng)驗(yàn)。第一給規(guī)則加白名單。比如內(nèi)部漏洞掃描器的IP、運(yùn)維人員的跳板機(jī)IP這些正常行為不應(yīng)該觸發(fā)告警。ElastAlert2支持在filter里用must_not排除特定IP。第二設(shè)置告警聚合。如果同一條規(guī)則在短時(shí)間內(nèi)觸發(fā)多次不要每次都發(fā)郵件而是合并成一封。ElastAlert2的aggregation功能可以做到這一點(diǎn)它會(huì)把相同規(guī)則的告警合并減少告警風(fēng)暴。第三定期回顧告警記錄。我每周會(huì)花半小時(shí)看一下過去一周的告警標(biāo)記哪些是誤報(bào)、哪些是真實(shí)事件。對(duì)于誤報(bào)分析原因并調(diào)整規(guī)則對(duì)于真實(shí)事件記錄處理過程作為后續(xù)優(yōu)化的參考。這個(gè)習(xí)慣堅(jiān)持下來規(guī)則的準(zhǔn)確率會(huì)越來越高。提示不要追求零誤報(bào)。安全告警的本質(zhì)是在漏報(bào)和誤報(bào)之間找平衡。寧可多一些誤報(bào)讓安全人員去確認(rèn)也不要因?yàn)橐?guī)則太嚴(yán)導(dǎo)致漏掉真實(shí)攻擊。關(guān)鍵是建立一套快速研判和反饋的流程。5. 可視化展示與日常運(yùn)營5.1 Kibana儀表盤的設(shè)計(jì)原則Kibana是ELK棧的可視化組件用它可以做出各種圖表和儀表盤。但很多人做出來的儀表盤花里胡哨實(shí)際用起來卻找不到關(guān)鍵信息。我的設(shè)計(jì)原則是一屏之內(nèi)回答三個(gè)問題——現(xiàn)在有沒有異常、異常在哪里、異常有多嚴(yán)重。具體來說儀表盤頂部放幾個(gè)關(guān)鍵指標(biāo)卡過去24小時(shí)的總告警數(shù)、未處理告警數(shù)、高危告警數(shù)。中間放一個(gè)時(shí)間趨勢(shì)圖展示告警數(shù)量隨時(shí)間的變化能一眼看出有沒有尖峰。底部放一個(gè)表格列出最近的告警詳情包括時(shí)間、類型、源IP、目標(biāo)IP、嚴(yán)重級(jí)別。對(duì)于態(tài)勢(shì)感知場(chǎng)景地圖可視化很有價(jià)值。用Kibana的Coordinate Map或Region Map可以把攻擊源IP的地理位置展示出來。雖然內(nèi)網(wǎng)IP解析不出位置但公網(wǎng)攻擊源的分布能幫你判斷威脅來源的大致區(qū)域。儀表盤不要做太多三到五個(gè)就夠了。一個(gè)是總覽一個(gè)是告警詳情一個(gè)是特定場(chǎng)景的專項(xiàng)視圖比如Web攻擊分析、暴力破解分析。每個(gè)儀表盤都要有明確的使用場(chǎng)景不要為了好看而堆圖表。5.2 告警降噪與分級(jí)處理機(jī)制告警發(fā)出來之后怎么處理也很關(guān)鍵。如果所有告警都發(fā)到同一個(gè)郵箱或群組安全人員很快就會(huì)被淹沒。我的做法是分級(jí)處理低危告警只記錄到系統(tǒng)里不主動(dòng)推送中危告警發(fā)到安全團(tuán)隊(duì)的群組高危告警除了發(fā)群組還要發(fā)短信或打電話通知值班人員。分級(jí)的標(biāo)準(zhǔn)可以根據(jù)資產(chǎn)重要性和攻擊類型來定。比如針對(duì)核心數(shù)據(jù)庫服務(wù)器的暴力破解嘗試即使次數(shù)不多也應(yīng)該定為高危而針對(duì)測(cè)試環(huán)境的掃描行為可以定為低危。ElastAlert2支持在規(guī)則里設(shè)置priority字段你可以在告警輸出時(shí)根據(jù)這個(gè)字段決定通知方式。另外建議給每條告警生成一個(gè)唯一ID并記錄處理狀態(tài)。安全人員處理完一條告警后標(biāo)記為“已處理”或“誤報(bào)”。這樣后續(xù)統(tǒng)計(jì)時(shí)可以算出告警處理率和誤報(bào)率作為規(guī)則優(yōu)化的依據(jù)。5.3 數(shù)據(jù)保留策略與性能優(yōu)化態(tài)勢(shì)感知系統(tǒng)跑起來之后數(shù)據(jù)會(huì)越來越多如果不做保留策略磁盤很快就會(huì)被寫滿。Elasticsearch提供了Index Lifecycle Management功能可以自動(dòng)管理索引的生命周期。我的配置是熱數(shù)據(jù)保留7天放在SSD上保證查詢速度溫?cái)?shù)據(jù)保留30天放在大容量機(jī)械盤上超過30天的數(shù)據(jù)自動(dòng)刪除。對(duì)于特別重要的告警數(shù)據(jù)比如高危告警的原始日志可以單獨(dú)導(dǎo)出到對(duì)象存儲(chǔ)或歸檔數(shù)據(jù)庫長期保存。這樣既控制了Elasticsearch的存儲(chǔ)成本又滿足了合規(guī)審計(jì)的要求。性能優(yōu)化方面有幾個(gè)參數(shù)值得關(guān)注。Elasticsearch的refresh_interval默認(rèn)是1秒意味著每秒都會(huì)生成一個(gè)新的segment寫入性能會(huì)受影響。對(duì)于日志場(chǎng)景可以把這個(gè)值調(diào)到30秒寫入吞吐量能提升不少。number_of_shards和number_of_replicas也要根據(jù)數(shù)據(jù)量和節(jié)點(diǎn)數(shù)合理設(shè)置分片太多會(huì)增加集群管理開銷分片太少會(huì)影響查詢并行度。Logstash的pipeline.workers參數(shù)控制并行處理線程數(shù)默認(rèn)是CPU核數(shù)。如果發(fā)現(xiàn)Logstash處理有延遲可以適當(dāng)調(diào)大這個(gè)值但不要超過CPU核數(shù)的兩倍否則上下文切換反而會(huì)降低性能。6. 建設(shè)過程中容易忽略的細(xì)節(jié)與個(gè)人體會(huì)6.1 時(shí)間同步這個(gè)小事坑過不少人說出來你可能不信我在三個(gè)不同的項(xiàng)目里都遇到過因?yàn)闀r(shí)間不同步導(dǎo)致態(tài)勢(shì)感知數(shù)據(jù)錯(cuò)亂的問題。業(yè)務(wù)服務(wù)器、日志服務(wù)器、Elasticsearch節(jié)點(diǎn)如果時(shí)間不一致日志的時(shí)間戳就會(huì)對(duì)不上關(guān)聯(lián)分析根本沒法做。明明是先掃描后登錄因?yàn)闀r(shí)間偏差在系統(tǒng)里看變成了先登錄后掃描攻擊鏈完全亂了。解決辦法很簡(jiǎn)單所有服務(wù)器統(tǒng)一配置NTP時(shí)間同步指向同一個(gè)內(nèi)網(wǎng)時(shí)間源。配置完之后用chronyc sources或ntpq -p檢查同步狀態(tài)確保偏差在毫秒級(jí)。這個(gè)事看起來不起眼但它是態(tài)勢(shì)感知系統(tǒng)能正常工作的前提。6.2 日志質(zhì)量比日志數(shù)量更重要?jiǎng)傞_始做的時(shí)候我總想著多接幾種日志覺得數(shù)據(jù)越多分析越準(zhǔn)。后來發(fā)現(xiàn)如果日志本身質(zhì)量不高比如格式不統(tǒng)一、關(guān)鍵字段缺失、時(shí)間戳不準(zhǔn)確接進(jìn)來反而是負(fù)擔(dān)。解析規(guī)則要寫一大堆查詢速度還被拖慢。后來我調(diào)整了策略先把最核心的兩三類日志接好確保解析準(zhǔn)確、字段完整、時(shí)間戳正確。比如Nginx訪問日志、SSH登錄日志、防火墻會(huì)話日志這三類覆蓋了大部分常見的攻擊場(chǎng)景。等這套跑順了再逐步擴(kuò)展其他日志源。寧可少而精不要多而雜。6.3 安全運(yùn)營是持續(xù)過程不是一錘子買賣態(tài)勢(shì)感知系統(tǒng)上線只是開始后續(xù)的運(yùn)營才是重頭戲。我見過一些團(tuán)隊(duì)系統(tǒng)搭好之后就不管了規(guī)則從來不更新告警從來不處理儀表盤從來不看。這樣的系統(tǒng)跟沒有沒什么區(qū)別。我的建議是把安全運(yùn)營納入日常工作計(jì)劃。每天花15分鐘看一下告警面板處理一下未讀告警每周花半小時(shí)回顧一下告警記錄調(diào)整誤報(bào)規(guī)則每月做一次規(guī)則和儀表盤的全面檢查根據(jù)業(yè)務(wù)變化更新配置。這些工作看起來瑣碎但堅(jiān)持下來系統(tǒng)的價(jià)值會(huì)越來越明顯。還有一點(diǎn)安全規(guī)則要跟著威脅形勢(shì)更新。比如出現(xiàn)了新的漏洞攻擊者開始利用你就需要及時(shí)添加對(duì)應(yīng)的檢測(cè)規(guī)則?？梢躁P(guān)注一些開源情報(bào)源定期獲取最新的檢測(cè)規(guī)則轉(zhuǎn)換成Sigma或ElastAlert2格式導(dǎo)入系統(tǒng)。6.4 團(tuán)隊(duì)協(xié)作與知識(shí)沉淀態(tài)勢(shì)感知系統(tǒng)不是一個(gè)人能玩轉(zhuǎn)的。采集配置、解析規(guī)則、告警規(guī)則、儀表盤這些都需要有人維護(hù)。如果只有一個(gè)人負(fù)責(zé)一旦他請(qǐng)假或離職系統(tǒng)就可能停擺。所以從一開始就要做好知識(shí)沉淀把配置文件的用途、規(guī)則的邏輯、常見問題的處理方法都寫成文檔放在團(tuán)隊(duì)共享的地方。另外建議建立值班制度。安全告警需要有人及時(shí)響應(yīng)不能等上班了再看?？梢园才泡喼得總€(gè)人負(fù)責(zé)一段時(shí)間內(nèi)的告警處理。處理完之后在群里同步一下情況讓其他人也知道發(fā)生了什么。這樣既保證了響應(yīng)速度也促進(jìn)了團(tuán)隊(duì)的安全意識(shí)提升。我在實(shí)際項(xiàng)目里還發(fā)現(xiàn)一個(gè)有用的做法定期做模擬攻擊演練。用一些開源的攻擊模擬工具在內(nèi)網(wǎng)里跑一遍看看態(tài)勢(shì)感知系統(tǒng)能不能檢測(cè)到、告警及不及時(shí)、告警信息全不全。通過演練來檢驗(yàn)系統(tǒng)的有效性比單純看規(guī)則數(shù)量更有意義。演練之后根據(jù)暴露出來的問題針對(duì)性地優(yōu)化規(guī)則和流程系統(tǒng)的實(shí)戰(zhàn)能力會(huì)提升得很快。