淺析紅藍對抗中攻擊方基礎設施的日誌聚合和監控

在紅藍對抗中，已經證明，監控我們用於攻擊所使用的基礎設施與我們所實施的攻擊一樣重要。在防禦方開始調查時快速隱藏攻擊方意味著可以保持我們的互動式命令和控制（C2）會話與銷毀我們的基礎設施之間的差異。如果你已經閱讀過史蒂夫和我寫的紅隊基礎設施Wiki文檔，那麼你就知道我們是熱衷於使用大量分散式基礎架構的忠實粉絲，並且在任何方面我們都會使用到重定向器。當我們擁有包含基礎設施的資產多於20個時，監控就變得越來越困難。幸運的是，這個問題在很久以前就可以用rsyslog解決了。在這篇文章中，我們將介紹如何使用rsyslog監視分散式的攻擊基礎架構，來幫助我們實現更快的反應動作。

設計方案

Rsyslog遵循伺服器/客戶端架構。我們將配置專用的主機作為rsyslog伺服器，接收日誌信息並解析日誌獲取有意義的事件。我們的團隊伺服器和Web伺服器將充當客戶端並將其日誌轉發到日誌伺服器。

可以將Rsyslog配置為從許多不同的程序轉發日誌。實質上，如果工具能夠輸出有規律的格式化日誌，則可以通過rsyslog將數據記錄到中央伺服器。在這篇文章中，我們將專註於使用Apache日誌來說明這個概念。

這是攻防實驗室的設置：

實驗室設置

TLS設計注意事項

默認情況下，rsyslog是以明文協議傳輸的; 但是，它也支持SSL / TLS加密。使用TLS配置本文所描述的監控設置需要執行其他步驟，包括需要在轉發日誌的每個主機上生成計算機證書。你實際操作的設置步驟可能需要增加一些複雜性，也可能不需要。

以下是需要考慮的幾個因素：

·傳輸的數據有多敏感？只是web流量嗎？

·關於目標的任何元數據都不應泄露？

·資產的生命周期如何？每次基礎架構發布時，重新配置TLS可能是一項重大工作。

·你能編寫部署腳本嗎？

·如果日誌記錄伺服器被黑客發現，你是否預料到這些攻擊者可能會嘗試發送虛假的日誌內容？

有關使用TLS設置rsyslog的更多信息，請查看官方文檔。

使用Syslog聚合日誌

對於rsyslog的設置說明，Gary Rogers 的GitHub中有詳細的介紹。本文中提供的步驟也是基於Gary的博文內容，但要滿足我們的需求需要做一些修改。每個主機都需要設置; 日誌伺服器接收日誌並且客戶端（即我們的有效載荷伺服器和Cobalt Strike團隊伺服器）將日誌發送到日誌記錄伺服器。在實際的操作設置中，日誌記錄伺服器應獨立於任何攻擊基礎架構，並且應充分加強防護以防止日誌被篡改。

日誌記錄伺服器設置

任何安裝了rsyslog的*nix主機都可以使用此設置，但是本文的演示中，我們使用的是Debian 9主機。

默認情況下，rsyslog通過UDP發送消息。為了降低日誌消息在傳輸過程中丟失的可能性，我們將在我們的設置中使用TCP來作為傳輸協議。這需要在埠514上啟用TCP，並將下面這行內容添加到/etc/rsyslog.conf文件中：

$ModLoad imtcp$InputTCPServerRun 514

接下來，我們需要設置在本地主機上採集訪問和錯誤日誌。將下面這行添加到同一個文件的底部：

local3.* /var/log/apache2/combined_error.log

local4.* /var/log/apache2/combined_access.log

重新啟動服務讓應用更改生效：

service rsyslog restart

創建文件/var/log/apache2/combined_access.log和/var/log/apache2/combined_error.log。確保rsyslog可以寫入文件。

日誌記錄客戶端安裝程序

在配置主機時，需要設置每個客戶端。重定向器和有效載荷伺服器的設置步驟與Cobalt Strike團隊伺服器的步驟略有不同。

有效載荷日誌記錄客戶端

創建/etc/rsyslog.d/apache.conf文件並插入以下文本：

# Default Apache Error Log

$InputFileName /var/log/apache2/error.log

$InputFileTag apache-error-default:

$InputFileStateFile stat-apache-error

$InputFileSeverity info

$InputFileFacility local3

$InputRunFileMonitor

# Default Apache Access Log

$InputFileName /var/log/apache2/access.log

$InputFileTag apache-access-default:

$InputFileStateFile stat-apache-access

$InputFileSeverity info

$InputFileFacility local4

$InputRunFileMonitor

$InputFilePollInterval 1

如果你使用的不是基於Debian的發行版系統，則第4行和第12行會有所不同。這兩行應該分別指向Apache錯誤和訪問日誌。

修改/etc/rsyslog.conf文件，並將以下文本添加到文件的底部：

$WorkDirectory /var/lib/rsyslog # where to place spool files

$ActionQueueFileName fwdRule1 # unique name prefix for spool files

$ActionQueueMaxDiskSpace 1g # 1gb space limit (use as much as possible)

$ActionQueueSaveOnShutdown on # save messages to disk on shutdown

