第 18 週家庭作業讓我們去探索

第 18 週家庭作業讓我們去探索

Vandalay Industries 監控活動說明

第一步：追求速度

背景：作為全球進出口行業的領導者，Vandalay Industries 一直是許多試圖破壞其線上業務的對手的目標。最近，Vandaly 的網路伺服器遭受了 DDOS 攻擊。

不僅網頁伺服器因 DDOS 攻擊而離線，上傳和下載速度在中斷後也受到顯著影響。您的網路團隊提供了最近一次 DDOS 攻擊前後的網路速度結果。

任務：建立報告以確定 DDOS 攻擊對下載和上傳速度的影響。此外，建立一個附加欄位來計算上傳速度與下載速度的比率。

1. 上傳以下攻擊發生時系統速度的檔案。

速度測試文件

上傳到 Splunk 的「server_speedtest.csv」檔案的螢幕截圖：

2. 使用eval指令，建立一個名為ratio 的字段，用於顯示上傳和下載速度之間的比率。

提示：建立比率的格式為： | eval new_field_name = 'fieldA' / 'fieldB'

Splunk 中用於產生上傳和下載速度比率的查詢 - source="server_speedtest.csv" | eval ratio = DOWNLOAD_MEGABITS/UPLOAD_MEGABITS

我們可以從這個查詢看到下載和上傳的比率。

3. 使用 Splunk 的 table 指令建立報告，以在統計報告中顯示下列欄位：

• _time
• IP_ADDRESS
• DOWNLOAD_MEGABITS
• UPLOAD_MEGABITS
• ratio

提示：對於表格命令，請使用以下格式： |表字段A 字段B 字段C

Splunk 中用於產生上傳和下載速度比率的查詢 - source="server_speedtest.csv" | eval ratio = DOWNLOAD_MEGABITS/UPLOAD_MEGABITS | table _time, IP_ADDRESS, DOWNLOAD_MEGABITS, UPLOAD_MEGABITS, ratio

從上面的螢幕截圖中，我們可以看到下載和上傳發生的總事件時間軸。

從上面的螢幕截圖中，我們可以看到下載和上傳發生的時間以及執行此操作的來源 IP 位址。

從上面的螢幕截圖中，我們可以看到這些下載和上傳事件以長條圖格式的直觀表示。時間顯示在底部，這使我們的數據更具可讀性。

回答以下問題：

• 根據創建的報告，攻擊發生的大致日期和時間是多少？

根據我們在上述查詢中的發現，我們可以看到下載和上傳速度在 2 月 23 日下午 2:30 左右急劇下降。我們可以在下面的螢幕截圖中看到這一點：

我們可以看到下載量在下午 2:30 下降到 7.87。這與上一次事件的 109.16 兆位元相比大幅下降。可以公平地假設這就是攻擊開始的時間。

• 系統什麼時候開始恢復？

從上面的截圖我們可以看到，下載量從17.56增加到了65.34，這是一個急劇的增長。因此，可以安全地假設這是在系統開始恢復並恢復正常網路流量時發生的。

• 網路流量什麼時候看起來正常？

從上面的截圖中我們可以看到，2 月 23 日晚上 11:30 左右，下載量從 78.34 躍升至 123.91。

提交您的報告的螢幕截圖以及上述問題的答案。

第二步：我們容易受到傷害嗎？

背景：由於攻擊頻繁，您的經理需要確保其伺服器上的敏感客戶資料不易受到攻擊。由於 Vandalay 使用 Nessus 漏洞掃描器，因此您已提取過去 24 小時的掃描以查看是否有任何嚴重漏洞。

有關 Nessus 的更多信息，請閱讀以下連結：https://www.tenable.com/products/nessus

任務：建立一份報告，確定客戶資料伺服器上存在多少個嚴重漏洞。然後，如果該伺服器上再次出現嚴重漏洞，請建立警報以通知您的團隊。

1. 從 Nessus 漏洞掃描上傳下列檔案。

Nessus 掃描結果

上傳到 Splunk 的 nessus 掃描結果的螢幕截圖：

2. 建立一個報告，顯示客戶資料庫伺服器中嚴重漏洞的計數。

• 資料庫伺服器 IP 為10.11.36.23 。

在查詢中使用dest_ip="10.11.36.23"

