ML-IDS + Telegram

用隔離環境產生攻擊流量 + 自產正常流量,訓練 flow-based ML 入侵偵測模型。

資料流

ConCap(產攻擊 + 自產四協定正常) → RustiFlow -f cic(特徵)
  → 合併 / 預處理(帶 scenario 標記)→ XGBoost
  → 整體 TPR/FPR + harness(各攻擊類型 TPR、各正常協定 FPR)

2026-05-31 改版:benign 從外部 MAWILab 換成 k3s 自產四協定正常流量 (normal-http/ftp/ssh/https,走同一條 ConCap 管線、完整錄包)。 原因:MAWI 是 header-only 擷取,benign 封包大小全 = 0,造成 35 個假 artifact、 AUC 假性 = 1.0;換源後 artifact 35→9(且性質變成 rate/timing 類、benign_mean 非零)、 移除後仍 AUC = 1.0 → 靠真行為而非擷取假象。

外部依賴

• ConCap(本 repo 的 git submodule,位於 deps/ConCap) — 我的 fork github.com/Jueruili/ConCap @ 34c16a1, 產攻擊流量 + 四個 normal-* 正常 scenario(run-cic/scenarios/)。
• RustiFlow — flow 特徵抽取(-f cic)。不需另外 clone 原始碼: 透過容器映像 ghcr.io/idlab-discover/rustiflow:slim 在 k8s pod 內執行 (由 ConCap 的 processing pod 呼叫)。正式環境建議改釘 image digest 以求可重現。
• MAWILab — 正常流量,放 ~/Downloads/mawi/(已棄用 2026-05-31,見上方改版說明)

重現步驟

1. 連 submodule 一起 clone:git clone --recursive <本 repo> (已經 clone 過的話,補:git submodule update --init)
2. python3 -m venv .venv && .venv/bin/pip install -r requirements.txt
3. 在 deps/ConCap 跑 ConCap,產出攻擊 + 四個正常 scenario 到 deps/ConCap/run-cic/completed/<scenario>/rustiflow-cic.csv
4. 跑 notebooks/pipeline.ipynb

⚠️ 待辦:notebooks/pipeline.ipynb 目前仍寫死 /home/jerry/.../ConCap 絕對路徑, 尚未改成 deps/ConCap 相對路徑;在那之前,在別的機器上重現需自行調整 notebook 內路徑。

部署(deploy/,需 Kubernetes 叢集)

線上即時偵測跑在 k8s 上——我在 k3s 與 microk8s 單機環境都部署過,manifest 是標準 k8s 物件,兩者皆可。

叢集只負責「錄包」+「抽特徵」,模型推論在本機 Python 跑:

ids-target pod(ssh 靶 + tcpdump 錄包)→ pcap 段
  → rustiflow-cic pod(kubectl exec 抽 cic 特徵)→ cic csv
  → 本機:preprocess(81 特徵)→ 模型 .pkl 預測 → 超閾值發 Telegram

前置:本機有 kubectl、~/.kube/config(或 $KUBECONFIG)能存取叢集; rustiflow-cic pod 由 ConCap 部署;deploy/.env(gitignore,不進 repo)放 TELEGRAM_TOKEN / TELEGRAM_CHAT_ID。

主要腳本:

• realtime_watch.py — 看守 tcpdump 滾出的 pcap 段,逐段抽特徵+推論,命中才發 Telegram(有冷卻)。
• detect.py — 單檔版:cic csv 或 pcap → 推論 → 超閾值告警(pcap 會先經 rustiflow-cic pod)。
• pcap_to_cic.py — pcap → cic csv,經 k8s rustiflow-cic pod(flags 與訓練一致)。
• preprocess.py — 原始 rustiflow cic csv → 81 特徵模型輸入(照 features.json reindex)。
• live_eval.py — 對 fresh 重跑 資料算各 scenario TPR/FPR、舊 vs 新模型對照(別餵訓練資料)。
• telegram_alert.py — 發 Telegram(只用標準庫)。

⚠️ 真實部署的兩道關卡(目前都還沒過)

1. 擷取面 — 目前只抓得到 lab 流量,抓不到外界流量。 現有 manifest 沒設 hostNetwork,tcpdump 抓的是 pod 內 eth0 = 只看得到該 pod 自己的流量。 要抓 host 真實網卡,需 hostNetwork: true + privileged(或 NET_RAW+NET_ADMIN)+ tcpdump 指定真實介面(eth0/wlan0)。但 k8s 改變不了物理限制:一個 node 只看得到送到它網卡的封包—— 單機抓 wlan0 只抓得到本機流量;要監看整個網段得靠網路位置(交換器 SPAN/mirror port、TAP、 把 node 放 inline/gateway、或雲端 traffic mirroring),不是靠 k8s。
2. 模型面 — lab-to-reality gap。 模型只在乾淨 lab TCP 上訓練,碰到真實背景流量(廣播/多播如 mDNS/SSDP)會 OOD 全判成攻擊 (見 deploy/ids-target.yaml 註解)。

結構

• notebooks/ — pipeline(載攻擊 → 載四協定正常 → 抽樣 → 預處理 → 訓練 → harness → artifact 掃描)
• deploy/ — 線上偵測腳本 + k8s manifest(*.yaml)
• deps/ConCap — ConCap fork(git submodule)
• data/ — 資料放置處(gitignore,不進 git;含 merged.csv / preprocessed.csv / ids_model*.pkl)
• requirements.txt — 套件版本(pin)

模型檔

• data/ids_model.pkl — 部署用(舊 MAWI 版,搭配 deploy/features.json 的 81 特徵)
• data/ids_model_k3s.pkl — k3s benign 版(本次重訓;資料仍在迭代,尚未 redeploy)