Deterministic Intrusion Detection Rules for MODBUS Protocols

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 † [email protected] 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.

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 0054a [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

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 subclasses). 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].

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 IDENTIFIER IDENTIFIER

LENGTH

UNIT 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.

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

1

1774 1772

Protocol Identifier

TCP

standalone

trans.protid != 0

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.

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 MODBUS/TCP client and server behavior to determine system response to non-matching query and 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 Response Pairs

TCP

preprocessor

  ∈ { ():  ∈ }  ∈ { ():  ∈ }  ℎ  ∈ { ℎ():  ∈   ⋃  5

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.

3

Length

TCP

standalone

(1)

6

Max Length

standalone

trans. length  lengthlist

Unit ID

TCP

standalone

trans. unitid  {0, … ,247}

trans.length != actual_length

Rule 6 alerts if the transaction unit identifier field is not between 0 and 247. MODBUS RTU and ASCII systems include a single byte address to a single client to address multiple MODBUS servers. Each MODBUS server is assigned a unique address. MODBUS systems typically have a static configuration in which the number of servers does not change and the address assignment of the individual clients does not change. Equation 5 defines the legal address range for MODBUS RTU and ASCII systems. Equation 6 defines the set of used addresses for a given MODBUS system where used(a) returns addresses in use for the protected MODBUS system.

Rule 3 alerts if the transaction length does not match the actual remaining length of the packet. The MODBUS/TCP length field is 2 bytes, however, the maximum total length of a MODBUS/TCP packet (MBAP+Function Code+payload) is specified has 260 bytes. From this the maximum value contained in the length field of the MODBUS/TCP packet is 260-6=254 bytes, where 6 is the size of the transaction ID + protocol ID + length fields. 4

TCP

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.

query.transid != response.transid

_ ℎ =  (  ) +  (  ) +  ()

Length List

(2) (3) (4)

TCP

standalone

trans.length 254

>

 ∈ {0, . . ,247}  ∈ {():  ∈ }

Rule 4 alerts if the transaction length field is greater than 254. MODBUS systems typically implement a fixed set of queries which can be derived from the logic used to control the master terminal unit (or MODBUS client).

7

1775 1773

Serial Address

Serial

standalone

(5) (6)

trans. addr  usedADDR

9

Rule 7 alerts if the MODBUS RTU or ASCII address is not in the list of used addresses for the protected system. Address 0 is a broadcast address. Many system implementers will prefer to disallow use of the broadcast address. 8

Serial Address not 0

Serial

standalone

Rule 8 alerts if the MODBUS RTU or ASCII transaction address is 0. This rule is optional and should only be used if broadcast addressing is prohibited. The MODBUS/TCP function code field is a single byte. MODBUS specifications define 4 types of function codes; public function codes, user defined function codes, reserved function codes, and error function codes. Equation 7 lists the set of public function codes.

standalone

query. fc allowedPC ∪ implementedUD ∪ usedRC

# ∈ { + 0$80:  ∈  ∪ !! ∪ } 10

Response Function Codes

TCP | Serial

standalone

(13)

resp. fc allowedPC ∪ implementedUD ∪ usedRC ∪ allowedEC

Rule 10 alerts if a response’s function code is not in the set of allowed public function codes, implemented user defined codes, used reserved codes, or allowed error codes. As stated previously, MODBUS queries and responses arrive in pairs. Query and response function codes must match or the response function code must be the query function code + 0x80 in the event of an error.

 ∈ {1,2,3,4,5,6,7,8,11,12,15,16,17,20,21,22,23,24,43} (7)

MODBUS implementers may wish to limit the set of allowed public function codes to a subset of UD. For example function code 8 is a diagnostic function code which provides such commands as force listen only mode and clear counters and diagnostic register. Equation 8 defines the set of allowed public function codes where allowed(f) returns function codes permitted by the MODBUS system implementer or IDS rule writer.

11

FC Query Response

TCP | Serial

preprocessor

resp. fc {query. fc, query. fc + 0x80}

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.

(8)

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} !! ∈ { !!():  ∈ }

TCP | Serial

Rule 9 alerts if a query’s function code is not in the set of allowed public function codes, implemented user defined codes, or the set of used reserved codes. When a MODBUS query generates an error at the MODBUS server an error function code is returned in the response. The error function code is the query function code + 0x80. Allowed error codes are defined by equation 13.

