Zeek如何提供對加密通信的感知

Zeek如何提供對加密通信的感知，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

概述

   加密通信現已無處不在，但從某種程度上說，加密不僅保證了信息的機密性，也沒有阻礙對流量進行分析。某些協議（如 SSH 與 TLS）可以確保流量分析工具不能直接讀取內容，但對傳輸數據的大小和順序的分析是可以提供幫助的。本文將概述 Zeek 用于提供 SSH 連接可見性的一些工作。

任何在對外暴露的 IP 上觀察過網絡流量的人都可以看到互聯網中的各種連接。未許可的、來自互聯網掃描儀、爬蟲、蠕蟲與反射的連接都是很常見的。類似 Shodan、Greynoise 與 Censys 的服務提供商創造了互聯網范圍內的掃描數據，提供用于取證和情報調查的歷史數據集。雖然這些服務都是良性的，也可以向提供商提交排除掃描的要求。但并不是所有的掃描都是良性的，比如 Mirai 的變體。僵尸網絡會掃描 SSH 和 Telnet 服務，并嘗試使用默認的密碼列表進行登錄嘗試。

Zeek 的 SSH 暴力破解檢測

檢測針對主機的 SSH 暴力破解是 Zeek 提供的“開箱即用”的能力之一。啟用針對 SSH 暴力破解的策略腳本后，Zeek 就可以跟蹤每個主機成功、失敗的 SSH 連接嘗試，以此來檢測 SSH 暴力破解。該腳本檢測的是 SSH 暴力破解嘗試，如果是憑據竊取，則稱為 Credential Stuffing。

此腳本的邏輯是使用 SumStats 框架統計 ssh_auth_successful 和 ssh_auth_failed 事件的數量。每次發生 ssh_auth_failed 事件時，計數器都會遞增。如果計數器超過配置的閾值（password_guesses_limit），就會發出告警。如果通過密碼猜測最終登錄成功服務器，腳本也會發出告警。如果在 ssh_auth_failed 事件后看到 ssh_auth_successful 事件，且發起和響應的主機也相同，Zeek 推斷已經通過暴力破解登錄成功。進一步理解 SSH 協議對理解到底是什么原因導致了 ssh_auth_successful 事件與 ssh_auth_failed 事件是十分必要的。

SSH 協議

RFC 4251 對 SSH 的描述：SSH 協議是一種用于通過不安全網絡進行安全遠程登錄和其他網絡服務的協議。該協議由三個子協議組成，具有不同的消息類型，以便在控制端和客戶端之間交換信息。這三個子協議負責不同的任務，包括：

傳輸層協議，用于建立加密并完善其他兩個子協議

認證協議，用于驗證 SSH 連接的端點

連接協議，用于提供交互式會話、命令執行、X11 Forwarding 或是端口連接

下圖描述的就是典型 SSH 連接交換信息的過程。最初建立 TCP 連接，兩個端點都發送它們的版本標示字符串，這與 HTTP 協議中的 User-Agent 類似，但 SSH 中需要雙方都各提供一個。在交換后進行初始密鑰交換，這有助于創建對稱密鑰加密隧道。在加密開始之前要明確協商使用的密碼套件、壓縮方法和其他配置選項。圖中頂部的框就顯示了這種交換，標記為 In the clear。值得注意的是，在明文中交換的信息也被 HASSH 等指紋技術所使用。

盡管 SSH 協議沒有強制要求加密開始后必須要做什么。但大多數客戶端都向服務器發送類型為 ssh-userauth 的服務請求消息，（在下圖的綠色框內標記為“Encrypted”的第一條發送的消息），指示客戶端希望向服務器發起身份驗證。服務器通過接受消息 SSH_MSG_SERVICE_ACCEPT 或斷開消息 SSH_MSG_DISCONNECT 響應客戶端的服務請求，斷開消息將終止 TCP 連接。如果 TCP 連接沒有終止，則可以認為服務器向客戶端發送了接受消息。測量服務器接受消息的大小也是信息泄漏的一個例子。這就是 Zeek 如何推斷成功的 SSH 身份驗證，從而生成 ssh_auth_successful 事件的關鍵。

身份驗證完成后，客戶端會向服務器發起另一個服務請求。與類型為 ssh-authuser 的第一次服務請求不同，第二次服務請求的類型為 ssh-connection。同樣的，如果服務器接受客戶端的服務請求，將會發送服務接受消息而不是斷開消息。如上圖的紫色框中所示，交換連接協議。這些消息用于發出特定的請求，如用于交互式登錄的 PTY 會話、用于 X11 Forwarding 的 X11 會話或用于 SFTP 的會話。在 SSH 協議中測量此時數據包的大小也可用于推斷客戶端和服務器之間建立的會話類型，例如檢測文件上傳時就具備易于識別的包大小。

