Information Security Journal: A Global Perspective

ISSN: 1939-3555 (Print) 1939-3547 (Online) Journal homepage: http://www.tandfonline.com/loi/uiss20

On the use of open-source firewalls in ICS/SCADA

systems

J. Nivethan & M. Papa

To cite this article: J. Nivethan & M. Papa (2016): On the use of open-source firewalls in ICS/
SCADA systems, Information Security Journal: A Global Perspective

To link to this article: http://dx.doi.org/10.1080/19393555.2016.1172283

Published online: 29 Apr 2016.

Submit your article to this journal

View related articles

View Crossmark data

Full Terms & Conditions of access and use can be found at

http://www.tandfonline.com/action/journalInformation?journalCode=uiss20

Download by: [172.56.8.226] Date: 29 April 2016, At: 09:37

 INFORMATION SECURITY JOURNAL: A GLOBAL PERSPECTIVE
http://dx.doi.org/10.1080/19393555.2016.1172283

On the use of open-source firewalls in ICS/SCADA systems

J. Nivethan and M. Papa
Tandy School of Computer Science, University of Tulsa, Tulsa, Oklahoma, USA

ABSTRACT KEYWORDS
Firewalls are one of the most widely used security devices to protect a communications network. Firewalls; network security;
They help secure it by blocking unwanted traffic from entering or leaving the protected network. open source; SCADA secur-
Several commercial vendors have extended their firewall capabilities to support SCADA protocols ity; SCADA systems
or designed SCADA-specific firewalls. Although open-source firewalls are used successfully in IT
networks, their use in SCADA networks has not been properly investigated. In this research we
investigate the major open-source firewalls for their use in SCADA networks and identify Linux
iptables’ potential as an effective SCADA firewall. Iptables is a powerful open-source firewall
solution available as part of most Linux distributions in use today. In general, use of iptables as
a network-level firewall for SCADA systems has been limited to basic port and host filtering,
without further inspection of control messages. We propose and demonstrate a novel methodol-
ogy to use iptables as an effective firewall for SCADA systems. This is achieved by utilizing
advanced iptables features that allow for dynamic inspection of packet data. It is noteworthy to
Information Security Journal: A Global Perspective

mention that the proposed solution does not require any modification to the netfilter/iptables
framework, making it possible to turn a Linux system into an effective SCADA firewall. The
approach has been tested by defining filtering rules for the Modbus TCP protocol and validating
its ability to defend against various attacks on the protocol.

1. Introduction
output necessary to drive the process to the desired
Critical infrastructures, and modern industrial control state (Boyer, 2009; Pires & Oliveira, 2006). This out-
systems in general, rely on SCADA (Supervisory put is applied to the process through actuators. Many
Control and Data Acquisition) systems for most of SCADA protocols have been developed, but only a
their control needs. A SCADA system is a computer- few are widely used (Krutz, 2005). Different industries
based control system which monitors, controls, and use different protocols to suit their operational needs.
supervises industrial and infrastructure operations. For instance, the electrical grid has different opera-
Generally speaking, SCADA systems consist of the tional requirements from an oil and gas control net-
following major components: remote terminal units work. Most popular SCADA protocols have evolved
(RTUs) or programmable logic controllers (PLCs), a over time and have been extended to allow transport
human–machine interface (HMI), supervisory sys- of these protocols over an Ethernet-based TCP/IP
tems, and a communications infrastructure which network. As a result, serial buses have been replaced
interconnects the components. PLCs and RTUs are by Ethernet-based networks and the SCADA mes-
connected to the physical process they control sages use the TCP/IP layer just like any network
through sensors and actuator. PLCs use sensors to application would. This makes the SCADA protocols
read different process properties (such as tempera- not only vulnerable to the same attacks that can be
ture, pressure, flow, and others). They convert the carried out on TCP/IP networks but also to those
sensor signals into digital format, and send the digital targeting the specific industrial control protocol. In
data to a supervisory system. The HMI is the part of this article we focus our attention on SCADA net-
the SCADA system which is operated by humans to works that use Ethernet as their physical and data-link
control and monitor the entire system. Data collected layers and TCP/IP to provide network and transport
from the sensors is used by the PLCs to calculate the services.

CONTACT J. Nivethan nivethan@utulsa.edu Tandy School of Computer Science, University of Tulsa, 800 S Tucker Dr, Tulsa, OK 74104.
Color versions of one or more of the figures in the article can be found online at www.tandfonline.com/uiss.
© 2016 Taylor & Francis
 2 J. NIVETHAN AND M. PAPA

