SNORT IDS for SCADA Systems

RedHat 5 Enterprise
Installation Guide
Featuring
SCADA ICCP Signatures

Patrick Weaver, CISSP

1
Table of Contents
Introduction...................................................................................................................................3

System Configuration...................................................................................................................6
Initial Recommendations.....................................................................................................................6
Creating Snort related user Group and Account .................................................................................6
Installing necessary packages (use root).............................................................................................6
Installation Directory............................................................................................................................7
Additional packages:............................................................................................................................7
Snort Installation...........................................................................................................................9

Adding Rules to /etc/snort..........................................................................................................10

Adding SCADA Rules........................................................................................................................11
Editing snort.conf........................................................................................................................12
Adding HOME_NET...........................................................................................................................12
MYSQL Configuration.................................................................................................................16

Adding Snort to init.d..................................................................................................................18

“BASE” Installation......................................................................................................................20

ADODB Installation.....................................................................................................................22

Final Steps..................................................................................................................................25
Testing...............................................................................................................................................26
Conclusion..................................................................................................................................27

2
Introduction
This document has been created in response to the Critical Infrastructure Protection (CIP) standards
set forth by the North American Electric Reliability Corporation (NERC); these standards directly impact
the security posture of Bulk Electric Systems of North America by providing guidance for improving the
security of systems that are directly responsible for providing “monitoring and control, automatic
generation control, real-time power system modeling, and real-time inter-utility data exchange” (CIP-
002-R3 http://www.nerc.com/files/CIP-002-1.pdf, page 2).

With the ever increasing threat of cyber attacks targeting the Bulk Electric System, it is important for
security professionals to incorporate robust security mechanisms that assist in either conforming to the
CIP standards and/or industry best practice.

As a reference point, the architecture used in this document is only an example and does not
necessarily present the best-case-scenario or best practice; it is only an example that provides a view
into segmentation of the Electronic Security Perimeter from other resources that may/may not be
present in this industry. It should be noted that all SCADA related communications should be protected
according to the CIP standards and should by default disallow any unnecessary ports and services
from traversing the protected zone. The example architecture is shown in Figure 1:

Figure 1

3
ICCP traffic can span multiple network segments and include resources that exist outside of the ESP as
well as outside of the corporate network. These external networks that may be managed and
maintained by governing authorities or partner companies can pose the greatest threat. Although the
Corporate network can be considered an additional attack vector as well, it is the unknown security
posture of outside entities that is just as dangerous.

Although it is important to monitor ingress and egress packet flows from and to the ESP, it is also
important to monitor traffic taking place between hosts within the ESP. In most cases, intrusion
detection solutions (either inline or promiscuous) will be staged at the perimeter. In this document,
Snort will be installed on a Red Hat Enterprise server monitoring traffic within the ESP by way of a
spanned switch port, as shown in Figure 2:

Figure 2

With this architecture the Snort server is capturing all traffic flows within the ESP, it is not limited to only
ingress/egress traffic.

During the testing phase, it was required to configure two ports on the Snort server – one interface
used exclusively for capturing traffic and the other used for administrative purposes.

4
This guide is not an all-in-one solution for securing SCADA networks; it only reflects recommended
methods for deploying a more robust intrusion detection solution. It is assumed that the reader is
working with the following criteria:

• Fully patched, updated version of RedHat Enterprise Linux v5.

• Root level access.
• IDS Signature Release 3.3 from Digital Bond (requires subscription).
• Snort 2.8.4.1
• Current release of Snort Rule set (requires registration).
• Server with two available network interfaces.

It must be noted that this project could not have been completed without the Snort Users Manual and
SCADA Signatures provided by Digital Bond. The Snort development team and the crew from Digital
Bond have provided extremely helpful resources.

Reviewing the most current Snort Users Manual and any one of the SCADA IDS documents published
by Digital Bond is highly recommended. These documents can be found at the following links:

http://www.snort.org/assets/82/snort_manual.pdf

http://www.digitalbond.com/index.php/category/scada-ids/

5
System Configuration
As noted in the Introduction, this document is assuming that the reader is working with the following
criteria:

• Fully patched, updated version of RedHat Enterprise Linux v5.

• Root level access
• IDS Signature Release 3.3 from Digital Bond (requires subscription).
• Snort 2.8.4.1
• Current release of Snort Rule set.
• Server with two available network interfaces.

For ease of testing, RedHat was installed on a Virtual Machine.

Initial Recommendations

Although Snort can be used with a single network interface, the test platform used in this document is
using two network interfaces; one is used for capturing traffic and the other for system management.

Ensure that host name has been configured and that both NICs are assigned IP addresses.

If iptables is enabled, it wouldn’t hurt to disallow all traffic and add rules as needed. The services used
in this guide are SSH, HTTP, HTTPs and syslog.

If using SELinux either disable or fine tune to allow your management traffic.

Creating Snort related user Group and Account

Create a group (IDS) and user account (snort). The useradd –G IDS snort command will create the
user snort and add it to the IDS group, as shown in Figure 3:

Figure 3

This account will primarily be used to interact with the SQL Database.

Installing necessary packages (use root)

Most of the required packages will be installed during the system update; however, it will be necessary
to install additional packages.

As a side note, a list of rpm’s can be printed to the terminal by issuing rpm –qa | more, as shown in
Figure 4:

Figure 4

6
The first step is to ensure that the following packages are installed:

mysql mysql-bench mysql-server mysql-devel php

php-mysql php-pear httpd gcc pcre-devel
php-gd gd mod_ssl glib2-devel gcc-c++
bison libpcap pcre tcpdump flex
libpcap-devel libtool

These packages can be installed by issuing the yum -y command followed by the package names, as
shown in Figure 5:

Figure 5

Installation Directory

Once the additional packages are downloaded to the Snort server, create a repository (directory). This
will be the directory where all packages will be placed and decompiled. This directory should be placed
in /root and named as you wish. For purposes of this guide, I’ve created the /root/ids_packages
directory as shown in Figure 6:

Figure 6

Additional packages:

snort-2.8.4.1 snortrules-snapshot-2.8 adodb4991 base-1.4.3.1 SCADA_IDS_3_3

The snort-2.8.4.1, snortrules-snapshot-2.8 and SCADA_IDS_3_3 packages were downloaded to my

host Windows workstation, added to a thumb drive and manually installed on the Snort VM. The
SCADA_IDS_3_3 rules will need to be downloaded from the Digital Bond website with a paid
subscription and acquiring the snort rules will require registration.

These packages can be found at the following links:

http://www.snort.org/downloads

http://www.digitalbond.com/index.php/category/scada-ids/

7
BASE and adodb4991 can be downloaded from the command line using wget.

#wget http://easynews.dl.sourceforge.net/sourceforge/secureideas/base-1.4.3.1.tar.gz

#wget http://hivelocity.dl.sourceforge.net/sourceforge/adodb/adodb4991.tgz

Change to the newly created directory using # cd /root/ids_packages and download BASE and
adodb4991 as shown in Figures 7 and 8:

Figure 7

Figure 8

8
Snort Installation
Depending on where the snort tar file was placed, you’ll need to copy it into the /root/ids_packages
directory by using the copy command cp as shown in Figure 9:

Figure 9

Confirm the package was copied and issue the tar command, as shown in Figure 10:

Figure 10

Confirm that snort-2.8.4.1.tar.gz has been unpackaged using ls, enter the newly created directory
snort-2.8.4.1 and type the command ./configure --with-mysql --enable-dynamicplugin (enables SQL and
dynamic API), as shown in Figure 11:

Figure 11

When ./configure completes (hopefully with no additional errors), type make, as shown in Figure 12:

Figure 12

If make completes with no errors type make install, as shown in Figure 13:

Figure 13

If make install completes with no errors continue with the next step. If errors exist, try removing the
directory snort-2.8.4.1 (rm –r snort-2.8.4.1) and start again with tar as shown in Figure 9.

Confirm that the copy worked by changing to /etc/snort and typing ls, as shown in Figure 14:

Figure 14

9
Adding Rules to /etc/snort
You’ll now need to copy the snort rules that were unpackaged in the /root/ids_packages directory.
Change back to /root/ids_packages/rules, copy all rules to /etc/snort/rules and confirm successful copy,
as shown in Figures 15 and 16:

Figure 15

Figure 16

10
Adding SCADA Rules

Adding the SCADA rules follows the same methodology as above, with a few additional changes.
Change back to /root/ids_packages, change to the SCADA_IDS_3_3 directory and print to screen a list
of the contents, as shown in Figure 17:

Figure 17

Digital Bond has created a very intuitive package for assisting in this process. Although there is some
useful information here and I recommend taking advantage of this, we will focus on copying only the
.rules files to /etc/snort/rules, as shown in Figure 18:

Figure 18

You can now change back to /etc/snort/rules and view a list of the contents, as shown in Figure 19:

Figure 19

11
Editing snort.conf
In order for Snort to monitor your network, the snort.conf file needs to be altered to reflect your network
architecture. To accomplish this, you’ll need to change some variables.

Change directory to /etc/snort and type vi snort.conf, as shown in Figure 20:

Figure 20

Although vi is my editor of choice, feel free to use your preference. If you are unfamiliar with vi you can
find common commands at the following address:

http://www.cs.colostate.edu/helpdocs/vi.html

Adding HOME_NET

Once in edit mode, arrow down until you see # You can specify it explicitly as:, as shown in Figure 21
and make the changes shown in Figure 22:

Figure 21

Figure 22

These changes include un-commenting #var HOME_NET 10.1.1.0/24 and changing the network range
to the range in which you wish to monitor. The test network used for this guide is 192.168.47.0/24.

Next, configure the External Network by editing the EXTERNAL_NET address. I’ve chosen any as
recommended by the developers and as shown in Figure 23:

Figure 23

Choosing any implies that every IP is to be considered external.

Modifying the server list will allow you to define the protocols and hosts on your network that Snort will
be monitoring. In this example, I’m not concerned with all of the listed services, mainly DNS, SCADA,
HTTP and SQL related services.

12
Although the modbus and ICCP client and server lists have been added, only the ICCP rules will be
used for this example, the modbus variables have been commented out.

It is here where you will define the client and/or server IP addresses. In the architecture example on
Page 4 of this document, the ICCP servers have been defined. These servers will be forwarding and
receiving ICCP traffic from the ESP to the Power Plant, Corporate Network and Partner Company. The
snort.conf file will need to be changed to reflect the ICCP_CLIENT and ICCP_SERVER addresses. As
a limitation, only the ICCP_SERVER variables can be listed as any, there must be IP addresses
assigned to ICCP_CLIENT variables.

In this example, I have added the two server IP addresses to the ICCP_CLIENT list and designated
ICCP_SERVER as any. This implies that any other IP address is considered an ICCP_SERVER and
the rules should still alert on anomalous traffic from the clients to the ICCP_SERVER list or any other IP
addresses. The configuration example is shown in Figure 24:

Figure 24

If using any of the other services, be sure to uncomment as needed – don’t forget to write the changes.

13
The next step is to add the ports/services that will need to be monitored. This is accomplished using the
same methodology as adding the servers and clients. Arrow down (below server list) and ensure that all
necessary portvar variables are uncommented. You’ll also need to add any additional ports that aren’t
already defined, such as ICCP/MODBUS, as shown in Figure 25:

Figure 25

Notice the last entry SCADA_Ports. The snort rule set used in this example incorporates a predefined
SCADA rule set. Although these ports may be a duplicate of the ICCP and MODBUS entries, they need
to remain in the snort.conf file if using the Snort SCADA rules.

Continue by adding the path to /etc/snort/rules. Under # Path to your rules files, ensure that the
RULE_PATH is set to /etc/snort/rules and also uncomment or add the path to the preproc_rules, as
shown in Figure 26:

Figure 26

The pre processor rules may still be located in /root/ids_packages/snort-2.8.4.1. Check the /etc/snort
directory and see if it’s there, if not change back to /root/ids_packages/snort-2.8.4.1 and do a recursive
copy to the /etc/snort directory and confirm that the copy was successful.

[root@localhost ids_packages]# cp –r preproc_rules /etc/snort

Once the preproc_rules have been moved, check the /etc/snort directory, it should resemble the list
shown in Figure 27:

Figure 27

14
It is also necessary to alter the preprocessor choices as well – the preprocessors will assist in packet
reassembly for examination.

In the Snort version used for this document, Frag3 and Stream5 are being used and the snort.conf file
will need to be configured appropriately; Frag3 is an IP defrag module and Stream5 is a TCP
reassembly module.

There are several options to choose from here, it is recommended that these examples be reviewed for
applicability in your environment.

In this example, I’ve left the frag3 examples, as shown in Figure 28:

Figure 28

Stream5 is configured as shown in Figure 29:

Figure 29

It is recommended that the “README.stream5” and “README.frag3” files be reviewed to better

understand the preprocessor.

15
MYSQL Configuration
In this step, edit the database section of snort.conf.

Edit snort.conf with your editor of choice. If using vi and not in edit mode begin by typing /database, the
forward slash is a keyword search value that will search for the term database; it should put you right
where you want to be in the conf file. You’ll need to uncomment the line containing:

output database: log, mysql, user= password= dbname= host=localhost

In edit mode, change user, password, dbname and host, as shown in Figure 30:

Figure 30

The password for user snort will be needed during the configuration of the SQL Database and the host
name can be changed to reflect your production system. This must be changed if your server is named
something other than localhost.

When complete, write the changes, exit snort.conf and enter mysql by typing mysql at the command
line. If you get an error, try restarting the mysql daemon by typing service mysqld restart. If you don’t
receive an error continue with the commands as shown in Figure 31:

Figure 31

16
Next, create the database/tables by typing the following command, as shown in Figure 32:

# mysql –D snort –u root –p < /root/ids_packages/snort-2.8.4.1/schemas/create mysql

Figure 32

Confirm that the database was successfully created by typing the following command # mysql –p, as
shown in Figure 33:

Figure 33

Verify that the tables exist by typing > use snort, as shown in Figure 34:

Figure 34

17
Adding Snort to init.d
During this stage, you’ll need to add snort to init.d and ensure that it is properly configured. Following is
a copy/pasted example that will work with this particular build. Copy the text, paste it to a shell script
file, save it to /etc/init.d and escalate permissions using chmod 755 /etc/init.d/snort:

#!/bin/sh
#
# This script starts and stops snort
#
# config: /etc/snort/snort.conf
# processname: snort

# Source function library

. /etc/rc.d/init.d/functions

BASE=snort
DAEMON=”-D”
INTERFACE=”-I eth0”
CONF=”/etc/snort/snort.conf”

# Looking for BASE install

[ -f /usr/local/bin/$BASE ] || exit 0

# Location of netconfig
. /etc/sysconfig/network

# Verify that network is available

[ ${NETWORKING} = “no” ] && exit 0

RETVAL=0
# Snort/BASE Call-out
case “$1” in
start)
if [ -n “`/sbin/pidof $BASE`” ]; then
echo –n $”$BASE: already running”
echo “”
exit $RETVAL
fi
echo –n “Starting snort service: “
/usr/local/bin/$BASE $INTERFACE –c $CONF $DAEMON
sleep 1
action “” /sbin/pidof $BASE
RETVAL=$?
[ $RETVAL –eq 0 ] && touch /var/lock/subsys/snort
;;
stop)
echo –n “Shutting down snort service: “
killproc $BASE
RETVAL=$?
Echo
[ $RETVAL –eq 0 ] && rm –f /var/lock/subsys/snort
;;
restart|reload)
$0 stop
$0 start
RETVAL=$?
;;
status)
status $BASE
RETVAL=$?
;;
*)
echo “Usage: snort {start|stop|restart|reload|status}”
exit 1
esac

