本頁面由 Cloud Translation API 翻譯而成。

收集 Aruba 無線控制器和存取點記錄

支援以下發布途徑：

Google secops Siem

本文說明如何使用 Bindplane 收集 Aruba Wireless Controller 和存取點記錄。剖析器會處理 SYSLOG 訊息，擷取與觀察者、中介服務和存取點詳細資料相關的欄位。接著，系統會將這些欄位對應至整合式資料模型 (UDM)，藉此強化事件資料的安全性結果嚴重性，並在處理過程中處理各種錯誤狀況。

事前準備

確認您有 Google Security Operations 執行個體。
請確認您使用的是 Windows 2016 或更新版本，或是支援 systemd 的 Linux 主機。
如果在 Proxy 後方執行，請確認防火牆通訊埠已開啟。
確認您具備 Aruba Wireless Controller 的特殊存取權。

取得 Google SecOps 擷取驗證檔案

登入 Google SecOps 控制台。
依序前往「SIEM 設定」>「收集代理程式」。
下載擷取驗證檔案。請在將要安裝 Bindplane 的系統上，安全地儲存檔案。

取得 Google SecOps 客戶 ID

登入 Google SecOps 控制台。
依序前往「SIEM 設定」>「設定檔」。
複製並儲存「機構詳細資料」部分中的客戶 ID。

安裝 Bindplane 代理程式

Windows 安裝

以系統管理員身分開啟命令提示字元或 PowerShell。

執行下列指令：

msiexec /i "https://github.com/observIQ/bindplane-agent/releases/latest/download/observiq-otel-collector.msi" /quiet

Linux 安裝

開啟具有 root 或 sudo 權限的終端機。

執行下列指令：

sudo sh -c "$(curl -fsSlL https://github.com/observiq/bindplane-agent/releases/latest/download/install_unix.sh)" install_unix.sh

其他安裝資源

如需其他安裝選項，請參閱這份安裝指南。

設定 Bindplane 代理程式，以便擷取系統記錄檔並傳送至 Google SecOps

存取設定檔：
1. 找出 config.yaml 檔案。通常位於 Linux 的 /etc/bindplane-agent/ 目錄或 Windows 的安裝目錄。
2. 使用文字編輯器 (例如 nano、vi 或記事本) 開啟檔案。

按照下列方式編輯 config.yaml 檔案：

receivers:
    udplog:
        # Replace the port and IP address as required
        listen_address: "0.0.0.0:514"

exporters:
    chronicle/chronicle_w_labels:
        compression: gzip
        # Adjust the path to the credentials file you downloaded in Step 1
        creds: '/path/to/ingestion-authentication-file.json'
        # Replace with your actual customer ID from Step 2
        customer_id: <customer_id>
        endpoint: malachiteingestion-pa.googleapis.com
        # Add optional ingestion labels for better organization
        ingestion_labels:
            log_type: ARUBA_WIRELESS
            raw_log_field: body

service:
    pipelines:
        logs/source0__chronicle_w_labels-0:
            receivers:
                - udplog
            exporters:
                - chronicle/chronicle_w_labels

視基礎架構需求替換通訊埠和 IP 位址。
將 <customer_id> 替換為實際的客戶 ID。
在「取得 Google SecOps 攝入驗證檔案」部分，將 /path/to/ingestion-authentication-file.json 更新為驗證檔案的儲存路徑。

重新啟動 Bindplane 代理程式以套用變更

如要在 Linux 中重新啟動 Bindplane 代理程式，請執行下列指令：
```
sudo systemctl restart bindplane-agent
```
如要在 Windows 中重新啟動 Bindplane 代理程式，您可以使用「Services」主控台，或輸入下列指令：
```
net stop BindPlaneAgent && net start BindPlaneAgent
```

設定 Aruba 無線控制器和存取點

登入 Aruba 控制器網頁版使用者介面。
前往頂端選單，然後依序選取「設定」>「系統」。
選取「Logging」，開啟記錄設定頁面。
在「Syslog 伺服器」專區中，按一下「+ 新增」，新增 syslog 伺服器。
系統會顯示新的表單，請輸入下列詳細資料：
- 名稱：輸入系統記錄檔伺服器的專屬名稱，例如 Google SecOps Syslog。
- IP 位址：輸入 Bindplane IP 位址。
- Port：輸入 Bindplane 通訊埠編號 (通常為 UDP 的 514)。
- 記錄設施：從選單中選取「local 6」 (這通常用於網路裝置)。
- 記錄層級：選取「資訊」，即可擷取資訊記錄。
- 格式：選取 bsd-standard 格式 (這是 Aruba 控制器使用的預設 syslog 格式)。
按一下「提交」即可儲存設定。
按一下「待處理變更」。
按一下「Deploy Changes」，套用新的 syslog 伺服器設定。

注意： 部署變更後，您必須為特定類別的記錄設定記錄層級。
前往「記錄層級」設定，並將「記錄層級」設為下列各類別的「資訊」：
- 網路
- 全部
- 叢集
- DHCP
- GP
- 機動性
- 封包傾倒
- SDN

