不續約防火牆資安服務後 …
不續約防火牆資安服務後 …

資安 ｜ 防火牆 ｜ Windows 內建防護 ｜ Pico-UTM 100 ｜ ZYXEL USG FLEX 200 作者：Mr. τ ／ 風雲網通系統　·　2026-10-27 不續約防火牆資安服務後，電腦與瀏覽器的內建防護能支撐「已知威脅」，支撐不了「網路設備被直接攻擊」和「事後沒有紀錄」。風險升在網路入口與設備這兩處。 ✔ 可以勉強支撐：已知的釣魚與惡意網站、已知的惡意檔案、本機的勒索行為偵測。前提是 Windows 有更新、Defender 與 SmartScreen 都開著。 ✔ 照顧不到：NAS、伺服器與舊設備被直接攻擊、手機與訪客、郵件的第一層過濾、自動隔離、集中的網路紀錄。 ✔ 該做的事：到期前匯出報表與日誌、提醒同仁、確認備份與更新，再決定繼續續約、加裝 Pico-UTM 100，或先觀察。 Pico-UTM 100 對應 FLEX 200 的網址、攻擊、病毒三層，但沒有應用程式管控、垃圾信過濾與自動隔離，詳見對照表。 背景防護依賴：沒出事，不代表沒有東西被擋 防護成功的時候，使用者什麼也看不到。用了幾年之後，同仁自然把「沒事」當成理所當然，不知道網路入口有一層檢查一直在運作。 這會默默養鈍風險敏感度：信件看起來正常就打開，連結看起來正常就點，因為過去點了也沒發生事。真正的原因不是「那些連結都安全」，而是「那些危險連結在到達電腦之前已經被擋掉」。 防護服務到期後，行為習慣不會跟著改變，這段空檔最危險。同仁仍照「有防護」的習慣操作，而防線已經少了一層。所以不續約的第一件事，是讓同仁知道「以前有人在擋，現在沒有了」。 FLEX 200 與 Pico-UTM 100 功能對照 核心的網址、攻擊、病毒三層，Pico-UTM 100 都有對應；差在 Pico-UTM 沒有應用程式管控、垃圾信過濾與自動隔離。 防護面向 ZYXEL... » read more

0
Read
steven
外掛式資安服務與資安閘道器的位置差異
外掛式資安服務與資安閘道器的位置差異

工程師思路系列・事出必有因 企業訂閱電信業者的資安外掛服務（例如中華電信資安艦隊），是好消息。對供應鏈資安查核而言，這是一項具體的邊界防護佐證。但外掛服務擺在業者端，和擺在公司內網入口的設備，看到的東西並不一樣。這篇文章用「位置」來說明兩者的差異與搭配。 圖：兩類佐證各自回答不同的查核問題。本圖為架構說明，不構成任何合規認證。 外掛式服務（中華電信資安艦隊這類）的優點與位置界線 優點：不必自行維護設備，且在網路業者端先行攔阻已知威脅，減少帶威脅的流量進入公司。 服務範圍界線則是位置：設備位於業者端，看到的是企業防火牆送出的連線，通常以單一公網位址呈現。若某條連線有疑慮，較難進一步指出是公司內部哪一台電腦或設備發起的。 簡單地說 資安艦隊這類服務，在外面把火勢擋下來，但看不出是公司內網哪一台設備一再點火。 圖解：方案擺放位置不同，帶來不同效果 圖：兩種方案擺放位置不同，看到的內容也不同。下方示意圖再把位址轉換（NAT）的邊界標出來。 位址轉換前：公網側 位址轉換後：內網側 網際網路 → 中華電信資安艦隊 外部邊界防護 → 防火牆 路由器／閘道 ⇢ Pico-UTM 100 內部行為可視 → 主交換器 → 內網設備 電腦・伺服器・AP NAT 邊界 資安艦隊的觀察範圍 進出口流量，通常以單一公網位址呈現 Pico-UTM 100 的觀察範圍 名稱解析與對外連線，可對應到個別設備 資安艦隊在位址轉換之前，Pico-UTM 100 在位址轉換之後。放在防火牆之後，才有機會分辨每一台設備。 資安閘道器補上的位置 資安閘道器（Pico-UTM 100）串接在防火牆與主交換器之間，是全公司設備對外連線的必經位置： 防火牆 → Pico-UTM 100 → 主交換器 → 全公司電腦與設備（內部網路） 內部網路這一區是日常行為與異常最常出現的地方，也是需要公司與維運方持續跟進改善的地方，但是並不在外掛式服務（資安艦隊這類）的服務範圍內。 內網常見的兩類弱點 1 使用者端的資安風險意識。同仁一時閃神點到釣魚連結，或安裝來路不明的軟體，是資安事件最常見的起點之一。 2... » read more

