Network Traffic Analysis (NTA) 可以描述為檢查網絡流量以表征所使用的常見端口和協議的行為，為我們的環境建立基線，監控和應對威脅，并確保對我們組織的網絡有最大程度的了解。

此過程可幫助安全專家及早發現網絡中的異常情況（包括安全威脅），并有效地查明威脅。網絡流量分析還可以促進滿足安全準則的要求。攻擊者頻繁更新策略以規避檢測，并使用大多數公司允許在其網絡中使用的工具來利用合法憑據，這使得檢測和隨后的響應對防御者來說極具挑戰性。在這種情況下，網絡流量分析再次證明其作用。NTA 的日常用例包括：

試想一下，一個威脅行為者瞄準并滲透我們的網絡。如果他們想要攻破網絡，攻擊者必然會與我們的基礎設施進行交互和通信。網絡通信通過許多不同的端口和協議進行，所有這些端口和協議都被員工、設備和客戶同時使用。為了發現惡意流量，我們需要利用我們對自身區域內典型網絡流量的了解。這樣做可以縮小搜索范圍，并幫助我們快速發現并阻止敵對通信。

例如，如果我們SYN在網絡中從未（或很少）使用的端口上檢測到許多數據包，我們就可以得出結論，這很可能是有人試圖確定我們主機上哪些端口是開放的。此類行為是典型的惡意行為portscan。進行此類分析并得出此類結論需要特定的技能和知識。

所需技能和知識

我們即將列出和描述的技能需要長期積累的理論和實踐知識。我們不必熟記所有內容，但當某些內容看起來不熟悉時，我們應該知道該尋找什么。這不僅適用于NTA，也適用于我們在網絡安全中處理的大多數其他主題。

TCP/IP 堆棧和 OSI 模型

這種理解將確保我們掌握網絡流量和主機應用程序如何交互。

基本網絡概念

要了解每個層級上會出現哪些類型的流量，需要理解構成 TCP/IP 和 OSI 模型的各個層級，以及交換和路由的概念。如果我們在骨干鏈路上接入網絡，會看到比平時多得多的流量，這與在辦公室交換機上接入網絡時看到的流量截然不同。

常用端口和協議

快速識別標準端口和協議并從功能上了解它們的通信方式將確保我們能夠識別潛在的惡意或畸形的網絡流量。

IP 數據包和子層的概念

了解 TCP 和 UDP 通信的基礎知識至少能確保我們理解所見或所搜索的內容。例如，TCP 是面向流的，使我們能夠輕松跟蹤主機之間的對話。UDP 速度很快，但不注重完整性，因此很難從這種數據包類型中重建某些內容。

協議傳輸封裝

每一層都會封裝上一層。能夠讀取或分析封裝何時發生變化將有助于我們更快地處理數據。根據封裝頭信息很容易找到提示。

環境與設備

以下列表包含許多可用于執行網絡流量分析的不同工具和設備類型。每種工具和設備都提供不同的流量捕獲或解析方式。有些工具提供復制和捕獲的方式，而另一些則提供讀取和提取的方式。本模塊將僅探討其中幾種（主要是Wireshark和tcpdump）。請記住，這些工具并非專門為管理員設計的。其中許多工具也可能被用于惡意目的。

常見的流量分析工具

BPF 語法

上面提到的許多工具都有各自的語法和命令可供使用，但它們之間有一個共同點，那就是伯克利包過濾器 (BPF)語法。我們將主要使用這種語法。本質上，BPF 是一種允許原始接口從數據鏈路層進行讀寫的技術。考慮到所有這些，我們之所以關注 BPF，是因為它提供了過濾和解碼功能。我們將在本模塊中使用 BPF 語法，因此了解 BPF 過濾器的基本設置方法會很有幫助。有關 BPF 語法的更多信息，請參閱此參考資料。

執行網絡流量分析

執行分析可以像在我們的控制臺中觀看實時流量一樣簡單，也可以像使用水龍頭捕獲數據一樣復雜，將其發送回 SIEM 進行提取，并分析 pcap 數據以獲取與常見策略和技術相關的簽名和警報。

