2013 46th Hawaii International Conference on System Sciences
Deterministic Intrusion Detection Rules for MODBUS Protocols
Thomas H. Morris†, Bryan A. Jones, Rayford B. Vaughn, Yoginder S. Dandass
Mississippi State University
†
morris@ece.msstate.edu
Abstract
This paper introduces a set intrusion detection
system rules for MODBUS/TCP and MODBUS over
Serial Line systems. The rules described in this paper
were derived from a vulnerability analysis of the
MODBUS protocols. In total the paper describes 50
signature based intrusion detection sys-tem rules.
Details on protocol requirements and the construction
of the rules are provided for each rule. Rule
descriptions are generic to encourage use on multiple
intrusion detection system platforms.
1. Introduction
National Electric Reliability Council (NERC)
Critical Infrastructure Protection (CIP) Standard 005-
4a [1] requires utilities and other responsible entities to
place critical cyber assets within an electronic security
perimeter. Electronic security perimeters must be
subjected to vulnerability analyses, use access control
technologies, and include systems to monitor and log
the electronic security perimeter access. Intrusion
detection for industrial control systems is largely
limited to host based intrusion detection systems
deployed on PCs in control rooms, inspection of
electronic security perimeter logs to detect malicious
activities. Operational networks and industrial network
protocols such as MODBUS, DNP3, are largely left
unmonitored by signature based intrusion detection
systems.
A primary threat to networked devices in
industrial control systems is denial of service attacks.
Protocol mutation attacks in which an exploit
intentionally breaks protocol rules to induce
undesirable behavior are a considerable source of
denial of service attacks. Protocol mutation attacks
against industrial control system networked appliances
have been shown to cause programmable logic
controller (PLC), remote terminal unit (RTU), and
intelligent electronic device (IED) operating systems,
network stacks, and application programs to crash and
cease to function and or to cause devices to reset
themselves [2][3].
This paper provides a set of signature based
intrusion detection rules for the MODBUS/TCP,
1530-1605/12 $26.00 © 2012 IEEE
DOI 10.1109/HICSS.2013.174
MODBUS over Serial Line protocols based upon a
review of the protocol for. A total of 50 rules are
described with details on protocol requirements and
construction of the IDS signature. The rules described
in this paper are intended for use with the SNORT
Intrusion Detection System [7]. However, the rules are
described in a non-proprietary format to encourage
their use on any signature based intrusion detection
system.
In previous work a gasket was developed to allow
use of SNORT to inspect MODBUS over Serial Line
packets [4]. The Stuxnet [5][6] worm highlights the
need to protect legacy serial based cyber assets. The
Stux-net worm searches for hosts with the Siemens
WinCC human machine interface software package
installed. If a WinCC host system is found and the
WinCC host is connected to a Simatic S7-417 PLC and
certain signatures match the targeted physical process
controls, Stuxnet alters the firmware in the PLC. The
Simatic S7-400 PLC series supports both Ethernet and
serial port communications. This suggests it is
possible to alter PLC the firmware of a serially
connected RTU, IED, or PLC after a HMI host node is
compromised. As such, this paper describes IDS rules
for both MODBUS/TCP and MODBUS over Serial
Line systems.
The remainder of this work is organized as
follows. First, a section on related works is provided.
Next the main body of the paper describes the set of
IDS rules developed for this work. Finally, the paper
offers future works and conclusions.
2. Related Works
Snort is a rule based open source network
intrusion detection and intrusion prevention tool [7].
Snort collects and logs network traffic, analyzes
network traffic searching for rule violations, and alerts
the administrator of suspicious activity. Snort is
commonly used to monitor Ethernet and TCP/IP
communications traffic.
Quickdraw [8] is a Snort preprocessor and a set of
Snort rules developed for industrial control systems
using the MODBUS/TCP, DNP3, and Ether/IP
communication standards. The quick draw rules
include alerts for invalid device configuration attacks,
1771
1773
coil and register read and write attacks, high traffic
volume attacks, malformed MODBUS application data
unit (ADU) content attacks, unresponsive device
scenarios, and port and function code scanning attacks.
Currently, the Quickdraw preprocessor and Snort rules
are limited to protecting TCP/IP systems. This article
describes a mechanism to enable use of the Quickdraw
Snort rules and other Snort rules to protect a serial
based industrial control system. The Quickdraw
MODBUS/TCP rules were used to validate the work
described in this article. Currently there are no known
Snort rules or preprocessors to support monitoring
industrial control serial port protocols.
Many researchers have developed statistics based
intrusion detection systems targeted for industrial
control systems [8]-[13]. Statistical intrusion detection
systems use statistical methods to classify network
traffic as normal or abnormal (or into smaller sub-
classes). Various model types or classifiers can be used
to build the statistical model, including neural
networks, linear methods, regression models, and
Bayesian networks. There are two types of
inaccuracies in intrusion detection systems: false
positives and false negatives. False positives generate a
false alarm when there is no intrusion, while false
negatives miss an actual intrusion. False positives may
lead to dropping a valid communication packet which
can have catastrophic results on an industrial control
system. Snort uses pattern matching to
deterministically detect rule violations. Correctly
formed rules will not generate false positives. Because
Snort is deterministic, validated rules may be used with
Snort in intrusion prevention mode; a mode which
drops illegal network packets.
Three MODBUS specifications were used in this
work; the MODBUS Messaging on TCP/IP
Implementation Guide V1.0b [14], MODBUS
Application Protocol Specification V1.1b [15], and
MODBUS over Serial Line Specification and
Implementation Guide V1.02 [16].
3. MODBUS Intrusion Detection System
Rules
MODBUS/TCP and MODBUS over Serial Line
protocols share a common protocol data unit (PDU)
which includes a function code byte and payload. The
MODBUS over Serial Line protocol forms an
application data unit by adding a single byte address
before the PDU and a CRC or LRC checksum byte
after the PDU. The MODBUS/TCP ADU adds a 7 byte
MODBUS Application Protocol (MBAP) header
before the PDU. MODBUS/TCP does not include a
CRC at the MODBUS layer. MODBUS/TCP utilizes
TCP CRC for error detection. Figure 1 shows the
1774
1772
common MODBUS PDU, the MODBUS over Serial
Line ADU, the MODBUS/TCP ADU, and the
MODBUS/TCP MBAP header.
MODBUS PROTOCOL DATA UNIT (PDU)
FC PAYLOAD
MODBUS OVER SERIAL LINE APPLICATION DATA UNIT (ADU)
ADDR PDU CRC/LRC
MODBUS/TCP APPLICATION DATA UNIT (ADU)
MBAP
PDU
HEADER
MBAP HEADER
TRANSACTION PROTOCOL UNIT
LENGTH
IDENTIFIER IDENTIFIER IDENTIFIER
Figure 1: MODBUS/TCP Packet Contents
In the remainder of this section descriptions of the
MODBUS IDS rules are provided. Each IDS rule
includes a table entry and accompanying text
describing the rule. The rule table entries include from
left to right; a rule number, a rule name, applicable
protocol (TCP and/or Serial), a stand-alone or
preprocessor descriptor, and a field summarizing the
rule text. Most rules descriptions and the summarizing
rule text utilize set theory to describe protocol
requirements and the main body the rule. Set theory
based descriptions were used to provide brevity and
conciseness. The common PDU allow many IDS rules
to be developed for both of the MODBUS protocols.
As such many of the rules are intended for both
MODBUS/TCP and MODBUS over Serial Line
systems.
All of the rule descriptions refer to generating
alerts. An alert provides a signal to a system
administrator what the rule has triggered but does not
block the packet from its destination. Rule
implementers may consider converting alerts to drop
rules. Drop rules drop packets which match the rule
specification.
All MODBUS/TCP packets include a protocol
identifier field. The protocol identifier is defined as 0
for all MODBUS/TCP packets. Other values are
illegal. As such a rule is needed to alert for TCP traffic
on the session which does not have a protocol identifier
field set to zero. In effect, this means any TCP packet
with the second byte in the payload not equal to zero is
disallowed and should result in an alert. This rule may
also be safely defined as a drop rule.
1 Protocol TCP stand- trans.protid != 0
Identifier alone
 Rule 1 alerts if the MODBUS/TCP protocol