0
Read
steven
續篇：我們努力過了——請 AI 助理陪我探查舊 NAS 的真實環境
續篇：我們努力過了——請 AI 助理陪我探查舊 NAS 的真實環境

工程師思路系列・事出必有因 續篇：我們努力過了——請 AI 助理陪我探查老舊主機的真實環境 Mr. τ ｜ 風雲網通系統 ｜ 2026-10-22 昨天那篇談的是「更新不動、換機不實際、放著不管、廠商不扛」四道難題。有人問我：你說得頭頭是道，那你自己的呢？ 這篇就是交代。我沒有憑印象下結論，而是請 AI 助理陪我確認一台對外主機的實際狀況。為了不替別人提供地圖，這篇刻意不寫品牌、型號、版本、位址與路徑，只談做法和結論。 一、我是怎麼做的 流程：AI 助理擬出唯讀指令，我貼到主機上執行，再把輸出貼回去讓它判讀。它自己能做的，只有從外網做最基本的連線測試，只看回應狀態。 它一度想直接遠端登入，驗證失敗後就停手，沒有重試，也沒有猜密碼。 檢查指令本身都是唯讀的。唯一的設定變動，是我為了檢查而暫時啟用了一個高權限帳號 【請確認：檢查後是否已停用並更換密碼】。 二、查到什麼 1 平台沒有修復路徑（以我的系統版本而言）。這台機器已升到它能升的最後一版系統，而平台提供的執行環境選項，全都停在已終止支援的舊分支，沒有任何一個落在官方的修復線上。這不是我忘了更新，是平台已經沒路了。 10/23 補充：設備廠商後來針對較新的系統版本發布了 PHP 更新，所以是否有修復路徑，取決於你的系統版本；較舊或已終止支援的系統仍沒有直接的路。【請依自己實際的系統版本確認：是否在廠商更新涵蓋範圍內】 2 PHP 實際被誰用。對外的網站只用到單一一組執行環境。同一台機器上另有少數附屬套件各自帶有執行環境，網站目錄裡也堆著多年累積的舊專案與測試檔。 3 對外曝露。網站前面有 CDN，從正式網域測試未使用的管理介面，回應是找不到。但來源主機的另一個入口上，仍有一個沒在使用的管理介面入口沒有來源限制，只要有人知道來源位址就可能連到。另外，我從外網確認有少數不該公開的檔案可以直接下載。漏洞公告逼你檢查，而檢查常常先翻出自己留下的爛攤子。 4 入侵跡象。我掃描了常見的後門特徵，也檢查了使用者上傳區：沒有命中。近期被修改的程式檔，我還在確認是否都出自我自己的更新。另有少數項目因為權限問題，檢查帳號讀不到；我查了擁有者、權限和內容開頭，判斷是我自己先前測試時留下的，網站程式本身也讀不到它。 所以「沒有發現入侵證據」只涵蓋上述這幾項，不等於「沒事」。 5 順手發現的雜物。網站程式本身落後多年；附加元件很多，我還沒逐一確認哪些有啟用、哪些仍在維護；有些檔案的權限開得過寬；網站目錄裡有開發測試殘留。這些在多數老站都很常見，建議你也逐項檢查。 三、同一台機器上別的套件呢？ 給也在用類似設備的讀者：不是每個套件都共用網頁服務的 PHP。我順便查了郵件類套件：執行中的行程和相依項目裡都沒有 PHP，所以在我這台機器上看不到它們使用 PHP 的跡象。10/23 補充：廠商公告提到部分郵件類套件需要手動更新，不同廠商、不同套件的實作不同，請以自己設備的公告為準。【請確認自己使用的郵件套件是否在受影響清單內】 但有些套件會自帶獨立的執行環境，改網頁服務的設定改不到它。這只代表我這台機器，你的情況請自己查。 四、今天的新情況 ✔ 攻擊活動變多了。據報導，雲端業者的蜜罐最早在 10/17 就觀察到攻擊嘗試，PoC 公開後嘗試快速增加。相對地，資安廠商在 10/21 的報告裡寫的是尚未獨立確認有大規模利用。兩者其實只是時間差，而且講的都是「嘗試」。我仍未看到可靠證據確認有網站被成功入侵，但風險已從「可能被利用」變成「正在被大量嘗試」，所以日誌建議至少從 10/17... » read more

