在過去的幾年裡，Honeynet Project 已經收集和歸檔了 backhat 的活動訊息，我們盡我們最大的能力來記錄和捕捉對 Honeynet 每一個探測，攻擊，和使用。這些原始的數據有很高價值。我們的重點會放在兩個部分，第一，我們打算演示 Blackhat 團體是怎樣活動的。不管你是誰，你是不安全的，我們的目標是讓你認識到這些威脅的存在。其二，為了對一些早期警告和預報內容的進行測試，通過鑒別方法和傾向，可能預測在攻擊發生之前的攻擊和進行一定程度的對抗。我們使用 Honeynet Project 採集到的數據來測試這個理論。

The Collected Data
Honeynet Project 維護著 8 個高度的控制和完全監視的網路，我們收集和歸檔了 2000 年 4 月到 2001 年 2 月這段時期中網路的每一個攻擊，Honeynet 有 8 個 IP 位址組成，使用本地 ISP 提供的單一 ISDN 連接，這種連接類型類似與大多數家庭用戶或者小型商業用戶。實際上，Honeynet 位於其中一 Project 成員空餘的臥室中。在那段時期，Honeynet 中存在 3 個系統，其中包括如下：Solaris Sparc, WinNT, Win98, 和 Linux Red Hat 作業系統。

Honeynet 網路是用來捕捉數據的網路，是一些使用普通的網路作業統，如：Red Hat Linux 或者 Windows NT 並在預設的設定情況下執行現的。Honeynet 既沒有對企圖來標榜 Honeynet 也沒有企圖來 "引誘" 攻擊者。理論上來說這個站只會有很少的活動跡象，就想我們沒有廣告任何服務和系統。

Honeynet 數據有價值的地方是 Honeynet 減少了主動錯誤訊息(false positives) 和被動錯誤訊息(false negatives) 所產生的問題。主動錯誤訊息(false positives) 指的是當組織由於惡意活動而被通知警報時候，經檢查其實沒有任何事情發生，而當這個組織持續的被主動錯誤訊息(false positives) 所觸發警報，他們開始忽略他們的警報系統和數據採集，導致警告系統發生人為的失效。舉個例子，MAIL 入侵偵測系統警告管理員系統被攻擊，可能是一般已知的攻擊被偵測到，但是，這個警告可能是由一封包含對這個已知漏洞的警告並包含了攻擊者所需的 Souce Code 來通知管理員的郵件錯誤觸發的，或者可能是網路監視通訊程序 SNMP 或者 ICMP 錯誤觸發的。主動錯誤訊息(false positives) 對於大多數組織機構來說是是一項持續的挑戰。Honeynet 通過不包含任何實際的產品通訊所觸發的訊息來減少這個問題，即不安裝任何相關應用產品。因為 Honeynet 網路沒有實際用途，它只是為了捕獲未授權的活動，這表示任何訊息封包的進入和離開 Honeynet 都會被認為是有嫌疑的(因為沒有任何應用平台)，就簡化了數據捕獲和程序分析，減少主動錯誤訊息(false positives) 的產生.

被動錯誤訊息(false negatives) 是多數組織機構需要面對的另一項挑戰，被動錯誤訊息(false negatives) 就是對於真實的惡意攻擊者或者未授權活動偵測失敗。多數組織機構有適當的機制來檢測攻擊，如入侵偵測系統，防火牆日誌，系統日誌和程序記錄。這些工具的目的是為了偵測有可疑或者未授權活動，但是，其中有兩個重要的問題會導致產生被動錯誤訊息(false negatives) 偵測失敗：數據負載過重和新的漏洞，數據負載過重是當組織機構捕獲過多的數據，而沒有全部被查看，因此攻擊者被忽略過，如，多數組織機構記錄 G 等級的防火牆或者系統活動訊息，這樣對與重新複查這些成噸的訊息來鑑別可疑行為變的極其困難。第二個問題就是新型漏洞的攻擊，而造成安全軟體沒有能力來偵測這種個攻擊。Honeynet 通過絕對的捕獲所有進出 honeynet 的訊息來減少這種新型攻擊產生的漏捕。記住：Honeynet 裡只有很少或者沒有的相關應用平台和程序所產生的活動，這表示所有捕獲的相關訊息是有一定嫌疑的。即使我們漏捕最初始的攻擊，我們仍然截獲這個活動，如 Honeynet 中有 2 個系統在沒有任何警告給 Honeynet 管理員的情況下被入侵，我們沒有探測到這次攻擊知道被入侵的主機發起對外的連接，一旦這些嘗試被我們探測到，我們就檢查了所有捕獲的活動訊息來鑑定這個攻擊：它是怎樣成功的，為何我們漏捕了，通過這些研究，honeynet 減少了被動錯誤訊息(false negatives) 所產生的問題.

