Practical Modbus Flooding Attack and Detection

Sacred Heart University

From the SelectedWorks of Sajal Bhatia

January 20, 2014

Practical Modbus Flooding Attack and DetectionSajal Bhatia, Queensland University of TechnologyNishchal Kush, Queensland University of TechnologyChris Djamaludin, Queensland University of TechnologyJames Akande, Queensland University of TechnologyErnest Foo, Queensland University of Technology

Available at: https://works.bepress.com/sajal-bhatia/8/

http://www.sacredheart.edu

https://works.bepress.com/sajal-bhatia/

https://works.bepress.com/sajal-bhatia/8/

Practical Modbus Flooding Attack and Detection

Sajal Bhatia Nishchal Kush Chris Djamaludin James AkandeErnest Foo

Information Security Discipline,Queensland University of Technology,

Email: {s.bhatia, n.kush, christopher.djamaludin, ayodejijames.akande, e.foo}@qut.edu.au

Abstract

The Modicon Communication Bus (Modbus) proto-col is one of the most commonly used protocols in in-dustrial control systems. Modbus was not designedto provide security. This paper confirms that theModbus protocol is vulnerable to flooding attacks.These attacks involve injection of commands that re-sult in disrupting the normal operation of the con-trol system. This paper describes a set of experi-ments that shows that an anomaly-based change de-tection algorithm and signature-based Snort thresh-old module are capable of detecting Modbus floodingattacks. In comparing these intrusion detection tech-niques, we find that the signature-based detection re-quires a carefully selected threshold value, and thatthe anomaly-based change detection algorithm mayhave a short delay before detecting the attacks de-pending on the parameters used. In addition, we alsogenerate a network traffic dataset of flooding attackson the Modbus control system protocol.

Keywords: Modbus, Denial-of-Service (DoS), ChangeDetection, Intrusion Detection

1 Introduction

Supervisory Control and Data Acquisition (SCADA)systems are used in many industrial sites to remotelymonitor and activate motors, pumps and other equip-ment that run water processing plants, factories, re-fineries and electricity substations.

In recent years control systems have been up-graded from the standard serial bus systems to mod-ern Transmission Control Protocol (TCP)/InternetProtocol (IP) based systems. This has resulted in costsavings as standard Information and CommunicationsTechnology (ICT) Ethernet cabling can be used, butit has also provided the convenience of allowing thesecontrol systems to be connected to existing data net-works. The trade off in this course of action, that isconnecting these control systems to the Internet ex-poses them to existing cyber attacks. Traditionally,

This work was supported in part by Australian Research Coun-cil Linkage Grant LP120200246.

Copyright c©2014, Australian Computer Society, Inc. Thispaper appeared at the Australasian Information SecurityConference(ACSW-AISC 2014), Auckland, New Zealand, Jan-uary 2014. Conferences in Research and Practice in Informa-tion Technology (CRPIT), Vol. 149, Udaya Parampalli and IanWelch, Ed. Reproduction for academic, not-for-profit purposespermitted provided this text is included.

control system devices and protocols have not beendesigned to withstand malicious attacks. It is impor-tant to determine how vulnerable these systems areand how to detect if an attack is being conducted onthese systems so that appropriate action can be takenbefore serious damage occurs.

The published work regarding vulnerabilities andattacks on industrial control systems is grow-ing (Huitsing et al. 2008, Morris et al. 2013). How-ever, to the best of our knowledge, there is currentlyno work in the public domain that practically demon-strates such attacks and their detection. This paperconcentrates on the common Modicon Communica-tion Bus (Modbus) control protocol that has beenadapted to run over TCP/IP. It has not been de-signed to provide any security properties, thereforeit is vulnerable to many types of attack. This pa-per focuses on flooding attacks as they are the easiestattack to conduct on a SCADA system. The workalso explores different detection techniques that canbe used to identify when an attack is being conducted.The contribution of this paper is two-fold. Firstly, weshow that it is possible to use flooding attacks to suc-cessfully subvert a control system using Modbus. Sec-ondly, we show that the anomaly-based change detec-tion algorithm and the signature-based Snort thresh-old module are capable of detecting a Modbus flood-ing attack. Additionally, we also provide a set of ex-periments that results in a network traffic dataset offlooding attacks on the Modbus control system proto-col. These datasets can be used to validate a varietyof intrusion detection algorithms.

