ExpTech | Blog

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

Sun, 15 Nov 2026 00:00:00 GMT

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 類誤報之後，同樣的時間估計會降到二十幾則。

結語

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

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

09/18 基礎設施遭入侵事件完整說明

Fri, 18 Sep 2026 00:00:00 GMT

嚴重程度：嚴重狀態：修補完成，11/15 複查無再入侵

問題描述: 承載服務的四台網路設備遭到入侵，攻擊者取得了完整管理權限
根本原因: 設備的系統版本落後於已公開的安全性修補，而且管理介面直接暴露在網際網路上。
最早入侵痕跡: 2026/09/02
發現日: 2026/09/18
影響範圍: 承載 DPIP 服務的四台網路設備

先講結論

2026/09/18 上午，DPIP 服務出現異常。排查後我們發現，承載服務的四台網路設備遭到入侵，攻擊者取得了完整管理權限。

進一步取證後確認，最早的入侵痕跡可以回溯到 2026/09/02 —— 也就是說，攻擊者在我們的設備上待了約 16 天，我們才發現。

這是我們的疏失。設備的系統版本落後於已公開的安全性修補，而且管理介面直接暴露在網際網路上。這兩件事都是我們自己該做而沒做好的。

截至 2026/09/20，四台設備的修補與清除已全部完成並經實測驗證。 期間我們還捕捉到兩次攻擊者嘗試重新利用同一漏洞、被新版本擋下的紀錄 —— 這是修補確實有效的直接證據。

之後到 2026/11/15 為止的複查都沒有再入侵跡象，見後續追蹤。

這篇文章把我們查到的東西完整寫出來，包含每一項結論是怎麼驗證的，以及還沒查完的部分。

對你的影響

這是你最需要知道的部分，所以放在最前面。

你的資料

項目	狀態	依據
DPIP 蒐集的使用者相關資料	本即為去識別化資料，經確認未受影響	——
經過這些設備的網路流量	被側錄的可能性已基本排除	見下方「關於流量是否被側錄」
設備上的憑證、VPN 金鑰、私鑰	一律視為已洩漏 → 已全部輪換完成	9 把 WireGuard 私鑰、4 組 CA、5 個 `.ovpn`、4 把 SSH host key
內網服務的認證資訊	無法排除曾被讀取 → 已輪換或加上認證	見還沒查完的部分

被入侵的四台是網路層設備（路由器 / 負載平衡），它們負責把封包送到正確的地方，本身不存放應用程式資料。攻擊者拿到的是「網路設備的管理權」，不是「使用者資料庫」。

關於流量是否被側錄

攻擊者確實具備側錄能力（植入的排程帶有 sniff 權限，且他們處在所有流量的路徑上）。但 RouterOS 上所有「實際有效」的側錄手法都必須修改設定，而設定變更會留下紀錄。

我們逐一檢查了全部 9 種手法在取證當下的實際狀態：

側錄手法	需改設定	取證時的實際狀態
`/tool sniffer` 設過濾器後啟動	需要	22 個過濾欄位全部為空（出廠預設）
`/tool sniffer` 串流外送至遠端	需要	`streaming-enabled=no`、目標為預設值
`/tool sniffer` 存檔	需要	檔名欄位空白；設備上無任何 `.pcap` / `.cap` 檔
`/tool sniffer` 放大緩衝區	需要	`100KiB`（出廠預設，未動）
防火牆 `action=sniff-tzsp` 鏡像至遠端收集器	需要	0 條規則
交換晶片埠鏡像	需要	來源 / 目標皆為 `none`（預設）
NetFlow 外送	需要	四台皆 `enabled=no`
容器內跑 tcpdump	需要	container 套件四台皆未安裝
`/tool sniffer quick`（純執行期）	不需要	無法從設定排除 —— 見下方

決定性的一點是：我們能證明「修改設定一定會留紀錄」。

攻擊者自己留下了 32 筆 log action changed 紀錄 —— 那正是他們破壞日誌所用的 /system logging action set 操作。這證明了 /system X set 這類操作確實會被記錄。既然如此，/tool sniffer set … 也會被記錄。

而入侵期間（09/15 起）四台合計 47 筆此類操作紀錄，分類如下：

操作	筆數	性質
修改日誌輸出設定	32	反取證
修改日誌規則	8	反取證
新增使用者	4	建立後門帳號
從排程移除腳本	4	惡意程式的重複投放設計
與側錄相關	0	——

紀錄緩衝區的覆蓋範圍也經過確認（最舊紀錄早於入侵日，因此沒有被捲掉）：

節點	紀錄筆數	最舊紀錄日期	早於入侵日 09/15？
`core-tnn1`	101	2026-06-30	是
`node-tnn1`	40	2026-07-02	是
`node-tnn2`	22	2026-09-03	是
`lb-khh1`	19	2026-09-02	是

唯一無法從設定排除的是 /tool sniffer quick（純執行期操作，不留設定紀錄）。但在未經修改的預設設定下，它的緩衝上限是 100KiB、單封包上限 2048 bytes，大約只能保存 50 到 100 個封包，而且沒有過濾器 —— 抓到的是隨機流量，不是針對特定服務的憑證。要有效擷取憑證就必須設過濾器或放大緩衝，那就回到「必須改設定」，而那些紀錄是 0 筆。

結論：流量側錄基本排除。 這不是「我們覺得應該沒事」，是逐項查證後的結果。

我們仍然無法排除的部分

服務可用性

警告 2026/09/18 11:45
服務出現異常
資訊 2026/09/18 15:20
取證完成
資訊 2026/09/18 15:25
開始清理，服務陸續恢復

你需要做什麼

發生了什麼事

一句話版本

MikroTik 這家廠商的路由器作業系統在 2026 年 9 月被公開了一組安全漏洞，攻擊者可以不需要密碼就取得路由器的最高管理權限。我們的四台設備版本太舊、沒有修補，而且管理介面對全世界開放，所以被打進來了。

稍微詳細一點

2026/09/02，資安社群開始觀測到有人在網路上大規模掃描並攻擊 MikroTik 路由器（這波攻擊被稱為 MikroTrick）。 2026/09/03，MikroTik 釋出修補版本。 2026/09/05，波蘭國家電腦緊急應變小組（CERT Polska）正式公告，當時全球有 122,500 台 MikroTik 設備的管理介面暴露在公網上。 2026/09/14，統計顯示全球約 260 萬台 MikroTik 設備處於曝險狀態。

我們的四台設備，系統版本的發布日期全部早於 09/03 的修補釋出日。 從攻擊活動開始的那天起，這四台就一直是可以被攻破的狀態，而我們完全不知道。

攻擊者在 09/02 就進來了。

修補在攻擊者部署主要惡意程式的 12 天前就已經可以取得。 這一點我們必須講清楚 —— 這不是零時差攻擊，是我們沒有及時更新。

為什麼會被打進來

漏洞本身

這次公開的其實是六個 CVE，不是新聞上常提到的那兩個：

CVE	攻擊面	修補版本
CVE-2026-67276	SSH 認證（RSA exponent 未驗證）	7.23.4 / 7.24.2
CVE-2026-67277	btest / bandwidth-test	6.49.21 / 7.23.4 / 7.24.2
CVE-2026-67278	TLS + SSH host-key	7.23.6 / 7.24.3
CVE-2026-67279	SSH rekey	6.49.21 / 7.23.4 / 7.24.2
CVE-2026-67281	WebFig `/jsproxy`	7.23.4 / 7.24.2
CVE-2026-86060	SSH 登入提權	6.49.21 / 7.23.4 / 7.24.2

其中 CVE-2026-67277 與 CVE-2026-86060 已於 2026/09/10 被美國 CISA 列入 KEV（已知遭利用漏洞清單） —— 代表這不是理論風險，是確定有人在用它攻擊。

攻擊者怎麼進來的

真正的接管鏈是兩個漏洞串起來的，全程走 SSH，不需要任何帳號密碼：

[1] CVE-2026-67276
    RouterOS 在比對 SSH 公鑰時，只比對 key type 與 modulus，「不比對 exponent」。
    攻擊者送出一把 exponent = 1 的公鑰，就能在沒有私鑰的情況下偽造出有效簽章
    → 認證通過。
              ↓
[2] CVE-2026-86060
    用一個「開頭是禁用字元」的使用者名稱（例如 -2）登入，
    RouterOS 的登入處理程式沒有正確處理參數分隔符，
    導致這個連線可以改寫自己的權限設定
    → 提權成功。
              ↓
[3] 未認證的攻擊者取得完整 administrator 權限

CVE-2026-86060 的特徵是使用者名稱以 - 開頭。這不只是理論 —— 我們在升級完成後的設備日誌上，實際捕捉到兩次以 -2 為使用者名稱的 SSH 登入嘗試：

time=2026-09-18 20:20:44 topics=system,error,critical
message="login failure for user -2 from 46.101.236.154 via ssh"
extra-info="app=ssh duser=-2 outcome=failure src=46.101.236.154"

time=2026-09-18 20:55:16 topics=system,error,critical
message="login failure for user -2 from 159.89.228.250 via ssh"
extra-info="app=ssh duser=-2 outcome=failure src=159.89.228.250"

兩次都是 outcome=failure。詳見修補有效的直接證據。

CVE-2026-67278 的修補版本寫的是 7.23.4 / 7.24.2，但那個修補是不完整的。

CERT Polska 的原文明確寫著：“Releases 7.23.4 and 7.24.2 included an incomplete fix.” 實際需要 7.23.6 或 7.24.3。

問題是 —— 我們查了四個來源：

來源	標示的修補版本	有提到修補不完全嗎
CERT Polska（原始通報者）	7.23.6 / 7.24.3	有
OpenCVE	7.23.4 / 7.24.2 / 6.49.21	沒有
Rapid7	7.23.4 / 7.24.2	沒有
MikroTik 官方 supportsec 頁	只列 7.25beta3 / 7.24.2 / 7.23.4 / 6.49.21	沒有

連 MikroTik 自己的公告頁都沒寫。 如果我們只看漏洞資料庫或原廠公告就升級到 7.23.4，會以為已經修好了，但實際上還有一個洞開著。

我們最後把判定線訂在 7.23.6 以上，實際升級到當時的最新穩定版 7.24.4。

我們自己的問題

漏洞是廠商的，但設備沒更新、管理介面對外開放，是我們的責任。

節點	事發版本	版本發布日	落後
`core-tnn1`	7.23.1	2026-06-02	約 3 個月
`node-tnn2`	7.22.2	2026-04-22	約 5 個月
`node-tnn1`	7.22.1	2026-03-23	約 6 個月
`lb-khh1`	7.22.1	2026-03-23	約 6 個月

而且四台的 SSH 管理介面都設定成允許任何來源 IP 連入。

時間軸

所有時間為台灣時間（UTC+8）。node-tnn1 的系統時鐘當時慢了 6 小時 45 分（NTP 未同步、期間未重開機，偏差固定），該台的時間都已換算成實際的台灣時間。

外部事件

警告 2026-09-02
CERT Polska 觀測到針對 RouterOS 的攻擊開始
資訊 2026-09-03
MikroTik 釋出修補版本 7.24.2 / 7.23.4
警告 2026-09-05
CERT Polska 正式公告，全球 122,500 台設備曝險
警告 2026-09-10
CISA 將兩個 CVE 列入 KEV
資訊 2026-09-14
全球曝險設備統計約 260 萬台

我們的設備上發生的事

