QNAP《2026 台灣企業資安韌性大調查》（調查 241 家企業）把內網橫向偵測列為三大盲點之一，有多達 40% 的企業在這一塊完全沒有防護。調查頁面的說法很直接，邊界防火牆擋不住已經潛入的威脅，攻擊者平均 29 分鐘就開始橫向移動，企業卻要 14 天才察覺。
這兩個數字頁面上沒有標註出處，CyberQ 查了一下原始來源，29 分鐘這個數字出自 CrowdStrike《2026 Global Threat Report》，指 2025 年以營利為目的的犯罪集團（eCrime）從入侵到橫向移動的平均「突破時間」（breakout time）。同一份報告裡，最快的一次只花了 27 秒。而 14 天的數字則出自 Mandiant《M-Trends 2026》，是 2025 年全球入侵事件的「停留時間」（dwell time）中位數，也就是從入侵到被發現的時間。
兩個數字的母體不同，不能直接相減，但方向很清楚，攻擊者以分鐘計，防守方以天計。這份資安大調查報告開出的處方是部署 NDR（Network Detection and Response，網路偵測與回應），而且強調可以「在不干擾既有網路架構下」完成。
這句話我們想實際驗證是否為真，所以 CyberQ 這次用辦公室現有的一台 QNAP 交換器和兩台 QNAP NAS，從零部署 ADRA NDR X，測試這兩件重要的事：
1、部署前後，既有網路有沒有被干擾。
2、一台內網主機開始掃描或橫向連線時，從第一個封包到被交換器隔離，實際要多久。
為什麼叫旁路呢?
傳統的入侵防禦設備（IPS）多半是串接，也就是說，流量要套過它才能聯通，因此萬一設備當掉，你的網路環境就中斷。而 ADRA NDR X 走的是另一條路，稱為旁路：
偵測走旁路
交換器開啟 NDR 模式後，用 ACL 挑出特定封包，複製一份送到鏡像埠。NAS 從鏡像埠收封包，在容器裡跑 Suricata 偵測引擎與 ADRA 的關聯分析。原本的流量照常走，NAS 不在路徑上。
阻斷靠交換器
判定某台裝置有風險時，ADRA 呼叫交換器 API，針對那台裝置下一條拒絕（deny）ACL。執行阻斷的是原本就在網路中間的交換器，不必另外串一台設備進去。
這個設計正好對應「不干擾既有網路架構」的說法，不改 IP、不改閘道、不改 VLAN，只需要多接一條鏡像線，這對於不能安裝 agents 或額外軟體的 OT 環境、產線環境是很剛好的選項，對於 IT 環境來說，在這個架構下也能受益。
實測環境
| 項目 | 內容 |
|---|---|
| 核心交換器 | QNAP QSW-M3212R-8S4T，韌體 4.5.0 |
| ADRA 主機（主機 B） | QNAP TVS-h877AX，QuTS hero h6.1.0 Beta，16 GB 記憶體 |
| 受保護主機（主機 A） | QNAP TS-855x，平常就在跑檔案、備份等正式服務 |
| ADRA NDR X | 1.0.7.1044（2026/10/12 發行），Suricata 規則 20261012，共 52,414 條 |
| 受駭端 | 在主機 A 上用 macvlan 建一個容器，有自己的 MAC 與 IP，模擬一台被入侵的內網電腦 |
| 量測端 | 一台 10GbE Debian Linux 工作站，全程以每秒 10 次的頻率 ping 各主機 |
要先說明的一點，本次測試的機器是 TVS-h877AX，它不在 QNAP 官方公布 ADRA NDR X 1.0.7 的 App Center 支援清單上（清單以 TS-x73A、x74、x88 等系列為主）。安裝包本身只檢查 x86 架構與至少 8 GB 記憶體，所以 CyberQ 直接用 App Center 的「手動安裝」裝上，沒有修改任何檢查。預設就能直接裝好，即便是介面會跳出「不支援的主機裝置型號」提示，說明只影響連接埠設定頁的裝置圖片。這屬於實驗性的測試用部署，正式導入請選清單內的機型。
部署採用三步驟精靈，約 25 秒完成交換器設定
部署只需要做一件實體工作，把 NAS 的一個空閒網卡直接接到交換器的一個空埠，當作鏡像線。這個埠必須絕對專用，不能接在下游交換器後面，因為鏡像埠收到的是複製的流量。這次用主機 B 的第二個 10GbE 網卡接交換器的 Ex0/3。
接著在 ADRA 的「連接埠設定」新增核心交換器，精靈分三步：
- 連線：輸入交換器 IP 與管理員帳密，建議勾選 HTTPS。
- 鏡像連接埠：在交換器面板圖上點選 NAS 接的那個埠。
- 受監控連接埠：選要觀察的埠。這次選了主機 A 與主機 B 所在的 Ex0/1、Ex0/2。
按下「註冊」後，同時量測交換器的設定。結果如下：
第 7 秒：交換器狀態轉為 connected。
第 25 秒：交換器上已經多出完整的鏡像 session 與 19 條 ACL。
這期間工作站對各主機的 ping 全部正常，零掉包。
ADRA 下的鏡像 ACL 只挑這幾類封包（全部 12 個埠的入向都套用）：
| 封包類型 | 用途 |
|---|---|
| TCP SYN、TCP RST | 誰在對誰建立連線?、誰被拒絕? |
| ICMP、ARP | 探測與位址解析 |
| DHCP（UDP 67） | 新裝置加入網路 |
| DNS（UDP 53 雙向） | 查了哪些網域? |
| RDP（3389） | 遠端桌面連線 |
也就是說，ADRA 平常看的是「誰連了誰、查了什麼」，不是連線內容。只有被判定可疑的裝置，才會依既有原則自動進入「威脅監控」，此時這台裝置的全部封包才會被鏡像分析。
第一件事：既有網路有沒有被干擾
這是這次測試的核心問題，所以 CyberQ 分三個層次量：
1. 延遲與掉包
工作站全程以 10 Hz 頻率 ping 兩台 NAS、閘道與交換器本身，比較部署前 24 分鐘與 NDR 運作期間 69 分鐘的結果（排除自己換網路線的兩次）：
| 目標 | 部署前掉包 | NDR 運作中掉包 | 部署前 p50 | NDR 運作中 p50 |
|---|---|---|---|---|
| 主機 A | 0 / 14,400 | 0 / 41,200 | 0.62 ms | 0.56 ms |
| 主機 B | 0 / 14,400 | 0 / 41,200 | 0.50 ms | 0.42 ms |
| 閘道 | 0 / 14,400 | 0 / 41,200 | 0.49 ms | 0.45 ms |
| 交換器 | 0 / 14,400 | 0 / 41,200 | 1.59 ms | 1.52 ms |
NDR 運作期間主機 A 的 p99 從 1.28 ms 升到 2.39 ms，原因是這段時間內跑了好幾輪 10G 滿載的吞吐測試，屬於量測本身造成的負載。
2. 吞吐量
在相同接線下，分別在 NDR 運作中與解除註冊後，用 iperf3 量兩條 10GbE 路徑，各跑 3 回合雙向：
| 路徑 | NDR 運作中 | NDR 關閉 |
|---|---|---|
| 工作站 ↔ 主機 A | 9.35 至 9.45 Gbps | 9.39 至 9.46 Gbps |
| 主機 B ↔ 主機 A | 9.36 至 9.49 Gbps | 9.41 至 9.46 Gbps |
差異落在量測雜訊內。
3. 鏡像量
從註冊完成到測試結束的 46 分鐘裡，所有埠的入向流量合計 115 GB，鏡像埠只送出 9 MB，約 0.008%。所以鏡像線用 2.5GbE 甚至 1GbE 都綽綽有餘，NAS 也不需要即時分析 10G 等級的流量。
結論很簡單，在這個環境裡，「不干擾既有網路架構」這句話成立。唯一的實體變更是多接一條鏡像線。測試結束後解除註冊，交換器設定備份與部署前逐檔比對完全一致（只有備份檔的時間戳不同）。
第二件事：從第一個封包到被隔離，要多久 ?
阻斷原則怎麼設 ?
ADRA 的原則分四級，預設是只告警不阻斷的「風險通知」：
為了確保自動阻斷只會打到測試用的受駭端，這次測試新增一條規則，來源只限受駭端容器的 MAC，保護原則選「進階保護」（中度與高度風險事件都自動隔離），其他裝置維持預設的「風險通知」。另外部署一個「陷阱」，也就是一台假的 NAS，用 DHCP 取得位址，正常使用者不會去碰它，碰了就代表有人在內網探測。
測試情境與結果
受駭端在每個情境都由腳本發起，時間以毫秒記錄。工作站同時每 0.2 秒 ping 受駭端，交換器 ACL 每秒讀一次：
| 情境 | 回合 | 第一筆告警 | 被交換器隔離 | 結果 |
|---|---|---|---|---|
| S1：對陷阱、另一台 NAS、交換器做服務埠探測 | 3 | +0.4 秒（陷阱，高風險） | +2.2 至 3.2 秒 | 3 / 3 隔離 |
| S2：對陷阱嘗試 SMB、SSH 登入與連線 | 3 | +0.5 秒 | +2.4 至 4.5 秒 | 3 / 3 隔離 |
| S3a：只掃非陷阱主機，3 台各 11 個埠 | 3 | 1 回合在 +88 秒由關聯引擎發出 | +90.7 秒 | 1 / 3 隔離 |
| S3b：只掃非陷阱主機，2 台各 200 個埠 | 3 | 第 1 回合 +0.3 秒（中度風險） | +3.4 秒 | 1 / 3 隔離 |
| S4：查詢可疑網域（Telegram API） | 1 | +0.5 秒（低風險） | 不隔離 | 符合「進階保護」設計 |
只要碰到陷阱，或掃描量明顯，從第一個封包到交換器把它隔離，大約 2 到 4.5 秒。對照調查引用的「29 分鐘開始橫向移動」，這是兩個數量級的差距。
交換器實際做了什麼 ?
隔離發生時，交換器上會多出兩條 ACL：
一條拒絕「來源 IP 為受駭端」的所有 IPv4 封包。
一條拒絕「來源 IP 為受駭端」的 ARP。
兩條都套用在全部 12 個埠的入向。連 ARP 都擋，受駭端就連同網段的鄰居都找不到。
同一時間，其他四個量測目標（兩台 NAS、閘道、交換器）零掉包，主機 A 本身的服務也沒有中斷，即使受駭端容器就跑在主機 A 上。原因是阻斷以「來源 IP」為單位，而不是把整個連接埠關掉。
解除隔離
管理者在風險管理頁選取裝置，執行「確認所有風險事件，並改為進行常態偵測」，交換器就會撤掉這兩條 ACL。實測從按下確認到受駭端恢復連線，只要 0.2 到 1.3 秒。
測出來的限制，導入前要知道
NDR 不是萬靈丹，這次測試也測到幾個邊界：
- 陷阱是這套系統裡最有效的感測器，建議一定要部署。
- 同一台主機內部的流量看不到。 受駭端容器和主機 A 上另一個容器之間的 DNS 查詢，在主機 A 內部就轉送完了，根本沒經過交換器，ADRA 自然看不到。虛擬機或容器密集的主機，東西向流量需要搭配主機端的防護。
- 解除隔離前，先確認端點已經清乾淨。 S2 第三回合開始前，受駭端就又被隔離了。原因是上一回合被擋住的 SSH 連線還在重送，解除隔離後立刻連上陷阱，於是再次觸發。
- 記憶體需求不低。 ADRA 在主機 B 上約占 3.3 GB（Suricata 約 2 GB、資安控管元件約 1.1 GB），這還是先停掉 NAS 上 AI 相關服務之後的數字。16 GB 機型若同時跑其他重度服務會很吃緊，建議規劃專用或記憶體充裕的機型。
- 需要相容的 QNAP 交換器。鏡像與阻斷都靠 QSW 系列交換器開啟的 NDR 模式，陷阱功能也有韌體門檻（Marvell 晶片 4.5.0 以上、Realtek 3.2.2 以上，Microchip 晶片不支援）。
部署檢查清單
如果你也想在現有網路上補一層內網橫向偵測，CyberQ 這次的經驗整理成一份建議部署強化清單：
☐ 確認 NAS 機型在 ADRA NDR X 的 App Center 支援清單內，記憶體建議 16 GB 以上且不與其他重度服務共用。
☐ 確認交換器為支援 NDR 模式的 QSW 機型，韌體符合陷阱功能需求。
☐ 準備一個 NAS 空閒網卡與交換器空埠，直接對接作為鏡像線，不要經過下游交換器或會發燙的轉接模組。
☐ 註冊前先備份交換器設定，註冊後比對新增的鏡像 session 與 ACL。
☐ 確認偵測引擎實際監聽的是鏡像網卡，並執行一次「檢查健康狀態」。
☐ 手動更新一次 Suricata 規則，確認版本號真的有變。
☐ 部署至少一個陷阱，並在 DHCP 伺服器保留它的位址。
☐ 先用「風險通知」觀察一到兩週，把正常行為加入例外，再逐步對高風險網段啟用「基本保護」或「進階保護」。
☐ 把「檢查健康狀態」列入例行巡檢，並演練一次解除隔離的流程。
旁路架構確實可行
調查裡 40% 的企業在內網橫向偵測「完全無防護」，常見的理由是怕動到既有網路、怕設備串在中間變成單點故障。這次實測的答案是，旁路架構確實可以做到不改線、不改 IP、不影響吞吐，交換器設定也能乾淨還原。在攻擊者碰觸陷阱或掃描量明顯時，從第一個封包到被隔離只要幾秒鐘。
它的限制同樣明確，需要設置陷阱可強化偵測效果，同一主機內容器間互相的流量看不到，而且需要相容的 QNAP 交換器與記憶體充裕的 NAS。
CyberQ 認為，把 ADRA 系列的功能，當成「內網的煙霧偵測器加自動灑水器」很貼切，它不取代端點防護與邊界防火牆，但能把「14 天才察覺」縮短到「幾秒就隔離」，對沒有專職資安人力的中小企業與缺乏人力維護的 OT 環境和工廠產線來說，是一個門檻不高、效果看得見的好起點。
如果搭配端點防護、防火牆與其他資安服務，會是企業網路內的重要防禦縱深強化利器。
