AI 時代的防備
該標籤下有 13 篇文章
Linux 核心 CVE-2026-98432：可透過網路觸發的 TCP 釋放後使用漏洞（CVSS 9.8）；請安裝已修復的核心、重新啟動並檢查 MPTCP
CVE-2026-98432 是 Linux 核心 IPv4 TCP 程式碼中的一個釋放後使用漏洞，於2026年10月15日公布。核心專案的 CNA 給出 CVSS v3.1 9.8 分（網路、無需權限、無需使用者互動）。據報導，一家 AI 公司的研究人員在實驗室中、依據其自身報告，示範了針對具有 Multipath TCP（MPTCP）監聽器的伺服器以 root 身分遠端執行程式碼。BleepingComputer 稱，針對一般 TCP 伺服器的遠端程式碼執行尚未公開展示，也未確認有在野利用，本站於11月1日在 CISA 的 KEV 目錄中沒有找到該 CVE。上游修復包含在 5.10.272、5.15.223、6.1.190、6.6.159、6.12.113、6.18.56 與 7.2.10 及之後的版本中。截至11月1日，Debian 已有修復的核心，SUSE 有部分，Ubuntu 與 Red Hat 將修復列為進行中。僅停用 MPTCP 並不是完整的修復。本站的結論是：隨著修復發布，更新面向網際網路的 Linux 伺服器並重新啟動，僅在此之前使用廠商的暫行緩解措施。
AI 時代的安全防護｜個人開發者現在就該夯實的基本功（按優先級排序的清單）
AI 強化的不是『新弱點』，而是『自動、大規模地利用既有弱點』那一側。所以比起特別的新對策，按正確的順序夯實基本功才是最好的準備。CVE 立即打修補程式＋相依套件監控、停止重複使用密碼＋MFA、清除暴露的機密、最小權限、收縮公開面、記錄/IOC 的準備、備份——全都用一份按優先級排序的清單講清楚。
AI 時代有效與無效的安全對策：小站為何也會成為目標
糾正 AI 時代的 4 個誤解。①太小不會被盯上→自動化攻擊不需要由人挑選目標②需要特別的新對策→基本功仍然最有效③裝個產品就安心→比起偵測，先做到『不讓它發生』的設計④AI 生成程式碼又快又安全→可能夾帶漏洞，上線前必須複查。真正有效的，是按正確順序把不起眼的基本功做紮實。
冒充自己網域的郵件：如何與被入侵區分，以及 SPF、DKIM、DMARC 如何阻止它
即使收到自稱來自自己網域的可疑郵件，多數也不是『伺服器被入侵』，而是『寄件人(From)被偽造』。因為 SMTP 允許任意填寫 From。讀懂郵件標頭裡的 Authentication-Results、Received、Reply-To，就能分辨是入侵還是冒充。它能進到收件匣的主因是沒有設定 DMARC。用 SPF→DKIM→DMARC(p=none→reject) 的分階段引入來止住它。
備份基礎：3-2-1 原則與抵禦 ransomware 的還原計畫
備份只是「有做」還不夠，只有「已確認可以還原」的備份才有用。基礎是 3-2-1 原則（3 份副本、2 種媒介、1 份異地）。要防 ransomware，還需要至少 1 份「離線或不可變（immutable）」的副本，因為一直連著的備份會連同原始資料一起被加密。雲端同步不是備份（誤刪和加密也會被同步）。再加上多版本管理和定期還原測試，才算完整。
多因素認證(MFA)如何正確選擇：比 SMS 更強的「抗釣魚」是什麼
MFA 結合不同類別的因素。手動輸入的驗證碼可能被釣魚中繼，SMS 也依賴對手機號碼的控制。重要帳戶應優先考慮通行金鑰或 FIDO2 安全金鑰等抗釣魚方式，並檢查使用者驗證要求與復原流程。
漏洞（CVE）處置實務：徹底修復，並持續監控復發
漏洞處置不是『修了』就完事。完成＝①掃描②修復③隔離/移交④監控四點齊備才算數。尤其在加上監控（每日變化偵測）之前都算未完成——因為相依套件明天又可能變得脆弱。修復內容哪怕100分，只要下一次部署就被覆蓋，也等於0分。越是小團隊，越能靠自動變化偵測和『local→push→deploy』的紀律守得出奇地穩。
osv-scanner 的安裝與使用：自動找出相依套件裡的 CVE
osv-scanner 是一款免費工具，掃描鎖定檔或容器以排查相依套件中的 CVE。本文把安裝、執行、CI 整合做成步驟，並理清它與 npm/pnpm audit、Dependabot 的取捨。本站的觀點＝哪個工具合適取決於你的架構。多語言混用或不依賴 GitHub 就用 osv-scanner，單一 npm 用內建的 pnpm audit 就夠了。
密碼管理器安全嗎？運作原理與雲端、本機的區別，以及如何選擇
密碼管理器協助你為每項服務使用強且不重複的密碼。零知識加密旨在提供方外洩加密資料時保護內容，但安全性還取決於主密碼強度、加密設定和裝置安全。透過 MFA 防止未經授權的登入，並按用途選擇雲端型或本機型。
是否把機密檔案遺忘在公開目錄裡：webroot 盤點
放在 webroot 裡的東西，任何人都能透過 URL 取走。遺留的權杖／憑證 JSON、.env 或備份就等於立即外洩；如果它來自共用範本，每個站點都有同一個檔案。對策：公開目錄只放可以公開的東西，機密放在 webroot 之外並設權限 600，一旦發現一個，就盤點所有站點與主機。
個人開發 / 小規模維運的安全底線：按優先順序列出業界標準的對策
最低限度的對策並非『全都一樣重』。本站的優先順序 ＝ ①管理帳號、網域與郵件（多因素驗證）②金鑰與程式碼 ③應用程式本體 ④修補 / 偵測 / 還原。資源有限的個人，按這個順序從上往下填才是正解。多數事故並非新型攻擊，而是這些基本對策的缺口造成的。
SSH 金鑰的最小權限：別把正式環境的 root 金鑰放進可能被入侵的臨時環境
從可能被入侵的臨時環境（GPU pod、CI runner、一次性 VM）向正式環境登記 root 金鑰，該環境一旦被入侵，攻擊者就會取得正式環境的 root。對策：臨時環境不放 root 金鑰；不用就刪除；再次需要時，用非 root 使用者加上限制為單一操作的 command 限制金鑰。把重複使用的金鑰當作最重要的資產，絕不要建立一把金鑰外洩就能打開所有伺服器的架構。
API key 從 AI 寫的程式碼外洩並被盜刷：原因是未修補的 CVSS 10.0 漏洞
帳單暴漲是症狀。原因是公開已久、卻未修補的 CVSS 10.0 RCE。本文把隱去專有名詞的案例，提煉成防禦的教訓。