基于网络回溯分析技术的SCADA系统故障诊断

日期: 2014-01-13 来源:TechTarget中国

案例场景

某排水集团在线业务区的SCADA系统需要从DMZ区的I/O Server上采集数据,SCADA系统使用某些IP能够正常从I/O Server采集数据,但是另一部分IP则不能正常的从I/O Server上采集数据,提示异常并且断开连接。

例如:10.2.103.8为SCADA系统的IP地址,能够正常的从10.2.0.51和10.2.0.52的I/O Server上采集数据,但是将SCADA系统的IP改为:10.2.103.10,则不能正常从10.2.0.51和10.2.0.52的I/O Server上采集数据。

案例分析

一、网络拓扑图(简化)

下图为简化拓扑图,我们展示SCADA系统和I/O Server之间的通讯链路,分别在靠近SCADA系统和I/O Server的接入交换机上采用端口镜像的方式旁路部署科来网络回溯分析系统,采集SCADA系统和I/O Server之间的通讯数据包。

图 1 网络拓扑图

二、故障排查

我们从DMZ区的交互机和在线业务区交互机上同时采集通讯数据,进行对比分析,来看看具体是什么原因造成了业务系统的故障。

(一)DMZ区交换机数据

在DMZ区交换机数据中可以看到TCP会话中10.2.103.10向10.2.0.52发送了大量的RST(复位)数据包,如下图2所示。这些连接被这些复位数据包释放掉了,但是为什么会存在这么多的复位数据包?又是谁发送了这些数据包?

图 2 DMZ区捕获到的TCP会话

通过查看科来网络回溯分析系统的交易时序图,可以发现复位数据包的TTL(生存时间)值是127。而正常时传输的数据,可以看到TTL(生存时间)值为61,和异常时明显不同,说明复位数据包并不是从10.2.103.10发出来的,而是有个中间设备发送了复位数据包中断了正常的应用会话。

正常会话的TTLTTL值为61,而异常复位数据包的TTLTTL值为127。结合该集团的拓扑图来看,正常会话发送初始TTLTTL值为64,经过2台防火墙和1台核心交换机后抓取到的TTLTTL值为61,而异常复位数据包初始TTLTTL值为128,只经过了DMZ区连接的防火墙,TTLTTL值减为127,说明复位数据包极有可能是某上网行为管理设备发送的。

(二)在线业务区交换机数据

我们在在线业务区交换机上抓取数据,找到同一个TCP会话。如下图3所示:

图 3 在线业务区捕获到的TCP会话

可以看到该会话中同样存在了大量的复位数据包,但与DMZ区不同的是,复位数据包是由10.2.0.52发送的。

同样查看科来网络回溯分析系统的交易时序图,可以看到复位数据包的TTL(生存时间)值是126。而正常时传输的数据,可以看到TTL(生存时间)值为125,和异常时明显不同,同样说明了复位数据包并不是从10.2.0.52发出来的,而是有个中间设备发送了复位数据包中断了正常的应用会话。

正常会话的TTL值为125,而异常复位数据包的TTL值为126。结合该集团的拓扑图来看,正常会话发送初始TTL值为128,经过2台防火墙和1台核心交换机后抓取到的TTL值为125,而异常复位数据包初始TTL值为128,抓取到的TTL值却为126,说明数据包只经过了核心交换机和在线业务区区连接的防火墙,说明复位数据包极有可能是某上网行为管理设备发送的。

三、结论及处理结果

结合DMZ区与在线业务区捕获的数据包分析来看,在正常的通讯过程中DMZ区与在线业务区之间的设备发送了RST(复位)数据包,释放了正常的会话,造成了SCADA系统不能正常从DMZ区的I/O Server上提取数据。根据数据包的解码分析,可以确定发送异常复位数据包的设备为某上网行为管理设备,通过对该设备策略的修改,10.2.103.10能够正常的从I/O Server上提取数据,未发生异常情况。

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

电子邮件地址不会被公开。 必填项已用*标注

敬请读者发表评论,本站保留删除与本文无关和不雅评论的权力。