0
Read
steven
從硬體架構、DPI 引擎原理到 SMB 商業模式——為什麼這兩種方案根本不在同一個維度競爭？
從硬體架構、DPI 引擎原理到 SMB 商業模式——為什麼這兩種方案根本不在同一個維度競爭？

資安工程 UTM 評估 開源方案 工程師思路系列 從硬體架構、DPI 引擎原理到 SMB 商業模式——為什麼這兩種方案根本不在同一個維度競爭？ 問題起點：能否用開源方案取代 Pico-UTM？ Pico-UTM 100 的市場定價約 NT$12,980（三年特徵碼／韌體更新含主機，市場參考價，依通路與時間而異）。從 IPQ4018 此類 SoC 的量產規模推估，售價結構應包含硬體與多年授權費兩個部分，授權費佔比不低。問題是：能用開源方案組合出 70~80% 的同等功能嗎？ ▌ 結論先說 偵測能力可以做到 75~85%，但「難拚」的點不在功能，在工程取捨與商業模式。開源方案和 Pico-UTM 根本是不同維度的產品。 難拚的根本原因有三個層次：引擎技術（Lionic 自有 DPI 演算法）、硬體成本（ARM SoC 大量製造壓低成本）、責任歸屬（盒子本身就是一份保固承諾）。 Pico-UTM 100 硬體規格解析 規格項目 數值 說明 CPU Qualcomm IPQ4018 4 核 ARMv7 Cortex-A7；官方 spec 600MHz，板廠超頻至 700~716MHz 是常態，日本代理商標示 710MHz RAM 256MB 串流式掃描設計，不需將整個檔案暫存 Flash... » read more

0
Read
steven
資安診斷，不是回答「安全不安全」
資安診斷，不是回答「安全不安全」

