態勢感知（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）,否則可能出現數據偏差，例如：

snmpwalk -v 2c -c public -u username 192.168.1.10 ifHCInOctets
IF-MIB::ifHCInOctets.1 = Counter64: 5020760
IF-MIB::ifHCInOctets.2 = Counter64: 12343743
IF-MIB::ifHCInOctets.3 = Counter64: 7123
IF-MIB::ifHCInOctets.21 = Counter64: 3854

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 中復制信息，包含來源及目的地、服務的種類等字段：

1. Source and destination IP address
2. Input and output interface number
3. Source and destination port number
4. Layer 4 Protocol
5. Number of packets in the flow
6. Total Bytes in the flow
7. Time stamp in the flow
8. Source and destination AS
9. 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:關于網絡數據包的捕獲、過濾和分析

wireshark應用案例：TCP Window Zero

在企業應用中，網絡監測數據通常需要與基礎監控平臺融合才能發揮最大價值（開源的方案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

• 安全威脅情報服務，通過信息共享渠道了解識別攻擊者的來源、類型和安全廠商確認情況，做到知己知彼。