SCADA protocols were designed with opera- available on the Internet. Therefore, SCADA-spe-
tional requirements in mind, and many of them cific firewalls are crucial in protecting PLCs/RTUs
lack or do not have any security functionality from any external and internal attacks. Clearly,
(Igure, Laughter, & Williams, 2006). Protecting there is a market need for SCADA security solu-
SCADA systems against cyber-attacks is critically tions, and commercial firewall vendors are trying
important due to the impact that service disrup- to satisfy this need by designing SCADA firewalls
tion may have on society and our everyday lives. or extending existing ones with SCADA function-
For instance, a cyber attack that disrupts electric ality. Checkpoint 1200 R (Checkpoint, 2015),
power supply to a city or affects proper operation Bayshore IC6000-S (Evan, 2014), patriotSCADA
of an atomic plant could have serious conse- (Pollet, 2012), and Tofino (Tofino, 2014) are
quences. In 2014 the Industrial Control Systems some of the commercial SCADA firewalls available
Cyber Emergency Response Team (ICS-CERT) today.
received and responded to 245 security incidents
from various ICSs (MONITOR, 2015). Of those
2. Background and related work
245 incidents, more than half involved persistent
threats associated with sophisticated actors. It is The most common approach in the development
important to note that of all the sectors reporting of network monitoring and filtering solutions for
to ICS-CERT, the energy sector (electric power SCADA environments is the use of popular intru-
Information Security Journal: A Global Perspective

and oil & gas) account for 32% of reported sion detection systems (IDS) such as Snort
incidents. (Roesch, 1999) and Bro (Paxson, 1999). A
In 2001 a disgruntled contractor breached the SCADA firewall has to be able to inspect (at the
Maroochy Water Services in Queensland, very least) the header of an industrial control pro-
Australia’s control network and released approxi- tocol such as Modbus or DNP3. Snort and Bro
mately 1 million liters of sewage into the river. have been extended and fine-tuned to be used in
This individual was able to penetrate the control the SCADA domain with success (Zhu & Sastry,
network from the Internet using wireless devices 2010; Peterson, 2009; Lin et al., 2013). To our
(Slay & Miller, 2008). In 2010 the Stuxnet worm, knowledge, this is the first attempt to use an
designed to attack very specific SCADA/PCS, open-source firewall (without any kernel modifi-
caused serious damage to uranium-enriching facil- cations) to monitor and protect SCADA protocols.
ities in Iran (Falliere, Murchu, & Chien, 2011). In Firewalls, are network security devices that
2008, a software update installed in a computer inspect packets entering and leaving the network
operating in the business network also introduced to decide whether a packet should be dropped or
a piece of malware that manipulated data in the not. This is done by matching packets against
control system of a nuclear power plant in Baxley, filtering rules configured at the firewall. There
Georgia, USA, causing the plant to shut down are commercial firewalls and open-source fire-
(Krebs, 2008). It can also be noted that all three walls. Commercial firewalls such as Cisco ASA
of these attacks were backdoor attacks that (Hucaby, 2007) often run on dedicated hardware,
occurred because field devices (PLCs/RTUs) were and open-source firewalls often operate as part of
not appropriately protected from attacks within *nix systems. While open-source firewalls are fully
the network. SCADA systems often span over a featured (Potter, 2006), i.e., with capabilities simi-
large geographical area, using different network lar to those found in commercial solutions, only a
connections and software systems. An attacker single attempt (Igure et al., 2006), by Cisco, has
(or malware) that manages to get access to a com- been made to use them in SCADA networks
puter within the network can inflict serious (beyond using them for simple port or host-
damage by sending specific messages to the based filtering). In 2004 Cisco Systems developed
PLCs/RTUs which control the operations of criti- a netfilter module that facilitates the use of
cal infrastructure components. Unfortunately, Modbus protocol header fields using iptables
these tasks have become even easier due to the (Franz & Pothamsetty, 2004). However, their
fact that various SCADA client software are freely method required the use of a precompiled Linux
 INFORMATION SECURITY JOURNAL: A GLOBAL PERSPECTIVE 3

