当前位置:文档之家› 典型的工业控制系统通信协议安全性分析-启明星辰集团

典型的工业控制系统通信协议安全性分析-启明星辰集团

典型工业控制系统通信协议

安全性分析报告

启明星辰集团

工控安全事业部

2015/10/26

目录

前言 (2)

1 Modbus TCP协议 (3)

1.1协议简介 (3)

1.2协议规范 (4)

1.3协议安全性分析 (6)

2 OPC协议 (8)

2.1协议简介 (8)

2.2协议安全性分析 (14)

3 DNP3协议 (16)

3.1协议简介 (16)

3.2协议规范 (16)

3.3协议安全性分析 (18)

4 Ethernet/IP协议 (20)

4.1协议简介 (20)

4.2协议规范 (20)

4.3协议安全性分析 (21)

5 EtherCAT协议 (23)

5.1协议简介 (23)

5.2协议规范 (23)

5.3协议安全性分析 (25)

1

前言

网络协议是计算机网络中进行数据交换而建立的规则、标准或约定。要理解工业网络如何工作,首先要了解他们所使用的底层通信协议,及其应用场景和选择这些协议的原因。目前,已有的许多工业控制专用协议,大多是为了提高效率和可靠性而设计的,以满足大规模分布式控制系统的运行需要。同时,令人堪忧的是为了提升效率,而放弃了协议的安全特性,例如:要求额外开销的认证和加密等措施。更有许多工控协议为了能够适应以太网运行做了修改,使得协议存在可以被利用的漏洞。

因此,启明星辰对常见的Modbus TCP、OPC、DNP3、Ethernet/IP、EtherCAT 这五种常见协议进行安全性分析,以期发现基于协议漏洞的攻击方式。

欢迎各位专家提宝贵意见。

技术联系人:

郑凌鹏:189******** zheng_lingpeng@https://www.doczj.com/doc/8e15967605.html,

孟雅辉:139******** meng_yahui@https://www.doczj.com/doc/8e15967605.html,

2

1 Modbus TCP协议

1.1协议简介

Modbus是由Modicon(现为施耐德电气公司的一个品牌)在1979年发明的,是一个划时代、里程碑式的网络协议,作为上个世纪第一个在工业现场总线发挥作用的工业总线协议,Modbus协议由于其免费、开放、简单等优点,至今仍然活跃在工业、建筑、基础设施等领域中。随着时代的发展和需求的变化,Modbus 己经衍生出Modbus Plus. Modbus TCP/IP等协议,其已经发展成一个协议簇。

在我国,已制定国家标准GB/T19582-2008《基于Modbus协议的工业自动化网络规范》。Modbus协议是应用于电子控制器上的一种通用语言。通过此协议,控制器相互之间、控制器经由网络(例如以太网)和其它设备之间可以通信。

使用Modbus协议,不同厂商生产的控制设备在各种网络体系结构内进行简单通信,每种设备(PLC、HMI、控制面板、驱动程序、动作控制、输入\输出设备)都能使用Modbus协议来启动远程操作,在基于串行链路和以太TCP/IP网络的MODBUS上可以进行相同通信。

Modbus TCP以一种比较简单的方式将Modbus帧嵌入TCP帧中。IANA(互联网编号分配管理机构)给Modbus协议赋予TCP端口502。

如下图所示,每种设备都能使用Modbus协议来启动远程操作,在基于串行链路和以太网TCP/IP的Modbus上可以进行相同的通信,一些网关允许在几种使用Modbus协议的总线或网络之间进行通信。

3

图1-1 ModbusTCP 通信网络

1.2协议规范

Modbus TCP是OSI通信参考模型第七层上的应用层报文传输协议,它在连

接至不同类型总线或网络的设备之间提供客户机/服务器通信。如下图所示:

协议格式如下:

MBAP报文头功能代码数据

图1-2 Modbus TCP协议应用数据单元的结构

Modbus协议的功能码分为三类:

(1)公共功能码

是较好地被定义的功能码;

保证是唯一的;

MODBUS组织可改变的;

4

5

公开证明的;

具有可用的一致性测试;

MB IETF RFC 中证明的;

包含已被定义的公共指配功能码和未来使用的未指配保留供功能码。

(2)用户定义功能码

有两个用户定义功能码的定义范围,即65至72和十进制100至110;

用户没有MODBUS 组织的任何批准就可以选择和实现一个功能码;

不能保证被选功能码的使用是唯一的;

