文章总结： OPCUA是一种用于工业自动化和过程控制系统的安全通信协议，具有平台无关性和传输无关性。文章详细介绍了OPCUA的常见端口（如4840、4843等）、三层安全架构（传输层、会话层、应用层）、完整通信流程（从Hello握手到断开连接）以及消息格式。文章强调了OPCUA的安全特性，如加密、签名和访问控制，并建议在生产环境中使用加密端口和X.509证书认证以提高安全性。
综合评分： 84
文章分类： IoT安全,网络安全,应用安全,漏洞分析,安全建设
【大话工控安全】工业控制系统基础知识之常见工业协议家族OPC UA协议分析
原创
老付话安全
老付话安全
2025年11月25日 20:33
山东
OPC UA协议分析
OPC UA（开放平台通信统一架构）是一种用于工业自动化和过程控制系统的协议。它是一种机器对机器通信协议，允许各种工业设备之间无缝通信。OPC UA 为设备、机器和控制系统之间提供了一种安全可靠的通信通道，无论制造商或平台如何。它被设计为平台无关，这意味着它可以在不同的操作系统和硬件平台上运行。
OPC UA 的设计精髓之一就是其传输无关性。它定义了一个统一的应用层协议和信息模型，然后可以通过不同的底层传输协议来实现通信，以适应各种场景的需求。
OPC UA 采用客户端-服务器架构，其中客户端通常是请求数据的软件应用或边缘设备，而服务器则是提供数据的设备或系统。它支持多种数据类型，包括文本、数字和二进制数据，并且可以在不同的传输层（如 TCP/IP、HTTP 或 MQTT）上传输信息。由于其互操作性、可靠性和安全性（如授权、认证和加密）等特性，该协议已成为工业自动化行业广泛采用的标准。它被应用于制造、能源、楼宇自动化和交通系统等多种场景。
OPC UA 常见端口
1. 标准未加密端口
- 4840：这是 OPC UA 规范为 UA Binary 协议分配的官方默认端口。绝大多数OPC UA服务器和客户端在非安全模式下会使用这个端口。
- 80：当OPC UA使用 HTTP 或 WebSocket 进行通信时（通常用于Web集成或穿越防火墙），可能会使用标准的HTTP端口80。
2. 标准安全端口
- 4843：这是 OPC UA 规范为基于TLS/SSL加密的UA Binary协议推荐的默认端口，类似于HTTPS的443端口。使用此端口可以确保通信的机密性和完整性。
- 443：当OPC UA使用HTTPS 或 安全的WebSocket 进行通信时，会使用标准的HTTPS端口443。
3. 其他与发现相关的端口
- 4840 或 4841：除了常规通信，4840端口也常用于服务器发现。在一些部署中，可能会使用 4841 作为专门的发现服务器端口。
OPC UA 规范定义的这些端口是推荐而非强制的。在实际的工业产品或软件中，管理员几乎总是可以更改这些端口号。例如，出于安全策略或避免端口冲突的考虑，完全可以将UA Binary服务器配置在8080或其他任意端口上运行。生产环境强烈建议使用加密端口（如4843），并配置X.509证书进行身份验证，避免使用未加密的4840端口，以防数据被窃听或篡改。通过更改默认端口，可以一定程度上减少来自互联网的自动化扫描和攻击。
| 端口号 | 协议类型 | 安全状态 | 主要用途 |
| — | — | — | — |
| 4840 | UA 二进制 / 发现 | 未加密 | OPC UA二进制协议的标准端口，也用于服务器发现 |
| 4843 | UA Binary over TLS/SSL | 加密 | OPC UA安全通信的推荐端口 |
| 80 | HTTP / WebSocket | 未加密 | 用于Web服务或穿越严格防火墙 |
| 443 | HTTPS / Secure WebSocket | 加密 | 用于安全的Web服务通信 |
| 1883 | MQTT | 通常未加密 | OPC UA over MQTT 的默认端口（非OPC UA原生定义，属MQTT标准） |
| 8883 | MQTT over TLS/SSL | 加密 | 安全的MQTT通信端口 |
在OPC UA规范中定义了三个层级：传输层、会话层、应用层。
传输层使用TLS/SSL协议（对于基于TCP的UA Binary）或 HTTPS（对于SOAP-HTTP）来为整个通信链路提供传输级安全。这可以防止网络层面的窃听和篡改。
会话层使用应用程序实例证书：每个OPC UA客户端和服务器都拥有一个唯一的X.509证书，作为其在网络中的“数字身份证”。在建立会话时，客户端和服务器会交换并验证对方的证书。服务器会检查客户端证书是否受信任，客户端同样会验证服务器证书的真伪（防止连接到假冒服务器）。安全策略协商：双方会协商后续通信使用的安全策略，包括签名、加密的算法和密钥长度
应用层保障用户身份和数据操作的安全，实现访问控制。实现方式：
- 用户身份认证：在会话建立后，客户端必须提供用户凭证。OPC UA支持多种方式：用户名/密码、X.509用户证书、基于令牌的认证。
- 消息级安全：这是OPC UA最核心的安全特性。所有在会话中交换的应用层消息（如读取一个数据点、响应一个报警）都会受到保护：
签名：对消息进行数字签名，确保消息的完整性和不可否认性，防止在传输过程中被篡改。
加密：对消息的有效载荷进行加密，确保数据的机密性，即使被截获也无法读取。
基于角色的访问控制：服务器维护一个访问控制列表，根据认证通过的用户身份及其所属角色，来授权其可以执行哪些操作（读、写、执行方法、订阅事件等）。
简单比喻：身份确认后，双方开始谈具体的商业机密。每一条信息都用只有双方能懂的密码本书写（加密），并且附上无法伪造的签名（签名）。同时，服务器会根据你的职位（角色），决定你是否有权查阅“财务报表”或只是“公司通讯录”。
OPC UA通信流程
OPC通信流程大概分为如下几个阶段：
- 发送Hello报文（客户端首先向服务端发送一个 Hello报文，表示即将建立连接并提供自身的一些连接参数，如协议版本、URL、最大消息大小、接收缓冲区大小、最大消息长度等）
- 服务器返回Ack确认报文（服务端接收到 HELLO 报文后，会返回一个 Acknowledge（简称 ACK）报文，确认可以进行连接，并提供服务端自身的连接参数）
- 客户端请求建立OPN安全通道（建立一个安全通道，
- 服务器OPN ResponseOPN 响应（通常服务端会返回一个 SecureChannelID（安全通道 ID），用于后续安全通信的标识。该安全通道用于加密和签名 OPC UA 报文，以保证通信的机密性与完整性）
- MSG类型信息通信创建会话（客户端和服务端将通过 Message类型的报文进行业务数据的传输。这些消息封装了实际的服务请求与响应（如读取、写入、订阅等），并在安全通道内进行加密和完整性保护）。客户端在安全通道内发送创建会话请求；CreateSession Response创建会话响应服务器返回会话ID和认证信息。
- MSG: ActivateSession消息：激活会话，客户端激活会话（提供用户凭证）
- ActivateSession Response激活会话响应，服务器确认会话激活。至此，会话建立完成
- #### 浏览和监控配置MSG: 浏览MSG，客户端浏览服务器地址空间，查找需要的数据节点
- Browse Response浏览响应服务器返回浏览结果（节点列表）
- CreateSubscriptionMSG: 创建订阅MSG，客户端创建订阅（设置发布间隔等参数）
- CreateSubscription Response创建订阅响应，服务器返回
SubscriptionId订阅创建完成。 - MSG: MonitoredItemsCreate客户端在订阅中创建监控项（指定要监控的数据节点）
- MonitoredItemsCreate 服务器返回
MonitoredItemId和初始值，监控项设置完成 - CLO报文断开连接（客户端会发送一个 CloseSecureChannelRequest 报文，请求关闭安全通道并断开连接。服务端响应 CloseSecureChannelResponse 报文后，双方连接正式断开）。
OPC UA协议格式
通用OPC UA TCP的消息包含一个消息头和消息体：
消息头通常包含消息类型、编码方式、消息长度等关键信息，用于标识通信目的和数据结构；
消息体则承载实际的数据内容，如会话建立、服务请求或数据传输等操作所需的参数和响应内容。这种结构便于消息的快速解析与处理，适用于工业通信对低延迟与高可靠性的要求
UA 安全会话消息
- 整个消息由“加密数据”和“签名数据”构成，其中包括消息头、对称/非对称安全头、序列头、消息体、填充和签名等字段。
- 消息头用于标识消息类型和长度，安全头携带安全策略和证书信息，序列头用于防止重放攻击，
- 消息体承载实际业务数据，填充和签名则确保消息的完整性与机密性。通过该结构，OPC UA 实现了分块加密、安全认证和完整性校验，是其安全通信机制的核心基础。
OPC UA over TCP 握手过程
阶段一：TCP连接与Hello握手（底层传输建立）
- TCP三次握手
- 客户端向服务器的知名端口（通常为4840）发起标准的TCP三次握手（SYN, SYN-ACK, ACK）。这一步与普通的网页浏览建立TCP连接没有区别。
- Hello消息交换（HEL）
-
ProtocolVersion：协议版本。 -
ReceiveBufferSize：接收缓冲区大小。 -
SendBufferSize：发送缓冲区大小。 -
MaxMessageSize：单条消息的最大长度。 -
MaxChunkCount：单个消息最多可以分成的块数。 -
TCP连接建立后，客户端和服务器立即相互发送一条
HEL消息。 -
目的：这不是一个请求-响应，而是一个双向握手。用于在建立安全通道之前，协商最基本的通信参数：
-
如果双方参数兼容，则继续；否则，会关闭TCP连接。
阶段二：安全通道建立（SecureChannel – 通信安全层）
- 打开安全通道（OPN）
-
SecurityPolicy：安全策略（如None,Basic256Sha256等），决定使用的加密算法套件。 -
MessageSecurityMode：消息安全模式（如None,Sign,SignAndEncrypt）。 -
ClientNonce：客户端生成的随机数，用于生成密钥。 -
RequestedLifetime：请求的安全通道有效期（毫秒）。 -
客户端发送
OPN消息，这是一个OpenSecureChannel请求。 -
目的：建立一个安全上下文，用于对后续所有
MSG进行加密、签名和身份验证。 -
关键参数：
- 安全通道响应
-
SecurityToken：一个安全令牌，包含了唯一的TokenId、创建时间、修订号和服务器生成的ServerNonce。 -
RevisedLifetime：服务器同意的安全通道实际有效期。 -
服务器处理请求，生成
SecurityToken并通过OPN Response返回给客户端。 -
关键参数：
至此，SecureChannel 建立完成。 后续所有的 MSG 都会使用这个通道协商的密钥进行签名和（可选地）加密。一个SecureChannel上可以承载多个Session。
阶段三：会话建立（Session – 应用逻辑层）
- 创建会话（MSG: CreateSession）
- 客户端在安全的SecureChannel内，发送第一条
MSG类型的应用层消息——CreateSession请求。 - 目的：在客户端和服务器之间建立一个逻辑上的、有状态的会话。会话包含了应用层的上下文信息，如用户身份、订阅等。
- 关键参数：端点URL、应用程序描述、服务器URI等。
- 创建会话响应
- 服务器返回
CreateSession Response，包含一个唯一的SessionId以及服务器支持的认证机制等信息。
- 激活会话（MSG: ActivateSession）
- 客户端发送
ActivateSession请求，以真正启动这个会话。 - 目的：这是用户认证发生的地方。客户端提供用户凭证（如用户名/密码、X.509证书等）。
- 服务器验证凭证后，会话才进入活动状态，可以处理业务请求。
至此，Session 建立并激活完成。 现在客户端可以开始进行浏览地址空间、读取数据、创建订阅等操作。
结束
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：老付话安全 老付话安全《【大话工控安全】工业控制系统基础知识之常见工业协议家族OPC UA协议分析》