微软 DCOM 补丁对 OPC Classic 客户端和服务端的影响
推荐使用 OPC UA
微软 DCOM 补丁
相关文章：
💧 KB5004442-中文
💧 KB5004442-英文
💧 OPC官方论坛的讨论帖子
💧 CVE 2021 26414-微软漏洞
💧 CVE-2021-26414
微软为了修补 DCOM 的安全漏洞，发了更新补丁。
2021年6月8日，微软发布了针对DCOM的Windows安全更新KB5004442（CVE-2021-26414）——强制更改了Windows操作系统DCOM安全机制。该更新要求DCOM应用程序提供“数据包完整性”身份验证级别，否则可能会出现无法兼容的问题。
分布式组件对象模型（DCOM）远程协议是一种使用远程过程调用（RPC）公开应用程序对象的协议，它支持远程过程调用，并且可用于网络设备的软件组件之间的通信。
会受影响操作系统版本
可用性
这些错误事件仅适用于 Windows 版本的子集;请参阅下表。
| Windows 版本 | 可在这些日期或之后使用 |
|---|---|
| Windows Server 2022 | 2021 年 9 月 27 日KB5005619 |
| Windows 10版本 2004、Windows 10、版本 20H2、Windows 10、版本 21H1 | 2021 年 9 月 1 日KB5005101 |
| Windows 10 版本 1909 | 2021 年 8 月 26 日KB5005103 |
| Windows Server 2019、Windows 10 版本 1809 | 2021 年 8 月 26 日KB5005102 |
| Windows Server 2016、Windows 10 版本 1607 | 2021 年 9 月 14 日KB5005573 |
| Windows Server 2012 R2 和 Windows 8.1 | 2021 年 10 月 12 日KB5006714 |
| Windows 11版本 22H2 | 2022 年 9 月 30 日KB5017389 |
基于 DCOM 的 OPC Classic 存在的安全问题
OPC Classic 缺点
通过传统的DCOM来实现OPC Classic网络通信存在以下两个弊端：
1、设置DCOM时，需要用到的“dcomcfng”服务程序将深入Windows操作系统，因此任何错误的配置调整都可能导致系统不稳定；
2、特别是端口135的开放会造成严重的安全漏洞——应用程序可以通过“远程过程调用（RPC）”来干扰Windows组件，并且毫无限制。实际上，这为许多计算机病毒提供了一个入口。
OPC 安全
（1）动态端口
与大多数应用层协议不同，OPC Classic的基础协议DCOM协议使用动态端口机制，OPC客户端首先向OPC服务器的135端口发起连接，连接成功后再经过OPC服务器分配新端口，并通过应答报文返回给客户端，然后OPC客户端会向服务器的新端口发起连接用来后面数据的传输。
传统防火墙不支持OPC协议的识别解析，为了能够保证OPC业务的正常使用，只能开放OPC服务器的所有可开放端口，而OPC服务器可以分配的端口号范围很广，如果OPC服务器安装在Windows Server 2008，会有超过16000个端口号可能被使用，端口全部开放将使得OPC服务器受攻击面大大增加。
（2）协议缺陷
OPC协议架构基于Windows平台，Windows系统所具有的漏洞和缺陷在OPC部署环境下依然存在。并且，为了实现信息交互的便捷性，所有的Client端使用相同的用户名和密码来读取OPC Server所采集的数据。只要Client端连接，所有的数据都会公布出去，极易造成信息的泄露，也可通过Client端添加数量巨大的数据项使控制系统过载而导致业务中断。
（3）明文传输
专用的工控通信协议或规约在设计之初一般只考虑通信的实时性和可用性，很少或根本没有考虑安全性问题，缺乏强度足够的认证、加密或授权措施等，为保证数据传输的实时性， OPC Classic协议多采用明文传输，易于被劫持和修改指令。
论坛讨论内容
以下内容为 edge 自带的翻译
微软DCOM更新
MS发布了DCOM补丁，该补丁将影响所有销售基于OPC DCOM的产品的供应商：
关键日期：
2021 年 6 月 8 日 - 默认情况下禁用强化更改，但能够使用注册表项启用它们。
2022 年 3 月 8 日 - 默认情况下启用强化更改，但能够使用注册表项禁用它们。
[来自MS的最新信息 - 日期已修订至2022年6月14日]
2022 年 6 月 14 日 - 默认情况下启用强化更改，但无法禁用它们。此时，您必须解决环境中强化更改和应用程序的任何兼容性问题。
[来自MS的最新信息 - 日期已修订为2023年3月14日]
它实际做什么：
需要RPC_C_AUTHN_LEVEL_PKT_INTEGRITY或更高的身份验证级别才能激活。
眼：
将强制实施 DCOM 安全性，因此选择无安全性的应用程序将不再工作。（此问题也可能适用于选择不适当的安全设置的应用程序，或者具有不匹配或超过所需级别的硬编码安全设置的应用程序）
对OPC经典客户端的影响：
客户端权限是使用名为 CoInitializeSecurity 的函数设置的。每个实例只能调用一次此函数;后续调用将不会执行，并将返回错误。如果 OPC 经典客户端调用此函数，则设置基于调用中包含的参数。如果客户端不调用此函数，OS 将根据默认 DCOM 设置代表应用程序调用它。调用此函数的任何客户端都可能需要更改其源代码，以将所需的安全对象（身份验证级别）设置为所需的值（数据包完整性）（如果这不能用作应用程序的配置输入）。不调用 CoInitializeSecurity 的客户端在调用 CoCreateInstanceEx 时应用默认配置，但默认级别将提高数据包完整性。应用程序无法覆盖此设置（即，在其 CoCreateInstanceEx 调用中显式设置身份验证级别的应用程序必须确保它们删除此设置或确保它至少是数据包完整性，因为 CoCreateInstanceEx 中的设置将覆盖。
对OPC经典服务器的影响：
服务器应用程序也可以调用 CoInitializeSecurity，但大多数服务器通常在 DCOMCNFG 实用程序中指定建立通信的权限。因此，在 DCOMCNFG 中修改自定义权限将确定要使用的安全设置。只要服务器使用 DCOMCNFG 实用程序，任何问题都更易于管理。仍需要检查应用程序设置。
其他选项：
而不是更新经典应用程序 - 更新它以使用 OPC UA
考虑添加一个代理/包装器来将应用程序推向OPC UA（代理/包装器从经典产品中消除了DCOM-它们使用COM，然后使用OPC UA进行网络通信。