identifier field is not 0.
All MODBUS/TCP packets include a transaction
ID field is a single byte which can take any value and
is unique to the current outstanding transaction.
MODBUS/TCP packets occur in query response pairs
and the transaction ID field should match for the
current query and response pair. An alert should be
generated if the query and response transaction IDs do
not match. Users should test individual
If the fixed set of queries is known a complimentary
fixed set of responses can also be derived. A length
white list can be derived which is the set of all lengths
from the known set of lengths and responses.
Equations 2-4 describe creation of the length white list
where Q is the set of all possible queries and R is the
set of all possible response. The legal() function used
in equations 2 and 3 returns queries or responses which
are possible for the system being protected by the IDS.
MODBUS/TCP client and server behavior to  ∈ { ():  ∈ } (2)
determine system response to non-matching query and  ∈ { ():  ∈ } (3)
response transaction IDs. Based upon system response
users may decide to make rule 2 a drop rule. Rule 2
requires use of a pre-processor which stores the
contents of the last query for comparison to the current
response.
2 Query TCP preprocessor query.transid !=
Response response.transid
Pairs
Rule 2 alerts if the response transaction identifier
does not match the query transaction identifier.
The MODBUS/TCP length field is a single byte
field which specifies the number of bytes remaining in
the packet after the length field. Length is defined by
equation 1. The size of the unit ID and function code
fields are constant and 1 byte each.
_ ℎ =
 ℎ ∈ { ℎ():  ∈  ⋃  (4)
5 Length TCP stand- trans. length  lengthlist
List alone
Rule 5 alerts if the transaction length is not in the
set of lengths of all valid query and response packets.
The unit ID field is a single byte which takes a
predefined value to unique to each remote slave. The
contents unit ID field is not proscribed by the
MODBUS/TCP specification and its contents are
system specific. Snort rules should be written based
upon the convention used by the client or server
manufacturer. It is common for this field to be limited
to values between 0 and 247 since this was the legal
address range supported by predecessor
MODBUS/RTU and MODBUS/ASCII technologies
and the MODBUS/RTU and MODBUS/ASCII address
is often mapped into the unit ID field.

( ) + 
( ) +

() (1) 6 Unit ID TCP stand- trans. unitid  {0, … ,247}
alone
3 Length TCP stand- trans.length != actual_length
alone Rule 6 alerts if the transaction unit identifier field is
not between 0 and 247.
Rule 3 alerts if the transaction length does not MODBUS RTU and ASCII systems include a
match the actual remaining length of the packet. single byte address to a single client to address
The MODBUS/TCP length field is 2 bytes, multiple MODBUS servers. Each MODBUS server is
however, the maximum total length of a assigned a unique address. MODBUS systems
MODBUS/TCP packet (MBAP+Function typically have a static configuration in which the
Code+payload) is specified has 260 bytes. From this number of servers does not change and the address
the maximum value contained in the length field of the assignment of the individual clients does not change.
MODBUS/TCP packet is 260-6=254 bytes, where 6 is Equation 5 defines the legal address range for
the size of the transaction ID + protocol ID + length MODBUS RTU and ASCII systems. Equation 6
fields. defines the set of used addresses for a given MODBUS
system where used(a) returns addresses in use for the
4 Max Length TCP stand- trans.length > protected MODBUS system.
alone 254
 ∈ {0, . . ,247} (5)
Rule 4 alerts if the transaction length field is greater  ∈ {():  ∈ } (6)
than 254.
MODBUS systems typically implement a fixed set 7 Serial Serial stand- trans. addr  usedADDR
of queries which can be derived from the logic used to Address alone
control the master terminal unit (or MODBUS client).

1775
1773
 Rule 7 alerts if the MODBUS RTU or ASCII 9 Query TCP | stand- query. fc allowedPC ∪
address is not in the list of used addresses for the Function Serial alone implementedUD ∪
protected system. Address 0 is a broadcast address. Codes usedRC
Many system implementers will prefer to disallow use Rule 9 alerts if a query’s function code is not in the
of the broadcast address. set of allowed public function codes, implemented user
defined codes, or the set of used reserved codes.
8 Serial Serial stand- trans. addr == 0 When a MODBUS query generates an error at the
Address not 0 alone MODBUS server an error function code is returned in
the response. The error function code is the query
Rule 8 alerts if the MODBUS RTU or ASCII function code + 0x80. Allowed error codes are defined
transaction address is 0. This rule is optional and by equation 13.
should only be used if broadcast addressing is
prohibited. # ∈ { + 0$80:  ∈
The MODBUS/TCP function code field is a single  ∪ !! ∪ } (13)
byte. MODBUS specifications define 4 types of
function codes; public function codes, user defined 10 Response TCP | stand- resp. fc allowedPC ∪
function codes, reserved function codes, and error Function Serial alone implementedUD ∪
Codes usedRC ∪ allowedEC
function codes. Equation 7 lists the set of public
function codes.
Rule 10 alerts if a response’s function code is not in
 ∈ {1,2,3,4,5,6,7,8,11,12,15,16,17,20,21,22,23,24,43} (7) the set of allowed public function codes, implemented
