S7 COM PLC狀態查詢 - 讓你知道攻擊是否生效

好的,這是一個非常實際的問題,在進行網路監控或開發自己的客戶端時至關重要。 要從 S7 封包中判斷 PLC 的狀態 (主要是 RUN 或 STOP),沒有一個固定的欄位存在於每一個封包中。您必須透過攔截並解析特定的請求-回應 (Request-Response) 封包組合來實現。 以下是三種主要的方法,從最直接到最間接: 方法一:主動查詢系統狀態列表 (Read SZL) - 最準確的方法 這是最標準、最可靠的作法。您的應用程式(或您正在監控的客戶端)會主動向 PLC 發送一個「讀取系統狀態列表」的請求,PLC 會在回應中明確告知其當前狀態。 要觀察的封包:【請求】 您會看到一個由客戶端發往 PLC 的封包。 PDU 類型 (ROSCTR): 0x07 (Userdata) 參數 (Parameters): 在 Userdata 的參數部分,會包含一個「Read SZL」(讀取 SZL) 的子功能請求。 關鍵識別碼 (SZL ID): 請求中會指定要讀取的 SZL ID。用於查詢 CPU 狀態的 ID 通常是 0x0424 或 0x0132 (取決於 CPU 型號和韌體)。 要觀察的封包:【回應】 PLC 會回覆一個 PDU 類型為 0x03 (Ack_Data) 的封包。 這個封包的資料區 (Data) 就包含了您要的狀態資訊。 如何判斷 (解析回應封包的 Data 區): _ 在 SZL 回應的資料區中,會有一個特定的位元組 (Byte) 用來表示 PLC 的運行狀態。 ...

S7 COM 功能碼介紹 - 懂了就能任意操控西門子PLC

1. 連線與會話管理 (Connection & Session Management) 這是在進行任何其他操作之前,建立通訊所必需的功能。 功能碼 (Hex) 功能名稱 說明 0xF0 Setup Communication 設定通訊。這是三階段交握的最後一步,用於客戶端 (Client) 與 PLC 之間協商通訊參數,例如 PDU (協定資料單元) 的最大長度和可同時處理的任務數量。 2. 核心資料讀寫 (Core Data Access) 這是最基本也是最常用的功能,用於與 PLC 的記憶體區域進行互動。 功能碼 (Hex) 功能名稱 說明 0x04 Read Variable 讀取變數。從指定的記憶體區域讀取一個或多個變數的值,例如輸入 (I)、輸出 (Q)、旗標 (M)、資料塊 (DB) 等。 **0x05 Write Variable 寫入變數。將一個或多個值寫入到指定的記憶體區域。 3. PLC 狀態控制 (PLC State Control) 這些功能用於改變 CPU 的運行模式。 功能碼 (Hex) 功能名稱 說明 0x28 PLC Control PLC 控制。這是一個多功能命令,透過不同的參數可以實現:<br>- Start (啟動)<br>- Hot Restart (熱啟動)<br>- Cold Restart (冷啟動) 0x29 PLC Stop PLC 停止。將 CPU 的模式從 RUN 切換到 STOP,停止使用者程式的執行。 4. 程式區塊操作 (Program Block Operations) 這些功能主要由 TIA Portal 或 STEP 7 等工程軟體使用,用於程式的上傳和下載。 ...

IEC 62443 系列教學 (六):邁向認證之路:準備工作與實戰指南