This paper is divided into seven sections. Section1 introduces the paper and gives a brief descriptionof the existing Modbus over TCP protocol. Section 2reviews related work on Modbus vulnerabilities andattack detection. Section 3 describes the floodingattack and the software that was developed to suc-cessfully conducted the attack on our experimentalsystem. Section 4 introduces the theory behind thetwo intrusion detection mechanisms that are used todetect the flooding attacks. Section 5 describes theexperimental methodologies used to generate a rangeof datasets that we present and analyse in Section 6.Section 7 concludes the paper.

1.1 Modbus

Devices connected using the Modbus protocol com-municate with each other using a master-slave orserver-client configuration (Modbus Organization Inc.2006). The master device controls all the activitiessuch as the transmission and monitoring. It initiatesthe queries while the connected devices or slaves, re-spond to the queries. For this reason, the Modbusprotocol is referred to as a single master protocol. The

Proceedings of the Twelfth Australasian Information Security Conference (AISC 2014), Auckland, New Zealand

57

Figure 1: Modbus/TCP ADU Message Structure

master device can either send a broadcast message toall connected and configured slave devices, or poll aslave device individually (Modbus Organization Inc.2006).

Modbus packets also have function codes whichspecify the type of operation requested. EveryModbus device has a register map of functions thatare used to monitor, configure and control module in-put/output. There are two main variants of Modbusprotocol, Modbus Serial and Modbus/TCP. For thispaper, we will focus on Modbus/TCP, and for theremainder of this paper references to Modbus meanModbus/TCP.

Modbus is a communication protocol designed toallow communication of industrial equipment such ascomputers, sensors, Programmable Logic Controllers(PLCs) and other physical input/output devices overthe IP/Ethernet network. TCP/IP and Ethernet areused in carrying Modbus message structure. Modbusis a protocol embedded inside the TCP/IP frames ofEthernet (Modbus Organization Inc. 2006). Figure 1depicts the structure of a Modbus IP Message knownas Modbus Application Data Unit (ADU).

The message structure of Modbus ADU is shownin Figure 1, and is divided into two parts (Morriset al. 2013). The first, is the Modbus ApplicationProtocol (MBAP) Header, which consists of:

1. Transaction Identifier (2 bytes) - Used for syn-chronisation between server and client messages.

2. Protocol Identifier (2 bytes) - Set to 0 forModbus, for potential future use.

3. Length Field (2 bytes) - Used to define the num-ber of remaining bytes in this message structure.

4. Unit Identifier (1 byte) - Slave address of de-vice the message structure is to be sent to. ForModbus, address of slave device is the IP addressand therefore the Unit Identifier is set to 0xFF.

The second part of a Modbus ADU message is a typ-ical Modbus Protocol Data Unit (PDU) message. Itconsists of:

1. Function Code (1 Byte) - Modbus supportedfunctions.

2. Function Data (n bytes) - Data accompanyingthe Function Code as a response or command.

2 Related Work

This section provides an overview of previous workundertaken on Modbus, and Intrusion DetectionSystem (IDS) for Modbus protocols. The Modbusprotocol provides no security for messages. Messagesare passed in the clear providing no confidentiality, ormessage integrity (Modbus Organization Inc. 2006).

Huitsing et al. (Huitsing et al. 2008) provides acompilation of attack taxonomy on the Modbus pro-tocol, with the analysis focusing on Modbus serialand TCP protocols. According to the research, thecorresponding targets include the master, field deviceslaves, network communication links and messages.Huitsing et al. outlines that Modbus attacks consist

of protocol specification attacks, which are commonto all Modbus implementations. A total of 28 at-tacks were identified for Modbus protocols. Some ofthese attacks include spoofing, Modbus network scan-ning, baseline response replay, and direct slave con-trol. Modbus flooding attack was not included in thelist of attacks presented in Huitsing et al.. Further-more, the paper does not discuss any practical analy-sis of the attacks.

Queiroz et al. (Queiroz et al. 2009) conducted asecurity evaluation on a simulated water treatmentSCADA system using a Distributed Denial-of-Service(DDoS) attack. The work demonstrated how mali-cious attackers have the ability to disrupt the con-trol and operation of a SCADA system using Modbus.The main aim of the work by Queiroz et al. was topropose a testbed architecture, and only a DDoS at-tack was discussed with no form of detection mecha-nism discussed.

