你的網絡全流量從來都不「全」

最近一兩年間，研究網絡流量分析的各種流派，都殊途同歸到“全流量”這個方向。你也全流量我也全流量，但究竟什么是全流量，大家不是語焉不詳就是諱莫如深。更有甚者，拿開源IDS引擎來直接充當全流量，就像“人工智能”一樣，兀自念了一個咒語，就能雞犬升天。讓人不能不感慨，一個IDS的時代結束了，這個時代的人還活著——這是一件很殘酷、卻很常見的事。

流量，顧名思義，即流淌于網絡中的各種數據。全，則是全部的意思。放在一起，望文生義來說就是網絡中全部的數據。用小學生的視角去看，與“全”對應的就是“部分”。使用過眾多流量分析工具的各位都知曉，大部分工具輸入的就是全部網絡流量，那這個被大家集體鄙視的“部分”又從何而來？ 

PART1 全從何來

我們不妨直接去看故事的結尾，安全管理和維護人員，最常遇到的用戶對網絡的反饋。 

反饋1：今天我電腦被勒索了，是不是從網絡來的，你花錢買的安全設備為什么沒防住，明天就開除你！

反饋2：昨天下午四點鐘，這網絡慢死了，你告訴我為什么？我花了這么多錢買帶寬，買設備，以后不能這樣了！ 

不切身走到一線，很難體會網絡安全和維護工程師，此時面對一堆安全設備告警和網管軟件流量曲線的無奈感。用戶對網絡的要求究竟是什么，問題又到底出在哪里？

• 滯后性：真正的現象性需求，總是在事件發生后的一段時間出現，不管是網絡入侵還是質量波動，很少在第一時刻被最終用戶體會到，但是用戶對源頭的追溯往往卻是不遺余力的。
• 模糊性：網絡使用者，對現象的描述都是似是而非的，通常都是“好像中毒了”、“慢”、“卡”、“電腦不正常”等，澄清現狀的過程本身就需要用細致的數據與其做交互，落實諸如：時間、應用、具體狀態等。
• 離散性：由于滯后和模糊，在澄清需求和分析定位過程中，往往使用離散（告警）或切片（流量波動圖）來驅動整個過程，雖然數字世界天生是一個離散的世界，但是對使用者來說他需要的是一個近似連續的實體，不能丟棄細節，就像沒有人想在電視屏幕上看到大片的像素點。

大部分的流量在線分析引擎雖然具備即時性、準確性，但從本質上來說，仍然是一個離散的系統，把網絡世界肢解為一個個帶有時間戳的孤立事件或切片，例如：3月5日15時29分47秒，內網中毒主機192.168.25.4對服務器10.3.29.5進行了一次SQL注入攻擊。攻擊關聯分析、用戶溯源、未知威脅發現、性能測量、故障分析與預警，在離散系統上都是很難展開的。因此，殊途同歸，大家一致認為，用“全流量”去塑造一個近似連續的網絡世界，將成為解開這個難題的救命稻草。 

PART2全流量何以可能

要解開這個問題，需要把它切分成三個維度：時間、空間和成本。

1.時間維度

要貫徹全流量的“全”字，首先要考慮的是時間軸上的完整。數字世界由0和1組成，天生離散，只有當達到一定密度才能擬合出一個近似連續的系統映像。前面也講到，最終使用網絡的用戶，經常提出的訴求也是建立在對一個時間連續數據的訴求上。比如：昨天下午三點前后的網絡如何如何。應對這種顯然帶有滯后性的連續分析需求，一個最大密度的連續記錄還原當時網絡場景的能力，就是所有分析系統的數據基礎。

2.空間維度

在傳統分層結構的網絡架構中，由于出口網關、骨干路由器、核心交換機和匯聚交換機等設備的存在，要提取網絡中的流量，在物理結構上相對容易。在網絡出口鏡像或者分光，可以解決南北向數據提取的問題，在核心交換機的鏡像功能則可以解決絕大部分的東西向流量采集。

隨著5G和云網絡技術的普及，一切都發生了根本性改變。絕大多數的政企網絡已經完成或正在經歷從單一園區網，向移動化、多分支化和云化的邁進。一個總部、多個云、眾多分支和移動辦公的普及，已經變成了網絡管理人員所要面臨的常態。單點鏡像分光能解決的問題，已經退化到了只能解決為數很少的骨干網節點，其他位置已經失去了基本的存在可能。在這種網絡結構下，多分支多點逐跳采集、云南北向采集、云東西向采集和移動端數據采集，就成了當前全流量采集首先要面對的基礎問題。

3.成本維度

