A Linux-based firewall for the DNP3 protocol

Jeyasingam Nivethan Mauricio Papa

Tandy School of Computer Science Tandy School of Computer Science
University of Tulsa University of Tulsa
Tulsa, OK 74104 Tulsa, OK 74104
Email: [email protected] Email: [email protected]

Abstract—Firewall solutions, specifically designed for smart to recognize the various packet fields used by the control
power grids and other industrial control systems, are quite protocol. By doing so, the firewall has the ability to filter
limited, with only a few commercial offerings. This paper presents protocol-specific attacks. Some commercial vendors provide
a novel methodology that extends existing Linux-based firewalls
for use in systems that use DNP3 protocol for industrial control. firewall solutions for certain ICS protocols (such as Modbus,
The proposed solution uses the u32 byte-matching feature of which is used by the oil & gas sector, and DNP3). Cisco
the iptables firewall, a firewall solution available in most Linux provides DNP3 specific signatures for some of their firewalls
distributions. To demonstrate the approach, filtering rules for [4]. Raidflow provides DNP3 packet filtering capabilities with
common attacks on the DNP3 protocol were developed. DNP3 its 1031 Secure Ruggedized Gateway [5]. On the other hand,
is an industrial control protocol typically used in the electric
power sector. The main goal of our work is to leverage an openly there have not been any significant efforts made to use open
available and robust firewall solution for use in protecting the source firewalls to filter DNP3 network traffic. Open source
U.S. smart grid. The prototype was tested on a scaled-down firewalls, such as Linux iptables have been successfully used
electric power substation which runs the DNP3 protocol for in IT networks to protect mission critical systems [6]. This
communication between the field devices and the SCADA master. paper presents a novel approach for the generation of DNP3
specific iptables filtering rules. The proposed solution uses
an advanced feature of iptables to inspect the payload of a
I. I NTRODUCTION
DNP3 message and to identify suspicious DNP3 commands.
DNP3 (Distributed Network Protocol Version 3.0) is one In addition, we also present a set of rules for the most common
of the most popular Industrial Control System (ICS) protocol attacks on the DNP3 protocol. These rules allow iptables to
[1], widely known for its use in the Electric power sector recognize specific DNP3 protocol packet fields and go beyond
in the U.S. and around the world. According EPRI [2], it is basic TCP/IP filtering capabilities. The goal of this research
estimated that more than 75% of the Electric power utilities in effort is to provide an effective and openly available DNP3
the US use DNP3. Originally developed as a serial protocol, firewall solution that advances the security posture of the
DNP3 (as most ICS protocols) has been modernized and is Energy sector.
now transported over TCP/IP. The use of commodity Ethernet
II. BACKGROUND
hardware and TCP/IP for communication provides a good
solution in terms of maintenance and operational costs. If DNP3 is a SCADA protocol originally designed for serial
not adequately protected, the use of TCP/IP may expose communication (like other traditional SCADA protocols). As
these delicate systems to the larger Internet. This results in with many other protocols, DNP3 has been extended to allow
increased risk by making them potential targets for cyber- the use of TCP/IP as the transport mechanism for DNP3
attacks. While it is possible to isolate the ICS from the Internet, messages. The TCP/IP extension simply encapsulates an entire
if not done correctly, an attacker or malware could still gain DNP3 frame with TCP/IP headers, i.e., the encapsulation
access to the control network and cause serious damage to preserves the original pseudo-transport and link layer header
the physical components and the infrastructure. In 2014, the and payload. Therefore a DNP3 packet sent over the TCP/IP
Industrial Control Systems Cyber Emergency Response Team (or UDP/IP) will also have DNP3 data-link and pseudo-
(ICS-CERT) received and responded to 245 security incidents transport header fields. The DNP3 pseudo-transport layer and
from various industrial control systems. [3] Of those 245 link layer were part of the communication stack for serial
incidents, more than half involved persistent threats associated connections. A DNP3/TCP packet (Figure 1) will have an
with sophisticated actors. It is important to note that of all the Ethernet header, an IP header, and a TCP header. Then within
sectors reporting to ICS-CERT, the energy sector accounts for the TCP payload, a message has a link header, a transport
the majority of the reported incidents (32% of all reported header and an application header followed by a number of
incidents). This is a clear indication that further research DNP3 objects and header tuples.
is needed to better protect the Energy sector. Firewalls are A DNP3 message may incorporate the following fields:
commonly used to protect networks from malicious attacks. • Start - This two-byte field indicates that it is a DNP3
When protecting ICS, it is critical that firewalls be able packet with the value 0x0564
 Fig. 1. DNP3 message architecture

