Zeek如何提供對(duì)加密通信的感知

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

概述

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

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

Zeek 的 SSH 暴力破解檢測(cè)

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

此腳本的邏輯是使用 SumStats 框架統(tǒng)計(jì) ssh_auth_successful 和 ssh_auth_failed 事件的數(shù)量。每次發(fā)生 ssh_auth_failed 事件時(shí)，計(jì)數(shù)器都會(huì)遞增。如果計(jì)數(shù)器超過(guò)配置的閾值（password_guesses_limit），就會(huì)發(fā)出告警。如果通過(guò)密碼猜測(cè)最終登錄成功服務(wù)器，腳本也會(huì)發(fā)出告警。如果在 ssh_auth_failed 事件后看到 ssh_auth_successful 事件，且發(fā)起和響應(yīng)的主機(jī)也相同，Zeek 推斷已經(jīng)通過(guò)暴力破解登錄成功。進(jìn)一步理解 SSH 協(xié)議對(duì)理解到底是什么原因?qū)е铝?nbsp;ssh_auth_successful 事件與 ssh_auth_failed 事件是十分必要的。

SSH 協(xié)議

RFC 4251 對(duì) SSH 的描述：SSH 協(xié)議是一種用于通過(guò)不安全網(wǎng)絡(luò)進(jìn)行安全遠(yuǎn)程登錄和其他網(wǎng)絡(luò)服務(wù)的協(xié)議。該協(xié)議由三個(gè)子協(xié)議組成，具有不同的消息類型，以便在控制端和客戶端之間交換信息。這三個(gè)子協(xié)議負(fù)責(zé)不同的任務(wù)，包括：

傳輸層協(xié)議，用于建立加密并完善其他兩個(gè)子協(xié)議

認(rèn)證協(xié)議，用于驗(yàn)證 SSH 連接的端點(diǎn)

連接協(xié)議，用于提供交互式會(huì)話、命令執(zhí)行、X11 Forwarding 或是端口連接

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

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

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

Zeek 中與 SSH 相關(guān)的事件

通過(guò)了解 SSH 協(xié)議和數(shù)據(jù)包大小的不同狀態(tài)，就可以了解 Zeek 何時(shí)會(huì)生成 ssh_auth_successful 和 ssh_auth_failed 事件。代碼中也顯示了 SSH 分析器以 generate_ssh_auth_ 為開(kāi)頭的事件產(chǎn)生的邏輯。

查看之前的代碼提交記錄可以發(fā)現(xiàn)靈感的來(lái)源，SSH.cc 文件的歷史顯示當(dāng)前的代碼邏輯是在四年前添加的。ProcessEncrypted 函數(shù)中的邏輯可以總結(jié)如下：

1、確定服務(wù)器的 SSH_MSG_SERVICE_REQUEST 數(shù)據(jù)包的大小，標(biāo)記為Auth service accept

2、確定客戶端的未經(jīng)身份驗(yàn)證的狀態(tài)（在圖中被標(biāo)記為 Optional auth request (none)）是否會(huì)導(dǎo)致服務(wù)器發(fā)出 SSH_MSG_USERAUTH_SUCCESS 或 SSH_MSG_USERAUTH_FAILURE 的響應(yīng) a. 身份驗(yàn)證成功將比步驟 1 中的數(shù)據(jù)包小 16 個(gè)字節(jié) b. 失敗的包大小會(huì)存在差異

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

4、檢查服務(wù)器對(duì)在圖中標(biāo)記為 Auth request (publickey) 的客戶端第二次身份認(rèn)證嘗試的響應(yīng)包大小 a. 認(rèn)證成功將比步驟 1 中的數(shù)據(jù)包小 16 個(gè)字節(jié) b. 失敗的包大小與步驟 2b 的大小相同

這就了解了 Zeek 如何推斷身份認(rèn)證成功的，但還沒(méi)有了解如何推斷身份認(rèn)證失敗的。ssh_auth_failed 事件永遠(yuǎn)不會(huì)是 SSH 協(xié)議分析器觸發(fā)的，而是 Zeek scriptland 觸發(fā)的。這些代碼顯示一旦 SSH 連接將要在 Zeek Core 中過(guò)期就會(huì)觸發(fā) ssh_auth_failed 事件。任何未觸發(fā) ssh_auth_successful 事件又完成的 SSH 連接都有可能觸發(fā) ssh_auth_failed 事件?；叵胍幌律弦还?jié)中，ssh_auth_failed 事件被用于在請(qǐng)求主機(jī)與響應(yīng)主機(jī)之間進(jìn)行計(jì)數(shù)，與設(shè)置好的閾值進(jìn)行比較。

回到暴力破解

最近 Corelight 實(shí)驗(yàn)室分析了有關(guān) SSH 數(shù)據(jù)包的一組細(xì)節(jié)，這些數(shù)據(jù)包是從一個(gè)規(guī)模適中的網(wǎng)絡(luò)收集來(lái)的。數(shù)據(jù)集包括匿名的遠(yuǎn)程主機(jī)與本地主機(jī)的主機(jī)號(hào)、端口號(hào)、時(shí)間戳與數(shù)據(jù)包大小。在我們分析的過(guò)程中，很快就發(fā)現(xiàn)只需要檢查數(shù)據(jù)包的大小與排序，就可以對(duì)連接行為進(jìn)行惡意推斷，即便是加密流量也沒(méi)問(wèn)題。

為了描述這一發(fā)現(xiàn)，我們首先將數(shù)據(jù)集劃分成不同的會(huì)話，然后將會(huì)話表示為圖形。這些圖形表示在概念上與 Joy 使用的 SPLT 分析有些類似。

下圖是認(rèn)證嘗試的示例，X 軸為時(shí)間，紅色表示本地主機(jī)發(fā)送的分組大小，藍(lán)色表示遠(yuǎn)程主機(jī)發(fā)送的分組大小。這個(gè)示例是遠(yuǎn)程主機(jī) 1 試圖對(duì)本地主機(jī) 66 進(jìn)行暴力破解。本地主機(jī) 66 可能配置為響應(yīng)客戶端身份驗(yàn)證嘗試失敗前要延遲一段時(shí)間，小數(shù)據(jù)包交換之間的間隙就可以證明這一點(diǎn)。會(huì)話開(kāi)始時(shí)的大數(shù)據(jù)包可能反映了初始密鑰交換，即上圖中的 kex_algorithms…。

下圖是成功連接的 SSH 會(huì)話示例，本地主機(jī)已經(jīng)成功通過(guò)遠(yuǎn)程主機(jī)驗(yàn)證，并開(kāi)始將數(shù)據(jù)傳送給遠(yuǎn)程主機(jī)。本地主機(jī)生成 PDU 的大小可能超過(guò)以太網(wǎng)的 MTU，在圖中包的大小總是接近 1500。假設(shè)這些都成功后，遠(yuǎn)程主機(jī) 78 屬于 GitHub 的基礎(chǔ)設(shè)施，這個(gè) SSH 會(huì)話可能用于傳輸一些小文件。

下面兩幅圖是成功認(rèn)證后長(zhǎng)時(shí)間傳輸大量數(shù)據(jù)的圖形表示。第一幅圖顯示了客戶端傳輸大量數(shù)據(jù)的 SSH 會(huì)話示例，第二幅圖顯示了服務(wù)器傳輸大量數(shù)據(jù)的 SSH 會(huì)話示例。

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

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