寫在前面:從學徒到主廚,迎接米其林評鑑的挑戰 恭喜你,堅持走到了這裡!在過去五篇文章中,我們一起: 認識了 IEC 62443 這本「食譜」(Art 1)。 學會了為客人「診斷」並決定「菜色」(Art 2: 風險評估與 SL 選擇)。 掌握了每道菜的「烹飪技巧」(Art 3: FR 詳解)。 理解了維持廚房「品質與衛生」的標準 (Art 4: SAR 解析)。 演練了完整的「診斷流程」(Art 5: 深度風險評估)。 現在,你已經從一個廚房學徒,成長為一位能獨當一面的主廚。而接下來的挑戰,就是迎接美食界的最高榮譽——米其林星級評鑑,也就是我們最終的目標:取得 IEC 62443 認證。 這篇文章,就是你的「米其林迎檢手冊」,將指導你如何將所有知識付諸實踐,成功摘星。 認證之路的四大階段 將認證視為一個正式的專案,並依循以下四個階段來推進,將會事半功倍。 階段一:專案啟動與規劃 (Initiation & Planning) 精神:方向對了,就不怕路遠。 取得管理層的支持 (Get Management Buy-in) 這是所有工作的第一步,也是最重要的一步。利用你在第五篇學到的風險評估報告,向管理層清楚地說明:我們面臨什麼風險?若不處理,最壞的後果是什麼?導入 IEC 62443 能帶來什麼價值(不只是合規,更是提升營運韌性與市場競爭力)?把這件事從一個「成本支出」,重新定位為一個「必要的投資」。 成立認證專案小組 (Form the Project Team) 再次強調,這需要一個跨部門的團隊。除了 OT、IT、工程師外,務必指派一位專案經理 (PM) 來負責統籌進度、溝通協調與資源分配。 明確定義認證範圍與目標 (Define Scope & Goal) 和你的團隊及高層,精準地定義: 我們要認證的系統 (SUC) 是什麼? 目標安全等級 (SL-T) 是多少? 這將是你們與認證機構簽訂合約的基礎。 選擇合適的認證機構 (Choose a Certification Body) 尋找在工控領域有豐富經驗且具備公信力的第三方認證機構(如:TÜV、SGS、DNV、UL 等)。在選擇時,可以考量他們的產業實績、稽核員的專業背景以及溝通的順暢度。 ...

IEC 62443 系列教學 (五):如何像專家一樣進行風險評估

寫在前面:從基礎健檢到專家的深度診斷 在過去的文章中,我們已經了解,從選擇安全等級 (SL) 到實作基礎要求 (FR),再到準備保證文件 (SAR),這一切的源頭都指向一個核心動作——風險評估。 在第二篇文章中,我們對風險評估做了一次「基礎健康檢查」,了解了它的基本概念。而今天,我們要進行的是「專家的深度診斷」。這意味著我們將學習一套更系統、更嚴謹的方法,一步步地找出系統的潛在病灶,並開出最精準的處方。 這篇文章將以 IEC 62443-3-2(工控系統安全風險評估標準)的精神為藍本,為您呈現一份清晰的實戰操作指南。 專家級風險評估的四大步驟 一個專業的風險評估,絕不是天馬行空的想像,而是一個有結構、有紀律的過程。 步驟一:準備與範疇定義 (Preparation & Scoping) 精神:沒有好的準備,就沒有好的開始。 在動手分析之前,必須先做好功課,這一步至關重要。 組建黃金團隊: 風險評估絕對不是資安或 IT 人員的獨角戲。你的團隊必須包含: 操作人員 (OT):他們最了解生產流程與日常操作。 控制工程師:他們懂系統架構與設備細節。 廠務/維護人員:他們了解實體環境與維護流程。 IT/資安人員:他們提供資安專業知識與威脅情資。 工廠管理層:他們能從業務衝擊的角度提供觀點,並給予支持。 定義評估範疇 (SUC): 明確定義本次要評估的「待議系統 (System Under Consideration, SUC)」是什麼。是「整座晶圓廠」,還是「三號鍋爐的燃燒控制系統」?範圍定義得越清楚,後續的分析就越聚焦、越準確。 收集基礎資料: 盡可能收集所有相關文件,例如: 網路架構圖 資產清單 (包含 PLC, HMI, Server 等) 製程流程圖 (P&ID) 現有的安全政策與程序 步驟二:系統分割與高階評估 (Partitioning & High-Level Assessment) 精神:化整為零,優先處理高風險區域。 直接分析一個龐大的系統是不切實際的,我們需要先進行分割和篩選。 劃分區域與管道 (Zoning): 將 SUC 依照功能、實體位置或網路分段,劃分成數個較小的「區域 (Zone)」。例如,一個「鍋爐安全儀控系統 (SIS)」可以是一個 Zone,而「生產數據歷史資料庫」則是另一個 Zone。 進行高階風險篩選: 針對每個劃分好的 Zone,快速地問一個問題:「如果這個 Zone 完全癱瘓,對工廠造成的最大衝擊是什麼?」 ...

IEC 62443 系列教學 (四):安全保證需求 (SAR) 的深度解析