$ActionQueueType LinkedList # run asynchronously

$ActionResumeRetryCount -1 # infinite retries if host is down

local3.* @@192.168.10.11 #replace with rsyslog server

local4.* @@192.168.10.11 #replace with rsyslog server

將最後兩行的IP地址修改為你的rsyslog伺服器的IP。

重啟服務：

service rsyslog restart

Cobalt Strike團隊伺服器日誌記錄客戶端

要將Cobalt Strike團隊伺服器的weblog活動日誌發送到我們的rsyslog伺服器，我們需要使用Aggressor這個腳本將weblog中命中的數據大致格式化為與Apache默認日誌格式相匹配的日誌文件。使用agscript在你的團隊伺服器上執行此腳本：

./agscript syslog-monitor /path/to/apache-style-weblog-output.cna

創建/etc/rsyslog.d/cobalt.conf文件並插入以下文本：

# Default Cobalt Web Log

$InputFileName /var/log/cobaltstrike/weblog.log

$InputFileTag cobalt-strike-weblog-default:

$InputFileStateFile stat-apache-access

$InputFileSeverity info

$InputFileFacility local4

$InputRunFileMonitor

$InputFilePollInterval 1

修改/etc/rsyslog.conf文件，並將以下文本添加到文件的底部：

$WorkDirectory /var/lib/rsyslog # where to place spool files

$ActionQueueFileName fwdRule1 # unique name prefix for spool files

$ActionQueueMaxDiskSpace 1g # 1gb space limit (use as much as possible)

$ActionQueueSaveOnShutdown on # save messages to disk on shutdown

$ActionQueueType LinkedList # run asynchronously

$ActionResumeRetryCount -1 # infinite retries if host is down

local4.* @@192.168.10.11 #replace with rsyslog server

將第4行的日誌路徑修改為你的團隊伺服器上的weblog.log路徑，並將最後一行的IP地址修改為你的rsyslog伺服器的IP。

重啟服務：

service rsyslog restart

演示

下面是配置的組合訪問日誌的演示：

日誌記錄示例

請注意，Apache日誌記錄的默認日誌格式為：

[時間戳] [客戶端主機名] [InputFileTag]：[Apache請求數據]

日誌解析和監控

現在我們有數據流入了我們的rsyslog伺服器，我們需要一種簡單的方法從日誌中提取有意義的事件數據。我們可以而且確實應該在攻擊運行時審查原始日誌，但我們沒有理由忽視一些重要的事件。

在業內已經有很多種方法可以針對日誌設置有效的告警。出於本文的目的，我們會演示如何設置Apache將我們的有效載荷託管日誌發送到Papertrail，以便我們可以留意到防禦方的探測行為。

Papertrail設置

一旦我們成功運行提供的安裝腳本，我們的日誌就會開始與Papertrail進行同步，我們會收到一條「Logs received from: our host」的提示。

通過日誌同步，我們可以導航到Papertrail中的「事件」選項卡。在這裡，我們將找到rsyslog轉發到Papertrail實例的所有信息。屏幕底部有一個易於使用的搜索欄，我們可以在其中查詢所有或特定的日誌記錄伺服器。

值得注意的是，Papertrail會保留近兩天的日誌，然後將其歸檔。遺憾的是，歸檔日誌無法在Papertrail中搜索到。但是，Papertrail通過允許我們根據你的查詢設置警報來彌補這一點！Papertrail支持許多警報平台，如SMS，Slack，HipChat等。更多細節可以在這裡找到。

讓我們來看看針對我們的有效載荷的任何命中規則的示例告警。

首先，在搜索欄中執行搜索。搜索完成後，選擇「保存搜索」。我們將在下面的窗口中看到提示。

為搜索輸入一個吸引人的標題，然後選擇「保存並設置告警」按鈕。然後會跳轉到一個選擇告警平台的頁面。

告警平台選擇

對於這個設置，我們這裡使用Slack，因為Slack非常棒。單擊「Slack」圖標，系統會提示我們輸入Slack WebHook URI。輸入URI後，選擇你的時間間隔，然後選擇「保存」。就是這樣！我們完成了配置。一旦我們的警報觸發，我們將在Slack通道中收到提示，如下圖所示：

正如我們所看到的，當防禦方的請求命中我們的有效載荷URI時，我們每分鐘都會收到告警。雖然使用rsyslog和Papertrail，我們可以做的不止有效載荷命中檢測這件事情。我們可以利用我們的想像來告警埠探測，SSH登錄嘗試，電子郵件日誌等事情。我們可以使用rsyslog做很多事情，然後導入到Papertrail並設置告警。

總結

在本文中，我們介紹了如何使用rsyslog設置日誌聚合以及如何創建有意義的告警來檢測攻擊基礎架構的高價值操作。Rsyslog提供了一種簡單的機制，可以將日誌轉發到集中式伺服器或第三方日誌聚合服務，如Papertrail。在整個評估過程中積極監控整個分散式的紅隊攻擊基礎架構，使我們能夠更快的做出響應，並在開始銷毀基礎架構元素時更改攻擊策略。

註：這篇文章由Steve Borosh（@ 424f424f）和Jeff Dimmock（@bluscreenofjeff）共同撰寫。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！