To detect flooding attacks on the Modbus proto-col, an IDS may be employed. An IDS is a software orhardware mechanism that detects misuse or unautho-rised actions (Mell 2001). An example of a networkIDS is Snort. Cheung et al. (Cheung et al. 2007) de-veloped a model based detection approach for moni-toring Modbus networks using Snort. More recently,Morris et al. (Morris et al. 2013) provided a set of 50signature for Modbus and Modbus over serial links.These rules were developed to detect malicious activ-ities on industrial control systems using the Modbusprotocol specifications. However, no practical analy-sis or implementation of these rules were presented byMorris et al..

With Modbus as the de facto industrial commu-nications protocol, and its widespread applicationin SCADA systems, an analysis and evaluation ofModbus flooding attacks is still considered an openproblem. We focus on Modbus, and the use ofanomaly-based, and signature-based detection tech-niques, to detect the onset of malicious activity aimingto disrupt normal operational control. We implementand analyse flooding specific rules and attacks on theModbus protocol.

3 Modbus Flooding Attack

Modbus flooding attack is defined as one where theattacker is able to inject packets into the local net-work connecting the Human Machine Interface (HMI)and the control system and disrupting its normal op-eration. The attacker does not attempt to preventmessages from reaching the control system, it merelysends a larger than normal number of messages withselected function codes. The aim of the attacker is tocontrol the system through this flood of messages andto effectively drown out legitimate commands fromthe HMI.

The Modbus protocol is particularly susceptibleto this type of attack because the messages in theModbus protocol do not include any authenticationmechanisms that will allow the detection and rejec-tion of injected false packets. Modbus messages alsodo not have any inherent checksum or integrity check-ing mechanisms, so it is much easier for the attacker

CRPIT Volume 149 - Information Security 2014

58

Figure 2: TCP Modbus Hacker Program

to flood the local network with false Modbus messagesthat the control system will accept.

For our experiments, we have developed softwareto conduct a flooding attack on a control system. Thisis described in the following section.

3.1 TCP Modbus Hacker

A simple Java application, TCP Modbus Hacker1, waswritten to conduct a flooding attack on a Modbuscontrol network. The Java application has two mainfunctions; reading, and writing registers on the con-trol system. These registers represent system actua-tors such as pumps and flow controls, as well as sen-sors such as water level sensors and temperature sen-sors. The software has the ability to query all thepossible system registers to determine the active reg-isters. This initial scan is important, as unfamiliarattackers will not know what registers are used by aparticular control system. The software also allowsan attacker to write to a single coil or multiple regis-ters. As a result, the attacker can send commands tothe control system that will be acted upon. The TCPModbus Hacker has the ability to alter the speed ofthe commands sent to the target system by introduc-ing a configurable sleep time in milliseconds betweeneach command sent. The TCP Modbus Hacker alsohas the ability to pause and resume the attack at anytime.

When the TCP Modbus Hacker is run against thetarget PLC, the PLC receives correct commands fromthe LabView HMI program at the same time. TheTCP Modbus Hacker can generate process commandsfaster than the LabView HMI, and while the controlsystem still tries to execute all the commands it re-ceives, inevitably the control system only acts on thecommands generated by the TCP Modbus Hacker.Figure 2 gives the graphical user interface for the TCPModbus Hacker program.

1The authors acknowledge Vinh Tung Le and Pedram Moham-madian for implementing the TCP Modbus Hacker application

4 Modbus Flooding Attack Detection

This section presents the two attack detection tech-niques viz. anomaly-based detection (change de-tection algorithm) and signature-based detection(Snort), used for detecting the proposed Modbusflooding attacks.

4.1 Anomaly–based Detection

The onset of an anomalous activity such as flooding-based Denial-of-Service (DoS) attack, is generally ac-companied by a change in the statistical propertiesof the parameters indicating the anomaly. Hence, theproblem of detecting such anomalous activities can betransformed into a change detection problem with theaim to detect changes in the observed parameters withminimal delay and false detection rate (Tartakovskyet al. 2006a,b).

In order to detect such abrupt changes in the pa-rameters being observed, various change detectiontechniques have been proposed and applied in dif-ferent domains such as finance, network, image pro-cessing and seismology. Amongst all the differenttechniques that have been proposed, moving average,Cumulative Sum (CUSUM) and spectral analysis, arethe most commonly used to detect anomalous networkbehaviour such as a flooding attack. The change de-tection technique used in this paper is a variant ofthe moving average technique called ExponentiallyWeighted Moving Average (EWMA). EWMA waschosen because of its simplicity, flexibility, robustnessand effectiveness, especially in detecting high inten-sity attacks (Siris & Papagalou 2006) such as flooding-based attacks. It also has a lower false positive rateas compared to CUSUM for large dataset samples, orwhenever the parameters are estimated (Khoo et al.2011).

