🔍 Linux Log 分析與 SIEM 實作：journalctl、GoAccess、ELK、Auditd、Fail2Ban 全攻略

🔍 Linux Log 分析與 SIEM 實作：journalctl、GoAccess、ELK、Auditd、Fail2Ban 全攻略

在現代環境裡，單一台 Linux 主機的 log 已經不再只是「出問題時才翻出來看」的輔助工具， 而是整體安全監控與事件追蹤的關鍵基礎。

本文會從單機的 journalctl、Auditd、Fail2Ban， 到 Web 流量分析工具 GoAccess，一路延伸到集中化的 ELK / SIEM 架構， 提供一套可以從「一台主機」平滑升級到「多台伺服器集中監控」的實戰路線。

---

📌 一、為什麼需要集中化 Logging + SIEM？

先快速整理傳統做法的幾個痛點：

• 只在出事時才上機看 /var/log，平常完全沒有趨勢觀察。
• 環境一多（5 台以上），每台逐一 ssh 查 log 完全不具規模性。
• 沒有統一的格式與保留策略，查舊資料時要靠運氣。
• 缺乏告警：Docker 當機、Nginx 502、sshd 爆量暴力攻擊時，沒有人第一時間收到通知。

而一套完整的 Logging + SIEM 架構可以提供：

• 集中收集：系統、Web、DB、安全設備 log 全丟到同一平台。
• 全文檢索：關鍵字搜尋或多條件過濾。
• 視覺化：儀表板顯示趨勢、Top IP、Top URL、Top 錯誤碼。
• 告警：依規則推播到 mail / Slack / Teams / LINE。
• 稽核追蹤：配合 Auditd、sudo log 等建立操作軌跡。

---

📚 二、Linux Log 基礎盤點：哪些東西要被收集？

常見要納入 Monitoring / SIEM 的 log 類型：

• 系統 log：systemd journal（journalctl）、kernel、boot
• 認證 log：sshd、sudo、su、PAM
• 服務 log：Nginx / Apache / HAProxy / Postfix / DB
• 安全 log：Auditd、Fail2Ban、SELinux / AppArmor event（可參考你的 Linux Security 系列）:contentReference[oaicite:1]{index=1}
• 應用程式 log：自家服務、微服務、容器應用產生的 log

接下來會從「單機工具」開始，逐步往集中化架構走。

---

🧰 三、journalctl：systemd 時代的 log 查詢主角

在使用 systemd 的 Linux 上，大部分服務 log 已經收斂到 journal 之中。

1. 查看整體 log（依時間倒序）

journalctl -r

2. 只看本次開機的 log

journalctl -b

3. 依照 service 過濾（例如 nginx）

journalctl -u nginx.service -f

4. 依時間區間查詢

journalctl --since "2025-12-03 10:00" --until "2025-12-03 11:00"

單機排錯與稽核時，習慣善用 journalctl 會讓效率差非常多。

---

🛡 四、Auditd + Fail2Ban：從 Log 到動作（封鎖攻擊）

1. Auditd：記錄「誰在系統上做了什麼」

Auditd 適合用來記錄：

• 關鍵檔案被誰修改（例如 /etc/sudoers、/etc/passwd）
• 特定目錄的讀寫行為
• 重要指令的執行記錄

# 監控 /etc/sudoers 任何存取
auditctl -w /etc/sudoers -p wa -k sudoers_watch

之後可用：

ausearch -k sudoers_watch
aureport -f

2. Fail2Ban：從 log 中自動封鎖惡意 IP

你已有 Fail2Ban 進階教學文章，可以當作本篇的延伸閱讀之一:contentReference[oaicite:2]{index=2}。

簡化版概念：

• 讀取指定 log（例如 /var/log/auth.log 或 journal）
• 比對 Regex 找出多次登入失敗 IP
• 透過 iptables / nftables / Firewalld 自動封鎖

[sshd]
enabled  = true
filter   = sshd
logpath  = /var/log/auth.log
maxretry = 5

Fail2Ban 的 log 本身也要進 SIEM，因為它代表「哪些 IP 曾經攻擊過你」。

---

📈 五、GoAccess：Web Access Log 即時分析

你已經有獨立的 GoAccess + Nginx/Apache Dashboard 教學文，可直接串為本篇延伸閱讀:contentReference[oaicite:3]{index=3}。

典型用法：

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  --real-time-html \
  --output=/var/www/html/report.html

優點：

• 部署超快，適合臨時分析流量。
• 可視化 Top URL、HTTP 狀態碼、來源 IP、User-Agent。
• 可當作「Web log 視覺化前哨」，再把原始 log 丟給 ELK 做更進階分析。

---

🧱 六、ELK / SIEM 架構：集中化 Log 與安全事件管理

典型的集中化架構大致如下：