寫在前面:如何證明你蓋的堡壘真的很堅固? 在前面的文章中,我們已經學會了如何選擇目標安全等級 (SL),並了解了為了達標,必須實作哪些基礎要求 (FR)。這就像我們已經拿到了一份詳細的「堡壘設計藍圖」,上面標明了需要多厚的牆 (FR3)、多堅固的門 (FR1)、多嚴密的崗哨 (FR2) 等等。 現在,一個更深層次的問題來了:你如何證明這座堡壘是嚴格按照藍圖建造的?你怎麼能相信建造過程沒有偷工減料?當堡壘建成後,你又如何確保它能被妥善地維護,而不是逐漸荒廢? 回答這些問題的核心,就是我們今天的主角——安全保證需求 (Security Assurance Requirements, SAR)。SAR 關乎的不是「有什麼功能」,而是「這些功能的品質與可信度有多高」。 一、FR 與 SAR 的根本區別:建材 vs. 施工品質 為了徹底理解 SAR,我們必須先釐清它與 FR 的根本不同。讓我們用「建造一棟大樓」來比喻: 比較項目 基礎要求 (FR) 安全保證需求 (SAR) 核心焦點 技術功能 (The “What”) 流程與證據 (The “How Well”) 回答問題 「大樓用了哪些建材?」 「施工品質如何?有沒有偷工減料?」 具體例子 是否用了防火門?(FR1) 是否有監視器?(FR6) 防火門的檢驗報告在哪? 監視器系統的測試紀錄? 工地的施工日誌? 最終目標 具備安全「能力」 證明安全能力是「可信賴」且「可持續」的 簡單來說,FR 是產品規格書上的功能列表,而 SAR 則是證明這些功能被正確設計、嚴謹測試、並被妥善維護的全套「履歷與證明文件」。只有 FR,沒有 SAR,就相當於一個宣稱自己很安全的「口說無憑」的系統。 二、SAR 的核心支柱:建立信任的流程 IEC 62443-3-3 中定義的 SAR,可以被歸納為三大核心支柱,它們共同構成了從設計到維運的完整信任鏈。 支柱一:安全的設計與文件 (Secure by Design) 精神:安全不是事後補救,而是從一開始就內建於 DNA 中。 這要求在專案的最初階段就把安全考慮進去,並留下完整的文件紀錄。 ...

IEC 62443 系列教學 (三):七大基礎要求 (FR) 詳解與實踐心法

寫在前面:拿到藥方後,該如何精準用藥? 在前面的文章中,我們學會了如何「診斷病情」(風險評估)並開立「藥方」(選擇目標安全等級 SL-T)。現在,我們手上拿著一張寫著「SL2」或「SL3」的藥方,接下來最關鍵的問題是:這張藥方對應的具體藥物和劑量是什麼? 這篇文章,就是這份「用藥說明書」。我們將逐一拆解七大基礎要求(Foundational Requirements, FR),詳細說明在不同的安全等級(SL)下,每一個要求需要做到什麼程度。 可以這樣比喻: 這 7 個 FR 就像學校裡的 7 個科目(國文、數學、英文…),而安全等級 SL 就像是你需要達成的成績目標(及格、良好、優秀)。想拿到「優秀 (SL3)」的成績,你在每個科目上需要付出的努力和達到的標準,自然遠高於「及格 (SL1)」。 七大基礎要求的 SL 等級演進 以下,我們將深入探討每個 FR 從 SL1 到 SL4 的要求是如何層層遞進的。 FR 1 - 識別與認證控制 (Identification and Authentication Control) 核心精神:「確認你是誰,並驗證你的身份。」 SL 1 (基本要求): 為每位使用者(包含操作員、維護人員)提供唯一的帳號。 使用密碼進行身份驗證。 SL 2 (強化要求): 實施強密碼原則(例如:長度、複雜度、定期更換)。 導入角色為基礎的存取控制 (RBAC),不同角色(如操作員 vs. 工程師)擁有不同帳號。 SL 3 (專業要求): 強制使用多因子認證 (MFA),例如:密碼 + 手機驗證碼。 具備集中式的帳號管理機制(如:整合 Active Directory)。 SL 4 (最高要求): 使用更先進的 MFA(如:生物辨識、智慧卡)。 對所有遠端連線強制執行 MFA。 嚴格的連線逾時與工作階段管理。 FR 2 - 使用控制 (Use Control) 核心精神:「即使你進了門,也只能做你被允許做的事。」 ...