Change Detection Algorithm The change detec-tion algorithm used in this paper, EWMA, exam-ines the value of the observed parameter and deter-mines if it has exceeded a particular threshold value.In comparison to other static threshold-based tech-niques, EWMA makes use of a dynamic (adaptive)threshold. This adaptive threshold is based on the


59

Figure 3: Experimental Set-up

estimated mean of the observed parameter, which inturn is computed from the recent observations. Thecomputed threshold at every sampling interval is thenused to make decisions about the changes detectedin the parameter of interest, incoming TCP Modbuspackets in this case.

Let xt represent the number of TCP Modbus pack-ets observed in the time interval t, and µt−1 representsan average packet rate computed from measurementsprior to t. Time t is a cardinal number and indicates asampling time instance of the time series, rather thanan actual time stamp. A significant change in xt isindicated if,

xt ≥ (1 + η)µt−1 (1)

where η > 0 is a parameter indicating the fractionalchange from the mean (µ) that constitutes a ‘change’or an indication of the anomalous behaviour of xt i.e.number of incoming Modbus packets. It is to be notedthat the change detection condition Equation 1 is usedonly to flag positive changes in the observed parame-ters.

The mean value µt of the parameter can beestimated, either using a sliding window, or viaan EWMA of its previous occurrences until thattime interval. The EWMA technique gives a max-imum weight to the most recent observation, andan exponentially decreasing weight to older observa-tions (Roberts 2000). In this paper, EWMA tech-nique is used to calculate the mean value for the pa-rameter of interest at each sampling time interval.Thus, the EWMA µt of the parameter xt, as firststudied by Roberts 2000, can be written as:

µt = λxt + (1− λ)µt−1 (2)

where

• xt is number of packets observed at a time periodt.

• µt is the EWMA value of xt at a time period t.

• λ is the EWMA factor with a value between 0and 1.

The value of xt can either be an individually ob-served value, or an average computed using a givensampling period and technique. The value of λ de-termines the relative weight given to the most recentvalues of the mean parameter value computed beforethe current time interval.

Instead of flagging a change in the parameter beingobserved with every single occurrence of the thresh-old condition (Equation 1), the change detection tech-nique has been slightly modified so that it triggers an

alarm (an actual change) only after a minimum num-ber of consecutive occurrences of threshold conditionare detected. This is done to minimise the false alarmsthat would potentially arise due to erratic fluctuationsin the number of packets being observed. Thus, analarm is triggered when there are k consecutive timeintervals for which the change detection condition oc-curs before flagging an actual change in the observedparameter.

t∑j=t−(k−1)

1{xj≥(1+η)µj−1} ≥ k (3)

where k ≥ 1 is a parameter indicating the numberof consecutive time intervals for which the change de-tection condition is violated before flagging an actualchange in the observed parameter.

The following section presents alternate signature-based attack detection technique using Snort.

4.2 Signature–based Detection

Snort (Roesch 1999) is an open source signature-basednetwork IDS. Due to its wide deployment, Snort hasbecome the de facto standard for intrusion detection.Snort captures network traffic utilising libpcap or win-pcap libraries (depending on the platform it is de-ployed on) and decodes it. The purpose of the decodeis to identify the type of network traffic. The de-coded buffer is then made accessible to one or moreSnort preprocessors. Preprocessors operate on the de-coded buffer to perform appropriate transformationsto the buffer. In the work presented in this paper, theModbus preprocessor (Peterson 2009) is used. Thetransformed buffer is subsequently passed to the Snortdetection engine, which detects traffic matching a sig-nature or rule to generate alerts. Snort alerts may begenerated by preprocessors or the detection engine,and specific detection rules can be specified to suitdeployment.

Thus, similar to the change detection thresholddiscussed in Section 4.1, Snort rule thresholds can beapplied as part of a Snort rule or as a stand-alonerule. Thresholds are applied to Snort rules to detectany changes in parameters which result from anoma-lous traffic such as a flooding-based DoS traffic.