對於有價值的數據的複查可以很明顯的減少主動錯誤訊息(false positives) 和被動錯誤訊息(false negatives) 的產生。記住：下面我們所討論的發現是特定我們的網路，這不意味著你的組織機構中會看到同樣的模式或者行為，我們使用這個採集到的數據來演示部分 blackhat 的性質和早期警告和預測的可能性。

Analyzing the Past
當我們研究 blackhat 團體的時候，Honeynet 項目驚奇地看到 blackhat 團體是如此的活躍。我們的發現是令人驚慌的。下面是我們對十一個月來所收集數據的一些統計。公佈這些數據的目地是展示 blackhat 團體的頻繁活動。需要注意的是，這些統計訊息只代表了一個沒什麼價值的小家庭網路，它沒有對外廣而告之並且沒有試圖引誘駭客。那些有很高名氣和很大價值的大型組織機構極有可能被探測和攻擊的次數多得多。

攻擊後的分析：

• 從 2000 年 4 月到 11 月，7 台預設安裝的 Red Hat 6.2 服務器在它們被放上 Internet 的三天之內被攻擊。基於此，我們估計一個預設安裝的 Red Hat 6.2 服務器的預期生命少於 72 小時。當我們最後一次試圖證實這個估計的時候，系統在 8 小時內就被攻破。一個系統最快在 15 分鐘內就被入侵。這意味著系統在連上 Internet 的 15 分鐘內就被掃瞄，探測和入侵。碰巧的是，這是我們在 1999 年 3 月建立的第一個誘陷系統。
• 在 2000 年 10 月 31 日，我們放置了一個預設安裝的 Windows98 系統，就像許多家庭和組織那樣設定了共享。這個誘陷系統在 24 小時之內就被入侵。在接下來的三天中又被入侵了 4 次。就是說在少於 4 天內它被成功地入侵了 5 次。在 2000 年 5 月，我們有了第一個全月的 Snort 入侵警告訊息，Honeynet 項目記錄了 157 個 Snort 警告。在 2001 年 2 月，Honeynet 項目記錄了 1398 個 Snort 警告，表示了超過 890% 的增長。這些增長可能受到對 Snort 入侵檢測系統設定檔案修改的影響。然而，我們也從防火牆日誌中看到了活動的增加。在 2000 年 5 月我們有了第一個全月的防火牆的警告訊息，Honeynet 項目防火牆記錄了 103 個不同的掃瞄（不包括 NetBios）。在 2001 年 2 月，Honeynet 項目記錄了 206 個不同的掃瞄（不包括 NetBios）。這表示增加了 100% 。這些數字表示了 blackhat 活動的持續的增加，極有可能是因為更具攻擊性的自動掃瞄工具的出現和它們能更容易地被得到。
• 在 30 天內（2000 年 9/20-10/20），Honeynet 收到 524 個不同的 NetBios 的掃瞄，平均每天 17 個不同的掃瞄。
• 在 2001 年 2 月，一共對 Honeynet 有 27 次 X86 漏洞利用。X86 意思是這些攻擊被設計是對付 Intel 架構系統的。在這些攻擊中，有 8 次是對 Solaris Sparc 系統的進行的。因為系統架構不兼容，這些漏洞利用對 Sparc 系統是無效的。這暗示了一些攻擊者並不確認是什麼作業系統或在其上執行了什麼版本的服務。當他們發現了服務，他們甚至首先不確認系統是不是脆弱的，或者甚至是不是正確的系統類型。這種活動方式能使 blackhat 在更短的時間內掃瞄和攻擊更多的系統。
• 從 2000 年 4 月至今，除了通常的掃瞄外，最流行的探測方法是 DNS 版本查詢，接下來的就是 RPC 服務的查詢。
• 最流行的攻擊是對 Intel 架構系統的 rpc.statd 溢出攻擊。
• 最流行的掃瞄方法是對整個 IP 區段對特定通訊埠的 SYN-FIN 掃瞄（通常按先後順序）。這反映了聚焦於單個脆弱性的策略，針對這個脆弱性掃瞄到盡可能多的系統。許多 blackhat 只使用單個的工具，或只利用他們知道如何利用或最有效的漏洞。

