2. 這次事故到底是怎么爆的一次典型的內(nèi)網(wǎng)失控全過程先交代一下背景。我們是一家做企業(yè)服務(wù)的公司研發(fā)、測試、運營加起來一百多人內(nèi)網(wǎng)環(huán)境屬于典型的“比上不足比下有余”——有基礎(chǔ)的防火墻、有核心交換機但離嚴(yán)格的分區(qū)隔離和全量審計還差得遠。這種環(huán)境平時夠用一旦有人“硬上”某個不成熟的工具就會瞬間露出所有短板。事情的起因非常樸素。老板不知道從哪看到一個開源的智能體編排框架名字就不點了反正就是那種可以對接內(nèi)部系統(tǒng)、自動處理工單、跑審批流程的東西。他覺得這東西能幫我們解決跨部門協(xié)作效率低的問題于是讓運維直接在辦公網(wǎng)段部署了一套連通了內(nèi)部的知識庫、工單系統(tǒng)和一部分測試環(huán)境的數(shù)據(jù)庫。前后不到半天問題就來了。2.1 第一波癥狀網(wǎng)絡(luò)延遲飆升辦公網(wǎng)段直接卡死最先感知到異常的是行政和財務(wù)的同事。平時打開OA系統(tǒng)、收發(fā)郵件都很流暢那天下午突然開始轉(zhuǎn)圈刷新頁面要等十幾秒視頻會議直接沒法開。緊接著運維后臺的監(jiān)控圖表開始報警內(nèi)網(wǎng)核心交換機的入向流量從平時的幾百兆跳到了接近帶寬上限CPU占用率長時間維持在90%以上。我當(dāng)時的第一個反應(yīng)是“有設(shè)備被攻破了正在被利用往外發(fā)包”。因為這種流量特征太典型了——不是瞬時突刺而是持續(xù)占滿帶寬像是有什么程序在不停地上傳或下載數(shù)據(jù)。但奇怪的是防火墻上的外聯(lián)記錄并沒有顯示大規(guī)模的外部連接流量似乎都集中在內(nèi)網(wǎng)網(wǎng)段之間。這一下問題就變得棘手了。如果只是外部攻擊封掉外聯(lián)端口就能止血但如果是內(nèi)網(wǎng)自己跑的程序在互相通信那就要找出通信源頭。2.2 第一次排查以為是中毒其實是智能體在“沸騰”我先在核心交換機上做了流量采樣用端口鏡像把流量導(dǎo)到分析機上然后按源IP排序。結(jié)果讓我很意外——流量大頭來自老板部署那套智能體工具的服務(wù)器而且它和辦公網(wǎng)內(nèi)的幾十臺終端都在建立連接。換句話說這臺服務(wù)器正在瘋狂地“呼叫”內(nèi)網(wǎng)里的每一臺機器。進一步看連接狀態(tài)發(fā)現(xiàn)它是在嘗試調(diào)用各臺機器上開放的接口和端口。正常情況下智能體應(yīng)該通過提前配置好的接口列表去對接指定系統(tǒng)但這個框架默認(rèn)開啟了網(wǎng)絡(luò)探測能力會把內(nèi)網(wǎng)網(wǎng)段里所有可達的IP都掃一遍然后自動識別開放的服務(wù)端口嘗試?yán)斫夂驼{(diào)通。這本來是一個方便自動化的功能但部署時沒有做任何網(wǎng)絡(luò)邊界配置它就把整個辦公網(wǎng)當(dāng)成了自己的“操作范圍”。這就是為什么會卡死它不是在做一件惡意的事情但它做的事和惡意掃描沒什么區(qū)別——對整個網(wǎng)段發(fā)起大量并發(fā)探測每個探測都要經(jīng)過交換機轉(zhuǎn)發(fā)短時間內(nèi)生成了海量的會話記錄直接把交換機的轉(zhuǎn)發(fā)能力拖垮了。2.3 我最初踩的坑先重啟設(shè)備差點把證據(jù)弄沒了說到這里我必須坦白一個教訓(xùn)。當(dāng)時我第一反應(yīng)是重啟核心交換機想著先把業(yè)務(wù)恢復(fù)再說。還好同事拉住了我——重啟交換機意味著所有內(nèi)存里的會話記錄、轉(zhuǎn)發(fā)緩存、端口狀態(tài)全部清空如果這臺服務(wù)器真的有問題重啟之后我們就很難再還原它到底訪問過哪些機器。正確的做法是先切斷故障源頭而不是重啟基礎(chǔ)設(shè)施。我們把那臺智能體服務(wù)器直接從交換機上拔線隔離然后立刻對它的磁盤做只讀鏡像保留系統(tǒng)日志、進程內(nèi)存轉(zhuǎn)儲和應(yīng)用配置文件。這些證據(jù)在后來的復(fù)盤和加固中起到了關(guān)鍵作用如果重啟了交換機很多信息就永遠找不回來了。2.4 隔離之后事情并沒有結(jié)束數(shù)據(jù)還在悄悄往外傳把服務(wù)器隔離之后辦公網(wǎng)的流量恢復(fù)正常了。但我心里不踏實又去看了一眼防火墻的會話日志。這一看發(fā)現(xiàn)問題了——在服務(wù)器被隔離之前它已經(jīng)通過辦公網(wǎng)段的出口訪問過一次外部地址而且傳輸?shù)臄?shù)據(jù)量大概有幾百MB。這個外部地址是那個開源框架默認(rèn)的遙測端點。很多開源工具會默認(rèn)開啟使用統(tǒng)計和崩潰上報功能把運行日志、異常堆棧、使用情況發(fā)給開發(fā)者的服務(wù)器。這本來是正常的軟件行為但在企業(yè)內(nèi)網(wǎng)環(huán)境里這代表公司的一部分內(nèi)部數(shù)據(jù)已經(jīng)離開了內(nèi)網(wǎng)邊界而且沒有任何人審批過。我不覺得開源工具收集遙測數(shù)據(jù)是惡意行為但在企業(yè)內(nèi)部部署時這必須被當(dāng)作敏感事件來處理。公司的數(shù)據(jù)出去是出去了這就不能當(dāng)作“沒發(fā)生”看待。而且這件事也暴露了一個更嚴(yán)重的問題我們當(dāng)時根本沒有任何審計機制能提前發(fā)現(xiàn)這臺服務(wù)器在對外通信。2.5 根因總結(jié)三句話能說清楚但代價不小復(fù)盤到最后這起事故的根因其實不復(fù)雜第一一個功能強大但邊界缺失的工具被不加保護地放進了辦公網(wǎng)核心位置。它具備網(wǎng)段探測、接口自動發(fā)現(xiàn)、外部遙測等功能但部署時沒有限制它的網(wǎng)絡(luò)可達范圍和行為邊界。第二審批流程形同虛設(shè)。老板直接要求部署運維沒有經(jīng)過變更評審也沒有做安全評估。流程這東西平時覺得煩出了事才知道它是用來救命的。第三監(jiān)控覆蓋不足。我們對出口流量有基本的日志記錄但對內(nèi)網(wǎng)東西向流量服務(wù)器與終端之間的通信幾乎完全透明等到交換機都被拖垮了才意識到異常。這三點放在任何一家公司可能都成立但真正把這些隱患點炸開的是一次“無心但無約束”的快速部署。所以后面我們在做加固的時候思路非常明確不是去追究誰的責(zé)任而是從制度、技術(shù)和意識三個層面把漏洞補上。3. 事后止血與加固一套可以落地的內(nèi)網(wǎng)安全操作方案如果說前面是復(fù)盤那這一部分就是要動手解決的問題。我們花了大概兩周時間把整件事從“臨時救火”推進到“系統(tǒng)性加固”。下面這些措施都是基于這次事故的親身經(jīng)歷不拔高、不空談每一步都經(jīng)歷過驗證。3.1 第一件事重新梳理網(wǎng)絡(luò)分區(qū)劃分信任邊界最根本的問題是那臺服務(wù)器擁有過大的網(wǎng)絡(luò)權(quán)限。要解決這個問題第一件事就是按“最小權(quán)限原則”重新劃分內(nèi)網(wǎng)。我給網(wǎng)段做了這樣的區(qū)分辦公網(wǎng)段員工終端、打印機、門禁設(shè)備等彼此之間默認(rèn)不互信。業(yè)務(wù)網(wǎng)段運行OA、知識庫、工單系統(tǒng)等內(nèi)部應(yīng)用的服務(wù)器區(qū)域。數(shù)據(jù)網(wǎng)段存放數(shù)據(jù)庫、文件存儲等核心數(shù)據(jù)資產(chǎn)的區(qū)域。管理網(wǎng)段給運維人員做設(shè)備管理和配置用的獨立網(wǎng)絡(luò)與其他區(qū)域隔離。測試網(wǎng)段研發(fā)調(diào)試用的臨時環(huán)境按項目隔離隨時可銷毀。這次出問題的智能體服務(wù)器被我劃到了“業(yè)務(wù)網(wǎng)段”里的一個獨立子網(wǎng)并且用防火墻策略明確限制它只允許訪問業(yè)務(wù)網(wǎng)段里指定的那幾臺應(yīng)用服務(wù)器不能訪問數(shù)據(jù)網(wǎng)段不能訪問辦公網(wǎng)段出口流量必須經(jīng)過統(tǒng)一的互聯(lián)網(wǎng)代理。這個事情難在哪兒難在舊系統(tǒng)太多了。很多老系統(tǒng)部署的時候圖省事跨網(wǎng)段互相訪問甚至在辦公網(wǎng)上直接開數(shù)據(jù)庫端口。真正按新規(guī)則去收斂的時候一個個業(yè)務(wù)系統(tǒng)都要重新確認(rèn)通信需求溝通成本非常高。但這一步不做后面所有防護都沒意義。3.2 第二件事給開源工具做“能力裁剪”去掉不必要的權(quán)限很多開源框架功能越強大默認(rèn)開啟的能力就越危險。這次的智能體框架就是一個典型它默認(rèn)能做網(wǎng)絡(luò)探測、接口自動發(fā)現(xiàn)、外部數(shù)據(jù)上報。這些功能在單機開發(fā)環(huán)境里很實用但對內(nèi)網(wǎng)部署來說就是安全隱患。我們就地對部署方案做了改造在配置文件中顯式關(guān)閉網(wǎng)絡(luò)探測和自動接口發(fā)現(xiàn)功能所有的對接目標(biāo)改成手工白名單維護禁止服務(wù)器主動發(fā)起外聯(lián)請求出網(wǎng)必須通過代理并在代理層做域名/端口白名單需要連的企業(yè)系統(tǒng)提前申請、逐一審批把遙測、統(tǒng)計上報等業(yè)務(wù)全部關(guān)閉不讓任何內(nèi)部數(shù)據(jù)未經(jīng)允許離開內(nèi)網(wǎng)。這里有一個容易忽略的細節(jié)修改這些配置之后一定要檢查工具是否還會重新生成默認(rèn)配置。有些框架啟動時會自動補齊缺失的配置項你以為關(guān)閉了重啟之后它又悄悄開啟了。正確做法是在配置文件里顯式寫上“禁用”而不是簡單地刪除或注釋掉相關(guān)選項這樣才能確保工具不會“自作主張”把默認(rèn)行為加回來。3.3 第三件事基于最小權(quán)限建設(shè)賬號和接口體系收斂攻擊面隔離了網(wǎng)絡(luò)、裁剪了功能接下來就是賬號和接口層面的收斂。首先是賬號體系。我們把這個服務(wù)器上的所有應(yīng)用賬號統(tǒng)一到企業(yè)內(nèi)的統(tǒng)一身份認(rèn)證體系并且按照“最小權(quán)限”分配了角色機器人賬號只擁有查詢工單、發(fā)起審批流程的權(quán)限不擁有修改、刪除、批量導(dǎo)出數(shù)據(jù)的權(quán)限不能讀取數(shù)據(jù)庫里的客戶原始數(shù)據(jù)所有操作日志追回到統(tǒng)一日志平臺。然后是接口層面。我們把內(nèi)部各系統(tǒng)對外的API做了一次全面梳理建立了三個級別的接口規(guī)范核心敏感數(shù)據(jù)接口只允許經(jīng)統(tǒng)一網(wǎng)關(guān)轉(zhuǎn)發(fā)應(yīng)用接口要求必須有獨立的身份校驗和限流控制內(nèi)部調(diào)試接口全部關(guān)閉或者只允許管理網(wǎng)段訪問。這個改造直接把未來接口被濫用的可能性壓低了一大截。3.4 第四件事補齊監(jiān)控與告警告別“出了事才發(fā)現(xiàn)”這次事故最大的教訓(xùn)是我們對內(nèi)網(wǎng)東西向流量完全沒有視界。所以補監(jiān)控是優(yōu)先級很高的任務(wù)。我們在核心交換機和關(guān)鍵匯聚交換機上部署了流量分析探針覆蓋了辦公網(wǎng)、業(yè)務(wù)網(wǎng)和管理網(wǎng)之間的所有必經(jīng)鏈路。一方面建立全網(wǎng)的流量臺賬另一方設(shè)了四條告警規(guī)則單個IP在單位時間內(nèi)發(fā)起的連接數(shù)超過閾值比如每秒超過兩百個新建連接單個IP訪問的內(nèi)網(wǎng)目標(biāo)數(shù)超過閾值比如一分鐘內(nèi)訪問超過五個不同的網(wǎng)段非管理網(wǎng)段出現(xiàn)對外聯(lián)請求流量趨勢曲線出現(xiàn)長時間高位平穩(wěn)而不是業(yè)務(wù)高峰那種周期性波動。這些規(guī)則未必能覆蓋所有攻擊場景但捕捉這次事故這種“智能體沸騰”型事件已經(jīng)夠用。運維同學(xué)現(xiàn)在每天只需要花幾分鐘看告警隊列確認(rèn)沒有異常即可徹底告別了過去那種靠人肉翻日志的日子。3.5 第五件事從流程上下手把“人”這個變量管住技術(shù)手段做到位之后還要解決“老板硬上”這個源頭問題。我們專門建立了一個“高風(fēng)險變更評估表”。任何系統(tǒng)只要滿足以下條件之一就必須走完整評估流程能訪問員工個人信息能訪問客戶數(shù)據(jù)有對外發(fā)起網(wǎng)絡(luò)請求的能力有自動執(zhí)行操作的能力能對接三個以上內(nèi)部系統(tǒng)。這次出問題的智能體框架五條全占在評估表里屬于最高風(fēng)險等級。同時給管理層專門做了一次匯報核心意思是不是說不能用新工具而是要用得安全。我們給出了一個標(biāo)準(zhǔn)化的接入路徑先申請、再評估、然后選型、部署、測試、上線。流程看起來多了一步但每一步都有明確的責(zé)任人和時限不會讓業(yè)務(wù)等著急。注意這里說的審批不是走形式。我自己見過太多公司把“變更評審”做成十分鐘簽字會那就是掩耳盜鈴。真正的評審重點是讓技術(shù)負責(zé)人看一遍網(wǎng)絡(luò)拓撲變更讓安全負責(zé)人看一遍數(shù)據(jù)流圖讓業(yè)務(wù)負責(zé)人確認(rèn)系統(tǒng)不能被外部直接訪問。三方都確認(rèn)了這個會才算開完。3.6 一件順手做掉但很重要的補丁賬號權(quán)限全面盤點既然賬面都翻了一遍我建議順手把公司里的“僵尸賬號”和“高權(quán)限賬號”清理一輪?，F(xiàn)在很多企業(yè)系統(tǒng)已經(jīng)支持接入統(tǒng)一身份認(rèn)證但很多歷史遺留的老系統(tǒng)還依賴本地密碼。這些老系統(tǒng)的賬號往往被人遺忘了離職員工的賬號沒刪、行政小妹有數(shù)據(jù)庫管理員權(quán)限、外包開發(fā)拿著root密碼。這種問題的風(fēng)險不亞于一臺沒做防護的服務(wù)器。我們用了一個周末做了全量盤點把使用超過一年且沒有登錄記錄的賬號全部凍結(jié)再把所有管理員權(quán)限壓縮到十人以內(nèi)雙向認(rèn)證全部開啟。這個工作和前面的網(wǎng)絡(luò)隔離一樣辛苦但它能把“一旦被攻破后的爆炸半徑”再縮小一圈。做完了這些我們才敢說這次事故算是真正處理完了。4. 一些真實的排查細節(jié)與工具經(jīng)驗這個部分我相信是實操中最容易卡住的地方。很多文章講安全只說大概念不聊細節(jié)。我把自己在排查過程中真正用到的方法和踩過的坑寫下來希望能幫到正在處理類似問題的同行。4.1 工具選型實測可視化分析配合流量審查當(dāng)交換機CPU告警、網(wǎng)絡(luò)全線卡頓的時候命令行工具已經(jīng)很難實時操作了。我們最先做的是把核心交換機的端口鏡像開啟用流量分析工具抓取真實流量。分析工具不用追求大而全關(guān)鍵要看兩點能不能快速按IP做排序統(tǒng)計能不能跨時間維度做回溯。我這次用的組合是“抓包工具加可視化分析平臺”抓包工具負責(zé)收集原始流量包保留到本地可視化分析平臺負責(zé)把抓到的數(shù)據(jù)按五元組源IP、源端口、目標(biāo)IP、目標(biāo)端口、協(xié)議做索引方便我們快速定位是哪個IP在和哪個IP通信。這套組合的好處是即使當(dāng)時沒有配置全量的網(wǎng)絡(luò)分析設(shè)備只要有一臺普通服務(wù)器和交換機端口鏡像就能臨時搭出分析環(huán)境為事后追溯提供足夠證據(jù)。4.2 日志審查時最容易忽略的幾個字段我們常規(guī)都會看訪問日志里的時間、用戶、操作類型但出了這類事才發(fā)現(xiàn)真正要重點盯的是這幾個字段用戶代理、來源IP、目標(biāo)地址、傳輸字節(jié)數(shù)、設(shè)備指紋、以及會話持續(xù)時長。就拿這次事件來說那臺智能體服務(wù)器訪問外部遙測端點時用戶代理字段就顯示了框架的名稱和版本號。如果我們當(dāng)初的日志系統(tǒng)能對這種用戶代理做告警整個事件可以提前幾小時發(fā)現(xiàn)。傳輸字節(jié)數(shù)也很重要內(nèi)部系統(tǒng)的常規(guī)接口調(diào)用往往只有幾十KB單次會話傳出幾百MB數(shù)據(jù)這本身就是再明顯不過的危險信號。建議所有負責(zé)運維和安全的朋友在做日志審計時一定要把這兩個維度加進去異常用戶代理自動告警、異常傳輸量自動告警。光看“有沒有登錄成功”是遠遠不夠的。4.3 三個典型的故障排查手段最后分享三個在排查這次事故時實際用到的判定方法第一個是“丟包率定位法”。當(dāng)網(wǎng)絡(luò)卡頓時用工具去ping不同網(wǎng)段的幾個關(guān)鍵IP對比丟包率。如果所有網(wǎng)段都掉包那問題大概率出在核心設(shè)備如果只有某個網(wǎng)段掉包就往該網(wǎng)段內(nèi)部的終端和設(shè)備上找原因。我們當(dāng)時就是用這個方法先從交換機上確定了故障點再用流量分析鎖定了具體的故障服務(wù)器。第二個是“香農(nóng)熵”的另類用法。流量基線穩(wěn)定的時候源IP和目的IP的分布是比較“整齊”的但當(dāng)有設(shè)備在做全網(wǎng)掃描時目的IP出現(xiàn)頻率會變得非常均勻熵值會異常下降。雖然網(wǎng)格化的流量數(shù)據(jù)分析工具可以直接看到這種變化但如果你手頭只有基礎(chǔ)的數(shù)據(jù)包文件也可以用腳本計算IP分布熵來做快速判斷數(shù)據(jù)上一樣能看出掃描行為。第三個是“長連接清單”檢查法。我們在核心防火墻上拉取了一天內(nèi)所有持續(xù)時間超過三分鐘的連接記錄逐一核對這些連接對應(yīng)的進程和業(yè)務(wù)。正常的企業(yè)應(yīng)用連接大多是短連接出現(xiàn)大量長連接說明有東西在保持通信。這次事故中那臺服務(wù)器的對外遙測連接恰好就是一條長連接在清單里非常扎眼一眼就揪出來了。4.4 跟設(shè)備廠商打交道的經(jīng)驗該做快照就做快照這次出事的服務(wù)器操作系統(tǒng)和上面跑的框架涉及不止一個軟件廠商。我們在排查過程中想請廠商的技術(shù)支持幫忙分析框架行為對方提出要我們提供系統(tǒng)日志和進程快照。說實話當(dāng)時線上服務(wù)已經(jīng)處于不穩(wěn)定狀態(tài)運維同事很擔(dān)心做快照會不會影響正常業(yè)務(wù)。最終我們用了一臺同型號的空閑服務(wù)器裝了同樣的操作系統(tǒng)和框架版本然后做了一次完整的模擬部署和踩踏實驗——安全、嚴(yán)謹(jǐn)?shù)貜?fù)現(xiàn)了“硬上”導(dǎo)致內(nèi)網(wǎng)擁塞的過程再將完整快照提供給廠商。這樣做既沒有影響線上業(yè)務(wù)也拿到了廠商需要的診斷材料。這個經(jīng)驗很有用當(dāng)你需要別人幫你分析問題務(wù)必給到一個可復(fù)現(xiàn)的環(huán)境而不是讓別人的技術(shù)支持對著線上半死不活的環(huán)境遠程操作。時間上雖然會慢但整個過程是可控、安全的。4.5 一些“便宜但管用”的老辦法最后還想說一個容易被年輕人忽略的點很多老辦法在關(guān)鍵時刻比花哨的工具更有用。我們這次能快速定位到那臺服務(wù)器很大程度上依賴的是一套非常原始的方法——在核心交換機上按接入端口流量做了半小時排序然后把流量最大的十個端口逐個和物理資產(chǎn)表對了一遍。這種“土辦法”雖然慢但它在任何環(huán)境下都能做不依賴任何高級工具。建議每家公司都建一個“物理資產(chǎn)端口對應(yīng)表”哪怕是用電子表格記錄交換機的哪個端口接的是哪臺機器IP是什么用途是什么。出了事你才知道這張表有多值錢——有些公司連核心交換機的端口接什么都說不清楚那就只能眼看著問題在眼前發(fā)生卻沒辦法下手。5. 從一次事故到一套機制這件事給我留下的三點體會整個事件從發(fā)生到徹底處理完花了大概兩周時間?，F(xiàn)在回頭看我最大的體會不是技術(shù)本身而是安全這件事的機制價值。第一如果你把一臺服務(wù)器當(dāng)成“自己人”放進內(nèi)網(wǎng)就必須給它畫好邊界。無論它是不是開源的、是不是老板親自部署的、是不是自帶各種自動化能力只要它能觸達公司內(nèi)部系統(tǒng)和數(shù)據(jù)就要按最高風(fēng)險等級來對待。這是這次事故最深刻的教訓(xùn)。第二監(jiān)控不一定越貴越好。我們這次事后配置的四條告警規(guī)則實際上就是基于已有設(shè)備能力做了組合并沒有采購任何新的硬件。搞清楚自己手里有什么設(shè)備、設(shè)備能供什么數(shù)據(jù)然后把規(guī)則寫對比迷信“采購一套高級安全系統(tǒng)”管用得多。第三流程和意識必須綁定。就算我們把所有安全機制都建好了如果老板還想著“下次再快速部署一個工具”技術(shù)手段也攔不住。所以事后我們專門給管理層做了一次“十五分鐘安全課”核心內(nèi)容就一句話新工具接入沒有問題但接入之前必須過流程、劃邊界、留權(quán)限。沒有這三個動作任何部署都是裸奔。這次課之后效果還是很明顯的——至少現(xiàn)在沒人敢再繞過流程去動核心網(wǎng)段了。最后再分享一個小細節(jié)我們在給那臺智能體服務(wù)器做隔離時刻意沒有關(guān)機而是保持了六小時只讀掛載狀態(tài)。這六小時里我們完整導(dǎo)出了應(yīng)用日志和系統(tǒng)會話記錄還順手找到了三條它試圖連通但因為目標(biāo)端口不一致而失敗的記錄。這些記錄后來成為判斷信息泄露范圍的關(guān)鍵證據(jù)。如果當(dāng)時為了“省事”直接關(guān)機或者重新啟動了服務(wù)這些痕跡就再也找不回來了。遇到大規(guī)模變動的時候切記先保護現(xiàn)場再談恢復(fù)。