trans. addr == 0

 ∈ {():  ∈ }

Query Function Codes

(9) (10)

/ ∈ {8/{0, … ,18, 20},43/{13,14}} 12

Reserved function codes are codes in the public code space which have been used by legacy devices and which are not supported as public codes. IDS rule writers should define set of used reserved codes for the protected system. This set is most often empty. Reserved function codes are in the range defined by equation 11. Used reserved function codes are defined by equation 12 where used(f) returns function codes in use by the protected system.

13

FC=8 SubCodes FC=43 SubCodes

(14)

TCP | Serial

standalone

trans. fc == 8 & trans. sc {0, … , 18, 20}

TCP | Serial

standalone

trans. fc == 43 & trans. sc {13,14}

Rules 12 and 13 alert if the function sub-code is not allowed. 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 code sub-code pairs should replace rule 12 with rule 14. 14

FC/SC FC=8

17 Holding Register Starting Address 18 Input Register Starting Address

TCP | stand-alone trans. fc == 8 & Serial trans. sc {0, … , 21}

MODBUS includes a set of data access function codes for reading and writing different types of data; discrete inputs, coils, and registers. These function codes are defined by equation 15-19 where ca is the set of coil access codes, da is the set of discrete input access codes, hra is the set of holding register access codes, and ira is the set of input register access codes.  ∈ {1, 5, 15}  ∈ {2} ℎ ∈ {3,6,16,23}  ∈ {4}  ∈  ∪  ∪ ℎ ∪ 

(15) (16) (17) (18) (19)

 ∈ {0$0, … ,0$%%%%} !! ∈ { !!():  ∈ }  ∈ {():  ∈ !!}

(19) (20) (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 Starting Address 16 Discrete Input Starting Address

TCP | stand- query. fc ∈  Serial alone & query. starting_address usedA TCP | stand- query. fc ∈  Serial alone & query. starting_address usedA

TCP | stand- query. fc ∈  Serial alone & query. starting_address usedA

Rules 15-18 alert when the function code matches one of the data access function codes and the starting address is not in the white list of used addresses. The variable usedA is referred to in each rule; however, usedA will be different for each object type. The start address is followed by a quantity field. Together the start address and the quantity can be used to compute the total address space required by the read. 19

20

Each of the data access function codes is to be followed a starting address field to identify the data location to access and a quantity of objects to access. Function codes 16 and 22 include a byte count field after the quantity field. Function code 23 is a dual read/write command which requires separate rules. The starting address is limited to the range defined by equation 19. Not all MODBUS servers implement all legal addresses in the range defined by equation 19. Furthermore, a program running in a MODBUS server will not use all implemented addresses. The MODBUS server program (ladder logic or implementation language) can be parsed to generate a white list of used addresses. This white list is defined by equation 21.

TCP | stand- query. fc ∈ ℎ Serial alone & query. starting_address usedA

21

22

Coil Access Size Discrete Input Access Size Holding Register Access Size Input Register Access Size

TCP | stand- query. fc ∈  Serial alone & (query. starting_address + query. quantity) usedA TCP | stand- query. fc ∈  Serial alone & (query. starting_address + query. quantity) usedA TCP | stand- query. fc ∈ ℎ Serial alone & (query. starting_address + query. quantity) usedA TCP | stand- query. fc ∈  Serial alone & (query. starting_address + query. quantity) usedA

Rules 19-22 alert when the function code matches one of the data access function codes and the total size of the memory access does not fall in the white list of used addresses. The variable usedA is referred to in each rule; however, usedA will be different for each object type. The quantity field for all of the data access function codes is defined by equation 22. A data access with quantity of 0 or greater than 2000 is illegal.  ∈ {1, … ,2000} 23 Illegal Quantity

TCP | standSerial alone

(22) query. fc ∈ dafc & 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 predefined 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.

1777 1775

 '* ∈ {acc (, , ):  ∈ ,  ∈ ,  ∈  }  -* ∈ {acc (, , ):  ∈ ,  ∈ ,  ∈  }  ;K __ ℎTVO< = 2 + ITVO
K = 6 + I'J>K __ ℎ`jKV