exit $RETVAL

18
Following the previous step, be sure that you are root and run /etc/init.d/snort restart. Hopefully the
service starts, as shown in Figure 35:

Figure 35

You can also check the status of the install by typing # snort –c /etc/snort/snort.conf. I generally find this
useful to run after making changes to be sure there are no issues. The output is as shown in Figure 36
(representative sample):

Figure 36

19
“BASE” Installation
Basic Analysis and Security Engine (BASE) is the front end used for viewing the Snort output. This
section will cover the installation and testing.

The first step is to ensure that the pear extensions are installed for proper image/graph rendering. This
can be accomplished by typing the following command:

# pear install Image_Graph-alpha Image_Canvas-alpha Image_Color Numbers_Roman

This routine is shown in Figure 37:

Figure 37

Next, change back to /root/ids_packages, view a listing of the contents, ensure that the base-
1.4.3.1.tar.gz file is still there. If it is, type # tar –xzvf base-1.4.3.1.tar.gz, as shown in Figure 38:

Figure 38

Once this is complete, view the contents of ids_packages, copy base-1.4.3.1 to base and copy base to
/var/www/html. You can also confirm that the copy was successful. These steps are shown in Figure
39:

Figure 39

20
The next step is to change to the base directory and copy base_conf.php.dist to base_conf.php, as
shown in Figure 40:

Figure 40

The next step requires editing base_conf.php by inserting the BASE urlpath, DBlip_path and defining
the database type and database connection parameters, as shown in Figures 41, 42, 43 and 44:

Figure 41

Figure 42

Page 43

Figure 44

21
ADODB Installation
Change back to /root/ids_packages and review the contents, as shown in Figure 45:

Figure 45

Confirm that adodb4991.tgz exists and copy the package to /var/www as shown in Figure 46:

Figure 46

Un-package the file and confirm success, as shown in Figures 47 and 48:

Figure 47

Figure 48

As a final installation step, restart the httpd server, as shown in Figure 49:

Figure 49

Now, we’ll see if the front end works. Go to a browser and test http://<localhost>/base, if you’ve
forgotten the IP address, run ifconfig eth0, as shown in Figure 50:

Figure 50

22
If everything works right, you will be presented with the setup page, as shown in Figure 51:

Figure 51

If you get this far, click Setup page and you will be redirected to the page shown in Figure 52:

Figure 52

23
Choose Create BASE AG, and if everything works you will be redirected to the page shown in Figure
53:

Figure 53

24
Final Steps
In order to complete the overall installation and test functionality type the following commands:

chkconfig snort on
service snort start

Restart your browser of choice and re-enter http://<localhost>/base. You should now see the BASE
front page and verify that alerts are being reported, as shown in Figure 54:

Figure 54

Notice that the Sensors/Total number reflects one active sensor as well as another idle sensor. This
system used for this document has been virtualized; therefore, the sensor information is showing the
capture interface as well as the Virtual interface. You will also see this on production systems if you are
using two network interface cards, one for capturing and one for management.

You can see the active sensors by logging into the mysql database and typing SELECT * FROM
sensor; as shown in Figure 55:

Figure 55

25
Testing

If everything works and you are able to capture your SCADA traffic, you may see an alert similar to
Figure 56:

Figure 56

In this example, the ICCP rules have been successfully tested, syslog is being generated and your
logging and alerting solution of choice should be forwarding alerts to your inbox.

To further break this traffic down, you can select the alert ID number and review the trigger and packet
information in more detail.

To confirm that the Digital Bond rules are configured properly, you can compare the Triggered
Signature data shown in Figure 57 with the table provided by Digital Bond at
http://www.digitalbond.com/index.php/research/ids-signatures/iccp-ids-signatures/.
You are looking for the SID associated with the specific alert – the SID associated with Unauthorized
MMS Write Request Attempt is 1111404, as also shown in Figure 57:

Figure 57

26
Conclusion
I cannot express enough thanks to Digital Bond and the Snort development crew – their expertise and
research and development is invaluable as well as critical to the successful deployment of Snort and
SCADA based intrusion detection solutions.

As mentioned previously, only ICCP traffic has been tested within this guide. It is my desire to continue
moving forward with the testing and development of additional SCADA related rules and openly provide
the results to the Snort and Bulk Electric System communities.

27