The typical format of the Snort threshold2 ruleis as follows threshold: type threshold, track<by src|by dst>, count <c>, seconds <s>;. The

2The threshold rule has been deprecated and will not beavailable in future. However additional event processing filter(event filter) is available to implement threshold checking.


60

threshold rate may be tracked by the traffic sourceaddress (by src) or destination (by dst) address, for acount (c), which specifies the number of alerts withinthe time specified as time in seconds (s).

To prevent the false-positive paradox, the thresh-old values employed in the Snort rule need to be basedon some statistical mean of normal traffic. Alterna-tively, the threshold values may be derived experi-mentally, to ensure that no false positive alerts aregenerated as a result of the threshold rules.

Since the attacks described in Section 3.1, floodsTCP port 502 to write to a single coil (Modbus func-tion code 0x05), the Snort rules may be refined fur-ther to alert on specific Modbus traffic. As Snortprovides a Modbus preprocessor, specific rules can bewritten to examine the contents of the Modbus pay-load. Modbus TCP packets contain a MBAP Headerand PDU as illustrated in Figure 1, and patterns inthese may be matched using the content keyword.

The typical content option is in the format(content:[!]‘‘<content string>’’;). Addi-tionally modifiers such as offset, depth andbyte test are used to specify the offset into the pay-load, how far from the offset to search, and how manybytes to convert to find the function code. Contentspecific rules can be applied together with thresholdrules to get higher accuracy detection of the attacks

5 Experimental Set-up and Methodology

This section describes the experimental set-up andmethodology used for generating the attack and be-nign traffic used in this paper.

5.1 Experimental Set-up

A typical SCADA architecture comprises a human op-erator, a HMI, a Master Telemetry Unit (MTU), adata communications network and Remote Teleme-try Units (RTUs). The human operator monitorsthe SCADA system and performs supervisory controlfunction via the HMI, which presents data and allowsfor control inputs. The MTU transmits the control in-formation and collates the data for presentation to theHMI. The RTU receives control information via thedata communications network from the MTU and ma-nipulates the field devices under its control. The RTUis also responsible for acquiring data from field devicesand transmitting them to the MTU. The communi-cation between the MTU and RTU is implementedusing a SCADA protocol.

In the case of the experimental set-up, as illus-trated in Figure 3, the LabView application on theController provides both the HMI and MTU func-tionality. A conventional Ethernet network is utilisedas the data communications network. The TargetPLC using a National Instruments Compact RIO pro-vides RTU functionality, and Modbus is utilised as theSCADA protocol.

The experimental set-up used for generating therequired normal and attack traffic, consists of threemachines, a PLC and a layer 2 network switch con-necting all the devices. Figure 3 gives an overviewof the experimental set-up. The three machines usedin the testbed are standard PCs with 3.0 GHz In-tel Core2 processors, 4 GB of memory, and a main1 Gb Network Interface Card (NIC). Of these threemachines, one is used as an Attacker and runs an in-stance of the TCP Modbus Hacker program previousdescribed (see Section 3.1 for details). The two re-mainder machines are used to act like a Controller(running LabView HMI) and Monitor Box (running

tcpdump) respectively. The Target PLC is a NationalInstruments Compact RIO 9074, with a UniversalAnalog Input Card (NI9219), a 20mA Analog InputCard (NI9203), a 10V Analog Output Card (NI9263),and a High Speed 24V Digital Output Card (NI9474).

This PLC controls the process setup show in Fig-ure 5. The process setup is of two tanks, a lowerreservoir tank and an upper holding tank. A pumpcycles water into the upper tank, which then drainsback into the lower tank. Various instrumentationmeasure the temperature, pressure and level of eachtank, with flow indicators measuring the flow of wa-ter in both pipelines. The flow control valve controlsthe flowback of water into the lower reservoir. Forthis paper, we launch a packet flooding attack on thepump in an attempt to control the pump. The HMI,for this process setup is shown in Figure 4. Built inLabView, it shows the controllers view of the process.

Figure 5: Process and Instrumentation Diagram

5.2 Methodology

The experiment was conducted with two parties, theController and Attacker over a period of 180 seconds,using the set-up shown in Figure 3. The Controllerattempted to control the pump, shown in Figure 5,with it being on (state 1) for the first 30 seconds, andbeing turned off (state 0) for the next 30 seconds,combining into a 60 second periodic cycle that wasrepeated three times as shown in Figure 6a. The At-tacker attempted to disrupt control of the pump bylaunching a flooding attack using the TCP ModbusHacker program previously discussed (Section 3.1).

