2026FIFAWorldCup/docs/security/incident-2026-06-18-188-miner-triage.md

2026-06-18 188 主機挖礦木馬疑慮清查紀錄

結論摘要

截至 2026-06-18 11:20（Asia/Taipei）的第一輪清查，尚未在 current-fifa2026-web-1 或 FIFA 相關容器內確認正在執行的挖礦程序。

實際確認到的高風險問題是：正式產品 repo 與正式部署目錄曾混入多個手工維運與緊急防禦腳本。這些腳本包含硬編碼密碼、跨主機 sshpass、自動修改正式機檔案、手動重建容器、直接刪除暫存 ELF、以及非 CI/CD 管控的自動 kill 流程。這類做法不可再進入正式環境。

188 現場觀察

• CPU 熱點主要是 signoz-clickhouse、falco、VibeWork/Momo 相關服務與監控元件。
• FIFA 相關容器 CPU 佔用很低，current-fifa2026-web-1 在抽樣時為 0% 左右。
• current-fifa2026-web-1 容器內只看到 next-server，未看到 javae、npm start、xmrig、kinsing、kdevtmpfsi 或 /tmp 可疑執行檔。
• /tmp、/var/tmp、/dev/shm 抽樣未看到典型挖礦 ELF。
• ss 抽樣未看到連往常見挖礦連接埠或已封鎖 IOC 的現行連線。
• Falco 主要警報來自 Wazuh 與 Momo/Postgres healthcheck 讀取敏感檔案造成的告警噪音，需另行調整規則與 healthcheck。

已確認高風險檔案

下列檔案不得存在於正式產品 repo，也不得由手工 SSH 推進到正式環境：

• iwooos_javae_monitor.sh
• iwooos_autopatch.py
• fix_guardian.py
• fix_register.sh
• fix_wazuh.sh
• ops/harden-host.sh

風險原因：

• 含硬編碼密碼或手工 sudo 流程。
• 含跨主機 sshpass 與自動修改遠端主機設定。
• 含自動修改 package.json、重建 Docker、直接操作正式容器。
• 含可能刪除證據的 /tmp ELF 清除流程。
• 含與 Docker Compose 狀態不一致的手動 docker run。

已套用的 repo 修正

• 移除上述 6 個高風險腳本。
• 將 Wazuh API route 改成只使用環境變數，不再硬編碼帳密。
• Wazuh 未設定或讀取失敗時，明確回傳「未接入真實資料」，不再輸出假告警、假弱點統計或假事件。
• Gitea CD 新增安全閘門，阻擋硬編碼密碼、手工 SSH 修補、挖礦 IOC、sshpass 與禁止檔案。
• Gitea CD 移除會吞錯的 || true，測試、lint、稽核失敗即停止部署。
• Gitea CD 改用 rsync --delete，讓正式機同步清掉已從 repo 移除的高風險腳本。
• Docker Compose 改成要求正式環境必須提供 DB_PASSWORD、REDIS_PASSWORD、NEXTAUTH_SECRET，不得再使用 change_me 類預設值。

後續必做事項

• 輪換所有曾出現在腳本、環境檔、shell 歷史或部署目錄中的密碼與 API key。
• 由 Gitea Secrets 管控正式部署密鑰，不再把密鑰寫進 repo 或腳本。
• 移除 188 上 /home/ollama/scripts/iwooos_javae_monitor.sh 的 cron。
• 清查 192.168.0.112 guardian/Wazuh 來源，確認反覆 SSH 進 188 執行防火牆檢查的流程是否仍需要保留。
• 調整 Falco/Wazuh 規則，降低 healthcheck 造成的敏感檔案誤報。
• 收斂 188 對外服務埠，只保留必要入口。