使用本地 LLM 建置自動化基礎架構日誌分析系統 #
AI 每 15 分鐘自動分析防火牆、驗證基礎架構、交換器、負載平衡器與網頁伺服器的日誌，偵測異常、判斷嚴重程度並提出處理建議——全部透過 Slack 通知完成。日誌資料絕不會外流至環境之外。
建置動機 #
動機非常單純：我們沒有時間逐一檢視日誌。
BESTNET-CLOUD 運行著多台防火牆、L2/L3 交換器、Windows AD、負載平衡器與網頁伺服器。每一台都會輸出 syslog，但要人工每天逐一檢視所有日誌並不現實。我們使用 Zabbix 進行資源監控，但要判讀 syslog 內容、決定某個攻擊模式該忽略還是該處理，這件事仍然仰賴人力。
像是 AWS DevOps Agent（2026 年 3 月正式發布）與 Azure Security Copilot 這類服務，目前在公有雲端已提供 AI 驅動的日誌分析功能。然而，這些服務主要針對雲端資源，缺乏直接解析並分析地端實體設備 syslog 的功能。此外，由於日誌資料會被傳送至雲端供應商的 AI 基礎架構，這些方案無法用於封閉網路環境。
於是只剩下自行建置一途。所幸本地 LLM 的效能已達到實用等級，所需的所有元件也都可透過開源方式取得。
系統架構 #
本系統名為 BASTION——意指堡壘或最後據點，體現了在封閉網路環境中保護基礎架構的願景。
架構本身相當單純。
使用的元件如下——皆為開源或免費方案：
| 元件 | 角色 | 授權 |
|---|---|---|
| rsyslog | 集中接收所有設備的 syslog，並依主機分別儲存 | OSS（GPL） |
| Shell script 套件 | 各設備日誌的彙整、解析與前處理 | 自主開發 |
| OpenClaw | AI 代理框架（LLM 整合、Slack 整合、命令執行） | OSS |
| Qwen2.5-14B | 本地 LLM（日文日誌分析、異常偵測） | OSS（Apache 2.0） |
| GPUStack | GPU 推論伺服器（提供 OpenAI 相容 API） | OSS |
| Slack（Socket Mode） | 通知與雙向互動 | 免費方案 |
資料流程詳解 #
1. 日誌收集（rsyslog） #
各設備透過 UDP/TCP 514 埠傳送 syslog，並依主機名稱、年、月及程式名稱分類儲存於目錄中。
/var/log/remote/ fw-primary/2026/04/filterlog.log ad-server/2026/04/Security-Auditing.log lb-server/2026/04/loadbalancer.log ...
2. 日誌彙整（summarize.sh） #
cron 每 15 分鐘執行一次 summarize.sh，針對每台設備擷取過去 30 分鐘內的事件，並產生結構化的文字摘要。
由於每台設備的日誌格式完全不同，解析邏輯需針對每台設備分別撰寫。例如，防火牆 filterlog 採用逗號分隔欄位，來源 IP 位於第 19 欄、目的埠位於第 22 欄。Windows AD 日誌則包含二進位資料，需使用 grep -a。這些內嵌於腳本中的設備專屬知識，正是本系統的核心工作所在。
3. AI 分析（analyze.sh） #
摘要文字透過 OpenClaw 交由本地 LLM（Qwen2.5-14B）處理。提示詞會指示：「判斷嚴重程度，並以 JSON 格式回傳偵測到的異常與建議處理方式」。
此處有兩項關鍵設計決策。
對話隔離：每次分析都會產生一個動態的 session ID，避免過去的對話記錄污染上下文。LLM 容易受先前結果影響而導致判斷偏移，因此我們確保每次分析都是全新的上下文。
誤判控制：正常運作模式（如 Nextcloud LDAP 定期驗證、Kerberos 自動驗證、防火牆封鎖外部掃描等）會定義於系統提示詞中，為 LLM 提供排除條件以將這些視為雜訊。我們會在營運過程中持續增補模式。
4. 通知（notify.sh） #
LLM 分析結果會依嚴重程度以顏色區分後傳送至 Slack（critical=紅色、high=橘色、medium=黃色、low=綠色）。
對於 medium 以上等級，系統會自動傳送第二則詳細分析訊息，其中包含原始日誌前 50 行，讓維運人員僅憑通知內容即可同時確認「發生了什麼事」與原始資料。
5. 互動式分析（Slack 雙向互動） #
除了排程分析外，只要在 Slack 中提及 @OpenClaw-Monitor firewall analysis，即可立即針對指定設備進行詳細分析。也支援自然語言查詢，例如「是否有 VPN 驗證的可疑跡象？」或「確認是否有單一 IP 嘗試多種攻擊手法」。
由於 OpenClaw 可執行 bash 命令，未來擴展為自動處理——例如動態新增防火牆規則、隔離服務等——是可行的。
GPU 需求 #
資源消耗意外地相當精簡。
| 項目 | 消耗量 |
|---|---|
| 模型（Qwen2.5-14B Q4 量化） | 約 9GB |
| KV 快取（16K tokens） | 約 1–2GB |
| 合計 | 約 10–11GB |
支援的設備 #
| 設備類型 | 分析內容 |
|---|---|
| 防火牆 | 攻擊封鎖次數、攻擊來源 IP、埠分佈、VPN 錯誤 |
| 驗證（AD） | 登入成功/失敗/鎖定、失敗來源 IP、失敗帳號 |
| 負載平衡器 | 各後端的 5xx 錯誤率 |
| L2/L3 交換器 | 連線中斷、迴路、風暴偵測 |
| 網頁伺服器 | HTTP 狀態分佈、敏感 URL、4xx/5xx 來源 IP |
任何會輸出 syslog 的設備，只要新增解析腳本即可納入監控範圍。FortiGate、Cisco、Palo Alto 等設備皆可以相同方式支援。
營運心得 #
判斷交給 LLM，資料處理交給腳本 #
最初我們曾嘗試直接將原始日誌餵給 LLM，但它誤判了 syslog 的欄位位置，並出現計算錯誤。LLM 不擅長精確的數值彙整。現在，解析、計數與彙整皆由 shell script 處理；LLM 僅負責閱讀摘要並判斷「是異常還是正常？」以及「該如何處理？」。
誤判控制會隨營運逐漸完善 #
第一週充斥著誤判。Kerberos 電腦帳戶對 AD 的定期驗證產生了超過 1,000 筆登入成功報告，Nextcloud LDAP 整合則被標記為「可疑登入嘗試」。將每個模式陸續加入系統提示詞作為正常行為後，約兩週內雜訊便消除了。
對話隔離不可或缺 #
若直接沿用同一 session，先前的分析結果會殘留於上下文中，導致 LLM 加入諸如「與上次報告相比……」這類不必要的內容。安全分析每次都需要全新的視角，因此我們針對每次分析動態產生 session ID。
「沒有異常」的報告也有其價值 #
一開始，頻繁的 LOW 通知讓人感覺吵雜。但隨著時間過去，我們發現這些報告其實是在確認「系統正常運作中」。當通知停止時，我們便能察覺「監控本身已停止」——正是靠著這些定期報告。
未來規劃 #
目前的流程是「偵測 → 通知」。我們計畫將其擴展為「偵測 → AI 判斷 → 自動處理」。
具體而言，我們將實作攻擊來源 IP 的自動封鎖（直接呼叫防火牆 API）、暴力破解偵測時的自動封鎖，以及異常資源使用時的自動限流。我們也正在探索一種混合架構，讓 BASTION 透過 webhook 接收既有監控系統（Zabbix、AWS CloudWatch、Azure Monitor）的告警，執行跨系統的 AI 分析，並執行自動化處理。
總結 #
我們透過本地 LLM（Qwen2.5-14B）+ GPUStack + OpenClaw + rsyslog + shell script，實現了自動化基礎架構日誌分析。系統運行於一張 V100 16GB GPU 上，日誌資料不會離開此環境，每月營運成本僅為 GPU 的電費。
所有元件皆為開源，因此任何人都能重現此架構。然而，要達到完整運作，仍需要針對各設備進行日誌解析、累積誤判模式並調校系統提示詞——這些都是不容小覷的工作與營運知識。
BASTION 目前正 24 小時全年無休地在 BESTNET LLC 自有基礎架構（BESTNET-CLOUD）上正式運行。