為了進行被動監聽，我們至少需要連接到想要監聽的網段。 在交換環境中尤其如此，因為 VLAN 和交換機端口不會將流量轉發到其廣播域之外。因此，如果我們希望捕獲特定 VLAN 的流量，我們的捕獲設備應該連接到同一網絡。諸如網絡分接頭之類的設備、Span 端口之類的交換機或路由器配置以及端口鏡像可以讓我們獲取流經特定鏈路的所有流量的副本，無論該流量屬于哪個網段或目標。

NTA工作流程

流量分析并非一門精確的科學。網絡流量分析 (NTA) 可能是一個非常動態的過程，并非一個直接的循環。它很大程度上受到我們所尋找的內容（網絡錯誤還是惡意操作）以及我們對網絡的可見性的影響。執行流量分析可以提煉出一些基本原則。

NTA工作流程

網絡 - 第 1-4 層

本節將快速回顧網絡知識，以及我們在執行流量捕獲時可以看到的一些標準協議的工作原理。 這些概念是捕獲和解析流量的核心。 如果不了解典型的網絡流程以及所使用的端口和協議，我們就無法準確分析捕獲的任何流量。

OSI / TCP-IP 模型

上圖并排展示了開放系統互連 ( OSI) 模型和傳輸控制協議 - 互聯網協議 ( TCP-IP) 模型。這兩個模型以圖形方式展示了聯網計算機之間如何處理通信。讓我們花點時間比較一下這兩個模型：

在研究這兩個模型時，我們會注意到 OSI 模型比 TCP-IP 模型更加細分。這是因為它被分解成更小的功能塊。OSI 模型的第一層到第四層專注于控制主機之間的數據傳輸。這種控制涵蓋了從用于傳輸的物理介質到用于管理數據傳輸過程中對話（或不對話）的協議的方方面面。 第五層到第七層負責對呈現給最終用戶的封裝數據進行解釋、管理和呈現。 OSI 模型可以理解為萬物運作背后的理論，而 TCP-IP 模型則更貼近網絡的實際功能。TCP-IP 模型則更加融合，規則也更加靈活。TCP-IP 模型包含四層，其中 OSI 模型的第五層、第六層和第七層與 TCP-IP 模型的第四層相對應。第三層負責傳輸，第二層是互聯網層，與 OSI 模型中的網絡層相對應，第一層是鏈路層，涵蓋了 OSI 模型的第二層和第一層。

在本模塊中，我們將學習許多不同的協議數據單元 ( PDU，Protocol Data Units)，因此需要對其在理論上和實際應用中的功能性理解。PDU 是由 OSI 模型中各層封裝的控制信息和數據組成的數據包。下面的分解部分將展示這兩個模型中的各層如何與 PDU 進行匹配。

在檢查 PDU 時，我們需要牢記封裝的概念。隨著數據在協議棧中向下移動，每一層都會將前一層的數據封裝在一個我們稱之為封裝的新氣泡中。這個氣泡會將該層的必要信息添加到 PDU 的報頭中。這些信息可能因層級而異，但都包含前一層的數據、操作標志、協商通信所需的任何選項、源 IP 地址和目標 IP 地址、端口、傳輸層協議以及應用層協議。

上圖并排展示了 PDU 的構成以及 Wireshark 數據包詳細信息窗格中數據包的分解。請注意，在 Wireshark 中查看分解時，順序是相反的。Wireshark 反向顯示 PDU，因為它的順序與解封裝時的順序一致。

尋址機制

既然我們已經了解了驅動網絡行為的基本概念，接下來讓我們花點時間討論一下如何將數據包傳送到正確的主機。我們首先從媒體訪問控制 (MAC) 地址開始。

MAC地址

連接到主機的每個邏輯或物理接口都有一個媒體訪問控制 ( MAC) 地址。該地址是一個 48 位six octet地址，以十六進制格式表示。如下圖所示，紅色箭頭處就是一個示例