• Length - One byte field contains the length of all the network and transport headers and very rarely check payload
subsequent fields without the CRC contents. An iptables feature, added only a few years ago,
• Control - One byte control field that contains the direction allows for the dynamic inspection of message payloads. This
of the message flow, data-link function codes and some feature is called u32 match and our proposed solution uses it
other indicators. as the basic mechanism to inspect DNP3 packets (beyond the
• Destination - Two byte field that identifies the receiver of standard checks on TCP/IP headers).. The u32 match feature
the message instructs the module to extract 32 bits (4 bytes) from the packet
• Source - Two byte field that identifies the sender of the at any specified location and compare it against a given value.
message If the field that needs to be extracted is less than 32 bits,
• FIN - One bit indicates this is the last fragment the extracted data is masked and shifted. This option, makes
• FIR - One bit indicates that this is the first fragment it possible to match up to 32 bits of data from any part of
• Sequence number - Six bit sequence number used for the packet. This feature also provides a simple technique to
fragmentation and reassembly overcome the variable header length problem when options are
• Application control - One byte field designed to facilitate used in TCP or IP. This technique uses the header-length field
fragmentation within application layer. This field also has of the packet to calculate the header length and then jump
a bit that indicates whether a message from outstation is to the beginning of its ICS message. Our solution follows
unsolicited or a response for a request. the following steps to generate iptables rules that can filter
• Function code - One byte field that indicates the function SCADA messages using u32:
to be performed by the receiving device 1) From the IP header, calculate the header length by
• Indicators - Two byte internal indicators which are only extracting the hlen field value in the IPv4 header and
used by the responses from the outstations multiply it by four. The resulting value is the length in
• DNP3 object header - Two byte header for each DNP3 bytes of the IP header.
object set present in the message 2) Use the calculation in the previous step to jump to the
• DNP3 objects - DNP3 objects contain values (input beginning of the TCP header (also the beginning of the
readings and output updates) from and to the outstations packets IP payload).
3) From the TCP header, extract the offset field and multi-
III. E XTENDING THE L INUX IPTABLES FIREWALL FOR USE ply it by four. The resulting value is the length in bytes
WITH DNP3
of the TCP header.
Netfilter/Iptables is available with almost all popular Linux 4) Use the calculation in the previous step to jump to the
distributions. Technically speaking, Iptables is the user-space beginning of the DNP3 packet (also the beginning of the
module of the Linux netfilter framework. The Linux kernel DNP3 header).
incorporates the Netfilter framework which provides functions 5) From this point in the packet, jump to the FIR bit and
that include packet filtering, network address translation, and check if the bit is set to one. This indicates this is the
packet mangling. Iptables rules often check only data-link, first fragment of a message.
 Fig. 2. IP header Fig. 3. TCP header

