09/18 事件之後的資安強化

分享2026年11月15日閱讀時間約 10 分鐘

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 台），沒有一次同時中斷

前兩項是實測，比例是依盤點表逐項推算，自動更新是設備上的安裝紀錄。下面依序說明。

一、盤點每一個對外入口

這次被入侵，問題不在於沒有防火牆，而在於有些被放行的入口沒有限制來源。所以第一件事，是把每一個對外入口逐一列出來，問同一個問題：這個入口，有沒有必要讓全世界都連得到？

盤了三次，加一次複查

日期	範圍
09/19	四台路由器所有可能的攻擊路徑，加上雲端主機之間的服務互連，共列出 19 項
10/18	白名單複查（唯讀）：四台所有「允許來源」的設定與轉發規則
10/29	四台路由器的對外入口，加上經兩台雲端主機轉進來的路徑。這次最完整，有從外部實測，下面的數字都來自這次
11/05	IPv6：四台路由器、底下的區網與兩台雲端主機。路由器底下的設備沒有 IPv6 對外路徑，白名單不會被 IPv6 繞過

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 起只接受白名單來源。

二、來源白名單

日期	加上來源限制的入口
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 都沒有再出現。這段期間所有的登入失敗都來自我們自己的站台。

覆蓋率怎麼算

約 47% → 約 88% 是我們依盤點表逐項算出來的，不是工具量出來的：

每個埠／協定算 1 個入口，經雲端主機的每條轉發路徑也算 1 個，停用的規則不算。
分母只算需要限制來源的入口，不算網站、VPN 這類本來就要公開的入口，也不算後面沒有服務在聽的規則。

	09/18	10/30 之後
需要限制來源的入口	47	50
已限制（來源白名單＋只放需要的埠）	22	44
比例	約 47%	約 88%

09/18 那一欄是從現況倒推的，當時沒有做同樣的外部實測。其餘是評估後保留的入口。

三、收緊防火牆

路由器「沒有明確放行就拒絕」的基本架構，事件前就有，事後沒有重寫。這次補的是放行規則本身：替原本不限來源的規則加上來源與範圍的限制。

四台合計	09/18	11/15
過濾規則（filter）	104	107
轉址規則（NAT）	59	73

規則數量變化不大。轉址規則多出的 14 條，主要是 VPN 使用者的 DNS 強制導向（10/11，每台 2 條）、隧道的截止規則與監控轉發。真正的變化是 17 條轉址規則加上了來源或埠的限制（12＋2＋3），以及四台 SSH 管理介面的來源限制。

改規則的原則：

變更前後都匯出完整設定逐行比對，確認除了要改的地方之外沒有其他差異。
每次變更前先準備好回復的方式。
先看連線與封包，確認誰在使用，再決定怎麼收窄。

另外，四台的管理密碼、VPN 使用者密碼、SSH 主機金鑰與 VPN 憑證機構都各自獨立。單一台被攻破，不會連帶拿到其他三台的憑證。

四、自動更新

這次被利用的漏洞，原廠的修補比攻擊者植入惡意程式早了 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 版本。

五、資安速報、資安詳細、資安日報

這段期間，我們也做了一套自動判讀主機日誌的工具，在 10/29 上線，涵蓋 7 台 Linux 主機，分成三種報告：

資安速報

定時執行。程式規則加上 AI 先做初步判讀，正常時只發一行「一切正常」，有問題才通知。

資安詳細

遇到新的危險項目，或負責人要求細查時，再做深入分析，產出一份報告。

資安日報

每天一份，整理前一天的狀況，加上相依套件的弱點、容器映像的掃描結果，以及新列入 CISA KEV（已知遭利用的弱點清單）的 CVE。

這套工具本身不能變成新的弱點

資料只能單向送出。 各主機用各自專屬的金鑰，把摘要送到收件端。每把金鑰都綁死一個指令，只能上傳這一台自己的資料，開不了 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 類誤報之後，同樣的時間估計會降到二十幾則。

結語

這兩個月做的事，大部分不是新技術。來源限制的機制原本就在設備上，只是沒有用在該用的地方；自動更新是事件說明裡提到的「最便宜的防線」。

這些工作還在持續進行，我們會繼續檢查與調整。