工程師思路系列・事出必有因 資安診斷，不是回答「安全不安全」 把不確定的現場，整理成可以行動的知識 「我們公司，到底安不安全？」 這是一個看似簡單、實際上很難回答的問題。難的不是技術，而是問題本身的形狀：它預設了答案只有兩種。 這篇想談的，是一份資安診斷應該怎麼思考：它該看什麼、該承認什麼、該把讀者帶到哪裡。 資安不是二元問題 如果答案只能是「安全」或「不安全」，那麼幾乎所有企業都會落在「不安全」，而且會一直停在那裡。因為從「不安全」走到「安全」的距離看起來太遠、太貴、太模糊，遠到讓人不知道從哪裡開始。 更有用的問法是：現在的暴露在哪裡？哪些已經處理了？哪些還沒有？下一步處理哪一個，最值得？ 問題的形狀一改，答案就不再是一個判決，而是一張可以往前走的地圖。 從設備清單，看見暴露地圖 企業主未必熟悉「勒索軟體」「殭屍網路」這些名詞，但一定知道辦公室裡有什麼：幾台電腦、一台 NAS、門口的監視器、角落的事務機、機櫃裡那台分享器。 這份清單，是企業主看得懂的世界。 工程師要做的，是把它翻譯成另一張圖：每一台設備可能怎麼被接觸到、它接在網路的哪個位置、它出事時會牽動什麼。好的診斷，就是把「設備清單」翻譯成「暴露地圖」的過程。 事出必有因 企業主感受到的，常常是症狀：網路變慢、信箱被停、檔案打不開。真正的暴露點，往往在好幾個環節之前，在一台沒人管理的設備、一組從沒改過的密碼、一條沒人記得的網路線上。暴露地圖的價值，就是讓症狀與根因之間的路徑變得看得見。 不要只問防了多少，要問還剩下什麼 談資安時，最常見的思考方式是產品思維：這個盒子可以防什麼？ 另一種是風險思維：裝完這個盒子之後，還有什麼是它處理不了的？ 兩種問法看的是同一件事，得出的結論卻完全不同。產品思維容易走向「買了就完整」的錯覺；風險思維則會自然推導出：每一項控制措施都只改變了一部分風險，剩下的部分，需要另一項措施、另一筆預算、另一段時間。 所以一份誠實的診斷，不會只列出每項措施的能力，而是讓讀者看到：一項一項累加之後，剩餘風險如何逐步下降，以及最後仍然剩下什麼。資安無法做到零風險，目標從來都是在合理的預算內，把風險降到可以接受的範圍。 延伸閱讀：Cyber Kill Chain 的視角 Lockheed Martin 在 2011 年提出的 Cyber Kill Chain，把一次入侵拆成七個階段：偵察、武器化、投遞、漏洞利用、安裝、命令與控制、達成目標。攻擊必須一環扣一環才能成功，防守方只要在任何一環切斷，攻擊就會中止。 用這個視角看，「防了多少」就是一項措施切斷了哪幾個環節；「還剩下什麼」就是哪幾個環節還沒有任何措施能切斷。每多導入一項措施、多切斷幾個環節，就是縱深防禦的意思。 這個框架也有自己的邊界：它以惡意程式入侵為原型。攻擊者若直接用外洩的合法帳號密碼登入，就會跳過投遞、漏洞利用、安裝這幾個環節，專門防守這幾段的措施完全看不到。框架本身，同樣需要知道自己看不到什麼。 好的診斷，必須知道自己不知道什麼 診斷有兩種邊界，常常被混在一起談： 邊界 它描述的是 做不到 工具與措施的能力邊界：某一項防護，本來就處理不了某一類問題。 還不知道 我們對現實世界的認知邊界：從描述推得出「可能」，但要到現場才知道「是不是」。 承認「做不到」，是對讀者誠實；承認「還不知道」，是對方法誠實。後者更難，也更重要。 一份根據企業自行描述所做的診斷，能推論的是「這類設備、在這類條件下，可能形成什麼暴露」。至於那台設備的韌體版本、管理介面有沒有對外開放、帳號密碼是誰在管，這些在沒有實際確認之前，都只是合理的假設。把假設寫成結論，診斷就越界了。 這不是保守，而是工程判斷的基本紀律：知道自己的觀測邊界在哪裡。 把未知，整理成值得確認的問題 承認未知之後，下一步不是停下來，而是把未知轉換成問題。 「這類設備可能存在風險」不是結論。真正有用的下一句是：什麼資訊，可以讓我們確認它到底有沒有暴露？ ✔這台設備的管理頁面，從公司外面連得進去嗎？ ✔它的密碼是誰設的？最後一次更換是什麼時候？ ✔公司的備份，上一次實際還原測試是什麼時候？ ✔曾經出現過的「網路怪怪的」，後來有找到原因嗎？ 每一個問題，都有明確的方式可以回答。這樣一來，診斷就從一份靜態的報告，變成一段認知的過程：能判斷的先判斷，需要確認的，整理成清楚的問題留下來確認。... » read more

0
Read
steven
在資安風暴的第一排，你準備好了嗎？– 從 NIST 網路安全框架談起
在資安風暴的第一排，你準備好了嗎？– 從 NIST 網路安全框架談起