Predicting the Future
Honeynet 項目想要研究的一個方向是對系統攻擊的前期預警，這樣也可以給 Honeynet 搜集更多有價值的數據帶來理論上的幫助。這些理論並不是非常新的，而且也有有些大公司在使用著，我們也希望我們的研究對這些公司及其它組織有所幫助。在詳細地解釋我們的方法之前，我想先聲明：我們的研究還處於初始階段，還有大量的數據分析工作需要進行。

OK，讓我們開始吧……

• 我現在討論的僅僅是一個獨立的Honeynet，僅是提供單節點的、數據量不大的觀察結果。下面所要提及的方法將會在世界各國更廣闊的環境、有眾多 Honeynet 的環境中測試。
• 我們並沒有試圖對由同一個攻擊者發起的攻擊作出識別，原因很簡單，因為現在欺騙技術使用太廣泛了。
• 我們的許多推測建立在一個攻擊者總是首先掃瞄然後攻擊服務器這個流程上。當然，有些情況下或許掃瞄與攻擊這兩個事件根本是偶然。但我們仍堅持上述的觀點。

我們努力對攻擊情況做出合理的預測，期間 Honeynet 的兩位成員提出了兩個不同的方法，但是最終發現他們的結果是大同小異的，幾乎所有的入侵者都在他們實施真正攻擊前的兩到三天被發現。

使用統計學原理對事件做預警[Statistical Process Controls(SPC)]:

首先是非常基礎的統計學分析，類似於工廠裡對生產情況進行統計對比。這種方法雖然看起來相當簡單，但卻能夠精確地判斷出短時期內(三天會更短)對 Honeynet 可能發生的攻擊情況，簡單的操作如下：

• 我們分析了從 2000 年 4 月到 2001 年 1 月的所有 snort 記錄。
• 對 snort 報告最多的 10 種攻擊，我們計算出每天每種攻擊會被重複多少次。
• 然後，我們計算出每種攻擊方式3天內的滑動平均模型，稱作 3DMA(three day moving average)，然後我們在圖上標出每種攻擊方式在每天及每三天內會被報告多少次。
• 我們計算出一個時期內的攻擊水平平均值。
• 在任何一個 3DMA 階段內，如果發現 2 倍於平均值的攻擊數量，或者持續高速增長，我們就可以認為這是一個危險訊號。

在這裡，我們並沒有區分入侵嘗試及成功攻擊，只是在圖表畫出來後，再標記上成功及企圖的攻擊，所有的數據可以在 Honeynet 的網站上獲取。下面是我們的一些發現：

1. Honeynet 在 2000 年 4/9 到 2000 年 9/30 期間記錄下了 8 次成功的攻擊事件，除了一件之外，其餘的都利用上面所描述的方法得到了準確的預測。

