博客 / 詳情

返回

TryHackMe-SOC-Section 7:網絡安全監控

目錄
  • Sestion 7:網絡安全監控
    • 網絡安全監控基礎知識
      • 介紹
      • 網絡概覽
        • 網絡組件——網絡的基本組成部分
        • 小型企業網絡
        • 用户工作站(端點)
        • 文件和數據庫服務器
        • 應用服務器(Web、電子郵件、VPN等)
        • 活動目錄(AD)/身份驗證服務器
        • 路由器和交換機(網絡基礎設施)
        • 防火牆/邊界設備
      • 網絡可見性
        • 以主機為中心的日誌
          • 關鍵主機中心日誌源
        • 網絡中心日誌
          • 關鍵網絡中心日誌源
      • 網絡邊界
        • 邊界
        • 網絡邊界的重要性
        • 小型企業中的網絡邊界
        • 為什麼這很重要
        • 安全分析師的角色
      • 網絡邊界:監控與保護
        • 監控邊界
        • 監控邊界行動
        • 場景 1:探測端口(端口掃描)
        • 場景二:攻擊Web服務器(SQL注入)
        • 場景 3:猜測密碼(VPN 暴力破解)
      • 邊界日誌:調查此次入侵事件
        • 事件場景
        • 調查日誌
          • 方法一:人工日誌分析
          • 偵察嘗試
          • VPN暴力破解/憑證訪問
          • 橫向移動
          • C2信標
          • 數據泄露企圖
          • 方法二:通過 Splunk 分析日誌
      • 結論
    • 網絡發現檢測
      • 網絡發現
        • 攻擊者和網絡發現
        • 防禦者和網絡發現
        • 檢測網絡發現的挑戰
      • 外部掃描與內部掃描
        • 外部掃描活動
        • 內部掃描活動
        • 識別內部掃描和外部掃描
      • 水平掃描與垂直掃描
        • 水平掃描
        • 垂直掃描
      • 掃描機制
        • Ping 掃描
        • TCP SYN 掃描
        • UDP掃描
        • 識別掃描類型
    • 數據泄露檢測
        • 介紹
      • 數據泄露:概述、技術和指標
        • 攻擊者為何要進行數據竊取
        • 威脅行為者及其數據竊取技術
        • 與滲出相關的常見階段
        • 技術與指標
      • 檢測:通過 DNS 隧道進行數據泄露
        • DNS隧道
        • 攻擊跡象
        • 通過 Wireshark 進行檢測
        • 查找過長的查詢(可疑的子域名長度)
        • 使用 Splunk 進行調查
        • 長查詢名稱(子域名編碼)
      • 檢測:通過FTP泄露數據
        • 攻擊者如何利用FTP進行數據竊取
        • 攻擊跡象
        • 識別有效載荷較大的流量
      • 檢測:通過 HTTP 進行數據泄露
        • 為什麼這很重要
        • 攻擊者如何利用HTTP進行數據竊取
        • 攻擊指標 (IoA)
          • 常用網絡指標
        • 在 Splunk 中分析日誌
        • 網絡流量分析
          • 過濾 HTTP 流量
      • 檢測:通過 ICMP 進行數據泄露
        • 敵方如何利用ICMP進行數據竊取
        • Wireshark中的攻擊指標
    • 中間人攻擊檢測
      • 介紹
      • 中間人攻擊概述
        • 中間人攻擊的工作原理
        • 常見的中間人攻擊類型
        • 真實案例
        • 中間人攻擊和網絡殺傷鏈
        • 將中間人攻擊置於網絡殺傷鏈中
      • 檢測 ARP 欺騙
        • 什麼是ARP協議
        • ARP欺騙
        • 攻擊指標
        • 網絡信息
        • 網絡流量分析
          • 縮小 ARP 流量範圍
          • ARP請求
          • ARP響應
          • 免費ARP響應
          • 與網關相關的ARP流量
          • 檢查可疑的 MAC 地址
          • 檢查重複的 IP 地址到 MAC 地址映射
      • 揭露DNS欺騙
        • 簡化的DNS協議
        • 攻擊指標
        • 網絡流量分析
          • 縮小 DNS 流量範圍
          • 過濾合法流量
          • 檢查DNS響應
          • 來自 DNS 服務器的 DNS 響應
          • 對我們域名的DNS請求
          • 除了DNS服務器之外的其他DNS響應。
        • 分析概要
      • 發現 SSL 剝離攻擊
        • 工作原理
        • SSL剝離的指標
        • 網絡流量分析
          • 縮小SSL 流量範圍
          • 檢查我們服務器的SSL流量。
          • 顯示剝離之前的 DNS 重定向。
          • 驗證 TLS 是否消失
        • 概括
    • IDS基礎知識
      • 什麼是IDS
      • IDS的類型
        • 部署模式
        • 檢測模式
      • IDS 示例:Snort
      • Snort的模式
      • Snort的使用
        • 規則格式
        • 規則創建
        • 規則測試
        • 在 PCAP 文件上運行 Snort
      • 實踐實驗室
    • Snort
      • 介紹
      • IDS/IPS簡介
        • 入侵檢測系統(IDS)
        • 入侵防禦系統(IPS)
        • 檢測/預防技術
        • 概括
        • Snort
      • 與 Snort 的初次互動
      • 操作模式 1:嗅探模式
      • 操作模式 2:數據包記錄器模式
      • 操作模式 3:IDS/IPS
      • 操作模式 4:PCAP 調查
      • Snort 規則結構
      • Snort2 操作邏輯:要點回顧
        • Snort規則

Sestion 7:網絡安全監控

網絡安全監控基礎知識

瞭解網絡安全基礎知識的關鍵方面,以及如何監控和防禦攻擊者。

介紹

網絡是所有現代組織的支柱。服務器、工作站、應用程序和安全設備並非孤立存在,而是相互連接,形成一個完整的生態系統。網絡邊界將這個內部生態系統與外部互聯網隔離開來,因此它往往是攻擊者的首要目標。

  • 學習目標
    在這個房間裏,我們將涵蓋以下學習目標:
    • 瞭解什麼是網絡並識別其關鍵組成部分。
    • 探討網絡邊界的概念及其重要性。
    • 識別關鍵的周邊威脅。
    • 檢查防火牆日誌,監控正常日誌和可疑日誌。

網絡概覽

在瞭解網絡安全方面之前,重要的是要了解什麼是網絡,它由哪些組件或資產構成,以及它們是如何工作的。

網絡組件——網絡的基本組成部分

計算機網絡並非只是設備的隨機集合;它是一個有組織的結構,網絡資產通過該結構連接起來,實現彼此之間以及與世界的通信、資源共享和連接。

小型企業網絡

從安全角度來看,瞭解這些設備的功能及其重要性有助於快速識別可疑活動。我們以小型企業網絡為例,瞭解其關鍵組件、用途以及它們在安全方面的重要性:
500

用户工作站(端點)

員工日常工作都在工作站(台式電腦、筆記本電腦)上進行。然而,這些工作站也是攻擊者最常見的入侵途徑,攻擊者通常通過網絡釣魚郵件或惡意下載進行攻擊。

  • 例如:一封釣魚郵件在金融用户的電腦上植入惡意軟件。
  • 重要性:終端通常較少受到監控,但一旦終端被攻破,攻擊者就能以此為跳板橫向移動。

重要性

端點日誌可以揭示惡意進程,但網絡日誌可能首先顯示C2(命令與控制)連接。

文件和數據庫服務器

這些服務器存儲着企業最重要的資產——數據。文件服務器提供對共享文檔的集中訪問,而數據庫服務器則管理結構化數據,例如客户記錄、人力資源信息或財務數據。

重要性

攻擊者通常會以這些服務器為目標,因為攻破這些服務器意味着可以獲取寶貴或敏感的數據。特別是勒索軟件運營者,他們會專門攻擊文件服務器以最大化其影響。數據竊取活動通常涉及將這些服務器上的數據悄悄轉移到網絡之外。

應用服務器(Web、電子郵件、VPN等)

這些服務器提供員工和客户每天都依賴的服務。

  • 網絡服務器:託管公司網站和網絡應用程序。
  • 電子郵件服務器:處理公司內部通信。
  • VPN網關:允許對內部資源進行安全的遠程訪問。

重要性

由於應用服務器面向外部,因此它們是高價值的攻擊目標。攻擊者會不斷掃描它們,尋找軟件漏洞或配置缺陷。一旦利用了這些漏洞,攻擊者往往就能進入內部網絡。

從安全角度來看,我們需要監控應用程序日誌、防火牆警報和入侵檢測系統 (IDS)簽名,以識別:

  • 攻擊嘗試(例如,對 Web 應用程序進行SQL注入)。
  • 對電子郵件或VPN服務進行暴力破解登錄嘗試。
  • 可疑的外部IP地址與敏感應用程序進行交互。
活動目錄(AD)/身份驗證服務器

Active Directory 是大多數企業網絡的身份管理核心。它管理用户、組、計算機及其訪問權限。員工使用其AD憑據登錄計算機、訪問電子郵件、文件服務器和內部應用程序。

重要性

  • AD是控制網絡內所有用户帳户和系統的主要組件。
  • 攻擊者通常會以AD為目標,進行權限提升、持久化和橫向移動。
  • 一個被攻破的域管理員賬户就可能導致整個企業癱瘓。

從安全角度來看,我們需要監控身份驗證日誌,以發現可疑行為,例如:

  • 多次登錄失敗(密碼噴灑攻擊)。
  • 來自外部IP 地址或在非正常時間的異常登錄。
  • 賬户訪問了它們通常不應該訪問的系統。
路由器和交換機(網絡基礎設施)

路由器連接不同的網絡,其中最重要的是將企業局域網連接到互聯網。交換機連接同一網絡內的設備,確保員工的電腦、打印機和服務器能夠無縫通信。這些設備構成了企業的運轉系統。

重要性:
雖然路由器和交換機在大多數企業環境中並不直接暴露在外,但如果遭到入侵,攻擊者可以:

  • 攔截和操縱網絡流量(中間人攻擊)。
  • 通過重新路由流量創建後門。
  • 開通通往互聯網的隱藏通道。
防火牆/邊界設備

防火牆是控制可信內部網絡與不可信互聯網之間流量的主要安全網關。它會檢查傳入和傳出的數據包,並根據預定義的安全規則決定是否允許或阻止它們。現代防火牆還能對應用程序進行深度檢查、入侵防禦,甚至檢測惡意軟件。

重要性:

  • 保護企業免受直接互聯網攻擊。
  • 防止未經授權訪問內部服務(例如數據庫或RDP)。
  • 記錄每一次連接嘗試,無論成功與否。這些日誌通常是攻擊(例如端口掃描、暴力破解或漏洞利用)的最早跡象。

現在我們已經瞭解了什麼是網絡,哪些組件連接起來形成網絡,以及它們的用途和重要性,讓我們進入下一個任務,探索關鍵的網絡邊界。

網絡可見性

網絡可視性在網絡安全中至關重要。它指的是監控和了解整個網絡運行狀況的能力。這是安全分析師的核心原則:你無法防禦你看不見的東西。有效的可視性能夠實現威脅檢測、事件調查和強大的安全態勢。這並非意味着跟蹤每一個數據包,而是擁有構建清晰網絡圖景的工具。缺乏可視性,你將對潛在威脅視而不見。

網絡可見性主要來源於兩個日誌來源。您必須瞭解它們之間的區別,才能有效地拼湊出攻擊時間線。


為什麼提高曝光度至關重要?

想象一下,如果房子沒有窗户或監控攝像頭,我們該如何保護它?一旦有人試圖闖入,我們可能根本察覺不到,直到為時已晚。網絡可視性就像我們數字環境的“眼睛”。如果沒有它,惡意軟件感染、未經授權的訪問和數據泄露等惡意活動就可能完全不被察覺。
有效的可視性使安全分析人員能夠:

  • 檢測異常情況: 發現可能表明遭受攻擊的異常模式。
  • 調查事件: 將襲擊事件的經過拼湊起來,以瞭解發生了什麼。
  • 威脅搜尋: 主動搜索網絡中隱藏的攻擊者。
  • 確保合規性: 通過記錄和監控網絡活動來滿足監管要求。

為了實現這一目標,我們主要依賴日誌,日誌記錄了網絡內部和各個設備上發生的事件。讓我們來詳細瞭解一下日誌來源的兩大類。

以主機為中心的日誌

300

主機日誌由網絡上的各個設備(主機)生成,例如服務器、工作站和筆記本電腦。這些日誌讓我們能夠詳細瞭解特定機器上發生的情況。它們對於理解攻擊對系統的直接影響至關重要。

關鍵主機中心日誌源
  • 操作系統日誌: Windows 事件日誌、Linux syslog日誌、macOS 日誌。這些日誌記錄用户登錄、進程創建、服務啓動和登錄失敗等事件。
  • 應用程序日誌: 主機上運行的軟件的日誌,例如 Web 服務器(Apache、Nginx)、數據庫(MySQL、MSSQL)和其他應用程序。
  • 安全工具日誌: 來自防病毒軟件、端點檢測和響應 ( EDR ) 代理和基於主機的入侵檢測系統 ( HIDS ) 的日誌。

主機中心日誌的重要性

這些日誌對於回答以下問題至關重要:

  • 詳細的取證分析: 瞭解攻擊者在受感染的機器上執行的確切操作,例如訪問、修改或刪除了哪些文件。
  • 進程和執行跟蹤: 識別惡意進程的創建、未經授權的腳本(如PowerShell)的執行以及系統服務的更改。
  • 用户活動監控: 追蹤登錄用户、登錄時間和使用的權限。這對於檢測外部攻擊和內部威脅至關重要。
  • 惡意軟件影響評估: 確認惡意文件是否已執行,以及它對系統註冊表、文件系統或正在運行的服務進行了哪些更改。

網絡中心日誌

主機日誌告訴我們設備上發生了什麼,而網絡日誌則告訴我們設備之間發生了什麼。這些日誌由位於網絡中的網絡設備生成,這些設備監控流經網絡的流量。

  • 它們顯示的內容:源IP地址和目標IP地址、端口、協議以及採取的操作(例如,允許或阻止)。
  • 它們的重要性在於: 它們能提供至關重要的“時間”、“地點”和“方式”。它們可以揭示攻擊者的初始偵察嘗試、系統間的橫向移動或數據竊取企圖。

要獲得完整的信息,你需要將兩者關聯起來。可以這樣理解:以主機為中心的日誌告訴你房間內發生了什麼,而以網絡為中心的日誌則告訴你誰進出過建築物。

300

關鍵網絡中心日誌源
  • 防火牆: 防火牆日​​志記錄了根據預定義的安全規則允許或拒絕的每一個連接。防火牆日誌是查找來自互聯網的未經授權連接嘗試的首要位置。
  • 入侵檢測/防禦系統(IDS / IPS): 它們監控網絡流量,尋找與已知惡意攻擊(特徵碼)相匹配的模式或異常行為。它們的日誌對於實時檢測活躍攻擊至關重要。
  • 路由器和交換機: 雖然路由器等設備不進行傳統意義上的日誌記錄,但它們可以生成流量數據。這些數據彙總了網絡流量的交互過程,包括通信雙方、通信時長以及數據傳輸量。它非常適合用來了解網絡活動的總體概況。
  • 網絡代理: 對於通過代理路由網絡流量的組織而言,這些日誌是一座金礦。它們記錄了每個網站用户的訪問情況,從而可以瞭解基於網絡的威脅、策略違規或數據泄露嘗試。
  • VPN: 這些設備用於管理員工的遠程訪問。它們的日誌會跟蹤誰在何時從何處連接到公司網絡,這對於監控遠程連接的安全性至關重要。

網絡中心日誌的重要性
網絡中心日誌的重要性網絡中心日誌提供了設備間以及網絡邊界內流量的高級概覽。它們對於以下方面至關重要:

  • 早期威脅檢測: 在網絡邊緣識別威脅,防止其危害終端設備。這包括阻止端口掃描、暴力破解嘗試以及來自已知惡意IP的連接。
  • 識別命令與控制(C2): 發現受感染的內部主機與外部攻擊者控制的服務器之間的通信模式。
  • 追蹤橫向移動: 觀察攻擊者在內部網絡中從一台受感染的機器移動到另一台受感染的機器。
  • 檢測數據泄露: 對異常大或可疑的出站數據傳輸發出警報,這可能表明存在數據泄露。
  • 提供廣泛的背景信息: 通過查看受感染主機嘗試與哪些其他設備通信來了解攻擊的範圍。

有效的安全監控依賴於對主機日誌和網絡日誌的雙重檢查。這種綜合方法使分析人員能夠構建出任何安全事件的完整、準確的時間線。

在本任務中,我們探討了網絡可見性,這是​​網絡安全的關鍵概念。在下一個任務中,我們將探討網絡邊界以及它們如何幫助我們監控和保護網絡。

網絡邊界

網絡邊界是將組織內部網絡(可信區域,例如員工、服務器、業務應用程序)與外部互聯網(非可信區域)分隔開來的界限。它是數據進出網絡的入口。您可以將其想象成安全建築物的大門或正門。所有來自互聯網的流量都必須經過此點才能進入您的網絡,所有內部流量也必須經過此點才能離開互聯網。網絡邊界是您的第一道也是最關鍵的防線。

  • 內部網絡是業務關鍵系統所在的位置。
  • 外部互聯網充滿了潛在威脅。
  • 周邊區域是所有車輛通行的受控入口。

對於安全分析師來説,瞭解安全邊界、其存在方式以及如何防禦至關重要。

邊界

網絡邊界由網絡邊緣的硬件設備定義。然而,在現代環境中,它還包括虛擬網關、雲連接和遠程接入點。

網絡邊界的常見組成部分包括:

  • 防火牆:過濾內部網絡和外部網絡之間流量的守門人。
  • 路由器/網關:用於路由流量和執行訪問規則的設備。
  • 非軍事區(DMZ ):放置面向公眾的服務器(Web、郵件、 VPN )的緩衝區網絡段。
  • 遠程訪問網關/VPN:為在辦公室外工作的員工提供安全的入口點。
網絡邊界的重要性

網絡邊界如同守門人,控制着網絡的進出。它並非單一設備,而是一系列安全控制措施和網絡組件的集合,共同保護內部資產免受外部威脅。這些組件在管理、過濾和保護內部網絡與外部網絡之間的數據流方面發揮着不同的作用。

攻擊者總是從外部開始探測。網絡邊界通常是第一道防線,也是安全運營中心(SOC)分析師最先發現惡意活動跡象的地方。

如果網絡邊界薄弱或配置錯誤,攻擊者可以:

  • 利用暴露的服務(例如RDP、MySQL、SMB)獲取訪問權限。
  • 執行掃描和偵察,繪製網絡地圖。
  • 對登錄服務發起暴力破解攻擊。
  • 利用數據泄露渠道發送竊取的數據。
小型企業中的網絡邊界

300

想象一下一個小型企業網絡:

  • 防火牆位於互聯網和內部局域網之間。
  • 為了讓客户能夠訪問網站,我們將網絡服務器放置在非軍事區 (DMZ)中。
  • 內部服務器(AD、文件和數據庫)位於防火牆後,只有員工才能訪問。
  • 辦公室外的員工通過VPN網關連接。

這種設置確保只有受控流量才能到達內部網絡,而公共服務則被隔離在更安全的區域中。

通常包括:

  • 路由器:直接傳輸網絡流量。
  • 防火牆:檢查和過濾網絡流量。
  • 非軍事區( DMZ):提供面向公眾的服務。
  • VPN網關:安全遠程訪問。
為什麼這很重要

網絡邊界是抵禦外部威脅的第一道防線。攻擊者會掃描邊界IP 地址,尋找開放端口和漏洞。配置錯誤或防護薄弱的網絡邊界通常會導致:

  • 未經授權的訪問(例如,暴露的RDP / SSH)
  • 數據泄露
  • 惡意軟件入侵
安全分析師的角色

作為安全分析師,監控網絡邊界意味着:

  • 查看防火牆日誌,確認是否存在被阻止/允許的連接。
  • 識別掃描嘗試或暴力破解登錄嘗試。
  • 標記可能表明存在惡意軟件信標或數據泄露的異常出站流量。
  • 瞭解周邊應該(和不應該)暴露哪些內容。

網絡邊界:監控與保護

在上一項任務中,我們討論了網絡邊界、其重要性以及它如何作為可信內部系統與外部互聯網之間的界限。攻擊者會不斷探測這條邊界,尋找薄弱環節。接下來,我們將探討各種場景,以及如何監控不同的網絡邊界,以識別威脅並加以防禦。

監控邊界

監控網絡邊界意味着使用防火牆、入侵檢測/防禦系統 ( IDS / IPS ) 和訪問控制來檢查和限制風險暴露,並強制執行安全規則。這使得安全分析人員能夠:

  • 及早發現攻擊,例如端口掃描或暴力破解嘗試。
  • 檢測導致敏感服務暴露的錯誤配置。
  • 識別可能表明存在惡意軟件或數據泄露的出站流量異常。

/Perimeter_logs/task6/以下場景中使用的邊界日誌可以在桌面上的文件夾中找到。

監控邊界行動

以下幾個場景説明了監控周邊環境的重要性。

場景 1:探測端口(端口掃描)

攻擊者正在測試您的網絡,查看哪些端口是打開的還是關閉的,而防火牆則在履行其職責並阻止這些端口。

防火牆日誌

2025-09-22 08:30:04 ALLOW TCP 198.51.100.45:49876 -> 10.0.0.51:80
2025-09-22 08:30:05 BLOCK TCP 203.0.113.10:50001 -> 10.0.0.20:21
2025-09-22 08:30:06 BLOCK TCP 203.0.113.10:50002 -> 10.0.0.20:22
2025-09-22 08:30:07 ALLOW TCP 192.0.2.115:51235 -> 10.0.0.50:443
2025-09-22 08:30:08 BLOCK TCP 203.0.113.10:50003 -> 10.0.0.20:23
2025-09-22 08:30:09 BLOCK TCP 203.0.113.10:50004 -> 10.0.0.20:25
2025-09-22 08:30:10 ALLOW TCP 198.51.100.92:51111 -> 10.0.0.50:443
2025-09-22 08:30:11 BLOCK TCP 203.0.113.10:50005 -> 10.0.0.20:53

日誌細分

  • 同一個外部 IP 地址 (203.0.113.10) 正在快速嘗試連接到同一台內部機器上的多個端口。
  • 分析師結論:這是一次典型的端口掃描。攻擊者正在尋找可以攻擊的開放服務。
場景二:攻擊Web服務器(SQL注入)

公司網站正遭受攻擊。入侵檢測系統 (IDS) 比防火牆提供更多詳細信息,可以識別攻擊類型。

WAF(Web應用程序防火牆)日誌

timestamp=2025-09-22T09:14:44Z src_ip=192.0.2.130 action=ALLOW request="GET /index.html"timestamp=2025-09-22T09:14:45Z src_ip=198.51.100.92 action=ALLOW request="GET /products.php?id=9"timestamp=2025-09-22T09:14:46Z src_ip=[REDACTED] action=BLOCK request="GET /search.php?q=<script>alert('XSS')</script>" rule_id=941100 attack_type="XSS"timestamp=2025-09-22T09:14:47Z src_ip=192.0.2.140 action=ALLOW request="GET /css/style.css"timestamp=2025-09-22T09:15:42Z src_ip=[REDACTED] action=BLOCK request="GET /../../../../etc/passwd" rule_id=930120 attack_type="Directory Traversal"........

日誌細分

  • 此日誌顯示了允許和阻止操作的混合情況。分析人員可以篩選 action=BLOCK 的操作,以便立即發現威脅。WAF 會完成繁重的工作,阻止請求並告知我們原因。
  • attack_type=" SQL Injection" 警報顯示攻擊者試圖轉儲數據庫信息。
  • attack_type=" XSS " 警報表示嘗試注入惡意腳本。
  • attack_type="Directory Traversal" 警報表明有人試圖讀取敏感的服務器文件。
  • 分析師結論:WAF成功識別並阻止了來自可疑IP地址的多種網絡攻擊類型。這是一個高度可信的警報,表明攻擊者正在積極攻擊該網站。
場景 3:猜測密碼(VPN 暴力破解)

攻擊者試圖猜測用户密碼以獲取對網絡的遠程訪問權限。這會在身份驗證日誌中產生大量噪聲。