As shown in Figure 6b, the Attacker lays dormantin the time period of 0-60 seconds. In the time periodof 61-90 seconds, the Attacker floods the PLC withstate 0 packets, opposite to the Controller state in thesame time period. When the Controller state switchesto state 0 at 91 seconds, the Attacker state changesto 1 and begins to flood the PLC with state 1 pack-ets. At 120 seconds, the Attacker returns to dormantstate, and ceases the attack. This experiment was re-peated for different values of Sleep time, a parameterwithin the TCP Modbus Hacker program, which al-lows to set the inter-packet delay, in millisecond (ms),between outgoing packets. For this paper, three setsof experiments were conducted using 0ms, 50ms and100ms as the sleep time value. These values were cho-sen to simulate the Attacker’s attempt to avoid detec-tion, whilst still successfully flooding the Target PLC.All the generated traffic for the three variants of theflooding attack were captured on the Monitor Box.The captured traffic was then analysed in an off-linemanner using two detection techniques viz. changedetection algorithm and signature-based attack de-tection via Snort. The following section presents theobtained results and analysis.


61

Figure 4: LabView HMI

0

1

2

0 30 60 90 120 150 180

Con

trol

ler

Sta

te

Time (Seconds)

(a) Controller States over Time.

0

1

2

0 30 60 90 120 150 180

Atta

cker

Sta

te

Time (Seconds)

(b) Attacker States over Time.

Figure 6: Traffic Generation Scenario

6 Experimental Results and Analysis

The flooding attack launched on the Target PLC asdescribed in Section 5.2 was successful in overwhelm-ing the PLC for the three variations in sleep time.In the attack time period of 61 to 90 seconds of theexperiment, the pump was successfully turned off asthe Attacker was flooding the Target PLC with state0 commands. The HMI on the Controller was stillshowing the pump as running (state 1). In the time

period of 91 to 120 seconds, the Controller turned thepump off by changing the pump state to 0. However,the Attacker reversed the flooding attack state to 1,and was successful in turning on the pump, whilst theController HMI depicted the pump as turned off. The0ms sleep time was the most responsive in changingthe running status of the pump and occurred within1 to 2 seconds of launching the attack. The attacksusing a sleep time of 50ms and 100ms were also suc-cessful in changing the running status of the pump.


62

0

250

500

750

1000

1250

0 30 60 90 120 150 180 0

1

2

Num

ber

of P

acke

ts

Dec

isio

n F

unct

ion

Sampling Interval (5 seconds)

Number of Packets Decision Function

(a) Modbus flooding attack with 0ms sleep.

0

100

200

300

400

500

0 30 60 90 120 150 180 0

1

2

Num

ber

of P

acke

ts

Dec

isio

n F

unct

ion


(b) Modbus flooding attack with 50ms sleep.

0

100

200

300

400

500

0 30 60 90 120 150 180 0

1

2

Num

ber

of P

acke

ts

Dec

isio

n F

unct

ion


(c) Modbus flooding attack with 100ms sleep.

Figure 7: Modbus flooding attack detection using change detection algorithm

However, the Target PLC was relatively slower to re-spond to these attacks.

This section presents the experimental results ob-tained by running the anomaly-based change de-tection algorithm and a signature-based detection(Snort) against the attacks. It also presents a compar-ative analysis on the two attack detection techniques.

6.1 Anomaly–based Detection

In this section, the change detection algorithm de-scribed previously in Section 4.1 is used to detect theflooding attacks. Different values for the four config-urable parameters – η, λ, k, T – were initially basedon the previous work done in change detection us-ing EWMA (Montgomery 2007, Paul 2006, Khoo etal. 2011, Siris & Papagalou 2006). These values werethen experimentally optimised to improve the detec-

tion accuracy. Once optimised, the values were keptconstant for all three attack datasets. Unless statedotherwise, the values considered for these parametersare η = 0.25, λ = 0.98, k = 2, T = 5.

The experimental results obtained by running theEWMA-based change detection algorithm on thenumber of incoming packets to the target PLC areshown in Figure 7. The graph plots number of pack-ets on the left y-axis against time (sampled every 5seconds). The output of the decision function is shownon the right y-axis, with 0 indicating no-change (nor-mal traffic) and 1 representing the change (attack)detected in the number of incoming packets to thePLC over a period of 180 seconds.