MAC 尋址用于the data-link or link-layer depending on which model you look at主機之間的第二層 ( ) 通信。它通過廣播域內的主機間通信實現。如果第二層流量需要跨越第三層接口，則該 PDU 將被發送到第三層出口接口，并路由到正確的網絡。在第二層，這看起來像是將 PDU 發送到路由器接口，路由器在確定下一步將其發送到何處時會考慮第三層地址。一旦做出選擇，它會剝離第二層的封裝，并用指示路由中下一個物理地址的新信息替換它。

IP 尋址

互聯網協議 ( IP) 的開發是為了跨越網絡邊界，將數據從一個主機傳送到另一個主機。IP 負責路由數據包、封裝數據，以及在數據報到達目標主機后對其進行分片和重組。IP 本質上是一種無連接協議，無法保證數據一定能夠到達預期的接收者。為了確保數據傳輸的可靠性和有效性，IP 依賴于 TCP 等上層協議。目前，IP 主要有兩個版本：IPv4（當前主流標準）和 IPv6（旨在取代 IPv4）。

IPv4

最常見、最熟悉的尋址機制是互聯網協議地址版本 4 (IPv4)。IPv4 尋址是跨網絡將數據包路由到我們周邊區域以外的主機的核心方法。下圖中綠色箭頭所示的是一個 IPv4 地址示例。

IPv4 地址由一個 32 位的四字節數字組成，以十進制格式表示。在我們的示例中，我們可以看到地址 192.168.86.243。IP 地址的每個八位字節可以用一個從 0 到 255 的數字表示。在檢查 PDU 時，我們會在 OSI 模型的第三層（網絡層）和 TCP-IP 模型的第二層（互聯網層）找到 IP 地址。我們不會在這里深入探討 IPv4，但為了本模塊的目的，我們先了解一下這些地址是什么，它們的作用是什么，以及它們在哪一層使用。

IPv6

在使用 IPv4 十多年后，我們發現可用的 IP 地址池很快就耗盡了。由于大量地址被劃分為特殊用途或私有地址，全球的可用空間很快就被耗盡了。為了解決這個問題，我們采取了兩項措施。首先是實施可變長度子網掩碼 (VLSM) 和無類別域間路由 (CIDR)。這使我們能夠重新定義 v4 格式的可用 IP 地址，從而改變地址分配給用戶的方式。其次是創建并持續開發 IPv6 作為 IPv4 的后續版本。

IPv6 為我們提供了更大的地址空間，可用于任何網絡用途。IPv6 是一個 128 位地址，以十六進制格式表示，包含 16 個八位字節。下圖中藍色箭頭所示的是一個縮短的 IPv6 地址示例。

除了更大的地址空間外，IPv6 還提供：更好地支持多播（將流量從一個設備發送到多個設備）；每臺設備全局尋址；以 IPSec 形式實現的協議內部安全性；簡化的數據包報頭，使處理和在連接之間移動更加輕松，而無需重新分配地址。 IPv6 在其架構中使用四種主要類型的地址：

IPv6 尋址類型

在思考每種地址類型時，記住單播流量是主機到主機的，多播是一對多的，而任播是群組中的一對多，只有一個會應答數據包（類似負載平衡）。 盡管 IPv6 目前比 IPv4 具有許多優勢，但其普及速度卻很慢。

IPv6的采用

在撰寫本文時，根據谷歌發布的統計數據，全球采用率僅為 45% 左右。

TCP/UDP，傳輸機制

傳輸層擁有多種機制，有助于確保數據從源到目標的無縫傳輸。不妨將傳輸層視為一個控制中心。來自較高層級的應用數據必須沿著協議棧向下傳輸到傳輸層。該層指示如何封裝流量并將其發送到較低層級的協議（IP 和 MAC）。數據到達目標接收者后，傳輸層將與網絡層協議協同工作，按正確的順序重新組裝封裝的數據。用于完成此任務的兩種機制是傳輸控制協議 (TCP) 和用戶數據報協議 (UDP)。

TCP VS. UDP