在資安風暴的第一排，你準備好了嗎？ 工程師思路系列 · 資安視角 在資安風暴的第一排，你準備好了嗎？ Mr. τ ／ 風雲網通系統有限公司 PCPiLOT  ·  2026-09-23  ·  資訊安全 / NIST CSF 2.0 / SMB 選購指南 這篇文章，是一個從 1993 年就入行、在 IT 產業走了三十年的人，在看到某些事情之後，忍不住想說的話。 不是要賣你東西。是希望你不要在浪打來的時候，站在最前排。 威脅的速度，已經不是人力能追的 2024 年全年新增 CVE 漏洞超過 40,000 筆——平均每天 110 筆新漏洞被公開揭露。這個數字在 2025 年之後因為 AI 輔助的加持，殺傷力又再倍增。 📖 CVE 是什麼？ CVE（Common Vulnerabilities and Exposures，通用漏洞披露）是一套國際通用的資安漏洞編號系統。每當軟體或硬體被發現有安全漏洞，就會被賦予一個 CVE 編號，例如 CVE-2024-XXXXX，讓全球的資安研究人員和廠商能用同一個語言討論同一個問題。 CVE 的數量，是衡量「現有軟硬體被發現有多少已知漏洞」的直接指標。數字越多，代表攻擊者可以利用的已知破口越多——而修補這些漏洞的速度，往往跟不上它們被公開的速度。 一個以前需要熟練駭客花三天研究的攻擊手法，現在一個毫無技術背景的人用 AI 工具半小時就能複製並發動。攻擊的門檻在下降，速度在提升，目標範圍在擴大。... » read more

0
Read
steven
看不到、摸不著——網路威脅的真實面貌 | PCPiLOT 工程師思路系列
看不到、摸不著——網路威脅的真實面貌 | PCPiLOT 工程師思路系列

工程師思路系列 · 資安視角 看不到、摸不著—— 網路威脅的真實面貌 Mr. τ ／ 風雲網通系統有限公司 PCPiLOT  ·  2026-09-22  ·  資訊安全 / SMB 防禦 / Pico-UTM 陽光、空氣、水、網際網路——現代生活四要素，缺一不可。 喝水，我們會在意水質，濾水器早就是標準配備。 出門，我們會看 PM2.5 和紫外線，狀況不好就減少戶外曝曬。 那麼，同樣列為生活必需的「上網」，我們真的能無憂無慮地使用嗎？ 以下是一個真實企業案例。透過 Lionic Pico-UTM 100 資安閘道器，我們記錄了約一個月的網路威脅情況，把「看不見的東西」視覺化——讓數字說話。 📌 閱讀前提示 以下數字，看得到的代表已經被攔截。看不到的那部分——資安閘道器視角之外的盲區——才是更需要持續關注的地方。 2 件 病毒事件 High 等級・已摧毀 59 件 網頁過濾封鎖 High 23・Medium 36 842 件 入侵防禦攔截 全部 Low・已封鎖或記錄 記錄期間：2026/08/24 – 2026/09/22　｜　內部網段：192.168.123.x 🦠 病毒事件：2 件... » read more

0
Read
steven
從裸奔的 API Key 到全面打通的郵件架構 — 修一個問題，順著脈絡把旁邊的問題也一起收掉。
從裸奔的 API Key 到全面打通的郵件架構 — 修一個問題，順著脈絡把旁邊的問題也一起收掉。

PCPILOT · 工程師思路系列 Pico-UTM 行銷日： 從裸奔的 API Key 到全面打通的郵件架構 修一個問題，順著脈絡把旁邊的問題也一起收掉。 那天的任務很單純：為 Pico-UTM 100 的銷售衝刺準備材料。這批設備有點特別——三年資安服務授權綁定的 700Mbps UTM，價格實在超值到連我自己都先買了一台，是難得一見的尾盤機會。 從早上開始，文件、網頁工具、診斷問卷一份接一份。其中最花工夫的是「企業網路風險自我診斷」工具：業主勾選公司有哪些網路設備，系統依風險模型即時產生報告，同步寄信給業主和業務端。 測試完成，信寄出去，報告顯示正常。完美。然後習慣性地按了 F12。 裸奔的發現 EmailJS 的 Public Key、Service ID、兩組 Template ID，全部白紙黑字在原始碼裡。 📌 什麼是 API Key 裸奔？ 網頁的所有程式碼，任何人都可以用瀏覽器「檢視原始碼」或開發者工具看到。如果服務的金鑰（API Key）直接寫在網頁裡，等同於把保險箱密碼貼在門口。拿到 EmailJS 的 Key，任何人都能冒用你的帳號大量寄信，直到額度用完或帳號被封。 做資安診斷工具的人，自己的工具先裸奔——這個畫面說不過去。當天就決定修掉。 路徑分歧：怎麼選解法 解法不只一條，每條都有代價。 方案 可行性 決定 自架後端伺服器 可行，Key 安全 ❌ 多管一台機器，排除 Resend 前端直打＋Domain 限制 Key 洩漏仍可發詐騙信 ❌ 法律風險，排除... » read more