如果用户要重新设置功能作为一个公共功能码,那么用户必须启动RFC ,

以便将改变引入公共分类中,并且指配一个新的公共功能码。

(3)保留功能码

一些公司对传统产品通常使用的功能码,并且对公共使用是无效的功能

码。

图1-3 Modbus 功能码分类

图1-4 公共功能码定义

1.3协议安全性分析

(1)没有认证机制

在网络连接方面,利用的是TCP协议。在知道目标IP地址的情况下,只要通过502端口就可以发起并建立通信连接。如果应用数据单元携带的功能码是Modbus设备所支持的,那么就可以建立起一个合法的Modbus会话。

没有消息校验(只有Modbus TCP存在该问题)。在某些Modbus TCP 实现中,校验和是在传输层而非应用层生成,从而使得假冒命令更加容易。

(2)没有权限区分

对于任何人,只要他能够连接到目标Modbus设备上,那么他就可以执行所有Modbus设备所具有的功能。

(3)数据明文传输

Modbus协议封装的是ADU,传输的也是这个ADU,在网络上都是以明文的形式传输,通过抓包技术就可以获取并解析出里面的数据。

由于工厂生产环境特殊性,不到万不得已的地步,工厂很难做到随时停工停产进行生产设备的更新换代,因此在现有条件基础上对Modbus协议以上三

点缺点进行安全加固工作很有必要。

(4)没有广播抑制(只有串行 Modbus变体存在该问题)

串行连接的所有设备都会收到所有消息,意味着在串行连接设备链中,可以通过对不明地址进行广播,有效地实现拒绝服务(Dos)攻击。

(5)可编程性

Modbus最危险的特点是它为编程控制器设计的,因此可以用来向RTU 或PLC中注入恶意代码,该问题也存在于许多其他工业协议中。

一些需要特别关注的Modbus 消息的例子包括:

强制从设备转到“只听”(Listen Only)模式的功能码

重启通信的功能码

清除、擦除或重置诊断信息(如计数器与诊断寄存器)的功能码

请求关于 Modbus服务器、 PLC配置或其他敏感信息的功能码

对定义点列表及其值的 Modbus请求(配置扫描)

请求从站标志信息

请求从站附加信息

大小或长度有问题的 Modbus TCP数据包。可能的拒绝服务攻击

从服务器到多个节点的 Modbus流量,可能的拒绝服务攻击

TCP端口502上的非 Modbus或缺陷 Modbus报文

从设备忙异常代码延迟(异常码06),可能的拒绝服务攻击

确认异常代码延迟(异常码05),可能的拒绝服务攻击

不正确的报文长度(最大253),可能的拒绝服务攻击

配置扫描(例如定义的点列及其值)(30秒内5个异常码02)

可用功能码扫描(60秒内3个异常码01)

修改分隔符(08-03)

周期较短(实际阈值待定)的无意义命令,暴力拒绝服务

广播性质的报文或一个主站向多个从站的请求

包含在异常协议数据单元中的信息

列出所有可用功能码的命令(功能扫描)

2 OPC协议

OPC(OLE for Process Control,用于过程控制的OLE)是一个工业标准,管理这个标准国际组织是OPC基金会,OPC基金会现有会员已超过220家。遍布全球,包括世界上所有主要的自动化控制系统、仪器仪表及过程控制系统的公司。基于微软的OLE(现在的Active X)、COM (部件对象模型)和DCOM (分布式部件对象模型)技术。OPC包括一整套接口、属性和方法的标准集,用于过程控制和制造业自动化系统。

OPC的出现解决了控制系统突破“信息孤岛”的瓶颈问题。OPC技术建立了一组符合工业控制要求的接口规范,将现场信号按照统一的标准与SCADA,HMI等软件无缝连接起来,同时将硬件和应用软件有效地分离开。只要硬件开发商提供带有OPC接口的服务器,任何支持OPC接口的客户程序均可采用统一的方式对不同硬件厂商的设备进行存取,无须重复开发驱动程序。这样大大提高了控制系统的互操作性和适应性。

1995年,由Fisher-Rosemount、RockwellSoftware、Opto22、Intellution和IntuitiveTechnology发起成立OPC基金会。第一份OPC标准草案于1995年12月发布,第二份草案于1996年3月发布,第二份草案成功的吸引了大量开发人员的注意,并将其理念推向世界。OPC规范1.0版本于1996年8月29日正式出版,开始了全球范围的活动。截止2011年,OPC国际基金会总共拥有440余位公司成员/80多位最终用户成员,3500多家致力于开发OPC产品的公司,超过22000种产品,拥有3000多种产品资料,在包括中国在内的全球52个国家和地区拥有众多分支机构。随着技术的发展和市场的需求,OPC技术的发展经历了三个主要阶段,即经典OPC、OPCXML-DA和OPCUA。