IEC 62443 系列教學 (二):風險評估與安全等級的選擇藝術

寫在前面:拿到地圖後,如何決定目的地? 在上一篇文章中,我們一起認識了 IEC 62443 這張工控資安的「世界地圖」,了解了它的基本構成、七大基礎要求 (FR) 以及四個安全等級 (SL)。 現在,我們手握地圖,但問題來了:我的系統究竟該前往哪個目的地?是需要輕裝簡行的 SL1,還是固若金湯的 SL4? 這篇文章的核心任務,就是教您如何像一位專業的領航員,透過「風險評估」這項工具,為您的系統選擇出最恰當、最不浪費資源的目標安全等級 (Security Level Target, SL-T)。這不僅是技術,更是一門權衡的藝術。 一、風險導向:工控資安的核心哲學 在開始之前,我們必須先建立一個核心觀念:沒有所謂「100% 的安全」。 資安的目標不是打造一個絕對無法入侵的系統 (那不切實際且成本極高),而是將風險降低到一個可接受的程度。這就是「風險導向 (Risk-Based)」方法的精髓。 想像一下醫生看診:一位病人只是輕微感冒,另一位是心臟病發。醫生絕不會給兩者開立相同的藥方。他會先診斷病情 (評估風險),然後對症下藥 (給予相應的防護)。 在工控資安中,這個「診斷」過程,就是風險評估。一個基本的風險概念可以這樣理解: 風險 = 衝擊 (Impact) × 可能性 (Likelihood) 衝擊 (Impact):如果壞事發生了,後果有多嚴重?(例如:產線停擺、工安意外、環境污染) 可能性 (Likelihood):這件壞事發生的機率有多高?(取決於威脅來源與系統的脆弱性) 我們的目標,就是找出那些「高衝擊、高可能性」的環節,並投入最多的資源去保護它。 二、第一步:劃分區域,精準防護 (Zoning) 在評估整個工廠的風險之前,直接把整座工廠當成一個單位來分析,會非常困難且不精確。IEC 62443 提供了一個聰明的方法:區域與管道 (Zones and Conduits)。 區域 (Zone):將功能類似、資安需求相近的設備圈在一起,形成一個個獨立的「安全區域」。 管道 (Conduit):連接不同區域的網路通訊路徑,就像是區域之間的「橋梁」或「通道」。 生活化比喻:設計一棟安全的豪宅 整棟豪宅:就是你的整個工廠系統 (System under Consideration, SUC)。 區域 (Zones): 臥室/書房 (Zone 1):存放個人貴重物品,需要較高的安全防護。 客廳/廚房 (Zone 2):訪客可以進入,安全需求相對較低。 車庫 (Zone 3):有獨立的出入口,需要特別的管理。 管道 (Conduits):連接各個房間的走廊、門、窗戶。你需要確保門是鎖好的,窗戶是堅固的。 為什麼要這麼做? 因為你可以為「臥室」設定 SL3 的高防護等級,同時為「客廳」設定 SL1 的基本防護。這樣既能確保重點區域的安全,又不會把成本浪費在不必要的地方。分區管理,是實現成本效益最大化的關鍵第一步。 ...

IEC 62443 系列教學 (一):輕鬆讀懂工控資安聖經 IEC 62443

寫在前面:為何你的智慧工廠需要一本資安說明書? 歡迎來到 IEC 62443 的世界!如果說智慧工廠、工業物聯網 (IIoT) 是現代工業的未來,那麼 IEC 62443 就是確保這個未來能夠安全、穩定運作的關鍵說明書。它被公認為全球最權威的工業控制系統 (ICS) 資安標準。 這個系列文章的目標,是帶你用最沒有壓力的方式,從零開始,一步步看懂 IEC 62443-3-3 這份重要的系統安全規範。 本系列文章規劃: 輕鬆讀懂工控資安聖經 IEC 62443 ← 本篇 系統安全需求與安全等級的選擇藝術 七大基礎要求 (FR) 詳解與實踐心法 安全保證需求 (SAR) 的深度解析 如何像專家一樣進行風險評估 邁向認證之路:準備工作與實戰指南 一、什麼是 IEC 62443?為何它如此重要? 標準的誕生故事 IEC 62443 (其前身為 ISA-99) 是由國際電工委員會 (IEC) 為了保護工業自動化與控制系統 (IACS) 而制定的網路安全標準。你可以這樣理解它的演進: 過去 (1990s~2000s):隔離就等於安全 工廠的控制系統自成一個封閉的小世界,與世隔絕,大家認為只要物理上不被接觸就是安全的。 近代 (2000s~2010s):IT 與 OT 的碰撞 為了提升效率,工廠開始將辦公室網路 (IT) 與生產線網路 (OT) 連接起來,但當時還沒有一套專為工廠環境設計的資安規則。 現在 (2010s~至今):智慧工廠的專業保鑣 隨著智慧製造的興起,連網設備暴增,攻擊風險也隨之而來。IEC 62443 因此應運而生,成為守護工廠的專業資安標準。 工廠的資安,為何不能直接用辦公室那套? 你可能會想:「公司不是已經有 IT 資安團隊了嗎?直接請他們來保護工廠不行嗎?」答案是:不行。因為 IT 與 OT (營運技術) 環境的 DNA 截然不同。 ...