Zeek 中與 SSH 相關的事件

通過了解 SSH 協議和數據包大小的不同狀態，就可以了解 Zeek 何時會生成 ssh_auth_successful 和 ssh_auth_failed 事件。代碼中也顯示了 SSH 分析器以 generate_ssh_auth_ 為開頭的事件產生的邏輯。

查看之前的代碼提交記錄可以發現靈感的來源，SSH.cc 文件的歷史顯示當前的代碼邏輯是在四年前添加的。ProcessEncrypted 函數中的邏輯可以總結如下：

1、確定服務器的 SSH_MSG_SERVICE_REQUEST 數據包的大小，標記為Auth service accept

2、確定客戶端的未經身份驗證的狀態（在圖中被標記為 Optional auth request (none)）是否會導致服務器發出 SSH_MSG_USERAUTH_SUCCESS 或 SSH_MSG_USERAUTH_FAILURE 的響應 a. 身份驗證成功將比步驟 1 中的數據包小 16 個字節 b. 失敗的包大小會存在差異

3、在步驟 2a 中成功消息發送到客戶端前，確定服務器是否發送了圖中標記為 Optional banner 的可選 Banner

4、檢查服務器對在圖中標記為 Auth request (publickey) 的客戶端第二次身份認證嘗試的響應包大小 a. 認證成功將比步驟 1 中的數據包小 16 個字節 b. 失敗的包大小與步驟 2b 的大小相同

這就了解了 Zeek 如何推斷身份認證成功的，但還沒有了解如何推斷身份認證失敗的。ssh_auth_failed 事件永遠不會是 SSH 協議分析器觸發的，而是 Zeek scriptland 觸發的。這些代碼顯示一旦 SSH 連接將要在 Zeek Core 中過期就會觸發 ssh_auth_failed 事件。任何未觸發 ssh_auth_successful 事件又完成的 SSH 連接都有可能觸發 ssh_auth_failed 事件。回想一下上一節中，ssh_auth_failed 事件被用于在請求主機與響應主機之間進行計數，與設置好的閾值進行比較。

回到暴力破解

最近 Corelight 實驗室分析了有關 SSH 數據包的一組細節，這些數據包是從一個規模適中的網絡收集來的。數據集包括匿名的遠程主機與本地主機的主機號、端口號、時間戳與數據包大小。在我們分析的過程中，很快就發現只需要檢查數據包的大小與排序，就可以對連接行為進行惡意推斷，即便是加密流量也沒問題。

為了描述這一發現，我們首先將數據集劃分成不同的會話，然后將會話表示為圖形。這些圖形表示在概念上與 Joy 使用的 SPLT 分析有些類似。

下圖是認證嘗試的示例，X 軸為時間，紅色表示本地主機發送的分組大小，藍色表示遠程主機發送的分組大小。這個示例是遠程主機 1 試圖對本地主機 66 進行暴力破解。本地主機 66 可能配置為響應客戶端身份驗證嘗試失敗前要延遲一段時間，小數據包交換之間的間隙就可以證明這一點。會話開始時的大數據包可能反映了初始密鑰交換，即上圖中的 kex_algorithms…。

下圖是成功連接的 SSH 會話示例，本地主機已經成功通過遠程主機驗證，并開始將數據傳送給遠程主機。本地主機生成 PDU 的大小可能超過以太網的 MTU，在圖中包的大小總是接近 1500。假設這些都成功后，遠程主機 78 屬于 GitHub 的基礎設施，這個 SSH 會話可能用于傳輸一些小文件。

下面兩幅圖是成功認證后長時間傳輸大量數據的圖形表示。第一幅圖顯示了客戶端傳輸大量數據的 SSH 會話示例，第二幅圖顯示了服務器傳輸大量數據的 SSH 會話示例。

上面講述了 Zeek 提供加密通信可見性的眾多方法之一。僅僅是傳輸的內容被加密并不能阻止所有的分析方法，本文中討論的許多概念也可以用于 TLS，一些研究也針對 HTTP 進行了研究。此外，其他一些研究表明包分析可以用于識別那些包含對 Shell 或 pty 訪問請求的 SSH_MSG_CHANNEL_REQUEST 數據包的大小。

關于Zeek如何提供對加密通信的感知問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。