作者Richard Bejtlich，Corelight首席安全性原則師

在我上一篇文章中，我介紹了一種觀點，即對加密HTTP流量的分析需要不同的分析模型。如果您希望保留加密（而不是通過中間框進行檢查），則必須放弃對HTTP有效負載的直接檢查，以識別正常、惡意和可疑的活動。

在本文中，我將使用Zeek日誌來演示分析加密HTTP流量的其他方法，目的是將不確定性的海洋减少到值得研究的活動子集。如果我們能用Zeek數據解决這個問題，太好了。如果我們做不到，至少我們已經决定了在哪裡需要進行額外的調查，也許是通過應用情報、基於主機的日誌數據或其他資源。

因為我們在討論加密問題，所以我從Zeek的x509.log開始。X509是一個定義公開金鑰證書格式的Internet標準。這些證書是與https通信一起使用的SecureSockets層（SSL）和傳輸層安全性（TLS）加密的一個重要元素。

在下麵的示例中，我要分析用於簽名x509證書的算灋。

最後的結果令人擔憂。我不希望在我的環境中看到任何由SHA1算灋簽名的證書。正如Mozilla所解釋的，SHA1存在許多問題，使其不適合現代環境。這是可疑的還是惡意的？我可以想像一個場景，一個入侵者不擔心簽名衝突，因為他的惡意軟件不在乎被穀歌的網頁搜索算灋排名靠後。

接下來，我使用SHA1算灋蒐索Zeek x509.log條目。

除了包含匹配項的特定日誌之外，我在這裡收集了一些重要資訊。首先，我得到一個檔案識別字FTGvvp4TC5GHCel6ad，我將很快利用它。此檔案識別字唯一標識Zeek在加密會話期間觀察到的x509證書。其次，我看到這個證書是由cn=http.l.root-servers.org頒發的，OU=LROOT，O=ICANN，l=New Taipei，C=TW。我不知道這本身是否有問題。我還注意到，證書似乎是在2018年底頒發的，這是奇怪的，因為有警告說x509證書不能使用SHA1。

使用檔案ID，我開始查找其他Zeek日誌條目。這展示了Zeek日誌的真正威力：它們可以通過類似檔案ID的條目進行連結。我將依次檢查它們的顯示。（注意，我本可以蒐索證書識別字以查找其他日誌條目。我還可以通過日誌向外部源獲取有關此識別字的更多資訊。）

上面有一個files.log條目。

這是Zeek在跟踪加密會話並寫入x509.log的過程中生成的。這是一個關鍵日誌，因為它提供了連接ID CJDF553HmA2WdUq1Af，我們可以使用它來查找其他Zeek日誌。files.log還包含源和目標IP地址，但我們將依賴連結日誌來獲取有關會話的更多資訊。

接下來是ssl.log。

此日誌項提供有關感興趣會話中使用的加密性質的詳細資訊。我們有和前面一樣的IP地址，還有埠。我稍後再談這些。暫時注意ja3和ja3s欄位的最後兩個粗體條目。我很快也會回到那些問題上。此日誌中最重要的部分是CJDF553HmA2WdUq1Af的uid，在完成搜索結果後立即使用。這是我們稍後將蒐索的連接識別字。

最後一個日誌是x509.log。我在這裡展示它是為了演示在剛才顯示的三種類型的日誌中蒐索檔案ID的結果：files.log、ssl.log和x509.log。按照邏輯創建的順序，它們將列為ssl.log、x509.log和files.log。

返回ssl.log的結果，您會記得我們找到了一個連接ID。讓我們蒐索它並查看我們找到了什麼。再次，我將一次顯示一個條目並解釋相關方面。

conn.log是一種“頂級”Zeek日誌。

Zeek為“connections”創建conn.log條目，不管它們是面向連接的（如TCP）還是無連接的（如UDP）。此項向我們顯示有關連接的流詳細資訊，如源IP（10.10.40.48）、目標IP（199.7.83.80）、源埠和目標埠（36780和443）以及IP協議（TCP）。

我對這三個結果稍微重新排序，以便分組和跳過它們。conn summary log基本上是conn.log的重複（在本例中），我們已經看到了檔案.log和ssl.log。讓我們繼續解釋下一個獨特的結果。

上面是notice.log。Zeek為感興趣的連接生成此項，因為它是自簽名證書。這本身並不能告訴我們事件是正常的、可疑的還是惡意的，但它仍然是不需要的。

上面是notice.log。Zeek為感興趣的連接生成此項，因為它是自簽名證書。這本身並不能告訴我們事件是正常的、可疑的還是惡意的，但它仍然是不需要的。

如果我們想把這些日誌看作一個鏈，我會直接訂購它們（忽略conn-summary.log，因為它在大多數情况下是一個“元”日誌）。

conn.log、ssl.log、x509.log、files.log、notice.log

讓我們以ssl.log中的兩個感興趣的條目為中心，ja3和ja3 s條目。JA3根據用戶端和服務器TLS連接的各個方面對連接進行指紋識別。ja3條目反映客戶機，ja3s條目反映服務器。對於ssl.log，我們有以下元素：

首先我們要尋找ja3客戶的指紋。哪些系統向其服務器提供與TLS會話相同的方面？我忽略了我們在下麵的結果中已經查看過的服務器，只顯示了新的資訊。

看起來我們感興趣的主機10.10.40.48是我們網絡上唯一在運行的系統，但是我們找到了另外兩個與10.10.40.48通信的服務器—193.0.6.139和193.0.6.158。如果我們願意的話，我們可以以這些IP地址為中心。還要注意新的ja3s值。

現在讓我們看看伺服器端是否有其他服務器向其客戶機提供類似的TLS連接特性。我們從前面的ssl.log中獲取jas3值。

真有趣！看起來我們有三臺蘋果iTunes服務器，它們使用的TLS連接管道與那些接受10.10.40.48版本連接的服務器相同，並且我們有三臺獨特的用戶端連接到每臺服務器。這可能是正常的，但有趣的是。請記住，如果我們希望避開這些結果，我們可以選擇一個會話並蒐索連接ID。在下麵的示例中，我將查找最後三個結果（粗體）中第一個結果的連接ID。

如您所見，Zeek提供了大量與識別字連結的日誌，使您能够拉動各種線程。

在本例中，我無法從Zeek日誌本身確定SHA1證書簽名算灋的使用性質。

然而，Zeek日誌提供了一些資訊，我可以用來做進一步的調查。我有源和目標IP地址，以及正在播放的加密證書的資訊。至少，我已經找到了一種方法，可以讓顯微鏡聚焦在一個問題上；我不會烦乱於在哪裡尋找問題。

例如，我可以選擇查看所討論的奇數主機10.10.40.48的其他Zeek日誌。它還使用什麼協定？它與誰有聯系，又是如何聯系的？Zeek dns.log可能特別有趣。或許我們將在下一篇博客文章中討論這些問題。

這種在面對加密時使用網絡級數據來識別感興趣的問題的概念是我的主要觀點，我希望您在查看Zeek日誌的過程中感到愉快！