2.1协议简介

(1)经典OPC

OPC第一阶段的技术称为经典的OPC。根据工业应用的不同需求,经典OPC 包括的规范:Data Access(DA),Alarm&Events(A&E),Historical Data Access(HDA),OPC Batch,OPC Security,OPCDX和OPC Complex Data。其中

应用较多的有DA,AE和HAD。DA指出如何访问当前的过程数据,A&E提供了基于事件信息的接口,HDA描述了如何访问已存档的数据。所有的接口都提供通过地址空间导航获取可用数据的方法。

(2)OPC DA

OPC DA即OPC数据访问规范,它是由OPC基金会定义的其中一种通信规范,定义了实时数据如何在数据源和数据接收体(比如PLC,HMI)之间,在不知道彼此特定通信协议的情况下仍然进行交换、传输。

年份版本备注

1996 1.0 初始规范

1997 1.0a 数据访问,该名称用于区分与其并行开发的其它1998 2.0-2.05a 多处规范澄清和修改

2003 3.0 进一步补充和修改

表2-1 OPC DA规范主要版本

OPC数据存取规范定义了OPC服务器中一组COM对象及其接口,并规定了客户程序对服务器程序进行数据存取时需要遵循的标准。OPC数据存取规范以OPC对象模型逻辑为基础,该模型包含三类对象:OPC服务器对象,OPC组对象和OPC项对象。OPC服务器对象并作为OPC组对象的包容器维护有关服务器的信息,OPC服务器对象主要实现IUnknown和IOPCServer接口,OPC客户程序通过OPC服务器的接口与OPC对象进行通信,存取数据源,数据源可以是现场设备,也可以是应用程序,服务器内部封装了与I/O控制设备通讯及操作的具体实现过程;OPC组对象维护有关其自身的信息,提供包容OPC项的机制,并管理OPC项,它提供了一种客户程序组织数据的手段,例如一个组中可以包括一个设备中所有的数据项,客户程序和数据项之间可以建立基于“订阅”的连接;有两种类型的组,公共组和局域组,公共组可以被多个客户共享,而局域组只能被一个客户使用,每个组中都可以定义一个或多个OPC项。

图2-1 OPC DA中的对象

(3)OPC HDA

OPC HDA即OPC历史数据存取规范,提供了一种统一的在各种不同的应用层面之间传递数据的方式,但跟OPCDA完全不同的是,OPCHDA在不同角色之间传递的是非实时数据,即不是当下的时刻,而是过去某点或某段时间内的过程数据。任何支持OPCHDA规范的数据可视化、数据分析或者趋势汇报的软件,都可以从任何一个支持OPCHDA的过程历史数据库中读取数据。因为OPCHDA 已经是一种非常之成熟的OPC访问规范,所以现在市场上的主要过程历史数据库都支持OPCHDA,即使用户所用的历史数据库没有提供OPC通信,现在各大OPC供应商也都有为不同历史数据库提供OPC接口的软件。可以看出其应用主要不同的地方在于它是和过程数据库进行数据交换,其余的应用和之前的OPCDA规范基本相同,是为了适应新需求而升级的规范。

OPC历史数据服务器对象实现了与历史服务器进行读取或写入数据的功能,数据类型取决于服务器。通过接口可以获取所有的COM对象,客户端只能看到这些COM对象。

(4)OPC A&E

OPCA&E即OPC报警事件规范,提供了基于事件信息的接口。OPC支持两种类型的报警事件服务器:简单的和复杂的。简单服务器监测报警或事件,并提供给报警事件客户;复杂服务器从多个数据源处(包括简单服务器)监测报警或事件信息,并向报警事件客户提供信息。报警事件客户也分为三类:操作站、报警事件管理子系统和报警事件logging组件。

OPC报警事件服务器包含一系列的对象和接口,这些对象和接口向客户提

供报警事件信息。OPC报警事件服务器中涉及以下几个概念:

报警(Alarm):报警是一种非正常的状态。

状态(Condition):状态是OPC报警事件服务器定义的,每个状态还可以包含若干个子状态,状态最终是和现场数据项联系的。每一个状态都包含一个或多个子状态、属性和质量等属性。OPC报警事件服务器中定义状态机处理相应的状态或子状态之间的变化。