UDM 對應表

記錄欄位	UDM 對應	邏輯
`Additional Info`	`read_only_udm.security_result.description`	原始記錄檔中的 `Additional Info` 值會對應至 UDM 欄位 `security_result.description`。
`AP`	`read_only_udm.target.hostname`	如果原始記錄中出現 `AP:` 後面的值，系統會擷取該值並對應至 UDM 欄位 `target.hostname`。
`BSSID`	`read_only_udm.target.mac`、`read_only_udm.principal.resource.name` (資源類型為 BSSID 時)	原始記錄檔中的 BSSID 值會對應至 `target.mac`。當 `principal.resource.type` 為 `BSSID` 時，系統也會將其用做資源名稱。
`COMMAND`	`read_only_udm.principal.process.command_line`	原始記錄檔中的指令值會對應至 UDM 欄位 `principal.process.command_line`。
`Dst-MAC`	`read_only_udm.target.mac`	如果有，則原始記錄檔中的 Dst-MAC 值會對應至 UDM 欄位 `target.mac`。
`SERVER`	`read_only_udm.target.hostname`	如果有此欄位，原始記錄中的伺服器名稱會對應至 UDM 欄位 `target.hostname`。
`SERVER-IP`	`read_only_udm.target.ip`	如果存在，原始記錄中的伺服器 IP 會對應至 UDM 欄位 `target.ip`。
`Src-MAC`	`read_only_udm.principal.mac`	如果有，原始記錄檔中的 Src-MAC 值會對應至 UDM 欄位 `principal.mac`。
`SSID`	`read_only_udm.target.resource.name` (當資源類型為 SSID 時)	當 `target.resource.type` 為 `SSID` 時，系統會使用原始記錄中的 SSID 值做為資源名稱。
`USER`	`read_only_udm.target.user.userid`	如果有此欄位，原始記錄中的使用者 ID 會對應至 UDM 欄位 `target.user.userid`。
`USERIP`	`read_only_udm.principal.ip`、`read_only_udm.observer.ip`	如果有此欄位，系統會將原始記錄檔中的使用者 IP 對應至 UDM 欄位 `principal.ip` 和 `observer.ip`。
`USERMAC`	`read_only_udm.principal.mac`	如果有此欄位，原始記錄中的使用者 MAC 會對應至 UDM 欄位 `principal.mac`。
`USERNAME`	`read_only_udm.principal.user.userid`	如果存在，原始記錄中的使用者名稱會對應至 UDM 欄位 `principal.user.userid`。
`action`	`read_only_udm.security_result.action`	原始記錄中的動作值 (例如`permit`、`deny`) 會對應至 UDM 欄位 `security_result.action`。
`apname`	`read_only_udm.target.hostname`	在這種情況下，原始記錄中的 AP 名稱會對應至 UDM 欄位 `target.hostname`。
`bssid`	`read_only_udm.target.mac`	如果有，原始記錄檔中的 BSSID 值會對應至 UDM 欄位 `target.mac`。
`collection_time.seconds`	`read_only_udm.metadata.event_timestamp.seconds`	原始記錄檔中收集時間的秒數值會對應至 UDM 欄位 `metadata.event_timestamp.seconds`。
`device_ip`	`read_only_udm.intermediary.ip`	原始記錄或 `logstash` 中的裝置 IP 會對應至 UDM 欄位 `intermediary.ip`。
`dstip`	`read_only_udm.target.ip`	如果存在，原始記錄中的目的地 IP 會對應至 UDM 欄位 `target.ip`。
`dstport`	`read_only_udm.target.port`	如果存在，原始記錄中的目的地連接埠會對應至 UDM 欄位 `target.port`。
`event_id`	`read_only_udm.metadata.product_event_type`	原始記錄中的事件 ID 會用於建構 UDM 中的 `metadata.product_event_type` 欄位，前置 `Event ID:`。
`event_message`	`read_only_udm.security_result.summary`	原始記錄中的事件訊息會對應至 UDM 欄位 `security_result.summary`。
`log.source.address`	`read_only_udm.observer.ip`	記錄來源位址會對應至 UDM 欄位 `observer.ip`。
`log_type`	`read_only_udm.metadata.log_type`	原始記錄中的記錄類型會對應至 UDM 欄位 `metadata.log_type`。
`logstash.collect.host`	`read_only_udm.observer.ip`或`read_only_udm.observer.hostname`	如果是 IP 位址，Logstash 收集主機會對應至 `observer.ip`；如果是主機名稱，則會對應至 `observer.hostname`。
`logstash.ingest.host`	`read_only_udm.intermediary.hostname`	Logstash 擷取主機會對應至 UDM 欄位 `intermediary.hostname`。
`logstash.process.host`	`read_only_udm.intermediary.hostname`	Logstash 程序主機會對應至 UDM 欄位 `intermediary.hostname`。
`program`	`read_only_udm.target.application`	原始記錄中的節目名稱會對應至 UDM 欄位 `target.application`。
`serverip`	`read_only_udm.target.ip`	如果存在，原始記錄中的伺服器 IP 會對應至 UDM 欄位 `target.ip`。
`servername`	`read_only_udm.target.hostname`	如果有此欄位，原始記錄中的伺服器名稱會對應至 UDM 欄位 `target.hostname`。
`srcip`	`read_only_udm.principal.ip`	如果存在，原始記錄中的來源 IP 會對應至 UDM 欄位 `principal.ip`。
`srcport`	`read_only_udm.principal.port`	如果存在，原始記錄中的來源連接埠會對應至 UDM 欄位 `principal.port`。
`syslog_host`	`read_only_udm.intermediary.hostname`	原始記錄檔中的 syslog 主機會對應至 UDM 欄位 `intermediary.hostname`。
`timestamp`	`read_only_udm.metadata.event_timestamp`	系統會剖析原始記錄中的時間戳記，並對應至 UDM 欄位 `metadata.event_timestamp`。
`userip`	`read_only_udm.principal.ip`、`read_only_udm.observer.ip`	如果有此欄位，系統會將原始記錄檔中的使用者 IP 對應至 UDM 欄位 `principal.ip` 和 `observer.ip`。
`usermac`	`read_only_udm.principal.mac`	如果有此欄位，原始記錄中的使用者 MAC 會對應至 UDM 欄位 `principal.mac`。
`username`	`read_only_udm.principal.user.userid`	如果存在，原始記錄中的使用者名稱會對應至 UDM 欄位 `principal.user.userid`。取自剖析器中的 `event_id` 和邏輯。解析器會根據事件 ID 和記錄訊息內容決定。已硬式編碼至 `Wireless`。已硬式編碼至 `Aruba`。解析器會根據事件 ID 和記錄訊息內容決定。解析器會根據事件 ID 和記錄訊息內容決定。使用規則運算式從原始記錄訊息中擷取。解析器會根據事件 ID 和記錄訊息內容決定。如果 event_type 為 USER_LOGIN 或相關的驗證事件，系統會新增空白物件。由剖析器根據事件中使用的網路通訊協定 (例如 TCP、UDP、ICMP、IGMP)。包含根據特定條件從原始記錄中擷取的其他欄位。舉例來說，如果有 `ap_name`，系統就會將其新增為鍵/值組合。主體內容中出現 BSSID 時，請將其設為 `BSSID`。如果目標內容中出現 SSID，請將其設為 `SSID`。包含從原始記錄中擷取的相關偵測資訊的鍵/值組合，例如 BSSID 或 SSID。