如果說時間和空間維度，解決的是技術問題，那么成本維度就是戰略問題。一條1Gb的物理鏈路，在全流量記錄下，通常每天會消耗超過10TB的存儲。當今是一個流量爆炸的時代，一個家寬都動輒500M，那我們面對10G、40G、100G甚至T級別骨干網的時候，存儲成本讓全流量何以自處？

以我們多年研究網絡原始流量的經驗來看，一個經驗豐富的數據分析師，在配有較為強大的數據分析工具前提下，一天能處理的原始數據量達到1TB就是極限。換句話說，1Gb鏈路一天產生的流量，如果要做到同步分析，需要10個有經驗的分析師才能在滯后一天完成。與看起來高昂的存儲成本相比，這才是全流量所要面對的最大成本——你會被淹死在數據的海洋里！ 

PART3三個境界

鋪陳許多，現在就來解剖一個全流量系統的邏輯模塊，來闡述全流量系統的境界差異。從邏輯結構上，可以將任意一個全流量系統拆分為采集、預處理、在線分析、數據包存儲、離線分析五個部分，通過一張圖來展示如下。

• 云化多分支采集

與傳統的單點分層網絡結構相比，云化多分支的網絡結構有了比較大的變化，整個云化分支網絡的六大采集點包括：總部網絡出口、分支網絡出口、數據中心出口、云網絡南北向出口、云東西向流量和移動用戶接入數據。要實現真正的“全流量”采集，就需要覆蓋到以上的所有采集點，這種情況下，需要各種實體和虛擬化探針的加持才能完成。

• 預處理引擎

采集后的流量需要先進入預處理引擎，預處理引擎再根據規則丟棄一些流量。丟棄多少流量，丟棄哪些流量，取決于在線分析引擎的實際輸入需求，也取決于預處理引擎的分析能力。預處理引擎對性能要求高，一般采用ASIC、FPGA、DPU/SmartNIC和DPDK/eBPF等技術架構簡單過濾方式，比如：根據IP地址、端口丟棄包，剩下的部分流量穿透到在線分析引擎。

• 在線分析引擎

在線分析引擎接收預處理引擎給到的流量，并根據分析目標的不同將所有流量生成不同種類的摘要，然后將生成的摘要作為索引送到數據包存儲引擎。后續再根據索引做分析，每個索引種類會對應不同的全流量設備。常見的摘要類型包括：告警、會話、文件和元數據。IDS、IPS、WAF、SoC等產品對應的索引是告警；NPM、流分析、溯源、威脅情報和DDoS等產品則使用會話作為處理依據和索引；防病毒、APT、內容審計類的全流量分析，則更多依賴的是還原的文件。元數據本質上是更高一個維度的索引儲備，在生成的那一刻只是代表未來可能會要求被快速提供，并不即刻就對應一個結果。例如：HTTP協議的UserAgent字段元數據，經常會被用來事后追溯一種特殊的HTTP客戶端，用于離線分析，但是在生成提取的時候并沒有確切的結果。

• 數據包存儲引擎

數據包存儲是全流量分析的重要組成部分，與傳統的數據分析不同的是，全流量數據存儲需要存儲原始數據報文。1Gb帶寬的實時流量，每天就會產生10TB的原始數據包。面對海量數據的存儲，對數據庫的選擇、數據的區分、索引的創建、內存的分配、文件格式、緩存以及中間表都有更高的要求。最終所有的數據組成大的存儲矩陣，為了方便提取，優秀的索引管理也就尤為重要。

• 離線分析引擎

離線分析引擎的主要針對已經存儲好數據包內容和索引進行分析和處理，需要有豐富的進一步深度解碼數據包、報表和分析模型創建能力。為了保障分析的準確性，離線分析引擎可以根據原始數據進一步更新索引表內容，例如以一個新解析的元數據類型重構索引，同時還需要具備文件還原、數據重放、場景回滾等能力。離線分析引擎還需要提供對外接口，用于和其它產品或數據庫對接，常見的比如Hadoop原始文件接口、Kafka消息接口等。 

要量化的評價一個全流量系統基礎能力，可以有三個參數，或說是全流量的三個境界：

境界一：輸入全部（C0=1）：擁有俯視一個已完成云化和多分支化的網絡的能力，在任何時刻都可以按需完成對其中云化多分支六大采集點的流量采集和回傳，是全流量的第一個目標。能采集的流量和要害節點總流量的比例，就是評價系統能力的第一個參數C0。C0的取值范圍為[0,1]，越接近1，說明采集輸入的能力越強。