嚴重 09-02 14:39
後門帳號 ops 登入 —— 最早的入侵痕跡core-tnn1
嚴重 09-02 15:45
後門帳號 ops 登入node-tnn1
嚴重 09-10 16:27 / 16:43
兩台各殘存的唯一一筆日誌：possible SYN flooding on tcp port 22（相距 16 分鐘，同一波 SSH 攻擊）lb-khh1 / core-tnn1
嚴重 09-10 22:53
後門帳號 routeradmini 登入，11 秒後開始修改日誌設定lb-khh1
嚴重 09-11 05:44
同一個後門帳號做同樣的事core-tnn1
嚴重 09-11
植入「每日自動重建後門帳號」的排程lb-khh1
嚴重 09-12 22:25:11 / 22:25:49
後門帳號 system 登入兩台，相隔 38 秒 → 自動化橫向移動core-tnn1 / node-tnn2
嚴重 09-15 08:05
植入 C2 遠端控制程式，每 3 分鐘對外回連node-tnn1
嚴重 09-15 17:48 → 21:34
四台在 4 小時內被依序套用相同的日誌破壞設定四台
嚴重 09-15 → 09-18
日誌壓制動作被反覆執行 20 次以上四台
嚴重 09-17 05:19
新增後門帳號 gabor76core-tnn1
嚴重 09-18 05:06
新增後門帳號 mark65node-tnn1
嚴重 09-18 10:41
攻擊者建立兩條管理員權限的 SSH 連線core-tnn1
嚴重 09-18 10:44
新增後門帳號 martin1node-tnn1

我們的應變

警告 09-18 11:45
服務異常，開始排查
警告 09-18 12:50
確認遭植入惡意腳本
資訊 09-18 12:53
開始完整取證（四台，全程唯讀）
資訊 09-18 15:20
取證完畢，SHA256 與保管鏈建立
資訊 09-18 15:25
開始清理，服務陸續恢復
已恢復 09-18 15:56 → 16:10
四台逐台升級至 7.24.4（16:00–16:06），各台升級後立即輪換管理密碼
資訊 09-18 16:21
四台建立磁碟日誌規則
資訊 09-18 16:40 → 16:50
RouterBOOT 韌體升級的重開機
已恢復 09-18 20:20 / 20:55
修補約 4 小時後，兩次 -2 再入侵嘗試被新版本擋下（見下節）
資訊 09-18 → 09-19
VPN PKI 重建（09-18）、9 把 WireGuard 私鑰輪換（站對站 09-18、roadwarrior 09-19）
資訊 09-19 00:35 → 00:45
四台 SSH 管理介面設來源白名單
資訊 09-19 01:43 → 01:49
記憶體日誌上限拉到 65535、每週自動更新排程上線
警告 09-19 02:00 → 12:00
擴大範圍稽核 → 發現資料平台的認證缺口並修補（見下節）
資訊 09-19 12:00 → 18:00
移除 46 個受污染／調查產物檔案，建立乾淨基準備份
已恢復 09-20 11:44
重新入侵比對：四台皆無新入侵跡象
已恢復 09-21
第二次健康檢查：四台無再入侵跡象
已恢復 11-15
第三次健康檢查：四台無再入侵跡象
（見後續追蹤）

修補有效的直接證據

這是我們認為最值得分享的一段。

升級完成約 4 小時後，攻擊者回來了兩次，而設備日誌把過程完整記下來了：

時間	節點	來源 IP	來源歸屬	使用者名稱	結果
2026-09-18 20:20:44	`node-tnn2`	`46.101.236.154`	DigitalOcean	`-2`	失敗
2026-09-18 20:55:16	`lb-khh1`	`159.89.228.250`	DigitalOcean	`-2`	失敗

使用者名稱 -2 正是 CVE-2026-86060 的引數注入特徵。同一個攻擊手法，在修補後的版本上失敗了。

攻擊者被完全擋在門外的驗證

09/19 凌晨我們把四台的 SSH 管理介面限制為來源白名單。效果可以直接量化 —— 以下是外部來源的 SSH 登入失敗次數逐日統計：

節點	09-18	09-19	最後一次外部嘗試
`core-tnn1`	140	12	2026-09-19 00:30:06
`node-tnn1`	1667	120	2026-09-19 01:01:34
`node-tnn2`	145	14	2026-09-19 01:41:57
`lb-khh1`	166	24	2026-09-19 00:37:28

白名單的套用時間是 09-19 00:35 到 00:45。外部嘗試在那之後隨即歸零。截至 11/15，近兩個月一次都沒有 —— 期間所有登入失敗紀錄的來源，都是我們自己的站台。

這不是「我們相信設定生效了」，是從外部實測的結果。

技術細節：攻擊者做了什麼

攻擊者不是只留一條後路，而是在不同設備上用了四種完全不同的手法。這也是為什麼「升級 + 改密碼」完全不夠。

1. 後門帳號（四台都有）

四台合計 25 個帳號條目、12 個不重複的帳號名稱，全部是最高權限、全部不限制來源 IP。

帳號	`core-tnn1`	`node-tnn2`	`node-tnn1`	`lb-khh1`	備註
`ops`					CERT Polska 公告的 MikroTrick 特徵帳號
`saryn`					攻擊者取證當下使用中
`SystemMikrotik`					偽裝成系統帳號
`routeradmin`					偽裝成管理帳號
`routeradmini`					上一個的 typo 變體
`system`					偽裝成系統帳號
`operator`
`test`
`gabor76`					人名型
`mark65` / `martin1`					人名型
`zkadmin`					刪掉會自己長回來

ops 這個帳號是本案最強的關聯證據。 它是 CERT Polska 公告中點名的 MikroTrick 特徵帳號，而它在我們兩台設備上的最後登入時間是 2026-09-02 —— 正好就是全球攻擊活動開始的那一天。

攻擊者的互動來源 IP 是 203.74.122.229（取證當下 saryn 的兩條活躍連線來源）。

2. C2 遠端控制程式（node-tnn1）

這是最嚴重的一項。攻擊者在其中一台植入了一支會主動對外回連、接收遠端指令的程式。

連線目標： http://85.137.54.178:8080（荷蘭，VSYS-AMS-COLO）
頻率： 每 3 分鐘一次
植入時間： 2026-09-15 08:04:59（設備時鐘顯示 01:19:52，該台時鐘慢 6 小時 45 分）
截至取證的執行次數： 1536 次

它做兩件事：

把設備資訊（架構、系統版本、硬體型號、設備名稱）回報給對方
去對方的伺服器抓一個指令檔回來執行，執行完立刻把檔案刪掉

也就是說，攻擊者可以隨時在這台設備上執行任何指令，而且不留痕跡。

這支程式的原始碼第一行是它自己寫的註解：

# RouterOS foothold — beacon CNC every 3 minutes WITH identity
# Installed via /import after /tool fetch

「foothold（立足點）」、「beacon CNC（向指揮控制伺服器回連）」—— 它自己說明了自己是什麼，我們不需要任何外部情報就能判定它是惡意程式。

三個設計細節值得說明：

start-time=startup —— 重開機會自動復活。所以「重開機就好了」是錯的。
安裝程式具幂等性 —— 它執行時會先刪掉舊的再裝一次，代表它被設計成可以重複投放。只要對方還連得到設備，刪掉它沒有意義。
靜默失敗 —— 整段程式碼包在錯誤忽略的區塊裡，出錯不會留下任何記錄。

我們刻意沒有去連線或掃描那個 C2 伺服器。觸碰攻擊者的基礎設施可能驚動對方、讓他清除痕跡或加速破壞，這部分交由司法機關與 CERT 處理。

完整 IoC 清單（供其他防守方比對）：

# C2
85.137.54.178:8080          # 本案實際觀測（荷蘭 VSYS-AMS-COLO），未見於公開清單
82.192.72.4                 # 公開 IoC，本案未出現
103.102.31.18               # 公開 IoC，本案未出現

# 攻擊者互動來源
203.74.122.229              # 取證當下的活躍管理連線

# 再入侵嘗試來源（修補後，皆失敗）
46.101.236.154              # DigitalOcean
159.89.228.250              # DigitalOcean

# 後門帳號名稱
ops saryn SystemMikrotik routeradmin routeradmini
system operator test gabor76 mark65 martin1 zkadmin

# 持久化的檔案／排程／腳本名稱
boat_ros                    # C2 排程與腳本（node-tnn1）
daily-maint                 # 帳號復活排程（lb-khh1）
logrotate                   # 帳號復活腳本（lb-khh1）
ros-task.rsc                # C2 下載的指令檔（執行後即刪）

# SSH 登入特徵
使用者名稱以 "-" 開頭（例如 -2）   # CVE-2026-86060 引數注入

3. 會自己長回來的後門帳號（lb-khh1）

另一台設備上沒有 C2，但有一套更陰險的東西：

排程「daily-maint」（每日維護）  每天 03:00 執行
      ↓
腳本「logrotate」（日誌輪替）
      ↓
如果後門帳號 zkadmin 不存在 → 用固定密碼重新建立為最高權限

你刪掉那個帳號，隔天凌晨三點它就回來了。

最值得警惕的是偽裝手法：daily-maint（每日維護）和 logrotate（日誌輪替）這兩個名字，看起來比我們自己寫的排程還像正常維運工作。

唯一能區分的是建立者欄位 —— 同一台設備上所有合法的排程（NTP 校時、MAC 重置、DDNS 更新、韌體升級、WAN 備援檢查）全部標示為 admin，只有這兩個標示為 0（代表非由使用者互動建立）。

看建立者，不要看名字。

4. 注入的 SSH 金鑰（lb-khh1）

這是四種手法裡最隱蔽的一種：攻擊者在合法的 admin 帳號上，掛了一把自己的 SSH 金鑰（RSA 3072，指紋 SHA256:zJ8ypOH1lW4DtgPrO+V1qmZUJprP8WzxlJGFYIFWZt8=）。

為什麼難發現：

它不是一個新帳號 —— 稽核帳號清單看不到
它不是一個新排程或腳本 —— 稽核持久化機制看不到
它掛在合法帳號上
金鑰登入不受暴力破解防護限制（金鑰認證不計失敗次數）

它還有一個副作用，而這個副作用其實就是我們最初遇到的怪事 —— 正確的管理密碼在這台設備上突然失效了。

原因是 RouterOS 的一項設定語義：「這個使用者如果已經註冊了金鑰，就拒絕密碼登入」。攻擊者掛上金鑰之後，我們自己的密碼就被擋在門外了。

我們一開始以為是憑證記錯了。「管理密碼突然失效」本身就是一個入侵指標，這是我們學到的一課。

這台最後是改用 RouterOS 的 REST API 完成取證的，取得 119/121 個端點、238 個證據檔。

此外這台的 SOCKS 代理伺服器也被開啟且沒有任何來源限制，並建立了一個代理帳號（r7n2k）—— 這是把設備變成攻擊他人的中繼站的典型手法。同一個帳號也出現在 core-tnn1，而另外兩台的 SOCKS 帳號清單是空的，這個差異本身就證明它是攻擊者留下的。

5. 反取證：日誌被系統性破壞（四台一致）

這是讓我們最難查的一件事。

四台設備的日誌設定都被改成了無法保留任何紀錄的狀態：

記憶體日誌上限從原廠預設的 1000 筆改成 1 筆
涵蓋「登入事件、帳號建立、設定變更」的日誌類別全部停用
沒有設定外部 syslog 伺服器 → 設備之外沒有任何副本

結果是四台各只剩下 1 筆日誌。

節點	殘存的唯一一筆
`lb-khh1`	`09-10 16:27:07` SSH 埠遭大量連線攻擊
`core-tnn1`	`09-10 16:43:18` SSH 埠遭大量連線攻擊
`node-tnn2`	`09-14 13:35:56` DHCP 警告
`node-tnn1`	`09-09 17:34:34` 排程移除紀錄（設備時鐘；實際為 09-10 00:19）

前兩筆很有意思 —— 兩台在 16 分鐘內都記錄到對 SSH 埠的大量連線攻擊。而 SSH 正是這次漏洞的攻擊面，2026-09-10 也正是 CISA 把這些漏洞列入 KEV 的同一天。

這是唯一殘存、時間點與攻擊活動吻合的日誌。其餘全部被抹掉了。

6. 但有一樣東西活下來了

RouterOS 有一份「設定變更歷史」，記錄誰在什麼時候改了什麼。它只存在記憶體裡，重開機就永久消失。

攻擊者沒有動它（也動不了）。而它清楚地畫出了入侵分界線：

合法的維運變更全部標示 admin
惡意變更全部標示 0 或後門帳號名稱
它直接記錄了 user gabor76 added、user mark65 added、user martin1 added
它顯示日誌壓制被反覆執行 20 次以上，橫跨 9 天

