淺談基於數據分析的網路態勢感知

01-29

態勢感知（Situational Awareness，SA）的概念最早在軍事領域被提出。20世紀80年代，美國空軍就提出了態勢感知的概念，覆蓋感知（感覺）、理解和預測三個層次。90年代,態勢感知的概念開始被逐漸被接受，並隨著網路的興起而升級為「網路態勢感知（Cyberspace Situation Awareness，CSA）」，指在大規模網路環境中對能夠引起網路態勢發生變化的安全要素進行獲取、理解、顯示以及最近發展趨勢的順延性預測，而最終的目的是要進行決策與行動。本文將圍繞以下話題討論網路態勢感知中的幾個常見問題：

網路感知的基礎:網路分層、感測器
網路分析技術：SNMP、NetFlow、sFlow、NetStream、Packet Capturing
網路數據可視化: WireShark、NTopng、Ganglia、GeoIP

一、網路感知的基礎

1、沒有任何一個感測器是全能的

測量一個網路的一般步驟如下：首先獲得網路拓撲圖，網路的連接方法、潛在的觀察點列表等；然後確定潛在觀察點，確定該位置所能看到的流量；最後，確定最優的覆蓋方案。在複雜網路中，沒有任何一個感測器能夠全面覆蓋，需要多種感測器配合使用。按照採集的領域，感測器可以分為三類：

網路：入侵檢測系統（IDS）、NetFlow採集器、TCP採集器（如tcpdump）
主機：駐留在主機上，監控主機上的活動（文件訪問、登錄註銷）、網卡流量
服務：郵件消息、特定服務的HTTP請求

2、網路分層對感測器的影響

總的來說，網路感測器的焦點是OSI模型中的第2層～第4層，而服務感測器的焦點是第5層及以上。分層對網路流量的影響中，還需要考慮最大傳輸單元（MTU）：數據幀尺寸的上限，影響到介質中可以傳送的封包的最大尺寸，乙太網的MTU為1500位元組，即IP封包不會超過這個尺寸。OSI模型第5層會話層需要考慮的情況是會話加密，加密後的信息無法直接理解；在第6層和第7層中，必須知道協議細節，才能提取有意義的信息。

二、網路分析技術

網路流量反映了網路的運行狀態，是判別網路運行是否正常的關鍵。如果網路所接收的流量超過其實際運載能力，就會引起網路性能下降。網路中流量的各種參數主要包括：接收和發送數據報、丟包率、數據報延遲。

1、SNMP

SNMP（ Simple Network Management Protocol )包含一個應用層協議（application layer protocol）、資料庫模型（database schema），和一組數據對象。SNMP的第一個RFC系列出現在1988年(RFC1065-1067)，第二版（RFC1441–1452）作了修訂，由於第二版的新安全系統被認為過於複雜而不被廣泛接受，因此出現了兩個方案：SNMP v2c（基於社區，RFC1901–1908）、SNMP v2u(基於用戶，RFC1909–1910)。SNMP第三版（RFC3411-3418）主要增加了安全性方面的強化：信息完整性，保證數據包在發送中沒有被竄改；認證，檢驗信息來自正確的來源；數據包加密，避免被未授權的來源窺探。

基於SNMP協議定義的計數器：ifInOctets、ifOutOctets，兩次採樣的差值除以間隔時間即可獲得平均流量。需要注意的是計數器的數據類型有兩種：counter32和counter64。counter32計數的最大值是2的32次方減1，當超過4G的時候，計數器就會清零。如果是大流量、高精度採樣（間隔時間低於1分鐘），需要考慮使用counter64（ifHCInOctets、ifHCOutOctets）,否則可能出現數據偏差，例如：

2、RMON

SNMP是基於TCP/IP、應用最廣泛的網管協議，但是也有一些明顯的不足，如：SNMP使用輪詢方式採集數據信息，在大型網路中輪詢會產生巨大的網路管理通訊報文；不支持管理進程的分散式管理，它將收集數據的負擔加在網管站上，網路管理站會成為瓶頸；只能從這些管理信息庫中獲得單個設備的局部信息，標準管理信息庫MIB-II(RFC1213)和各廠家的專有MIB庫主要提供設備埠狀態、流量、錯誤包數等數據，要想獲得一個網段的性能信息是比較困難。

因此IETF提出了RMON（Remote Network Monitoring，RFC2021）以解決SNMP所面臨的局限性。RMON 由 SNMP MIB 擴展而來，網路監視數據包含了一組統計數據和性能指標，它們在不同的監視器（或稱探測器）和控制台系統之間相互交換。它可以主動地監測遠程設備，對設備埠所連接的網段上的各種流量信息進行跟蹤統計，如某段時間內某網段上報文總數等。只要給予探測器足夠的資源，它還可以對數據設備進行防防性監視，設備主動地對網路性能進行診斷並記錄網路性能狀況，在發生故障時可以把信息及時通知管理者，相關信息分為統計量、歷史、告警、事件等四個組，可以預置規則。

3、NetFlow vs sFlow vs NetStream

NetFlow最早由 Cisco 研發的流量匯總標準，最初用於網路服務計費，本意不是為了流量分析和信息安全。它通過路由器提供收集IP網路流量的能力，分析的NetFlow數據（UDP packets）感知網路流量和擁塞情況。NetFlow的核心概念流（Flow），NetFlow直接從 IP Packet 中複製信息，包含來源及目的地、服務的種類等欄位：

Source and destination IP address
Input and output interface number
Source and destination port number
Layer 4 Protocol
Number of packets in the flow
Total Bytes in the flow
Time stamp in the flow
Source and destination AS
TCP_Flag & TOS

