從硬體架構、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