境界二：分析全部（C1=1）：任何品類的在線分析引擎，在物理硬件限制下都有兩個確定參數：生成摘要的種類和最大處理能力。基于摘要的種類和處理能力，可以反推預處理引擎需要基于哪些規則，來丟棄不處理的流量。被預處理引擎保留不丟棄的流量和輸入預處理引擎的總流量的比例，是評價系統能力的第二個參數C1。C1的取值范圍為[0,1]，越接近1，說明在線分析引擎的性能越強勁，需要預處理引擎干預的越少。

境界三：記錄全部（C2=1）：基于在線分析引擎建立的摘要，指令數據包存儲引擎來保存哪些原始數據包。同時，這個記錄的能力受限于存儲管理模塊的性能和硬件設備的寫入瓶頸。所有記錄的原始數據，都必須是基于摘要可回溯的。實際存儲的原始數據包流量和發送到在線分析引擎的流量比例，是評價系統能力的第三個參數C2。C2的取值范圍為[0,1]，越接近1，說明記錄和回溯原始數據的能力越強。 

PART4未來到哪里去

4.1軟件定義的云化多分支采集

在上一章里提到的C0值，理論上C0=1最佳，但是要在現網中實現園區出口、企業出口、政府出口、云南北向出口、云東西向流量等等點位的采集，面臨著極大的挑戰。當離散的采集點過多時，探針成本問題、專線成本問題、數據分析問題會接踵而至。

探針成本的問題，不僅來自于部署探針點位的多少，更在于各類數據分析產品的探針無法通用，導致探針存在重疊部署。探針采集到的全量數據回傳至總部，需要大量的網絡帶寬，所以帶寬成本也高居不下。假設預算充足，以上問題均已得到有效解決，但是從海量的數據中提取有價值的信息堪比大海撈針。因此，所有流量采集點部署全部的檢測能力并全部回傳，從來都是一個永遠不可完成的任務。

因此，未來全流量的采集必須進行優化。首先，在采集部署上要事先預判采集節點的重要性，戰略上放棄部分無用點位流量。其次，探針要具備良好的兼容性，可以和主流的各類安全分析產品對接，減少采集點重復性投入。最后在采集方式上要有豐富的篩選條件，拋棄無用的數據采集。而這一切的篩選條件、采集時間等規則，必須可以方便的全網同步和軟件定義。

4.2跨越到應用層的流量預處理

從上一章可以得出，用戶的實際場景需求決定了預處理的需求，也決定了C1值的大小。因此流量預處理的判斷精度要實現三層到應用層的轉變，僅僅依靠IP、端口等方式進行篩選難以完成此重任。舉例說明：例如用戶使用的是WAF產品，在預處理過程中則可以丟棄所有非Web訪問，但是有大量非80/443端口的Web流量，不能用依據端口的規則進行丟棄，要細化到應用級別。再例如用戶使用的是APT產品，需要在已知流量中尋找異常，丟棄是不允許的，比如有未知協議使用53端口，如果依據端口規則直接丟棄，則會失去對異常流量的判斷能力。如果面對海量的數據輸入時，可以通過增加硬件，集群化部署來緩解預處理引擎的壓力，擁有云原生的橫向擴展能力，而不是簡單地使用ASIC、FPGA等應用層處理能力低下的快速篩選。

4.3在線元數據“全”分析

全流量分析產品的在線分析引擎，首先要保證強大的處理性能，其次是保證數據分析的全量。在線分析引擎要基于會話或是元數據創建索引，同時又兼容文件、告警等多種交叉索引方式，真正實現C2=1。在線分析引擎每多一種索引，就增加一個網絡分析的維度，同時也加大一次引擎的性能消耗，如何在索引和性能之間取得更好的折中是在線分析的最大難題之一。簡單如Netflow，復雜如幾千種元數據的實時采集建模。索引的選取，直接決定了最終的產品類型，交叉索引則產生更有戲劇性的結果，比如最近頗為流行的APT分析產品。在實時展示方面，要設置豐富的篩選條件，支持多級的數據檢索能力，同時保障元數據快速的檢索能力。

在線分析引擎的傳統硬件部署方式，雖然可以解決流量吞吐問題，但是靈活性較差。為了更好的適應網絡的發展，其一定要具備云原生的彈性擴展能力。在公有云、私有云以及混合云市場蒸蒸日上的大環境下，和在線分析引擎本身一樣，探針和數據庫也需要具備云原生彈性擴展能力。

4.4持續優化的包存儲引擎

經過在線分析引擎輸出的數據隨時有可能會被用戶讀取，如果采用隨機存儲的方式，那么對于用戶讀取數據來說，會變得相當困難。

【舉例說明：以開頭的故事為例，運維人員想要快速查詢“昨天下午14:00-14:30之間，A分支至總部的視頻會議時延超過300ms的會話有哪些”。】

面對這樣的多緯度分組聚合查詢，需要有很多方面的優化，比如：

