資安速報
定時執行。程式規則加上 AI 先做初步判讀，正常時只發一行「一切正常」，有問題才通知。
09/18 事件之後的資安強化
このコンテンツはまだ日本語訳がありません。
2026/09/18，我們發現承載 DPIP 服務的四台路由器遭到入侵。事件經過、影響與處置寫在事件完整說明，當天的服務公告在這裡。
那篇講的是「發生了什麼」。這篇接著講之後兩個月（09/18 到 11/15）我們在防護上做了哪些事，以及實測的結果。到 11/15 為止的複查都沒有再入侵的跡象，見事件說明的後續追蹤。
| 項目 | 09/18 | 之後 |
|---|---|---|
| 路由器 SSH 的外部登入失敗（四台合計） | 2,118 次 | 09/19 降到 170 次，09/20 起 0 次（至 11/15） |
| 白名單外連得上的對外入口（四台合計） | 26 個 | 11 個，包含網站、VPN 這類本來就要公開的服務 |
| 需要限制來源的入口中，已限制的比例 | 約 47%（22／47） | 約 88%（44／50） |
| SSH 管理入口有來源白名單的數量 | 1／13 | 15／15 |
| 路由器自動更新 | 沒有 | 12 次（3 個版本 × 4 台），沒有一次同時中斷 |
前兩項是實測，比例是依盤點表逐項推算，自動更新是設備上的安裝紀錄。下面依序說明。
一、盤點每一個對外入口
Section titled “一、盤點每一個對外入口”這次被入侵，問題不在於沒有防火牆，而在於有些被放行的入口沒有限制來源。所以第一件事，是把每一個對外入口逐一列出來，問同一個問題：這個入口，有沒有必要讓全世界都連得到？
盤了三次，加一次複查
Section titled “盤了三次，加一次複查”| 日期 | 範圍 |
|---|---|
| 09/19 | 四台路由器所有可能的攻擊路徑，加上雲端主機之間的服務互連，共列出 19 項 |
| 10/18 | 白名單複查（唯讀）：四台所有「允許來源」的設定與轉發規則 |
| 10/29 | 四台路由器的對外入口，加上經兩台雲端主機轉進來的路徑。這次最完整，有從外部實測，下面的數字都來自這次 |
| 11/05 | IPv6：四台路由器、底下的區網與兩台雲端主機。路由器底下的設備沒有 IPv6 對外路徑，白名單不會被 IPv6 繞過 |
10/29 怎麼盤
Section titled “10/29 怎麼盤”-
唯讀查詢四台的設定：防火牆、目的地轉址、路由器本身開著的服務、IPv6、UPnP。
-
從白名單外實際連連看：從一台不在白名單內的主機，連四台的對外位址。TCP 測約 75 個常見埠，加上設定裡出現過的埠；UDP 與 ICMP 另外測。結果分三種：連得上、逾時（封包被丟掉）、被拒絕（路徑是通的，但後面沒有服務）。
-
追經雲端主機轉進來的路徑：唯讀查詢兩台雲端主機的轉址與隧道設定。
-
動手前先看誰在用：要收窄其中一條轉發之前，先抓了 12 秒的封包標頭（只看來源，不看內容），發現有 7 個外部客戶端正在使用 DPIP 的一個資料埠，所以這個埠保留。
我們刻意不做全埠掃描：後端是正式服務，掃得太兇可能觸發自動封鎖，連帶影響使用者。所以實測範圍是約 75 個常見埠，加上設定中出現過的埠。
- 白名單外連得上的入口，四台合計從 26 個降到 11 個。少掉的 15 個沒有刪除任何轉發規則，而是加上來源白名單，或把轉發範圍縮小；從白名單內照常可以使用。
- 經兩台雲端主機轉進來的路徑，原本是所有埠、所有協定都轉進內網，改成只放網站與 DPIP 資料需要的幾個 TCP 埠。改完從外部實測，其他埠都連不到，DPIP 既有的長連線也沒有中斷。
- 路由器上停用了 6 個服務：這次攻擊用到的頻寬測試服務（4 台）、攻擊者自己開啟的 SOCKS 代理（2 台，連同攻擊者建立的代理帳號）。另外停用一組設備已離線的校時轉送規則。
- Winbox、API、Telnet、FTP 這類管理服務在事件前就已停用，不是這次才關的。事件當時真正對全世界開放的管理入口是 SSH，09/19 起只接受白名單來源。
二、來源白名單
Section titled “二、來源白名單”| 日期 | 加上來源限制的入口 |
|---|---|
| 09/19 | 四台路由器的 SSH 管理介面 |
| 10/29 | 12 條轉發規則：轉到內網主機的 SSH 10 條、內部服務 2 條 |
| 10/29 | 經雲端主機的 2 條全埠轉發，改成只放需要的埠 |
| 10/30 | 3 條原本對全網開放的監控指標轉發，限制為單一監控主機；另新增 2 條同樣限制 |
白名單的範圍刻意保持最小：不同用途的入口用不同的清單，例如監控用的清單只有實際抓指標的那一台主機，不沿用管理用的清單。
套用時，我們也切掉了白名單外的既有連線，四台合計 112 條。這些連線的來源都是雲端主機與海外的網路業者，判斷是暴力破解。
路由器 SSH 的外部登入失敗，09/18 四台合計 2,118 次，09/19 降到 170 次，09/20 起是 0，到 11/15 都沒有再出現。這段期間所有的登入失敗都來自我們自己的站台。
覆蓋率怎麼算
Section titled “覆蓋率怎麼算”約 47% → 約 88% 是我們依盤點表逐項算出來的，不是工具量出來的：
- 每個埠／協定算 1 個入口，經雲端主機的每條轉發路徑也算 1 個，停用的規則不算。
- 分母只算需要限制來源的入口，不算網站、VPN 這類本來就要公開的入口，也不算後面沒有服務在聽的規則。
| 09/18 | 10/30 之後 | |
|---|---|---|
| 需要限制來源的入口 | 47 | 50 |
| 已限制（來源白名單＋只放需要的埠） | 22 | 44 |
| 比例 | 約 47% | 約 88% |
09/18 那一欄是從現況倒推的，當時沒有做同樣的外部實測。其餘是評估後保留的入口。
三、收緊防火牆
Section titled “三、收緊防火牆”路由器「沒有明確放行就拒絕」的基本架構，事件前就有，事後沒有重寫。這次補的是放行規則本身：替原本不限來源的規則加上來源與範圍的限制。
| 四台合計 | 09/18 | 11/15 |
|---|---|---|
| 過濾規則（filter） | 104 | 107 |
| 轉址規則（NAT） | 59 | 73 |
規則數量變化不大。轉址規則多出的 14 條，主要是 VPN 使用者的 DNS 強制導向（10/11，每台 2 條）、隧道的截止規則與監控轉發。真正的變化是 17 條轉址規則加上了來源或埠的限制（12＋2＋3），以及四台 SSH 管理介面的來源限制。
改規則的原則：
- 變更前後都匯出完整設定逐行比對，確認除了要改的地方之外沒有其他差異。
- 每次變更前先準備好回復的方式。
- 先看連線與封包，確認誰在使用，再決定怎麼收窄。
另外，四台的管理密碼、VPN 使用者密碼、SSH 主機金鑰與 VPN 憑證機構都各自獨立。單一台被攻破，不會連帶拿到其他三台的憑證。
四、自動更新
Section titled “四、自動更新”這次被利用的漏洞，原廠的修補比攻擊者植入惡意程式早了 12 天釋出。只要有任何形式的自動更新，就能擋下這次攻擊。
所以 09/19 起，四台路由器改成定期自動檢查並安裝原廠 stable 通道的更新：
- 不限制只裝同一系列的小版本：入侵時有一台還在 7.22.1，而修補不在 7.22 系列裡；如果只裝 7.22.x，根本拿不到修補。
- 四台錯開進行，不會同時中斷。
- 安裝前自動備份，有問題可以回復；取不到版本資訊就跳過，不會誤裝。
- 排程的名稱與註解寫明是事件應變部署。這次的攻擊者就是用排程做持久化，避免日後稽核時被誤認成攻擊者留下的。
實際的結果：
| 版本 | 四台完成 |
|---|---|
| 7.24.5 | 10 月上旬 |
| 7.25 | 10 月下旬 |
| 7.25.1 | 11 月上旬 |
三個版本 × 四台，共 12 次自動升級，每次都有安裝紀錄，沒有一次造成四台同時中斷。11/15 時四台都是最新的 stable 版本。
五、資安速報、資安詳細、資安日報
Section titled “五、資安速報、資安詳細、資安日報”這段期間，我們也做了一套自動判讀主機日誌的工具，在 10/29 上線，涵蓋 7 台 Linux 主機，分成三種報告：
資安詳細
遇到新的危險項目，或負責人要求細查時，再做深入分析，產出一份報告。
資安日報
每天一份，整理前一天的狀況，加上相依套件的弱點、容器映像的掃描結果，以及新列入 CISA KEV（已知遭利用的弱點清單）的 CVE。
這套工具本身不能變成新的弱點
Section titled “這套工具本身不能變成新的弱點”- 資料只能單向送出。 各主機用各自專屬的金鑰，把摘要送到收件端。每把金鑰都綁死一個指令，只能上傳這一台自己的資料，開不了 shell，也冒充不了其他主機。收件端會檢查格式、大小與檔名，每台每天也有總量上限。
- 送出前先遮掉機密。 網址裡看起來像憑證的參數一律換成遮罩。完整的原始日誌留在各主機上，送出去的只有統計與挑過的片段。
- AI 只能唯讀。 日誌是外面的人寫的，網址、標頭裡都可能是攻擊者刻意埋進去的文字。所以讀日誌的 AI 只能讀監控資料，沒有 shell，也讀不到任何機密。
- 程式規則優先。 程式規則判定有問題的，就算 AI 判讀失敗也照樣通知。AI 不能直接修改判斷規則，只能提議，由程式驗證後才生效；所有排除最長 24 小時，入侵類的警示永遠不能排除，被負責人撤銷的規則 30 天內不會再學回來。
| 資料 | 保存 |
|---|---|
| 各主機送出的分類資料 | 30 天，總量上限 1 GB |
| 原始的上傳檔 | 3 天 |
| 主機的數字指標（CPU、網路流量等） | 由另一套指標系統保存 365 天 |
資料壓縮後只剩原本的約 1/37，所以 30 天的資料也用不到 1 GB。
- 機密檔掃描：有人掃
.env這類設定檔，全部回 404，沒有打進去。 - 資料庫叢集自動主從切換（11/12）：協調服務之間連線逾時，主節點自動切換，10 分鐘後原本的主節點接回成備援。新規則上線當天就抓到。
- 不熟悉來源的登入（11/11）：日報標出一筆從不熟悉來源的金鑰登入，請負責人確認，結果是本人，之後加進已知來源。
上線初期誤報偏多：11/12 回頭看 36 小時，約發了 110 則通知，大部分是誤報或重複。當天修掉 5 類誤報之後，同樣的時間估計會降到二十幾則。
這兩個月做的事，大部分不是新技術。來源限制的機制原本就在設備上，只是沒有用在該用的地方；自動更新是事件說明裡提到的「最便宜的防線」。
這些工作還在持續進行，我們會繼續檢查與調整。