user defined codes, used reserved codes, or allowed
MODBUS implementers may wish to limit the set error codes.
of allowed public function codes to a subset of UD. For As stated previously, MODBUS queries and
example function code 8 is a diagnostic function code responses arrive in pairs. Query and response function
which provides such commands as force listen only codes must match or the response function code must
mode and clear counters and diagnostic register. be the query function code + 0x80 in the event of an
Equation 8 defines the set of allowed public function error.
codes where allowed(f) returns function codes
permitted by the MODBUS system implementer or 11 FC Query TCP | preprocessor resp. fc {query. fc,
Response Serial query. fc + 0x80}
IDS rule writer.

 ∈ {():  ∈ }
User defined function codes must be in the range
defined by equation 8. System implementers will wish
to limit to user defined function codes to the set of
implemented user defined function codes as defined by
equation 10 where implemented(f) returns function
codes in UD which have been implemented.
 ∈ {65, … ,72,100, … ,110}
(8) Rule 11 alerts if the MODBUS response function
code does not match the query function code or the
associated error function code for the query function
code.
Some MODBUS function codes have a white list of
sub-codes. When used the sub-code is the first 2 bytes
of the MODBUS payload, i.e. the two bytes immediate
following the function code. The set of legal function
code and sub-code pairs is defined in equation 14.
(9)
!! ∈ {!!():  ∈ } (10) / ∈ {8/{0, … ,18, 20},43/{13,14}} (14)