• 識別漏洞等級的欄位是嚴重性。

值得注意的是，這些日誌會找出 5 種嚴重級別，如下所示：

我們希望過濾出任何嚴重性等級為「關鍵」值的漏洞。我們可以在查詢中使用severity="crtiical" 。

整個查詢是source="nessus_logs.csv" dest_ip="10.11.36.23" severity="critical"

請參閱下面的螢幕截圖，了解整個查詢，該查詢顯示來自此日誌檔案的客戶資料庫伺服器的嚴重漏洞計數：

當目標IP為10.11.36.23（資料庫伺服器）時，共發現49個嚴重漏洞。

3. 建立一個警報，每天監控該伺服器是否有任何嚴重漏洞。如果存在漏洞，請將警報透過電子郵件發送至[email protected] 。

在我們從上面的查詢產生結果後，按一下“另存為”，然後按一下“警報”以建立警報：

輸入詳細資訊以在 Nessus 偵測到資料庫伺服器上的漏洞時產生警報。輸入名稱、描述和任何其他相關資訊：

輸入電子郵件詳細資訊以將產生的警報發送至 - [email protected] ，然後輸入要與電子郵件一起發送的訊息詳細資訊：

繼續輸入警報的詳細信息，然後按一下「儲存」：

保存後，我們應該能夠看到警報並根據需要進行編輯：

提交報告的螢幕截圖以及警報已建立的證據螢幕截圖。

第 3 步：繪製（基線）線

背景：Vandalay 伺服器的管理員帳戶也遭受暴力攻擊。管理層希望您設定監控，以便在暴力攻擊再次發生時通知 SOC 團隊。

任務：分析記錄暴力攻擊的管理員日誌。然後，建立管理員錯誤登入正常數量的基線，並確定閾值以指示是否發生暴力攻擊。

1. 上傳管理員登入日誌。

管理員登入

上傳到 Splunk 的「Administrator_logs.csv」檔案的螢幕截圖：

2. 暴力攻擊發生在什麼時候？

提示：

• 尋找名稱欄位以尋找失敗的登入。

• 請注意，攻擊持續了幾個小時。

因為我們想要尋找暴力攻擊的任何跡象，所以我們想要深入了解帳戶無法登入的日誌。如果我們導航到“名稱”字段，我們可以看到日誌中保存的值。在本例中，我們可以看到「帳戶無法登入」的計數為 1004。這是發生暴力攻擊的良好指標。看截圖：

現在，如果我們將其添加到搜尋中，我們可以看到發生此情況時的總事件。然後我們可以看到大多數事件發生的時間，這是判斷事件發生時間的一個很好的指標。看截圖：

可以看到，2月21日上午9點左右「帳戶登入失敗」事件出現了相當大的高峰。我們可以看到總共發生了 1004 起事件，其中 124 起事件在上午 9 點發生，並且在隨後的幾個小時內出現了類似的數字。因此，我相信攻擊是在這個時間（2020 年 2 月 21 日上午 9:00）左右開始的。

3. 確定正常活動的基線和發生暴力攻擊時發出警報的門檻。

從這些事件的時間線我們可以看出，124 是一個相當大的高峰。在此事件發生之前的幾個小時內，最多的錯誤登入次數約為 23 次。看截圖：

考慮到這一點，並考慮到暴力攻擊發生時大約有 124-135 次登入嘗試，我會考慮每小時大約 40 次不良登入的基線。我每小時的不良登入範圍如下：

• 0-25 是正常行為
• 25-50值得研究
• 50+ 被認為是關鍵事件，應盡快調查事件。

4. 設計一個警報以每小時檢查閾值，並在觸發時向 SOC 團隊發送電子郵件至[email protected] 。

要為此類事件建立警報，我執行了以下步驟：

按一下“另存為”，然後按一下“警報”：

填寫警報的詳細信息，包括何時觸發警報（每小時嘗試超過 25 次）：

輸入操作的詳細資訊。在這種情況下，我們將發送電子郵件至[email protected] ：

儲存警報，然後我們可以查看它：

我們現在已經成功建立了一個警報，當帳戶登入失敗的事件超過 25 個時，該警報就會觸發。

提交有關暴力破解時間、基線和閾值問題的答案。此外，請提供螢幕截圖作為已建立警報的證據。