• 時序存儲減少硬盤存儲碎片

對采集的數據進行時序存儲，并采用固定塊大小，固定文件個數，輪詢覆蓋最老文件，減少硬盤存儲碎片。

• 使用內存進行數據壓縮

通過內存進行原始數據壓縮，減少硬盤存儲文件的數量，達到存儲性能提升的目的，并且使用內存進行數據壓縮，并不會消耗太多性能，畢竟壓縮文件是內存的強項。

• 元數據、原始數據包分級存儲

將元數據與原始數據包的分級存儲，元數據存在SSD上面，原始數據包存在機械硬盤上面。以此保證索引信息的快速查詢，又不會因為原始數據包過多，造成用戶硬盤存儲成本的增加。

• 建立廣泛的索引

對海量的數據處理，對大表建立索引是必行的，建立索引要考慮到具體情況，例如針對大表的分組、排序等字段，都要建立相應索引，一般還可以建立復合索引。

• 存儲的彈性化部署

如果是對云南北向出口或是云東西向的流量進行存儲時，為了減少中間鏈路的傳輸壓力，原始數據的存儲將會放到云端，因此，數據包存儲引擎也必須支持云化的彈性部署。

除了存儲方式的優化，該部分還要具備原始數據包的回放能力，被回放的數據一般會用于對接第三方的安全產品。數據回放可以復原當時網絡的真實情況，方便運維人員對故障或是安全事件的分析。

4.5 離線智能化分析

離線分析引擎的后分析能力，主要在于強大的數據建模能力和事先由在線分析引擎建立的索引，可以設定豐富的分析模型和報表能力，甚至更深度的數據包解碼分析。本質上，這是一種再賦能的過程，賦能可以包括深度，也可以包括廣度。與在線分析引擎更多關注網絡的已知問題不同，離線分析引擎是發現網絡未知威脅和問題的重要手段，其主要價值體現在以下兩點：

• 在已知中尋找異常

所謂大隱隱于市，異常的通信內容隱蔽偽裝在常用協議中，是很多惡意應用的常用手段。離線分析引擎需要對已經識別的協議，根據協議、目標去向、域名、URL、DNS請求、用戶身份、地理位置、UA等元數據，建立數據倉庫，然后再根據它們的波動、差分、排序等統計規律尋找異常變化，最后對鎖定的異常變化會話數據進行深度的原始數據分析，就會到很多問題的答案。

• 在未知中排除正常

通常情況下，被在線分析引擎確定為未知的協議數據有三種：小眾協議、已知協議數據的漏識別以及廣泛使用的非正常協議。在離線引擎種，可以利用同目標其他識別結果的交叉校驗，排除大量已知協議數據情況，然后再結合交叉地理位置、使用頻度等情況，剩余的小眾協議和廣泛使用的非正常協議就會快速的浮出水面。值得一提的是，兩種協議分別是APT類未知威脅發現和黑產類未知威脅發現的重點分析目標。

PART5選擇需要慧眼

在現實中，并不存在一個“完美”的全流量系統。前述C0、C1、C2和索引的選擇，可以用于評價一個全流量系統的目標和現實水平。

從采集完整度講，C0=1是理想目標，但其面臨的是六大離散的采集點的復雜度，成本和管理復雜度都是大問題，C0值需要根據具體任務目標靈活設定。例如：只是監控和保護服務器，C0=0.15就是可以接受的選擇，而如果目標是全網態勢感知，監控全部分支內外通信，則C0必須大于0.8以上，否則從數據樣本就已滿盤皆輸。困擾大部分全流量系統的是在線分析引擎的性能，而C1決定的預處理引擎，可以極大消減輸入的數據數量。C1的取值某種程度上體現出對在線分析引擎能力的信心，但是依據任務不同，的確有很多的流量是可以不用注入在線分析引擎。例如：對WAF來說，非HTTP/HTTPS的流量就是無謂的性能浪費。C2越大，則意味著原始痕跡越多，離線分析引擎進行再貼標簽和回滾問題的幾率越大。

誠然，世界上并沒有絕對完美的全流量產品，但是全流量產品的種類會越來越豐富，與用戶網絡的結合度也會越來越高。自己定義的目標，決定了全流量產品選擇的優劣。大多數人都是又懶又蠢的，只要稍微用點心，稍微努力點，就能比大多數人做得更好一點。為了不和又蠢又懶的人為伍，大家在定義自己想要的全流量系統時，可以問自己四個問題：

我想要的采樣能力C0為多少？

我想要主動丟棄的流量C1為多少？

我想要建立的實時索引種類有哪些？

我想留存的數據包C2對應的時間長度和空間存儲為多少？

（本文來自：Panabit，作者小月月）