Reserved function codes are codes in the public 12 FC=8 TCP | stand- trans. fc == 8 &
code space which have been used by legacy devices
Sub- Serial alone trans. sc {0, … , 18, 20}
Codes
and which are not supported as public codes. IDS rule 13 FC=43 TCP | stand- trans. fc == 43 &
writers should define set of used reserved codes for the Sub- Serial alone trans. sc {13,14}
protected system. This set is most often empty. Codes
Reserved function codes are in the range defined by
equation 11. Used reserved function codes are defined Rules 12 and 13 alert if the function sub-code is not
by equation 12 where used(f) returns function codes in allowed.
use by the protected system. The function code sub-code pairs 8/19 and 8/21 are
reserved but have been implemented by legacy
 ∈ {65535, 9, 10, 13, 14, 41, 42, 90, 91, 125, 126,127} (11)
 ∈ {():  ∈ } (12)

1776
1774
 devices. IDS for systems using these reserved function 17 Holding TCP | stand- query. fc ∈ ℎ
code sub-code pairs should replace rule 12 with rule Register Serial alone & query. starting_address usedA
14. Starting
Address
18 Input TCP | stand- query. fc ∈ 
14 FC/SC TCP | stand-alone trans. fc == 8 &
Register Serial alone & query. starting_address usedA
FC=8 Serial trans. sc {0, … , 21} Starting
Address
MODBUS includes a set of data access function
codes for reading and writing different types of data; Rules 15-18 alert when the function code matches
discrete inputs, coils, and registers. These function one of the data access function codes and the starting
codes are defined by equation 15-19 where ca is the set address is not in the white list of used addresses. The
of coil access codes, da is the set of discrete input variable usedA is referred to in each rule; however,
access codes, hra is the set of holding register access usedA will be different for each object type.
codes, and ira is the set of input register access codes. The start address is followed by a quantity field.
Together the start address and the quantity can be used
 ∈ {1, 5, 15} (15) to compute the total address space required by the read.
 ∈ {2} (16)
ℎ ∈ {3,6,16,23} (17) 19 Coil TCP | stand- query. fc ∈ 
 ∈ {4} (18) Access Serial alone & (query. starting_address +
 ∈  ∪  ∪ ℎ ∪  (19) Size query. quantity) usedA