各 Linux 主機：
  - systemd journal
  - /var/log/*（Nginx / Apache / App）
  - Auditd / Fail2Ban / Security logs
          │
          ▼
  Log Shipper（Filebeat / Fluent Bit / Vector）
          │
          ▼
  Elasticsearch / OpenSearch（索引與儲存）
          │
          ├─ Kibana / OpenSearch Dashboards（視覺化）
          └─ Alerting / SIEM（告警與關聯分析）

實作重點：

• 所有節點安裝輕量 Agent（如 Filebeat / Fluent Bit）。
• 針對不同 log 類型使用不同 input module（systemd、nginx、auditd …）。
• 在中央的 ELK/類似平台做索引、Mapping 與索引輪替。
• 在 Dashboards 上建 Dashboard：流量、錯誤、登入失敗、root/ sudo 操作等。

---

⚙️ 七、簡易實作範例：Filebeat + Elasticsearch + Kibana

1. 在 ELK 伺服器安裝 Elasticsearch + Kibana（略）

假設你已有一台集中化 log 伺服器。

2. 在 Linux 節點安裝 Filebeat

# 以 Debian 系為例（實際 repo 依官方文件）
sudo apt install filebeat

3. 啟用 systemd module

filebeat modules enable system
filebeat modules enable nginx
filebeat modules enable auditd

4. 設定輸出到 Elasticsearch

# /etc/filebeat/filebeat.yml
output.elasticsearch:
  hosts: ["elk01:9200"]
  username: "elastic"
  password: "your_password"

5. 啟動 Filebeat

systemctl enable filebeat
systemctl start filebeat

之後即可在 Kibana 上看到 systemd、nginx、auditd 等 log index，並建立 Dashboard 與 Alert。

---

🔔 八、告警與 SIEM 規則設計範例

集中化之後，關鍵在於你定義什麼樣的事件要「叫醒人」：

• 1 分鐘內多次 ssh 登入失敗 > N 次（配合 Fail2Ban 檢查）
• 某台主機 Journal 出現 repeated segfault / OOM
• Web 服務的 5xx 狀態碼突然飆高
• Auditd 出現對敏感檔案的異常讀寫
• 某 IP 對多個服務 port 做 port scan

這些規則同時可以記錄在你的 Runbook / SOP 中，讓值班人員照表處理。

---

🧪 九、容量管理與保留策略（結合你現有 logrotate 教學）

集中化 log 的另一個挑戰是：容量爆炸。你已經有獨立的 logrotate 進階教學，可以用來控管本機 log 檔案輪替:contentReference[oaicite:4]{index=4}。

在集中化平台則需要：

• 為 Index 設定保存天數與 size 上限。
• 將舊 Index 轉到冷儲存（S3 / 便宜磁碟）。
• 對「安全相關 log」與「一般應用 log」設定不同保留時間。
• 搭配備份策略（例如每天 snapshot、定期還原演練）。

---

📋 十、Linux Log + SIEM 實作 Checklist

✅ 盤點所有要收集的 log 類別（系統 / Web / DB / 安全設備 / App）
✅ 統一時區與 NTP，同一事件不會每台時間都不同
✅ 善用 journalctl / Auditd / Fail2Ban 做單機防禦
✅ Web 流量先用 GoAccess 做初步分析與報表
✅ 部署集中化 Log 平台（ELK / OpenSearch / 其他）
✅ 每台 Linux 安裝 Log Shipper（Filebeat / Fluent Bit / Vector）
✅ 對關鍵事件定義 Alert 規則並測試通知
✅ 為 Index / Log 設定保留天數與容量上限
✅ 定期做「還原與稽核演練」，確認 log 真能回答問題
  

---

💬 互動留言引導（Log / SIEM 實戰分享區）

如果你在規劃或實作 Linux Log / SIEM 架構時，遇到以下狀況：

• 不知道該先收哪些 log？
• ELK / OpenSearch 架起來卻效能很差？
• Filebeat / Fluent Bit 一直送不到集中平台？
• Fail2Ban / Auditd log 太多，不知道該看什麼？

歡迎在下方留言你的環境規模、節點數量與目前做法， 我會盡量以實戰角度協助分析，並把有代表性的案例整理成後續補充篇。

---

🔗 延伸閱讀

• 🛡 Linux 安全強化：SELinux / AppArmor / Auditd / Fail2Ban 完整指南
• 📊 GoAccess + Nginx/Apache Dashboard 教學：即時 Web Log 分析
• 🗄️ Linux Logrotate 進階指南：Log 輪轉、壓縮、清理與自動化
• 📡 Linux 監控工具完整指南：top / htop / glances / nmon / dstat
• 🔐 Linux OpenVPN 完整實戰：PKI 建置、Client 設定與路由規劃

— WWFandy・Linux Log & SIEM Notes