The change detection is able to successfully detectall the three attacks with the decision function indi-cating 1 for the attack period, as shown in Figures 7a,7b and 7c. A small lag between the start of the attack


63

0

1

2

3

4

5

0 30 60 90 120 150 180

Num

ber

of A

lert

s

Time (seconds)

0ms 50ms 100ms

Figure 8: Modbus flooding attack detection using Snort

at the 61st second and the output of the decision func-tion is due to the selected value of k, 2 in this case,which flags a change only after 2 consecutive viola-tions of the change detection condition (Equation 3).Setting a lower value of k such as 1 would remove thislag, however, would also result in flagging small fluc-tuations in the observed traffic, thereby increasing thenumber of false alarms.

A small dip is observed around the 95th second,especially in Figures 7a and 7b. This is mainly dueto a switch in the attackers activity i.e. from tryingto turn-off the pump (flooding with packets with 0s)to turn it on (flooding with packets with 1s), oppositeto the controllers activity. This switching of activityfrom the attacker is accompanied by a delay in re-sponse from the Target PLC and hence a drop in thenumber of incoming packets. This drop in the num-ber of incoming packets affects the adaptive thresh-old value in the attack with 50ms delay, Figure 7b,which thereby causes the decision function momentar-ily drop around the 100th second mark, before goingback to 1 and detecting the remainder of the attack.

6.2 Signature–based Detection

An alternative to the anomaly-based detection usingthe change detection algorithm, a signature-based de-tection technique using Snort was also used. Thiswas primarily done to test if Snort, being the indus-trial de-facto for intrusion detection, can be used todetect the proposed flooding attack. The preliminaryresults obtained using Snort with customised rules arediscussed below.

To enable Snort to detect the proposed Modbusflooding attacks, the following rule was utilised:

alert tcp any any -> 10.10.10.12 502(msg:"Modbus threshold violation";sid:1000001; rev:1; priority:1;threshold:type threshold, track by dst,count 50, seconds 1;).

This rule utilised the Modbus preprocessor forSnort together with the threshold directive as de-scribed in Section 4.2. The initial normal (non-attack)network traffic, i.e. traffic between 0 s and 60 s (seeFigure 6) from the Controller to the TCP port 502on the Target PLC was observed to be, on average,42 packets per second. This value was adjusted ex-perimentally to obtain the value of 50 packets persecond. Employing this value ensured that there were

no false alerts generated in the initial non-attack pe-riod. Thus, the Snort rule threshold value employeda count of 50 packets for 1 second period. These val-ues are specific to the scenario, and will need to bechanged to suit the specific environment that Snort isdeployed in.

Figure 8 plots the number of alerts generatedagainst time in seconds. Using Snort with the afore-mentioned rule, the Snort IDS was able to success-fully detect the onset of anomalous activities in all thethree variants of the flooding attack. In the case ofattack with 0ms sleep, the number of alerts triggeredwere higher as compared to the attacks with 50ms and100ms delay. This is speculated to be an artifact ofSnort, which uses a sliding-window-based time periodto perform the rate calculations and is used to de-termine if there is an rule violation and subsequentlytrigger an alert. Thus, with the 0ms attack, as thereare a large number of packets violating the thresholdin comparison to the 50ms and 100ms attacks, thereare more of these sliding-windows triggering alerts.

It should also be noted that the number of alerts,while interesting (and indicating a greater likelihoodof a flooding attack) should not detract from the factthat any alerts should be investigated. A detailedanalysis of the use of a signature-based techniqueneeds further investigation and constitutes the futurework of this research.

6.3 Comparative Analysis

The two techniques used in this paper, anomaly-basedchange detection algorithm and signature-based de-tection via Snort, successfully demonstrate that ab-normal activities started at the 60th second and fin-ished at the 120th second. The two techniques, whilecompletely orthogonal, do possess their respective ad-vantages and disadvantages. Whereas the signature-based detection requires a predefined threshold whichis fixed, the change detection algorithm does not re-quire any pre-defined threshold. Instead, the thresh-old is adaptively calculated and changes continuouslywith the observation time. In terms of implement-ing the attack detection technique in a real-worldscenario, signature-based detection is easier to de-ploy than the anomaly-based change detection algo-rithm, as Snort already provides a preprocessor forModbus, and thus can be used to detect attacks us-ing this protocol. However, in either of the two de-tection techniques, values of the configurable param-eters/threshold used are scenario dependent and thusrequire optimisation.