如果我們當初「先重開機再說」，這份東西會永久消失，而且無法補救。

7. 第二條獨立的證據鏈

設備上的每日自動備份沒有加密，可以直接解析出每個時間點的帳號清單。這構成一條不依賴記憶體紀錄的獨立證據鏈。

最重要的發現是找到了入侵前的乾淨基準線：

節點	基準線備份時間	當時的帳號
`core-tnn1`	2026-06-13	只有 `admin`
`node-tnn1`	2026-04-05	只有 `admin`

這是「那些後門帳號全部不是我們自己建的」的客觀證據，不需要依賴任何人的記憶：這兩台上出現的 11 種後門帳號名稱，在基準線中都不存在；第 12 種 zkadmin 只出現在 lb-khh1，由攻擊者植入的排程自動建立。

兩條證據鏈交叉比對，完全沒有矛盾。

我們怎麼驗證這些結論

處置一旦執行，記憶體裡的證據和設備上的檔案就永久消失，沒有第二次機會。所以在動手之前，我們做了一輪對抗式驗證 —— 主動嘗試推翻自己已經寫下的結論，只留下經得起檢驗的部分。

我們用的標準是：這份取證要能直接交給執法單位。 每一項結論都要有獨立的依據，每一份證物都要能和設備上的原始資料逐位元對上。

這件事不是只做一次。修補與驗證期間，以及之後兩個月的複查，我們都用同樣的方式回頭核對結論與原始紀錄。

經覆核後確認成立的結論

下列結論在對抗式驗證後確認成立：

「7.23.4 / 7.24.2 修補不完全」成立
攻擊者身分與來源成立（使用的是不存在於乾淨基準線中的後門帳號，時間與我方動作完全不重疊）
C2 程式的惡意性成立（程式碼自證，不依賴任何外部情報）
反取證的責任歸屬反而被強化（有一個具名的後門帳號直接修改了日誌規則）
流量側錄基本排除（見關於流量是否被側錄）

意外發現：資料平台的認證缺口

這一段嚴格來說不屬於這次入侵造成的損害，但它是這次事件調查的直接產物，而且風險比入侵本身更立即。我們認為必須一併公開。

怎麼發現的

在追查「攻擊者有沒有可能從路由器讀取內網服務資料」時，我們從網際網路直接對各服務埠實測。

結果發現的東西跟路由器無關 —— 有兩台資料平台主機把叢集協調服務直接開放在網際網路上，而且完全沒有認證。

發現的內容

項目	狀態（09/19 發現當時）
etcd（叢集協調服務）`2379`	兩台主機對全網開放，`GET /v2/keys/` 直接回 200
etcd 寫入	未認證即可 `PUT`
Patroni（資料庫高可用管理）REST `8008`	未認證，`POST /config`、`/switchover`、`/restart` 全部開放
etcd 版本	3.5.17 —— 含已知的認證繞過 CVE

處置與驗證

09/19 當天完成修補。以下是修補後從外部實測的結果：

測試	修補前	修補後
etcd v2 `GET /v2/keys/`	`200`	`401`
etcd v2 `PUT /v2/keys/…`	`200`	`401`
etcd v3 `POST /v3/kv/range`	正常回應	`etcdserver: user name is empty`
Patroni `DELETE /switchover`	`200`	`401`
Patroni `GET /health`（健康探測）	`200`	`200`（刻意保留）
etcd 版本	`3.5.17`	`3.5.32`

為什麼會這樣

跟路由器那件事是同一個根因的不同表現：

路由器：管理介面對全世界開放，因為「它一直好好的」
資料平台：叢集協調服務對全世界開放，因為「它在內網」

→ 兩者都沒有人真的從外部驗證過「它到底有沒有對外」

處置

為什麼「升級 + 改密碼」完全不夠

這是最常見的誤解，也是我們必須說清楚的一點：

後門所在	升級能清除？	改密碼能清除？
25 個最高權限後門帳號（12 種名稱）	不能	不能，帳號還在，只是密碼被改
C2 程式（腳本 + 排程）	不能	不能
每日自動重建的後門帳號	不能	不能，改密碼也會被腳本覆寫
注入的 SSH 金鑰	不能	不能，金鑰登入完全繞過密碼
SOCKS 代理	不能	不能
被破壞的日誌設定	不能	不能
已洩漏的憑證與私鑰	不能	不能，必須輪換
C2 可重新投放	不能，只要連得到就能重裝	不能

清理順序有硬性約束

這不是可以隨便排的：

錯誤的順序	正確的順序
先刪後門帳號 → 隔天凌晨 03:00 自動重建，白做	先移除排程 → 再移除腳本 → 然後才刪帳號
先重開機 → C2 程式自動復活，記憶體證據全毀	先移除 C2 的腳本與排程 → 才能重開機
先換密碼再升級 → 漏洞還在，改了也能再被繞過	先升級切斷漏洞 → 再輪換憑證

完成進度

項目	狀態	驗證方式
全程唯讀取證，未重開機、未清理	完成	記憶體證據完整保全
全部證物 SHA256 ＋證據保管鏈	完成	1000 份以上證據檔
四台升級至 7.24.4 ＋ RouterBOOT 韌體	完成	版本與韌體皆實測確認；之後由自動更新升到 7.24.5、7.25、7.25.1
移除全部後門帳號與持久化機制	完成	四台帳號各剩 1 個（僅 `admin`）；排程／腳本建立者全為 `admin`
移除注入的 SSH 公鑰	完成	四台 SSH 公鑰數皆為 0
關閉 SOCKS、bandwidth-server	完成	四台皆 `enabled=no`
輪換四台管理密碼	完成	舊密碼實測已失效
重建 VPN PKI（4 組新 CA ＋伺服器憑證）	完成	舊 CA 簽發的憑證全部失效
輪換 9 把 WireGuard 私鑰	完成	雙端同步，隧道握手正常
重新產生四台 SSH 主機金鑰	完成	升級後重新產生，舊主機金鑰作廢
SSH 管理介面限制來源白名單	完成	外部暴力破解量歸零（見前面）
日誌強化（磁碟落地＋ 65535 筆）	完成	磁碟日誌實際捕捉到再入侵嘗試
每週自動更新排程	完成	四台錯開時段；10–11 月已自動完成 3 次升級
移除受污染的備份與調查產物	完成	46 個檔案，並建立乾淨基準備份
資料平台認證缺口修補	完成	外部實測 401（見上一節）
重新入侵比對	完成	09/20、09/21、11/15 三次，四台皆無新跡象
剩餘節點檢查	未完成	5 台中已檢查 2 台，見還沒查完的部分

必須輪換的清單

#	項目	狀態
1	全部 VPN 帳號密碼（其中確認有一組帳號在兩台設備間重用了完全相同的密碼）	完成
2	全部 9 把 WireGuard 私鑰	完成
3	VPN CA 與客戶端憑證（重簽並撤銷舊的）	完成
4	四台全部管理帳號密碼	完成
5	四台全部 SSH 主機金鑰	完成
6	內網主機的服務認證資訊	部分完成

根本原因：我們哪裡做錯了

漏洞是廠商的，但被打進來 16 天沒發現，是我們的問題。

直接原因

四台設備版本落後於安全性修補（3 到 6 個月）
        +
SSH 管理介面對公網開放，且不限制來源 IP
        ↓
攻擊者不需要密碼就取得完整管理權限

為什麼會拖 16 天

#	問題	說明
1	沒有集中式日誌	日誌只存在設備本機，攻擊者一改設定證據就歸零。本案 80% 的證據缺口來自這一項
2	沒有設定變更告警	新增 25 個（12 種名稱）最高權限帳號、植入腳本與排程、修改日誌設定 —— 沒有任何一項觸發通知
3	沒有出向流量監控	一台設備每 3 分鐘對荷蘭的 IP 發 HTTP 請求，連續 3 天、1536 次，沒被發現
4	管理介面直接暴露於公網	設備上明明就有來源白名單機制，只是沒用在管理介面上
5	版本落後 3 到 6 個月	漏洞公告後 15 天仍未升級
6	沒有定期稽核	帳號清單、腳本、排程從來沒有定期比對過
7	過度信任內建偵測	「入侵旗標顯示正常」讓人安心，但它只比對已知指標
8	從未從外部驗證過暴露面	我們以為在內網的服務，實際上對全世界開放（見資料平台那一節）

五個為什麼

為什麼設備被完整接管？

因為六個 CVE 全部未修補，而 SSH 對公網無限制開放。
為什麼 CVE 未修補？

因為沒有版本追蹤機制 —— 沒有人知道「我們的設備落後幾版」。
為什麼沒有版本追蹤機制？

因為網路設備被當成「裝好就不用管」的基礎設施，不像應用服務有 CI/CD 與相依套件掃描在盯。
為什麼入侵持續 16 天沒被發現？

因為日誌只存在設備本機，且沒有任何設定變更或出向流量的告警。
為什麼沒有集中式日誌？

因為過去從沒發生過事故，沒有動機去建。

我們已經改的事

#	項目	為什麼	狀態
1	管理介面全面下架	只允許白名單與 VPN 來源。路由器本身於 09/19 完成；轉發到內網主機的 SSH 等服務則到 10/29 才補上白名單（見後續追蹤）	完成
2	啟用自動更新	本案的修補在攻擊前 12 天就存在 —— 自動更新原本就能擋下	完成
3	關閉不必要的服務	包含這次的攻擊面之一 bandwidth-server	完成
4	每台設備獨立的金鑰	不再用還原備份的方式複製設備設定	完成

我們特別檢查了這一點，因為它是最便宜的防線：

事件	日期
MikroTik 釋出修補	2026-09-03
攻擊者部署 C2	2026-09-15
修補可取得的時間差	12 天

只要有任何形式的自動更新（即使是每週一次），這次攻擊在 C2 植入前就會被擋下。

四台現已設定每週自動檢查並安裝更新，且時段錯開，避免同時重開機造成服務全斷。10 月到 11 月間已實際自動完成三次升級（7.24.5、7.25、7.25.1）。

還沒查完的部分

誠實列出來，因為這些會影響結論的完整性。

與路由器相連的主機

透過隧道與四台路由器相連的 2 台 Linux 主機都已檢查，結果乾淨。

主機	狀態	結果
郵件 / WireGuard 對端主機（加拿大）	已檢查	帳號、`sudoers`、`sshd_config`、cron 皆未變動；`authorized_keys` 乾淨
WireGuard 對端主機（新加坡）	已檢查	同上

東京、大阪、台北三台是 VPS，沒有 RouterOS，不受這次的漏洞影響。

技術上無法補救的限制

#	限制	影響
L-01	日誌已被破壞	無法取得攻擊過程本身的證據。初始入侵途徑是研判，不是確證
L-02	檔案系統層的植入無法檢查	這類植入無法透過一般指令觀察，需要離線磁碟鑑識
L-03	韌體層無法驗證	若植入在韌體層，設備自己的所有輸出都不可信
L-04	C2 是否曾成功下發指令無從查證	程式執行後立刻刪檔，沒有殘留

重刷（netinstall）方面：RouterOS 7.24beta1 起可以由另一台 RouterOS 遠端重刷，但兩台必須在同一個二層網段；我們四台實測不共用任何二層網段，所以重刷只能到場進行。

我們無法排除的一件事

給其他維運者的 10 條具體建議

如果你也在跑 MikroTik，或更廣義地說，在跑任何「裝好就不太管」的網路設備，以下是我們用這次事件換來的東西。

如果你懷疑自己也被打了，先跑這幾項

列出帳號清單 —— 有沒有你不認識的名字？

特別注意：ops / saryn / SystemMikrotik / routeradmin / system / operator
列出排程與腳本 —— 看「建立者」欄位，不要看名字

建立者是 0（而非 admin）＋名字很像維運工作 = 高度可疑
列出使用者的 SSH 公鑰 —— 合法帳號上有沒有你沒掛過的金鑰？

這是最隱蔽的一種後門，稽核帳號清單看不到
檢查日誌設定 —— 記憶體上限是不是被改小了？日誌規則是不是被停用？