事件:OPC规范中定义了三种事件。条件事件:定义描述了状态的变化。跟踪事件:指当客户与OPC事件服务器中定义的数据项之间发生交互时引发的事件。简单事件:指除以上两种事件以外的任何事件,例如,服务器中定义的物理系统和设备的错误等。

OPC A&E服务器主要包括OPC事件服务器对象、OPC事件订阅对象和OPC 事件区域浏览对象。

(5)OPC XML-DA

OPCXML-DA是OPC基金会提出的一个基于XML规范和SOAP技术的接口规范,OPCXML-DA将要交换的结构化数据信息组织为SOAP消息来传送。

基于XML技术和SOAP技术的特征使得它可以更好地促进工业现场数据跨越Internet的传输,简化不同应用间的互操作性,并将现场数据统一到企业层的运用中,实现诸如MES和ERP等系统的一体化连接,XML在OPC规范中的引入,为控制系统到信息系统之间的数据交换搭建了一个桥梁。控制系统现场采用XML描述的数据可以被管理信息系统中的标准XML解析器解析,而不需要根据不同的控制系统数据描述开发多种解析器,这使得统一和标准化的数据传输成为可能。

OPCXML-DA支持8种服务,每种服务都包括1个请求和1个响应。通过对这些服务的定义,提供了访问工业现场数据的标准接口,请求和响应按照SOAP协议标准被包装成SOAP信封,信封标题说明消息如何被处理,信封正文则包含工业过程信息。

OPCXML-DA支持的服务类型具体包括:

GetStatus:返回关于服务器、版本、当前模式、运行状态等信息;

Browse:在服务器的命名空间里搜索所有可获取的项的名字;

GetProperties:返回1个或多个项的属性相关信息;

Write:向1个或多个项中写入新值;

Read:返回1个或多个项的值、品质和时间戳;

Subscribe:指定1个客户希望持续更新的项列表;

SubscriptionCancel:删除在前一个Subscrible调用中指定的项列表;

SubscriptionPolledRefresh:返回上次调用以来在项列表中数值发生变化的所有项。

(6)OPCUA

OPC通信标准的核心是互通性(Interoperability)和标准化(Standardization)问题。传统的OPC技术在控制级别很好地解决了硬件设备间的互通性问题,在企业层面的通信标准化是同样需要的。OPCUA之前的访问规范都是基于微软的COM/DCOM技术,这会给新增层面的通信带来不可根除的弱点。随着传统OPC 技术不够灵活、平台局限等问题逐渐凸显,OPC基金会于2006年发布了最新的OPC技术规范—OPC统一体系架构(OPCUA),涵盖了OPC实时数据访问规范(OPCDA)、OPC历史数据访问规范(OPCHDA)、OPC报警事件访问规范(OPCA&E)和OPC安全协议(OPCSecurity)的不同方面,但在其基础之上进行了功能扩展。

OPCUA是在传统OPC技术取得很大成功之后的又一个突破,让数据采集、信息模型化以及工厂底层与企业层面之间的通讯更加安全、可靠,它是未来OPC 技术的核心发展技术规范。

OPCUA的几大优势:

与平台无关,可在任何操作系统上运行

为未来的先进系统做好准备,与保留系统继续兼容

配置和维护更加方便

基于服务的技术

可见性增加

通信范围更广

通信性能提高

OPCUA有效地将现有的OPC规范(DA、A&E、HDA、命令、复杂数据和对象类型)集成进来,成为现在的新的OPCUA规范。OPCUA提供了一致、完

整的地址空间和服务模型,解决了过去同一系统的信息不能以统一方式被访问的问题。

(1)通信性高

OPCUA规范可以通过任何单一端口进行通信。这让穿越防火墙不再是OPC 通信的路障,并且为提高传输性能控制工程网版权所有,OPCUA消息的编码格式可以是XML文本格式或二进制格式,也可使用多种传输协议进行传输,比如:TCP和通过HTTP的网络服务。

(2)可靠性、冗余性

OPCUA的开发含有高度可靠性和冗余性的设计。可调试的逾时设置控制工程网版权所有,错误发现和自动纠正等新特征,都使得符合OPCUA规范的软件产品可以很自如地处理通信错误和失败。OPCUA的标准冗余模型也使得来自不同厂商的软件应用可以同时被采纳并彼此兼容。

(3)标准安全模型