provided by Cisco, or users had to recompile the Table 1. Comparison of popular open-source firewalls.
Linux kernel with their module. The project did Stateful Port, host, String Byte
filtering protocol NAT match match
not continue further and did not provide support
Iptables Yes Yes Yes Yes Yes
for the later Linux kernels (SoureForge shows this PF Yes Yes Yes No No
project has been inactive since 2004 (Pothamsetty IPFW Yes Yes Yes No No
IPFILTER Yes Yes Yes No No
& Franz, 2004)).
Our proposed solution significantly advances
Cisco’s attempt to use iptables in SCADA domain.
Our solution allows security practitioners to filter (for example, filtering a message based on function
based on SCADA protocol fields without any mod- code) is impossible, because they do not provide
ifications to the netfilter/iptables library (no need to any features that can be used to match a string or
recompile the kernel). Another significant advantage byte in the TCP/UDP payload. Table 1 shows a
our solution provides is that it can be used for any comparison of iptables, PF, IPFW, and IPFILTER
SCADA protocols (as opposed to Cisco’s solution, firewall features. Besides the basic filtering fea-
which was designed only for the Modbus protocol). tures, all major open-source firewalls provide sta-
This is achieved by leveraging an advanced feature in teful filtering, host and port forwarding, and
iptables (introduced in 2010) that supports dynamic Network Address Translation (NAT). Iptables is
deep packet inspection, and this feature can be used to the only one that offers string and byte matching.
Information Security Journal: A Global Perspective

filter different SCADA protocols (a prototype imple- Our solution uses byte matching (through the u32
mentation has been demonstrated for the Modbus option) to enable dynamic deep packet inspection
protocol, but the approach can be easily used to of SCADA messages. All the popular open-source
protect other SCADA protocols). firewalls, with the exception of iptables, do not
We conducted a survey of available firewall support string or byte matching mechanisms to
utilities in BSD (PF, IPFW, and IP filter) and inspect packet data beyond a TCP or UDP header.
Linux (netfilter/iptables) to find the best candidate Iptables is the most popular and widely used
that we could use to implement a true SCADA open-source firewall. It has already been used to
firewall (i.e., one that can inspect SCADA protocol protect mission-critical systems with capabilities
fields). The PF firewall was originally designed for that are on par with commercial firewalls
the OpenBSD operating system and is ported to (Lawton, 2002). The Linux kernel incorporates
other operating systems, including FreeBSD, the Netfilter framework (Netfilter, 2014), which
Solaris, Apple Mac OS, and Apple iOS provides packet filtering capabilities. Iptables is
(Hansteen, 2014; Szongott Henne, & Smith, the user-space module of Netfilter which allows
2012). It is currently the built-in firewall of users to define firewall rules, essentially making it
Apple iOS and Mac OS. IPFW firewall was origin- a Linux firewall. It is important to note that several
ally designed for the FreeBSD operating system firewall products are available in the Linux
(Lidl et al., 2002), and it was the built-in firewall domain, such as Shorewall and Ubuntu ufw, but
for Mac OS until Apple replaced it with PF (Apple they are just front-end applications that simplify
2015). The other open-source firewall, IP Filter, iptables configuration tasks. This article presents a
works with Solaris and BSD systems in general technique to use iptables for SCADA protocols
(Van Rooij, 2001). The built-in IP Filter firewall and a novel approach that allows it to recognize
of the Oracle Solaris operating system is based on SCADA protocol packet fields. Our proposed solu-
the open-source software IP Filter (Oracle, 2010). tion goes beyond offering basic filtering capabil-
All these three firewalls can filter traffic based on ities at the TCP/IP level and allows security
IP address, port, network interface, and specific practitioners to inspect specific fields and data
transport and IP header fields (Artymiak, 2003; within the actual SCADA message. Iptables does
freeBSD Handbook, n.d.). They can protect a not recognize protocols or fields beyond the trans-
SCADA network by blocking traffic from/to port layer (i.e., TCP and UDP) and is therefore not
unwanted IP address and ports. However, using capable to process SCADA messages transported
them to filter based on the SCADA protocol fields over TCP. In our research we leverage some
 4 J. NIVETHAN AND M. PAPA

advanced features of iptables to extend its capabil- 3. Proposed method