如果只剩 1 筆日誌，那本身就是入侵指標
檢查 SOCKS 代理是否被開啟
讀「設定變更歷史」 —— 它在記憶體裡，重開機就沒了，所以先讀它

十條建議

#	建議	我們為什麼這樣說
1	不要先重開機	設定變更歷史只在記憶體。我們的整條時間軸都靠它。而且 C2 設定了開機自動啟動，重開機只會讓它復活
2	修補版本以原始通報者為準，不要相信漏洞資料庫	四個來源中只有 CERT Polska 寫出「7.23.4 修補不完全」。連原廠公告頁都沒寫
3	看建立者，不要看名字	`daily-maint`、`logrotate` 比我們自己寫的排程還像正常維運工作
4	「管理密碼突然失效」是入侵指標	掛上 SSH 金鑰會讓密碼登入被拒。我們一開始以為是自己記錯憑證
5	不要信任設備的內建入侵旗標	我們四台全部顯示正常，四台全部確認被入侵
6	不要只比對公開 IoC 清單	我們找到的 C2 不在任何公開清單上；公開清單上的兩個 IP 我們完全沒遇到
7	日誌必須離開設備	這是最高價值的一項。本案 80% 的證據缺口來自這一點
8	記憶體日誌不夠，要有磁碟日誌	我們捕捉到的兩次再入侵嘗試，在 15 分鐘內就被擠出記憶體緩衝區。靠磁碟日誌才留下來
9	升級先於改密碼	漏洞還在的話，改密碼也能被繞過
10	清理順序：排程 → 腳本 → 帳號	反過來做，帳號隔天就會被腳本重建

兩個容易誤判的技術細節

後續追蹤

事件處置完成之後，我們持續檢查並收緊防護。以下是到 2026/11/15 為止的進展。

沒有再入侵

日期	檢查	結果
09/20、09/21	完整健康檢查，並與乾淨基準比對	四台皆無新跡象
11/15	同上，並把四台設定與最後一次授權變更後的快照逐行比對	0 處差異；已知的 9 項入侵特徵與漏洞利用嘗試皆為 0；日誌中每一筆設定變更與登入，都能對應到我們自己的操作或自動排程

自動更新確實在運作

本文提到的每週自動更新，在 10 月到 11 月間已自動完成三次升級。四台錯開時段，沒有同時中斷。

已恢復 10/05–10/08
自動升級至 7.24.5
已恢復 10/26–10/29
自動升級至 7.25
已恢復 11/04–11/10
自動升級至 7.25.1

之後補上的防護

日期	內容
10/09	統一四台的 DNS 與校時：區網裝置的 DNS 查詢一律導向路由器，由路由器經加密 DNS（DoH）向上游查詢；校時統一由路由器提供。過程中發現其中一台的 DNS 攔截被另一條路由設定打壞而失效，已修正
10/11	VPN 使用者的 DNS 也強制導向路由器；清除四台上未使用的撥號與 VPN 範本設定（其中包含指向第三方 DNS 的設定）
10/29	從網際網路實際掃描四台的對外埠：轉發到內網主機的 10 個 SSH 埠與一個內部 AI 服務沒有來源限制，當日補上白名單並從白名單內外各驗證一次；經雲端主機轉入的流量也改為只放行服務需要的埠
10/31	修正 VPN 用戶端設定 `auth-nocache` 造成的每小時斷線：RouterOS 每小時重新協商金鑰時要再送一次帳密，而這個選項讓用戶端登入後就丟掉密碼。已從用戶端設定檔移除
11/05	盤點 IPv6：路由器底下的設備沒有任何 IPv6 對外路徑，白名單不會被 IPv6 繞過

為什麼有些細節沒寫出來

這篇是公開版本。內部的完整取證報告含有明文密碼、私鑰、設備序號與內網拓樸，不會公開。

本文的處理原則：

類別	處理
我方設備的公網 IP、序號、金鑰指紋、內網位址與拓樸	移除，改以節點代號與地區表示
VPN 帳密、私鑰、憑證內容	只描述數量與型別，不列值
資料平台的主機位址、資料庫帳號密碼	移除
攻擊者的 C2 位址、來源 IP、後門帳號名稱、惡意程式檔名、持久化手法、注入金鑰指紋	完整揭露 —— 這些對其他防守方有價值

完整取證資料（1000 份以上的證據檔、全案 SHA256 清單、證據保管鏈、驗證紀錄）保存於 private 證據庫。

結語

首先向所有受影響的使用者致歉。 DPIP 是一個防災服務，服務的穩定與可信度直接關係到它存在的意義。這次事件是我們在基礎設施維運上的疏失，沒有推託的餘地。

三件我們認為必須講出來的事：

修補在攻擊者植入 C2 的 12 天前就已經釋出。

這不是零時差攻擊。任何形式的自動更新 —— 即使是每週跑一次 —— 都能擋下這次攻擊。我們沒有做，因為網路設備被當成「裝好就不用管」的東西。這是最便宜的防線，而我們沒有架。
我們差一點就毀掉自己的證據。

「先重開機再說」是最自然的反應。如果當初那樣做，唯一能證明「誰在何時建立了哪個後門帳號」的紀錄會永久消失，而且 C2 程式會因為開機自動啟動的設定而復活。取證優先於復原，這個判斷事後證明是對的。
那個叫 ops 的後門帳號在設備上躺了 16 天。

它是官方公告直接點名的入侵指標，只要跑一個指令列出帳號清單就看得到。我們沒有跑，因為沒有人覺得需要去看一台「一直好好的」路由器。

發布紀錄

本文於 2026/11/15 發布。事件當天（09/18）我們先以公告發布摘要。

參考資料

CERT Polska — Vulnerabilities in MikroTik RouterOS software（原始通報者，修補版本以此為準）
BleepingComputer — Hackers exploit new MikroTik RouterOS flaws to hijack routers
Triskele Labs — Critical MikroTik RouterOS Vulnerabilities under Active Exploitation (MikroTrick)
MikroTik Security Advisories
CISA Known Exploited Vulnerabilities Catalog

同一場地震，為什麼會算出兩個不同的震度？

Wed, 29 Jul 2026 00:00:00 GMT

2026 年 7 月 28 日，日本熊本縣熊本地方發生規模 7.1 的地震，日本氣象廳命名為「令和 8 年熊本地震」。震源在內陸、深度約 16 公里，研判為日奈久斷層帶錯動，最大震度 7（宇城市、氷川町）。日本的強震觀測網記錄下 125 個測站的完整波形，資料完全公開。

我拿其中一站的紀錄，用兩種常見的處理方式各算了一次最大地動速度——這是決定震度的關鍵數字。結果是：

98.92 和 130.83。差了三成。

同一筆資料、同一個公式、同一台電腦。差別只在中間有一個步驟，做法不同。

哪一個才對？我原本以為查一下規定就有答案。結果發現，規定寫到頻率範圍就停了，剩下的得自己往別處找線索。

這篇記錄整個查證過程。沒有程式碼，但有 16 張圖。

先講結論

問題	答案
為什麼會差三成？	中間那個步驟會把不同頻率的波錯開不同的時間，而「最大值」對這件事極度敏感
哪一個比較接近真實地動？	差三成的那個（130.83）比較忠實，但它的波形裡有物理上不可能發生的東西
那台灣的震度該用哪個？	用 98.92 那個。理由不是「它比較準」，而是台灣的震度公式當初就是這樣校準的
法規怎麼規定？	規定了「濾掉哪個頻率範圍」，濾波方式則屬於實作層面

一、地震儀錄到的東西，不能直接拿來用

地震儀記錄的是加速度——地面每一瞬間被搖動的劇烈程度。以這場地震離震央最近的測站之一為例：

圖 16　一個測站錄到的三個方向加速度，每秒 100 個取樣點、共 300 秒

地震儀有三個方向：南北、東西、上下。每秒取樣 100 次，這段紀錄有 300 秒、三萬個點。

但這串數字不能直接用，有兩個原因：

裡面有雜訊。 車輛、風、儀器本身的電子雜訊，都混在裡面。
要算「速度」得先積分，而積分會失控。 加速度累加成速度時，只要原始資料有一點點微小的偏差，累加幾萬次之後就會漂移到天上去。

所以要濾波——把不需要的頻率成分濾掉。可以想成一個篩子：太高頻的（雜訊）篩掉，太低頻的（漂移）也篩掉，留下地震真正的能量。

聽起來很單純。問題出在篩子有兩種做法。

二、兩種濾波：現場直播 vs 錄影後製

做法 A：只能看過去（因果）

直播式

處理到第 100 個資料點時，只准使用第 1 到第 100 點。不准偷看後面。

這就像現場直播——主播只能根據已經發生的事情反應，不可能知道三秒後會發生什麼。

地震預警系統只能這樣做。地震還在發生，未來的資料根本還不存在。

做法 B：可以看未來（零相位）

後製式

先把整段錄完，再從頭到尾濾一次、然後反過來從尾到頭再濾一次。第二次等於用到了「未來」的資料。

這就像錄影後製——整集拍完了，剪接師可以先看完再回頭調整任何一格。

圖 1　同一個脈衝，兩種濾波的反應完全不同

圖 1 是把一個「瞬間敲擊」丟進兩種濾波器看反應。上圖（直播式）敲下去之後才有反應，很合理。下圖（後製式）敲擊還沒發生，就已經有反應了——因為它用到了未來的資料。

為什麼不能兩全其美？

有人會問：那能不能做一個「只看過去、又完全不扭曲」的濾波器？

對這裡用的這一類濾波器來說，不行。

規格用的是遞迴式濾波器

台灣和日本的規格用的都是遞迴式濾波器：少數幾個係數反覆套用、計算極省，適合即時。
只能看過去，就受一條硬性限制

只要一個遞迴式濾波器是「只能看過去」的，它的扭曲程度就被它的篩選效果決定了，沒得選。
完全不扭曲，就等於什麼都不做

唯一完全不扭曲的「只看過去」遞迴濾波器，是「什麼都不做」。只要你真的想篩掉什麼，就一定會產生扭曲。

圖 2　兩種做法篩掉的東西差不多（左），但扭曲程度天差地別（右）

圖 2 左邊是「篩掉了多少」——兩種做法差不多。右邊是「扭曲了多少」——直播式（藍線）扭曲很大，後製式（橘線）是一條零。

這就是全部的差別。 篩選效果一樣，扭曲不一樣。

三、扭曲一下，最大值為什麼會差三成？

關鍵：不同頻率被延後不同的時間

「扭曲」具體是什麼意思？我實際量了一下：拿標準的正弦波餵進濾波器，看它出來時被移動了多少時間。

圖 3　直播式濾波把不同頻率的波移動了不同的時間

波的頻率	被移動
每 10 秒振動一次	−3.43 秒
每 5 秒振動一次	−0.75 秒
每 2 秒振動一次	−0.09 秒
每秒振動 1 次	幾乎不動
每秒振動 2 次	+0.03 秒

地震波的能量主要就落在這個範圍。同一段波形裡，慢的成分和快的成分被錯開了 3.5 秒。

最大值是「大家同時用力」的結果

這才是重點。地動的最大值不是某一個頻率造成的，而是很多不同頻率的波，剛好在某一瞬間同時到達波峰、疊加起來的結果。

像一群人推車：大家同時用力，車就衝出去；錯開幾秒各推各的，車就只是晃兩下。

圖 4　成分完全沒變，只是錯開時間，最大值就掉了三成

圖 4 上半是四個頻率的波同時到達波峰，疊出 3.20 的高峰。下半是同樣那四個波，只是照圖 3 的量錯開時間——最大值掉到 2.18。

這裡我只是把四個波在時間上平移，沒有削掉任何成分——所以能量一點都沒少，純粹是不同步造成的。

決定性的實驗

上面是示意圖。要證明差異純粹來自「錯開時間」而不是「篩掉了東西」，得做一個更乾淨的實驗。

我用完全相同的濾波器跑了兩次，唯一的差別是第二次把「扭曲」那部分拿掉——篩掉的東西一模一樣，只有時間對齊不同。