6) If the FIR bit is set, then match the function code field
against the desired value.
Header length fields of IP and TCP represent the header
length as 4-byte words, i.e., the value should be multiplied by
4 to obtain the actual length in bytes. The header length field
of IP is located in bits 4-7 of the first byte (Figure 2). Since
u32 extracts 4 bytes (32 bits) at a time, the actual value of the
IP header length can be obtained by extracting the first four
bytes of the IP header, right shifting 22 bits and masking the
result with 0x3C (this quarantines the field and multiplies it
by four at the same time) . The u32 command to perform this
operation is 0>>22&0x3C. The @ sign instructs a jump of n
bytes, where n precedes the @ sign. For instance, if the result
of 0>>22&0x3C is 20 (the length of an IP header without
any options), then 0>>22&0x3C@ will jump 20 bytes from,
in this case, the beginning of the IP header. After this jump,
iptables is pointing at the start of the TCP header. In the similar
manner, the TCP header length can be obtained to jump to
the end of the TCP header, which is also the beginning of
the DNP3 packet. The TCP header length is represented by
the offset field (Figure 3) which starts at byte 12 (from the
beginning of the TCP header). Following the same procedure
used for the IP header, a jump to the end of the TCP header
can be made with 12>>26&0x3C@. At this point, iptables Fig. 4. Iptables rules for common DNP3 attacks
is ready to start inspecting the DNP3 packet. One of most
important field to inspect in a DNP3 message is the function
code field. This field carries specific commands (represented DNP3 data-link layer [7]. A DNP3 firewall or IDS (Intru-
by different numbers) to the outstation devices as transmitted sion Detection System) must be able to monitor and check
by the master node. The function code field is part of the fragmented DNP3 messages. IDS preprocessors (such as the
application header of a DNP3 message and is always located Snort preprocessor for DNP3) have the ability to reassemble
at byte 12 from the beginning of the DNP3 message. For DNP3 fragments in order to reconstruct a full DNP3 message.
instance, consider function code 13 (0xD) which is a cold Firewalls in general will not attempt to reconstruct DNP3
start command that reboots the PLC. It can be simply matched fragments (the final DNP3 recipient should be able to do so).
using the 12>>24&0xff=0xD directive to look for function In many applications, this type of preprocessing is not done
code 13 (assuming iptables is already inspecting the beginning at the Firewall because the reassembly process may cause
of the DNP3 packet). unacceptable delays. Timing requirements in the electric power
DNP3 protocol has a pseudo-transport layer that supports sector are very common to ensure that response times are
message fragmentation and reassembly. This feature is needed adequate. For instance, the maximum delay for a trip signal
in case a message is too long for transmission over the message should not be more than 4 milliseconds for a power-
line frequency of 60Hz [8]. Our proposed solution seeks to registers, without requiring an acknowledgement from
provide protection for the DNP3 protocol without the added the affected outstation. An attacker can send a DNP3
burden of reassembling fragmented messages. This is done by message with function code 10 and clear the frozen
taking advantage of how DNP3 handles fragmentation, i.e., by registers which may contain important information. The
setting FIR bit to true for the first fragment. It is important to freeze clear command using function code 9 also does
note that an unfragmented DNP3 frame is also transmitted with the same but it requires the device to send a response
FIR flag set. This first DNP3 fragment also contains the control upon clearing.
fields associated with the message. A DNP3 receiver will • DNP3 warm restart: A DNP3 request with function code
drop any fragments for which it has not observed a fragment 14 Warm Restart, restarts the communication tasks in
marked as FIR. We propose a method that only filters the first the outstation. A continuous stream of requests of this
DNP3 fragment if needed, e.g. when it matches a rule for a type causes a denial of service attack. Such an attack
prohibited operation. In doing so, we achieve two goals: (i) could prevent an outstation from communicating with the
protect the receiving device (which will drop all subsequent Master and HMI.
fragments because the first fragment is missing) and (ii) avoid • DNP3 cold restart: A DNP3 request with function code 13
reassembly at the firewall level. Since unfragmented DNP3 Cold Restart, restarts an outstation device. A continuous
traffic also goes with the FIR flag set, the proposed approach stream of requests causes a denial of service attack and
effectively protects devices against fragmented and unfrag- makes the outstation unavailable.
mented messages. We can check whether FIR is set with a • DNP3 broadcast request: the DNP3 data-link layer has
10>>30&0x01=0x01 u32 directive. Additional u32 directives a two byte field to denote the destination address of the
can then be used to inspect control fields. To illustrate a more message. A message with broadcast address (0xFFFF)
sophisticated use of the u32 directive, consider the case where in this field will send the message to all other DNP3
the firewall needs to filter Cold Restart messages (function outstation devices. An attacker could use this technique
code 13). This could be done with the following iptables rule: to obtain the address of all DNP3 servers (outstation
sudo iptables -A INPUT -p tcp –dport 20000 -m u32 –u32 devices) or to flood the network with broadcasts.
“0>>22&0x3c@ 12>>26&0x3C@ 10>>30&0x01=0x01 Firewall rules (Figure 4) were developed for the attacks
&& 0>>22&0x3c@ 12>>26&0x3C@ 9&0xff=0x0D” -j described above and then tested in a smart grid testbed.
DROP
This rule contains two tests or parts: IV. E XPERIMENTAL R ESULTS