64

7 Conclusion and Future Work

The work described in this paper has explored thearea of cyber attacks in industrial control systems.In particular we have investigated flooding attacks onthe commonly used Modbus control systems proto-col. The work in this paper has shown that flood-ing attacks can disrupt the functionality of physicalsystems. The paper also investigated anomaly-basedand signature-based techniques for detecting these at-tacks. Both of the intrusion detection techniques areshown to be successful in detecting the flooding at-tack. However, signature-based systems are depen-dent on threshold values, while the anomaly-basedchange detection algorithm takes time to react tothe attack. Future work includes investigating howvulnerable the Modbus protocol is to other types ofattacks such as man in the middle attacks, and toinvestigate and compare different intrusion detectiontechniques for these new attacks. Mitigation strate-gies such as integrating checksums and authenticationmechanisms need to be developed to improve the secu-rity of the Modbus protocol to make industrial controlsystems more secure.

References

Cheung, S., Dutertre, B., Fong, M., Lindqvist, U.,Skinner, K. & Valdes, A. (2007), Using model-basedintrusion detection for scada networks, in ‘Proceed-ings of the SCADA Security Scientific Symposium’,pp. 1–12.

Huitsing, P., Chandia, R., Papa, M. & Shenoi, S.(2008), ‘Attack Taxonomies for the Modbus Proto-cols’, International Journal of Critical Infrastruc-ture Protection 1, 37–44.

Khoo, M., Teh, S., Ang, L. & Ng, X. (2011), AStudy on the False Alarm Rates of X, EWMA andCUSUM Control Charts when Parameters are Es-timated, in ‘Proceedings of the 2011 InternationalConference on Circuits, System and Simulation’.

Mell, R. (2001), ‘Intrusion detection systems’,National Institute of Standards and Technology(NIST), Special Publication.

Modbus Organization Inc. (2006), ‘Modbus applica-tion protocol specification v1. 1b’.

Montgomery, D. (2007), Introduction to StatisticalQuality Control, John Wiley & Sons.

Morris, T. H., Jones, B. A., Vaughn, R. B. & Dan-dass, Y. S. (2013), Deterministic Intrusion Detec-tion Rules for MODBUS Protocols, in ‘Proceedingsof the 46th Hawaii International Conference on Sys-tem Sciences (HICSS), 2013’, IEEE, pp. 1773–1781.

Paul, O. (2006), Improving Web Servers FocusedDoS Attacks Detection, in ‘Proceedings of theIEEE/IST Workshop on Monitoring, Attack De-tection and Mitigation (MonAM 2006), Tuebingen,Germany’.

Peterson, D. (2009), Quickdraw: Generating Secu-rity Log Events for Legacy SCADA and ControlSystem Devices, in ‘Proceedings of Conference forHomeland Security on Cybersecurity Applicationsand Technology’, IEEE, pp. 227–229.

Queiroz, C., Mahmood, A., Hu, J., Tari, Z. & Yu, X.(2009), Building a scada security testbed, in ‘Pro-ceedings of Third International Conference on Net-work and System Security, 2009. NSS’09.’, IEEE,pp. 357–364.

Roberts, S. (2000), ‘Control Chart Tests Basedon Geometric Moving Averages’, Technometrics42(1), 97–101.

Roesch, M. (1999), Snort - Lightweight Intrusion De-tection for Networks, in ‘Proceedings of the 13thUSENIX Conference on System Administration’,LISA ’99, USENIX Association, Berkeley, CA,USA, pp. 229–238.

Siris, V. & Papagalou, F. (2006), ‘Applicationof Anomaly Detection Algorithms for DetectingSYN Flooding Attacks’, Computer Communica-tions 29(9), 1433–1442.

Tartakovsky, A., Rozovskii, B., Blazek, R. & Kim, H.(2006a), ‘A Novel Approach to Detection of Intru-sions in Computer Networks via Adaptive Sequen-tial and Batch-sequential Change-point DetectionMethods’, Signal Processing, IEEE Transactions on54(9), 3372–3382.

Tartakovsky, A., Rozovskii, B., Blazek, R. & Kim,H. (2006b), ‘Detection of Intrusions in Informa-tion Systems by Sequential Change-point Methods’,Statistical Methodology 3(3), 252–293.


65

Documents

Practical Modbus Flooding Attack and Detection