NetFlow vs IPFIX NetFlow 的主力實現版本是 v5，但是 v5 主要針對 IPv4 存在很多限制，因此 Cisco 推出了基於模版的 NetFlow v9 。在NetFlow v9 的基礎上，IETF在2008年發布了標準化的 IPFIX( Internet Protocol Flow Information eXport)（RFC5101/5102），IPFIX 提供了幾百種流欄位。另外，Juniper也有一套自己的標準 J-Flow 。

sFlow (Sampled Flow, 採樣流，RFC3176 )是另一種一種基於報文採樣的網路流量監控技術，主要用於對網路流量進行統計分析。sFlow 2001年由lnMon公司提出來，目前是IEFE的一個開放標準，可提供完整的第二層到第四層、全網路範圍內的流量信息。sFlow 關注的是介面的流量情況、轉發情況以及設備整體運行狀況，因此適合於網路異常監控以及網路異常定位，通過 Collector 可以以報表的方式將情況反應出來，特別適合於企業網用戶。sFlow Agent內嵌於網路設備中，在 sFlow 系統中收集流量統計數據發送到 Collector 端供分析。

NetStream 是H3C定義的一套網路流量的數據統計方法。它需要由特定的設備支持，首先由設備自身對網路流進行初步的統計分析，並把統計信息儲存在緩存區。值得注意的是，NetStream（IPv6）功能需要跟華為購買License，並且NetStream功能和sFlow功能不能同時在同一介面板上配置。如果介面板已經配置sFlow功能，則不能配置NetStream功能。

綜上所述，各種 NetFlow 方案都是基於網路硬體設施生成或者軟體封包為流，不同的廠商標準不同，尤其需要考慮兼容性。同時，各種機制都可能對硬體造成性能問題，特別是舊的型號存在更大的風險，一般不輕易開啟。無論是硬體（中高端設備）還是軟體（nProbe、nDPI）、NetStream（IPv6），都意味著昂貴的費用，需要充分考慮成本預算。

4、NetFlow的其它替代方案

基於軟體替代路由採集，基本都是採用封包的思路，將pcap文件當作數據源或者直接從網路介面上封包，通過解析Header聚合成流格式或者更豐富的輸出。常見的產品如下：

CERT YAT(Yet Another Flowmeter)
softflowd
QoSient Argus

5、協議和用戶識別

我們可以把數據包想像成一封信。根據解析數據報報頭的內容，可以分析IP地址、埠號、協議、報文格式等特徵，分類後可以實現對各種應用層協議的準確識別，如P2P（迅雷）、即時通信（QQ、微信）、VPN、郵件等。當然，這隻能算是「淺度」的數據包檢測，就好像是看看信封上的發件人和收件人。

「深度」的數據包檢測，可以理解成對信件內容的探查──相比起暴力打開信封，這種基於機器學習的技術更具有藝術性。它並不實際解讀數據包的內容，而是搜集周邊信息，對數據流進行「肖像刻劃」（Profiling）。國內某研究團隊曾發表論文「網路流量分類，研究進展與展望」，文章提到了多種使用機器學習進行「深度數據包檢測」（Deep Packet Inspection，DPI）的技術。對「牆」有興趣的同學可以深入了解,http://riboseyim.github.io/2017/05/12/GFW/ 。

三、網路數據可視化

1、面向流向分析的可視化

文中開頭我們就提到測量網路的第一步就是獲得網路拓撲圖，如果要獲得全局角度實時感知能力，需要在拓撲的基礎之上疊加通過各種網路分析技術獲得的流量/Flow/事件等信息，進而處理分析網路異常流量。能夠實用的數據分析具有相當的複雜性，需要專門的工具軟體，區分正常流量數據和異常流量數據、對於「異常模式」的演算法訓練都有一定門檻，因此存在大量的開源和商業解決方案。

2、面向故障診斷的可視化

抓包工具：tcpdump、TShark、 WinDump
圖形化工具：wireshark(客戶端)、ntopng(webUI)
自定義編程：R、Python(Python-Scapy)、Graphviz工具包

一個典型的故障場景：兩個服務之間發生故障、無法收發信息，可以通過tcpdump的抓包，並將抓包結果在WireShark上分析，基於染色的方式通信失敗的報文被高亮提示。TCP通信中客戶端向服務端發送tcp zero window（表示沒有window可以接收新數據），如果出現該特徵一般可以確定故障是由接收端伺服器TCP緩衝區佔滿的引起，應將排查方向鎖定在接收端。關於網路數據包的捕獲、過濾、分析的具體實現細節，可以參考：Packet Capturing:關於網路數據包的捕獲、過濾和分析

在企業應用中，網路監測數據通常需要與基礎監控平台融合才能發揮最大價值（開源的方案Zabbix/Ganglia/Nagios／Graphite等）。Collectd與Ganglia是競爭關係，都是C語言開發,數據輸出都是RRDTool，性能應該差不多，Collectd不包含圖形化組件。zabbix是覆蓋面比較廣的綜合套件，除了採集還有告警等其它管理功能，專業性和大規模應用方面可能就不太強。Nagios在思路方面比較接近zabbix,走的是綜合性路子，側重於告警方案：「Ganglia is more concerned with gathering metrics and tracking them over time while Nagios has focused on being an alerting mechanism.」在Ganglia項目中提供了一個 gmond_proxy 可以搭配 sFlow-RT 支持 NetFlow／sFlow 的數據收集，如果是自己實現 sFlow-RT 類似的組件也需要考慮對 Logstash/splunk的支持。

3、面向安全分析的可視化

流向&協議：Ntopng
地理位置服務，根據IP地址確定改地址的物理位置信息（坐標）：MaxMind GeoIP
安全威脅情報服務，通過信息共享渠道了解識別攻擊者的來源、類型和安全廠商確認情況，做到知己知彼。