• 0>>22&0x3c@ 12>>26&0x3C@ to jump over the Proposed solution was tested on the smart-grid test bed at
IP and TCP headers by calculating their lengths and the University of Tulsa. The Critical Infrastructure Protection
10>>30&0x01=0x01 to checks whether the FIR flag is Lab at The University of Tulsa has a scaled-down electric
set power substation (Figure 5). The design of the substation
• 0>>22&0x3c@ 12>>26&0x3C@ to jumps over the IP closely reflects the topology of a ring-type substation with
and TCP headers and then jumping to byte 9 to check redundant lines as well as inductive and resistive loads. Input
whether the function code (located in byte 12) is 13 (0xD) power level is limited to voltage availability in the lab building.
using 9&0xff=0x0D(bytes 9-11 are masked). The substation uses three-phase 208V input voltage (dual
inputs) and was designed for an estimated power consumption
The following list describes the most common attacks on the of 3KVA. The substation uses two controllers, also known as
DNP3 protocol [9], [10]: programmable logic controllers that communicate over an Eth-
• DNP3 disable unsolicited responses: DNP3 has an option ernet network using the DNP3 protocol. This facility has all the
where the master can disable unsolicited responses by elements needed to validate our approach: physical elements
sending a message with function code 21. Outstation (power input, switching relays), hardware interface (current
devices may be configured to update the master with and voltage transducers), software and control (programmable
unsolicited messages. In those cases, this type of message logic controllers) and communications (DNP3 over Ethernet).
would prevent the master from getting any unsolicited The Firewall was implemented on a dual-homed Ubuntu
messages from the target outstation. 14.04 LTS computer and placed between the two PLCs (out-
• DNP3 stop application: An attacker could send a DNP3 station devices) and the HMI. A rogue DNP3 master was
message with function code 18 and stop the applications deployed on the network to help generate malicious messages
running in an outstation device. This will essentially make targeting the PLCs. When the rogue master tried to attack
outstation devices unreachable to the master, because the grid by sending various types of malicious messages,
outstation devices do not have running applications to the firewall successfully blocked them. This was verified by
process a request. inspecting the iptables log (Figure 6 shows a few selected log
• DNP3 freeze clear: DNP3 PLCs have a set of specific entries generated during the experiment) and the unchanged
registers known as frozen registers which are allocated indicators on the HMI panels. When the firewall was disabled,
by the master for specific purposes, e.g. internal counter. the malicious packets were received by the PLCs and its effects
The freeze clear command, function code 10, clears these were directly observed by the HMI panels.
 Fig. 5. Electric power testbed at the CIP lab, University of Tulsa

words, the u32 feature can be effectively used to dynamically

inspect a DNP3 message transported over TCP/IP. Rules
for most common attacks on the DNP3 protocol are also
presented in the paper. These rules were all developed using
the methodology described in the paper. The solution has been
tested and validated on the smart-grid test bed at the Critical
Infrastructure Laboratory at the University of Tulsa.
R EFERENCES
[1] IEEE Standard for Electric Power Systems Communications-Distributed
Network Protocol (DNP3), in IEEE Std 1815-2012 (Revision of IEEE
Std 1815-2010) , vol., no., pp.1-821, Oct. 10 2012
[2] Electric Power Research Institute, Distributed Network Protocol 3 Secu-
rity Interoperability, Dec 2011, Palo Alto, CA
[3] ICS-CERT Monitor September 2014 February 2015
[4] Cisco, Inc. Cisco IOS Intrusion Prevention System (IPS) for Connected
Energy, White paper.
[5] 1031 Secure Ruggedized Gateway. http://www.radiflow.com/products/1031-
secure-ruggedized-gateway
[6] ] Lawton, George. “Open source security: opportunity or oxymoron?.”
Computer35, no. 3 (2002): 18-21.
[7] Curtis, Ken. “A DNP3 protocol primer.” DNP User Group (2005): 1-8.
[8] ] Nivethan, Jeyasingam, Mauricio Papa, and Peter Hawrylak. “Modeling
and simulation of electric power substation employing an IEC 61850
network.” In Proceedings of the 9th Annual Cyber and Information
Security Research Conference, pp. 89-92. ACM, 2014.
[9] East, Samuel, Jonathan Butts, Mauricio Papa, and Sujeet Shenoi. “A
Taxonomy of Attacks on the DNP3 Protocol.” In Critical Infrastructure
Protection III, pp. 67-81. Springer Berlin Heidelberg, 2009.
[10] Mander, Todd, Richard Cheung, and Farhad Nabhani. “Power System
Peer-to-Peer Networking Data Object Based Security.” In Power Engi-
neering, 2006 Large Engineering Systems Conference on, pp. 90-94.
IEEE, 2006.

Fig. 6. Iptables log

V. C ONCLUSION

This paper describes a novel approach for the use of the

iptables open-source firewall facility (available with most
Linux distributions), to protect against attacks on the DNP3
protocol. Experimental results show the approach succeeds
in blocking attacks targeting the DNP3 protocol. In other