VPN 網關日誌

2025-09-22 10:12:11 FAILED_AUTH TCP [REDACTED]:31245 -> 10.0.0.1:443 (user 'admin')
2025-09-22 10:12:15 FAILED_AUTH TCP [REDACTED]:31248 -> 10.0.0.1:443 (user 'admin')
2025-09-22 10:12:21 SUCCESS_AUTH TCP 198.51.100.88:41233 -> 10.0.0.1:443 (user 'b.jones')2025-09-22 10:12:08 FAILED_AUTH TCP [REDACTED]:31249 -> 10.0.0.1:443 (user 'guest')2025-09-22 10:12:09 FAILED_AUTH TCP [REDACTED]:31250 -> 10.0.0.1:443 (user 'user')

日誌細分

  • 日誌中充斥着 FAILED_AUTH 和 SUCCESS_AUTH 事件。
  • 來自不同IP地址的少量成功登錄是正常的。
  • 問題在於故障數量巨大。
  • 為了找到攻擊,分析人員會按源 IP 地址篩選或分組日誌。
  • 這樣做會立即揭示出,某個可疑用户在很短的時間內進行了數百次登錄失敗嘗試。
  • 分析師結論:檢測到一個可疑IP地址正在對VPN網關發起暴力破解攻擊。攻擊者試圖使用一系列常用用户名(例如“admin”、“root”、“test”等)來尋找可入侵的有效賬户。零星的成功登錄記錄均為合法員工的正常流量。

要點總結

  • 分析師的工作是將正常流量與可疑活動區分開來。
  • 留意可疑模式。
  • 從一個源到多個目的地的重複 = 掃描。
  • 從一個源到另一個目標的重複操作 = 暴力破解。
  • 流量以完美的、規律的時間間隔出現 = 惡意軟件信標。
  • 上下文至關重要。入侵檢測系統 (IDS)發出的警報,如果能告訴你某個漏洞被標記的原因,比簡單的防火牆攔截更有價值。
  • 監控網絡邊界是檢測攻擊的第一步。

查看防火牆日誌。哪個IP地址正在執行端口掃描?
head一下你會 發現有一個ip正在把端口+1的形式訪問,那就是掃描的動作

203.0.113.10

在 WAF 日誌中,哪個 單一源 IP 導致了所有被阻止的 Web 攻擊?
grep "BLOCK" waf_logs.txt | cut -d' ' -f 2 | cut -d= -f2 | uniq -c

198.51.100.12

VPN 日誌中,有多少次暴力破解嘗試失敗了?
grep "FAILED_AUTH" vpn_logs.txt | wc -l

90

哪個可疑 IP 地址被發現試圖對 VPN 網關發起暴力破解攻擊?
grep "FAILED_AUTH" vpn_logs.txt | cut -d' ' -f5 | cut -d: -f1 | sort -nr | uniq -c

45.137.22.13

邊界日誌:調查此次入侵事件

事件場景

Initech Corp是一家中型金融服務公司,最近部署了一套新的防火牆和入侵檢測系統(IDS)來監控其網絡邊界。過去一個月,安全分析師注意到異常的流量模式,但安全運營中心(SOC)團隊工作繁忙,未能進行更深入的分析。

作為一名新入職的安全分析師,你的任務是審查一個月的邊界日誌,以確定攻擊者使用了哪些技術,以及他們是否成功突破了邊界。

您已收到事件發生時的三份日誌文件。這些日誌文件Perimeter_logs/challenge位於桌面上的相應目錄中。

  • 防火牆日誌:firewall.log
  • WAF 日誌:ids_alerts.log
  • VPN日誌:vpn_auth.log

網絡資產

Initech Corp 的網絡包含以下資產。我們可以將其作為參考。

IP 主機名 角色 操作系統 團隊 臨界性
10.0.0.20 FINANCE-SRV1 文件/財務服務器(SMB) Windows Server 財務IT 高的
10.0.0.50 VPN -GW VPN網關 Linux 網絡運維 批判的
10.0.0.51 APP-WEB-01 內部網站/應用程序 Linux 應用團隊 高的
10.0.0.60 工作站-60 員工工作站 Windows 10 銷售量 中等的
10.8.0.23 VPN -客户端-攻擊 VPN分配客户端(臨時) 不適用 不適用 批判的
10.0.1.10 DMZ-WEB DMZ Web 服務器 Linux 網絡運維 中等的

調查日誌

有兩種方法可以查看日誌:手動使用命令行工具或使用 Splunk。
有關如何訪問 Splunk 實例的説明將在文末提供。

方法一:人工日誌分析

讓我們先來查看日誌,如下所示:

命令行: head firewall.log

ubuntu@tryhackme:~/Desktop/Perimeter_logs/challenge$ head firewall.log 
2025-08-25 00:47:46 ALLOW TCP [REDACTED]:60317 -> 10.0.0.50:443
2025-08-25 01:29:33 ALLOW TCP 203.0.113.100:62718 -> [REDACTED]:443
2025-08-25 01:42:12 ALLOW TCP 203.0.113.100:55875 -> [REDACTED]:80
2025-08-25 03:30:47 ALLOW TCP [REDACTED]:63035 -> [REDACTED]:80
2025-08-25 04:06:58 ALLOW TCP 192.0.2.115:65458 -> [REDACTED]:25
2025-08-25 05:51:36 ALLOW TCP 203.0.113.100:56035 -> [REDACTED]:53
2025-08-25 06:09:50 ALLOW TCP 198.51.100.92:63418 -> [REDACTED]:8080
2025-08-25 07:39:29 ALLOW TCP [REDACTED]:55955 -> [REDACTED]:8080
2025-08-25 08:24:34 ALLOW TCP 198.51.100.92:63475 -> [REDACTED]:8080
2025-08-25 08:57:21 ALLOW TCP 198.51.100.92:58636 -> 10.0.0.50:53

查看 ID 日誌,如下所示:

命令行: head ids_alerts.log

ubuntu@tryhackme:~/Desktop/Perimeter_logs/challenge$ head ids_alerts.log 
2025-08-25 00:12:53 [**] [1:2003272:1] ET POLICY Suspicious HTTP [**] [Classification: Suspicious Activity] [Priority: 3] {TCP} 198.51.100.92:20127 -> [REDACTED]:22
2025-08-25 01:50:30 [**] [1:2003377:1] ET POLICY Suspicious HTTP [**] [Classification: Suspicious Activity] [Priority: 1] {TCP} 203.0.113.100:56603 -> [REDACTED]:25
2025-08-25 02:16:39 [**] [1:2003437:1] ET INFO Possible Benign Scan [**] [Classification: Suspicious Activity] [Priority: 3] {TCP} [REDACTED]:62546 -> [REDACTED]:21
2025-08-25 02:23:07 [**] [1:2003344:1] ET WEB_SERVER Possible SQL Injection [**] [Classification: Suspicious Activity] [Priority: 2] {TCP} 198.51.100.45:12396 -> [REDACTED]:22
2025-08-25 02:25:48 [**] [1:2003445:1] ET POLICY Suspicious HTTP [**] [Classification: Suspicious Activity] [Priority: 3] {TCP} 192.0.2.115:3952 -> [REDACTED]:22
2025-08-25 03:35:00 [**] [1:2003160:1] ET INFO Possible Benign Scan [**] [Classification: Suspicious Activity] [Priority: 1] {TCP} [REDACTED]:38760 -> [REDACTED]:443
2025-08-25 05:02:36 [**] [1:2003187:1] ET WEB_SERVER Possible SQL Injection [**] [Classification: Suspicious Activity] [Priority: 1] {TCP} 198.51.100.92:46776 -> [REDACTED]:3389
2025-08-25 06:04:26 [**] [1:2003179:1] ET INFO Possible Benign Scan [**] [Classification: Suspicious Activity] [Priority: 2] {TCP} 198.51.100.92:20632 -> 10.0.0.50:8080
2025-08-25 14:12:11 [**] [1:2003500:1] ET INFO Possible Benign Scan [**] [Classification: Suspicious Activity] [Priority: 2] {TCP} 192.0.2.115:30225 -> [REDACTED]:445
2025-08-25 15:30:03 [**] [1:2003354:1] ET POLICY Suspicious HTTP [**] [Classification: Suspicious Activity] [Priority: 3] {TCP} 203.0.113.100:27572 -> [REDACTED]:4444

查看如下所示的 VPN 日誌:

命令行: head vpn_auth.log

ubuntu@tryhackme:~/Desktop/Perimeter_logs/challenge$  head vpn_auth.log 
2025-08-25 08:25:10 [REDACTED] alice SUCCESS assigned_ip=10.8.0.143
2025-08-25 08:27:38 203.0.113.100 svc_[REDACTED] SUCCESS assigned_ip=10.8.0.131
2025-08-25 14:57:10 203.0.113.10 svc_[REDACTED] SUCCESS assigned_ip=10.8.0.116
2025-08-25 23:04:53 203.0.113.10 jsmith SUCCESS assigned_ip=10.8.0.31
2025-08-26 03:36:17 198.51.100.92 svc_[REDACTED] SUCCESS assigned_ip=10.8.0.62
2025-08-26 08:55:14 [REDACTED] bob SUCCESS assigned_ip=10.8.0.126
2025-08-26 10:02:45 198.51.100.92 svc_[REDACTED] SUCCESS assigned_ip=10.8.0.81
2025-08-27 03:11:33 198.51.100.45 bob SUCCESS assigned_ip=10.8.0.163
2025-08-28 02:52:16 192.0.2.115 alice SUCCESS assigned_ip=10.8.0.132
2025-08-28 03:20:33 [REDACTED] svc_[REDACTED] SUCCESS assigned_ip=10.8.0.193
偵察嘗試

讓我們首先分析防火牆日誌中被阻止的請求,如下所示:

命令行: cat firewall.log | grep "BLOCK" | head

ubuntu@tryhackme:~/Desktop/Perimeter_logs/challenge$ cat firewall.log | grep "BLOCK" | head
2025-08-26 12:12:47 BLOCK TCP 203.0.113.10:64292 -> 10.0.0.50:21
2025-08-27 03:18:28 BLOCK TCP [REDACTED]:61701 -> [REDACTED]:23
2025-08-27 11:56:20 BLOCK TCP 203.0.113.10:64952 -> 10.0.0.50:22
2025-08-27 22:52:00 BLOCK TCP 203.0.113.10:63686 -> [REDACTED]:445
2025-08-28 10:00:00 BLOCK TCP [REDACTED]:50000 -> [REDACTED]:4444
2025-08-28 10:02:30 BLOCK TCP [REDACTED]:50005 -> [REDACTED]:22

檢查被阻止的請求表明,已發現外部 IP 使用各種端口(22、23、21、445、3389)探測內部 IP。

讓我們使用以下過濾方法來了解哪個 IP 地址導致了最多的 BLOCK 請求。

命令行: cat firewall.log | grep "BLOCK" | cut -d' ' -f5 | cut -d: -f1 | sort -nr | uniq -c

ubuntu@tryhackme:~/Desktop/Perimeter_logs/challenge$ cat firewall.log | grep "BLOCK" | cut -d' ' -f5 | cut -d: -f1 | sort -nr | uniq -c
279 [REDACTED]
46 203.0.113.10
26 [REDACTED]

我們已經發現了一個可疑的 IP 地址,我們可以利用它進行跳板操作,檢查其他日誌文件,並瞭解其中的關聯性。

讓我們使用以下查詢來查找我們的防火牆是否允許了對可疑 IP 地址的任何請求,如下所示:

命令行: cat firewall.log | grep [REDACTED] | grep "ALLOW"

ubuntu@tryhackme:~/Desktop/Perimeter_logs/challenge$ cat firewall.log | grep [REDACTED] | grep "ALLOW"
2025-08-26 00:17:58 ALLOW TCP [REDACTED]:61009 -> [REDACTED]:4444
2025-08-26 22:04:34 ALLOW TCP [REDACTED]:55996 -> 10.0.0.50:445
2025-08-27 21:04:23 ALLOW TCP [REDACTED]:53944 -> 10.0.0.50:22
2025-08-28 15:50:50 ALLOW TCP [REDACTED]:56123 -> [REDACTED]:3389
2025-08-30 20:26:23 ALLOW TCP [REDACTED]:61685 -> [REDACTED]:4444
2025-09-02 09:25:06 ALLOW TCP [REDACTED]:50550 -> 10.0.0.50:22  -----------
2025-09-22 15:46:02 ALLOW TCP [REDACTED]:59771 -> [REDACTED]:23
2025-09-22 17:22:11 ALLOW TCP [REDACTED]:49360 -> 10.0.0.50:22

攻擊者似乎利用漏洞入侵了內部網絡。我們來檢查一下 VPN 日誌,看看能否找到更多攻擊痕跡。

VPN暴力破解/憑證訪問

在 VPN 日誌中,我們首先使用以下命令檢查失敗嘗試次數,如下所示:

命令行: cat vpn_auth.log | grep FAIL | cut -d' ' -f3 | sort -nr | uniq -c

ubuntu@tryhackme:~/Desktop/Perimeter_logs/challenge$ cat vpn_auth.log | grep FAIL | cut -d' ' -f3 | sort -nr | uniq -c
118 [REDACTED]
1 203.0.113.100
1 198.51.100.92
1 198.51.100.45

我們可以清楚地看到,可疑 IP 地址有多次 VPN 登錄失敗的嘗試。現在,讓我們使用以下命令來縮小可疑 IP 地址的範圍,如下所示:

命令行: cat vpn_auth.log | grep [REDACTED]

ubuntu@tryhackme:~/Desktop/Perimeter_logs/challenge$ cat vpn_auth.log | grep [REDACTED]
2025-09-03 02:19:00 [REDACTED] svc_[REDACTED] FAIL
2025-09-03 02:19:10 [REDACTED] svc_[REDACTED] FAIL
2025-09-03 02:19:20 [REDACTED] svc_[REDACTED] FAIL
2025-09-03 02:19:30 [REDACTED] svc_[REDACTED] FAIL
--------
-----------
2025-09-03 02:19:40 [REDACTED] svc_[REDACTED] SUCCESS assigned_ip=[REDACTED]
2025-09-03 02:19:50 [REDACTED] svc_[REDACTED] SUCCESS assigned_ip=[REDACTED]
2025-09-04 16:45:24 [REDACTED] svc_[REDACTED] SUCCESS assigned_ip=10.8.0.181
2025-09-05 13:21:52 [REDACTED] jsmith SUCCESS assigned_ip=10.8.0.94
2025-09-09 17:54:00 [REDACTED] jsmith SUCCESS assigned_ip=10.8.0.187
2025-09-09 19:15:51 [REDACTED] jsmith SUCCESS assigned_ip=10.8.0.134
2025-09-10 12:24:20 [REDACTED] bob SUCCESS assigned_ip=10.8.0.39

上述結果表明,svc_REDACTED攻擊者對某個用户進行了多次登錄嘗試,最終成功登錄,並因此獲得了一個本地 IP 地址。我們將選取第一個被分配的 IP 地址,並進一步分析日誌文件中的相關痕跡。

橫向移動

現在已經確認,攻擊者已成功獲得初始訪問權限並控制了一個內部 IP 地址。讓我們查看防火牆日誌,看看能否找到從被入侵主機 IP 地址發起橫向移動的任何痕跡REDACTED

命令行: cat firewall.log | grep [REDACTED] | grep "ALLOW" | head

ubuntu@tryhackme:~/Desktop/Perimeter_logs/challenge$ cat firewall.log | grep [REDACTED] | grep "ALLOW" | head 
2025-09-05 06:00:00 ALLOW TCP [REDACTED]:2000 -> [REDACTED]:22
2025-09-05 06:10:00 ALLOW TCP [REDACTED]:2001 -> [REDACTED]:445
2025-09-05 06:20:00 ALLOW TCP [REDACTED]:2002 -> [REDACTED]:22
2025-09-05 06:40:00 ALLOW TCP [REDACTED]:2004 -> [REDACTED]:3389
2025-09-05 07:30:00 ALLOW TCP [REDACTED]:2009 -> [REDACTED]:22
2025-09-05 08:00:00 ALLOW TCP [REDACTED]:2012 -> [REDACTED]:22

據觀察,被入侵的 IP 地址正在探測內部機器10.0.0.20,在三個主要端口上的各個端口上10.0.0.51進行探測。 10.0.0.60``SMB/RDP/SSH (445/3389/22)

現在讓我們轉到 ids_alerts日誌,篩選被入侵的 IP 地址,看看能否找到任何被觸發的入侵規則,如下所示:

命令行: cat ids_alerts.log | grep [REDACTED] | head

ubuntu@tryhackme:~/Desktop/Perimeter_logs/challenge$ cat ids_alerts.log | grep [REDACTED] | head    
2025-09-05 06:00:00 [**] [1:2000200:1] ET SCAN Possible SSH Scan [**] [Classification: Attempted Unauthorized Access] [Priority: 1] {TCP} [REDACTED]:2000 -> [REDACTED]:22
2025-09-05 06:10:00 [**] [1:2000201:1] ET EXPLOIT Possible MS-SMB Lateral Movement [**] [Classification: Attempted Unauthorized Access] [Priority: 1] {TCP} [REDACTED]:2001 -> [REDACTED]:445
2025-09-05 06:20:00 [**] [1:2000202:1] ET SCAN Possible SSH Scan [**] [Classification: Attempted Unauthorized Access] [Priority: 1] {TCP} [REDACTED]:2002 -> [REDACTED]:22
2025-09-05 06:30:00 [**] [1:2000203:1] ET EXPLOIT Possible RDP Brute Force [**] [Classification: Attempted Unauthorized Access] [Priority: 1] {TCP} [REDACTED]:2003 -> [REDACTED]:3389
2025-09-05 07:10:00 [**] [1:2000207:1] ET SCAN Possible SSH Scan [**] [Classification: Attempted Unauthorized Access] [Priority: 1] {TCP} [REDACTED]:2007 -> [REDACTED]:22
2025-09-05 07:20:00 [**] [1:2000208:1] ET EXPLOIT Possible RDP Brute Force [**] [Classification: Attempted Unauthorized Access] [Priority: 1] {TCP} [REDACTED]:2008 -> [REDACTED]:3389
2025-09-05 07:30:00 [**] [1:2000209:1] ET SCAN Possible SSH Scan [**] [Classification: Attempted Unauthorized Access] [Priority: 1] {TCP} [REDACTED]:2009 -> [REDACTED]:22

看來,被入侵的主機正試圖利用上述主機上各種服務的漏洞。其中一條入侵檢測系統 (IDS) 警報顯示存在SMB漏洞利用,這很值得關注。讓我們使用以下搜索查詢來縮小搜索範圍:

命令行: cat ids_alerts.log | grep -n [REDACTED] | grep 'SMB' | cut -d' ' -f6,7,8,9,10,19,21 | head

ubuntu@tryhackme:~/Desktop/Perimeter_logs/challenge$ cat ids_alerts.log | grep -n [REDACTED] | grep 'SMB' | cut -d' ' -f6,7,8,9,10,19,21 | head
EXPLOIT Possible MS-SMB Lateral Movement [REDACTED]:2001 [REDACTED]:445
EXPLOIT Possible MS-SMB Lateral Movement [REDACTED]:2006 [REDACTED]:445
EXPLOIT Possible MS-SMB Lateral Movement [REDACTED]:2010 [REDACTED]:445
EXPLOIT Possible MS-SMB Lateral Movement [REDACTED]:2016 [REDACTED]:445
EXPLOIT Possible MS-SMB Lateral Movement [REDACTED]:2033 [REDACTED]:445
EXPLOIT Possible MS-SMB Lateral Movement [REDACTED]:2035 [REDACTED]:445

以上結果證實,被入侵的主機能夠利用SMB服務並實現橫向移動。

C2信標

現在我們已經掌握了攻擊者橫向移動的證據。接下來,我們來尋找任何與 C2 通信相關的跡象。查看入侵檢測系統 (IDS) 的警報,我們可以找到一條與 C2 信標相關的特定警報,這表明可能存在 C2 通信。讓我們使用以下搜索查詢來查看結果:

命令行: cat ids_alerts.log | grep C2 | head

ubuntu@tryhackme:~/Desktop/Perimeter_logs/challenge$ cat ids_alerts.log | grep C2 | head
2025-09-11 01:00:00 [**] [1:2001000:1] ET TROJAN Possible C2 Beaconing [**] [Classification: A network Trojan was detected] [Priority: 1] {TCP} [REDACTED]:30000 -> [REDACTED]:4444
2025-09-11 07:00:00 [**] [1:2001001:1] ET TROJAN Possible C2 Beaconing [**] [Classification: A network Trojan was detected] [Priority: 1] {TCP} [REDACTED]:30001 -> [REDACTED]:4444
2025-09-11 13:00:00 [**] [1:2001002:1] ET TROJAN Possible C2 Beaconing [**] [Classification: A network Trojan was detected] [Priority: 1] {TCP} [REDACTED]:30002 -> [REDACTED]:4444
2025-09-12 13:00:00 [**] [1:2001006:1] ET TROJAN Possible C2 Beaconing [**] [Classification: A network Trojan was detected] [Priority: 1] {TCP} [REDACTED]:30006 -> [REDACTED]:4444
2025-09-12 19:00:00 [**] [1:2001007:1] ET TROJAN Possible C2 Beaconing [**] [Classification: A network Trojan was detected] [Priority: 1] {TCP} [REDACTED]:30007 -> [REDACTED]:4444
2025-09-13 01:00:00 [**] [1:2001008:1] ET TROJAN Possible C2 Beaconing [**] [Classification: A network Trojan was detected] [Priority: 1] {TCP} [REDACTED]:30008 -> [REDACTED]:4444
2025-09-13 07:00:00 [**] [1:2001009:1] ET TROJAN Possible C2 Beaconing [**] [Classification: A network Trojan was detected] [Priority: 1] {TCP} [REDACTED]:30009 -> [REDACTED]:4444

這清楚地證實了我們對其中一台內部受感染主機的懷疑。

讓我們對結果進行細分,篩選出負責C2信標攻擊的被入侵 IP 地址,如下所示:

命令行: cat ids_alerts.log | grep -n [REDACTED]   | cut -d' ' -f6,7,8,9,10,19,22,23 | head -n 15