20 Discrete TCP | stand- query. fc ∈ 
Each of the data access function codes is to be Input Serial alone & (query. starting_address +
followed a starting address field to identify the data Access query. quantity) usedA
Size
location to access and a quantity of objects to access.
21 Holding TCP | stand- query. fc ∈ ℎ
Function codes 16 and 22 include a byte count field Register Serial alone & (query. starting_address +
after the quantity field. Function code 23 is a dual Access query. quantity) usedA
read/write command which requires separate rules. The Size
starting address is limited to the range defined by 22 Input TCP | stand- query. fc ∈ 
equation 19. Not all MODBUS servers implement all Register Serial alone & (query. starting_address +
legal addresses in the range defined by equation 19. Access query. quantity) usedA
Size
Furthermore, a program running in a MODBUS server
will not use all implemented addresses. The
Rules 19-22 alert when the function code matches
MODBUS server program (ladder logic or
one of the data access function codes and the total size
implementation language) can be parsed to generate a
of the memory access does not fall in the white list of
white list of used addresses. This white list is defined
used addresses. The variable usedA is referred to in
by equation 21.
each rule; however, usedA will be different for each
object type.
 ∈ {0$0, … ,0$%%%%} (19)
!! ∈ {!!():  ∈ } (20) The quantity field for all of the data access function
 ∈ {():  ∈ !!} (21)
The different data access function codes refer to up
to 2000 coils, 2000 discrete inputs, 2000 input
registers, and 2000 holding registers. These are 4
separate address ranges for 4 separate data objects. All
4 address ranges must adhere to the definition in
equation 19. However, for each range there will be a
separate set of implemented and used addresses.
15 Coil TCP | stand- query. fc ∈ 
Starting Serial alone & query. starting_address usedA
Address
16 Discrete TCP | stand- query. fc ∈ 
Input Serial alone & query. starting_address usedA
Starting
Address
1777
1775
codes is defined by equation 22. A data access with
quantity of 0 or greater than 2000 is illegal.
 ∈ {1, … ,2000} (22)
23 Illegal TCP | stand- query. fc ∈ dafc
Quantity Serial alone & query. quantity  Q
Rule 23 alerts when the quantity value is illegal. In
addition to checking for illegal quantities separate rules
can be added to check for supported quantities. As with
many other rules MODBUS system behavior is pre-
defined and limited. As such a limited set of used
quantities will exist for each allowed function code and
used address pair. Equations 23-26 define sets of used
quantities where acc() returns quantities which are
defined by the client program.
 '* ∈ {acc (, , ):  ∈ ,  ∈ ,  ∈  } (23) 30 PDU TCP | pre- query. fc ∈ {ca ∪ da}