圖 5　決定性實驗：總能量完全相同，最大值差 33%

同一段速度波形	有扭曲（直播式）	無扭曲（後製式）	比值
總能量	7.7444	7.7443	1.0000
最大值	98.919	131.923	1.3336

總能量到小數第三位完全相同（7.744），最大值差 33%。

上面的結果不代表「濾波不會改變能量」。濾波當然會改變能量——高通、低通、帶通只要把某個頻段削掉，總能量、平均振動強度、最大值、積分結果全都會跟著變。那本來就是濾波的目的。

這個實驗成立的前提是：兩次處理篩掉的東西完全一樣，只有時間對齊不同。在這個前提下，總能量不變是有數學保證的——因為總能量只取決於「每個頻率剩下多少振幅」，跟「這些成分在時間上怎麼排列」無關。

在篩選效果相同的兩種濾波之間比較時，時間錯位會大幅改變瞬時的最大值，但不會改變各頻率的能量分布。而震度量的，就是「最集中的那一瞬間」。

所以這個實驗證明的是：直播式與後製式在最大值上的落差，主要來自時間錯位，而不是因為其中一方多濾掉了什麼。它並沒有、也不能證明「濾波不影響能量」。

四、那後製版比較準嗎？

先講它的副作用，這個副作用很嚴重。

圖 6　後製版的代價：地震波還沒到，地面就先動了

右圖放大了 P 波（地震最先到達的波）抵達之前的那幾秒。藍線（直播式）貼著零——地震還沒到，地面本來就不該動。橘線（後製式）卻已經開始晃了。

這個現象叫前振鈴。原因就是「用到未來資料」：處理第 100 個點的時候偷看了第 150 點，於是後面的地震波「洩漏」到了前面。

從「這段波形有可能真的發生嗎」來看，後製版產生了物理上不可能的東西——因還沒發生，果就先出現了。

那後製版有什麼好？它沒有把不同頻率的成分錯開。 所以論「最大值有沒有被打散」，後製版比較忠實——最大值留在原本該有的時間點與大小。

兩邊各有代價

所以這件事沒有單一的正確答案。關鍵是兩種做法各自破壞了不同的東西：

你在意的事	該用	但要付的代價
地面真正晃了多大（最大值不被打散）	後製式（零相位）	波形出現物理上不可能的前振鈴
波形不要出現「因還沒到、果就先到」	直播式（因果）	各頻率成分之間的相對時間被錯開
即時預警（未來的資料根本還不存在）	只能用直播式	同上

講白一點：

後製式保住了「各成分的時間關係」，犧牲了「因果順序」。
直播式保住了「因果順序」，犧牲了「各成分的時間關係」。

五、125 個測站告訴我們什麼

一個測站看不出全貌。我把這場地震全部 125 個測站都算了兩遍。

圖 7　125 個測站：直播式造成的是亂跳，不是固定偏低

圖 8　最大速度的離散程度約 ±11%，最大加速度相對集中

如果直播式濾波「總是低估」，那所有的點應該落在同一側。實際上是 73 站偏低、52 站偏高，幾乎對半。

統計（後製 ÷ 直播）	中位數	範圍
最大速度	1.020	0.75 ~ 1.41
最大加速度	0.992	0.82 ~ 1.05

再做一次控制實驗，把「篩得多寡」的因素也扣掉，只留純粹的時間錯位效應——中位數 1.010、68 站偏低、57 站偏高。

結論：直播式濾波造成的不是系統性低估，而是站站不同、無法預測的亂跳。

六、那規定是怎麼寫的？

我原本以為這題早就有標準答案，翻一下文件就好。

台灣震度的法定依據是《交通部中央氣象署有感地震報告發布作業要點》的附表〈地震震度分級表〉註2。它把震度的計算寫成九個步驟，其中跟濾波有關的是這兩句：

資料進行 10Hz 低通濾波處理，適度過濾瞬間振動的高頻訊號。

將 3 向量原始加速度資料積分至速度，同時進行 0.075Hz 低切濾波移除因積分動作所引進的低頻訊號。

規定寫到「濾掉哪個頻率範圍」為止。 至於用哪一種濾波方式，就落在實作層面了。

這在技術規範裡其實很常見——法規通常界定「要達到什麼結果」，不會把每個實作細節都寫死。留白的部分，就交給慣例和專業判斷。

所以「該用直播式還是後製式」這一題，得往別的地方找線索。

線索在當初訂出震度公式的論文裡

台灣震度公式的兩個係數出自吳逸民教授團隊。翻他們的系列論文：

論文	寫了什麼
Wu & Kanamori (2005)	對台灣的強震記錄用的是「遞迴式」濾波器——遞迴就是只看過去的意思——而且同一篇論文裡就引用了台灣的震度公式。
Wu 等人 (2007)	更直接寫出「單向（one-way）」濾波器。
Wu、蕭乃祺與鄧大量 (2004)	這篇是氣象署官方引用的公式出處。寫著氣象局用的是「時域遞迴濾波器，基本上是即時運作的」。

最後這點是關鍵：氣象署要在地震發生後幾十秒內發布各縣市震度，強震即時警報更是以秒計。即時系統不可能取用未來的資料。

國際上的做法不太一樣

換到國際強震資料的處理慣例，答案反而是相反的：

來源	立場
國際強震資料處理準則（COSMOS, 2004）	「一般情況下應使用非因果（後製式）濾波器……若使用因果濾波器（例如即時應用），務必明確載明。」
Boore & Akkar (2003)	也推薦後製式。理由是「直播式的結果對參數選擇太敏感」，不是「最大值比較準」。
反方向的研究	有學者發現，條件相同時，兩種做法算出來的地震工程用參數「在統計上無法區分」。需要精確時間關係的應用（例如定位震央），直播式反而是首選。

會有這種分歧，是因為兩邊要的東西不一樣：國際強震資料庫的用途是給工程師做結構分析，追求波形忠實；而震度是要即時發布的公共資訊，追求的是能不能算得出來、以及跟過去的紀錄可不可比。

那到底該用哪個？

回到最實際的問題：如果你要算的是能跟氣象署發布值對照的震度，那就用直播式。

七、三種算法並列

查清楚之後，我讓計算同時輸出三組數字，方便交叉比對。

圖 9　三條處理流程：差別只在中間兩格，前後步驟完全相同

圖 10　最大加速度差在「篩掉多少高頻」，最大速度差在「有沒有扭曲」

三種比較	最大加速度中位	最大速度中位	最大速度離散程度
後製 ÷ 直播	0.992	1.020	0.111
日本規格 ÷ 直播	1.022	1.030	0.113
日本規格 ÷ 後製	1.032	1.008	0.047

最後一列是重點：日本規格和後製式的最大速度只差 0.8%，是三組比較裡最接近的——因為兩者都是後製式，只差在篩掉的頻率範圍略有不同。而任一者跟直播式比，離散程度都在 ±11% 上下（個別測站最多可差到 −25% ~ +41%）。

差異主要來自「有沒有扭曲」，不是來自「篩掉多少」。

八、順便解開日本沒公開的一個謎

日本防災科學技術研究所（NIED）公布了他們計算最大速度用的濾波器參數，但沒說是直播式還是後製式。

那就用數字反推。他們公布的其中一個測站，官方最大速度是 131.2。我照他們的規格算兩次：

圖 11　官方沒說，但數字只容許一個答案

做法	算出來	與官方差距
後製式	131.71	+0.39%
直播式	93.43	−28.8%

日本用的是後製式。 這跟他們引用的那篇 1978 年濾波器設計論文在日本實務上的慣用方式也吻合。

那剩下的 0.39% 呢？我掃了一輪參數：

掃的參數	對結果的影響
濾波器的「強度」	0.35%
「切在哪個頻率」	3.9%

強度幾乎不影響結果，切點影響很大。所以那 0.39% 來自我推算的切點跟他們實際用的差了一點點，不是理解錯誤。

完整對照官方公布值

項目	NIED 官方公布	本文算出	差異
資料起點時刻	2026/07/28 16:27:04	16:27:04	一致
測站經緯度	32.5099 / 130.5908	32.5099 / 130.5908	一致
最大加速度	482.7	482.70	−0.00%
最大速度	131.2	131.71	+0.39%
日本計測震度	5.7	5.7	一致

除了那 0.39%，其他全部對上。

九、日本的算法濾波器更多，震度卻更高？

順帶破解一個直覺誤區。

日本氣象廳算震度用了三個濾波器，台灣只用兩個。直覺上「濾得越多、剩下越少、震度應該越低」——但實際上同一場地震，日本算出來的震度常常比台灣高。

圖 13　日本的第三個濾波器其實是放大器

原因在圖 13 的粉紅線：日本的第三個濾波器不是拿來篩東西的，是拿來放大長週期成分的。三個相乘之後，在「每 1 ~ 2.5 秒振動一次」這個頻帶，總增益大於 1——也就是放大，尖峰落在每 1.6 秒振動一次，增益約 1.17 倍。

而大地震的能量正好集中在長週期帶。所以「濾波器比較多」反而讓震度變高。

十、台灣震度的定義，其實是一張表不是公式

這是查證過程中另一個意外。

大家常看到的台灣震度公式，其實不是法定定義。法定文件裡只有一張對照表——官方說明白，那張表是把公式算出來的數字「四捨五入並稍做微調方便記憶」之後劃定的。

問題是「稍做微調」在某些地方微調得不少：

圖 12　加速度那張表兩者等價，速度那張表不是

對照表	和公式差多少
加速度	所有界線吻合到 ±0.013 個震度單位，可以當成等價
速度	最大偏差 0.106，是加速度表的八倍

要跟法定分級表一致，就得查表，不能直接套公式。

十一、資料裡藏的時間陷阱

最後一個，是關於資料本身的。

日本強震網的公開檔案裡有個時間欄位。直覺上會以為那是「這筆資料從幾點幾分幾秒開始」，但其實它是儀器被觸發的時刻，而檔案裡的資料是從觸發前 15 秒開始的。

直接拿那個時間當起點，所有時間戳記會晚 15 秒。

我沒有直接相信文件，用地震波的走時做了驗證：

圖 15　兩張圖合起來只有一種解釋

左圖：初動出現在檔案的第幾秒

地震初動出現在每個檔案的第幾秒？中位數 14.39 秒，而且跟測站遠近完全無關。這是一段固定長度的「事前緩衝」。
右圖：時間欄位減去發震時刻

差值隨著測站距離線性增加，換算出來的速度是每秒 5.24 公里——正好是 P 波在地殼裡的速度。這個欄位跟著地震波跑，是觸發時刻，不是資料起點。
兩張圖合起來，只有一種解釋

後來在 NIED 的〈K-NET ASCII 格式說明〉找到白紙黑字：「この時刻はトリガー収録を開始した時刻を表しており、公開データはトリガーの 15 秒前からのデータを含んでいます」「データ先頭の時刻はこの時刻から 15 秒を引いてください」。

十二、這場地震的結果

圖 14　125 個測站換算成台灣震度標準的分布

把 125 個測站的紀錄全部換算成台灣的震度標準，分布如上。震央附近的熊本測站群最高達 6 強，隨距離往外遞減到 3 級、2 級。

給讀者的重點

如果你只想記三件事：

「最大值」比你想的脆弱。 同一筆資料、在篩掉的東西完全相同的前提下，只要把不同頻率的波錯開幾秒，最大值就可以差三成。所以看到不同單位公布的地震參數對不起來，未必有誰算錯，可能只是處理方式不同。
震度是一套「約定」，不只是一個物理量。 台灣的震度公式是用特定的處理方式校準出來的。換一種處理方式，數字也許更接近真實地動，但反而偏離了震度的定義。所以「哪個比較準」跟「哪個該用」是兩個不同的問題。
規範不會寫到每個細節。 台灣的法規寫到頻率範圍為止，濾波方式屬於實作層面；日本則沒有公開濾波的相位特性。這很正常——但也意味著想算得跟官方一致，只能把一手文件從頭讀過，必要時用數字反推。

參考資料

官方文件

台灣