通過查看上表，我們可以看到 TCP 和 UDP 提供了兩種截然不同的數據傳輸方式。TCP 被認為是一種更可靠的協議，因為它允許將錯誤檢查和數據確認作為常規功能。相比之下，UDP 是一種快速、即發即棄的協議，最適合于我們更注重速度而非質量和驗證的情況。

具體來說，TCP 用于傳輸對完整性而非速度要求更高的數據。例如，當我們使用安全外殼 (SSH) 從一個主機連接到另一個主機時，會打開一個連接，該連接在您發出命令和執行操作時保持活動狀態。這是 TCP 的一項功能，確保我們與遠程主機的對話不會中斷。如果由于某種原因中斷，TCP 不會重新組裝數據包的部分片段并將其發送給應用程序。我們可以通過這種方式避免錯誤。如果我們在遠程主機上執行類似 sudo passwd user 的命令來更改用戶密碼，并且在更改過程中部分消息丟失，會發生什么情況？如果通過 UDP 進行傳輸，我們將無法知道該消息的其余部分發生了什么，并可能弄亂用戶的密碼，甚至發生更糟的情況。TCP 協議通過確認收到的每個數據包來幫助防止這種情況發生，以確保目標主機在組裝命令并將其發送給應用程序執行操作之前已獲取每個數據包。

另一方面，當我們需要快速響應或使用對速度而非完整性要求更高的應用程序時，UDP 就是我們的答案。以流式傳輸視頻為例。用戶不會注意到流式傳輸視頻中丟失了一兩個像素。 我們更關心的是觀看視頻，而不是讓它不斷停下來緩沖下一個片段。另一個例子是 DNS。當主機請求 inlanefreight.com 的記錄條目時，該主機希望快速響應以繼續其正在執行的進程。如果 DNS 請求被丟棄，最糟糕的情況是它會被重新發出。這沒有損害，也沒有犯規。用戶不會因為這種丟棄而收到損壞的數據。 UDP 流量看起來像常規流量；它是一個單獨的數據包，沒有響應或確認已發送或接收，因此這里沒有太多可展示的內容。但是，我們可以看看 TCP 以及它是如何建立連接的。

TCP 三次握手

TCP 確保數據從服務器傳輸到客戶端的方法之一是利用會話。這些會話通過所謂的三次握手建立。為了實現這一點，TCP 在 TCP 報頭中使用了一個名為“標志”的選項。我們現在不會深入探討 TCP 標志；只需了解三次握手中常見的標志是同步 ( SYN) 和確認 ( ACK)。當主機請求通過 TCP 與服務器進行對話時；

讓我們快速看一下它的運行情況，以便在模塊稍后出現在數據包輸出中時熟悉它。

檢查此輸出時，我們可以在第一行看到握手的開始。查看紅框中突出顯示的信息，我們可以看到初始 Syn 標志已設置。如果我們查看綠色下劃線的端口號，我們可以看到兩個數字：57678 和 80。第一個數字是客戶端正在使用的隨機高端口號，第二個數字是服務器用于監聽傳入 Web 請求連接的 HTTP 公認端口。在第二行，我們可以看到服務器向客戶端發送了一個 SYN/ACK 數據包，該數據包發送到相同的端口。在第三行，我們可以看到客戶端確認了服務器的同步數據包以建立連接。

數據包 4 顯示 HTTP 請求已發送，并且已建立會話以流式傳輸所請求圖像的數據。我們可以看到，隨著數據流的繼續，TCP 會對發送的每個數據塊發送確認。這是一個典型的 TCP 通信示例。

我們已經了解了如何使用 TCP 建立會話；現在，讓我們研究一下如何結束會話。

TCP 會話拆除

實際上應該是四次揮手

詳細可以看我的這篇文章Nginx開發實戰——網絡通信（一）Wireshark監視數據包

網絡 - 第 5-7 層

我們已經了解了底層網絡的功能，現在讓我們看看一些處理應用程序的上層協議。維護網絡連接并確保數據在主機之間傳輸需要許多不同的應用程序和服務。本節將概述其中幾個重要的協議。