OPCUA访问规范明确提出了标准安全模型,每个OPCUA应用都必须执行OPCUA安全协议,这在提高互通性的同时降低了维护和额外配置费用。用于OPCUA应用程序之间传递消息的底层通信技术提供了加密功能和标记技术,保证了消息的完整性,也防止信息的泄漏。

(4)平台无关

OPCUA软件的开发不再依靠和局限于任何特定的操作平台。过去只局限于Windows平台的OPC技术拓展到了Linux、Unix、Mac等各种其它平台。基于Internet的WebService服务架构(SOA)和非常灵活的数据交换系统,OPCUA的发展不仅立足于现在控制工程网版权所有,更加面向未来。

OPCUA定义了一系列服务器所能提供的服务,特定的服务器需要向客户端详细说明它们所支持的服务;信息通过使用标准的和宿主程序定义的数据类型进行表达,服务器定义客户端可识别的对象模型,服务器可以提供查看实时数据和历史数据的接口,并且由报警和事件组件来通知客户端重要的变量或事件变化,OPCUA可以被映射到一种通信协议上并且数据可以以不同的形式进行编码来达到传输便捷和高效的目的。

OPCUA的总体架构如下图所示。

图2-3 OPC UA总体架构

2.2协议安全性分析

由于使用DCOM与RPC、OPC与OLE受到同样漏洞的影响,从而导致OPC很容易受到攻击。此外,OPC基于Windows操作系统,很容易受到针对windows漏洞的攻击影响。

虽然OPC及相关控制系统漏洞只有ICS-CERT 授权会员才能获得,但大量现存OLE与RPC漏洞早已广为人知。因为在工业网络中为产品系统打补丁存在困难,所以目前正在使用的工控系统依然存在许多这样的漏洞,哪怕微软公司已经提供了相应的补丁,但这种安全状态一直没有得到改变。

而且由于OPC基于Windows系统,通常的主机安全问题也会影响OPC系统。大量OPC主机使用弱安全认证机制,即使启用了认证机制也常使用弱口令。许多系统启用了与SCADA系统无关的额外Windows服务,导致非必需的运行进程和开放端口。这些问题将OPC系统广泛暴露于攻击之下。令问题更严重的是,由于Windows2000/XP 审计设置默认不会记录DCOM连接请求,因此攻击发生时,日志记录往往不充分甚至缺失,无法提供足够的详细证据。

也就是说,与前述的简单且目的单一的协议不同,OPC必须使用最新操作系统与网络安全手段,将其作为大型系统对待。由于OPC依赖于微软公司授权机制,因而弱口令是威胁OPC服务器安全的最严重脆弱性之一。另一个主要问题是,由于windows2000/XP的审计设置默认不会记录DCOM的连接请求、SMB登录以及访问系统对象的尝试,从而导致日志记录不充分。

其他OPC安全问题包括:

(1)过时的授权服务。

受限于维护窗口、解释性问题等诸多因素,工业网络系统升级困难,导致不安全的授权机制仍在使用。例如,在许多系统中,仍在使用默认的Windows2000 LanMan(LM)和Windows NT LanMan (NTLM) 机制,这些机制与其他过时的授权机制过于脆弱而易受攻击。

(2)RPC漏洞。

由于OPC使用RPC,因而易受所有RPC相关漏洞影响,包括几个在授权前就暴露的漏洞。攻击底层RPC漏洞可以导致非法执行代码或DoS攻击。

(3)不必要的端口与服务。

OPC支持除TCP/IP外的其他网络协议,包括NetBEUI、在Ipx协议上面向连接的NetBIOS和HTTP互联网服务等。

(4)OPC服务器完整性。

攻击者可以创建一个假冒OPC服务器,并使用这个服务器进行服务干扰、DoS攻击、通过总线监听窃取信息或注入恶意代码。

通过监控OPC网络或OPC服务器(服务器活动可以通过采集与分析Windows日志监控)可疑行为可以检测多种威胁,包括:

从OPC服务器发起的使用非OPC的端口与服务。

出现已知OPC(包括底层OLE RPC与DCOM)攻击。

来自未知OPC服务器的OPC服务(意味着存在假冒服务器)。

OPC服务器上的失败授权尝试或其他授权异常。

OPC 服务器上由未知或未授权用户发起的成功授权尝。

3 DNP3协议

3.1协议简介

DNP(DistributedNetworkProtocol,分布式网络协议)是HARRIS公司推出的一种远动通信协议,是目前电力系统自动化产品市场上的一种主流通信协议。

