工程師思路系列・事出必有因 NAS 勒索潮番外・第二篇
不得不對外：NAS 公開服務的「相對安全」存取指南
Mr. τ ｜ 風雲網通系統 ｜ 資訊截至 2026-11-02
#NAS#Synology#遠端存取#VPN#IPsec#GeoIP#修補窗口#風險接受
想像一下
老闆說：「我在外面要看一下檔案。」業務說：「行事曆能不能也同步？」
您明明知道這樣不安全，卻很難回他們一句「不行」。
這篇不教您說不，而是教您怎麼說「好」，但更安全。
🧭 三種讀法，挑一種開始
|
⚡ 30 秒
只看下面的「5 句話」。 |
☕ 5 分鐘
|
📖 完整版（約 29 分鐘）
從第一節讀起；每節有重點框，結尾可回目錄。 |
⚡ 先看這 5 句話
1
對外服務的風險不可能歸零：廠商修補前誰也縮不了，您能縮短的只有自己更新的那一段。
2
先把需求縮成四個最小：誰、用什麼服務、從哪裡、多久，通常真正非開不可的比想像少。
3
措施像一把梯子：VPN、Site-to-Site、前置驗證、直接對外加縮限；GeoIP 是濾網，不是圍牆。
4
短期一週止血、中期三個月改架構、長期把對外服務與核心資料分離；做不到就寫一頁風險接受聲明。
5
自架 Ubuntu 不是逃生口，修補窗口只是換人負責；NAS 上的 WordPress 要檢查 PHP、核心、外掛三層。
⏱ 只有 10 分鐘？現在先做這三件事
1．DSM 管理介面（5000／5001）與 SSH 不對外，只允許內網或 VPN 詳細做法 →
2．外部帳號：非 admin、啟用 2FA 與自動封鎖；防火牆只允許台灣來源 詳細做法 →
3．把「誰要從外面用什麼」列成一張表，排定逐步改走 VPN 的時間 詳細做法 →
🎯 你是哪一型讀者？直接看你需要的章節
| 如果你的情況是 | 直接跳到 |
|---|---|
| 只有主管、業務少數人要從外面用 | 三、措施階梯（先看 VPN） |
| 有分公司或門市要連回總部 | 3.2 Site-to-Site IPsec |
| NAS 上有公開網站（WordPress 等） | 1.3 NAS 上的 WordPress |
| 我想知道這週先做什麼 | 4.1 短期止血 |
| 正考慮自己架 Ubuntu，不想等原廠修補 | 六、自架的邏輯陷阱 |
| 老闆要我寫一份風險說明 | 4.4 風險接受聲明 |
— 正文開始 —
上一篇談的是「怎麼自檢、怎麼收斂入口」。但社團裡很快就有人回我：道理都懂，可是公司主管和業務在外面就是要用，DS File、Drive、Photos、Contacts、Calendar、Web Mail 都開著，一時關不掉，也找不到簡單又便宜的替代方案。
這個處境很真實，也很普遍。NAS 的賣點之一，本來就是「啟動服務很方便」。所以這一篇不勸退、不說教，只做三件事：
✔
老實說明：對外服務必然存在的風險，讓您知道自己在承擔什麼。
✔
承認需求、縮小需求：為什麼「非開不可」是正當的，以及怎麼把它變成可管理的最小集合。
✔
給出短、中、長期的做法，讓您可以「先止血，再改善，最後換架構」。
另外，也回應社團裡的兩種想法：「VPN 不就好了？」以及「乾脆自己架 Ubuntu，不要等原廠修補」。後者有一個很容易掉進去的邏輯陷阱，第六節會談。
本文的目標是「相對安全可靠」，不是「絕對安全」
只要服務對外，風險就不可能歸零。本文的做法是把風險降到可以說明、可以承擔、出事時可以復原的程度。
與第一篇相同，「單一來源」表示我只查到一份資料，請當作線索。
第 1 節／共 7 節 ■□□□□□□必讀
一、必然存在的風險：先把帳算清楚
👉 先知道自己在承擔什麼，後面的做法才有意義。有公開網站的人，請特別看1.3 WordPress 專區。
📌 本節重點
• 對外服務的風險由「廠商修補前」與「您更新前」兩段組成，不可能歸零。
• 您能縮短的只有後半段，所以重點是少暴露、限縮損害、救得回。
• NAS 上的網站（WordPress）有 PHP、核心、外掛三層更新鏈，最容易漏。
1.1 修補窗口：您能縮小的，只有一半
一個漏洞從出現到被利用，中間有幾個時間點。把它拆開，您就會知道「更新很快」能解決什麼、不能解決什麼：
| 階段 | 發生什麼事 | 誰能縮短 |
|---|---|---|
| ① 漏洞存在、尚無人知 | 程式裡有洞，但還沒被公開 | 無人能控制 |
| ② 被攻擊者發現並武裝 | 攻擊者開始利用，此時還沒有修補 | 廠商；使用者無能為力 |
| ③ 公開揭露、廠商發布修補 | 公告出現、修補版本提供下載 | 廠商 |
| ④ 使用者完成更新 | 您的 NAS 真的裝上修補 | 您：這是唯一在您手上的一段 |
近年的統計讓這件事更尖銳：Mandiant 的 M-Trends 2026 估計，2025 年漏洞被利用的平均時間約為負 7 天，也就是平均而言，攻擊在修補出現前約一週就已開始；2018 到 2019 年這個數字是 63 天。這是估計值，樣本來自事故回應案件（偏向嚴重入侵），並不表示每個漏洞都在公告前被打。但趨勢很清楚：第 ②、③ 階段，您完全無法縮短。
另一頭，Verizon 的 2026 年資料外洩調查報告（DBIR）指出，2025 年被偵測到的已知被利用漏洞，只有約 26% 被完整修補，完整處置的中位時間為 43 天。也就是說，第 ④ 階段，多數人其實也沒做好。
結論：這是結構性的風險，不是您不夠小心
對外服務的風險，由「廠商修補前」與「您更新前」兩段組成。前一段誰也縮不了，所以不可能歸零；後一段您可以盡力縮短，但也只是縮小而已。
這就是為什麼本文的重點，不是「再快一點更新」，而是讓攻擊者碰到的東西更少、碰到之後能做的事更少、出事之後救得回來。
1.2 每項服務各自的顧慮
| 服務 | 對外時的主要顧慮 | 備註 |
|---|---|---|
| DS File／File Station | 帳號被盜等於資料被讀寫；網頁入口與 App 入口都是對外面 | 分享連結要設到期日與密碼 |
| Synology Drive | 同步會「放大」損害：帳號或端點被攻陷時，刪除或加密會同步到所有端點 | 務必開版本歷史，並保留一份不同步的備份。Synology Drive 不受 PHP2Shell 影響；受影響的 IDrive 是第三方套件，名稱容易混淆 |
| Synology Photos | 常含家人與客戶的隱私；公開分享連結難以追蹤 | 有受害者自述只用 Photos、開了 2FA 仍中招，但入侵途徑未明（單一案例自述） |
| Contacts／Calendar | 通訊錄屬個資；Calendar 屬 Synology-SA-26:14（PHP2Shell）受影響的套件 | Calendar 需更新到 3.0.4-21435 以上。Node.js 的 Node2Shell（SA-26:15）則被 Synology 評估為不受影響 |
| Web Mail（Mail Station 等） | 郵件是長期被針對的服務；信箱又常被拿來重設其他服務的密碼，會產生連鎖接管 | Mail Station 同為 SA-26:14 受影響套件，且 PHP 更新後需另外手動更新（30000002.3.19-20333 以上）。MailPlus Server 不在 SA-26:14 清單內，但另有 SA-26:11（Critical，2026-06 已修補），請確認已更新 |
| Web Station 上的網站（WordPress、Joomla、phpMyAdmin 等） | 本質上是對全網開放的 PHP 應用；PHP2Shell 直接影響此類，風險分三層：PHP 版本、WordPress 核心、外掛與佈景主題 | 見下方 1.3 專區 |
共通點：每多開一個服務，就多一個入口、多一組要追蹤的修補、多一批要管理的帳號。這是下一節要處理的事。
1.3 特別提醒：NAS 上的網站（WordPress）最容易被漏掉
上面談的是 Synology 自家的服務。但不少人還在 NAS 上用 Web Station 架網站，最常見的就是 WordPress。在 Synology 公布的 PHP2Shell 受影響套件清單中，WordPress 與 Web Station 都在其中，同列的還有 Joomla、phpMyAdmin、MediaWiki、vtigerCRM、KodExplorer、IDrive、Calendar 與 Mail Station。
這份清單也出現在 Synology 10/29 的 L0CK3D 新聞稿裡：Synology 在調查 PHP2Shell 衝擊的同時，發現攻擊者利用 2024 年 12 月修補的漏洞，攻擊已終止支援（或過時）的 DSM，並再次呼籲受影響套件的使用者立即透過套件中心更新 PHP。需要分清楚的是，Synology 指認用於加密勒索的是 SA-24:20 那個 DSM 漏洞，不是 PHP2Shell；另有報導稱 Synology 10/30 另函通知客戶，確認 C3RB3R 與 PHP2Shell 無關（單一來源）。
所以 WordPress 的風險不是「它造成了這波 L0CK3D」，而是它本身是一個公開的 PHP 應用，剛好又遇上 PHP2Shell 這個獨立的高風險漏洞。兩件事要分開處理，但都要處理。
| 層 | 內容 | 更新管道 | 常見疏漏 |
|---|---|---|---|
| ① PHP 與 Web Station | 網站實際使用的 PHP 版本與參數 | 套件中心更新 PHP；對照 SA-26:14。PHP 7.4 的修補版本因 DSM 而異：DSM 7.2 以上 7.4.33-0131、DSM 7.0 至 7.1 為 7.4.33-0122、DSM 6.2 為 7.4.33-0010（皆為該版本以上） | 網站仍綁在舊的 PHP 設定檔；使用 PHP 7.3（無修補）；官方修補表只涵蓋 PHP 7.3 至 8.4 |
| ② WordPress 核心 | 網站程式本體 | WordPress 後台更新；若 WordPress 由套件中心安裝，也要確認該套件版本 | 久未登入後台，核心落後 |
| ③ 外掛與佈景主題 | 第三方程式碼，漏洞常見，且與 PHP2Shell 無關 | WordPress 後台更新 | 裝了不用的外掛，或外掛作者已停止維護 |
為什麼 WordPress 特別容易漏
一台 NAS 可以同時安裝多個 PHP 版本，而每個網站（虛擬主機）綁定的是其中一個 PHP 設定檔。PHP 8.2 更新了，網站卻還綁在舊的設定檔上，等於沒更新。
另外，PHP 更新後，相依套件會自動重新啟動；但 Mail Station 例外，需要在套件中心手動更新。
✔
逐一檢查Web Station 裡每個網站綁定的 PHP 設定檔，並確認該版本已達 SA-26:14 所列修補版本以上；PHP 7.3 應改用較新版本。
✔
WordPress 全部更新：核心、佈景主題、外掛。不用的外掛直接刪除，不要只是停用。
✔
後台登入加 2FA，並限制可登入的來源。
✔
暫時緩解（不能取代更新）：社群常見作法是在 PHP 設定檔將 session.upload_progress.enabled 設為 0；PHP 專案指出這不能取代更新。副作用是依賴 PHP 工作階段的上傳進度條會失效。
✔
前面加 CDN 或 WAF 代理：公開網站的訪客不會登入，無法用 Access 這類前置驗證；建議由代理轉發，原站只接受代理的來源，並關閉其他對外埠。
✔
長期：把公開網站搬到獨立主機、虛擬機或託管服務，NAS 不跑公開 WordPress；網站檔案與資料庫要有離機備份。
終止更新的機種上的網站
Synology 已將 PHP 修補延伸到終止支援的 DSM 7.0、7.1、7.2 與 6.2；對於早於 6.2 的 DSM，官方建議在升級前先暫時停用受影響的套件。
但請注意：官方修補表只涵蓋 PHP 7.3 至 8.4。若網站還跑在更舊的 PHP 版本上，不在修補範圍內，應直接改用受支援的版本，或把網站搬離。
第 2 節／共 7 節 ■■□□□□□選讀
二、承認需求：「非開不可」是正當的，但要變成「最小集合」
👉 要說服老闆或同事時讀這節；只想知道怎麼做的人可以直接跳到第三節。
📌 本節重點
• 「非開不可」是正當需求，不需要被污名化。
• 把需求縮成四個最小：誰、什麼服務、從哪裡、多久。
• 通常盤點完，真正非開不可的比想像少。
2.1 為什麼不能一句「不要對外」就結束
✔
主管與業務在外面要查資料、同步檔案、看行事曆與通訊錄，是真實的工作需求。
✔
市面上簡單、便宜、且不用換系統的替代方案，並不多。
✔
「啟用服務很方便」本來就是 NAS 的價值，對很多小型組織來說，NAS 就是他們唯一的伺服器。
✔
要求一個沒有資安人員的小公司「明天起全部改走 VPN」，通常只會讓人偷偷繞過去，結果更糟。
所以正確的態度是：承認需求，然後管理它。「必要」不等於「無條件」，我們要把「必要」拆開來看。
2.2 把需求縮成「四個最小」
| 盤點問題 | 縮小的方式 | 例子 |
|---|---|---|
| 誰需要？ | 最小人群：只開給確實要用的人，離職與職務變動要同步停權 | 5 位業務、2 位主管，而不是全公司 |
| 用什麼服務？ | 最小服務：沒人用的功能直接停用並移除套件 | 只留 Drive 與 File Station，Mail、Contacts 先停 |
| 從哪裡來？ | 最小來源：限制國別、限制 IP、或要求先連 VPN | 只允許台灣來源；出差者改走 VPN |
| 多久？ | 最小時間：臨時需求用臨時開通，到期關閉 | 客戶下載連結 7 天後失效 |
通常做完這張表，您會發現：真正「非開不可」的，遠比一開始以為的少。
第 3 節／共 7 節 ■■■□□□□必讀
三、措施階梯：從最安全到最方便
👉 全文的選擇題。看表格挑一階，再往下讀該階的細節即可，不必每個都讀。
📌 本節重點
• 措施像一把梯子：VPN、Site-to-Site、前置驗證、直接對外加縮限。
• 在可接受的不便下，盡量往上爬一階。
• GeoIP 是濾網，不是圍牆。
把可行的做法排成一把梯子。越往上，攻擊者越難碰到您；越往下，使用者越方便。您的目標是：在可接受的不便之下，盡量往上爬一階。
| 階 | 做法 | 防的是什麼 | 仍剩的風險 | 使用體驗 | 適合 |
|---|---|---|---|---|---|
| 1 | VPN 個人撥接 （OpenVPN、IPsec、WireGuard、Tailscale 等） |
服務不再直接被全網看見 | VPN 自身的漏洞；被偷或被感染的裝置等於通行證 | 要先連 VPN 再用 App | 固定人員：主管、業務 |
| 2 | Site-to-Site IPsec （分公司與總部對接） |
兩個網路固定互通，使用者不用裝軟體 | 對端網路被感染會波及總部；設定較複雜 | 使用者無感 | 分公司、門市、辦公室 |
| 3 | 前置驗證的網頁入口 （Cloudflare Access、反向代理加驗證） |
網頁類服務先驗證身分再放行 | 服務自身漏洞仍可被「已通過驗證者」利用；原生 App 未必相容，需實測 | 瀏覽器登入 | 網頁協作、Calendar 與 Photos 網頁 |
| 4 | 直接對外加縮限 （DSM 防火牆、GeoIP、2FA、自動封鎖） |
降低雜訊與暴力破解 | 免登入漏洞仍可直達 | 最方便 | 不得不時的最後選項，需風險聲明 |
| 4 | QuickConnect | 免開路由器埠 | 仍通往同一組服務；需信任 Synology 中繼 | 方便 | 等同第 4 階，建議限縮服務 |
3.1 VPN：看似最好，但要看清楚它是什麼
VPN 把問題從「全網都能打到服務」變成「要先通過 VPN 的身分驗證才能碰到服務」，這是質的改變，也是第一篇提到的「改變風險的形狀」。但它不是萬靈丹：
✔
個人撥接（client-to-site）：Synology 的 VPN Server 套件，在同一個平台整合 OpenVPN、L2TP over IPSec 與 PPTP，最多 40 個同時連線（實際依機型而異）。其中 PPTP 因為加密與驗證機制老舊，普遍不建議使用。也可以用路由器或防火牆內建的 VPN，或 Tailscale、WireGuard。
✔
VPN 的服務本身也是對外的：它是新的入口，所以同樣要更新、要限縮來源、要用 2FA 或憑證。歷史上，VPN 與防火牆設備本身就是常被攻擊的目標。
✔
裝置就是通行證：手機或筆電遺失、被感染，攻擊者就等於拿到進入內網的鑰匙。建議啟用裝置鎖定、離職與換機時撤銷憑證。
✔
VPN 通了之後，不要「全開」：用防火牆規則限制 VPN 使用者只能碰到需要的服務，而不是整個內網。
3.2 Site-to-Site IPsec：給分公司與門市的選項
如果存取的人集中在幾個固定據點，由兩端的邊界防火牆建立 IPsec 通道，可以讓同仁完全無感，也不必每個人裝 VPN 軟體。要注意的是：
✔
通道只放行需要的子網與埠，不要把兩個網路「整個打通」。
✔
金鑰要夠強；優先使用憑證或強隨機金鑰與 IKEv2，避免弱的預先共用金鑰。
✔
信任也跟著延伸：分支端的電腦如果被感染，經由通道可以直接碰到總部的 NAS。所以分支端的終端安全，等於總部的安全邊界，且 NAS 端要有分段與權限控管。
✔
兩端設備都要持續更新，並保留異常連線的日誌。
3.3 GeoIP：好用，但要放在對的位置
DSM 內建的防火牆可以依來源國別建立規則。常見做法是三條：先允許區域網路、再允許台灣、最後拒絕其他全部；規則由上而下依序比對，所以「允許」要放在「拒絕」前面，否則連自己都會被擋在外面。它的價值與限制如下：
| 項目 | 說明 |
|---|---|
| 有幫助的地方 | 減少境外自動化掃描與暴力破解的雜訊；縮小可攻擊的來源範圍；日誌乾淨了，異常更容易被看見 |
| 做不到的事 | 攻擊者可以用境內主機、雲端或代理；國別資料庫不完美；擋不住「來自台灣的攻擊」，也擋不住免登入漏洞本身 |
| 使用上的限制 | 依 Synology 社群討論，內建防火牆是以「埠」為單位，若多個服務共用 443，沒辦法分服務套用不同的國別規則；反向代理的存取控制設定檔可以限制來源 IP，但不是國別（單一討論串，請依您的 DSM 版本實測） |
| 出差與出國 | 會被自己擋住。建議出差者改走 VPN，或事先登記臨時白名單，而不是為了他們把國別限制拿掉 |
定位一句話：GeoIP 是濾網，不是圍牆。適合放在第 4 階做減噪，但不能拿它來證明「我很安全」。
3.4 幾項便宜但有效的縮限
✔
管理介面不對外：DSM 管理埠（5000、5001）與 SSH 只允許內網或 VPN。
✔
外部帳號只給一般權限：不使用 admin；服務帳號與管理帳號分開。
✔
應用程式存取控制：Synology 的 Application Portal 可為各應用程式指定存取控制設定檔，被拒絕的使用者無法開啟該應用程式；反向代理規則也可套用同樣的設定檔。
✔
2FA 與自動封鎖：擋暴力破解與帳號盜用，仍須啟用，但不要當成唯一防線。
✔
只裝必要的套件：用不到的 Mail、Calendar、Contacts，今天沒人用就先停用。
第 4 節／共 7 節 ■■■■□□□必讀
四、短中長期建議：先止血，再改善，最後換架構
👉 全文的行動清單。這週只要做 4.1 的六項就已經有明顯改善。
📌 本節重點
• 短期一週止血、中期三個月改架構、長期一年以上換架構。
• 最根本的做法是對外服務與核心資料分離。
• 做不到就寫一頁風險接受聲明，讓決策者知道。
不用一次做完。以下按「時間、成本、效果」排序，讓您可以按能量逐步做。
4.1 短期（一週內）：止血
| # | 措施 | 為什麼 | 成本 |
|---|---|---|---|
| 1 | 盤點「誰、用什麼、從哪裡」，停用沒人用的服務與套件 | 入口越少越好 | 低 |
| 2 | 更新 DSM 與所有套件（特別是 Web Station 的 PHP 設定檔與 WordPress 等網站套件、Calendar、Mail Station），並確認 Synology-SA-26:14 所列版本；Mail Station 要另外手動更新 | 縮短第 ④ 階段 | 低 |
| 3 | DSM 管理介面（5000／5001）與 SSH 不對外 | 最大的單一風險點 | 低 |
| 4 | 外部帳號：非 admin、啟用 2FA、啟用自動封鎖、使用強密碼 | 擋暴力破解與帳號盜用 | 低 |
| 5 | 防火牆啟用國別限制（只允許台灣）並只開必要埠；關閉 UPnP；不用 QuickConnect 就關，要用就取消 DSM 網頁入口 | 減噪、縮小來源 | 低 |
| 6 | 確認有一份「這台 NAS 的帳號改不動」的備份，並做一次還原測試 | 決定最壞情況的損失 | 中 |
4.2 中期（一到三個月）：改善架構
| # | 措施 | 為什麼 | 成本 |
|---|---|---|---|
| 1 | 主管與業務逐步改走 VPN，先從 2、3 位開始試，再擴大 | 把風險從「全網可打」換成「需先過 VPN」 | 中 |
| 2 | 對外的網頁類服務，前面加 Cloudflare Access 或反向代理加驗證 | 多一道身分驗證 | 中 |
| 3 | NAS 放獨立網段，防火牆限制它能連到哪裡，並做出站過濾 | 縮小被打穿後的影響 | 中 |
| 4 | 開通異常登入通知；集中保存日誌；寫好三行處置流程 | 縮短發現時間 | 低 |
| 5 | 備份升級：不可變備份或離線備份；每季一次還原演練 | 最後一道保險 | 中 |
| 6 | 依敏感度分資料夾權限：外部可碰的資料與核心資料至少在權限層面分開 | 限縮損害範圍 | 中 |
4.3 長期（半年到一年以上）：換架構
| # | 措施 | 為什麼 | 成本 |
|---|---|---|---|
| 1 | 權責與資料切割：對外服務放在獨立主機、虛擬機或雲端；NAS 只當內部主存與備份。這是最根本的做法 | 對外服務被打穿時，不會碰到核心資料 | 高 |
| 2 | 評估把「需要與外部協作的檔案」放在公司已有的雲端協作服務，NAS 負責內部與備份 | 把對外風險交給有專職團隊的服務 | 中～高 |
| 3 | 汰換已終止更新（EOL）的機種 | 無法修補的機器不該對外 | 高 |
| 4 | 建立「公告 → 評估 → 更新 → 紀錄」的固定流程，並指定負責人與代理人 | 把「靠記得」變成「靠流程」 | 低 |
| 5 | 每年做一次「假設中招」的桌上演練：誰通報、誰斷網、怎麼還原、要多久 | 讓處置不再是第一次 | 低 |
| 6 | 需求成長時，評估具 UTM 與 WAF 功能的邊界防火牆，或零信任網路存取（ZTNA）方案 | 把防護前移到邊界 | 高 |
社團裡確實有人願意切割權責，也請尊重「做不到」的人
「犧牲一台 NAS 專職對外」是我認為最乾淨的做法，且確實有不少個人與企業已經這樣做。但對更多人來說，預算、人力與習慣都不允許。
這時候最重要的是：做不到，就把風險寫清楚、讓決策者知道、同時把短期措施做滿，而不是假裝沒有風險。
4.4 做不到時：給老闆的一頁「風險接受聲明」
如果現階段只能停在第 4 階，建議用一張紙把事情講清楚。它不是為了推卸責任，而是讓決策有依據、出事時有依循：
✔
範圍：對外開放哪些服務、哪些人使用、從哪些來源。
✔
風險說明：對外服務存在免登入漏洞被利用的可能，且修補有時間差，風險無法歸零。
✔
已採措施：更新、限縮來源、2FA、備份、通知。
✔
殘餘風險與最壞情況：資料可能被加密或外洩，預估還原時間。
✔
決策者與責任人：誰決定接受、誰負責維運與通報。
✔
複查日期：多久重新評估一次，並設定改善的目標時間。
第 5 節／共 7 節 ■■■■■□□選讀
五、怎麼選：一棵簡化的決策樹
👉 把前面的內容濃縮成一張圖。看過前兩節的人，可以只看這一節。
誰需要從外面連？
│
├─ 固定人員（主管、業務）→ 能改用 VPN 嗎？
│ ├─ 能 → 階 1：VPN 個人撥接；關掉原本的直接對外入口
│ └─ 暫時不能 → 先做短期 6 項 → 排定「改 VPN」的時間表
│
├─ 固定據點（分公司、門市）→ 階 2：Site-to-Site IPsec
│
├─ 網頁類服務（協作、行事曆、相簿）→ 能加前置驗證嗎？
│ ├─ 能 → 階 3：Cloudflare Access 或反向代理加驗證
│ └─ 不能 → 階 4，並簽風險接受聲明
│
└─ 不特定外部人（客戶下載、公開網站、WordPress）→ 資料機與服務機能分開嗎？
├─ 能 → 長期 1：對外服務獨立，NAS 不直接對外
└─ 不能 → 階 4 加最小集合，限期與到期失效，並簽風險接受聲明
│
├─ 固定人員（主管、業務）→ 能改用 VPN 嗎？
│ ├─ 能 → 階 1：VPN 個人撥接；關掉原本的直接對外入口
│ └─ 暫時不能 → 先做短期 6 項 → 排定「改 VPN」的時間表
│
├─ 固定據點（分公司、門市）→ 階 2：Site-to-Site IPsec
│
├─ 網頁類服務（協作、行事曆、相簿）→ 能加前置驗證嗎？
│ ├─ 能 → 階 3：Cloudflare Access 或反向代理加驗證
│ └─ 不能 → 階 4，並簽風險接受聲明
│
└─ 不特定外部人（客戶下載、公開網站、WordPress）→ 資料機與服務機能分開嗎？
├─ 能 → 長期 1：對外服務獨立，NAS 不直接對外
└─ 不能 → 階 4 加最小集合，限期與到期失效，並簽風險接受聲明
第 6 節／共 7 節 ■■■■■■□選讀
六、「乾脆自己架」是邏輯陷阱：窗口不會因為換人負責而消失
👉 正在考慮自己架 Ubuntu 的人請讀這節；沒有這個打算的人可以跳過。
📌 本節重點
• 自架不會讓修補窗口消失，只是換人負責。
• Ubuntu 的 universe 套件，免費版是盡力而為。
• 自架前，先誠實回答五個問題。
有人的結論是：「Synology 要等原廠修補，我自己架 Ubuntu，加上檔案分享、相簿之類的軟體，不就不用等了？」這個想法聽起來合理，但它把兩個問題混在一起了。
6.1 修補窗口永遠存在，只是換了人負責
回到第一節的四個階段：不管是 Synology、Ubuntu，還是任何軟體，只要是「別人寫的程式」，就有 ① 到 ④ 的窗口。差別在於：誰來取得修補、誰來驗證、誰來部署。
| 項目 | Synology 原廠 NAS | 自架 Ubuntu 加套件 |
|---|---|---|
| 整合與修補的責任 | 原廠整合 DSM 與官方套件 | 您自己是整合者，要選元件、追公告 |
| 修補來源數量 | 集中在一個廠商 | 分散：作業系統、核心、SSH、反向代理、應用程式、資料庫、容器映像，各自有「原廠」 |
| 零時差空窗 | 有 | 一樣有，沒有人能提前替您補 |
| 取得修補後的部署 | 在套件中心或更新頁點更新 | 要自己設定自動更新、決定何時重新啟動、驗證沒壞 |
| 社群與非核心套件 | 依原廠對套件的維護 | Ubuntu 的 universe 套件，免費版只有「盡力而為」的安全修補；Ubuntu Pro 可涵蓋，個人最多 5 台免費 |
| 生命週期 | 機種或版本終止更新 | LTS 到期；或是自己忘了升級 |
| 可能的優勢 | 整合測試、介面一致 | 自由度高；若您持續追蹤上游並自動更新，有機會更快採用修補 |
Ubuntu 官方文件的說明是：Main 套件有標準安全更新；Universe 與 Multiverse 的公共倉庫提供的是社群與 Debian 的「盡力而為」修補；要有 Canonical 的完整保障，需要 Ubuntu Pro。很多常見的應用軟體正好是 Universe 或第三方來源，這是自架時容易忽略的地方。
6.2 另外三個容易被忽略的事
✔
速度不一定贏：以這次 PHP2Shell 為例，Synology 在發布安全公告 SA-26:14 時，就同時附上修補版本。自架者能否更快，取決於您有沒有人在看、有沒有自動更新、有沒有測試機制，而不是「自己架」這件事本身。
✔
攻擊面可能更大：原廠 NAS 的元件是被收斂過的；自架時您可能裝了更多東西，每一個都是新的入口。
✔
零時差時兩邊相同：第 ②、③ 階段沒有人能幫您，無論原廠或自架。
真正該問的不是「原廠 vs 自架」，而是「我有沒有能力在窗口內完成修補」
自架前，請誠實回答五個問題：
• 有沒有人每週看安全公告，並且有代理人？
• 有沒有啟用自動安全更新，以及必要的重新啟動？
• 有沒有測試或回復機制，更新壞了能不能退回去？
• 發現 Critical 漏洞時，能不能在一天內處理？
• 有沒有備份，並且做過還原？
五題都是「有」，自架是合理的選擇；否則它只是把一組您看得見的風險，換成一組您看不見的風險。
第 7 節／共 7 節 ■■■■■■■查詢用
七、本篇新增的術語卡
👉 像字典一樣用：遇到不熟的名詞再回來查，點開分類才會展開。
上一篇已有的名詞（QuickConnect、UPnP、IPv6、反向代理、Tailscale 等）不重複，可到 術語清單 查閱。
▍本篇新增術語 （點開查看 ▾）
Web Station 與 PHP 設定檔（PHP profile）
它在做什麼Web Station 是 DSM 上提供網站服務的套件；PHP 設定檔決定每個網站使用哪個 PHP 版本與參數。
運作原理一台 NAS 可同時安裝多個 PHP 版本，每個網站（虛擬主機）綁定其中一個設定檔。
隱藏風險更新了某個 PHP 套件，網站卻仍綁在另一個舊設定檔，等於沒更新；PHP 7.3 沒有官方修補。
你可以做到 Web Station 逐一檢查每個網站綁定的設定檔與版本，對照 SA-26:14。
個人撥接 VPN（Client-to-Site）
它在做什麼每位使用者的電腦或手機，各自連到公司 VPN，連線後才能存取內部服務。
運作原理使用者端軟體與公司端 VPN 伺服器，經過身分驗證後建立加密通道。
隱藏風險VPN 伺服器是新的入口；裝置遺失或被感染等於通行證外流；連上之後若不加限制，等於進了整個內網。
你可以做更新 VPN；使用憑證或 2FA；防火牆限制 VPN 使用者只能碰必要的服務；離職與換機要撤銷。
Site-to-Site IPsec VPN
它在做什麼兩個網路的邊界設備之間建立固定通道，讓兩邊的內網互通。
運作原理以 IKE 協商金鑰，再用 IPsec 加密封包。使用者端無須安裝軟體。
隱藏風險信任延伸：對端網路被感染會波及這邊。舊式設定下，較弱的預先共用金鑰可能被離線猜測。
你可以做只放行需要的子網與埠；用憑證或強隨機金鑰、IKEv2；兩端設備都要更新。
PPTP
它在做什麼最古老的 VPN 協定之一，設定簡單，多數裝置都內建。
運作原理使用舊的驗證與加密機制建立通道。
隱藏風險機制老舊，普遍被視為不安全；Synology 的 VPN Server 仍列出此協定，但不代表建議使用。
你可以做改用 OpenVPN、IPsec 或 WireGuard 類方案。
存取控制設定檔（Access Control Profile）
它在做什麼Synology Application Portal 內的設定，可限制哪些來源或使用者能開啟特定應用程式。
運作原理為應用程式或反向代理規則指定設定檔，不符的請求會被拒絕。
隱藏風險依社群討論，它能限制來源 IP，但不是國別；設定錯誤可能把自己擋在外面。
你可以做先在內網測試；保留一個安全的管理入口（內網或 VPN）。
修補窗口與 Time-to-Exploit（利用時間）
它在做什麼漏洞從被攻擊者發現，到您完成修補之間的時間差，以及「從揭露到被利用」的時間。
運作原理Mandiant 估計 2025 年平均為負 7 天（修補出現前就已被利用），較 2018 到 2019 年的 63 天大幅縮短。
隱藏風險這是估計平均值，且樣本偏向嚴重入侵事件；但它提醒我們「更新快」只能解決窗口的後半段。
你可以做同時投資「縮小暴露」與「限縮損害」，不要只押注更新速度。
Ubuntu 的 main／universe 與 Ubuntu Pro
它在做什麼Ubuntu 的軟體倉庫分層：main 是官方維護的核心套件；universe 是社群與 Debian 維護的大量套件。
運作原理main 提供標準安全更新；universe 的公共倉庫為盡力而為。Ubuntu Pro 可涵蓋 universe，個人最多 5 台免費。
隱藏風險以為「apt upgrade」就等於全部都有官方安全保障；實際上取決於套件來自哪一層。
你可以做用 Ubuntu 提供的檢查指令確認各套件來源；評估啟用 Ubuntu Pro；第三方來源的套件另外追蹤。
自動安全更新（unattended-upgrades）
它在做什麼Ubuntu 上自動安裝安全更新的機制。
運作原理定期檢查並安裝安全修補，必要時排程重新啟動。
隱藏風險只涵蓋啟用的來源；核心與部分服務更新後需重新啟動才生效；第三方軟體與容器映像不在其中。
你可以做搭配通知與重新啟動規則；容器映像另外建立重建流程。
ZTNA（零信任網路存取）
它在做什麼每次存取都驗證使用者與裝置，只放行特定應用程式，而不是整個網路。
運作原理由控制平面判斷身分、裝置狀態與政策，再轉發請求。
隱藏風險要信任控制平面與帳號；設定與維運比一般 VPN 複雜；仍無法修補應用程式本身的漏洞。
你可以做適合需求成長後的升級選項；先把短期與中期做好再評估。
風險接受聲明
它在做什麼把「已知但暫時無法消除的風險」寫下來，由決策者簽署接受。
運作原理列出範圍、風險、已採措施、殘餘風險、責任人與複查日。
隱藏風險變成只簽名不改善的形式；或沒有複查，風險被長期忽略。
你可以做一定要寫「改善目標時間」與「複查日期」。
結論：不是「開或不開」，而是「開多少、給誰、出事怎麼辦」
對外服務的風險不可能歸零，因為修補窗口是結構性的，不論原廠 NAS 還是自架 Ubuntu，都一樣。
所以我們能做的是三件事：把需求縮到最小、把入口換到更難打的位置（VPN、前置驗證、限縮來源）、把最壞情況變得可以承受（備份、分段、通知）。做不到的部分，就誠實寫下來。
參考來源
本文為一般性資安建議，不針對個別環境；事件仍在發展，請以 Synology 與各廠商的最新公告為準。
Mr. τ ｜ 風雲網通系統
Mr. τ ｜ 風雲網通系統
Comments