HTTP

超文本傳輸協議 (HTTP) 是一種無狀態的應用層協議，自 1990 年開始使用。HTTP 支持通過 TCP 在客戶端和服務器之間以明文傳輸數據。客戶端會向服務器發送 HTTP 請求，請求資源。會話建立后，服務器會響應請求的媒體（HTML、圖像、超鏈接、視頻）。HTTP 在正常操作期間通過 TCP 使用端口 80 或 8000。在特殊情況下，可以修改為使用其他端口，有時甚至使用 UDP。

HTTP 方法

要執行諸如獲取網頁、請求下載項目或發布最新推文等操作，都需要使用特定的方法。這些方法定義了請求 URI 時執行的操作。方法：

請注意，我們在每個方法旁邊都列出了必需或可選。根據標準要求，GET 和 HEAD 必須始終與標準 HTTP 實現兼容并存。這僅適用于它們。trace、options、delete、put 和 post 方法則是可選功能，可以允許使用。例如，只讀網頁（例如博客文章）。客戶端 PC 可以從頁面請求資源，但不能修改、添加或刪除資源。

有關 HTTP 作為協議及其運作方式的更多信息，請參閱 RFC:2616。

HTTPS

HTTP 安全協議 (HTTPS) 是對 HTTP 協議的一種改進，旨在利用傳輸層安全性 (TLS，Transport Layer Security) 或安全套接字層 (SSL，Secure Sockets Layer) 與舊應用程序配合使用，以保障數據安全。TLS 是一種加密機制，用于保護客戶端和服務器之間的通信。TLS 可以將常規 HTTP 流量封裝在 TLS 中，這意味著我們可以加密整個會話，而不僅僅是發送或請求的數據。在 TLS 機制出現之前，我們很容易受到中間人攻擊和其他類型的偵察或劫持攻擊，這意味著與客戶端或服務器位于同一局域網中的任何人如果在線監聽，都可以查看網絡流量。現在，我們可以在瀏覽器中實施安全措施，使每個人都可以加密他們的網絡行為、搜索請求、會話或數據傳輸、銀行交易等等。

盡管 HTTPS 是基于 HTTP 的，但它使用 443 和 8443 端口，而不是標準的 80 端口。這是一種客戶端向服務器發出信號以表明其希望建立安全連接的方式。讓我們看一下 HTTPS 流量的輸出，并了解一下 TLS 握手是如何運作的。

通過 HTTPS 進行 TLS 握手

在前幾個數據包中，我們可以看到客戶端使用藍色方框中標示的 443 端口與服務器建立了會話。這向服務器發出信號，表明它希望使用 HTTPS 作為應用程序通信協議。

通過 TCP 發起會話后，接下來會發送 TLS ClientHello 消息，開始 TLS 握手。在握手過程中，雙方會協商幾個參數，包括會話標識符、對端 x509 證書、要使用的壓縮算法、密碼規范加密算法（如果會話可恢復），以及客戶端和服務器之間共享的用于驗證會話的 48 字節主密鑰。

會話建立后，所有數據和方法都將通過 TLS 連接發送，并顯示為紅色方框中所示的 TLS 應用程序數據。 TLS 仍然使用 TCP 作為傳輸協議，因此我們仍然會看到來自流的確認數據包通過端口 443 發送。 握手過程總結：

加密本身是一個復雜而冗長的話題，值得專門寫一個模塊來闡述。本節簡單概述了 HTTP 和 TLS 如何在 HTTPS 應用協議中提供安全性。有關 HTTPS 的工作原理以及 TLS 如何執行安全操作的更多信息，請參閱 RFC:2246。

FTP

文件傳輸協議 (FTP) 是一種應用層協議，支持在計算設備之間快速傳輸數據。FTP 可以通過命令行、Web 瀏覽器或圖形化 FTP 客戶端（例如 FileZilla）使用。FTP 本身被認為是一種不安全的協議，大多數用戶已轉而使用 SFTP 等工具通過安全通道傳輸文件。展望未來，大多數現代 Web 瀏覽器已于 2020 年逐步停止支持 FTP。