交通部中央氣象署，《有感地震報告發布作業要點》附表〈地震震度分級表〉註2/註3/註4。最新修正：中華民國112年10月16日中象地字第1120051308號函；震度分級表自 109/1/1 施行。
交通部中央氣象局，《震度新分級應變更實用》新聞稿，2019-12-18。
蕭乃祺，《我國新地震震度分級制度》，中央氣象局地震測報中心。
中央氣象署，《小區域有感地震報告資料說明 E-A0016-001》。

日本

平成八年二月十五日気象庁告示第四号（計測震度的法定定義）。全文引用於：気象庁，《「震度に関する検討会」報告書》参考5。
気象庁，計測震度の算出方法。
気象庁地震火山部，《緊急地震速報の概要や処理手法に関する技術的参考資料》令和6年4月11日。
気象庁，長周期地震動の絶対速度応答最大値の計算方法（長周期地震動に関する情報検討会第4回別添資料3）。
気象庁，長周期地震動階級について。
気象庁，速度波形・変位波形の求め方。
防災科学技術研究所，K-NET・KiK-net 質問集（最大加速度與最大速度的計算方法、記錄開始時刻、發震時刻的精度）。
防災科学技術研究所，K-NET ASCII フォーマットについて。

國際

Shakal, A., Boore, D. M., Chiou, B., Iwan, W. D., O’Connell, D. R. H., & Stepp, J. C. (2004). COSMOS Summary Guidelines and Recommendations for Strong-Motion Records Processing. COSMOS Newsletter 11: 3–5.
USGS National Strong-Motion Project — Data Processing。

學術論文

台灣震度公式的來源

Wu, Y.-M., Teng, T.-L., Shin, T.-C., & Hsiao, N.-C. (2003). Relationship between Peak Ground Acceleration, Peak Ground Velocity, and Intensity in Taiwan. Bulletin of the Seismological Society of America, 93(1), 386–396. doi:10.1785/0120020097
Wu, Y.-M., Hsiao, N.-C., & Teng, T.-L. (2004). Relationships between Strong Ground Motion Peak Values and Seismic Loss during the 1999 Chi-Chi, Taiwan Earthquake. Natural Hazards, 32, 357–373.
Wu, Y.-M., & Kanamori, H. (2005). Rapid Assessment of Damage Potential of Earthquakes in Taiwan from the Beginning of P Waves. BSSA, 95(3), 1181–1185.
Wu, Y.-M., Kanamori, H., Allen, R. M., & Hauksson, E. (2007). Determination of earthquake early warning parameters, τc and Pd, for southern California. Geophysical Journal International, 170(2), 711–717.
Yang, B. M., Mittal, H., & Wu, Y.-M. (2021). Real-Time Production of PGA, PGV, Intensity, and Sa Shakemaps Using Dense MEMS-Based Sensors in Taiwan. Sensors, 21(3), 943.
徐明同（1979）。《地震學》。黎明文化，pp. 16–26。

兩種濾波方式的比較

Boore, D. M., & Akkar, S. (2003). Effect of causal and acausal filters on elastic and inelastic response spectra. Earthquake Engineering & Structural Dynamics, 32(11), 1729–1748. doi:10.1002/eqe.299
Boore, D. M., & Bommer, J. J. (2005). Processing of strong-motion accelerograms: needs, options and consequences. Soil Dynamics and Earthquake Engineering, 25, 93–115.
Ancheta, T. D., et al. (2014). NGA-West2 Database. Earthquake Spectra, 30(3), 989–1005.
Chiou, B., Darragh, R., Gregor, N., & Silva, W. NGA Project Strong-Motion Database. Earthquake Spectra.（引述 Bazzurro et al., 2004 的結論）

其他

Nigam, N. C., & Jennings, P. C. (1969). Calculation of response spectra from strong-motion earthquake records. BSSA, 59(2), 909–922.
Kunugi, T., Aoi, S., Nakamura, H., Fujiwara, H., & Morikawa, N. (2008). A Real-Time Processing of Seismic Intensity. 地震 2輯, 60(4), 243–252. doi:10.4294/zisin.60.243
功刀卓ほか（2013）。震度のリアルタイム演算に用いられる近似フィルタの改良。地震 2輯, 65, 223–230。
斎藤正徳（1978）。漸化式デジタル・フィルターの自動設計。物理探鉱, 31(4), 240–263。

沒能查到的部分

誠實說明幾個查不到的環節：

Kanamori、Maechling 與 Hauksson (1999)，BSSA 89, 311–316——這篇是氣象局速度計算的原始出處，很可能才是釘死當年做法的關鍵，但取不到全文。
徐明同（1979）《地震學》——加速度關係式的源頭，是中文教科書、沒有線上版本。整套台灣震度分級等於錨定在一份查不到的 1979 年迴歸上。
斎藤正徳（1978）原文——紙本日文期刊。若能取得，應該可以完全消掉第八節那 0.39% 的殘差。
大樣本的兩種濾波比較統計——目前找得到的公開比較只有 4 筆紀錄。本文的 125 站統計可能是手上最大的樣本。

資料來源

本文使用的地震紀錄全部來自日本防災科學技術研究所（NIED）的 K-NET 強震觀測網，公開資料。2026 年 7 月 28 日熊本 M7.1，125 個測站、每站三分量、每秒 100 個取樣點。

所有數字都可以從公開資料重現。文中引用的法規原文，是把 PDF 的文字全部抽出來逐字比對的結果，不是依賴搜尋摘要。

07/18 誤發緊急地震速報的原因分析

Sat, 18 Jul 2026 00:00:00 GMT

事件概述

嚴重程度：嚴重狀態：已結案

發生時間: 2026/07/18 08:29 (UTC+8) 左右
觸發條件: 服務重構測試過程中
問題描述: 誤發緊急地震速報
根本原因: NATS 權限管理不當，測試電文被廣播至生產環境

時間軸

時間 (UTC+8)

嚴重 2026/07/18 08:29
問題發生：誤發緊急地震速報
資訊 2026/07/18 08:30
確認問題並開始進行修復
警告 2026/07/18 08:31
執行緊急處理，阻斷問題電文

事件經過

07/18 早上進行 cwa-xml-go 的重構，目的是將 cwa-xml-go 與 cwa-eew-go 兩個服務合併（見下圖），以降低系統複雜度並減少處理延遲。

重構完成、進入測試時，測試用的電文意外洩漏至生產環境，最終誤發緊急地震速報。

其中 cwa-eew-go 負責轉發中央氣象署的強震即時警報。這次誤發的是 ExpTech 轉發流程送出的測試電文，不是中央氣象署發布的警報，也不是 ExpTech 自行發布的地震警報。

cwa-xml-go 與 cwa-eew-go 合併前後架構示意圖

根本原因分析

問題說明

共用同一組 NATS Supercluster： 測試機與生產環境共用同一組 NATS Supercluster
發布權限未受限制： 測試機可將電文推送至生產環境所訂閱的 subject
無法區分電文來源： 下游服務把測試電文視為正式電文處理
誤發緊急地震速報： 最終導致誤發緊急地震速報

解決方案

加強 NATS 權限管理： 限制測試機的發布權限，避免測試電文流入生產環境所訂閱的 subject
隔離測試與生產環境： 明確劃分測試與生產環境的訊息通道，防止跨環境的電文污染
全面盤點： 檢視其餘服務是否存在相同的權限風險，並一併修正

心得

這是一個相當低級的疏失。雖然此次事件間接驗證了異地雙活備援機制的可靠性，但也直接導致了誤發緊急地震速報。對於造成大家的不便，我們深感抱歉，並將以此為戒，加強環境隔離與權限控管。