DNP3.0是美国IEEE电力工程协会(PES)在IEC的基础上制定的国家标准。DNP3.0的开发是HARRIS公司集其多年SCADA通信规约应用经验,并参与了多个标准委员会的经验交流的结果(如IEEE,IEC,EPRI/UCA,MMSForum,AMRA,ANSI,CCAC,CIGRE等标准委员会组织)。

3.2协议规范

DNP3.0基于IEC870-5标准,采用了ISO七层模型中的三层:物理层、数据链路层和应用层,其结构为增强协议结构。这种分层结构使得数据传送的可靠性大大提高,同时也便于软件编程的模块化。物理层一般采用普通的RS232或RS485;链路层采用CRC校验;为了满足较长数据包的传送,又增加了一个伪传输层。发送数据时它可以将较长的应用层报文拆分为多个短帧然后多帧传送,反之,接收时将短帧组装成完整的应用层报文。

图3-1DNP3通信协议结构图

DNP3.0的数据链路层协议规定了DNP3.0版的数据链路层,链路协议数据单元(LPDU)以及数据链路服务和传输规程。数据采用一种可变帧长格式:FT3。一个FT3帧被定义为一个固定长度的报头,随后是可以选用的数据块,每个数

据块附有一个16位的CRC校验码。固定的报头含有2个字节的起始字,一个字节的长度(LENGH),一个字节的链路层控制字(CONTROL),一个16位的目的地址,一个16位的源地址和一个16位的CRC校验码,共10个字节。

图3-2 DNP3数据链路层协议格式

传输层协议

DNP的传输层是一个伪传输层。伪传输层功能专门设计用于在原方站和从方站之间传送超出链路规约数据单元(LPDU)定义长度的信息。其格式如下:

图3-3 DNP3传输层协议格式

其中:

传输层报头:传输控制字,1个字节

数据块:应用用户数据1-249个字节

应用层规约:DNP3.0应用层归约定义了应用层报文(APDU)的格式。这里,主站被定义为发送请求报文的站,而从站则为从属设备。被请求回送报文的RTU或智能终端,只有被指定的主站能够发送应用层的请求报文,而从站则只能发送应用层的响应报文。应用请求报文的格式:

图3-4 DNP3应用层响应报文格式

请求(响应)报头:标识报文的目的,包含应用规约控制信息(ACPI);

对象标题:标识随后的数据对象;

数据:在对象标题内的指定的数据对象;应用报文报头字段的定义:请求报头有两个字段。每个字段为8位的字节,说明如下:

图3-5 DNP3 应用层请求报文报头

响应报头有三个字段。前两个字段为8位的字节,第三个字段为两个字节,说明如下:

图3-6 DNP3应用层响应报文报头

3.3协议安全性分析

DNP3的主要关注点集中在数据帧完整性方面,而它并没有使用授权或加密机制(尽管在安全DNP3中有)。由于DNP3功能代码与数据类型都已经明确定义,因此篡改DNP3会话变得相当容易。

不过,在DNP3协议中引入安全机制的同时带来复杂度的增加,也为协议增加了出现漏洞的可能。ICS-CERT 已报告了几个DNP3漏洞。由于存在已知漏洞,而且DNP3协议已得到广泛使用,因此建议对DNP3互联进行适当渗透测试和补丁修复操作。

一些常针对DNP3进行攻击的实例包括使用MITM攻击来窃取地址然后用于操纵系统。实例如下:

关闭自主报告以瘫痪告警。

向主控站发送虚假自发响应事件,并欺骗操作员采取不当行为。

通过注入广播数据,在DNP3系统内制造广播风暴进行DoS攻击

篡改时间同步数据,导致同步失锁与通信错误。

篡改或阻塞确认信息,导致持续重传。

发起未授权的停止、重启或其他可能扰乱工控系统运行的指令

通过监控DNP3会话,监视特定功能码和行为可以检测多种威胁:

在DNP3端口上使用非DNP3通信(TCP与UDP端口20000)。

使用配置功能代码23(禁用自发响应)。

使用控制功能代码4、5或6(操作、直接操作、无确认的直接操作) 。 使用应用程序控制功能18(停止应用程序) 。

大量超时自发响应(响应风暴)。

对需要授权的操作进行任何非法尝试。

任何授权失败。

任何源自或去向一个未显式定义为主/从设备的DNP3通信。

19

相关主题
文本预览
相关文档 最新文档