Modbus TCP 深度解析 (六):防護策略與安全最佳實務

0x00 系列總結與防護概述 歡迎來到 Modbus TCP 深度解析系列的最終篇!在前面五集中,我們從基礎協議學到了攻擊技術,現在是時候學習如何保護我們的工控系統了。 系列回顧: 協議基礎與封包結構 - 理解 Modbus TCP 基本原理 功能碼詳解與實戰範例 - 掌握各種操作功能 資料模型與地址空間 - 深入資料組織方式 錯誤處理與異常診斷 - 學習故障排除技術 安全威脅與攻擊分析 - 了解潛在威脅 0x01 從真實攻擊事件學習防護策略 MITRE ATT&CK for ICS 框架概述 MITRE ATT&CK for ICS 是專門針對工控系統的攻擊技術框架,將攻擊生命週期分為以下階段: 🎯 Initial Access (初始存取) ↓ 🔍 Discovery (偵察發現) ↓ 🏃 Lateral Movement (橫向移動) ↓ 🎛️ Collection (資料收集) ↓ 💥 Impact (影響破壞) 讓我們透過真實案例來了解每個階段的防護策略。 案例研究 1:烏克蘭電網攻擊事件 (2015 年) 事件背景: 2015 年 12 月 23 日,烏克蘭西部電力公司遭受網路攻擊,導致約 23 萬居民停電數小時。這是全球首起確認由網路攻擊導致的大規模停電事件。 ...

Modbus TCP 深度解析 (五):安全威脅與攻擊手法分析

0x00 前情提要 在前一集中,我們學習了錯誤處理和診斷技術。今天我們要從資安的角度深入分析 Modbus TCP 的安全威脅,這對於保護工控系統至關重要。 上集練習題答案: 練習 3:錯誤封包分析 00 05 00 00 00 03 01 86 03 解析: - Transaction ID: 0x0005 - 錯誤功能碼: 0x86 (0x06 + 0x80) = 寫入單個暫存器錯誤 - 異常碼: 0x03 = Illegal Data Value - 問題:嘗試寫入的數值超出允許範圍 0x01 Modbus TCP 安全弱點分析 協議層面的安全缺陷 Modbus TCP 協議設計於工業環境安全性要求較低的年代,存在以下根本性安全問題: ┌─────────────────────────────────────────────────────────┐ │ Modbus TCP 安全弱點 │ ├─────────────────┬───────────────────────────────────────┤ │ 認證機制 │ ❌ 無內建身份驗證 │ │ 加密保護 │ ❌ 明文傳輸,無加密機制 │ │ 授權控制 │ ❌ 無存取權限控制 │ │ 完整性檢查 │ ❌ 無資料完整性驗證 │ │ 防重放攻擊 │ ❌ 無時間戳或序號保護 │ │ 會話管理 │ ❌ 無安全會話機制 │ └─────────────────┴───────────────────────────────────────┘ 攻擊面分析 網路層 ←→ TCP 層 ←→ Modbus 應用層 ←→ 設備層 ↓ ↓ ↓ ↓ 網路掃描 連線洪水 協議攻擊 設備控制 ARP 偽造 TCP 劫持 功能碼濫用 參數篡改 連線注入 資料注入 韌體攻擊 0x02 網路層攻擊技術 網路探測與指紋識別 攻擊者首先會進行網路偵察,識別 Modbus 設備: ...