ities to industrial control protocols. Our aim is to
Iptables can easily inspect the headers of network
strengthen SCADA security by writing customized
and transport layers on its own, but using it for
iptables rules that can actually inspect SCADA-
application-layer protocols has often been a chal-
specific data and fields. The proposed approach
lenging task. In 2010, iptables incorporated
is validated by experimental results on the popular
advanced features that were made part of popular
Modbus TCP SCADA protocol and can be
Linux distributions for the 2.6 kernel. These
extended to other SCADA protocols using the
advanced features included string matching sup-
same technique.
port and the u32 match (Rash, 2007). Both string
It is important to note that firewalls will introduce
matching and the u32 match have features to make
additional packet latency. The U.S. Department of
iptables potentially useful with SCADA protocols.
Energy’s (DOE) Secure Data Transfer Guidance for
In general, using string matching is a good
SCADA and ICS (Mahan et al., 2011) suggests not to
mechanism to identify data patterns within the
use firewalls inside a SCADA system that exchanges
payload portion of the packet. However, as defined
time-sensitive messages, for example, in an electric
in Iptables, the portion of the payload where string
substation. It further notes that regardless of the per-
matching is to occur is identified by a static offset
formance of the firewall, a denial-of-service attack
from the beginning of the IP header. The problem
could easily overload the firewall and delay message
Information Security Journal: A Global Perspective

with this is that both IP and TCP may have vari-

delivery. In domains with fast dynamics (e.g., the
able header lengths due to use of option fields.
electric power sector), message delays can be an
Since the offset is not static, it is not possible to
issue. Time-critical messages are typically not sent
predict exactly where (as an offset from the begin-
through the firewall. For instance, in an electric
ning of the IP header) the SCADA message begins.
power substation, trip signals must be transferred in
Therefore, string matching, as a general solution to
less than 4 ms for a system operating at 60 Hz, or 5 ms
the problem, is not a good candidate.
for a 50-Hz facility (Thorp, Phadke, Horowitz, &
The u32 test, as the name implies, allows it to
Beehler, 1979). Thus, in such cases it is suggested to
extract 32 bits (4 bytes) from the packet at any
strongly protect the perimeters of the SCADA systems
specified location and compare it against values of
(Mahan et al., 2011), instead of employing firewalls on
interest. For cases where the value or field of
the inside. In any case, if there is a specific need to
interest is less than 32 bits, the value can be easily
deploy a firewall for a time-sensitive communication,
masked and shifted. With this option, it is possible
its impact on packet latency must be carefully
to dynamically select a starting point in the packet
considered.
to match up to 32 bits worth of data. This feature
Typically, SCADA firewalls are used to protect
effectively helps overcome the variable-header-
field devices (PLCs/RTUs) from unauthorized
length problem by using the header-length field
requests that originate from outside the field
of the packet to calculate the header length and
(Figure 1). It is more crucial in deployments
then jump to the beginning of its payload. The
where the control center and PLC field devices
following steps would allow iptables to inspect
are separated by large distances (e.g., oil and gas
fields in a SCADA message using u32:
pipelines), and connected using various commu-
nication media. Furthermore, there is evidence
that the use of malware to attack PLCs from com- (1) Extract the header length field from the IP
puters that have access to them (Miller & Rowe, header and multiply it by 4 to get the header
2012) is becoming an increasing threat to SCADA length in bytes.
systems. In other words, it is best to deploy (2) Use this value to jump to the beginning of
SCADA firewalls around the perimeter, where the TCP header.
they will protect field devices from unauthorized (3) Extract the header length field from the
access but will not interface with time-critical TCP header and multiply it by 4 to get the
internal messages. header length in bytes.
 INFORMATION SECURITY JOURNAL: A GLOBAL PERSPECTIVE 5

Figure 1. A SCADA network structure.

(4) Use this value to jump to the beginning of really indicates the length of the TCP header)
Information Security Journal: A Global Perspective

