OPC包深度解析及工业防火墙 (上)

上篇带大家分析了一下服务端的软件,现在更进一步,对OPC的包进行深度解析。OPC使用的RPC协议和其它的工控协议有所不同,如Modbus协议服务端的固定端口是502,RPC协议在真正建立数据连接之前通讯双方要协商使用的服务端口,即要有一个绑定的过程。基于RPC协议本身的定义,RPC建立连接时有一个固定的135号端口供客户端绑定专用,然后RPC从服务端的端口池(1024 ~ 65535)中选一个未使用的端口返回给客户端(如下图中的1118)。客户端以后用此端口作为后续真正请求使用的端口。注意该端口是动态暂时的,该会话结束若再请求的话会得到一个不同的端口。具体的RPC访问初始绑定建立的过程见下图。

注意这里的ISystemActivator接口,它是负责真正地请求和返回服务端口的连接,但也不是唯一能达到此目地的接口,后面会另外介绍另一个接口也可以返回动态端口。

Windows下的RPC是基于TCP协议的,它的丰富的PDU(Protocol Data Unit)有二十多种不同的类型,有的负责绑定(11-13),有的负责请求和响应(0,2)。也有的是维护连接的长期有效(1)。本文关心的主要是请求/应答和绑定类型。

使用自创的OPC三合一客户端程序(见该篇),在建立一个实例前设置断点,然后启动Wireshark,运行客户端完成一个读操作,获得相应的一系列捕获的包,见下,

这张图片给了我们什么信息?我们看到,这是一个请求(0)类型的PDU,它的协议栏标为ISystemActivator接口而不是DCERPC,该接口下被调用的函数是RemoteCreateInstance,操作代码(Opnum)是4。请求方的端口在某个时间点从135变成了53286,而这个时间点正是ISystemActivator协议应答后发生的,由此我们有理由相信这个应答带回了动态端口信息,需要仔细审视。也许有人会问在协议栏,为什么标为ISystemActivator,不像其它行一样标为DCERPC?这里涉及到COM和DCOM及DCERPC的区别。COM一般都定义在IDL文件中,需要注册才能被用户使用。DCOM一般是系统使用,它只定义了一些有限的接口,而这些接口有的并没有在注册表出现,因为不是供用户使用的,比如ISystemActivator,IRemoteActivation等等。DCOM接口如下,

由此可见,DCOM是一些特殊的DCERPC请求/应答PDU,是微软平台下专有的接口,因此在协议栏中使用接口名称而不是一般的DCERPC。那么ISystemActivator到底是什么?查看源码,

获得了ISystemActivator的uuid,000001A0-0000-0000-C000-000000000046,但是如果搜索注册表却找不到它的相关信息,因为它不是给用户使用的,用户也不应直接调用。根据uuid再查相关信息,

看来ISystemActivator改名了,现在叫IRemoteSCMActivator,进一步查下它,

我们没有微软的相应IDL来查看该接口,但从文档上可以看到IRemoteSCMActivator接口下共有五个函数,最后一个就是抓包中所展现的RemoteCreateInstance,它相应的Opnum值是4,也就是说它是该接口下的第五个函数。看到这里大家应该对Opnum有个概念了,其实它是用来表示接口下的函数顺序,告诉服务端我要调用某个接口下的第x个函数。

绕了一大圈,有了这些铺垫,现在专注于ISystemActivator的应答,

果然不出所料,应答中包含了从服务端带回的以后连接所使用的端口号,53286。根据文档,STRINGBINDING正是存放服务端端点的地方,

至此我们获得了一个服务端传回的动态端口,工业防火墙设计上的一大挑战划上了句号。除了ISystemActivator会带来动态端口的信息,还有没有其它接口也会带来动态端口信息?

我用了另一个客户端,发起类似的创建过程,得到如下的包截图,

这里可以看见类似的端口改变,从135变成了52997。这种改变是从REMACT协议的应答后开始的,所以我们有理由相信该应答带回了动态端点内容。进一步看下应答,

果不其然,在STRINGBINDING中带回了服务端点52997。也许有人会问,REMACT到底是什么协议?上图显示是IRemoteAcitvation接口,uuid如下,

它的IID,4d9f4ab8-7d1c-11cf-861e-0020af6e7c57,同样在注册表中也查不到。其实已经改名了,叫IAcitvation,只有一个函数如下,自然Opcnum就是0了。

本文总结了二种方法下如何获取OPC的动态端口,抛砖引玉希望大家看完后点个赞,留个言。2020岁末已至,活下来真心不容易。这里的疫情没控制住还在蔓延,第一针疫苗也刚开打。此文算是留给难忘的2020作个总结,下篇讨论微软的紧急DCOM安全漏洞。再见2020,你好2021!

  • 17
    点赞
  • 29
    收藏
    觉得还不错? 一键收藏
  • 18
    评论
OPC UA(Open Platform Communications Unified Architecture)是一种开放的工业通信协议,用于在工业自动化和物联网领域进行设备间通信。报文解析是指对于传输在网络中的OPC UA报文进行分析和理解的过程。 OPC UA报文由多个字节构成,其中含了不同的字段和标记,用于描述通信的目的和内容。报文解析的过程主要括以下几个步骤: 1. 报文头解析:首先需要解析报文的头部信息,括报文类型、长度、版本等。这些信息能够帮助区分不同类型的报文,并确定解析的起始位置。 2. 数据结构解析:根据OPC UA规范,报文中的数据通常采用二进制编码,并以特定的结构进行组织。解析时需要按照规范定义的结构,逐层解析报文中的字段和标记,以获取其中的数据信息。 3. 数据内容解析:在报文中存在不同类型的数据内容,例如标量值、数组、字典等。解析时需要根据字段的定义和数据类型进行解析,并将其转换为可读的形式。 4. 错误处理:在报文解析过程中,可能会遇到数据格式错误、解析错误等问题。对于这些错误情况,需要进行适当的错误处理,例如跳过错误的字段或报错提示等,以保证解析的准确性和完整性。 报文解析OPC UA通信的重要环节,能够帮助实现设备间的数据交换和共享。通过对报文的解析,可以获取到设备的状态信息、测量数据等,进而进行数据分析和控制操作。同时,报文解析也可以帮助进行通信故障排查和性能优化,提高通信的可靠性和效率。
评论 18
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值