-* ∈ {acc (, , ):  ∈ ,  ∈ ,  ∈  } (24) length Serial processor & .  == . 
;<* ∈ {acc (, , ):  ∈ ,  ∈ ℎ, ∈  } (25) coil/ & length(resp. pdu)
><* ∈ {acc (, , ):  ∈ ,  ∈ ,  ∈  } (26) discrete ≠ resp_pdu_length?YHZ
response
24 Invalid TCP | stand- query. fc ∈ ca 31 PDU TCP | pre- query. fc ∈ {hra ∪ ira}
Q, CA Serial alone & trans. quantity  Qlist ?@ length Serial processor & .  == . 
25 Invalid TCP | stand- query. fc ∈ ca register & length(resp. pdu)
Q, DA Serial alone & trans. quantity  Qlist B@ response ≠ resp_pdu_lengthG[\H]^[G
26 Invalid TCP | stand- query. fc ∈ ca
Q, HRA Serial alone & trans. quantity  Qlist FG@
A protocol mutation attack may alter the size of a
27 Invalid TCP | stand- query. fc ∈ ca
data access response to not match the expected size.
Q, IRA Serial alone & trans. quantity  Qlist HG@
Checking the response packet PDU length detects this
attack. Rules 30-31 alert if the size of the response
Rules 24-27 alert when the transaction quantity is
PDU does not match the expected size based upon the
not in the list of quantities. These rules are used list of
data access function code and the quantity of objects
quantities associates with all function code and address
requested.
pairs for each type of data access. Rule writers may
The write multiple coils (FC=15) and write
prefer to replace rules 24-27 separate rules for each
multiple registers (FC=16) function codes include a
function code and address pair.
bytecount in the query. A mismatch between this field
The different data access function codes each
and the actual number of bytes of coil or register
generate a response from the server which includes the
content in a packet can be protocol mutation attack and
requested quantity of coils, discrete input bits, or
may cause the MODBUS server network stack to
registers. The size of the response packets varies
incorrectly process the packet and lead to adverse
according to the type of data requested and the quantity
affects on the server. Equations 27 and 28 provide the
of requested objects. Coils and discrete inputs are
expected bytecount for write multiple coils (FC=15)
single bit; however, the returned quantity of coils or
and write multiple registers (FC=16) function codes
discrete inputs is rounded up to the nearest byte
respectively.
boundary. Register are 2 bytes each. Response packets
include the function code, a one byte field which is the
32 bytecount TCP | stand- query. fc ∈ {15}
byte count, and the returned data objects. write Serial alone & query. bytecount
mult coil ≠ bytecount ?YHZ
I'J>K = %8 + ⌈/8⌉ (27)
33 bytecount TCP | stand- query. fc ∈ {16}
I<OS>TVO< =  ∗ 2 (28)
write Serial alone & query. bytecount
mult ≠ bytecount G[\H]^[G
28 bytecount TCP | pre- query. fc ∈ {ca ∪ da} register
coil/ Serial processor & .  == . 
discrete & resp. bytecount
Rules 32 and 33 alert if the query bytecount does
≠ bytecount ?YHZ
29 bytecount TCP | pre-
not match the bytecount predicted from the quantity
query. fc ∈ {hra ∪ ira}
register Serial processor & .  == .  field in the same packet. The mismatch can come from
& resp. bytecount an incorrect quantity or incorrect bytecount.
≠ bytecount G[\H]^[G The length of the write multiple coils (FC=15) and
write multiple registers (FC=16) function code query
Rules 28-29 alert if the bytecount field of a data access PDU is predictable from the quantity value in the
response packet does not match the requested number packet the object type (from the function code).
of objects from the previous query. Confirming that
__ ℎ`jKV'J>K = 6 + I'J>K (31)
both the query and response function codes match __ ℎ`jKV<OS = 6 + I<OS>TVO< (32)
ensures that rules 28-29 will not alert if the response
packet is an error. 34 PDU TCP | stand- query. fc ∈ {15}
length Serial alone & length(query. pdu)
__ ℎ'J>K = 2 + I'J>K (29) mult coil ≠ query_pdu_lengthkvZ^?YHZ
__ ℎ<OS>TVO< = 2 + I<OS>TVO< (30) write

1778
1776
35 PDU TCP | stand- query. fc ∈ {16} function codes in the allowed error function list which
length Serial alone & length(query. pdu) is defined by equation 13.
mult ≠ query_pdu_lengthkvZ^G[\ Exception code 01 is always used to indicate that a
register function code is not supported. Attackers may inject a
write function code supported errors for supported function
codes.
Rules 34 and 35 alert if the PDU length of write
multiple coil and multiple register queries does not % ∈ allowedPC ∪ implementedUD ∪ usedRC (33)
match the predicted PDU length based upon the
quantity field in the query packet. 40 Invalid TCP | pre- query. fcsupportedFC
The write multiple coils and write multiple registers Function Serial processor & . 
Code ∈ #
function codes allow a limited quantity of coils and Error & . $
registers to be written. The valid quantity ranges are code ∈ {01}
shown by equations 33 and 34. 41 Invalid TCP | pre- query. fc ∈ supportedFC
Function Serial processor & . 
 `jKV'J>K ∈ {1, … ,0$7I0} (33) Code ≠ query. fc + 0x80
 `jKV<OS ∈ {1, … ,0$7I} (34) Error (2) & . $
code ∈ {01}
36 write TCP | stand- query. fc ∈ {15}
mult coil Serial alone & query. quantity  Rule 40 alerts if the query function code is a
quantity quantitykvZ^?YHZ support function code but the response function code
37 write TCP | stand- query. fc ∈ {16} indicates an exception code of 01. Rule 41 alerts if an
mult reg Serial alone & query. quantity unsupported function code does not generate an error
quantity  quantitykvZ^G[\
response with exception 01 (unsupported function
code).
Rules 36 and 37 alert if the write multiple coil or Exception code 02 is used for multiple function
coils quantity field is outside of the valid range. codes. The most common use of this exception code
The write single coil function code (FC=5) function is to report that the requested address range is not valid
code allows only 2 values to be written to the coil. The for data access commands. For data access commands
value 0x0000 turns a coil off and 0xFF00 turns a coil which read or write to a single location exception code
off. 02 is used report an error in the starting address. For
data access commands which read or write to multiple
37 Illegal TCP | stand- query. fc ∈ {5} locations exception code 02 is used report an error
Quantity Serial alone & query. output value
related to the entire accessed address range. The single
 {0x0000, 0xff00}
object access function codes are defined by equation
34. The multiple object access function codes are
Rule 37 alerts if the output value field of a write
defined by equation 36.
single coil query is not 0x0000 or 0xFF00.
The MODBUS protocol used four exception codes
 ∈ {5, 6} (34)
to delineate error types. The legal exception codes are ! ∈ {1, 2, 3, 4, 15, 16, 23} (35)
shown in equation 35. The read file record (FC=21)
and write file record (FC=22) mention the possibility 42 Single TCP | pre- query.fc ∈ sa
of exception 08. However, there is no documentation Access Serial processor & (query.starting address)
showing how exception code 08 would be used in the Address ∈ usedA & resp.fc ==
Error query.fc+0x80
MODBUS Application Protocol Specification and
& resp.exception code==2
therefore this exception code was ignored for this 43 Multiple TCP | pre- query.fc ∈ ma &
work. Access Serial processor (query.starting address+
Address query.quantity) ∈ usedA
$ ∈ {01,02,03,04} (35) Error & resp.fc ==
query.fc+0x80
38 Illegal TCP | stand- response. fc ∈ allowedEC & resp.exception code==2
Exception Serial alone & response. exception code
Code  exceptions Rules 42 and 43 alert when a data access address
range is valid but the response indicates and error with
Rule 38 alerts if an illegal exception code is found exception code 02. Rules 42 and 43 refers the variable
in an error response packet. Rule 38 triggers only for usedA which is defined equation 21.

1779
1777
44 Single TCP | pre- query.fc ∈ sa Rule 50 alerts when a response with exception code 04
Access Serial processor & (query.starting address) occurs. This rule may indicate a cyber attack or a faulty
Address  usedA & resp.fc != MODBUS server. Both are important to bring to the
Error (2) query.fc+0x80 attention of system administrators.
45 Multiple TCP | pre- query.fc ∈ ma &
Access Serial processor (query.starting address+
Address query.quantity)usedA 4. Future Works
Error (2) & resp.fc != query.fc+0x80
This work is not an exhaustive treatment of the
Rules 44 and 45 alert when a data access address MODBUS protocol. Rules remain to be written for the
range is not valid and the response is not an error. read exception status, diagnostics, get comm event
Exception code 02 is also used by the 2 file access counter, report slave id, get comm event log, report
functions (FC=20, 21) and the Read FIFO queue slave id, read file record, write file record, read/write
function (FC=24), and the Read Slave ID function multiple registers, read FIFO queue, encapsulated
(FC=17). Future work is required to derive rules interface transport, CANopen general reference request
associated with these function codes. and response PDU, and read device identification
Exception code 03 is used by multiple functions to function codes. These function codes are less common
report errors related to data checks. The data access and system implementers should configure rules 8 and
functions use exception code 03 to the quantity field. 9 to alert if their function codes or error function codes
are detected on the MODBUS link. If these function
46 write TCP | stand- query. fc ∈ {15} codes are used by the system rules should be written to
mult coil Serial alone & query. quantity  detect invalid use cases.
quantity quantitykvZ^?YHZ
MODBUS is one of many communication
Error & (resp.fc != query.fc+0x80
|| resp.exception code != 03)
protocols used by industrial control systems. IDS rules
47 write TCP | stand- query. fc ∈ {16} are needed for many other protocols including but not
mult reg Serial alone & query. quantity  limited to ICCP, DNP3, IEEE C37.118, and the family
quantity quantitykvZ^?YHZ of IEC 61850 protocols.
Error & (resp.fc != query.fc+0x80
& resp.exception code != 03 5. Conclusions
Rules 46 and 47 alert when a data access quantity is Industrial control system operators often perform
invalid but the response is not an error or the response intrusion detection on PCs and enterprise systems in
error is not exception code 03. control rooms. Industrial control system operators
most often do not monitor communication traffic on
48 write TCP | stand- query. fc ∈ {15} the operation networks interconnecting industrial
mult coil Serial alone & query. quantity ∈ control system devices such as master terminal units,
quantity quantitykvZ^?YHZ
Error (2)
PLC, remote terminal units, and intelligent electronic
& resp.fc == query.fc+0x80
& resp.exception code == 03 devices. This work provides details on 50 intrusion
49 write TCP | stand- query. fc ∈ {16} detection rules developed to detect malicious activity
mult reg Serial alone & query. quantity  on industrial control system MODBUS communication
quantity quantitykvZ^?YHZ networks. The rules described in this paper are
Error (2) & (resp.fc == query.fc+0x80 intended for use with the SNORT Intrusion Detection
& resp.exception code == 03 System. However, the rules are described in a non-
proprietary format to encourage their use on any
Rules 48 and 49 alert when a data access quantity is signature based intrusion detection system.
valid but the response is an error and the response
exception code is 03.
Exception code 04 indicates that all query checks 6. References
passed yet the function was not successfully
implemented. This exception code may indicate a fault [1] North American Electric Reliability Corporation.
with the MODBUS server or may indicate a that an Standard CIP–005–4a - Cyber Security - Electronic
attacker has inserted an invalid response for a valid Security Perimeter(s). January 2011.
MODBUS query. http://www.nerc.com/files/CIP-005-4a.pdf
[2] Morris, T., Pan, S., Lewis, J., Moorhead, J., Reaves, B.,
50 Exception TCP | stand- resp. exception code == 04 Younan, N., King, R., Freund, M., Madani, V.
04 Serial alone

1780
1778
 Cybersecurity Testing of Substation Phasor
Measurement Units and Phasor Data Concentrators. The
7th Annual ACM Cyber Security and Information
Intelligence Research Workshop (CSIIRW). October
12-14, 2011. Oak Ridge, TN.
[3] Morris, T., Pan, S., Adhikari, U., Younan, N., King, R.,
Madani, V. Cyber Security Testing and Intrusion
Detection for Synchrophasor Systems. Submitted to
International Journal of Cyberspace Sciences and
Emergency Management (IJCSEM). Inderscience.
(submitted 03/2012)
[4] Morris, T., Vaughn, R., Dandass, Y. A Retrofit Network
Intrusion Detection System for MODBUS RTU and
ASCII Industrial Control Systems. Proceedings of the
45th IEEE Hawaii International Conference on System
Sciences (HICSS – 45). January 4-7, 2012. Grand
Wailea, Maui.
[5] O'Murchu, L. Last-minute paper: An indepth look into
Stuxnet. The 20th Virus Bulletin International
Conference. September 29 – October 1, 2010,
Vancouver, BC, Canada.
[6] Falliere, N., Murchu, L., Chien, E., W32.Stuxnet
Dossier, Version 1.3. Symantec Security Repsonse.
November 2010.
[7] Caswell, B. Bealeand, J., Foster, J. and Faircloth, J.
“Snort2.0 Intrusion Detection,” Syngress, Feb. 2003.
[8] Peterson, D. "Quickdraw: Generating Security Log
Events for Legacy SCADA and Control System
Devices," Conference for Homeland Security, 2009.
CATCH '09. Cybersecurity Applications & Technology,
pp.227-229, 3-4 March 2009
1781
1779
[9] Roosta, T. Nilsson, D., Lindqvist, U. Valdes, A. An
intrusion detection system for wireless process control
systems. 5th IEEE International Conference on Mobile
Ad Hoc and Sensor Systems, pp866-872, Atlanta, GA,
2008.
[10] Cheung, S., Valdes, A. Communication Pattern
Anomaly Detection in Process Control Systems. IEEE
International Conference on Technologies for Homeland
Security. Waltham, MA. May 11-12, 2009.
[11] Valdes, A., Cheung, S. Intrusion Monitoring in Process
Control Systems. Proceedings of the 42nd Hawaii
International Conference on System Sciences. 2009.
[12] Rrushi, J., Kang, K., Detecting Anomalies in Process
Control Networks. IFIP International Federation for
Information Processing 2009.
[13] Gao, W., Morris, T., Reaves, B., Richey, D. On SCADA
Control System Command and Response Injection and
Intrusion Detection, in the Proceedings of 2010 IEEE
eCrime Researchers Summit. Dallas, TX. Oct 18-20,
2010.
[14] MODBUS Messaging on TCP/IP Implementation Guide
V1.0b
http://www.modbus.org/docs/Modbus_Messaging_Impl
ementation_Guide_V1_0b.pdf
[15] Modbus Application Protocol Specification V1.1b
http://www.modbus.org/docs/Modbus_Application_Prot
ocol_V1_1b.pdf
[16] MODBUS over Serial Line Specification and
Implementation Guide V1.02
http://www.modbus.org/docs/Modbus_over_serial_line_
V1_02.pdf