0
Read
steven
換了高強度密碼還是失守 ——一個 SMB 郵件帳密持續洩漏案例的完整拆解
換了高強度密碼還是失守 ——一個 SMB 郵件帳密持續洩漏案例的完整拆解

部落格：換了高強度密碼還是失守——一個 SMB 郵件帳密持續洩漏案例的工程師視角 資安案例 · 工程師視角 換了高強度密碼還是失守 ——一個 SMB 郵件帳密持續洩漏案例的完整拆解 作者：Mr. τ｜風雲網通系統有限公司（PCPiLOT）｜2026 年 9 月 事件背景 某中小企業客戶的郵件帳號密碼遭到未授權方取得。事發後，來自境外（南非方向）IP 的主機，持續利用代管郵件主機大量對外寄信。 客戶第一次發現問題後更換了密碼。異常行為再度出現。第二次改用高強度密碼——問題仍然持續。 這一刻是整個案件的關鍵轉折點。 「換了高強度密碼還是失守」這件事，不應該被解讀為「密碼被暴力破解」。以現代密碼強度而言，暴力破解的可能性極低。更值得警戒的推斷是：存在某個環節，能在每次密碼更換後持續取得新版本帳密。 這個判斷改變了整個處置策略的方向。 已確認事實 vs. 推論 工程師思路的第一步，是把「確認知道的」和「還不知道的」分開。 已確認事實 郵件帳號遭未授權方取得並實際使用 境外 IP 利用代管主機大量對外寄信 更換密碼後異常行為再度出現，高強度密碼亦未能阻止 公司收發信工作站使用 Windows 7，已超出微軟支援期限 尚待確認（推論，非結論） 密碼洩漏的確切來源，目前有多種可能性，不能單憑現有現象判定： Windows 7 工作站本體漏洞遭利用，帳密被擷取 端點電腦遭 keylogger 或木馬感染 瀏覽器儲存的帳密遭取得 曾在其他地方保存的舊密碼被重複使用 郵件代管服務端或第三方服務發生問題 本次事件確認的是「郵件帳號遭未授權使用」，並非已確認公司內部電腦遭入侵。在釐清洩漏來源之前，任何過度的結論都會誤導處置方向。 處置架構：三層推進 1 立即止血 停用問題帳號，截斷現有入侵管道。重新建立新帳號與密碼，新帳密絕不在原可疑工作站上輸入——若舊電腦本身是洩漏來源，在同一台機器上輸入新密碼，等同於再次把新鑰匙送出去。改以 Windows 11 乾淨電腦作為郵件收發工作站。 2... » read more

0
Read
steven
2026 年 SMB 資安設備完整評析
2026 年 SMB 資安設備完整評析