不能忽略的 CVE-2025-66478 滿級漏洞 :(

Wed, 17 Dec 2025 00:00:00 GMT

事件概述

CVE-2025-66478 是影響 Next.js 的嚴重安全漏洞，來自 React Server Components (RSC) 協議的缺陷，可能導致伺服器被遠端執行腳本或指令。還好平常有使用 Docker 部署，大幅降低了損害。

嚴重程度：高狀態：已結案

發現時間: 2025/12/8
CVSS 評分: 10.0（Critical）
漏洞類型: 遠端程式碼執行（Remote Code Execution）
攻擊向量: 網路攻擊，無需身分驗證

心得與過程

一開始看到這個漏洞公告，還以為只是「又一個框架安全更新」，沒有特別在意。直到自己的 IP 被 Cloudflare 列入黑名單，才真正意識到事情不單純，背後很可能已經有人在主動嘗試攻擊。

最後只需要重新建置映像並重新部署，同時更新 Next.js 版本，就能把環境還原成乾淨狀態，算是有驚無險的一次經驗。

漏洞詳情

CVE-2025-66478 源於 React 的上游實作（CVE-2025-55182）。在特定條件下，攻擊者可以透過精心構造的請求，觸發伺服器端未預期的執行路徑，進而在伺服器上遠端執行腳本或指令。

漏洞成因

React Server Components (RSC) 協議缺陷
- RSC 協議在處理特定型態的請求時存在安全漏洞
- 攻擊者可以透過惡意請求繞過部分安全檢查
執行路徑控制
- 漏洞允許攻擊者影響伺服器端的程式碼執行流程
- 在某些情況下，可能繞過原本預期的安全防護機制

攻擊方式

實際觀察到的攻擊行為大致如下：

連線進來後，先偵測伺服器上已安裝的套件與環境
接著嘗試從遠端下載惡意腳本，並在伺服器上執行

目前實際遇到的腳本類型：

偽裝成 Nginx 的程式或服務
挖礦腳本
後門腳本（包含開機自動執行的腳本，持久性很強）
架設 VPN / Proxy 的腳本
PowerShell 腳本（針對 Windows 環境）

下方是其中一個惡意腳本的內容截圖（已對部分資訊進行遮蔽處理）：

惡意腳本截圖

參考資源

總結

CVE-2025-66478 是極為嚴重的安全漏洞（CVSS 10.0）。最壞的情況，甚至可能讓伺服器完全落入攻擊者手中。

這次之後，我會更重視伺服器的安全：

優先更新與安全性相關的套件與框架版本
持續關注 CVE 與官方安全公告
部署時盡量使用容器化與最小權限原則，降低實際損害範圍

也算是被這次事件好好上了一課：

安全性更新不是「之後再說」的選項，而是需要排進日常維護流程裡的必修課。

ExpTech NTP Server

Tue, 16 Dec 2025 00:00:00 GMT

越來越多 ExpTech 相關產品及服務需要時間同步。在 ttyAMA0 的幫助下，剛好有這個機會，我自己又加了一點料，就有了 ExpTech NTP Server，也把舊的時間同步機制一起整理過。

舊架構

早期是一個很簡單的 HTTP 服務，Body 回傳 Unix Timestamp（text/plain）。當時對時間精度沒有特別要求，這個陽春版撐了很久。

新架構

現在改在 time.exptech.com.tw:123 提供 SNTP（UDP），同時保留 HTTP，給不能用 UDP 的環境（例如網頁）對時。

SNTP

先拿幾個常見的公共 NTP Server 對照：

各家 NTP Server 對照

Google NTP Server

Cloudflare NTP Server

Apple NTP Server

TW NTP Server

ExpTech NTP Server

最後是主角，ExpTech 自家的 NTP Server：

HTTP GET（text/plain）

SNTP 之外，也可以用 HTTP 拿時間：

Header 會回傳 X-NTP-T2、X-NTP-T3
Body 仍回傳 Unix Timestamp（text/plain），向下相容舊架構

總結

協定	誤差	說明
SNTP	約 ±5ms	精度表現很好，實測相當穩定
HTTP	約 ±50ms	主要是 TCP 開銷。精度不如 SNTP，但在網頁這類不能用 UDP 的情境仍然很實用

依照實際使用環境選 SNTP 或 HTTP，不同平台都能維持不錯的時間同步。

特別感謝

感謝 台灣數位串流有限公司 TWDS（Taiwan Digital Streaming） 提供伺服器贊助，ExpTech NTP Server 才能穩定運作。

從 JavaScript 到 Golang：TREM 與 DPIP 的架構變遷

Mon, 15 Dec 2025 00:00:00 GMT

前言

TREM 與 DPIP 從 2022 年 5 月中開始做。當時我完全不會寫程式，邊做邊學；服務也從地震慢慢擴到其他類型。範圍變廣、系統變複雜之後，維護變難，穩定性也跟著往下掉。

這篇稿放了半年，現在才把故事寫完。要解釋 DPIP 為什麼這麼難用，得先從 TREM 怎麼長出來講起。

為什麼選擇做地震？

起點是 2022 年 3 月 23 日的花蓮地震。人在臺南，搖晃先到，警報才來。我開始想：能不能自己測，看出哪裡正在地震？學測剛考完，時間夠用，同年 5 月這個計畫就開始了。

TREM-net 觀測網

TREM-net（TREM 地震觀測網）由三種感測器組成：

名稱	感測器	上線	說明
`SE-net`（Strong Earthquake）	MEMS 加速度儀	2022-05-31	強震觀測網
`MS-net`（Micro Seismographic）	磁電式速度儀	2023-04-09	微地震觀測網
`ES-net`（Enhanced Sensitivity）	MEMS 加速度儀	2025-11-02	增強靈敏度地震觀測網

第一台地震儀

編號 6732340 地震儀

這台用 MPU6050 + ESP32 做的，編號 6732340，放在我家。從 2022 年 5 月運作到現在（2026 年 8 月），目前仍正常運作。

SE-net 地震儀

上圖是裝在一般住家的 SE-net 地震儀 ver 1.0。後面幾個版本改的是供電和外殼：

ver 1.0：AC 110V 供電，機內降壓到 DC 5V。
ver 2.0：改成外部 DC 5V（一般手機充電器）。
ver 2.1：透明 Arduino UNO 外殼，加工比較簡單、比較好生產，體積也更小。
ver 2.2：第一次試 3D 列印外殼。雖然創新，但當時還沒有自己的 3D 印表機，只做了極少量，後來停產，主力還是 ver 2.1。

2022 年 5 月到 2026 年 8 月，SE-net 一直是 DPIP 即時資訊與強震監視器通知的主要資料來源。時間一久，問題也慢慢出來。2025 年 9 月，在 ttyAMA0 的幫助下，開始著手開發新一代 ES-net，目標是更穩定、更靈敏。

新舊地震儀比較

以 2026/08/25 臺灣東南部海域 M5.8 地震為例，看兩套地震儀在同一場地震的表現。

SE-net

臺東縣臺東市 7725352

SE-net 地震儀

三軸分量

項目	EW	NS	UD
加速度 (cm/s²)	36.12	19.19	10.51
速度 (cm/s)	1.62	1.16	1.55

綜合指標

項目	數值
3 分量合成加速度 (PGA, gal)	39.07
3 分量合成速度 (PGV, kine)	1.65
最大計測震度	3.9
最大震度階	4 級
速度反應譜 (SVA)	3.43
長周期地震動階級 (LPGM)	0 (3.43 cm/s)
開始時間	2026/08/25 15:00:06
結束時間	2026/08/25 15:01:22

ES-net

ES-net 地震儀

分析

穩定性以外，雜訊也差一截：SE-net 高達 400 µg/√Hz，ES-net 則是 60 µg/√Hz。

而且不穩不只發生在強震當下。SE-net 平時就很容易斷線，工作人員得頻繁聯絡用戶，請對方把地震儀重新插拔，維運的工作量因此大很多。

高雜訊、不穩定，再加上大量雜訊誤報，是我們下定決心開發新版地震儀的主要原因。

講故事

硬體是一段辛酸史，軟體架構也沒少踩雷。時間拉回最前面，看整個系統怎麼一路長出來，也一路壞掉。

第 1 卷

2022 年 5 月，大約高三學測剛考完，開始做 SE-net。當時完全沒有程式基礎，用 PM2 + JavaScript。現在回頭看，選 JavaScript 等於替後面埋了一串炸彈；但那時候，它是我唯一寫得動大型專案的語言。

當時沒有 AI 可以問。身邊沒有朋友或家人在做這行，也沒有人可以請教（別指望普通高中的老師，高職或許有機會）。

過程中認識了蛋捲PVP，學到很多，主要是地球科學。在蛋捲的推動下，開始在全臺各地部署 SE-net 地震儀。

同年，一位熱心人士引薦，認識了 CWB 地震測報中心科長陳達毅。從他那邊學到非常多 EEW 系統的知識，12 月正式與交通部中央氣象局（CWB）簽約合作。

簽約半年後，在東華大學放上第一台 MS-net 磁電式速度儀。做法很粗：ADS1115 + Geophone（4.5 Hz）+ ESP32，就這三樣，卻一直運作到現在。我覺得已經是奇蹟了。要高精度的磁電式地震儀，可以看 AnyShake。

2021 年的電腦

當時的主力電腦是家人汰換下來的 ASUS X55V：CPU Pentium 2020M、記憶體 4GB DDR3。開個 VSCode 都卡到炸——~~天崩開局~~。SE-net 就是在這樣的環境下誕生的。沒錯，它現在還活著。再說一次：當時真的沒有 AI 可以問。

2021 年的伺服器

當時的主力伺服器是 AMD Ryzen 5 5600X。現在還在服役（笑），只是從主力換成打雜，負責各類非即時資料整理。

第 2 卷

PM2 用到 2024 年初，然後大改一次：PM2 換成 Docker，Node.js 換成 Bun.js（還是 JavaScript）。改完當下，「看似」還不錯。

好景不常。幾個月後，JavaScript 沒有型別的問題冒出來。新功能一直往上疊，錯誤變得很頻繁，於是開始加 TypeScript，想把這類問題壓下來。

第 2.5 卷？

0403 之後，意外認識了更多人，也來了很強的外援。

個人電腦與伺服器

巨科資訊有限公司贊助個人電腦（換掉那台 ASUS X55V）和伺服器（AMD Ryzen 9 7900X）。

高頻寬伺服器

台灣數位串流有限公司提供超高頻寬的伺服器，用來應付地震時的突發流量。

地震觀測本來就冷門，這兩家願意幫忙，真的非常感激。

第 3 卷

整個 2025 年上半年都在修修補補，沒有多少實質進展。

真正的改變在同年 9 月。在 ttyAMA0 的推薦下，開始嘗試 Golang，再逐步、分批把舊服務全部用 Golang 重寫（是 rewrite，不是 native port）。

效果很明顯：跟 JavaScript 比，總算能有效用上多核；記憶體用量更低；同樣的計算，CPU 用量更低；打包出來的 Image 也更小，等等。

架構也砍掉一大塊。以前太複雜、太冗餘，常常不穩。

項目	以前	現在
Balance Server	Nginx 後面還有一層 Server	拿掉那層，改成 Openresty + Lua，快取控得更細
儲存	JSON	SQLite（歷史遺留。嚴肅，別笑）
資料庫	MariaDB	ClickHouse（波形）+ HA PostgreSQL（解算資料）
內部通訊	WebSocket	NATS。不用維護健康狀態，邏輯比較簡單，也比較穩，而且本身就有異地備援

去 YouTube 翻地震紀錄影片，會發現現在延遲超級低。差在改用 Lua JIT。

新舊 TREM EEW 系統差異

新系統

地震儀裝置監控面板

舊版異地多活

兩個節點都會發報，但解算結果通常差很多。實際使用時只能固定單一節點，故障時要手動切換。

新系統

兩邊一樣都會解算，最後用仲裁決定哪個節點有發布權限（自動故障轉移）。也會自動補齊兩邊的差異測站，避免特定測站只存在單邊（例如一邊連不上）。

TREM 檢知報告

狀態監測

新系統

狀態監測

ML 模型

番外篇

學生時代

高一到高三，成績應該都是全校倒數（不是班排，是校排）。我其實有認真在讀書，大概吧。高中念了 4 年，大一還回高中重補修，全校大概只有我。

當時多半被當成怪人（不上課，都在胡搞瞎搞）加上廢人（成績爛）。家人一開始很生氣，後來就放棄了。他們很討厭我用 3C，希望我好好讀書，手機還被折成兩半（喜提折疊機）。經過好幾次家庭革命，才勉強能做自己想做的事。說到底，也只能說是運氣好，一路上遇到很多願意幫忙的人。

2024/04/03 地震

ExpTech 2024/04/03 07:58 M7.1 地震紀錄主震時的 TREM EEW 內部紀錄。

你是什麼人 2024/04/27 M5.8 地震紀錄餘震剛好都發生在語音通話時。事後看真的快被笑死。

LB Server 請求分析

Sun, 14 Dec 2025 00:00:00 GMT

分析概述

分析區間是 2025/12/13 上午 9:19:57 至 9:25:01（UTC+8），持續 5 分鐘 4 秒。目的是評估負載平衡伺服器的運作狀況與系統表現，重點為流量分布、伺服器負載、錯誤率與 API 使用情況。

流量

總請求數

948,920

RPS

平均 3,121.45，峰值 3,183.02

總傳輸量

659.64 MB

成功率

97.16%（5xx 為 0）

這段期間系統成功處理 948,920 個 HTTP 請求。峰值與平均 RPS 的差距小（僅 2%）。以平均 3,121 RPS 來看，系統能穩定處理高流量，處理能力足以應付這個負載。

平均請求大小 728.91 B（範圍 0 B ~ 94.12 KB），平均每個請求約 729 bytes，屬於輕量請求。總傳輸量 659.64 MB，傳輸效率良好。

HTTP 狀態碼

類別

狀態碼類別	數量	比例	評估
2xx（成功）	921,963	97.16%	優秀
3xx（重新導向）	1	0.00%	正常
4xx（客戶端錯誤）	26,956	2.84%	需改善
5xx（伺服器錯誤）	0	0.00%	極佳

個別狀態碼

狀態碼	數量	比例
200	921,702	97.13%
404	26,932	2.84%
204	261	0.03%
499	24	0.00%
302	1	0.00%

API 端點

API 端點	總請求數	比例	平均 RPS
`/api/v2/eq/…`	349,779	36.87%	~1,150
`/api/v2/trem/rts`	347,524	36.63%	~1,143
`/api/v1/trem/rts`	97,525	10.28%	~321
`/ntp`	92,440	9.75%	~304
`/websocket`	34,363	3.62%	~113
`/api/v1/eq/…`	25,977	2.74%	~85

地震預警 是流量最高的核心功能（36.87%），在 4 台負載平衡器上分布均勻，平均 RPS 約 1,150，處理能力良好。

即時測站（/api/v2/trem/rts） 與地震預警並列為核心服務（36.63%），負載分布均勻。兩個核心 API 合計 73.5%，核心服務運作正常。

v2 API 使用率 73.5%，是主要版本，大部分使用者已遷移至 v2 API。

/ntp 佔 9.75%，提供時間同步，使用率正常，運作穩定。/websocket 佔 3.62%，連線數穩定，用於即時資料推送，運作正常。

負載平衡器

共 5 個不同的 Host。

排名	Host	請求數	比例
1	lb-1.exptech.dev	290,151	30.58%
2	lb-2.exptech.dev	224,730	23.68%
3	lb-3.exptech.dev	212,328	22.38%
4	lb-4.exptech.dev	212,276	22.37%
5	lb.exptech.dev	8,886	0.94%

4 台負載平衡器與理想值（25%）的差異：

伺服器	請求數	比例	與理想值差異
lb-1	290,151	30.58%	+5.58%
lb-2	224,730	23.68%	-1.32%
lb-3	212,328	22.38%	-2.62%
lb-4	212,276	22.37%	-2.63%

4 台都在正常運作，沒有單點故障。負載相對均勻，差異在可接受範圍（22-31%）。核心 API 端點在 4 台上分布均勻。

通用網域 lb.exptech.dev 只處理 0.94% 的流量，表示大部分客戶端直接指定特定負載平衡器。這個做法有助於故障隔離，提升系統可靠性。

客戶端平台

共 14 個不同的平台。

排名	平台	請求數	比例
1	trem_lite	375,765	39.60%
2	Dart/Flutter	264,753	27.90%
3	tremv	165,834	17.48%
4	ZeroQuake	72,434	7.63%
5	Unknown	27,754	2.92%
6	Node.js	25,429	2.68%
7	Other	6,962	0.73%
8	Chrome	3,948	0.42%
9	Python	2,104	0.22%
10	Axios	2,081	0.22%
11	curl	1,080	0.11%
12	dpip	585	0.06%
13	Safari	183	0.02%
14	Firefox	8	0.00%

主要平台 trem_lite、Dart/Flutter、tremv 運作正常，合計 84.98%。trem_lite（39.60%）是最大的單一客戶端，運作穩定；Dart/Flutter（27.90%）是行動應用程式，使用率穩定；tremv（17.48%）是第三大平台，運作正常。14 個平台顯示系統被廣泛採用。

請求大小與傳輸

請求大小

指標	數值	評估
平均請求大小	728.91 bytes	輕量級，效能良好
最小請求大小	0 B	正常（健康檢查）
最大請求大小	94.12 KB	正常（WebSocket）

平均請求大小合理，屬於輕量級 API 請求。大小分布正常，沒有異常模式，系統能有效處理這類請求。

傳輸量

指標	數值	評估
總傳輸量	659.64 MB	5 分鐘內傳輸量正常
平均傳輸速度	約 2.2 MB/s	傳輸速度穩定
平均每個請求大小	729 bytes	輕量級請求，效率良好

資料傳輸效率良好，符合 RESTful API 的典型特徵。網路頻寬使用率在合理範圍，沒有明顯瓶頸；傳輸速度穩定，系統運作順暢。

總結

評估項目	狀態	說明
系統穩定性	優秀	零伺服器錯誤，成功率 97.16%
負載平衡	需改善	lb-1 負載過高（30.58%，理想值 25%）
API 端點	良好	核心 API 運作正常，流量分布均勻
錯誤處理	需改善	404 錯誤率 2.84%，略高於理想值
平台支援	良好	支援 14 個平台，主要平台運作正常

表現良好

系統穩定。 5xx 為 0，後端運作正常。97.16% 的請求成功，符合高品質服務標準。能穩定處理平均 3,121 RPS 的流量。
核心服務正常。 地震預警與即時測站運作穩定，在 4 台負載平衡器上分布均勻。流量集中在核心功能，符合預期的使用模式。
平台支援廣。 支援 14 個不同的平台。主要平台 trem_lite、Dart/Flutter、tremv 運作正常。
效能良好。 請求處理效率高，平均請求大小合理。資料傳輸效率良好，頻寬使用率正常。

需要改善

負載不均。 lb-1 處理 30.58% 的流量，高於其他伺服器，承受較大壓力，可能影響整體效能。
404 偏高。 2.84% 略高於理想值（< 2%），可能影響使用者體驗。需要留意客戶端設定與 API 版本。
v1 仍在使用。 仍有 13.02% 的流量使用 v1 API，需要留意版本遷移進度。
Unknown 平台。 2.92% 的請求無法識別來源，可能影響資料分析的準確性。

12/13 TREM 地震報告重複推送問題

Sat, 13 Dec 2025 00:00:00 GMT

事件概述

嚴重程度：中狀態：已結案

發生時間: 2025/12/13 03:33 (UTC+8) 左右
觸發條件: 維護過程中
問題描述: TREM Lite 地震報告重複推送的問題
根本原因: 快取鍵衝突

時間軸

時間 (UTC+8)

嚴重 2025/12/13 03:33
問題發生：TREM Lite 地震報告重複推送
資訊 2025/12/13 03:53
確認問題並開始進行修復
警告 2025/12/13 03:54
執行緊急處理，嘗試緩解問題
已恢復 2025/12/13 03:55
觀察到問題已緩解

事件經過

在進行 TNN Core Server 的維護作業期間，調整 Nginx 設定時將 report server 容器重啟，隨後發生 TREM Lite 地震報告重複推送的問題。問題發生後，立即進行排查，確認問題根源並執行修復，約 22 分鐘後問題得到緩解。

根本原因分析

問題說明

故障時 Nginx 設定如下：

location ~ ^/api/(v1|v2)/eq/report {
  set $cache_key "$uri|$arg_limit|$arg_page|$arg_minIntensity|$arg_maxIntensity|$arg_minMagnitude|$arg_maxMagnitude|$arg_minDepth|$arg_maxDepth";
  proxy_pass http://report;
  proxy_cache_key $cache_key;
  include /etc/nginx/conf.d/cache_1s.inc;
}

cache_1s.inc

proxy_cache my_cache;
proxy_cache_key $url;
proxy_cache_valid 200 1s;
proxy_cache_lock on;
proxy_cache_lock_timeout 1s;
proxy_cache_use_stale updating error timeout http_500 http_502 http_503 http_504;
proxy_cache_background_update on;

問題點：

快取鍵設定衝突：
- 在 location 區塊中設定了 proxy_cache_key $cache_key（使用自訂的快取鍵）
- 但在 cache_1s.inc 中又設定了 proxy_cache_key $url（使用 URL 作為快取鍵）
- 兩個 proxy_cache_key 設定衝突，導致快取鍵不一致
回應不符預期：
- cache_1s.inc 中的 proxy_cache_key $url; 會覆蓋 location 區塊中的 proxy_cache_key $cache_key;
- 當請求有查詢參數和沒有查詢參數時，$url 可能產生相同的快取鍵
- 例如：/api/v1/eq/report 和 /api/v1/eq/report?limit=10 可能使用相同的快取鍵
- 導致不同參數的請求共用相同的快取結果，返回不符合預期的資料
影響：
- 客戶端收到不一致的地震報告資料
- 相同的地震事件被重複推送

解決方案

修改後的設定

移除 cache_1s.inc 中的 proxy_cache_key $url; 設定，統一使用 location 區塊中定義的 $cache_key：

location ~ ^/api/(v1|v2)/eq/report {
  set $cache_key "$uri|$arg_limit|$arg_page|$arg_minIntensity|$arg_maxIntensity|$arg_minMagnitude|$arg_maxMagnitude|$arg_minDepth|$arg_maxDepth";
  proxy_pass http://report;
  proxy_cache_key $cache_key;
  include /etc/nginx/conf.d/cache_1s.inc;
}

cache_1s.inc（修改後）

proxy_cache my_cache;
# 移除 proxy_cache_key $url; 避免與 location 區塊中的設定衝突
proxy_cache_valid 200 1s;
proxy_cache_lock on;
proxy_cache_lock_timeout 1s;
proxy_cache_use_stale updating error timeout http_500 http_502 http_503 http_504;
proxy_cache_background_update on;

改進說明

統一快取鍵設定： 移除 cache_1s.inc 中的 proxy_cache_key $url;，避免與 location 區塊中的自訂快取鍵衝突
確保快取鍵唯一性： 使用包含所有查詢參數的自訂快取鍵，確保有參數和無參數的請求使用不同的快取鍵
確保回應正確性： 透過正確的快取鍵設定，確保不同參數的請求使用不同的快取，返回符合預期的資料

12/12 TREM 檢知重複觸發問題

Fri, 12 Dec 2025 00:00:00 GMT

事件概述

嚴重程度：中狀態：已結案

發生時間: 2025/12/12 04:24:28 (UTC+8)
觸發條件: 地震後
問題描述: TREM Lite 出現檢知重複觸發的問題
根本原因: upstream 資料不一致污染 cache，導致系統異常

根本原因分析

Balance Server 上的 Nginx 使用了以下負載平衡設定：

upstream core_servers {
    server tnn.exptech.dev:80;
    server tpe.exptech.dev:80;

    hash $remote_addr consistent;
}

兩個 upstream 的資料不一致

tnn.exptech.dev 和 tpe.exptech.dev 的資料不一致。
一致性雜湊把請求分到不同 upstream

使用 hash $remote_addr consistent; 時，請求可能被分配到不同的 upstream。
不一致的資料寫入 cache

從不同的 upstream 取得資料時，會將不一致的資料寫入 cache。
後續請求讀到被污染的 cache

資料狀態因此混亂。
檢知重複觸發

進而引發 TREM Lite 檢知重複觸發。

解決方案

修改後的設定

Nginx upstream 改成下面的設定：

upstream core_servers {
    server tnn.exptech.dev:80 max_fails=1 fail_timeout=10s;
    server tpe.exptech.dev:80 backup;
}

改進說明

主伺服器設定： tnn.exptech.dev 設為主伺服器，並設定故障檢測參數
- max_fails=1：允許最多 1 次失敗
- fail_timeout=10s：故障後 10 秒內不再嘗試該伺服器
備援伺服器設定： tpe.exptech.dev 設為備援伺服器（backup）

只在主伺服器不可用時才會使用。
移除一致性雜湊： 避免請求被分配到不同的 upstream 伺服器
單一資料來源： 使用主備模式，讓所有請求都從同一個資料來源取得資料，避免不同 upstream 的資料不一致污染 cache

排名	請求	請求數	比例	累積比例	RPS
1	`GET /api/v2/eq/… [lb-2.exptech.dev]`	88,110	9.29%	9.29%	289.84
2	`GET /api/v2/eq/… [lb-1.exptech.dev]`	87,496	9.22%	18.51%	287.82
3	`GET /api/v2/eq/… [lb-3.exptech.dev]`	87,108	9.18%	27.69%	286.54
4	`GET /api/v2/eq/… [lb-4.exptech.dev]`	87,065	9.18%	36.86%	286.40
5	`GET /api/v2/trem/rts [lb-2.exptech.dev]`	86,989	9.17%	46.03%	286.15
6	`GET /api/v2/trem/rts [lb-4.exptech.dev]`	86,966	9.16%	55.19%	286.07
7	`GET /api/v2/trem/rts [lb-1.exptech.dev]`	86,954	9.16%	64.36%	286.03
8	`GET /api/v2/trem/rts [lb-3.exptech.dev]`	86,615	9.13%	73.48%	284.92
9	`GET /api/v1/trem/rts [lb-1.exptech.dev]`	60,190	6.34%	79.83%	197.99
10	`GET /ntp [lb-1.exptech.dev]`	40,335	4.25%	84.08%	132.68
11	`GET /api/v1/trem/rts [lb-2.exptech.dev]`	25,096	2.64%	86.72%	82.55
12	`GET /ntp [lb-2.exptech.dev]`	17,428	1.84%	88.56%	57.33
13	`GET /ntp [lb-3.exptech.dev]`	17,332	1.83%	90.39%	57.01
14	`GET /ntp [lb-4.exptech.dev]`	17,321	1.83%	92.21%	56.98
15	`GET /websocket [lb-4.exptech.dev]`	8,575	0.90%	93.11%	28.21
16	`GET /websocket [lb-3.exptech.dev]`	8,544	0.90%	94.01%	28.11
17	`GET /websocket [lb-1.exptech.dev]`	8,475	0.89%	94.91%	27.88
18	`GET /api/v1/eq/… [lb-1.exptech.dev]`	6,633	0.70%	95.61%	21.82
19	`GET /api/v1/eq/… [lb-3.exptech.dev]`	6,351	0.67%	96.28%	20.89
20	`GET /api/v1/eq/… [lb-4.exptech.dev]`	6,346	0.67%	96.94%	20.88
21	`GET /api/v1/trem/rts [lb-3.exptech.dev]`	6,305	0.66%	97.61%	20.74
22	`GET /api/v1/eq/… [lb-2.exptech.dev]`	6,287	0.66%	98.27%	20.68
23	`GET /api/v1/trem/rts [lb-4.exptech.dev]`	5,934	0.63%	98.90%	19.52
24	`GET /api/v1/trem/rts [lb.exptech.dev]`	5,750	0.61%	99.50%	18.91
25	`GET /websocket [lb-2.exptech.dev]`	769	0.08%	99.58%	2.53
26	`GET /ntp [lb.exptech.dev]`	365	0.04%	99.62%	1.20
27	`GET /api/v2/trem/rts [lb.exptech.dev]`	360	0.04%	99.66%	1.18
28	`GET /api/v1/eq/… [lb.exptech.dev]`	360	0.04%	99.70%	1.18