ubuntu@tryhackme:~/Desktop/Perimeter_logs/challenge$ cat ids_alerts.log | grep -n [REDACTED]   | cut -d' ' -f6,7,8,9,10,19,22,23 | head -n 15
POLICY Suspicious HTTP [**] [Classification:
WEB_SERVER Possible SQL Injection [**] [REDACTED]:3389
POLICY Suspicious HTTP [**] [Classification:
WEB_SERVER Possible SQL Injection [**] [REDACTED]:25
POLICY Suspicious HTTP [**] [Classification:
POLICY Suspicious HTTP [**] [Classification:
POLICY Suspicious HTTP [**] [Classification:
POLICY Suspicious HTTP [**] [Classification:
INFO Possible Benign Scan [**] [REDACTED]:443
WEB_SERVER Possible SQL Injection [**] [REDACTED]:53

這進一步證實了受感染主機正在執行其他可疑活動。我們可以使用以下命令顯示針對受感染主機觸發的警報統計信息。

命令行: cat ids_alerts.log | grep -n [REDACTED] | cut -d' ' -f6,7,8,9,10,19,22,23 | uniq -c | sort -nr | head

ubuntu@tryhackme:~/Desktop/Perimeter_logs/challenge$ cat ids_alerts.log | grep -n [REDACTED] | cut -d' ' -f6,7,8,9,10,19,22,23 | uniq -c | sort -nr | head 
32 TROJAN Possible C2 Beaconing [**] {TCP} [REDACTED]:4444
5 POLICY Suspicious HTTP [**] [Classification:
3 TROJAN Possible C2 Beaconing [**] {TCP} [REDACTED]:4444
3 POLICY Suspicious HTTP [**] [Classification:
2 WEB_SERVER Possible SQL Injection [**] [REDACTED]:4444
2 TROJAN Possible C2 Beaconing [**] {TCP} [REDACTED]:4444

以上分析清楚地表明,我們的內部網絡已完全被攻破,現在外部 IP 地址充當C2服務器,接收來自我們被攻破主機的C2信標。

命令行: cat ids_alerts.log | grep -n [REDACTED]   | cut -d' ' -f6,7,8,9,10,19,22,23 | uniq -c | sort -nr | head

ubuntu@tryhackme:~/Desktop/Perimeter_logs/challenge$ cat ids_alerts.log | grep -n [REDACTED]  | cut -d' ' -f6,7,8,9,10,19,22,23 | sort -nr | uniq -c | sort -nr       
80 TROJAN Possible C2 Beaconing [**] {TCP} [REDACTED]:4444
32 INFO Possible HTTP POST Large {TCP} [REDACTED]:80
28 INFO Possible HTTP POST Large {TCP} [REDACTED]:8080
23 POLICY Suspicious HTTP [**] [Classification:
2 WEB_SERVER Possible SQL Injection [**] 10.0.0.50:53
2 WEB_SERVER Possible SQL Injection [**] 10.0.0.50:3389
2 WEB_SERVER Possible SQL Injection [**] [REDACTED]:8080
2 WEB_SERVER Possible SQL Injection [**] [REDACTED]:445
2 INFO Possible Benign Scan [**] 10.0.0.50:21
1 WEB_SERVER Possible SQL Injection [**] [REDACTED]:53
1 WEB_SERVER Possible SQL Injection [**] [REDACTED]:443
數據泄露企圖

既然我們已經識別出C2通信並檢查了其他針對可疑 IP 的警報,接下來讓我們調查是否存在數據從我們網絡泄露的跡象。我們將對受感染的主機應用過濾器,並檢查源自這些主機到外部目標 IP 的流量,如下所示:

命令行: cat firewall.log | grep [REDACTED]  | cut -d' ' -f5,6,7  |   uniq  | sort

ubuntu@tryhackme:~/Desktop/Perimeter_logs/challenge$ cat firewall.log | grep [REDACTED]  | cut -d' ' -f5,6,7 | uniq | sort 
[REDACTED]:40000 -> [REDACTED]:8080
[REDACTED]:40001 -> [REDACTED]:8080
[REDACTED]:40002 -> [REDACTED]:8080
[REDACTED]:40003 -> [REDACTED]:80
[REDACTED]:40004 -> [REDACTED]:80
[REDACTED]:40005 -> [REDACTED]:80
[REDACTED]:40006 -> [REDACTED]:80
[REDACTED]:40007 -> [REDACTED]:80
[REDACTED]:40008 -> [REDACTED]:80
[REDACTED]:40009 -> [REDACTED]:8080
[REDACTED]:40010 -> [REDACTED]:80
[REDACTED]:40015 -> [REDACTED]:80
[REDACTED]:40016 -> [REDACTED]:80
[REDACTED]:40017 -> [REDACTED]:8080
[REDACTED]:40018 -> [REDACTED]:80
[REDACTED]:40019 -> [REDACTED]:8080

輸出結果清晰地顯示,受感染的主機REDACTED 正在通過外部 IP 地址發送大量流量。我們還可以篩選 IDS 日誌,查看內部 IP 地址針對這些活動觸發的警報。

ubuntu@tryhackme:~/Desktop/Perimeter_logs/challenge$ cat ids_alerts.log | grep [REDACTED] | tail
2025-09-27 07:00:00 [**] [1:2002050:1] ET INFO Possible HTTP POST Large Upload [**] [Classification: Potential Data Exfiltration] [Priority: 2] {TCP} [REDACTED]:40050 -> [REDACTED]:8080
2025-09-27 11:00:00 [**] [1:2002051:1] ET INFO Possible HTTP POST Large Upload [**] [Classification: Potential Data Exfiltration] [Priority: 2] {TCP} [REDACTED]:40051 -> [REDACTED]:8080
2025-09-27 15:00:00 [**] [1:2002052:1] ET INFO Possible HTTP POST Large Upload [**] [Classification: Potential Data Exfiltration] [Priority: 2] {TCP} [REDACTED]:40052 -> [REDACTED]:80802025-09-28 07:00:00 [**] [1:2002056:1] ET INFO Possible HTTP POST Large Upload [**] [Classification: Potential Data Exfiltration] [Priority: 2] {TCP} [REDACTED]:40056 -> [REDACTED]:80
2025-09-28 11:00:00 [**] [1:2002057:1] ET INFO Possible HTTP POST Large Upload [**] [Classification: Potential Data Exfiltration] [Priority: 2] {TCP} [REDACTED]:40057 -> [REDACTED]:8080
2025-09-28 15:00:00 [**] [1:2002058:1] ET INFO Possible HTTP POST Large Upload [**] [Classification: Potential Data Exfiltration] [Priority: 2] {TCP} [REDACTED]:40058 -> [REDACTED]:80
2025-09-28 19:00:00 [**] [1:2002059:1] ET INFO Possible HTTP POST Large Upload [**] [Classification: Potential Data Exfiltration] [Priority: 2] {TCP} [REDACTED]:40059 -> [REDACTED]:8080

我們已發現數據泄露企圖的證據。如果我們深入分析IDS警報,並通過其他日誌文件關聯這些警報,我們還可以發現更多可疑活動。

方法二:通過 Splunk 分析日誌

作為安全運營中心 (SOC) 分析師,如果日誌文件很大,手動分析日誌會變得非常繁瑣。因此,如果您決定使用 Splunk 進行日誌分析,虛擬機中也提供了一個 Splunk 實例。

要繼續操作,請在瀏覽器中打開鏈接localhost:8000,點擊Search & Reporting左側欄的標籤頁,然後開始分析日誌。日誌已預先導入index="network_logs",如下所示:


請回答以下問題。

查看防火牆日誌。哪個外部IP地址執行的偵察活動最多?
cut -d' ' -f5 firewall.log | cut -d: -f1 | sort -nr | uniq -c

203.0.113.45

防火牆日誌中,哪個內部主機成為了掃描目標?
cut -d' ' -f7 firewall.log | cut -d: -f1 | sort -nr | uniq -c
看計數最高的那個就是

10.0.0.20

VPN日誌中針對的是哪個用户名?
cut -d' ' -f4 vpn_auth.log | sort -nr | uniq -c

svc_backup

VPN登錄成功後,系統分配到的內部IP地址是什麼?
這裏答案是看203.0.113.45該ip最早登錄進來的那個分配的ip,題目沒有説清楚
我們使用splunk調查,若純手工一直用終端查看日誌會比較吃力

10.8.0.23

橫向SMB嘗試使用了哪個端口?
注意看,我這裏查詢的語句不是一下子寫出來的,而是我一個個點的,比如我看ids的log的時候,看到alert字段裏面有一個和smb相關的,那我就把他加進去篩選條件裏面,然後就出來了,然後再看字段裏面有port的,那點開即可看到445端口
500

445

在IDS日誌中,哪個主機向C2服務器發送了信標?

那我們查所有ids,然後看alert字段中有沒有對應的c2日誌
500
然後點擊他加進篩選字段即可
500
可以看到了,很容易使用splunk點點點即可,不用手動在終端上篩選
可以知道是10.0.0.60這個往c2服務器發送內容

10.0.0.60

調查過程中,發現哪個 IP 與 C2 相關?
即哪個服務器是c2
500

198.51.100.77

哪個主機顯示了數據外泄嘗試?
我們看下有沒有和數據外泄相關的告警觸發
500
篩選後,再看源ip即可

10.0.0.51

結論

瞭解到企業網絡不僅僅是計算機和服務器的集合。它是一個生態系統,包含防火牆、活動目錄、應用服務器、文件/數據庫服務器、終端設備和無線接入點等關鍵組件。

  • 網絡邊界充當可信網絡和非可信網絡之間的界限。
  • 攻擊者不斷通過端口掃描、暴力破解和利用暴露的服務漏洞來測試這一邊界。
  • 通過監控網絡邊界,安全運營中心 (SOC)分析人員可以在攻擊者深入網絡之前發現這些早期跡象。

作為安全分析師,我們的職責是:

  • 識別正常網絡流量和可疑網絡流量。
  • 將異常活動上報至更高層級的安全運營中心(SOC)。
  • 瞭解每個網絡組件如何融入企業防禦的整體架構中。

網絡發現檢測

瞭解攻擊者如何發現網絡中的資產,以及如何檢測這種活動。

攻擊者一旦想要攻擊某個網絡,首先必須深入瞭解目標網絡。為此,攻擊者會執行一些特定操作來發現目標網絡。這通常是檢測攻擊者活動的首要步驟之一,也可能是安全運營中心 (SOC)分析師在值班期間最常觀察到的攻擊階段之一。

  • 目標:
    我們希望能夠理解:
    • 什麼是網絡發現?
    • 攻擊者為何執行網絡發現
    • 網絡發現有哪些不同類型?
    • 網絡發現技術的工作原理,以及我們如何檢測它們

網絡發現

攻擊者和網絡發現

如前文所述,攻擊者首先會嘗試發現組織機構中可通過公共互聯網訪問的資產(稱為攻擊面)。
在發現階段,攻擊者會嘗試獲取以下部分信息:

  • 攻擊者可以訪問哪些資產?
  • 這些資產的IP 地址、端口、操作系統以及運行的服務分別是什麼?
  • 目前運行的是哪些服務版本?是否存在可被利用的漏洞?

簡而言之,攻擊者試圖找到一個可以讓他們利用網絡漏洞的開口。
500

防禦者和網絡發現

另一方面,防禦者有時也會運行執行網絡發現活動的軟件。在此過程中,防禦者希望實現以下目標:

  • 清點組織的所有資產,並確保所有資產都有據可查。
  • 確保沒有不必要的 IP 地址、端口或服務開放,並且運行的都是必要的。
  • 確保漏洞得到修復,或者至少修復可被利用的漏洞。

簡而言之,防守方會盡可能縮小進攻面。

檢測網絡發現的挑戰

正如您可能已經注意到的,攻擊者和防禦者都會執行發現操作。許多研究機構、網絡爬蟲、搜索引擎等也會執行類似的發現操作,以繪製互聯網上的資源分佈圖。安全運營中心 (SOC)團隊必須區分好的發現和壞的發現。為了應對這一挑戰,SOC團隊通常會採用以下技術。

  • 將已知的內部和良性外部掃描器列入允許列表,確保不會對這些來源觸發任何警報。
  • 將威脅情報與檢測用例相結合,並僅標記來自已知惡意或可疑來源的掃描活動。
  • 由於前一點可能會遺漏一些惡意掃描活動,一些團隊會利用威脅情報來提高警報的嚴重程度,而不僅僅是觸發警報。此外,他們還會添加一些通用用例來發出掃描行為警報,我們將在後續任務中學習這些用例。

請回答以下問題。

除了 IP 地址、端口和操作系統版本之外,攻擊者還會掃描哪些內容來識別網絡中的漏洞?
服務/指紋

Services

外部掃描與內部掃描

在討論網絡發現行為時,安全運營中心 (SOC)團隊可能會遇到旨在映射目標網絡上主機的活動。這些活動可以分為以下幾種類型。

外部掃描活動

安全運營中心 (SOC)分析師可能會遇到來自組織網絡外部的掃描活動,並掃描網絡內部的機器,主要是位於網絡邊界的面向公眾的資產。SOC分析師會發現,此類攻擊的源 IP 地址是外部 IP 地址,而目標 IP 地址是屬於組織的 IP 地址。這種掃描表明攻擊仍處於MITRE ATT&CK 生命週期的偵察:https://attack.mitre.org/tactics/TA0043/階段。攻擊者尚未在網絡內部建立立足點,正在進行初步偵察,以尋找獲取網絡初始訪問權限的機會。
400
這種掃描處於攻擊的初始階段,攻擊者尚未在網絡中站穩腳跟,因此屬於低危掃描。針對外部掃描活動,安全運營中心 (SOC)分析師可以在組織網絡的邊界防火牆上屏蔽惡意 IP 地址。但是,我們必須注意,攻擊者可能會通過偽裝其 IP 地址再次發起攻擊。

內部掃描活動

安全運營中心 (SOC) 分析師可能觀察到的另一種掃描類型是內部到內部的掃描活動。SOC分析師會發現源 IP 地址和目標 IP 地址均為組織內部網絡的私有 IP 地址。這種類型的掃描從組織內部網絡發起,並掃描同一網絡中的資產。這種掃描表明攻擊已進入MITRE ATT&CK 生命週期中的發現階段。在其他一些框架中,它也可能被稱為內部偵察,表明攻擊者已在網絡中站穩腳跟,並正在準備橫向移動。
400

由於此類掃描表明攻擊者已進入網絡內部,因此屬於高危警報。在確認這並非授權活動後,安全運營中心 (SOC)分析師將升級此警報並啓動事件響應流程。在這種情況下,僅在防火牆上阻止源 IP 地址是不夠的,需要對系統進行更深入的調查,並執行根本原因分析。

識別內部掃描和外部掃描

讓我們看看防火牆日誌中的掃描活動是什麼樣的。

在附加的虛擬機中,打開終端並導航到指定目錄/home/ubuntu/Downloads/logs。該目錄中會有一些CSV文件,這些文件是從 SIEM 解決方案導出的。雖然日誌中包含一個經過脱敏處理的文件,但其他文件可能難以閲讀。然而,這正是從安全設備中提取的真實日誌文件的常見格式。我們可以使用命令head來預覽文件內容。

ubuntu@tryhackme:~/Downloads/logs$ head -n2 log-session-1.csv "@timestamp","source.ip","source.port","destination.ip","destination.port","rule.name","rule.category","rule.action","network.protocol",message,"event.dataset""Sep 7, 2025 @ 17:16:42.944","203.0.113.25",39120,"192.168.230.145",5922,"-","-","-","-","{""ts"":1757265402.944286,""uid"":""CjxnoPYeUTSU7IAo"",""id.orig_h"":""203.0.113.25"",""id.orig_p"":39120,""id.resp_h"":""192.168.230.145"",""id.resp_p"":5922,""proto"":""tcp"",""conn_state"":""S0"",""local_orig"":true,""local_resp"":true,""missed_bytes"":0,""history"":""S"",""orig_pkts"":1,""orig_ip_bytes"":44,""resp_pkts"":0,""resp_ip_bytes"":0,""community_id"":""1:JbLPvC3YPB/75Ez5qzk/uYmWvg4="",""orig_mac_oui"":""VMware, Inc.""}","zeek.conn"

熟悉文件內容後,我們可以使用分隔符cut工具,來篩選 CSV 文件的不同列。請注意,由於日期包含逗號,我們需要相應地計算列的值。接下來,讓我們瀏覽這些文件並回答以下問題。


哪個文件包含顯示內部掃描活動的日誌?
首先他這幾個文件應該是分開的,每一個日誌文件對應一個ip的會話動作
那我們就查看一下哪個ip是內部ip之間的掃描即可
head -n3 log-session-*

log-session-2.csv

執行內部掃描活動的內部 IP 地址有多少條日誌記錄?
解釋:
沒有 + 號:-n K(K 是正數),顯示文件最後 K 行。

有 + 號:-n +K,從文件第 K 行開始,一直顯示到文件末尾。
那我們就用+號
tail -n +2 filename

命令:tail -n +2 log-session-2.csv

2276

執行外部掃描活動的外部 IP 地址是什麼?
查看一下另外兩個文件
500
head -n2 log-session-0.csv log-session-1.csv

203.0.113.25

水平掃描與垂直掃描

一旦攻擊者知道網絡中存在哪些主機,他們通常會想要確定這些主機上哪些端口是開放的。這稱為端口掃描,可以分為以下幾種類型:

水平掃描

有時,攻擊者會掃描多個目標 IP 地址上的同一端口。這種掃描稱為水平掃描。水平掃描用於識別哪些主機暴露了特定端口。攻擊者如果打算利用該特定端口,就可能執行此掃描。例如,WannaCry 勒索軟件利用 SMBv1 漏洞在網絡中傳播,並掃描開放了 445 端口(用於SMB 協議)的計算機。
500

如果在多個事件中發現相同的源 IP 地址、單個目標端口,但多個目標 IP 地址,則可以從日誌中檢測到水平掃描。

垂直掃描

垂直掃描是指對單個主機 IP 地址的多個端口進行掃描。攻擊者執行垂直掃描是為了掌握主機信息並識別其暴露的服務。當攻擊者專注於識別單台機器上的漏洞時,他們可能會執行此操作,因為他們認為該機器基於自身目標具有重要價值。例如,如果一個組織僅將一台服務器暴露在互聯網上,那麼任何想要入侵該組織的攻擊者都會首先對該服務器執行垂直掃描,以識別開放端口並瞭解機器上運行的服務。
500
如果在多個事件中觀察到相同的源 IP 地址、相同的目標 IP 地址,但目標端口不同,則可以從日誌中檢測到垂直掃描。

有時攻擊者可能會進行水平和垂直混合掃描,以獲得兩種掃描方式的優勢。


請回答以下問題。

其中一個日誌文件包含水平掃描的證據?格式為 XXXX/X
cut -d, -f3,4,5,6 log-session-2.csv

203.0.113.0/24

在同一日誌文件中,有一個IP地址被執行了垂直掃描。請問這是哪個IP地址?
這裏看回session0和1就很明顯了,就只有一個ip正在掃描和被掃描

192.168.230.145

在某個IP地址上,只掃描了幾個託管常用服務的端口。請問該IP地址掃描了哪些端口?格式:port1、port2、port3,按升序排列。
cut -d, -f6 log-session-2.csv| sort -nr | uniq -c | sort -nr | head -5

80, 445, 3389

掃描機制

現在我們已經瞭解了可以運行的不同類型的網絡發現掃描,接下來讓我們深入瞭解這些掃描的工作原理。

Ping 掃描

這是最基本的網絡掃描技術之一。Ping 掃描通常用於識別網絡中存在的(且在線的)主機。該掃描通過向主機發送互聯網控制消息協議 (ICMP) 數據包來執行。如果主機在線,它會回覆一個 ICMP 數據包。然而,如今一些組織的安全控制措施通常會阻止這種掃描,使得此類掃描活動更容易被破解。

TCP SYN 掃描

TCP連接通過三次握手建立,步驟分別為 SYN、SYN-ACK 和 ACK。網絡掃描器有時會利用TCP握手的這一特性來識別在線主機及其開放端口。掃描器會向接收方發送 SYN 請求。如果收到 SYN-ACK 響應,則表示該主機在線,並且發送 SYN 連接的端口也處於開放狀態。這種掃描方式較為隱蔽,通常與網絡流量混雜在一起,更難被檢測到。

UDP掃描

另一種識別在線主機和開放端口的方法是發送一個(通常是空的)UDP數據包。如果端口關閉,主機將返回一個ICMP端口不可達應答。這表明端口已關閉,但主機在線。在某些情況下,掃描器需要等待設定的超時時間才能收到響應。如果未收到響應,掃描器會將端口標記為已打開(但這並不能明確證明端口確實已打開)。極少數情況下,掃描器可能會收到UDP響應數據包,這才是端口已打開的證據。由此可見,UDP掃描不可靠且速度較慢,因為它依賴於等待超時時間,直到未收到任何響應才會進行掃描。

大多數組織經常進行內部掃描,以檢查漏洞、監控惡意資產並識別任何可以縮小攻擊面的機會。對於安全運營中心 (SOC)分析師來説,瞭解這些掃描的詳細信息至關重要,例如掃描運行的 IP 地址、掃描類型以及任何掃描計劃。理想情況下,為了減少干擾,這些掃描應從SOC團隊的任何檢測用例中排除。

識別掃描類型

我們來看看能否通過防火牆日誌識別掃描類型。我們將使用Kibana來完成這項工作。
(這裏是通過tryhackme給的靶場來操作)

請回答以下問題。

哪個源 IP 地址對整個子網執行 ping 掃描攻擊?
500

192.168.230.127

zeek.conn.conn_state 值顯示連接狀態。利用此值提供的信息,確定 203.0.113.25 對 192.168.230.145 執行的掃描類型。
500

TCP SYN Scan

日誌中是否有UDP掃描嘗試?(y/n)
看一下字段佔比即可,沒有udp掃描
500

n

數據泄露檢測

介紹

數據泄露是指未經授權將敏感數據從計算機或其他設備傳輸出去。這是攻擊者入侵網絡後的主要目標。作為安全運營中心 (SOC)分析師,我們的工作就是在敏感信息泄露之前檢測並阻止此類行為。本次研討會將介紹攻擊者常用的數據竊取技術,更重要的是,我們將探討如何當場抓獲他們。

  • 學習目標
    我們將涵蓋以下學習目標:
    • 瞭解常用的數據泄露方法。
    • 學習如何利用網絡流量分析來檢測數據泄露企圖。
    • 識別終端設備上的數據泄露跡象。
    • 在SIEM系統中關聯日誌,以發現隱藏的數據泄露通道。
      400

數據泄露:概述、技術和指標

數據泄露是指未經授權將數據從組織傳輸到由敵對勢力控制的外部目標。這可能是蓄意為之(內部人員),也可能是通過惡意軟件/被盜憑證造成的。

攻擊者為何要進行數據竊取

數據竊取是指從網絡中竊取敏感信息的行為。攻擊者進行數據竊取的原因有很多:

  • 經濟利益:被盜數據(例如信用卡信息、個人記錄)可以在暗網上出售或用於欺詐。
  • 間諜活動:國家行為體以獲取知識產權、商業秘密或機密數據為目標,以獲取戰略優勢。
  • 勒索軟件和敲詐勒索:攻擊者竊取數據並威脅要泄露數據,除非支付贖金。
  • 破壞與蓄意破壞:一些對手旨在通過泄露內部數據來損害聲譽或業務。
  • 持久性和偵察:泄露的數據有助於攻擊者瞭解環境,以便進行未來的攻擊。
威脅行為者及其數據竊取技術

下表列出了一些現實世界中的威脅行為者及其數據竊取方法。

威脅行為者/活動 滲出技術 描述
APT29(舒適熊cozy-bear) 通過合法域名使用HTTPS 利用加密的 HTTPS 通道從政府網絡竊取數據。
FIN7 向C2服務器發送HTTP POST 請求 將竊取的數據嵌入HTTP POST請求中以逃避檢測。
月球蜘蛛(Zloader) 加密C2通道 利用加密通道進行了為期兩個月的入侵,並分階段實施了數據泄露。
DarkSide勒索軟件 雙重勒索:加密+竊取 在加密系統前竊取數據,然後威脅要公開泄露。
APT10(雲跳躍者) 雲到雲傳輸 利用雲 API 從託管服務提供商處竊取數據。
與滲出相關的常見階段
  • 發現/收集:攻擊者定位敏感文件。
  • 預置/壓縮:攻擊者聚合、壓縮、加密或編碼文件(ZIP、RAR、7z、tar、base64、隱寫術)。
  • 外泄傳輸:通過網絡、可移動介質、雲或隱蔽渠道進行傳輸。
  • 指揮與控制(C2)協調:協調傳輸並確認接收。
技術與指標

檢測數據泄露需要關聯主機和網絡級別的指標,例如異常大或頻繁的出站上傳(代理/防火牆)、長時間或高熵的 DNS查詢、可疑的進程命令行和網絡連接(Sysmon / EDR)、雲存儲API活動、可移動介質事件,以及有效的SOC L1 分類,重點關注源主機/用户、目標、傳輸的卷、進程身份/命令行,以及代理、DNS、流、主機和雲日誌中的支持證據。

技術 示例 攻擊指標及查找位置
基於網絡 HTTP /HTTPS 上傳到S3 /Azure Blob/webmail、FTP /SFTP/SCP、DNS隧道、ICMP/隱蔽協議、自定義TCP / UDP。 代理/Web網關日誌(大型POST請求、上傳到雲端點)、防火牆/NGFW流量(到單個IP/ASN的高字節數)、NetFlow(峯值/出站流量)、DNS日誌(長主機名、TXT查詢)。
基於主機 PowerShell /Invoke-WebRequest、rclone、awscli、curl/wget、歸檔創建(zip/rar)、使用可移動 USB、ADS/隱藏流。 Sysmon / EDR (進程創建、網絡連接、文件創建事件)、Windows 安全(4663/4656 對象訪問)、 Linux上的 auditd/shell 歷史記錄以及可移動介質事件。
雲層外滲 S3 PutObject/分段上傳、Azure Blob 上傳、Google Cloud Storage 對象插入、Drive/SharePoint 外部共享。 CloudTrail / Azure 活動 / GCP 審計、雲存儲訪問日誌、異常服務帳户或 IP 活動。
隱蔽和編碼 DNS隧道、base64 或分塊編碼、圖像/音頻隱寫術、將文件分割成許多小請求(低速)。 DNS日誌、 包含大量小型 POST 請求的代理日誌、間歇性上傳與可疑進程活動的關聯。
內部人員和協作工具 Slack/Teams/Dropbox/Google Drive/Box 上傳或共享給外部用户;員工帳户被盜用。 審計日誌(共享事件、文件下載)和郵件日誌。
通用 IoA 和分診信號 大量出站流量到外部IP /域、未知目標域、可疑進程/命令行、大量文件讀取事件後建立出站連接以及多部分/流式上傳。 關聯:代理/防火牆/ Netflow、DNS、Sysmon / EDR(事件 ID 1/3/11)、郵件服務器日誌。

數據泄露是一種影響巨大的威脅,它結合了機會主義手段、合法工具和巧妙的隱蔽渠道,將敏感資產轉移到組織外部。有效的檢測與其説是依賴於單一的警報,不如説是依賴於對主機、網絡和雲端遙測數據的快速關聯,從而識別數據訪問者、傳輸了哪些數據、數據是如何存儲的以及數據被髮送到了哪裏。

在接下來的任務中,我們將探索攻擊者用於執行數據竊取的各種技術,以及哪些指標可以幫助我們追蹤攻擊的痕跡。


請回答以下問題。

通過HTTP協議泄露數據屬於哪種技術?

Network-based

檢測:通過 DNS 隧道進行數據泄露

DNS數據竊取利用域名系統(DNS)這一通常允許在網絡中流通的協議,將編碼後的字節數據偷偷嵌入DNS查詢/響應中,從而使防火牆和 Web 代理無法檢測到。由於DNS通常被允許,並且經常未經過濾或轉發到公共解析器,因此它對隱蔽渠道極具吸引力。

DNS隧道

DNS(域名系統)將易於理解的域名(例如example.com example.com)轉換為IP地址,並提供其他記錄類型(A、AAAA、TXT、MX、CNAME等)。要點:

  • DNS 查詢無處不在:幾乎每個主機都會執行 DNS 查詢。
  • DNS 通常允許通過防火牆和網關,使其成為一個有吸引力的隱蔽通道。
  • DNS 主要使用 UDP 協議,通過 53 端口進行查詢和響應;TCP 協議用於區域傳輸或大型響應。

攻擊者為何利用 DNS 進行數據竊取:

  • 始終在線的服務:DNS 查詢是例行操作,並且通常允許出站。
  • 高覆蓋率:除非仔細檢查,否則查詢看起來與普通請求無異。
  • 靈活的有效載荷:數據可以編碼到子域標籤或 TXT 響應中。
攻擊跡象

在分析 DNS 流量以尋找數據泄露的可能跡象時,我們應該關注以下方面:

  • 大量 DNS 查詢被髮送到單個外部域,尤其是與基線相比,查詢數量非常高。
  • 子域名標籤過長或完整查詢名稱過長(> 60-100 個字符)。
  • 查詢名稱中存在高熵或類似 Base32/Base64 的模式(大量大小寫混合的字母、數字、,-符號,=用於 base64)。
  • 罕見的記錄類型(TXT、NULL)或許多大型 TXT 響應。
  • 異常響應行為:頻繁出現 NXDOMAIN(如果攻擊者使用查詢泄露而不進行響應),或者 DNS 出現 TCP/大型 UDP 分片。
  • 定期查詢(信標行為)。
通過 Wireshark 進行檢測

下面介紹 Wireshark 顯示過濾器、tshark 命令以及分析時需要注意的事項dns_exfil.pcap
我們首先對 DNS 流量應用過濾器,使用如下所示的過濾器:
篩選: dns

500

篩選: dns.flags.response == 0,篩選出沒有響應的DNS查詢。
500
我們可以看到一些DNS條目的查詢長度很大。

查找過長的查詢(可疑的子域名長度)

讓我們對查詢長度應用篩選條件,看看能否縮小結果範圍。
篩選: dns && frame.len > 70
500
上述結果識別出一個可疑域名,該域名正在接收這些可疑的DNS請求。讓我們使用以下過濾器來篩選該可疑域名:
篩選: dns && dns.qry.name contains tunnelcorp.net
500

看來我們已經成功識別出DNS隧道攻擊嘗試。從網絡流量中,我們可以觀察到:

  • 多台內部主機遭到入侵。
  • 所有這些主機都使用DNS隧道技術分塊發送數據。
  • 只有一個外部域被確定為接收DNS查詢的域。

讓我們用 Splunk 來關聯一下這些數據。

使用 Splunk 進行調查

打開 Splunk 實例。在搜索欄中,輸入以下搜索查詢。
搜索查詢: index=data_exfil sourcetype=DNS_logs

此搜索查詢將篩選並顯示匹配的結果sourcetype=DNS_logs

需要注意什麼
在 DNS 日誌中,我們需要查看那些看起來可疑的域名,這些域名可能來自多個主機或單個主機,查詢次數巨大(如果該域名不受信任,則很可疑)。 
讓我們運行以下搜索查詢,以顯示每個源 IP 生成的 DNS 查詢統計信息,如下所示:
搜索查詢index="data_exfil" sourcetype="DNS_logs" | stats count by src_ip

現在讓我們對查詢統計信息應用篩選器,以識別可疑查詢,如下所示:
搜索查詢: index="data_exfil" sourcetype="dns_logs" | stats count by query | sort -count

以上結果清楚地顯示了一些奇怪的 DNS 查詢,查詢語句的長度很大。

需要注意的事項:
我們可以觀察單個主機產生的 DNS 請求數量遠超正常水平的情況。

長查詢名稱(子域名編碼)

現在,讓我們對長度超過 30 的查詢應用以下過濾器,看看能否過濾掉那些看起來異常的查詢,如下所示:
搜索查詢: index="data_exfil" sourcetype="DNS_logs" | where len(query) > 30 | table query

完美。通過以下指標,我們能夠識別出通過DNS隧道進行的數據泄露嘗試:

  • 大量DNS請求沒有得到響應。
  • DNS查詢語句過長。

請回答以下問題。

哪個可疑域名正在接收DNS流量?

tunnelcorp.net

觀察到多少與 DNS 隧道相關的可疑流量/日誌?

315

哪個本地IP發送的可疑請求數量最多?
篩選:

index="data_exfil" sourcetype="DNS_logs" | where len(query) > 30 
| stats count by src_ip 
|  sort - count

500

192.168.1.103

檢測:通過FTP泄露數據

文件傳輸協議 ( FTP ) 是最古老的協議之一,用於在TCP /IP 網絡上實現客户端和服務器之間的文件傳輸。攻擊者利用 FTP 將大量數據從網絡中轉移出去,有時是通過泄露的憑據、配置錯誤的服務器或臨時帳户。檢測方法依賴於數據包檢查(僅限FTP)、服務器日誌、SSH會話元數據以及網絡流量/大小/模式分析的綜合分析。

攻擊者如何利用FTP進行數據竊取
  • 使用合法的FTP服務器(公共服務器或配置錯誤的內部服務器)來暫存/傳輸數據。
  • 使用被盜用的憑證(服務帳户、用户憑證)。
  • 使用非標準端口或隧道技術與其他流量混合。
攻擊跡象

需要注意的事項:

  • USERPASS命令(明文憑據)。
  • STOR(上傳)和RETR(下載)命令:重複或大批量傳輸。
  • 大量數據連接到不常見的外部 IP 地址,尤其是在非工作時間。
  • 在臨時端口(PASV)上打開數據通道,並配合大有效載荷。

我們來檢查一下桌面上ftp-lab.pcap的文件/data_exfil/ftp_exfil/。請在 Wireshark 中打開該文件,並按照以下步驟操作:

隔離 FTP 控制和數據
ftp || ftp-data首先,我們將使用如下所示的過濾器查找 FTP 會話:

此過濾器將隔離FTP控制流量。

查找憑證
讓我們篩選出僅顯示使用用户名/密碼登錄的嘗試:ftp.request.command == "USER" || ftp.request.command == "PASS"

從輸出結果中,我們可以查找可疑的用户名或弱密碼。
查找文件名或憑據中的異常情況
篩選ftp contains "STOR"

右鍵單擊packet → Follow → TCP Stream,如下圖所示:

我們可以通過篩選文件擴展名(例如 PDF、csv、TXT 等)來查找可疑文件。讓我們對包含特定術語的 FTP 數據包應用篩選條件csv,如下所示:
篩選: ftp contains "csv"

以上結果顯示,一個以訪客身份連接的可疑 IP 地址已將一些敏感的 csv 文件傳輸到可疑的外部 IP 地址。

識別有效載荷較大的流量

使用過濾器查看長度較大的流量,ftp && frame.len > 90並檢查TCP流中的內容,如下所示:

似乎有包含敏感信息的文檔正在被傳輸到外部 IP 地址。請檢查其他數據流,以查找更多通過HTTP協議泄露敏感文檔的跡象。


請回答以下問題。

觀察到有多少個來自訪客帳户的連接?
篩選:ftp contains "guest"

5

應用篩選條件;從根帳户中提取出的客户相關文件的名稱是什麼?
篩選:ftp contains "root"
然後跟蹤流即可看到

customer_data.xlsx

哪個內部 IP 地址向外部 IP 地址發送了最大的有效載荷?
篩選ftp協議,把長度排序一下即可

192.168.1.105

將 CSV 文件傳輸到可疑 IP 的 FTP 流中隱藏着什麼標誌?
直接看剛剛發現的最大長度的那個數據包就行了,跟蹤流查看即可

THM{ftp_exfil_hidden_flag}

檢測:通過 HTTP 進行數據泄露

通過HTTP 進行數據泄露是指攻擊者使用 HTTP作為傳輸協議將敏感數據從目標網絡轉移出去。HTTP常被濫用,因為它能夠與正常的網絡流量混合,可以穿透防火牆和代理服務器,並且可以被混淆(編碼、加密、隧道技術)。
本檢測任務旨在教會安全運營中心 (SOC)分析人員如何從數據包捕獲(Wireshark)和日誌(Splunk )中識別基於HTTP的數據泄露跡象,並提供實用的搜索查詢和調查步驟。

為什麼這很重要
  • HTTP協議非常普遍;攻擊者會將數據竊取隱藏在合法的網絡使用行為中。
  • 成功檢測可以阻止數據泄露,並有助於追蹤攻擊者在入侵後的活動。
  • 組織必須檢測並採取應對措施,以保護敏感數據並滿足合規要求。
攻擊者如何利用HTTP進行數據竊取
  • POST 上傳到外部服務器:大量數據通過 POST 請求正文發送到攻擊者控制的主機或雲存儲。
  • 帶有編碼數據的 GET 請求:攻擊者將小塊數據壓縮到查詢字符串或路徑段中(適用於低速數據泄露)。
  • 利用常用服務/CDN:將數據泄露偽裝成上傳到熱門服務或攻擊者控制的、信譽良好的域名下的子域名。
  • 自定義標頭:放置在標頭中的數據(例如,  X-Data: <base64>)可能會繞過一些基於字符串的 DLP。
  • 分塊傳輸/多部分傳輸:將大型有效負載拆分為多個請求,以避免大小閾值。
  • HTTPS/TLS 隧道:加密通道隱藏有效載荷;檢測需要 TLS 檢查、SNI 分析或基於元數據的檢測。
  • 通過雲服務進行部署:攻擊者將文件上傳到 Dropbox/GitHub/Gist,然後從外部獲取。

對手會採取各種應對措施:低速慢攻、加密/編碼以及利用合法服務來逃避檢測。

攻擊指標 (IoA)
常用網絡指標
  • 向外部/意外主機發出異常大的 HTTP POST 請求。
  • 對信譽度低/在基礎流量中很少出現的域名的 HTTP 請求。
  • 頻繁地向同一主機發送小請求(信標),然後進行大文件上傳。
  • 分塊或多部分傳輸,其中多個請求組成一個更大的文件。

讓我們檢查 Splunk 中的 HTTP 日誌,看看能否在日誌中找到數據泄露嘗試的跡象。

在 Splunk 中分析日誌

首先,使用以下搜索查詢來獲取結果http_logs,並確保選擇時間範圍All Time,如下所示:

搜索查詢: index="data_exfil" sourcetype="http_logs"

據我們瞭解,數據泄露嘗試可以通過 POST 請求進行。我們將對 POST 方法應用過濾器,以進一步縮小搜索範圍,如下所示:

搜索查詢: index="data_exfil" sourcetype="http_logs" method=POST

現在讓我們看一下發送到各個域的平均字節數,如下所示:
搜索查詢: index="data_exfil" sourcetype="http_logs" method=POST | stats count avg(bytes_sent) max(bytes_sent) min(bytes_sent) by domain | sort - count

讓我們過濾掉良性流量,並隔離有效載荷較大的 POST 請求。
搜索查詢: index="data_exfil" sourcetype="http_logs" method=POST bytes_sent > 600 | table _time src_ip uri domain dst_ip bytes_sent | sort - bytes_sent

我們目前的分析指向一個可疑條目,其中大量數據被上傳到了外部來源。讓我們將此條目與 pcap 文件關聯起來,以進一步展開分析。


我們目前的分析指向一個可疑條目,其中大量數據被上傳到了外部來源。讓我們將此條目與 pcap 文件關聯起來,以進一步展開分析。

網絡流量分析

打開文件夾http_lab.pcap中的文件/data_exfil/http_exfil/ 。

過濾 HTTP 流量

對HTTP流量應用過濾器,如下所示:

篩選http

我們可以看到包含 GET 和 POST 請求的HTTP流量。請篩選 POST 請求,如下所示:

篩選http.request.method == "POST"

過濾掉幀長度大於 500 的流量,如下所示:

篩選http.request.method == "POST" and frame.len > 500
此時應該仍然有很多噪聲。讓我們把篩選範圍擴大到 750,看看能否進一步縮小結果範圍。
篩選:http.request.method == "POST" and frame.len > 750

此請求僅顯示一個條目,與我們在Splunk中找到的條目相同。讓我們轉到HTTP流以查看文件內容,如下所示:


請回答以下問題。

哪個內部被入侵的主機被用來竊取這些敏感數據?

192.168.1.103

泄露的數據中隱藏着什麼標誌?

THM{http_raw_3xf1ltr4t10n_succ3ss}

檢測:通過 ICMP 進行數據泄露

ICMP 是一種網絡層協議,用於診斷和控制(例如,ping、TTL超時)。由於它通常被防火牆允許通過,且通常受到的檢查不如TCP / UDP嚴格,攻擊者有時會濫用 ICMP 來建立隧道並竊取數據。惡意攻擊者將數據編碼到 ICMP 有效載荷(回顯請求/應答、時間戳、信息)中,並將其發送到受其控制的遠程監聽器。

敵方如何利用ICMP進行數據竊取

常用技術:

  • ICMP 回顯(類型 8)/應答(類型 0)隧道:攻擊者將編碼(base64、十六進制)的文件塊嵌入 ICMP 有效載荷中。遠程服務器收集並解碼這些文件塊。
  • 自定義 ICMP 類型/代碼:使用不常見的 ICMP 類型或非零代碼來避免基於簽名的檢測。
  • 分片和重組:將較大的有效載荷拆分到多個數據包中。
  • 加密/混淆:對有效載荷進行加密(常用 base64 編碼),使其看起來像隨機數據。

可能存在惡意行為的跡象:

  • 與外部主機建立持續的 ICMP 會話,而該外部主機並非用於合法監控。
  • 異常大的 ICMP 有效載荷或頻繁的 ICMP 有效載荷大於典型 ping 大小。
  • 包含高熵數據或與 base64/hex 一致的模式的 ICMP 有效載荷。
  • ICMP 突發流量之後,同一主機上不會立即出現其他合法的應用流量。
Wireshark中的攻擊指標

在 Wireshark 中檢查pcap文件時,請查找以下內容:

  • ICMP 數據包數量:單個主機向外部 IP 發送大量 ICMP 回顯請求。
  • 大型frame.lenicmp.payload:有效載荷遠大於典型值(例如,> 64 字節)的 ping 請求。
  • ICMP 類型/代碼異常值:例如,時間戳(13/14)或自定義代碼的異常使用。
  • 規律性定時(週期性):攜帶大小相似的有效載荷的 ICMP 數據包均勻間隔發送。
  • 可重組的片段:來自同一源/目標對的多個 ICMP 片段。

過濾所有 ICMP 流量
以下過濾器會隔離所有 ICMP 數據包。請查找異常頻繁或數據包大小較大的 ICMP 回顯請求/回覆。
篩選: icmp

隔離icmp請求
讓我們應用過濾器來隔離 ICMP 回顯請求數據包,如下所示:
篩選: icmp.type == 8

檢查大型 ICMP 數據包
現在讓我們對 ICMP 請求應用過濾器,並重點關注幀長度超過 100 的請求,如下所示:
篩選icmp.type == 8 and frame.len > 100

標記有效載荷異常大的數據包。正常的 ping 數據包總大小約為 74 字節。任何超過 100 字節的數據包都屬於可疑數據包。
拷貝16進制數據出來,自己轉換一下

3a0d0a54484d7b31636d705f336368305f337866316c7472347431306e5f737563633373737d0d0a2d2d2d0d0a46696c65204861736865733a0d0a20207365637265742e7478743a2039633866336532623761316434653566366337623861396430653166326133620d0a20206261636b75702e7461722e


中間人攻擊檢測

瞭解什麼是中間人攻擊,以及如何在網絡流量中識別這種攻擊的痕跡。

介紹

中間人攻擊(MITM)是網絡安全中最隱蔽的威脅之一。在這種攻擊中,攻擊者會將自身置於合法通信端點之間,攔截、篡改或重定向流量。從藍隊的角度來看,檢測此類攻擊需要採用多層方法,結合網絡監控、證書驗證和行為分析。

  • 學習目標
    主要圍繞以下學習目標展開:
    • 瞭解常見的中間人攻擊途徑和技術
    • 學習識別與中間人攻擊相關的入侵指標
    • 用於檢測可疑流量模式的主控網絡監控工具
    • 針對中間人攻擊場景,制定事件響應程序
      400

中間人攻擊概述

中間人攻擊(MITM)是一種網絡攻擊,攻擊者在未經雙方(例如用户和服務方)同意的情況下,秘密攔截並可能篡改雙方之間的通信。攻擊者可能竊聽以竊取敏感數據,例如憑證和信用卡信息,或注入惡意內容。此類攻擊可針對任何組織或個人,尤其是在加密或身份驗證薄弱的情況下。
400

中間人攻擊的工作原理

中間人攻擊通常包括兩個主要步驟:

  • 攔截:攻擊者將自己插入通信流中,通常是通過利用網絡協議中的弱點或使用ARP、DNS或 IP 欺騙等技術。
  • 操縱/解密:攻擊者試圖訪問或修改通信,解密編碼數據或注入有害內容,例如篡改網站響應或偽造登錄表單。
常見的中間人攻擊類型
  • 數據包嗅探:捕獲通過網絡(通常是開放的 Wi-Fi 網絡)交換的未加密數據包。
  • 會話劫持:竊取和使用會話令牌來冒充用户。
  • SSL剝離:將HTTPS連接降級為不安全的HTTP連接,以竊取或篡改傳輸的數據。
  • DNS欺騙:通過操縱DNS響應,將合法網站流量重定向到欺詐性域名。
  • IP欺騙:製造看似來自受信任系統的惡意IP數據包。
  • 非法Wi-Fi接入點:創建虛假網絡以攔截用户流量。
真實案例
  • 2017 年,Equifax 遭遇中間人攻擊,導致重大數據泄露,超過 1 億用户的敏感數據遭到泄露。
  • 備受矚目的攻擊包括互聯網服務提供商注入代碼,以及國家行為體通過 SSL 欺騙攔截搜索流量。
中間人攻擊和網絡殺傷鏈

為了有效分析和應對安全事件,分析人員必須將警報置於更廣泛的敵方行動模型中進行解讀。孤立的指標只有在與攻擊者的戰術、技術和程序 (TTP) 相匹配時才具有意義。網絡殺傷鏈是目前廣泛採用的一種模型,它描述了高級網絡入侵的典型階段。

該框架由七個不同的階段組成:

  • 偵察:敵方收集目標情報,以發現其弱點。
  • 武器化:攻擊者將漏洞利用程序與惡意載荷捆綁在一起,打包成可投放的攻擊程序。
  • 投送:敵方將武器化包裹投送到目標環境中。
  • 利用:攻擊者的代碼被觸發,並利用軟件、硬件或人為漏洞來獲取初始訪問權限。
  • 安裝:攻擊者在受感染的資產上安裝惡意軟件或建立持久後門。
  • 指揮與控制(C2):敵方建立隱蔽通道,與被入侵資產進行通信並控制該資產。
  • 目標行動:敵方執行其最終目標,例如數據竊取、破壞或橫向移動。
將中間人攻擊置於網絡殺傷鏈中

中間人攻擊是一種用途廣泛的技術,敵方主要在漏洞利用和安裝階段利用這種技術。

  • 作為一種攻擊手段: 中間人攻擊利用了ARP和DNS等核心網絡協議固有的信任機制和設計缺陷。攻擊者通過操縱這些協議,可以攔截通信信道。這種會話攔截行為本身就是一種攻擊手段,因為它破壞了網絡的完整性,併為攻擊者提供了竊聽或主動操控的初始立足點。
  • 作為安裝途徑: 一旦攻擊者成功建立中間人攻擊 (MITM)位置,他們便可控制數據流,並將其用作惡意載荷的傳播媒介。例如,攻擊者可以將瀏覽器漏洞利用程序、惡意軟件投放器或遠程訪問木馬 (RAT) 注入到合法的未加密下載文件中。此操作對應於安裝階段,在此階段,攻擊者會在受害者系統上建立持久性或部署其他惡意工具。

檢測到中間人攻擊是一項至關重要的發現。這表明攻擊者正積極參與入侵的中間階段,為安全運營中心 (SOC)提供了關鍵的干預機會,可以在攻擊者最終目標達成之前介入並破壞攻擊鏈。

檢測 ARP 欺騙

在調查ARP欺騙攻擊之前,必須瞭解ARP協議是什麼、其用途以及攻擊者如何濫用它來執行中間人攻擊。

什麼是ARP協議

ARP(地址解析協議)將本地網絡中的 IP 地址映射到 MAC 地址。當一個設備想要向另一個 IP 地址發送數據時,它首先會詢問:“誰擁有這個 IP 地址?”正確的設備會回覆其 MAC 地址。

ARP欺騙

在ARP欺騙攻擊中,攻擊者發送偽造的ARP應答,誘使設備將攻擊者的MAC地址與合法的IP地址(通常是默認網關地址)關聯起來。這使得攻擊者能夠攔截、修改或重定向網絡流量。


ARP欺騙的原理
ARP協議沒有身份驗證機制。任何設備都可以發送未經請求的 is-at消息。攻擊者利用此漏洞向受害者和網關發送偽造的ARP應答:

  • 192.16.10.100攻擊者聲稱自己02:fe:BB:cd:55:55 是網關。

結果:

  • 受害者的ARP緩存被污染。
  • 所有發往網關的流量都會先經過攻擊者(中間人攻擊)。

攻擊指標

在調查日誌或網絡流量以查找使用 ARP 欺騙的潛在中間人攻擊時,我們可以尋找以下關鍵指標。

  • 重複的 MAC 地址到 IP 地址映射:多個 MAC 地址聲稱擁有相同的 IP 地址。這表明存在冒充行為。
  • 未經請求的 ARP 回覆:大量 ARP 回覆沒有匹配的請求(“無償 ARP”)。
  • ARP流量異常: 短時間內出現大量ARP數據包。
  • 異常流量路由:流量通過攻擊者的 MAC 地址重新路由。
  • 網關重定向模式: 同一網關 IP 地址對應多個目標 MAC 地址。
  • ARP 探測/應答循環:大量具有特定模式的 ARP 請求Who has 192.168.1.x? Tell 192.168.1.y
網絡信息

針對所調查的案例,我們掌握了以下關於該網絡的信息:

角色 IP 蘋果 筆記
網關 192.168.10.1 - 正品路由器
攻擊者 - - -
受害者 - - -
領域 corp-login.acme-corp.local -
網絡流量分析

讓我們從檢查ARP流量開始調查,看看如何識別和檢測網絡流量中的ARP欺騙。打開桌面上的network-traffic.pcap指定文件夾,然後按照以下步驟操作:the mitm_traffic

縮小 ARP 流量範圍

由於我們關注的是 ARP 協議,我們可以先使用以下過濾器將其隔離出來。這樣我們就可以檢查請求/響應,並注意到異常的數量或模式。

篩選arp

你會看到指向 ARP 請求和響應的請求和回覆(who-has和)。我們可以檢查結果,查找任何異常或重複的請求或響應。is-at
提示:按 CTRL + ALT + 1 可固定顯示時間。

ARP請求

讓我們來看一下如下所示的 ARP 請求。 
篩選:arp.opcode == 1

這顯示了從不同主機捕獲的所有ARP請求。

ARP響應

偽造的ARP欺騙通常使用未經請求的is-at回覆(無償/未經要求的回覆)。這些都是強有力的特徵。讓我們來看一下如下所示的ARP響應:

篩選:arp.opcode == 2

此過濾器顯示來自不同主機的ARP響應。仔細檢查這些響應會發現多種響應,包括一些無意義的響應。合法的響應通常對應於最近的“誰擁有”請求。可疑活動則表現為大量沒有明顯請求的響應,或者來自可疑 MAC 地址的同一 IP 地址的重複通告。

免費ARP響應

可疑主機發送大量未經請求的(免費的)ARP應答,尤其是發送到多個目標地址。重複發送免費的ARP應答可能表明攻擊者正在維持其惡意狀態。我們還可以過濾這些免費的ARP數據包,如下所示:

篩選arp.isgratuitous

與網關相關的ARP流量

我們已經掌握了網關的 IP 地址和 MAC 地址信息。接下來,我們將應用以下過濾器來檢查與該網關相關的ARP流量,如下所示:

篩選arp && arp.src.proto_ipv4 == 192.168.10.1 && eth.src == 02:aa:bb:cc:00:01

查看輸出結果,我們只能看到ARP響應。現在,讓我們縮小範圍,根據網關 IP 地址進一步探測與該 IP 地址關聯的 MAC 地址,使用如下所示的過濾器:

篩選arp.opcode == 2 && arp.src.proto_ipv4 == 192.168.10.1

這個輸出結果看起來很有意思。仔細觀察,我們發現一些ARP回覆將網關的 IP 地址指向了可疑的 MAC 地址。這些ARP回覆的頻率表明這確實是ARP欺騙。讓我們應用另一個過濾器來確認一下,如下所示:

篩選:arp.opcode ==2 && _ws.col.info contains "192.168.10.1 is at"

這個過濾器分為兩部分。第一部分關注ARP響應,第二部分 _ws.col.info contains "192.168.10.1 is at"過濾信息列中顯示的內容。這樣就能過濾掉將網關 IP 地址 192.168.10.1 指向 MAC 地址的 ARP 響應。但仔細觀察,我們可以發現攻擊者使用了 ARP 欺騙技術,將 IP 地址偽裝成 MAC 地址。我們也可以使用此過濾器arp.opcode == 2 && arp.src.proto_ipv4 == 192.168.10.1,結果相同。

檢查可疑的 MAC 地址

既然我們已經識別出ARP欺騙攻擊,接下來讓我們使用以下過濾器,縮小範圍,找到與網關 IP 地址關聯的攻擊者 MAC 地址:

篩選:arp.opcode == 2 && arp.src.proto_ipv4 == 192.168.10.1 && eth.src == 02:fe[REDACTED]

結果清楚地證實了攻擊者欺騙了ARP。

檢查重複的 IP 地址到 MAC 地址映射

最後我們可以檢查和確認的是,通過篩選“檢查是否存在與單個 IP 地址重複的 MAC 地址映射”來進行確認。

篩選: arp.duplicate-address-detected || arp.duplicate-address-frame

該結果表明攻擊者成功實施了ARP欺騙,並將自身置於受害者和網關之間。接下來,我們將探討攻擊者如何實施DNS欺騙攻擊以實現重定向。


請回答以下問題。

觀察到來自網關 MAC 地址的 ARP 數據包數量是多少?
因為我們已經知道了網關ip,篩選ip後再選擇這個mac地址進行篩選
500
500

10

攻擊者使用了哪個 MAC 地址來冒充網關?
篩選:arp.opcode == 2 && arp.src.proto_ipv4 == 192.168.10.1
可以看到有一個確實不是網關的mac,然後通知給其他人了,這就代表已經被冒充了

02:fe:fe:fe:55:55

對 192.168.10.1 觀察到了多少次免費 ARP 回覆?
篩選:arp.isgratuitous && arp.src.proto_ipv4 == 192.168.10.1

有多少個不同的 MAC 地址聲稱擁有同一個 IP 地址 (192.168.10.1)?
篩選:arp.opcode == 2 && arp.src.proto_ipv4 == 192.168.10.1
然後可以肉眼看下有多少個src的mac不一樣,其實就兩個,一個是真正的網關,另一個是hacker的

2

總共觀察到攻擊者發送了多少個 ARP 欺騙數據包?
篩選:(arp.opcode == 2 && arp.src.proto_ipv4 == 192.168.10.1) && (eth.src == 02:fe:fe:fe:55:55)

14

揭露DNS欺騙

簡化的DNS協議

首先,我們來了解一下 DNS。你可以把它想象成手機裏的通訊錄。你不會記住朋友的電話號碼,而是直接點擊他們的名字。同樣地,DNS會將人類可讀的網站名稱(例如 www.google.com)轉換成計算機可讀的IP地址

DNS欺騙(或DNS緩存投毒)是指攻擊者破壞此係統。他們會給你的計算機提供一個錯誤的“電話號碼”,讓你無法訪問該網站。

這是一種強大的中間人攻擊(MITM)技術。其工作原理如下:

  1. 受害者試圖前往他們的銀行my-real-bank.com
  2. 攻擊者已經進入本地網絡(可能是通過 ARP 欺騙),攔截受害者的DNS查詢。
  3. 欺騙: 攻擊者迅速向受害者發送偽造的DNS響應my-real-bank.com。該偽造響應顯示,我的 IP 地址是:ATTACKER_IP
  4. 攔截過程: 受害者的計算機信任這個偽造的響應,並將其保存在DNS緩存中。當受害者嘗試連接到他們的銀行網站時,他們會在不知不覺中直接連接到攻擊者的服務器,該服務器可能託管着一個與真實銀行網站完全相同的副本。

攻擊者現在正在in the middle捕獲受害者輸入的所有內容,包括他們的用户名和密碼。

攻擊指標

在調查日誌或網絡流量以查找使用DNS欺騙的潛在中間人攻擊時,我們可以尋找以下關鍵指標 。

  • 同一查詢出現多個DNS響應:一個合法的解析器和一個偽造的解析器都對同一查詢作出了響應。這是最可靠的鑑別指標。
  • 來自意外來源的DNS響應: DNS響應來自與(如 8.8.8.8 或您的DNS服務器)都不匹配的IP 地址。
  • 可疑的 TTL(生存時間)值過短:攻擊者使用非常低的 TTL(1 - 30 秒)來縮短被污染條目的生存時間並重新奪回控制權。
  • 未經請求的DNS響應:在沒有受害者發出相應DNS請求的情況下,出現了DNS響應。
網絡流量分析
縮小 DNS 流量範圍

由於我們關注的是 DNS 協議,我們可以先使用以下過濾器將其隔離。這樣我們就可以檢查請求/響應,並發現異常的數量或模式。

篩選dns

輸出結果包含DNS請求和相應的響應。

過濾合法流量

合法的DNS服務器(例如谷歌的DNS服務器8.8.8.8)會使用已知的外部IP地址進行響應。通過篩選來自該IP地址的響應,我們可以查看不同的normal解析結果,以便進行比較。

篩選dns.flags.response == 1 && ip.src == 8.8.8.8

結果顯示來自合法DNS服務器的有效DNS應答。

檢查DNS響應

讓我們使用下面的過濾器 來查看DNS響應。

篩選dns.flags.response==1

在輸出結果中,我們可以查找來自非常用DNS服務器 IP 地址的響應。仔細查看後,我們發現了一個來自非常用 IP 地址的 DNS8.8.8.8響應。這是一個有趣的發現。雖然我們發現了一個異常的 DNS 請求,表明可能存在 DNS 欺騙攻擊,但我們會先記錄下來,稍後再進行分析。

來自 DNS 服務器的 DNS 響應

以下篩選器將顯示來自 DNS 服務器的 DNS 響應。

篩選dns.flags.response == 1 && ip.src == 8.8.8.8

對我們域名的DNS請求

現在讓我們使用以下過濾器,來仔細查看一下我們感興趣的域名的DNS流量:corp-login.acme-corp.local

篩選dns && dns.qry.name == "corp-login.acme-corp.local"

現在,讓我們使用如下所示的過濾器,對來自DNS服務器的、針對我們感興趣的域的DNS請求進行過濾:

篩選dns.flags.response == 1 && ip.src == 8.8.8.8 && dns.qry.name == "corp-login.acme-corp.local"

輸出結果看起來也很正常,正如預期的那樣。

除了DNS服務器之外的其他DNS響應。

在之前的結果中,我們分析了來自目標域名的DNS服務器的DNS流量。現在,讓我們應用以下過濾器,看看是否有任何DNS請求來自DNS服務器以外的其他服務器:8.8.8.8

篩選dns.flags.response == 1 && ip.src != 8.8.8.8 && dns.qry.name == "corp-login.acme-corp.local"

這就是DNS欺騙的典型表現。它表明網絡中的某個系統充當了惡意DNS服務器的角色,發送偽造的DNS響應。

分析概要

前兩項任務的分析表明:

  • 一次成功的多階段中間人攻擊,攻擊者首先篡改了網關 (192.168.10.1) 的ARP映射。
  • 隨後,偽造了corp-login.acme-corp.local 的DNS回覆,將受害者重定向到攻擊者的 IP 地址。

對域 corp-login.acme-corp.local 觀察到了多少個 DNS 響應?
篩選:dns.flags.response == 1 && dns.qry.name == "corp-login.acme-corp.local"

觀察到來自 8.8.8.8 以外的 IP 地址的 DNS 請求數量是多少?
篩選:dns.flags.response == 1 && dns.qry.name == "corp-login.acme-corp.local"

2

攻擊者偽造的 DNS 響應為該域名返回了哪個 IP 地址?
看上面篩選的源ip即可

192.168.10.55

發現 SSL 剝離攻擊

SSL剝離是一種中間人攻擊技術,攻擊者攔截並篡改網絡流量,移除或阻止客户端與服務器之間的TLS加密。這會導致客户端使用HTTP而非HTTPS進行通信。攻擊者在與服務器保持安全(HTTPS)會話的同時,向受害者轉發純HTTP數據,從而實現竊聽和憑據捕獲。
500

工作原理
  1. 受害者向網站發起HTTPS請求。
  2. 攻擊者使用ARP欺騙或惡意接入點攔截請求。
  3. 攻擊者通過 HTTPS 連接到網站,但通過HTTP將響應轉發給受害者。
  4. 受害者在不知情的情況下通過HTTP進行交互,以明文形式暴露敏感數據。
SSL剝離的指標
  • 初始請求與響應: 用户的初始請求可能是針對HTTPS(端口 443),但後續數據包立即轉移到HTTP同一域的未加密(端口 80)。
  • 重定向/鏈接重寫:監控將HTTPS 請求持續定向到HTTP資源的重定向( HTTP狀態代碼 301、302)。
  • 證書錯誤:雖然攻擊者通常會試圖隱藏這一點,但如果攻擊者使用更直接的代理技術,則初始TLS/SSL 握手可能會失敗或顯示自簽名證書。
網絡流量分析
縮小SSL 流量範圍

本次任務中,我們關注的是 HTTPS 協議。首先,我們使用以下過濾器將其隔離。這將使我們能夠檢查 SSL 請求並發現異常的數量或模式。

篩選tls || ssl

此篩選器將顯示所有與 SSL 相關的流量。

檢查我們服務器的SSL流量。

讓我們應用以下過濾器來顯示與服務器建立的TLS握手,這證明該網站通常使用TLS進行通信。

篩選tls.handshake.type == 1 && tls.handshake.extensions_server_name == "corp-login.acme-corp.local"

從上述輸出結果中可以得出的一個關鍵結論是,確認了所討論的域使用TLS進行通信。

顯示剝離之前的 DNS 重定向。

我們假設 SSL 剝離發生在攻擊者成功執行 DNS 欺騙之後,將受害者重定向到攻擊者的 IP 地址。在之前的任務中,我們已經識別出執行 DNS 欺騙的攻擊者的 IP 地址。讓我們提取攻擊者的 DNS 響應,以證明受害者被指向了攻擊者的 IP 地址,如下所示:

篩選: dns.flags.response == 1 && ip.src == 192.168.10.55 && dns.qry.name == "corp-login.acme-corp.local"

以上結果顯示了攻擊者的 IP 地址向目標域 發送偽造DNS響應的兩起事件。

驗證 TLS 是否消失

SSL剝離的主要指標之一是,欺騙後,目標域名不再與合法服務器進行TLS握手,這驗證了受害者到真實服務器的TLS流量不存在。讓我們對服務器IP和攻擊者IP應用以下過濾器,如下所示:

篩選http && ip.src == 192.168.10.10 && ip.dst == 192.168.10.55

我們可以清楚地看到,受害者在 SSL 剝離後連接到了服務器並登錄了。

我們還可以識別出用户的明文憑據,這證實了攻擊者能夠獲取受害者的憑據。不過,還有其他 SSL 剝離的跡象需要我們關注。在本案例中,我們只觀察到一個跡象,即我們門户網站的 HTTPS 流量被剝離為HTTP。

概括

讓我們來看一下調查摘要,包括攻擊時間線。

  • ARP欺騙(緩存投毒):
    • ARP欺騙攻擊開始,攻擊者發送未經請求的ARP is-at請求,聲稱擁有網關IP地址。
  • DNS欺騙(偽造DNS響應):
    • 受害者 DNS查詢corp-login.acme-corp.local
    • 攻擊者 偽造的DNS響應 192.168.10.55,答案域 → 。
  • SSL剝離(TLS降級/憑證捕獲):
    • 受害者向已解析的 IP 地址發起連接,通過 HTTP 協議向攻擊者發起連接(SSL 剝離效果)。
    • 已觀察到憑證 POST(明文)。

請回答以下問題。

針對我們的域名 corp-login.acme-corp.local 觀察到了多少個 POST 請求?

1

SSL剝離攻擊成功後,從明文中提取的受害者密碼是什麼?

Secret123!

IDS基礎知識

什麼是IDS

眾所周知,防火牆是一種安全解決方案,通常部署在網絡邊界,用於保護其傳入和傳出的流量。防火牆會在建立連接時檢查流量,如果流量違反防火牆規則則會拒絕連接。然而,還需要一些安全措施來檢測已經通過防火牆的連接活動。因此,如果攻擊者通過看似合法的連接成功繞過防火牆,並在網絡內部執行惡意活動,則需要有相應的機制及時檢測到這些活動。為此,我們在網絡內部提供了一種安全解決方案,稱為網絡入侵防禦系統(IPV)Intrusion Detection System (IDS)

以建築物的安全系統為例。防火牆就像守門人,檢查人員進出。但總有可能出現不法分子成功潛入並進行惡意活動的情況。即使他在門口被漏網,但如果他已經進入系統,我們又該如何抓捕他呢?遍佈整棟大樓的監控攝像頭就能做到這一點。入侵檢測系統 ( IDS)就扮演着監控攝像頭的角色。它位於某個角落,基於自身特徵和異常檢測技術監控網絡流量,並檢測任何進出網絡的異常流量。每次檢測到異常,系統都會向安全管理員發出警報。IDS本身不會執行任何操作,它只會通知安全管理員存在惡意活動。

本課程將使您掌握全面的入侵檢測系統 (IDS)解決方案知識。在接下來的任務中, 我們還將探討最流行的開源IDS解決方案。

  • 學習目標
    • 入侵檢測系統的類型及其檢測能力
    • Snort IDS的工作原理
    • Snort IDS中的默認規則和自定義規則
    • 在 Snort IDS中創建自定義規則

入侵檢測系統(IDS)在檢測到威脅後能否阻止威脅的發生? (yea/nay)

Nay

IDS的類型

入侵檢測系統(IDS)可以根據某些因素進行不同分類。IDS的主要分類取決於其部署方式和檢測模式。

部署模式

IDS可以通過以下幾種方式部署:

  • 主機入侵檢測系統 ( HIDS ): 基於主機的入侵檢測系統解決方案單獨安裝在每台主機上,僅負責檢測與該特定主機相關的潛在安全威脅。它們提供主機活動的詳細可見性。然而,主機入侵檢測系統在大型網絡中的管理可能具有挑戰性,因為它們資源密集,並且需要在每台主機上進行管理。
  • 網絡入侵檢測系統 ( NIDS ): 基於網絡的入侵檢測系統解決方案對於檢測整個網絡中潛在的惡意活動至關重要,而無需考慮任何特定主機。它們監控所有相關主機的網絡流量,以檢測可疑活動。它提供了一個集中式的網絡檢測視圖。
    500
檢測模式
  • 基於特徵碼的入侵檢測系統 (IDS): 每天都會發生大量攻擊。每種攻擊都有其獨特的模式,稱為特徵碼。IDS 會將這些特徵碼保存在其數據庫中,以便將來如果發生相同的攻擊,系統能夠通過特徵碼檢測到該攻擊,並向安全管理員報告以採取相應措施。IDS 的特徵碼數據庫越強大,其檢測已知威脅的效率就越高。然而,基於特徵碼的IDS無法檢測零日攻擊。零日攻擊沒有先前的特徵碼(模式),也不會保存在IDS數據庫中。因此,基於特徵碼的IDS只能檢測之前發生的攻擊,並且這些攻擊的特徵碼(模式)會保存在數據庫中。在接下來的任務中,我們將探索一款名為 Snort 的基於特徵碼的IDS。

  • 基於異常的入侵檢測系統 (IDS): 這類IDS首先學習網絡或系統的正常行為(基線),並在出現任何偏離正常行為的情況時進行檢測。基於異常的IDS還可以檢測零日攻擊,因為它們不依賴於現有的特徵碼進行檢測。它們通過將當前狀態與正常行為(基線)進行比較來檢測網絡或系統內部的異常情況。然而,這類IDS可能會產生大量的誤報(將良性活動標記為惡意活動),因為大多數合法程序的性質與惡意程序相似。基於異常的IDS會將它們標記為惡意,並認為任何異常行為都是惡意的。我們還可以通過微調(在IDS中手動定義正常行為)來減少基於異常的IDS產生的誤報。

  • 混合型入侵檢測系統 (IDS): 混合型IDS結合了基於特徵碼的IDS和基於異常的IDS的檢測方法,以充分發揮兩種方法的優勢。某些已知威脅可能已經在IDS數據庫中擁有相應的特徵碼;在這種情況下,混合型IDS將使用基於特徵碼的IDS的檢測技術。如果遇到新的威脅,它可以利用基於異常的IDS的檢測方法。

基於特徵碼的入侵檢測系統 (IDS)可以快速檢測威脅,而其他類型的IDS則可能存在較高的處理開銷。然而,選擇IDS時也必須考慮多種因素。基於特徵碼的IDS可能適用於覆蓋較小的威脅面。基於異常的IDS和混合型IDS可以幫助檢測日益增多且可能對組織造成巨大損失的新型零日攻擊。


請回答以下問題。

部署了哪種類型的入侵檢測系統來檢測整個網絡中的威脅?

Network Intrusion Detection System

哪款入侵檢測系統同時採用了基於特徵的檢測技術和基於異常的檢測技術?

Hybrid IDS

IDS 示例:Snort

Snort 是 1998 年開發的最廣泛使用的開源入侵檢測系統(IDS)解決方案之一。它使用基於特徵碼和異常的檢測方法來識別已知威脅。這些威脅定義在 Snort 工具的規則文件中。該工具的軟件包中預裝了多個內置規則文件。這些內置規則文件包含各種已知的攻擊模式。Snort 的內置規則可以檢測大量惡意流量。但是,您可以配置 Snort 來檢測默認規則文件未涵蓋的特定類型的網絡流量。您可以根據自身需求創建自定義規則來檢測特定流量。如果內置檢測規則無法檢測到對您的系統或網絡有害的流量,您也可以禁用它們,並定義一些自定義規則。在接下來的任務中,我們將探索內置規則並創建自定義規則來檢測特定流量。

Snort的模式

模式 描述 用例
數據包嗅探模式 此模式讀取並顯示網絡數據包,但不對其進行任何分析。Snort 的數據包嗅探模式與入侵檢測系統 (IDS)功能沒有直接關係,但它有助於網絡監控和故障排除。在某些情況下,系統管理員可能需要在不進行任何檢測的情況下讀取流量,以診斷特定問題。此時,他們可以利用 Snort 的數據包嗅探模式。此模式允許您在控制枱上顯示網絡流量,甚至可以將其輸出到文件中。 網絡團隊發現一些網絡性能問題。為了診斷問題,他們需要詳細瞭解網絡流量。為此,他們可以利用 Snort 的數據包嗅探模式。
數據包日誌模式 Snort 實時檢測網絡流量,並將檢測結果以警報的形式顯示在控制枱上,供安全管理員採取相應措施。然而,在某些情況下,需要記錄網絡流量以供後續分析。Snort 的數據包日誌記錄模式允許您將網絡流量記錄為PCAP(標準數據包捕獲格式)文件。該文件包含所有網絡流量及其檢測結果。取證調查人員可以使用這些 Snort 日誌文件對之前的攻擊進行根本原因分析。 安全團隊需要對網絡攻擊展開取證調查。他們需要流量日誌來進行根本原因分析。通過 Snort 的數據包日誌記錄模式記錄的網絡流量可以為他們提供幫助。
網絡入侵檢測系統模式 Snort 的網絡入侵檢測系統(NIDS)模式是其主要模式,可實時監控網絡流量,並應用其規則文件來識別與已存儲為簽名的已知攻擊模式的任何匹配項。如果發現匹配項,則會生成警報。此模式提供了入侵檢測系統(IDS)解決方案的主要功能。 安全團隊必須主動監控其網絡或系統,以檢測潛在威脅。他們可以利用 Snort 的網絡入侵檢測系統(NIDS)模式來實現這一目標。

Snort 作為入侵檢測系統 (IDS)最相關的用途是其網絡入侵檢測系統(NIDS)模式。但是,根據具體需求,Snort 也可以在上述任何模式下使用。


請回答以下問題。

Snort 的哪種模式可以幫助我們將網絡流量記錄到 PCAP 文件中?

# 數據包日誌模式
Packet logging mode

Snort 的主要模式叫什麼?

# 網絡入侵檢測系統模式
Network Intrusion Detection System mode

Snort的使用

安裝 Snort 時,您必須提供網絡接口和範圍。您可以正常運行 Snort,它只會捕獲發往您主機的流量。但是,如果您想使用 Snort 捕獲和檢測整個網絡中的入侵,則必須啓用主機網絡接口的混雜模式。

Snort 內置了一些規則文件、一個配置文件和其他文件。這些文件存儲在 /etc/snort<path> 目錄中。Snort 的關鍵文件是其配置文件snort.conf,您可以在其中指定要啓用的規則文件、要監控的網絡範圍以及其他設置。規則文件存儲在 rules<folder> 文件夾中。讓我們使用以下ls命令列出 Snort 主目錄中的所有文件和文件夾:

Snort 目錄

ubuntu@tryhackme:~$ ls /etc/snort
classification.config  reference.config  snort.debian.conf
community-sid-msg.map  rules             threshold.conf
gen-msg.map            snort.conf        unicode.map
規則格式

現在,我們來討論一下如何在 Snort 中創建規則。編寫規則有其特定的方法。例如,一條規則可以檢測來自任何 IP 地址和端口、到達其所屬網絡(網絡範圍在 Snort 的配置文件中定義)任意端口的 ICMP 數據包(通常用於 ping 主機)。一旦檢測到此類流量,Snort 就會生成“Ping 檢測”警報。

該規則涉及的各個組成部分的詳細信息如下:

  • 操作: 此項指定規則觸發時要執行的操作。在本例中,當流量與此規則匹配時,我們將執行“發出警報”的操作。
  • 協議: 這指的是與此規則匹配的協議。在本例中,我們使用“ICMP”協議來ping主機。
  • 源 IP: 此設置確定流量的來源 IP 地址。由於我們希望檢測來自任何源 IP 的流量,因此將其設置為“any”。
  • 源端口: 這決定了流量的來源端口。由於我們希望檢測來自任何源端口的流量,因此我們將其設置為“any”。
  • 目標 IP: 此參數指定匹配流量的目標 IP 地址;它會生成警報。在本例中,我們使用了“$HOME_NET”。這是一個變量,我們在 Snort 的配置文件中將其值定義為整個網絡的 IP 地址範圍。
  • 目標端口: 這指定流量將到達的端口。由於我們希望檢測到達任何端口的流量,因此我們將其設置為“any”。
  • 規則元數據: 每條規則都包含一些元數據。這些元數據定義在規則末尾的括號內。其組成部分如下:
    • 消息 (msg): 此消息描述觸發主題規則時顯示的消息。消息應指示檢測到的活動類型。在本例中,我們使用了“檢測到 Ping 請求”。
    • 簽名 ID (sid): 每條規則都有一個唯一的標識符,用於將其與其他規則區分開來。此標識符稱為簽名 ID (sid)。在本例中,我們將 sid 設置為“10001”。
    • 規則修訂(rev): 此設置用於指定規則的修訂號。每次規則被修改時,其修訂號都會遞增,這有助於跟蹤規則的更改。
規則創建

讓我們將上面解釋的示例規則粘貼到 Snort 規則目錄中的自定義“local.rules”文件中。

首先,用文本編輯器打開“local.rules”文件:

編輯自定義規則文件

ubuntu@tryhackme:~$ sudo nano /etc/snort/rules/local.rules

現在,在文件中已有的規則之後添加以下規則:

alert icmp any any -> 127.0.0.1 any (msg:"Loopback Ping Detected"; sid:10003; rev:1;)

注意: 我們將在下一個任務中用到其他規則,所以請不要刪除它們。

文件編輯成功後,按下“Ctrl+X”,系統會詢問您是否要按“Y”保存更改。按下“Y”保存更改。
(這是教程裏面的使用nano,我們實際上用你自己的編輯工具編輯也行)

規則測試

首先,我們啓動 Snort 工具來檢測規則文件中定義的任何入侵行為。為此,我們需要在控制枱中以 sudo 權限執行以下命令:

運行 Snort 進行檢測

ubuntu@tryhackme:~$ sudo snort -q -l /var/log/snort -i lo -A console -c /etc/snort/snort.conf

注意: 如果您的環回接口名稱不是 “lo”, 請將其替換為正確的接口名稱。

由於這條規則旨在提醒我們注意任何發往我們環回地址的 ICMP 數據包,讓我們嘗試 ping 一下我們的環回地址,看看這條規則是否有效:

Ping 主機

ubuntu@tryhackme:~$ ping 127.0.0.1

下面的截圖顯示了當我們 ping 主機的迴環 IP 地址時,Snort 生成的“檢測到迴環 Ping”警報。這表明我們的規則運行正常。

運行 Snort 進行檢測

ubuntu@tryhackme:~$ sudo snort -q -l /var/log/snort -i lo -A console -c /etc/snort/snort.conf
07/24-10:46:52.401504  [**] [1:1000001:1] Loopback Ping Detected [**] [Priority: 0] {ICMP} 127.0.0.1 -> 127.0.0.1
07/24-10:46:53.406552  [**] [1:1000001:1] Loopback Ping Detected [**] [Priority: 0] {ICMP} 127.0.0.1 -> 127.0.0.1
07/24-10:46:54.410544  [**] [1:1000001:1] Loopback Ping Detected [**] [Priority: 0] {ICMP} 127.0.0.1 -> 127.0.0.1
在 PCAP 文件上運行 Snort

我們已經瞭解了 Snort 如何用於實時流量的入侵檢測。
然而,有時您可能會遇到這樣的情況:歷史網絡流量記錄在文件中,您需要進行取證調查,以確定是否存在任何入侵跡象。
這些流量通常以標準的“PCAP”數據包捕獲格式記錄。Snort 也能夠檢測包含歷史網絡流量的 PCAP 文件。

可以使用以下命令並以 sudo 權限執行此操作:

在 PCAP 上運行 Snort

ubuntu@tryhackme:~$ sudo snort -q -l /var/log/snort -r Task.pcap -A console -c /etc/snort/snort.conf

注意: 將“Task.pcap”替換為要分析的PCAP文件的路徑。


Snort 存儲其文件的主目錄在哪裏?

/etc/snort

Snort規則中的哪個字段表示規則的修訂號?

rev

任務中創建的示例規則定義了哪個協議?

icmp

包含 Snort 自定義規則的文件名是什麼?

local.rules

實踐實驗室

場景: 您是一名第三方取證調查員。一家公司聯繫您,希望您調查其網絡近期遭受的攻擊。他們提供了一個名為“Intro_to_IDS.pcap ”的PCAP文件,其中包含攻擊期間捕獲的網絡流量。您的任務是使用該PCAP文件運行Snort,並回答本任務中提出的問題。

注意: PCAP文件Intro_to_IDS.pcap已放置在該/etc/snort/目錄中。您需要切換到該目錄,並/etc/snort按照任務 4 中的相同方式對該新生成的PCAP文件運行PCAP分析命令。

運行:sudo snort -q -l /var/log/snort -r Intro_to_IDS.pcap -A console -c /etc/snort/snort.conf
500

10.11.90.211

除了 SSH 消息之外,PCAP 文件中還檢測到了哪些其他規則消息?

Ping Detected

檢測 SSH 的規則的 SID 是什麼?

1000002

Snort

學習如何使用 Snort 來檢測實時威脅、分析記錄的流量文件並識別異常情況。

介紹

SNORT 是一款開源的、基於規則的網絡入侵檢測與防禦系統 ( NIDS / NIPS )。它由 Martin Roesch、開源貢獻者和 Cisco Talos 團隊開發並維護至今。官方描述為:“Snort 是全球領先的開源入侵防禦系統 ( IPS )。Snort IPS使用一系列規則來定義惡意網絡活動,並利用這些規則查找匹配的數據包,從而為用户生成警報。”
500

  • 學習目標
    在這個房間裏,我們將涵蓋以下學習目標:
    • IDS / IPS概述
    • Snort 概述
    • 編寫IDS規則
    • 使用 Snort 檢測入侵

IDS/IPS簡介

在深入研究 Snort 和分析流量之前,我們先簡要了解一下入侵檢測系統 ( IDS ) 和入侵防禦系統 ( IPS ) 的概念。您可以配置網絡基礎設施以同時使用這兩種系統,但在開始使用之前,讓我們先了解一下它們之間的區別。

入侵檢測系統(IDS)

IDS是一種被動監控解決方案,用於檢測潛在的惡意活動/模式、異常事件和策略違規行為。它會針對每個可疑事件生成警報。

IDS系統主要分為兩大類:

  • 網絡入侵檢測系統(NIDS):NIDS監控來自網絡各個區域的流量。其目的是調查整個子網上的流量。如果識別出特徵碼, 則會生成警報。
  • 基於主機的入侵檢測系統(HIDS):HIDS監控來自單個終端設備的流量。 其目的是調查該設備上的流量。如果識別出特徵碼,則會生成警報。
入侵防禦系統(IPS)

入侵防禦系統 (IPS)是一種主動防護解決方案,用於預防潛在的惡意活動/模式、異常事件和策略違規。它負責在檢測到可疑事件後立即阻止/預防/終止這些事件。

入侵防禦系統主要有四種類型;

  • 網絡入侵防禦系統(NIPS):NIPS監控來自網絡各個區域的流量。其目的是保護整個子網上的流量。如果檢測到可疑特徵, 則會終止連接。
  • 基於行為的入侵防禦系統(網絡行為分析 - NBA):基於行為的系統監控來自網絡各個區域的流量。其目標是保護整個子網的流量。如果檢測到異常情況,則會終止連接。

網絡行為分析系統 (NBA) 的工作原理與網絡入侵防禦系統 (NIPS) 類似。NIPS與基於行為的系統之間的區別在於,基於行為的系統需要一個訓練期(也稱為“基線化”)來學習正常流量並區分惡意流量和威脅。這種模型能夠更有效地應對新的和未知的威脅。

該系統經過訓練,能夠識別“正常”狀態,從而檢測出“異常”狀態。訓練階段至關重要,可以避免誤報。如果在訓練期間發生安全漏洞,後果將不堪設想。另一個關鍵點是確保系統經過充分訓練,能夠識別良性活動。

  • 無線入侵防禦系統(WIPS):WIPS監控無線網絡的流量。其目的是保護無線流量並阻止可能發起的攻擊。如果檢測到可疑特徵碼, 則會終止連接。
  • 基於主機的入侵防禦系統(HIPS):HIPS主動保護來自單個終端設備的流量。其目的是調查特定設備上的流量。如果識別出特徵碼,則終止連接。

HIPS的工作機制與HIDS類似。區別在於,HIDS會針對威脅發出警報,而HIPS 則通過終止連接來阻止威脅。

檢測/預防技術

IDS和IPS解決方案中使用的主要檢測和預防技術有三種;

技術 方法
基於簽名的 這項技術依賴於識別已知惡意行為特定模式的規則。該模型有助於檢測已知威脅。
基於行為的 這項技術通過特徵碼識別具有新模式的新威脅。該模型將已知/正常行為與未知/異常行為進行比較,從而幫助檢測先前未知或全新的威脅。
基於政策的 該技術將檢測到的活動與系統配置和安全策略進行比較。該模型有助於檢測策略違規行為。
概括

讓我們簡要總結一下IDS和IPS的總體功能。

  • IDS可以識別威脅,但需要用户協助才能阻止威脅。
  • IPS可以在檢測到威脅時,以較少的用户協助識別和阻止威脅。
Snort

現在我們來聊聊Snort。以下是Snort的官方介紹剩餘部分;

Snort 也可以部署在網絡中來攔截這些數據包。Snort 主要有三個用途:作為類似 tcpdump 的數據包嗅探器、作為數據包記錄器(可用於網絡流量調試)或作為功能齊全的網絡入侵防禦系統。Snort 可供個人和企業用户下載和配置。

SNORT 是一個開源的、基於規則的網絡入侵檢測和防禦系統 ( NIDS / NIPS )。它由 Martin Roesch、開源貢獻者和 Cisco Talos 團隊開發並維護至今。

Snort 的功能

Snort 具備以下功能:

  • 實時交通分析
  • 攻擊和探測檢測
  • 數據包日誌
  • 方案分析
  • 實時警報
  • 模塊和插件
  • 預處理器
  • 跨平台支持!(Linux 和 Windows)

Snort模式

Snort 有以下三種主要使用模式:

  • 嗅探模式:在控制枱應用程序中讀取並提示 IP 數據包。
  • 數據包記錄器模式:記錄所有訪問網絡的 IP 數據包(入站和出站)。
  • NIDS(網絡入侵檢測系統)和NIPS(網絡入侵防禦系統)模式:根據用户定義的規則記錄/丟棄被認為是惡意的數據包。

請回答以下問題。

哪種類型的入侵檢測系統 (IDS) 或入侵防禦系統 (IPS) 可以幫助您阻止本地計算機上的威脅?

HIPS

哪種類型的入侵檢測系統 (IDS) 或入侵防禦系統 (IPS) 可以幫助您檢測本地網絡中的威脅?

NIDS

哪種類型的入侵檢測系統 (IDS) 或入侵防禦系統 (IPS) 可以幫助您檢測本地計算機上的威脅?

HIDS

哪種類型的入侵檢測系統 (IDS) 或入侵防禦系統 (IPS) 可以幫助您阻止本地網絡上的威脅?

NIPS

上述哪種解決方案的工作原理是檢測網絡中的異常情況?

NBA

根據官方對該Snort的描述,它屬於哪種類型的Snort?

full-blown

NBA訓練期也稱為……

baselining

與 Snort 的初次互動

首先,我們來驗證 Snort 是否已安裝。以下命令將顯示實例版本。

版本檢查

user@ubuntu$ snort -V

   ,,_     -*> Snort! <*-
  o"  )~   Version 2.9.7.0 GRE (Build XXXXXX) 
   ''''    By Martin Roesch & The Snort Team: http://www.snort.org/contact#team
           Copyright (C) 2014 Cisco and/or its affiliates. All rights reserved.
           Copyright (C) 1998-2013 Sourcefire, Inc., et al.
           Using libpcap version 1.9.1 (with TPACKET_V3)
           Using PCRE version: 8.39 2016-06-14
           Using ZLIB version: 1.2.11   

在開始實際操作之前,我們應該確保配置文件有效。
這裏,“-T”用於測試配置,“-c”指定配置文件 (snort.conf)。請注意,也可以通過
“-c” 指定其他配置文件 。

配置檢查

user@ubuntu$ sudo snort -c /etc/snort/snort.conf -T 

        --== Initializing Snort ==--
Initializing Output Plugins!
Initializing Preprocessors!
Initializing Plug-ins!
... [Output truncated]
        --== Initialization Complete ==--
   ,,_     -*> Snort! <*-
  o"  )~   Version 2.9.7.0 GRE (Build XXXX) 
   ''''    By Martin Roesch & The Snort Team: http://www.snort.org/contact#team
           Copyright (C) 2014 Cisco and/or its affiliates. All rights reserved.
           Copyright (C) 1998-2013 Sourcefire, Inc., et al.
           Using libpcap version 1.9.1 (with TPACKET_V3)
           Using PCRE version: 8.39 2016-06-14
           Using ZLIB version: 1.2.11

           Rules Engine: SF_SNORT_DETECTION_ENGINE  Version 2.4  
           Preprocessor Object: SF_GTP  Version 1.1  
           Preprocessor Object: SF_SIP  Version 1.1  
           Preprocessor Object: SF_SSH  Version 1.1  
           Preprocessor Object: SF_SMTP  Version 1.1  
           Preprocessor Object: SF_POP  Version 1.0  
           Preprocessor Object: SF_DCERPC2  Version 1.0  
           Preprocessor Object: SF_IMAP  Version 1.0  
           Preprocessor Object: SF_DNP3  Version 1.1  
           Preprocessor Object: SF_SSLPP  Version 1.1  
           Preprocessor Object: SF_MODBUS  Version 1.1  
           Preprocessor Object: SF_SDF  Version 1.1  
           Preprocessor Object: SF_REPUTATION  Version 1.1  
           Preprocessor Object: SF_DNS  Version 1.1  
           Preprocessor Object: SF_FTPTELNET  Version 1.2  
... [Output truncated]
Snort successfully validated the configuration!
Snort exiting  

使用配置文件後,Snort 的功能將大大增強!配置文件是 Snort 的一體化管理文件,其中包含規則、插件、檢測機制、默認操作和輸出設置等信息。雖然可以針對不同的用途和場景創建多個配置文件,但在運行時只能使用其中一個。

請注意,Snort 啓動時會自動顯示默認橫幅和初始設置信息。您可以使用“ -q”  參數阻止此行為。

範圍 描述
-V / --version 此參數提供有關您的實例版本的信息。
-c 識別配置文件
-T Snort 的自檢參數允許您使用此參數測試您的設置。
q 靜默模式會阻止 Snort 顯示默認橫幅和有關您設置的初始信息。

這很簡單,讓我們繼續下一個任務,繼續探索 Snort 的各種模式。


運行 Snort 實例並檢查構建版本號。
snort -V

149

使用“/etc/snort/snort.conf”文件測試當前實例,並檢查當前版本加載了多少條規則。
snort -T -c /etc/snort/snort.conf

4151

使用“/etc/snort/snortv2.conf”文件測試當前實例,並檢查當前版本加載了多少條規則。
snort -T -c /etc/snort/snortv2.conf

1

操作模式 1:嗅探模式

讓我們以嗅探模式運行 Snort。

與 tcpdump 類似,Snort 有各種標誌,可以查看有關它正在接收的數據包的不同數據。

嗅探器模式參數如下表所示;

範圍 描述
-v 詳細信息:在控制枱中顯示TCP /IP 輸出。
-d 顯示數據包(有效載荷)。
-e 顯示鏈路層(TCP /IP/ UDP /ICMP)報頭。
X 以十六進制顯示完整的數據包詳細信息。
-i 此參數用於指定要監聽或嗅探的特定網絡接口。如果您有多個接口,則可以選擇要嗅探的特定接口。

讓我們逐個使用每個參數,看看它們之間有什麼區別。Snort 需要你的接口上有活躍的流量,所以我們需要生成一些流量才能看到 Snort 的運行情況。
為此,請使用流量生成器腳本(可在 Task-Exercise 文件夾中找到)。
使用參數“-i”進行嗅探
以詳細模式 (-v) 啓動 Snort 實例,並使用接口 (-i) "eth0";sudo snort -v -i eth0
如果您只有一個網絡接口,Snort 默認會使用它。上面的示例演示瞭如何嗅探名為“eth0”的接口。 一旦您模擬了 -v 參數,您會發現它會自動使用“eth0”接口併發出提示。
使用參數“-v”進行嗅探
以詳細模式(-v) 啓動 Snort 實例;sudo snort -v
現在 以 sudo 權限運行流量生成器腳本,並 啓動ICMP/HTTP 流量。 流量生成後,Snort 將以詳細模式顯示數據包,如下所示:

使用 -v 進行嗅探

user@ubuntu$ sudo snort -v
                             
Running in packet dump mode

        --== Initializing Snort ==--
...
Commencing packet processing (pid=64)
12/01-20:10:13.846653 192.168.175.129:34316 -> 192.168.175.2:53
UDP TTL:64 TOS:0x0 ID:23826 IpLen:20 DgmLen:64 DF
Len: 36
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

12/01-20:10:13.846794 192.168.175.129:38655 -> 192.168.175.2:53
UDP TTL:64 TOS:0x0 ID:23827 IpLen:20 DgmLen:64 DF
Len: 36
===============================================================================
Snort exiting

如您所見,詳細模式會提供類似 tcpdump 的輸出信息。使用 CTRL+C 中斷嗅探後,它會停止並彙總嗅探到的數據包。
使用參數“-d”進行嗅探
以轉儲數據包模式(-d) 啓動 Snort 實例;sudo snort -d
現在 以 sudo 權限運行流量生成器腳本  ,並 啓動 ICMP/HTTP 流量。 流量生成後,Snort 將以詳細模式顯示數據包,如下所示:
使用 -d 進行嗅探

user@ubuntu$ sudo snort -d
                             
Running in packet dump mode

        --== Initializing Snort ==--
...
Commencing packet processing (pid=67)

12/01-20:45:42.068675 192.168.175.129:37820 -> 192.168.175.2:53
UDP TTL:64 TOS:0x0 ID:53099 IpLen:20 DgmLen:56 DF
Len: 28
99 A5 01 00 00 01 00 00 00 00 00 00 06 67 6F 6F  .............goo
67 6C 65 03 63 6F 6D 00 00 1C 00 01              gle.com.....

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

WARNING: No preprocessors configured for policy 0.
12/01-20:45:42.070742 192.168.175.2:53 -> 192.168.175.129:44947
UDP TTL:128 TOS:0x0 ID:63307 IpLen:20 DgmLen:72
Len: 44
FE 64 81 80 00 01 00 01 00 00 00 00 06 67 6F 6F  .d...........goo
67 6C 65 03 63 6F 6D 00 00 01 00 01 C0 0C 00 01  gle.com.........
00 01 00 00 00 05 00 04 D8 3A CE CE              .........:..

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

如您所見,數據包有效載荷模式涵蓋了詳細模式,並提供更多數據。
使用參數“-de”進行嗅探。0
以轉儲(-d)鏈路層報頭抓取(-e) 模式啓動 Snort 實例;snort -d -e
現在 以 sudo 權限運行流量生成器腳本  ,並 啓動 ICMP/HTTP 流量。 流量生成後,Snort 將以詳細模式顯示數據包,如下所示:
使用 -de 進行嗅探

user@ubuntu$ sudo snort -de
                             
Running in packet dump mode

        --== Initializing Snort ==--
...
Commencing packet processing (pid=70)
12/01-20:55:26.958773 00:0C:29:A5:B7:A2 -> 00:50:56:E1:9B:9D type:0x800 len:0x46
192.168.175.129:47395 -> 192.168.175.2:53 UDP TTL:64 TOS:0x0 ID:64294 IpLen:20 DgmLen:56 DF
Len: 28
6D 9C 01 00 00 01 00 00 00 00 00 00 06 67 6F 6F  m............goo
67 6C 65 03 63 6F 6D 00 00 01 00 01              gle.com.....

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

WARNING: No preprocessors configured for policy 0.
12/01-20:55:26.965226 00:50:56:E1:9B:9D -> 00:0C:29:A5:B7:A2 type:0x800 len:0x56
192.168.175.2:53 -> 192.168.175.129:47395 UDP TTL:128 TOS:0x0 ID:63346 IpLen:20 DgmLen:72
Len: 44
6D 9C 81 80 00 01 00 01 00 00 00 00 06 67 6F 6F  m............goo
67 6C 65 03 63 6F 6D 00 00 01 00 01 C0 0C 00 01  gle.com.........
00 01 00 00 00 05 00 04 D8 3A D6 8E              .........:..

使用參數“-X”進行嗅探
以完整數據包轉儲模式(-X) 啓動 Snort 實例;sudo snort -X
現在 以 sudo 權限運行流量生成器腳本  ,並 啓動 ICMP/HTTP 流量。 流量生成後,Snort 將以詳細模式顯示數據包,如下所示:
使用 -X 進行嗅探

user@ubuntu$ sudo snort -X
                             
Running in packet dump mode

        --== Initializing Snort ==--
...
Commencing packet processing (pid=76)
WARNING: No preprocessors configured for policy 0.
12/01-21:07:56.806121 192.168.175.1:58626 -> 239.255.255.250:1900
UDP TTL:1 TOS:0x0 ID:48861 IpLen:20 DgmLen:196
Len: 168
0x0000: 01 00 5E 7F FF FA 00 50 56 C0 00 08 08 00 45 00  ..^....PV.....E.
0x0010: 00 C4 BE DD 00 00 01 11 9A A7 C0 A8 AF 01 EF FF  ................
0x0020: FF FA E5 02 07 6C 00 B0 85 AE 4D 2D 53 45 41 52  .....l....M-SEAR
0x0030: 43 48 20 2A 20 48 54 54 50 2F 31 2E 31 0D 0A 48  CH * HTTP/1.1..H
0x0040: 4F 53 54 3A 20 32 33 39 2E 32 35 35 2E 32 35 35  OST: 239.255.255
0x0050: 2E 32 35 30 3A 31 39 30 30 0D 0A 4D 41 4E 3A 20  .250:1900..MAN: 
0x0060: 22 73 73 64 70 3A 64 69 73 63 6F 76 65 72 22 0D  "ssdp:discover".
0x0070: 0A 4D 58 3A 20 31 0D 0A 53 54 3A 20 75 72 6E 3A  .MX: 1..ST: urn:
0x0080: 64 69 61 6C 2D 6D 75 6C 74 69 73 63 72 65 65 6E  dial-multiscreen
0x0090: 2D 6F 72 67 3A 73 65 72 76 69 63 65 3A 64 69 61  -org:service:dia
0x00A0: 6C 3A 31 0D 0A 55 53 45 52 2D 41 47 45 4E 54 3A  l:1..USER-AGENT:
0x00B0: 20 43 68 72 6F 6D 69 75 6D 2F 39 35 2E 30 2E 34   Chromium/95.0.4
0x00C0: 36 33 38 2E 36 39 20 57 69 6E 64 6F 77 73 0D 0A  638.69 Windows..
0x00D0: 0D 0A                                            ..

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

WARNING: No preprocessors configured for policy 0.
12/01-21:07:57.624205 216.58.214.142 -> 192.168.175.129
ICMP TTL:128 TOS:0x0 ID:63394 IpLen:20 DgmLen:84
Type:0  Code:0  ID:15  Seq:1  ECHO REPLY
0x0000: 00 0C 29 A5 B7 A2 00 50 56 E1 9B 9D 08 00 45 00  ..)....PV.....E.
0x0010: 00 54 F7 A2 00 00 80 01 24 13 D8 3A D6 8E C0 A8  .T......$..:....
0x0020: AF 81 00 00 BE B6 00 0F 00 01 2D E4 A7 61 00 00  ..........-..a..
0x0030: 00 00 A4 20 09 00 00 00 00 00 10 11 12 13 14 15  ... ............
0x0040: 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25  .......... !"#$%
0x0050: 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35  &'()*+,-./012345
0x0060: 36 37                                            67

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

請注意,您可以按如下方式組合或單獨使用這些參數;

  • snort -v
  • snort -vd
  • snort -de
  • snort -v -d -e
  • snort -X

務必瞭解並練習每個參數在不同類型的流量下的表現,找出你最喜歡的組合。

操作模式 2:數據包記錄器模式

讓我們以日誌模式運行 Snort。

你可以將 Snort 用作網絡嗅探器,並通過日誌記錄模式記錄嗅探到的數據包。你只需要設置數據包日誌記錄模式的參數,Snort 會自動完成其餘操作。

數據包記錄器參數如下表所示;

範圍 描述
-l (這個是小寫L) 日誌記錄模式、目標日誌和告警輸出目錄。默認輸出文件夾為/var/log/snort

默認操作是將日誌以 tcpdump 格式轉儲到/var/log/snort 目錄。
-K ASCII 以ASCII格式記錄數據包。
-r 閲讀選項:查看 Snort 中記錄的事件。
-n 指定要處理或讀取的數據包數量。Snort 將在讀取指定數量的數據包後停止。

讓我們逐個使用每個參數,看看它們之間有什麼區別。Snort 需要你的接口上有活躍的流量,所以我們需要生成一些流量才能看到 Snort 的運行情況。

日誌文件所有權
在生成日誌並進行分析之前,我們必須記住Linux文件的所有權和權限。無需深入瞭解用户類型和權限。基本的文件所有權規則如下:
Snort 需要超級用户(root)權限才能嗅探網絡流量,因此,一旦您使用“sudo”命令運行 Snort,生成的日誌文件將歸“root”帳户所有。因此,您需要“root”權限才能查看日誌文件。分析生成的日誌文件有兩種不同的方法:
權限提升

  • 更改文件/目錄的所有權 - 您還可以更改文件/文件夾的所有權,以便以您的用户身份讀取它:sudo chown username file或者sudo chown username -R directory.“-R”參數啓用對文件和目錄的遞歸處理。

使用參數“-l”進行日誌記錄
首先,以數據包記錄器模式啓動 Snort 實例;sudo snort -dev -l.
現在使用流量生成器腳本啓動 ICMP/HTTP 流量
一旦流量生成,Snort 就會開始顯示數據包並將其記錄到目標目錄中。您可以在 Snort.config 文件中配置默認​​輸出目錄。不過,您也可以使用“-l”參數來設置目標目錄。指定默認日誌目錄對於持續監控操作非常有用,而“-l”參數則更適用於測試目的。
-l  命令會在當前目錄下創建日誌文件。您需要使用此選項才能將每個練習的日誌文件保存在各自的文件夾中。
使用 -l 記錄日誌

user@ubuntu$ sudo snort -dev -l.
                             
Running in packet logging mode

        --== Initializing Snort ==--
Initializing Output Plugins!
Log directory = /var/log/snort
pcap DAQ configured to passive.
Acquiring network traffic from "ens33".
Decoding Ethernet

        --== Initialization Complete ==--
...
Commencing packet processing (pid=2679)
WARNING: No preprocessors configured for policy 0.
WARNING: No preprocessors configured for policy 0.

現在,我們來查看生成的日誌文件。 請注意,您的日誌文件名可能與此不同

檢查日誌文件

user@ubuntu$ ls.                       
snort.log.1638459842

如您所見,這是一個包含所有信息的單一日誌文件。它是二進制/tcpdump格式的日誌。


使用參數“-K ASCII”進行日誌記錄
以數據包記錄器模式啓動 Snort 實例;sudo snort -dev -K ASCII
現在 以 sudo 權限運行流量生成器腳本,並 啓動 ICMP/HTTP 流量。 流量生成後,Snort 將以詳細模式顯示數據包,如下所示:

使用 -K ASCII 進行日誌記錄

user@ubuntu$ sudo snort -dev -K ASCII -l.
                             
Running in packet logging mode

        --== Initializing Snort ==--
Initializing Output Plugins!
Log directory = /var/log/snort
pcap DAQ configured to passive.
Acquiring network traffic from "ens33".
Decoding Ethernet

        --== Initialization Complete ==--
...
Commencing packet processing (pid=2679)
WARNING: No preprocessors configured for policy 0.
WARNING: No preprocessors configured for policy 0.

現在,讓我們查看生成的日誌文件。

檢查日誌文件

user@ubuntu$ ls .
                             
142.250.187.110  192.168.175.129  snort.log.1638459842

這是文件夾視圖中的顯示效果。

使用“-K ASCII”參數生成的日誌完全不同。其中有兩個文件夾,文件夾名稱以IP地址命名。我們來看看它們。

檢查日誌文件

user@ubuntu$ ls ./192.168.175.129/
                             
ICMP_ECHO  UDP:36648-53  UDP:40757-53  UDP:47404-53  UDP:50624-123

仔細查看創建的文件夾後,我們可以發現日誌是 ASCII 格式且已分類的,因此無需使用 Snort 實例即可讀取它們。

這是文件夾視圖中的顯示效果。

簡而言之,ASCII 模式以人類可讀的格式提供多個文件,方便使用文本編輯器輕鬆讀取日誌。與 ASCII 格式不同,二進制格式不可讀,需要使用 Snort 或類似應用程序(例如 tcpdump)進行分析。

讓我們用文本編輯器打開 ASCII 格式和二進制格式的文件,比較一下它們的區別。二進制日誌文件和 ASCII 日誌文件的區別如下所示。(左側:二進制格式;右側:ASCII 格式。)


使用參數“-r”讀取生成的日誌

以數據包讀取器模式啓動 Snort 實例;sudo snort -r

使用 -r 讀取日誌文件

user@ubuntu$ sudo snort -r snort.log.1638459842
                             
Running in packet dump mode

        --== Initializing Snort ==--
Initializing Output Plugins!
pcap DAQ configured to read-file.
Acquiring network traffic from "snort.log.1638459842".

        --== Initialization Complete ==--
...
Commencing packet processing (pid=3012)
WARNING: No preprocessors configured for policy 0.
12/02-07:44:03.123225 192.168.175.129 -> 142.250.187.110
ICMP TTL:64 TOS:0x0 ID:41900 IpLen:20 DgmLen:84 DF
Type:8  Code:0  ID:1   Seq:49  ECHO
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
WARNING: No preprocessors configured for policy 0.
12/02-07:44:26.169620 192.168.175.129 -> 142.250.187.110
ICMP TTL:64 TOS:0x0 ID:44765 IpLen:20 DgmLen:84 DF
Type:8  Code:0  ID:1   Seq:72  ECHO
===============================================================================
Packet I/O Totals:
   Received:           51
   Analyzed:           51 (100.000%)
    Dropped:            0 (  0.000%)
   Filtered:            0 (  0.000%)
Outstanding:            0 (  0.000%)
   Injected:            0
===============================================================================
Breakdown by protocol (includes rebuilt packets):
...
      Total:           51
===============================================================================
Snort exiting

請注意, Snort 可以讀取和處理二進制日誌輸出(tcpdump 和 Wireshark 也可以處理這種日誌格式)。但是,如果您使用“-K ASCII”參數創建日誌,Snort 將不會讀取它們。 如上面的輸出所示,Snort 讀取並顯示了日誌文件,就像在嗅探模式下一樣。

使用 tcpdump 打開日誌文件

user@ubuntu$ sudo tcpdump -r snort.log.1638459842 -ntc 10
                             
reading from file snort.log.1638459842, link-type EN10MB (Ethernet)
IP 192.168.175.129 > 142.250.187.110: ICMP echo request, id 1, seq 49, length 64
IP 142.250.187.110 > 192.168.175.129: ICMP echo reply, id 1, seq 49, length 64
IP 192.168.175.129 > 142.250.187.110: ICMP echo request, id 1, seq 50, length 64
IP 142.250.187.110 > 192.168.175.129: ICMP echo reply, id 1, seq 50, length 64
IP 192.168.175.129 > 142.250.187.110: ICMP echo request, id 1, seq 51, length 64
IP 142.250.187.110 > 192.168.175.129: ICMP echo reply, id 1, seq 51, length 64
IP 192.168.175.129 > 142.250.187.110: ICMP echo request, id 1, seq 52, length 64
IP 142.250.187.110 > 192.168.175.129: ICMP echo reply, id 1, seq 52, length 64
IP 192.168.175.1.63096 > 239.255.255.250.1900: UDP, length 173
IP 192.168.175.129 > 142.250.187.110: ICMP echo request, id 1, seq 53, length 64

使用 Wireshark 打開日誌文件。

“-r”參數還允許用户過濾二進制日誌文件。 您可以使用“-r”參數和伯克利數據包過濾器(BPF)來過濾已處理的日誌,以查看特定的數據包。

  • sudo snort -r logname.log -X
  • sudo snort -r logname.log icmp
  • sudo snort -r logname.log tcp
  • sudo snort -r logname.log 'udp and port 53'

輸出結果與上述相同,但只會顯示具有所選協議的數據包。 此外,您可以使用“-n”參數指定處理進程數。以下命令將僅處理前 10 個數據包: Snort -dvr logname.log -n 10

請參考以下資源瞭解BPF 的工作原理及其用途。

  • https://en.wikipedia.org/wiki/Berkeley_Packet_Filter
  • https://biot.com/capstats/bpf.html​​
  • https://www.tcpdump.org/manpages/tcpdump.1.html

請回答以下問題。

使用默認配置文件,以 ASCII 模式調查流量 。
sudo snort -dev -K ASCII -l .
同時執行sudo ./traffic-generator.sh 流量生成器腳本並選擇 “TASK-6 練習”。等待流量結束後,停止 Snort 實例。現在分析輸出摘要並回答問題。

現在,日誌應該位於當前目錄下。導航到文件夾“ 145.254.160.237 ”。連接端口 53 所使用的源端口是什麼?
500

3009

使用 snort.log.1640048004 
使用 Snort 讀取 snort.log 文件;第 10 個數據包的 IP ID 是什麼?
500

使用 Snort讀取“ snort.log.1640048004” 文件;第 4 個數據包的referer引用頁是什麼?
篩選:snort -dvr snort.log.1640048004 -n 4
500

http://www.ethereal.com/development.html

使用 Snort讀取“ snort.log.1640048004” 文件;第 8 個數據包的 ACK 號是多少?
篩選:snort -dvr snort.log.1640048004 -n 8

使用 Snort讀取“ snort.log.1640048004”文件“TCP 端口 80” 數據包的數量是多少?
篩選:snort -dvr snort.log.1640048004 'tcp and port 80'

41

操作模式 3:IDS/IPS

Snort 在IDS / IPS模式下

Snort 的功能不僅限於嗅探和記錄流量。IDS / IPS模式允許您根據用户定義的規則管理流量。

請注意, (N) IDS / IPS模式取決於規則和配置。 
讓我們以IDS / IPS模式運行 Snort
下表解釋了NIDS模式參數;

範圍 描述
-c 定義配置文件。
-T 正在測試配置文件。
-N 禁用日誌記錄。
-D 後台模式。
-A 警報模式;

full完整模式: 提供完整的警報信息,包含所有可能的警報詳情。此模式也是默認模式;如果您使用 -A 參數且未指定模式,Snort 將默認使用此模式。

快速模式會顯示警報消息、時間戳、源 IP 地址和目標 IP 地址以及端口號。

console控制枱: 在控制枱屏幕上提供快速樣式警報。

cmg: CMG 樣式,包含十六進制和文本格式的有效載荷的基本標頭詳細信息。 

None: 禁用警報。

讓我們開始使用每個參數,看看它們之間的區別。Snort 需要你的接口上有活躍的流量,所以我們需要生成流量才能看到 Snort 的運行情況。 為此,請使用 流量生成器 腳本 並抓取流量。

一旦啓動IDS / IPS模式, 就需要使用規則。正如我們之前提到的,我們將以預定義的ICMP規則為例。該規則只會針對任何方向的ICMP數據包活動生成警報。

alert icmp any any <> any any  (msg: "ICMP Packet Found"; sid: 100001; rev:1;)
該規則位於 “/etc/snort/rules/local.rules”中。

請記住,本模塊僅關注運行模式。如果流量觸發警報,Snort 將創建一個“警報”文件。 最後一點: 一旦啓動 IPS/IDS 模式,嗅探和日誌記錄模式將處於半被動狀態。但是,您可以使用前面任務中討論的參數 (-i、-v、-d、-e、-X、-l、-K ASCII) 來激活這些功能。如果您不記得這些命令的用途, 請回顧之前的內容。


IDS/IPS 模式,參數為“-c 和 -T”
啓動 Snort 實例並測試配置文件。 Sudo snort -c /etc/snort/snort.conf -T  此命令將檢查您的配置文件,並在當前設置存在任何錯誤時提示您。


IDS / IPS 模式,參數為“-N”
啓動 Snort 實例並運行以下命令禁用日誌記錄:sudo snort -c /etc/snort/snort.conf -N
現在 以 sudo 權限運行流量生成器腳本  ,並 啓動 ICMP/HTTP 流量。 此命令將禁用日誌記錄模式。其餘功能仍然可用(如果已啓用)。
命令行輸出將提供所需信息以及指定的參數。因此,如果您啓用 詳細模式 (-v) 或 完整數據包轉儲 (-X),您仍然會在控制枱中看到輸出,但日誌文件夾中不會生成任何日誌。


IDS/IPS 模式,參數為“-D”
使用以下命令以後台模式啓動 Snort 實例:sudo snort -c /etc/snort/snort.conf -D
現在 以 sudo 權限運行流量生成器腳本  ,並 啓動 ICMP/ HTTP流量。 流量生成後,Snort 將開始處理數據包,並使用附加參數完成給定任務。
後台運行

user@ubuntu$ sudo snort -c /etc/snort/snort.conf -D

Spawning daemon child...
My daemon child 2898 lives...
Daemon parent exiting (0)

命令行輸出將提供所需信息以及指定的參數。因此,如果您啓用 詳細模式 (-v) 或完整數據包轉儲 (-X) 並啓用數據包記錄器模式 (-l), 則日誌仍會保存在日誌文件夾中,但控制枱不會有任何輸出。
啓動後台模式後,如果想要檢查相應的進程,可以很容易地使用如下所示的“ps”命令;
後台運行

user@ubuntu$ ps -ef | grep snort

root        2898    1706  0 05:53 ?        00:00:00 snort -c /etc/snort/snort.conf -D

要停止守護進程,可以使用“kill”命令終止該進程。
後台運行

user@ubuntu$ sudo kill -9 2898

請注意,守護進程模式主要用於自動化 Snort 服務。此參數主要用於腳本中,以便在後台啓動 Snort 服務。除非您對 Snort 有深入的瞭解並且已配置好穩定的環境,否則不建議使用此模式。
IDS/IPS 模式,參數為“-A”
請注意,Snort 提供多種警報模式。

  • 控制枱: 在控制枱屏幕上提供快速樣式警報。
  • cmg: 以十六進制和文本格式提供有效載荷的基本標頭詳細信息。
  • 完整: 完整警報模式,提供有關警報的所有可能信息。
  • 快速模式: 快速模式,顯示警報消息、時間戳、源 IP 地址、目標 IP 地址以及端口號。
  • None: 禁用警報。

在本節中,只有 “console”“cmg” 參數會在控制枱中顯示告警信息。無法通過終端區分其餘告警模式。可以通過查看生成的日誌來識別差異。

在本節末尾, 我們將比較“完整”、“快速”和“無”三種模式。請注意,這些參數不會提供控制枱輸出,因此我們將繼續通過日誌格式來識別它們之間的差異。

IDS/IPS 模式,參數為“-A console”
控制枱模式可在控制枱屏幕上提供快速提示信息。使用以下命令以控制枱 提示模式(-A console)啓動 Snort 實例:sudo snort -c /etc/snort/snort.conf -A console
現在 以 sudo 權限運行流量生成器腳本  ,並啓動 ICMP/HTTP 流量。 流量生成後,Snort 將根據配置文件中定義的規則集開始生成警報。
以控制枱警報模式運行

user@ubuntu$ sudo snort -c /etc/snort/snort.conf -A console
Running in IDS mode

        --== Initializing Snort ==--
Initializing Output Plugins!
Initializing Preprocessors!
Initializing Plug-ins!
Parsing Rules file "/etc/snort/snort.conf"
...
Commencing packet processing (pid=3743)
12/12-02:08:27.577495  [**] [1:366:7] ICMP PING *NIX [**] [Classification: Misc activity] [Priority: 3] {ICMP} 192.168.175.129 -> 142.250.187.110
12/12-02:08:27.577495  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 192.168.175.129 -> 142.250.187.110
12/12-02:08:27.577495  [**] [1:384:5] ICMP PING [**] [Classification: Misc activity] [Priority: 3] {ICMP} 192.168.175.129 -> 142.250.187.110
12/12-02:08:27.609719  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 142.250.187.110 -> 192.168.175.129
^C*** Caught Int-Signal
12/12-02:08:29.595898  [**] [1:366:7] ICMP PING *NIX [**] [Classification: Misc activity] [Priority: 3] {ICMP} 192.168.175.129 -> 142.250.187.110
12/12-02:08:29.595898  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 192.168.175.129 -> 142.250.187.110
12/12-02:08:29.595898  [**] [1:384:5] ICMP PING [**] [Classification: Misc activity] [Priority: 3] {ICMP} 192.168.175.129 -> 142.250.187.110
===============================================================================
Run time for packet processing was 26.25844 seconds
Snort processed 88 packets.

IDS/IPS 模式,參數為“-A cmg”
CMG 模式提供基本的頭部信息,包括有效載荷,支持十六進制和文本格式。使用以下命令以CMG 警報模式 (-A cmg)啓動 Snort 實例 :sudo snort -c /etc/snort/snort.conf -A cmg
現在 以 sudo 權限運行流量生成器腳本,並啓動ICMP/HTTP流量。 流量生成後,Snort 將根據配置文件中定義的規則集開始生成警報。 
以 CMG 警報模式運行

user@ubuntu$ sudo snort -c /etc/snort/snort.conf -A cmg
Running in IDS mode

        --== Initializing Snort ==--
Initializing Output Plugins!
Initializing Preprocessors!
Initializing Plug-ins!
Parsing Rules file "/etc/snort/snort.conf"
...
Commencing packet processing (pid=3743)
12/12-02:23:56.944351  [**] [1:366:7] ICMP PING *NIX [**] [Classification: Misc activity] [Priority: 3] {ICMP} 192.168.175.129 -> 142.250.187.110
12/12-02:23:56.944351 00:0C:29:A5:B7:A2 -> 00:50:56:E1:9B:9D type:0x800 len:0x62
192.168.175.129 -> 142.250.187.110 ICMP TTL:64 TOS:0x0 ID:10393 IpLen:20 DgmLen:84 DF
Type:8  Code:0  ID:4   Seq:1  ECHO
BC CD B5 61 00 00 00 00 CE 68 0E 00 00 00 00 00  ...a.....h......
10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F  ................
20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F   !"#$%&'()*+,-./
30 31 32 33 34 35 36 37                          01234567

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

在討論其他告警類型之前,我們先來比較一下控制枱模式和 CMG 模式的輸出。如上所示,控制枱模式提供基本的報頭和規則信息,而CMG 模式則提供完整的包詳細信息以及規則信息。

IDS /IPS 模式,參數為“-A fast”
快速模式提供警報消息、時間戳以及源和目標 IP 地址。請注意,此模式下沒有控制枱輸出。 使用以下命令以快速 警報模式 (-A fast)啓動 Snort 實例 : sudo snort -c /etc/snort/snort.conf -A fast

現在 以 sudo 權限運行流量生成器腳本  ,並 啓動 ICMP/HTTP 流量。 流量生成後,Snort 將根據配置文件中定義的規則集開始生成警報。

以快速警報模式運行

user@ubuntu$ sudo snort -c /etc/snort/snort.conf -A fast
Running in IDS mode

        --== Initializing Snort ==--
Initializing Output Plugins!
Initializing Preprocessors!
Initializing Plug-ins!
Parsing Rules file "/etc/snort/snort.conf"
...
Commencing packet processing (pid=3743)
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

我們來查看一下報警文件。

如上圖所示,快速樣式警報包含有關操作的摘要信息,例如方向和警報標題。

IDS /IPS 模式,參數為“-A full”
完整警報模式會提供有關警報的所有可能信息。 請注意,此模式下沒有控制枱輸出。 使用以下命令以完整 警報模式 (-A full)啓動 Snort 實例 :sudo snort -c /etc/snort/snort.conf -A full
現在 以 sudo 權限運行流量生成器腳本  ,並啓動 ICMP/HTTP 流量。 流量生成後,Snort 將根據配置文件中定義的規則集開始生成警報。 
處於完全警報模式

user@ubuntu$ sudo snort -c /etc/snort/snort.conf -A full
Running in IDS mode

        --== Initializing Snort ==--
Initializing Output Plugins!
Initializing Preprocessors!
Initializing Plug-ins!
Parsing Rules file "/etc/snort/snort.conf"
...
Commencing packet processing (pid=3744)
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

我們來查看一下報警文件。

如上圖所示,全樣式警報包含有關操作的所有可能信息。
 
IDS /IPS 模式,參數為“-A none”
禁用告警。此模式不會創建告警文件。但是,它仍然會記錄流量並以二進制轉儲格式創建日誌文件。 請注意,此模式下沒有控制枱輸出。 使用以下命令以非告警模式 (-A none)啓動 Snort 實例 : sudo snort -c /etc/snort/snort.conf -A none
現在 以 sudo 權限運行流量生成器腳本  ,並 啓動 ICMP/HTTP 流量。 流量生成後,Snort 將根據配置文件中定義的規則集開始生成警報。 
以非警報模式運行

, user@ubuntu$ sudo snort -c /etc/snort/snort.conf -A none
Running in IDS mode

        --== Initializing Snort ==--
Initializing Output Plugins!
Initializing Preprocessors!
Initializing Plug-ins!
Parsing Rules file "/etc/snort/snort.conf"
...
Commencing packet processing (pid=3745)
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

如下圖所示,沒有生成告警文件。Snort 只生成了日誌文件。

IDS /IPS 模式:“使用規則文件,無需配置文件”
Snort 可以僅使用規則運行,無需配置文件。在這種模式下運行 Snort 有助於測試用户創建的規則。但是,這種模式的性能會降低。
未配置配置文件運行

, user@ubuntu$ sudo snort -c /etc/snort/rules/local.rules -A console
Running in IDS mode

12/12-12:13:29.167955  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 192.168.175.129 -> 142.250.187.110
12/12-12:13:29.200543  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 142.250.187.110 -> 192.168.175.129
12/12-12:13:30.169785  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 192.168.175.129 -> 142.250.187.110
12/12-12:13:30.201470  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 142.250.187.110 -> 192.168.175.129
12/12-12:13:31.172101  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 192.168.175.129 -> 142.250.187.110
^C*** Caught Int-Signal

IPS 模式和丟包
Snort IPS模式可通過-Q-- daq afpacket參數激活。您也可以通過編輯 Snort.conf 文件來激活此模式。但是,在本討論範圍內,您無需編輯 Snort.conf 文件。有關 daq 和高級配置設置的更多信息,請參閲附加任務或 Snort 手冊: -Q --daq afpacket
激活數據採集(DAQ)模塊,並使用afpacket模塊將Snort用作入侵防禦系統(IPS):-i eth0:eth1
識別接口時請注意,Snort IPS至少需要兩個接口才能工作。現在 以 sudo 權限運行流量生成器腳本  ,並 啓動 ICMP/HTTP 流量。

跑步IPS模式

user@ubuntu$ sudo snort -c /etc/snort/snort.conf -q -Q --daq afpacket -i eth0:eth1 -A console
Running in IPS mode

12/18-07:40:01.527100  [Drop] [**] [1:1000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 192.168.175.131 -> 192.168.175.2
12/18-07:40:01.552811  [Drop] [**] [1:1000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 172.217.169.142 -> 192.168.1.18
12/18-07:40:01.566232  [Drop] [**] [1:1000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 192.168.175.131 -> 192.168.175.2
12/18-07:40:02.517903  [Drop] [**] [1:1000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 192.168.1.18 -> 172.217.169.142
12/18-07:40:02.550844  [Drop] [**] [1:1000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 172.217.169.142 -> 192.168.1.18
^C*** Caught Int-Signal

如上圖所示,Snort 這次攔截了數據包。 我們使用了相同的規則,但執行了不同的操作(丟棄/拒絕)。


請回答以下問題

使用默認配置文件調查流量情況。
sudo snort -c /etc/snort/snort.conf -A full -l .
執行sudo ./traffic-generator.sh 流量生成器腳本並選擇 “TASK-7 練習”。等待流量停止後,停止 Snort 實例。現在分析輸出摘要並回答問題。

檢測到的HTTP GET方法有多少個?
500

2

操作模式 4:PCAP 調查

讓我們用 Snort 來研究 PCAP。

Snort 的功能不僅限於嗅探、記錄和檢測/阻止威脅。PCAP讀取/分析模式可幫助您處理pcap文件。 一旦您擁有pcap文件並使用 Snort 進行處理,您將收到默認的流量統計信息以及根據您的規則集發出的警報。

如果不使用之前討論過的任何其他參數,讀取pcap 文件只能概覽數據包並提供文件統計信息。在大多數情況下,這不太方便。我們使用 Snort 分析pcap文件,以便利用其規則,並通過已知的威脅模式來加快調查過程。

請注意, 我們離開始創建規則已經很近了。因此,您需要掌握 Snort 的工作原理,瞭解之前討論過的參數,並開始根據不同的目的組合使用這些參數。

PCAP模式參數的解釋如下表所示;

範圍 描述
-r / -- pcap -single= 讀取單個pcap 文件
-- pcap -list="" 讀取命令中提供的 pcap 文件(以空格分隔)。
-- pcap -show 處理過程中在控制枱上顯示pcap名稱。

使用參數“-r”研究單個PCAP
為了進行測試,您仍然可以使用以下命令通過pcap測試默認讀取選項。snort -r icmp-test.pcap
讓我們使用配置文件來 分析pcap文件,看看會發生什麼。sudo snort -c /etc/snort/snort.conf -q -r icmp-test.pcap -A console -n 10
如果您不記得給定命令中參數的用途,請回顧之前的內容,然後再回來!
調查單一pcap文件

user@ubuntu$ sudo snort -c /etc/snort/snort.conf -q -r icmp-test.pcap -A console -n 10

12/12-12:13:29.167955  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 192.168.175.129 -> 142.250.187.110
12/12-12:13:29.200543  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 142.250.187.110 -> 192.168.175.129
12/12-12:13:30.169785  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 192.168.175.129 -> 142.250.187.110
12/12-12:13:30.201470  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 142.250.187.110 -> 192.168.175.129
12/12-12:13:31.172101  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 192.168.175.129 -> 142.250.187.110
12/12-12:13:31.204104  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 142.250.187.110 -> 192.168.175.129
12/12-12:13:32.174106  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 192.168.175.129 -> 142.250.187.110
12/12-12:13:32.208683  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 142.250.187.110 -> 192.168.175.129
12/12-12:13:33.176920  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 192.168.175.129 -> 142.250.187.110
12/12-12:13:33.208359  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 142.250.187.110 -> 192.168.175.129

我們的ICMP規則被觸發了!正如您在輸出結果中看到的,Snort識別出了流量,並根據我們的規則集發出了警報。

使用參數“--pcap-list”調查多個PCAP文件
讓我們使用配置文件檢查多個 pcap 文件,看看會發生什麼。 sudo snort -c /etc/snort/snort.conf -q --pcap-list="icmp-test.pcap http2.pcap" -A console -n 10
正在調查多個pcap文件

user@ubuntu$ sudo snort -c /etc/snort/snort.conf -q --pcap-list="icmp-test.pcap http2.pcap" -A console

12/12-12:13:29.167955  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 192.168.175.129 -> 142.250.187.110
12/12-12:13:29.200543  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 142.250.187.110 -> 192.168.175.129
12/12-12:13:30.169785  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 192.168.175.129 -> 142.250.187.110
12/12-12:13:30.201470  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 142.250.187.110 -> 192.168.175.129
12/12-12:13:31.172101  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 192.168.175.129 -> 142.250.187.110
...
12/12-12:13:31.204104  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 142.250.187.110 -> 192.168.175.129
12/12-12:13:32.174106  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 192.168.175.129 -> 142.250.187.110
12/12-12:13:32.208683  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 142.250.187.110 -> 192.168.175.129
12/12-12:13:33.176920  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 192.168.175.129 -> 142.250.187.110
12/12-12:13:33.208359  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 142.250.187.110 -> 192.168.175.129

我們的ICMP規則被觸發了! 正如您在輸出結果中看到的,Snort識別出了流量,並根據我們的規則集發出了警報。

需要注意一點:我們處理了兩個 pcap 文件,但其中包含大量告警,因此如果沒有 Snort 的幫助,無法將這些告警與提供的 pcap 文件進行匹配。我們需要單獨處理 pcap文件,以確定告警的來源。

使用參數“--pcap -show”調查多個PCAP文件

讓我們研究多個 pcap 文件,區分每個文件,看看會發生什麼。 sudo snort -c /etc/snort/snort.conf -q --pcap-list="icmp-test.pcap http2.pcap" -A console --pcap-show

正在調查多個pcap文件pcap信息

user@ubuntu$ sudo snort -c /etc/snort/snort.conf -q --pcap-list="icmp-test.pcap http2.pcap" -A console --pcap-show 

Reading network traffic from "icmp-test.pcap" with snaplen = 1514
12/12-12:13:29.167955  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 192.168.175.129 -> 142.250.187.110
12/12-12:13:29.200543  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 142.250.187.110 -> 192.168.175.129
12/12-12:13:30.169785  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 192.168.175.129 -> 142.250.187.110
...

Reading network traffic from "http2.pcap" with snaplen = 1514
12/12-12:13:35.213176  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 142.250.187.110 -> 192.168.175.129
12/12-12:13:36.182950  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 192.168.175.129 -> 142.250.187.110
12/12-12:13:38.223470  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 142.250.187.110 -> 192.168.175.129
...

我們的 ICMP 規則被觸發了! 正如您在輸出結果中看到的,Snort 識別出了流量,區分了每個pcap文件,並根據我們的規則集發出了警報。

現在,請使用所附的 虛擬機 ,並 導航到 Task-Exercises/Exercise-Files/TASK-8 文件夾來回答問題!

生成的警報數量是多少?
500

170

繼續閲讀輸出結果。 有多少個 TCP 段正在排隊?
500

18

繼續閲讀輸出結果。提取了多少個“HTTP響應頭”?
500

3

使用第二個配置文件檢查 mx-1.pcap 文件。
sudo snort -c /etc/snort/snortv2.conf -A full -l . -r mx-1.pcap
生成的警報數量是多少?
500

68

使用默認配置文件檢查mx-2.pcap文件。
sudo snort -c /etc/snort/snort.conf -A full -l . -r mx-2.pcap
生成的警報數量是多少?
500

348

繼續閲讀輸出結果。 檢測到的 TCP 數據包數量是多少?
500

82

使用默認配置文件檢查 mx-2.pcap 和 mx-3.pcap文件。
sudo snort -c /etc/snort/snort.conf -A full -l . --pcap-list="mx-2.pcap mx-3.pcap"
生成的警報數量是多少?
500

1020

Snort 規則結構


對於任何藍隊和紫隊隊員來説,理解Snort規則的格式至關重要。Snort規則的主要結構如下所示;

每條規則都應包含操作類型、協議、源 IP 地址和目標 IP 地址、源端口號和目標端口號以及選項。請記住,Snort 默認處於被動模式。因此,大多數情況下,您會將 Snort 用作入侵檢測系統 ( IDS)。您需要啓動 “內聯模式”才能啓用入侵防禦系統(IPS)模式。 但是,在使用內聯模式之前,務必熟悉 Snort 的各項功能和規則。

Snort規則結構易於理解,但編寫起來卻比較複雜。您需要熟悉規則選項及其相關細節,才能創建高效的規則。建議您針對不同的使用場景練習Snort規則及其選項。

在本房間,我們將介紹基本的規則結構,並幫助您入門 Snort 規則。您可以通過練習不同的用例並深入研究規則選項的細節,不斷提升規則創建技能。我們將重點介紹兩個操作:“警報”(IDS模式下)和 “拒絕”(IPS模式下)。

規則必須包含頭部信息才能被處理。規則選項是“可選”部分。 然而,如果不使用規則選項,幾乎不可能檢測到複雜的攻擊。

行動 規則有多種操作方式。在為生產系統創建規則之前,請務必瞭解其功能並進行全面測試。以下是最常見的操作方式:

- 警報:生成警報並記錄數據包。
- 日誌:記錄數據包。
- 丟棄:阻止並記錄數據包。
- 拒絕:阻止數據包,記錄日誌,並終止數據包會話。
協議 協議參數標識了規則中篩選出的協議類型。

請注意,Snort2 規則中僅支持四種協議過濾器(IP、TCP、UDP和 ICMP)。但是,您可以使用端口號和選項來檢測應用程序流。例如,如果您想檢測FTP流量,則不能在協議字段中使用FTP關鍵字;而是可以通過檢查端口 21 上的TCP流量來過濾FTP流量。

IP地址和端口號

這些參數用於識別根據規則篩選的源 IP 地址和目標 IP 地址以及相關的端口號。

IP過濾 alert icmp 192.168.1.56 any <> any any (msg: "ICMP Packet From "; sid: 100001; rev:1;)

 此規則將對來自 192.168.1.56 IP 地址的每個 ICMP 數據包創建警報。
過濾 IP 地址範圍 alert icmp 192.168.1.0/24 any <> any any (msg: "ICMP Packet Found"; sid: 100001; rev:1;)

 此規則將對來自 192.168.1.0/24 子網的每個 ICMP 數據包創建警報。
過濾多個 IP 地址範圍 alert icmp [192.168.1.0/24, 10.1.1.0/24] any <> any any (msg: "ICMP Packet Found"; sid: 100001; rev:1;)

 此規則將對源自 192.168.1.0/24 和 10.1.1.0/24 子網的每個 ICMP 數據包創建警報。
排除 IP 地址/範圍。 “否定運算符”用於排除特定的地址和端口。否定運算符用“!”表示。

alert icmp !192.168.1.0/24 any <> any any (msg: "ICMP Packet Found"; sid: 100001; rev:1;)

 此規則將對每個並非源自 192.168.1.0/24 子網的 ICMP 數據包創建警報。
端口過濾 alert tcp any any <> any 21 (msg: " FTP端口 21 檢測到命令活動"; sid: 100001; rev:1;)

此規則將對發送到端口 21 的每個TCP數據包創建警報。
排除特定端口 alert tcp any any <> any !21 (msg: "沒有FTP端口 21 命令通道的流量活動"; sid: 100001; rev:1;)

此規則將對每個未發送到端口 21 的TCP數據包創建警報。
過濾端口範圍(類型 1) alert tcp any any <> any 1:1024 (msg: " TCP 1-1024 系統端口活動"; sid: 100001; rev:1;)

此規則將對發送到 1 到 1024 端口之間的每個TCP數據包創建警報。
過濾端口範圍(類型 2) alert tcp any any <> any:1024 (msg: " TCP 0-1024 系統端口活動"; sid: 100001; rev:1;)

此規則將對發送到端口 1 到 1024 的每個TCP數據包創建警報。
過濾端口範圍(類型 3) alert tcp any any <> any 1025:  (msg: " TCP非系統端口活動"; sid: 100001; rev:1;)

此規則將對發送到源端口大於或等於 1025 的每個TCP數據包創建警報。
過濾端口範圍(類型 4) alert tcp any any <> any [21,23]  (msg: "檢測到FTP和 Telnet 端口 21-23 活動"; sid: 100001; rev:1;)

此規則將對發送到端口 21 和 23 的每個TCP數據包創建警報。

方向
方向運算符指示 Snort 要過濾的流量方向。規則左側顯示源地址,右側顯示目標地址。

  • -> 從源到目的地的流程。
  • <> 雙向流
    請注意, Snort 中沒有“<-”運算符。

Snort 中有三種主要規則選項。

  • 通用規則選項 -  Snort 的基本規則選項。
  • 有效載荷規則選項 - 用於分析有效載荷數據的規則選項。這些選項有助於檢測特定的有效載荷模式。
  • 非有效載荷規則選項 - 專注於非有效載荷數據的規則選項。這些選項有助於創建特定模式並識別網絡問題。

一般規則選項

消息 消息字段是對規則的基本提示和快速標識。規則觸發後,消息字段將顯示在控制枱或日誌中。通常,消息部分是一行概括事件的語句。
SID Snort 規則ID (SID) 具有預定義的作用域,每條規則都必須具有格式正確的 SID。SID 有三種不同的作用域,如下所示。

- <100: 保留規則
- 100-999,999: 規則隨產品一起提供。
- >=1,000,000: 用户創建的規則。

簡而言之,我們制定的規則邊長應大於 1 億。另一點也很重要,SID 不應重疊,且每個 ID 必須是唯一的。
Reference 每條規則都可以包含附加信息或參考資料,以解釋規則或威脅模式的用途。這些信息或參考資料可以是通用漏洞披露 ( CVE ) ID 或外部數據。為規則提供參考資料始終有助於分析人員進行警報和事件調查。
Rev Snort 規則可以進行修改和更新,以解決性能和效率問題。修訂選項允許分析人員訪問每條規則的修訂信息,從而輕鬆瞭解規則的改進情況。每條規則都有其唯一的修訂編號,規則歷史記錄沒有自動備份功能。分析人員應自行維護規則歷史記錄。“修訂”選項僅指示規則的修訂次數。

alert icmp any any <> any any  (msg: "ICMP Packet Found"; sid: 100001; reference: cve , CVE -XXXX;  rev:1 😉

有效載荷檢測規則選項

內容 有效載荷數據。它通過 ASCII、十六進制或兩者來匹配特定的有效載荷數據。此選項可以在單個規則中多次使用。但是,您創建的模式匹配特徵越具體,分析數據包所需的時間就越長。

以下規則將針對每個包含關鍵字“GET”的HTTP數據包創建警報。此規則選項區分大小寫!

- ASCII 模式 - alert tcp any any <> any 80 (msg: "GET 請求已發現"; content:"GET"; sid: 100001; rev:1;)
- HEX mode - alert tcp any any <> any 80 (msg: "GET Request Found"; content:"|47 45 54|"; sid: 100001; rev:1;)
Nocase 已禁用大小寫區分, 用於增強內容搜索效果。

alert tcp any any <> any 80 (msg: "GET Request Found"; content:"GET"; nocase; sid: 100001; rev:1;)
快速模式 優先搜索內容可以加快有效載荷搜索速度。默認情況下,Snort 會使用最大的內容並將其與規則進行比對。“fast_pattern”選項可以幫助您選擇具有特定值的初始數據包匹配項,以便進行進一步調查。此選項始終不區分大小寫,並且每個規則只能使用一次。請注意,當使用多個“content”選項時,必須啓用此選項。 

以下規則有兩個內容選項,fast_pattern 選項指示 Snort 使用第一個內容選項(在本例中為“GET”)進行初始數據包匹配。

alert tcp any any <> any 80 (msg: "GET Request Found"; content:"GET"; fast_pattern; content:"www"; sid:100001; rev:1;)

非有效載荷檢測規則選項
還有一些規則選項專門針對非有效載荷數據, 這些選項有助於創建特定模式並識別網絡問題。

ID 過濾 IP ID 字段
alert tcp any any <> any any (msg: "ID TEST"; id:123456; sid: 100001; rev:1;)
flags 過濾TCP標誌
- F -FIN
- S -SYN
- R -RST
- P -PSH
- A -ACK
- U -URG

alert tcp any any <> any any (msg: "FLAG TEST"; flags:S; sid: 100001; rev:1;)
dsize 過濾數據包有效載荷大小
- dsize:min<>max;
- dsize:>100
- dsize:<100

alert ip any any <> any any (msg: "SEQ TEST"; dsize:100<>300; sid: 100001; rev:1;)
Sameip 過濾重複的源IP地址和目標IP地址
alert ip any any <> any any (msg: "SAME-IP TEST"; sameip; sid: 100001; rev:1;)

請記住,一旦創建規則,它就成為本地規則,應該保存在“local.rules”文件中。該文件位於“/etc/snort/rules/local.rules”。下面簡要介紹如何編輯本地規則。

修改本地規則

user@ubuntu$ sudo gedit /etc/snort/rules/local.rules 

那是你的"local.rules"文件。

請注意,Snort 實例默認啓用了一些規則。為了方便您管理規則並改善鍛鍊體驗,這些規則已被禁用。更多信息,請參閲Snort 用户手冊:http://manual-snort-org.s3-website-us-east-1.amazonaws.com。

至此,我們已經介紹了Snort規則的基本結構。建議在創建高級規則和使用其他選項之前,先理解並練習這些基礎知識。

哇!我們已經掌握了 Snort 規則的基礎知識!   現在,請使用附件中的虛擬機,並導航到 Task-Exercises/Exercise-Files/TASK-9文件夾來回答問題! 請注意,您可以使用以下命令在當前目錄中創建日誌:-l


請回答以下問題

使用“task9.pcap”文件。編寫一條規則來過濾 IP ID “35369”,並針對給定的 pcap 文件運行該規則。檢測到的數據包的請求名稱是什麼?您可以使用以下命令:“snort -c local.rules -A full -l . -r task9.pcap”

規則:alert icmp any any <> any any (MSG:"alert id 335369"; ID:35369; SID:10001; REV:1)

執行:snort -c local.rules -A full -l . -r task9.pcap
完事後他會保存一個snort.log.xxx文件的
使用snort -dvr snort.log.xxx 打開即可看到下面數據

TIMESTAMP REQUEST

清除之前的告警文件並註釋掉舊規則。創建一條規則來過濾帶有Syn標誌的數據包,並針對給定的 pcap 文件運行該規則。檢測到的數據包數量是多少?
規則:alert tcp any any <> any any (MSG:"SYN alert"; FLAGS:S; SID:10002; REV:1)
執行:snort -c local.rules -A full -l . -r task9.pcap
完事後他會保存一個snort.log.xxx文件的
使用snort -dvr snort.log.xxx 打開即可看到下面數據

1

清除之前的告警文件並註釋掉舊規則。編寫一條規則來過濾帶有Push-Ack標誌的數據包,並將其應用於給定的 pcap 文件。檢測到的數據包數量是多少?

# 刪掉這些產生的日誌文件先
sudo rm -rf snort.log.*

把規則寫進local.rules,規則如下:
規則:alert tcp any any <> any any (MSG:"SYN PUSH ACK alert"; FLAGS:P,A; SID:10003; REV:1)
執行:snort -c local.rules -A full -l . -r task9.pcap

回車snort查看後就能看到多少個包了

216

清除之前的告警文件並註釋掉舊規則。創建一條規則來過濾源 IP 和目標 IP 相同的UDP數據包,並將其應用於給定的 pcap 文件。有多少個數據包的源地址和目標地址相同?
做之前記得刪除那個snort.log.xxx,你不想刪除也可以,記得找時間戳作為文件後綴最大的那個才是最新的
規則:alert udp any any <> any any (MSG:"sampeip alert"; SAMPEIP; SID:10004; REV:1)
執行:snort -c local.rules -A full -l . -r task9.pcap
同理執行後使用snort查看這個log

7

案例示例——一位分析師成功修改了一條現有規則。實施後,分析師必須更改規則中的哪個選項?

# 版本
rev

Snort2 操作邏輯:要點回顧

要點回顧
鼻噴劑的主要成分

  • 數據包解碼器 - Snort 的數據包收集器組件。它收集並準備數據包以進行預處理。
  • 預處理器 - 用於整理和修改檢測引擎數據包的組件。
  • 檢測引擎 - 主要組件,它通過應用規則來處理、剖析和分析數據包。
  • 日誌記錄和告警 - 日誌和告警生成組件。
  • 輸出和插件 - 此組件支持輸出集成模塊(例如,向 syslog/mysql 發送警報)和其他插件(規則管理檢測插件)。
Snort規則

Snort 共有三種規則類型,具體説明如下:

  • 社區規則 - 根據 GPLv2 協議發佈的免費規則集。公開訪問,無需註冊。
  • 註冊規則 - 免費規則集(需要註冊)。此規則集包含訂閲者規則,延遲 30 天生效。
  • 訂閲用户規則(付費) - 付費規則集(需要訂閲)。此規則集為主規則集,每週更新兩次(週二和週四)。

下載並閲讀更多規則:https://www.snort.org/downloads

注意:安裝 Snort2 後,它會自動創建所需的目錄和文件。但是,如果您想使用社區版或付費版規則,則需要在 Snort.conf 文件中分別指定每條規則。

由於 Snort 的配置文件篇幅很長,而且包含所有功能,因此對於一些用户來説,在不造成配置錯誤的情況下對其進行編輯會比較麻煩。正因如此,Snort 提供了多個規則更新模塊和集成工具。總而言之,切勿直接替換已配置的 Snort 配置文件;而應手動編輯配置文件,或使用其他工具和模塊更新規則,以避免出現故障、崩潰或功能缺失等問題。

  • snort.conf:主配置文件。
  • local.rules:用户生成的規則文件。
    讓我們先來概覽一下主配置文件(snort.conf)。
    sudo gedit /etc/snort/snort.conf。

導航至“步驟 1:設置網絡變量”部分。
本節管理檢測範圍和規則路徑。

標籤名稱 信息 例子
家庭網絡 這就是我們正在保護的地方。 'any' 或 '192.168.1.1/24'
外部網絡 此字段表示外部網絡,因此我們需要將其設置為“any”或“!$HOME_NET”。 'any' 或 '!$HOME_NET'
規則路徑 硬編碼規則路徑。 /etc/snort/rules
SO_RULE_PATH 這些規則與註冊用户規則和訂閲用户規則一起提供。 $RULE_PATH/so_rules
PREPROC_RULE_PATH 這些規則與註冊用户規則和訂閲用户規則一起提供。 $RULE_PATH/plugin_rules

導航至“步驟 2:配置解碼器”部分。
在本節中,您可以管理Snort 的IPS模式。單節點安裝的IPS模型與“afpacket”模式配合使用效果最佳。您可以啓用此模式並在IPS 模式下運行 Snort 。

標籤名稱 信息 例子
#配置數據採集 IPS模式選擇。 afpacket
#配置 daq_mode 激活內聯模式 inline
#配置日誌目錄 默認日誌路徑是硬編碼的。 /var/logs/snort

數據採集​​模塊 (DAQ) 是專門用於數據包 I/O 的庫,可提供靈活的數據包處理方式。可以根據不同的用途選擇DAQ類型和模式。

Snort 中有六個數據採集模塊:

  • PCAP:默認模式,也稱為嗅探器模式。
  • Afpacket:內聯模式,也稱為IPS模式。
  • Ipq:在Linux上使用 Netfilter 實現的內聯模式。它取代了 snort_inline 補丁。
  • Nfq: Linux上的內聯模式。
  • Ipfw:在 OpenBSD 和 FreeBSD 上使用重定向套接字,配合 pf 和 ipfw 防火牆進行內聯。
  • 轉儲:測試內聯和規範化模式。

最流行的模式是默認模式(pcap)和內聯/ IPS(Afpacket)。

導航至“步驟 6:配置輸出插件”部分。
此部分管理IDS / IPS操作的輸出,包括日誌記錄和告警格式的詳細信息。默認情況下,所有信息都會顯示在控制枱應用程序中,因此配置此部分將有助於您更高效地使用 Snort。

導航至“步驟 7:自定義規則集”部分。

標籤名稱 信息 例子
# 特定站點規則 硬編碼的本地和用户生成的規則路徑。 包含 $RULE_PATH/local.rules
#include $RULE_PATH/ 硬編碼的默認/已下載規則路徑。 包含 $RULE_PATH/規則名稱

請注意,“#” 是註釋運算符。
您需要取消註釋才能激活該行。

user avatar
0 位用戶收藏了這個故事!

發佈 評論

Some HTML is okay.