Read Snort IDS for SCADA Systems text version

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" (CIP002-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 php-mysql php-gd bison libpcap-devel mysql-bench php-pear gd libpcap libtool mysql-server httpd mod_ssl pcre mysql-devel gcc glib2-devel tcpdump php pcre-devel gcc-c++ flex

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

Information

Snort IDS for SCADA Systems

27 pages

Report File (DMCA)

Our content is added by our users. We aim to remove reported files within 1 working day. Please use this link to notify us:

Report this file as copyright or inappropriate

685778