the SCADA message. starts at byte 12 (Figure 4). We are now ready to
(5) Specify an offset with respect to the begin- jump to the end of the TCP header using
ning of the SCADA message and then 12≫26&0×3 C@. Now iptables is ready to look
match against the desired value. into the SCADA message. We use the Modbus
TCP protocol (Swales, 1999) to illustrate how u32
Consider the iptables rule shown in Figure 2 can be used to extract a specific field (the same
using the u32 module. procedure can be followed for any other SCADA
IP and TCP header length fields indicate length protocols). Modbus TCP includes a function code
of the corresponding header in number of 4-byte field that indicates the type of operation a control-
words. For instance, if the value in the header ler should execute. This field is located at byte 7 of
length field for IP is 5, then the length of the IP the Modbus message (Figure 5). We can simply
header is 5*4 = 20 bytes. The header length field match against it with 7≫24&0×ff = 0×2B when
for IP (Figure 3) is the second nibble of the first looking for function code 43 (Read device identi-
byte of the header, that is, bits 4–7 of the first byte. fication). If iptables finds a match, the packet will
Since u32 extracts 32 bits at a time, we can obtain be dropped. Modbus is an application-layer pro-
the actual value of the IP header by reading the tocol (Swales, 1999), and it is the predominant
first four bytes of the IP header, shifting 22 bits to protocol in the oil and gas industry (Huitsing,
the right (this isolates the field and multiplies by 4 Chandia, Papa, & Shenoi, 2008). Modbus servers
at the same time) and masking it with 0×3 C. This reply only on receiving a request. The Modbus
operation is represented as 0≫22&0×3 C using transaction identifier is used to identify each trans-
u32. As shown a little later, the @ sign is used to action (same transaction id for a request and its
jump ahead as many bytes as indicated by the reply). Protocol identifier field is always set to
preceding statement. After this operation, iptables zero. Length field contains the length of the
is looking at the beginning of the TCP header. remaining fields in bytes (including the header
Similarly, we obtain the TCP header length and portion, unit id). Unit identifier is used when
jump to the end of it. The TCP offset field (which multiple Modbus slaves happen to be put behind

Figure 2. An iptables rule with the u32 module.

 6 J. NIVETHAN AND M. PAPA

Figure 3. IP header (header length field highlighted).

Information Security Journal: A Global Perspective

Figure 4. TCP header (offset—header length highlighted).

Figure 5. Modbus/TCP message.

a single IP gateway. Function code is a special code starting register and the number of registers to
that instructs the Modbus slave to perform specific read when accessing multiple registers). Function
tasks in a request message. When used in a reply, code and the data field of the Modbus message are
the function code may also indicate whether a the most valuable SCADA-related fields to be
command was executed successfully. The data inspected. For example, Modbus uses function
field (Figure 5) is a placeholder for either data code 8 for diagnostic purposes. This function
(for simple operations) or parameters associated code is often accompanied by sub function codes
with a specific function code (e.g., providing a to perform specific diagnostic functions (such as
 INFORMATION SECURITY JOURNAL: A GLOBAL PERSPECTIVE 7

clearing diagnostic registers). Sub function codes code 17—Report Slave ID to enumerate
(for diagnostic functions) are always 2-byte fields PLCs on a network.
following the function code. Some Modbus diag- ● Read device identification: An attacker may
nostic commands can be used to attack the system send a message with function code 43—
by modifying its state and configuration and there- Read Device Identification, which would pro-
fore should be carefully monitored and controlled. vide additional PLC information such as ven-
The following list describes the most common dor name, product name, and version
attacks on PLCs running the Modbus protocol number for the target PLC. This information
(Huitsing et al., 2008; Zhu et al., 2011; Byres will help the attacker to plan for an attack.
Hoffman, & Kube, 2006; Byres, Franz, & Miller,
2004). These are the most significant attacks that Figures 6 and 7 illustrate how our solution could
could be prevented by using the proposed be used to protect against all of these attacks. Note
solution. that in addition to looking for SCADA-specific
data, our solution also uses IP and TCP host and
● Unauthorized write: Writing unauthorized port filtering capabilities as provided by iptables.
Modbus servers often lack features that would
values into PLC registers may have devastat-
allow it to block specific requests from specific
ing effects on the physical system controlled
IPs. This type of access control is often an impor-
Information Security Journal: A Global Perspective

by the PLC. For instance, the action of open-

tant need in ICS environments. Ideally, the ability
ing or closing an important valve could be
to execute critical commands should be strictly
easily done by changing the value of a single
limited to authorized hosts in the network. Our
register with a write register operation. Even
solution can provide this type of protection
in cases where a PLC has the capability to
mechanism to Modbus systems. Figure 7 illustrates
white-list hosts by IP address, this PLC would
how to incorporate rules allowing only two hosts
still be exploitable (Fovino et al., 2009).
● Unauthorized read: Reading register values (192.168.56.1 and 192.168.56.2) to send a “Read
Coils” (function code 0×01) message to our
from unauthorized IP addresses may offer
SCADA network. Following a similar procedure,
valuable information about the state of the
filtering rules for other types of Modbus messages
physical system to an attacker—information
can be defined. This firewall solution provides a
that could be used for a future attack.
● Clear counters and diagnostic registers: Most solution to one of the most fundamental security
issues (source verification for each command) of
Modbus PLCs use special registers to main-
the Modbus TCP protocol. Finally, a rule is added
tain configuration and status information. A
to block any traffic that has not been specifically
Modbus request with function code 08 and
allowed using the iptables -P INPUT DROP direc-
sub function code 10 will clear those registers.
tive. The methodology presented in this article is
This operation should clearly be closely mon-
currently being used to demonstrate its use for the
itored and filtered.
● Remote restart: A Modbus message with func- DNP3 protocol as well (Nivethan & Papa, 2016).
tion code 08 and sub function code 01 instructs
the receiving PLC to restart. Clearly, unpro- 4. Experimental results
tected use of this message could easily result
in a denial-of-service attack. To validate our proposed solution, we built a test
● Force PLC into listen-only mode: An attacker SCADA network (Figure 8) that runs the Modbus.
could instruct a PLC to go into a listen-only The SCADA network set up for this experiment con-
mode using function code 08 and sub func- sists of three DirectLOGIC05 PLCs (PLC1, PLC2, and
tion code 04. In this mode the device will stop PLC3). Each PLC has a Modbus TCP communication
responding to any further requests. module for communication with the master. The
● Report server information: An attacker scan- SCADA master is a Modbus client software that
ning a SCADA network may use function runs in a PC. Two Modbus clients (master X and
master Y) running two different IP addresses are
 8 J. NIVETHAN AND M. PAPA

Figure 6. Iptables rules for common Modbus protocol exploits.

Information Security Journal: A Global Perspective

Figure 7. Ruleset to block Write Single Coil requests from IPs other than the mentioned two.

Figure 8. Experimental SCADA network setup.

used. Each PLC has four discrete inputs connected to registers allocated to store the input signals they
four different switches and four outputs connected to receive (from switches), and to store the output sig-
four different lights. The PLCs have a certain range of nals that control the connected outputs. These
 INFORMATION SECURITY JOURNAL: A GLOBAL PERSPECTIVE 9

Figure 9. An iptables log entry after filtering a packet.

registers can be accessed or overwritten by the master an effective SCADA firewall. It was also verified
using write requests. For instance, the master can that the firewall filters the common exploits
monitor the state of the lights connected to the using signatures shown in Figure 6. Figure 9
PLCs and control them (on or off) remotely by send- shows an actual syslog entry (logging can be
ing relevant Modbus/TCP messages. enabled optionally) generated by iptables for
We added firewall rules that allow only master blocking a Modbus restart communications
X to write to PLC1, allow only master Y to write to request message during our experiment.
PLC2, and allow both to write to PLC3. Each of
the masters is configured to send requests to write 5. Conclusions
to the registers which are connected to the lights.
While commercial solutions to deploy firewalls
Information Security Journal: A Global Perspective

The outcome, and therefore whether a message

made it through the firewall, can be observed by specifically designed (or extended) for use in the
the behavior of the lights connected to the PLCs. SCADA domain exist, the use of open-source
Masters were also configured to send read for the firewalls in the same environment has not been
four registers associated with the lights. The fol- properly explored. This article investigates the
lowing tests were performed: use of open-source firewalls in SCADA systems
and presents a novel and effective method to use
(1) Master X sends write requests to PLC1 with the Linux iptables firewall to inspect and filter
value1—All lights turn on. SCADA protocol messages. To offer an effective
(2) Master Y sends write requests to PLC1 with firewall solution for SCADA systems, the filter-
value 0—No change. ing device must have the capability to inspect
(3) Master X sends write requests to PLC2 with SCADA protocol fields located beyond the IP
value 1—No change. and TCP (or UDP) headers. In other words,
(4) Master Y sends write requests to PLC2 with security practitioners must be able to specify
value 1—All lights turn on. filtering rules at the industrial control protocol
(5) Master X sends write requests to PLC3 with level. This was achieved using an iptables feature
value 1—All lights turn on. known as u32 that allows it to inspect up to any
(6) Master Y sends write requests to PLC3 with four sequential bytes anywhere in the packet.
value 0—All lights turn off. Our solution uses u32 to be able to deal with
the dynamic nature of the header lengths of IP
and TCP. Our approach was validated using the
“No change” indicates that the requests were Modbus TCP protocol which is widely used in
blocked by the firewall. Master X and Master Y the energy sector. Firewall rules were created to
both read the register contents from PLC1 and
protect against the most common types of
PLC2, and reported their correct values, that is,
values that matched the actual status of the lights attacks and then tested to verify that the offend-
(0000 when off and 1111 when on). ing traffic was being blocked. This proof of
concept can be easily extended and applied to
Our experiment validates that the proposed other SCADA protocols.
firewall solution can filter (1) specific Modbus
requests from specific IPs, (2) specific Modbus
requests to specific PLCs, and (3) both, by ORCID
inspecting the protocol header fields, and act as Jeyasingam Nivethan http://orcid.org/0000-0003-0706-0957
 10 J. NIVETHAN AND M. PAPA

References Proceedings of the BSD Conference 2002 on BSD

Conference, USENIX Association, San Francisco, CA.
Apple. (2015). OS X: About the application firewall. Retrieved Lin, H., Slagell, A., Di Martino, C., Kalbarczyk, Z., & Iyer, R.
from https://support.apple.com/en-us/HT201642 K. (2013, January). Adapting Bro into SCADA: Building a
Artymiak, J. (2003). Building firewalls with OpenBSD and PF. specification-based intrusion detection system for the DNP3
Poland: Jack Artymiak. protocol. Paper presented at Proceedings of the Eighth
Boyer, S. A. (2009). SCADA: Supervisory control and data Annual Cyber Security and Information Intelligence
acquisition. Research Triangle Park, NC: International Research Workshop, ACM, Oak Ridge, TN.
Society of Automation. Mahan, R. E., Burnette J. R., Fluckiger, J. D., Goranson, C. A.;
Byres, E. J., Franz, M., & and Miller, D. (2004). The use of Clements, S. L., Kirkham, H., & Tews, C. (2011). Secure
attack trees in assessing vulnerabilities in SCADA systems. data transfer guidance for industrial control and SCADA
Proceedings of the International Infrastructure systems. Richland, WA: Pacific Northwest National
Survivability Workshop, Citeseer, Lisbon, Portugal. Laboratory.
Byres, E. J., Hoffman, D., & Kube, N. (2006). On shaky Miller, B., & Rowe, D. (2012, October). A survey SCADA of
ground—A study of security vulnerabilities in control pro- and critical infrastructure incidents. Paper presented at
tocols. Paper presented at Proc. 5th American Nuclear Proceedings of the 1st Annual Conference on Research in
Society Int. Mtg. on Nuclear Plant Instrumentation, Information Technology, ACM, Calgary, Alberta, Canada.
Controls, and HMI Technology, Albuquerque, NM. MONITOR, I.-C. (2015, Octorber/November). USA: ICS-
Checkpoint. (2015). 1200R Rugged Appliance. Retrieved from CERT.
https://www.checkpoint.com/products/industrial-control- Netfilter. (2014). The netfilter.org project. Retrieved from
systems-appliances/ http://www.netfilter.org/
Information Security Journal: A Global Perspective

Evan. (2014). Bayshore networks® announces four new SCADA Nivethan, J., & Papa, M. (2016, May). A Linux-based firewall
Firewalls. New York, NY: Bayshore Networks. for the DNP3 protocol. Paper presented at 15th Annual
Falliere, N., Murchu, L. O., & Chien, E. (2011). W32. Stuxnet IEEE Symposium on Technologies for Homeland
dossier (White paper, Symantec Corp., Security Response Security, IEEE, Waltham, MA, USA.
5). Cupertino, CA: Symantec Corporation. Oracle. (2010). Introduction to oracle solaris IP filter.
Fovino, I. N. Carcano, A., Masera, M., & Trombetta, A. Retrieved from http://docs.oracle.com/cd/E19253-01/816-
(2009). Design and implementation of a secure modbus 4554/eupss/index.html
protocol. In C. Palmer, & S. Shenoi (Eds.), Critical infra- Paxson, V. (1999). Bro: A system for detecting network
structure protection III (pp. 83–96). Berlin Heidelberg: intruders in real-time. Computer Networks, 31(23–24),
Springer. 2435–2463. doi:10.1016/S1389-1286(99)00112-7
Franz, M., & Pothamsetty, V. (2004). ModbusFW deep packet Peterson, D. (2009, March). Quickdraw: Generating security
inspection for industrial ethernet. Critical Infrastructure log events for legacy SCADA and control system devices.
Assurance Group, Cisco Systems. Paper presented at Conference for Homeland Security,
freeBSD Handbook. (n.d.). IPFW. Retrieved from https:// 2009. CATCH’09, Cybersecurity Applications &
www.freebsd.org/doc/handbook/firewalls-ipfw.html Technology, IEEE, Washington, DC.
Hansteen, P. N. (2014). Book of PF: A no-nonsense guide to the Pires, P. S. M., & Oliveira, L. A. H. (2006, May). Security
OpenBSD firewall. San Francisco, CA: No Starch Press. aspects of SCADA and corporate network interconnection:
Hucaby, D. (2007). Cisco asa, pix, and fwsm firewall hand- An overview. Paper presented at International Conference
book. Indianapolis, IN: Pearson Education. on Dependability of Computer Systems, 2006. DepCos-
Huitsing, P., Chandia, R., Papa, M., & Shenoi, S. (2008). RELCOMEX’06. IEEE, Philadelphia, PA.
Attack taxonomies for the modbus protocols. Pollet, J. (2012). patriotSCADA distributed firewall for
International Journal of Critical Infrastructure Protection, SCADA and industrial networks. Houston, TX: Plant
1, 37–44. doi:10.1016/j.ijcip.2008.08.003 Data technologies.
Igure, V. M., Laughter, S. A., & Williams, R. D. (2006). Pothamsetty, V., & Franz, M. (2004). Transparent modbus/
Security issues in SCADA networks. Computers & TCP filtering with linux. Retrieved from http://modbusfw.
Security, 25(7), 498–506. doi:10.1016/j.cose.2006.03.001 sourceforge.net/
Krebs, B. (2008, June 5). Cyber incident blamed for nuclear Potter, B. (2006). Open source firewall alternatives. Network
power plant shutdown. Washington DC: Washington Security, 2006(1), 16–17.
Post. Rash, M. (2007). Linux firewalls: Attack detection and
Krutz, R. L. (2005). Securing SCADA systems. Indianapolis, response with iptables, psad, and fwsnort. San Francisco,
IN: John Wiley & Sons. CA: No Starch Press.
Lawton, G. (2002). Open source security: Opportunity or Roesch, M. (1999). Snort: Lightweight intrusion detection for
oxymoron? Computer, 35(3), 18–21. doi:10.1109/2.989921 networks. In LISA ‘99 Proceedings of the 13th Usenix
Lidl, K. J., Lidl, D. G., & Borman, P. R. (2002). Flexible packet Conference on System Administration (pp. 229–238).
filtering: Providing a rich toolbox. Paper presented at Seattle, WA: Usenix.
 INFORMATION SECURITY JOURNAL: A GLOBAL PERSPECTIVE 11

Slay, J., & Miller, M. (2008). Lessons learned from the Biographies
Maroochy water breach. Springer.
Swales, A. (1999). Open modbus/TCP specification (Vol. 29). Mr. J. Nivethan is a PhD candidate in Computer Science,
Schneider Electric. specializing in Cyber Security, at the Tandy School of
Szongott, C., Henne, B., & Smith, M (2012). Mobile evil twin Computer Science, University of Tulsa. He obtained his MS
malnets—The worst of both worlds. In Cryptology and in Computer Science from the same institution in 2013. Mr.
Network Security (pp. 126–141). Berlin Heidelberg: Springer. Nivethan has obtained all six information assurance certifica-
Thorp, J., Phadke, A. G., Horowitz, S. H., & Beehler, J. E. (1979). tions (CNSS 4011–16) in accordance with the requirements
Limits to impedance relaying. IEEE Transactions on Power of the U.S. Committee of National Security Systems (CNSS).
Apparatus and Systems, PAS–98(1), 246–260. doi:10.1109/ Mr. Nivethan is part of the critical infrastructure protection
TPAS.1979.319525 research group at the University of Tulsa and is being super-
Tofino. (2014). Tofino firewall LSM. Retrieved from https://www. vised by Dr. Mauricio Papa.
tofinosecurity.com/products/Tofino-Firewall-LSM
Dr. M. Papa is an associate professor in the Tandy School of
Van Rooij, G. (2001). Real stateful TCP packet filtering in IP filter
Computer Science at the University of Tulsa. He also serves as
(White paper). Netherlands.
faculty director of the Institute for Information Security, which
Zhu, B., Joseph, A., & Sastry, S. (2011, October). A taxonomy of
supports a multidisciplinary program of study and research
cyber attacks on SCADA systems. Paper presented at Internet
tackling cyber security issues on a global scale. His primary
of things (iThings/CPSCom), 2011 International Conference
research area is critical infrastructure protection. His team has
on and 4th International Conference on Cyber, Physical and
designed and constructed process control testbeds to support
Social Computing, IEEE, Dalian, China.
cyber security efforts in critical infrastructure protection. He
Zhu, B., & Sastry, S. (2010). SCADA-specific intrusion detection/
Information Security Journal: A Global Perspective

also conducts research in distributed systems, network secur-

prevention systems: A survey and taxonomy. Proc. of the 1st
ity, cryptographic protocol verification, and intelligent control
Workshop on Secure Control Systems (SCS), Stockholm,
systems.
Sweden.