編按：本文來自一位讀者的投書。他把公司營運資料與多年家庭照片都放在同一台 NAS 上，10 月底那波 .L0CK3D 加密，讓他從使用者變成質疑者。以下以第三人稱整理他的敘述，關鍵處保留原話，後半段的公開資料與防護清單，由編輯部補充整理。
10 月 30 日早上，他打開 NAS，整排檔案後面都掛上了 .L0CK3D，旁邊一張冷冰冰的勒索信。身邊幾位朋友與客戶，也同樣受到打擊。
讓他更在意的不只是被攻擊，而是時間線，官方在 10 月 22 日才對外公告，說安全更新與更新檔已經就緒，一個多禮拜之後，還是有不少人中招。
他把公司的營運資料與多年的家庭照片，很放心地託付在這台機器上。看著社群與論壇一片哀號，他心裡浮現的不只是憤怒與焦慮，而是一種很具體的信任崩解。「如果真的這麼快就宣布的沒問題、漏洞已補，結果大家還是大規模中招。」他問，「那之後發的每一份安全公告，還能用原本的力氣去相信嗎？」
一、兩個互相排斥的說法，官方只講了對自己有利的那一半
面對社群反彈，群暉很快發出公告，把矛頭指向「受害設備多半停留在過舊的 DSM 版本」，意思是漏洞早在之前就已經修掉了，換言之，或許某些 NAS 中招的一部份責任也在使用者自己沒升級。
問題是，這個說法和 10 月 22 日那則「更新與更新檔已就緒」的公告，在邏輯上並不是同一件事：
- 如果漏洞在之前就補完了，那麼 10 月 22 日那則公告究竟是在補什麼？
- 如果補齊的動作發生在 10 月 22 日，那為什麼在事件應變團隊目前追查到的案例裡，已經出現執行 DSM 7.4.1 最新版本的 RS1221+ 同樣遇襲的紀錄？
兩個說法各自都成立，卻不能同時拿來當解釋。而官方對外呈現的，是比較方便的那一個。
二、後門不是更新檔能照顧到的範圍
這次攻擊手法裡，最麻煩的一段是，駭客在系統底層的 crond 排程中植入後門，並且採取間歇性加密。從 GitLab、Docker 容器環境的 CVSS 10.0 滿分弱點，到 PHP 核心的遠端程式碼執行漏洞（Synology-SA-26:14），攻擊者不是直接強攻突破防線，而是先進來、留下排程、等時間到再引爆。
這就產生一個很實際的維運問題，如果在先前的空窗期，設備已經被踩進來埋了排程，使用者事後就算乖乖升到最新版，單純套用系統更新檔的話，也清不掉這些潛伏的威脅，時間一到照樣被觸發產生危機。
而原廠急著對外定調「漏洞早已修復、新版沒事」，對於整條攻擊鏈的排查方法與後門清理指引，卻幾乎看不到夠深度的交代。在這些疑雲徹底釐清之前，給出修復完畢、沒事了的結論是稍微早了點，只會讓照著指示做的人仍舊是在曝險之中，如果還來不及更新，或許先用緩解法，加強防火牆對這一台設備的防護也是可行。
三、快的應該是什麼
資安本是高度不對稱的動態攻防，沒有任何一家廠商敢宣稱自家系統 100% 免疫於新型態的零日威脅，這點所有 IT 從業人員都清楚。使用者真正無法接受的，從來不是有漏洞，而是廠商在致命風險面前展現的不小心與樂觀。
關鍵在於廠商是把效率用在「透明通報」，還是用在「過早打包票」。
- 一份負責任的應變，會在威脅出現的第一時間示警、誠實通報進度，明確告知用戶目前排查到哪一步、哪些套件（容器環境、第三方服務）存在潛在風險，並立刻給出斷網、封鎖高風險連接埠這類最具體的防護指引。
- 相對地，市場上有些專注底層儲存安全的架構，堅持每一道修補都必須由工程團隊反覆滲透驗證、確認封堵到位，才依序發布更新。這種作風慢，但它換來的是「公告說沒事，就是真的沒事」。
群暉這次的表現，暴露的是「追求發布效率卻忽視驗證深度」的短線思維。對一個儲存品牌來說，這不只是技術疏漏，而是品牌信譽的影響，某些用戶的資料確實曝險。
四、下一次，誰敢第一時間按下更新？
現在大家對 Synology 最大的質疑其實很單純，當之後如果有新公告跳出來說「某某漏洞已修復完畢，請放心更新」，還有誰敢第一時間按下去？還有哪家企業敢把核心資料安心放進你們家的機器？在他看來，使用者恐怕都得用類似這樣的方式，自己更新後再驗證並實測過一遍，確認安全與周邊的防護有沒有自己再加固好。
迅速溝通現狀非常重要，但「實話實說的進度通報」和「沒徹底驗證就打包票」是兩件完全不同的事。前者建立信任，後者消耗信任，而信任這種資產，一次事件就能燒掉好幾年的累積。
唯有踏實通報、驗證到確定為止才發布，才真的守得住用戶的數位資產。
所有 NAS 共通的防護原則
這波 Synology 勒索病毒災情與市場上許多服務和網站的資安危機，反覆驗證的仍是同一組原則。儘量遵循 ISO 27001 的精神和原則，限縮被攻擊面，勤於更新，以及做好 3-2-1 備份。如果有 Airgap+ 或快照與額外的離線備份，可再降低快照被刪掉的風險。
- NAS 的管理介面與檔案服務不對網際網路直接開放，遠端存取一律走 VPN 或廠商中繼服務。本文所有已知細節的受害案例，都有連接埠轉發或管理介面直接暴露
- 系統更新優先於套件更新。這波勒索利用的是 9 月 18 日與 2024 年底就修補的 DSM 漏洞，受害者缺的不是 PHP 修補，而是幾個月甚至一年半的系統更新
- 不要相信「已是最新版本」的畫面，請自己比對各廠商官方網站公告上的版本號
- 每個共用資料夾都要有快照，快照要有保留期限與防刪除保護
- 備份要有版本，要有一份離線副本，而且要實際演練還原。RAID 不是備份，同步不是備份
- 停用預設管理員帳號，所有帳號啟用兩步驟驗證，開啟登入失敗自動封鎖
- 不再使用的套件與服務直接移除，每多裝一個對外服務就多一個攻擊面
- 廠商停止支援的舊機種，維運團隊請務必注意將之退出網際網路
延伸閱讀：本次事件的入侵途徑目前仍未有官方定論，CVE 編號與修補版本請以 Synology 安全公告頁 為準。
BleepingComputer 論壇 C3RB3R 支援討論串第 4 頁
PBX Science，Synology NAS Ransomware Alert
視角說明：本文前半為讀者投稿觀點，經編輯部整理為第三人稱敘述，附錄的公開資料、表格與清單由編輯部彙整，事件入侵途徑目前仍未有官方定論。