2. 在這段時間的試驗以及所有的攻擊中，多數的攻擊嘗試都是在 3DMA 超出了平均水平──也就是我們的控制點 2 倍，只有一次是 7 天之內，才發生真正的攻擊事件。下面是一些事例：
   • RPC: 我們從 2000 年 4 月 1 日 對 RPC 服務進行了觀察，總共用了 180 天時間，在第 61 至 68 天之間，發現圖表中的查詢次數有明顯上升趨勢，終於在第 68 天，一次利用 rpc.statd 的攻擊發生了。另一次是在第 153 到 170 天之間，有大量的請求 111 通訊埠的數據，而後就是在第 177 天時的一次對 rpc.statd 的成功溢位攻擊。下面是一個對這期間活動的模型圖表，X 座標是天，Y 座標是指發生次數。
     

   • DNS/named: 從第 81-85 天看起來不正常地活躍，有許多異樣的請求發送到 name server。在第 85 天，named 服務受到了一次不成功的攻擊。

第二種方法對於第一種方法是一個有益的補充，比如它可以顯示出在有人違反 snort 的 rpc 規則後，大概多長時間系統遭攻陷，明確兩者間的關聯。在一段連續的時間內，有些簡單的模型可以對違反 rpc 規則與系統真正被攻陷間做出清晰的關聯。

從下面的圖表模型中我們可以看出，利用 rpc.statd 進行攻擊的行為其實早幾天就能被發現。橫座標表示日期，在這裡是從 1-180 天，向下的曲線通常表明有一些重要的事件發生，這能夠預報一些攻擊行為，比如在第 68 天我們受到攻擊之前的 10 天內，就出現了這樣的行為，而在其後又有三次向下的曲線，緊接著就是一次同樣的 rpc 攻擊發生在第 177 天。這裡我也不太瞭解向上的曲線代表什麼，但通常處在這種情況下，是一個平穩時期，沒有太多的意外情況發生。

需要說明的是，在這些分析模型中肯定會存在一些錯誤，我們需要更多的數據，以及對這些分析預測模型更完善的利用方式，這樣才能夠有效地得出攻擊預警的一些思路。

利用 ARIMA 模型找出攻擊前的特徵

另一個研究的領域是識別出某些類型的攻擊或者掃瞄存在著的特徵，這兩個事例都來自於我們 Honeynet 小組成員的 "每月掃瞄" 中，下面的圖形描述了在一個月中我們遭受的通訊埠掃瞄的數量。這裡我們很樂於回答的另一個問題是對於不同的掃瞄及準備攻擊的行為： "在一段時期內的數據收集之後，我們想要觀察什麼呢？" 在這個簡單的 ARIMA(回歸滑動平均模型,Auto Regression Integrated with Moving Averages)案例中，是直接按捕獲的數據資料進行分析的，ARIMA 是一個可以用在對一定時期內搜集的數據進行深度分析的基本模型，下面的圖表表明了在九月份我們遭受的通訊埠掃瞄的頻繁程度。

• 我們需要獲取更多的，彼此相互關聯的數據來進行對比分析。
• 更多的變數參數值──增加一些不同類型的 snort 捕獲的數據，會有助於我們理解事件發生的流程。
• 不同的統計分析技術，比如事件歷史分析(Event History Analysis)

我們歡迎安全組織測試或者開發這樣的理論，並且將其應用於實際的統計分析上，對於不同的分析方法我們尤其感興趣。我們在這裡提供給大家的並不是最好的分析方法，事實上，一切研究都剛起步。從 2000 年 4 月起至 2001 年 2 月止 honeynet_data.tar.gz

結論
在這十一個月中，我們努力地捕獲所有的掃瞄、攻擊及利用我們機器的一些行為的訊息。這些訊息被我們以兩種方式分析。第一種方式說明了 blackhat 團隊的活躍性，要記住，Honeynet 是一個沒有關鍵訊息、並且不做任何宣傳的網路，如果你的網路裡有重要數據，或者你大做宣傳，那麼你可能會面臨更多的攻擊。第二種方法我們用來檢驗攻擊預警理論。我們認為利用它能夠對未來的攻擊行為作出預測。Honeynet 並不是僅有一種搜集訊息的手段，事實上，我們有許多方法來盡量減少主動訊息錯誤和被動訊息錯誤。充分利用了數據採集以及數據分析的方法，一個組織就能夠更好地對 blackhat 團隊的攻擊做出防護了。