異動

2024-12-27

改善項目：

新增 Grok 模式，以支援新的 syslog 記錄模式。

2024-09-04

改善項目：

新增支援 SYSLOG 日誌的新模式。

2024-08-26

改善項目：

新增支援功能，用於處理未剖析的 SYSLOG 記錄。
已將 details 對應至 metadata.description。

2024-06-18

改善項目：

新增支援功能，用於處理未剖析的 SYSLOG 記錄。

2024-04-18

改善項目：

新增 Grok 模式，從 ap_name 擷取有效值。
已將 ap_name 對應至 additional.fields。

2023-05-25

修正錯誤：

由於記錄模式不同，因此無法剖析記錄。

2022-09-15

修正錯誤：

修改 grok 模式，以便剖析記錄檔，這些記錄檔可能在記錄時間戳記中包含日期欄位，且某些記錄檔可能在記錄中不含 userip 索引鍵。
盡可能將 metadata.event_type 從 GENERIC_EVENT 變更為 STATUS_UPDATE。

2022-08-23

改善項目：

將客戶專屬剖析器遷移至預設剖析器。
已將「metadata.event_type」的對應項目從「GENERIC_EVENT」修改為「USER_RESOURCE_ACCESS」，其中 event_id 為「132053」。

2022-03-30

改善項目：

新增下列事件 ID：124003、126037、126038、199801、235008、235009、304119、306602、326091、326098、326271、326272、326273、326274、326275、326276、326277、326278、326284、341004、350008、351008、358000、393000、399815、520013、522274、541004
變更 metadata.event_type，其中 Event Id 為 126034、126064、127064、132006、132030、132093、132094、132197，從 GENERIC_EVENT 變更為 SCAN_UNCATEGORIZED
metadata.event_type (Event Id 為 132207) 已從 GENERIC_EVENT 變更為 NETWORK_CONNECTION
metadata.event_type (Event Id 為 520002) 已從 GENERIC_EVENT 變更為 USER_UNCATEGORIZED
已對應 intermediary.hostname、intermediary.mac、intermediary.ip、target.application、target.process.pid
將 logstash.irm_site、logstash.irm_environment、logstash.irm_region 對應至 additional.fields

還有其他問題嗎？向社群成員和 Google SecOps 專家尋求解答。