當我們考慮主機之間的通信時，我們通常會想到客戶端和服務器通過單個套接字進行通信。通過此套接字，客戶端和服務器都通過同一條鏈路發送命令和數據。在這方面，FTP 的獨特之處在于它同時使用多個端口。FTP 通過 TCP 使用端口 20 和 21。端口 20 用于數據傳輸，而端口 21 用于發出控制 FTP 會話的命令。在身份驗證方面，FTP 支持用戶身份驗證，并且如果已配置，還允許匿名訪問。

FTP 能夠以兩種不同的模式運行：主動模式和被動模式。主動模式是 FTP 的默認操作方式，這意味著服務器會監聽來自客戶端的控制命令 PORT，該命令指示使用哪個端口進行數據傳輸。被動模式使我們能夠訪問位于防火墻后面或啟用了 NAT 的鏈路（這些鏈路無法建立直接 TCP 連接）的 FTP 服務器。在這種情況下，客戶端會發送 PASV 命令，并等待服務器的響應，告知客戶端使用哪個 IP 地址和端口進行數據傳輸通道連接。

FTP 命令和響應示例

上圖展示了幾個通過 FTP 命令通道發出的請求（綠色箭頭）以及從 FTP 服務器返回的響應（藍色箭頭）的示例。這些都是非常標準的操作。要查看每個命令及其功能的列表，請查看下表。

查看 FTP 流量時，我們可以看到通過端口 21 傳遞的一些常見命令包括：

FTP 命令

以上并非可能出現的 FTP 控制命令的詳盡列表。這些命令可能因所使用的 FTP 應用程序或 Shell 而異。有關 FTP 的更多信息，請參閱 RFC:959。

SMB

服務器消息塊 (SMB) 是 Windows 企業環境中最常用的協議，它支持通過常見的網絡架構在主機之間共享資源。SMB 是一種面向連接的協議，要求主機向資源進行用戶身份驗證，以確保用戶擁有使用該資源或執行操作的正確權限。過去，SMB 使用 NetBIOS 作為通過 UDP 端口 137 和 138 的傳輸機制。經過現代化的改進，SMB 現在支持通過端口 445 的直接 TCP 傳輸、通過 TCP 端口 139 的 NetBIOS 傳輸，甚至支持 QUIC 協議。

作為用戶，SMB 使我們能夠輕松便捷地訪問打印機、共享驅動器、身份驗證服務器等資源。因此，SMB 對潛在攻擊者也極具吸引力。

與任何其他使用 TCP 作為傳輸機制的應用程序一樣，它會執行標準功能，例如三次握手和確認收到的數據包。讓我們花點時間了解一些 SMB 流量，以便熟悉它。

SMB 線路

從上圖可以看出，每次建立會話時，橙色框中的端口都會執行 TCP 握手。查看藍色框中的源端口和目標端口，可以看到端口 445 正在被使用，這表明 SMB 流量通過 TCP 進行。查看綠色框中的信息字段，可以了解到 SMB 通信中發生的情況。此示例中存在許多錯誤，值得深入研究。用戶身份驗證失敗一兩次的情況比較常見，但大量錯誤重復出現可能表明潛在的未經授權的用戶試圖訪問用戶的帳戶或使用其憑據進行移動。這是攻擊者常用的策略，他們會獲取已通過身份驗證的用戶，竊取其憑據，利用這些憑據進行橫向移動，或訪問通常被拒絕訪問的資源。

這只是 SMB 使用情況的一個例子。我們經常看到的另一個情況是服務器和主機之間的文件共享訪問。在大多數情況下，這是常規通信。但是，如果我們看到一個主機訪問其他主機上的文件共享，則這種情況并不常見。請注意誰在請求連接、去往何處以及他們在做什么。

之后我會持續更新，如果喜歡我的文章，請記得一鍵三連哦，點贊關注收藏，你的每一個贊每一份關注每一次收藏都將是我前進路上的無限動力 ！！！↖(▔▽▔)↗感謝支持！