SMB 資安閘道選購指南 2026｜工程師思路系列 工程師思路系列・事出必有因 PCPiLOT.com.tw 2026 年 SMB 資安設備完整評析 你的防火牆，到底有沒有在看 HTTPS？ 從 NT$3,699 到 NT$54,300，六款設備的真實能力差異， 以及為什麼「買了設備」不等於「有了防護」。 閱讀時間約 10 分鐘 這篇文章的起點，是一個很普通的詢價：「我需要一台防火牆，預算大概幾千塊。」 然後問題就來了——幾千塊能買到什麼？買到的東西，真的能防護什麼？ 我們花了一整天把市面上的選項拆開來看，結果發現，這個問題比想像中複雜得多。 一、問題的根源：現代流量幾乎都是密文 現在的上網流量，絕大多數都走 HTTPS——網路上傳輸的封包是加密的。這件事對資安設備來說是個根本性的挑戰： 傳統防火牆能看到什麼？ ✔ 你連到了哪個 IP、哪個網域（SNI） ✔ 流量大小與行為模式 ✗ 你下載了什麼檔案、網頁裡有什麼惡意腳本、傳輸的內容是否有病毒 這就是為什麼「有買防火牆」和「有防護 HTTPS 流量」是兩件完全不同的事。要真正掃描加密流量的內容，設備必須先把 HTTPS 解密、掃描、再重新加密——這個功能叫做 SSL/TLS Inspection，而它需要的計算資源遠比一般防火牆大得多。 概念解析・工程師白話版 HTTPS 是什麼？為什麼它讓資安掃描這麼難？ ▌ HTTPS 是日常連線的標準，不是例外 HTTPS（HyperText Transfer Protocol Secure）是 HTTP 加上 TLS/SSL 加密層的組合。你現在打開任何一個網站、登入任何帳號、使用任何雲端服務，幾乎都走 HTTPS。它的設計目的是保護使用者隱私——確保資料在傳輸途中不被第三方竊聽或竄改。這是好事，但也帶來了資安防護的根本矛盾。... » read more

1
Read
steven
從防火牆到 AI：資安設備真正累積的，從來不只是防護功能
從防火牆到 AI：資安設備真正累積的，從來不只是防護功能

從防火牆到 AI：資安設備真正累積的，從來不只是防護功能 工程師思路系列 · Mr. τ / 風雲網通系統  |  PCPiLOT 最近在研究 LionFilter 200。原本只是很單純的問題：一台標榜 10GbE、AI、防毒、IPS、惡意網站防護的中小企業 UTM，到底值不值得放進工廠環境？但一路研究下來，我反而想到一件更有意思的事情——我們今天看到的「AI 智能資安」，背後有一條走了二、三十年的路。而真正累積價值的，也許從來不是某一個防毒引擎，而是「資料」。 第一代：防火牆只需要知道「這個封包能不能過」 早期的防火牆，思考方式很單純：來源 IP、目的 IP、Port、Protocol——符合規則就放行，不符合就丟掉。這是一種「規則式」安全模型，工程師先定義什麼可以通過，設備負責執行。 後來攻擊越來越複雜，光看 IP、Port 已經不夠。於是開始加入 Anti-Virus、IDS、IPS、Web Filter、Application Control、Anti-Spam……慢慢形成今天所謂的 UTM。看起來像是把很多安全產品塞進同一台盒子裡，但真正的變化是：設備開始「看懂」網路流量。 第二代：從「封包」走向「行為」 再往後，資安設備開始不滿足於「這個封包有沒有病毒？」，而是開始問： ✔這個使用者在做什麼？ ✔這台電腦平常跟誰通訊？ ✔這個帳號最近是不是突然出現不一樣的行為？ 這就是網路行為分析、UEBA 等思維逐漸成熟的地方。舉例來說：某使用者平常上班時間使用 ERP、Office、Teams，但突然凌晨兩點從一台過去沒見過的裝置登入，開始大量讀取 NAS 資料，並把資料傳到從未連過的國外 IP——單看任何一件，不一定代表攻擊；把它們串起來，就開始有「故事」了。 真正有價值的資安系統，開始從「這個事件有沒有違反規則？」走向「這個行為，跟這個人平常的樣子有多不一樣？」 Palo Alto 這類產品，更早把問題往「行為情報」推 幾年前接觸 Palo Alto 的產品時，就已經看到這種思路。它不是單純把 Firewall、IPS、Application Control 一層一層疊上去，而是把使用者、裝置、App、URL、IP、流量與事件放進同一個上下文裡理解。於是設備看到的不再只是「某個 IP 連到某個 Port」，而是： 某個使用者，從某台裝置，在某個時間，以什麼方式，使用什麼應用程式，產生了什麼網路行為。 這個差別很大。因為「威脅」很多時候不是一個封包，而是一連串行為。 但行為模式從哪裡來？三層基準線... » read more

0
Read
steven