NETWORK INTRUSION DETECTION AND PREVENTIONUSING SNORT AND IPTABLES

A practice school report submitted

To

MANIPAL UNIVERSITY

For Partial Fulfillment of the Requirement for theAward of the Degree

Of

BACHELOR OF ENGINEERING

In

COMPUTER SCIENCE AND ENGINEERING

By

DISHA BEDIReg No: 080905220

Under the Guidance of

Prof. ASHWATH RAO Assistant Professor, Department of Computer Science and Engineering

And

Mr. KISHORE DOMMETIConsultant, CTDC-EFIE Department, Siemens Information Systems Ltd.

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

MANIPAL INSTITUTE OF TECHNOLOGY(A constituent Institute of MANIPAL UNIVERSITY)

MANIPAL - 576 104, KARNATAKA, INDIA

2012

NETWORK INTRUSION DETECTION AND PREVENTIONUSING SNORT AND IPTABLES

A practice school report submitted

To

MANIPAL UNIVERSITY

For Partial Fulfillment of the Requirement for theAward of the Degree

Of

BACHELOR OF ENGINEERING

In

COMPUTER SCIENCE AND ENGINEERING

By

DISHA BEDIReg No: 080905220

Under the Guidance of

Prof. ASHWATH RAO Assistant Professor, Department of Computer Science and Engineering

And

Mr. KISHORE DOMMETIConsultant, CTDC-EFIE Department, Siemens Information Systems Ltd.

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

MANIPAL INSTITUTE OF TECHNOLOGY(A constituent Institute of MANIPAL UNIVERSITY)

MANIPAL - 576 104, KARNATAKA, INDIA

2012

MANIPAL INSTITUTE OF TECHNOLOGY, MANIPAL - 576 104

A Constituent Institution of Manipal University, Manipal-576 104

___________________________________________________________________________

CERTIFICATE

This is to certify that the project work of

DISHA BEDI Reg No. 080905220

on the project Network Intrusion Detection and Prevention Using Snort and Iptables is a record of the bonafide work carried out in partial fulfilment of the requirements for awarding the degree of Bachelor of Engineering in Computer Science and Engineering discipline in Manipal Institute of Technology under Manipal University, Manipal during the academic year 2011-2012.

------------------------------- ---------------------------------- Prof. ASHWATH RAO Mr. KISHORE DOMMETI Project Guide (Internal) Project Guide (External)

-------------------------------Dr. RENUKA A

Head of the DepartmentDept. of Computer Science & Engg.

ACKNOWLEDGEMENT

I am immensely elated to conclude my final semester project at Manipal Institute of

Technology. I take this opportunity to express my gratitude to the people who have been

instrumental in the successful completion of this project.

I am extremely grateful to Mr. Kishore Dommeti for guiding me throughout my training

in spite of his extremely busy schedule and for taking out time for helping me out with

the required study material and solving my queries. I would also like to thank my internal

guide Prof. Ashwath Rao to guide me during the project duration and provide me with the

proper guidelines for carryimg out the project work.

I’m also grateful to the people at Siemens, who were of tremendous help to me when

working on this project. Working at this company has been an incredible learning

experience and I am thankful for that.

i

ABSTRACT

KEYWORDS: Intrusion Detection; Intrusion Prevention; Snort; Sensors; Firewall;

Iptables.

Intrusion detection is a set of techniques and methods that are used to detect suspicious

activity both at the network and host level. Intruders have signatures that can be detected.

Based upon a set of signatures and rules, the Intrusion Detection System (IDS) is able to

find and log suspicious activity and generate alerts An Intrusion Prevention System

(IPS) is a further development of intrusion detection systems. These systems not only

detect attacks but also prevent them by blocking the unusual data transmission.

Snort is primarily a rule-based IDS. Snort reads these rules at the start-up time and builds

internal data structures or chains to apply these rules to captured data. Iptables is a

powerful administration tool for IPv4 packet filtering. It is used to set up, maintain, and

inspect the tables of IP packet filter rules in the Linux kernel.

In this project I implement intrusion detection using Snort as well as other products like

BASE and Wireshark that work with Snort. Snort has the capability to log data collected

(such as alerts and other log messages) to a database. MySQL is used as the database

engine where all of this data is stored. Using BASE you can analyze this data. I also

wrote a program in BASH scripting to control the variable file.

ii

First I build the Network Intrusion Detection System (NIDS) with one sensor to monitor

traffic on one network line. Next, I extend our system to a 2 sensor scenario so that a

single NIDS is able to monitor traffic on 2 different network lines. Then I add an

Intrusion Prevention System (IPS) machine to our setup. Intrusion prevention is done

using Iptables. Next we configure snort in inline mode, to make it at act as an IPS.

I also create a template using BASH Scripting which outputs an entire iptables chain rule

set to a file, only with a few parameters given as input to the template from another file. I

also created three different web pages for creating iptable rule set and snort rule set for

single sensor as well as multi sensor scenario, using HTML, javascript, XML and XSLT

(eXtensible Stylesheet Language Transformations), in which the user selects rule data

from the given options and gets the rule set printed in a file. Documentation and manuals

are also prepared for using these tools.

The goal of this project is to implement network security to a product of Siemens, SPPA-

T3000, which is the instrumentation and control system that provides remote access to

power plant management systems.

iii

TABLE OF CONTENTS

ACKNOWLEDGEMENT iABSTRACT iiLIST OF FIGURES viiABBREVIATIONS viii

Chapter 1 INTRODUCTION 11.1 General Overview 21.2 Motivation 21.3 Objectives 31.4 Organization of Report 3

Chapter 2 SOFTWARE REQUIREMENTS AND SPECIFICATIONS 52.1 System requirements 62.2 Tools used to build security systems 62.2.1 Snort 62.2.2 BASE 82.2.3 Wireshark 92.2.4 Iptables 92.2.5 Bash scripting 102.3 Web page development tools 102.3.1 HTML 102.3.2 Javascript 112.3.3 XML 112.3.4 XSLT 11

Chapter 3 OVERVIEW OF THE LITERATURE 123.1 Intrusion Detection System 133.2 Intrusion Prevention System 143.3 Writing snort rules 153.4 Multi sensor snort 153.5 Inline snort 163.6 Network bridging 173.7 Working with registries 183.8 About SPPA-T3000 18

iv

Chapter 4 DESIGN 204.1 Research and Analysis 214.1.1 Threats to SPPA-T3000 214.1.2 Possible positioning of sensors 224.1.3 Position of sensor in our setup 234.1.4 Position of IPS in our setup 234.2 System level design 234.2.1 Setup for one sensor snort 234.2.2 Setup for two sensor snort 244.2.3 Setup for IPS in inline snort setup 254.3 Detailed design 254.3.1 Installing snort 254.3.2 Snort rules 304.3.3 Program to manage snort variables 314.3.4 Developing multi sensor snort 314.3.5 Iptable rules 324.3.6 Iptables template 324.3.7 Iptables webpage 324.3.8 Snort webpage 334.3.9 Snort rules databank webpage 344.3.10 Setting up the network bridge 354.3.11 Setting up IPS using inline snort 354.3.12 User manuals for the web page 36

Chapter 5 CODING AND TESTING 375.1 Coding 385.1.1 Rules for one sensor snort 385.1.2 Rules for two sensor snort 395.1.3 Iptable rules 405.1.4 Rules for snort in inline mode 415.1.5 Iptable rules webpage screenshots 415.1.6 Snort rules webpage screenshots 445.1.7 Snort rules databank webpage screenshots 515.2 Testing 545.2.1 Running single sensor snort and multi sensor snort 54

v

5.2.2 Program to manage snort variables 545.2.3 Running the iptable rules 555.2.4 Using the iptable template 555.2.5 Running then IPS using inline snort 56

Chapter 5 CONCLUSION AND FUTURE ENHANCEMENTS 575.1 Conclusion 585.2 Future Enhancements 59

REFERENCES 60

vi

LIST OF FIGURES

Figure No Figure Title Page No2.1 Components of snort 83.1 Multi sensor configuration of snort 164.1 Placing the sensor behind the firewall 224.2 Placing the sensor in front of the firewall 224.3 Setup for one sensor snort 244.4 Setup for two sensor snort 244.5 Setup for IPS using inline snort 25

ABBREVIATIONSvii

IDS Intrusion Detection SystemIPS Intrusion Prevention System

NIDS Network Intrusion Detection SystemNIPS Network Intrusion Prevention SystemBASE Basic Analysis and Security EngineHTML Hyper Text Markup LanguageXML eXtensible Markup LanguageXSLT eXtensible Stylesheet Language Transformations

SPPA-T3000 Siemens Power Plant Automation T3000DMZ De-militarized zoneSSH Secure ShellRDP Remote Desktop Protocol

viii

CHAPTER 1: INTRODUCTION

1

CHAPTER 1: INTRODUCTION

1.1 GENERAL OVERVIEW

Several network based attacks can be detected based on their packet information which is

also termed as signature of the attack. Based upon a set of signatures and rules, the

Intrusion Detection System (IDS) is able to find and log suspicious activity and generate

alerts, and the Intrusion Prevention System (IPS) is able to prevent these intrusions from

entering the internal network. Intrusion detection is done using Snort and intrusion

prevention is achieved by integrating Iptables with the Snort rules.

1.2 MOTIVATION

Intrusion detection and prevention is necessary for security of any network. Initially,

firewall was considered essential to provide security for the network but now Intrusion

Detection System (IDS) and Intrusion Prevention System (IPS) are the mainstream

devices along with firewall. Nowadays intrusion prevention is one of the fundamental

requirements of any big organization.

2

1.3 OBJECTIVES

The goal of this project is to implement network security to a product of Siemens, SPPA-

T3000, which is the instrument and control system that provides remote access to power

plant management systems. This security system includes a network intrusion detection

system built with Snort and a network intrusion prevention system built with snort in

inline mode, with help of Iptables. I also build tools such as templates, web pages etc to

make the work easier.

1.4 ORGANIZATION OF REPORT

This report is organized into five chapters.

Chapter 1 (Introduction): This chapter introduces the topic and the central idea of the

project. The motivation behind doing this work is included here.

Chapter 2 (Software Requirement and Specifications): This chapter specifies the

system requirements, tools used to build IDS and IPS and the webpage tools used.

Chapter 3 (Overview of the Literature): This chapter presents the background informa-

tion about intrusion detection and prevention systems, snort related technologies and

gives an overview of SPPA-T3000.

Chapter 4 (Design): This chapter is divided into three sections. The first section

mentions the analysis and research done. The second section gives the system level

design. The third section describes the detailed design of the project.

3

Chapter 5 (Coding and Testing): This chapter describes the code samples used in

implementation of the security systems developed and screen shots of the web page tools

created. It also touches upon the testing methodology used.

Chapter 6 (Conclusion and Future Enhancements): This chapter summarizes the work

in brief and lists some possible future enhancements that can be added.

4

CHAPTER 2:

SOFTWARE REQUIREMENTS &

SPECIFICATIONS

5

CHAPTER 2: SOFTWARE REQUIREMENTS & SPECIFICATIONS

2.1 SYSTEM REQUIREMENTS

Following systems are required for setting up the security systems:

A debian machine: The debian operating system uses the linux kernel. The version of debian required is 6.0.3 and it has the name Squeeze.

A firewall: A firewall is a device or set of devices designed to permit or deny network transmissions based upon a set of rules and is frequently used to protect networks from unauthorized access while permitting legitimate communications to pass. Many personal computer operating systems include software-based firewalls to protect against threats from the public Internet.

Application servers, terminal servers, thin clients, a switch in de-militarized zone and a switch in application highway.

2.2 TOOLS REQUIRED TO BUILD SECURITY SYSTEMS

The following tools are required to build the IDS and IPS systems:

2.2.1 Snort

Snort is an open source network intrusion prevention system (NIPS) and network

intrusion detection system (NIDS), created by Martin Roesch. It has the ability to perform

real-time traffic analysis and packet logging on Internet Protocol (IP) networks. Snort

performs protocol analysis, content searching, and content matching.

6

Snort can be configured to run in three modes-

Sniffer mode, which simply reads the packets off of the network and displays them for you in a continuous stream on the console (screen).

Packet Logger mode, which logs the packets to disk.

Network Intrusion Detection System (NIDS) mode, the most complex and configurable configuration, which allows Snort to analyze network traffic for matches against a user-defined rule set and performs several actions based upon what it sees.

Components of Snort-

Snort is logically divided into different components. These components work together to

detect particular attacks and to generate output in a required format from the detection

system. A Snort-based IDS consists of the following major components:

Packet Decoder: Prepares packets for processing.

Preprocessors or Input Plugins: Used to normalize protocol headers, detect anomalies, packet reassembly and TCP stream re-assembly.

Detection Engine: Applies rules to packets.

Logging and Alerting System: Generates alert and log messages.

Output Modules: Process alerts and logs and generate final output.

7

Arrangement of components of snort-

Fig 2.1 Components of Snort

2.2.2 BASE (Basic Analysis and Security Engine)

BASE is based on the code from the Analysis Console for Intrusion Databases (ACID)

project. This application provides a web front-end to query and analyze the alerts coming

from a Snort IDS system. BASE is a web interface to perform analysis of intrusions that

snort has detected on your network. It uses a user authentication and role-base system, so

that you as the security admin can decide what and how much information each user can

see. It is written in PHP. It works with Snort and databases like MySQL and makes

information available in the database to the user through a web server.

8

2.2.3 Wireshark

Wireshark is a network packet analyzer. A network packet analyzer will try to capture

network packets and tries to display that packet data as detailed as possible. In this

project, Wireshark is used to check if all the packets coming from the source, that satisfy

the conditions mentioned in the snort rules, show an alert in BASE. We also use

Wireshark to look into the components of the packets and update our rule set accordingly

from time to time.

2.2.4 Iptables

Iptables is a tool used in linux distributions to control kernel's netfilter's firewall. It is

used to set up, maintain, and inspect the tables of IP packet filter rules in the Linux

kernel. Iptables firewall contains 3 tables, every table contains chains. Those chains are

default. User is able to define new chains and link from default chains to user defined

chains.

iptables contains 3 tables:

1. Filter table: This table is used to filter packets that pass the firewall.

This table contains 3 chains:

INPUT chain - used to filter incoming packets OUTPUT chain - used to filter outgoing packets FORWARD chain - used to filter forwarded packets (between network cards).

9

2. NAT table: This table is used to change source of the IP.

This table contains 3 chains:

PREROUTING chain - used to change IP before forwarding take place POSTROUTING chain - used to change IP after forwarding take place OUTPUT chain - used to filter on outgoing

3. Mangle table: This table is used to modify packets.

This table contains 2 chains:

PREROUTING chain - used to modify packets before forwarding take place. POSTROUTING chain - used to modify packets after forwarding take place.

2.2.5 Bash scripting

A BASH script, also called shell script is a quick-and-dirty method of prototyping a

complex application. Normally shells are interactive. It means shell accept command

from you (via keyboard) and execute them. But if you use command one by one

(sequence of 'n' number of commands), then you can store this sequence of command to

text file and tell the shell to execute this text file instead of entering the commands.

2.3 WEBPAGE DEVELOPMENT TOOLS

The following tools are required to build the web pages:

2.3.1 HTML

With HTML you can create your own Web site. HTML stands for Hyper Text Markup

Language. HTML is not a programming language, it is a markup language. A markup

language is a set of markup tags.HTML uses markup tags to describe web pages. HTML

10

markup tags are usually called HTML tags. HTML tags are keywords surrounded by

angle bracketsHTML tags normally come in pairs like <b> and </b>.

2.3.2 Javascript

JavaScript is the scripting language of the Web. JavaScript is used in web pages to add

functionality, validate forms, communicate with the server, and much more. JavaScript

was designed to add interactivity to HTML pages. JavaScript is usually embedded

directly into HTML pages.

2.3.3 XML

XML stands for eXtensible Markup Language. XML is designed to transport and store

data. XML is a markup language much like HTML. XML was designed to carry data, not

to display data. XML tags are not predefined.

2.3.4 XSLT

XSLT (eXtensible Stylesheet Language Transformations) is the recommended style sheet

language of XML. XSLT is used to transform an XML document into another XML

document, or another type of document that is recognized by a browser, like HTML and

XHTML. Normally XSLT does this by transforming each XML element into an

(X)HTML element. With XSLT you can add/remove elements and attributes to or from

the output file. You can also rearrange and sort elements, perform tests and make

decisions about which elements to hide and display, and a lot more.

11

CHAPTER 3:

OVERVIEW OF THE LITERATURE

12

CHAPTER 3: OVERVIEW OF THE LITERATURE

3.1 INTRUSION DETECTION SYSTEMS

An Intrusion Detection System (IDS) monitors network traffic or computer systems for

both unauthorized access and misuse, subsequently alerting the network or system

administrator. They are used to increase security cautions in a network or computer

system in addition to firewalls. While a firewall only limits access to prevent attacks,

once its broken there is no way to detect the intruder or the malicious software without an

IDS. IDS can track the intruder in the network, detect software behaving abnormally, and

alert the administrator.

An intrusion detection system consists of three components-

Sensors are placed to listen to various activities in a network or system. Console monitors events and alerts. Engine generates alerts if there is a suspicious activity in the monitored events.

There are two types of IDS based on the choice of sensor position-

Host Intrusion Detection Systems (HIDS):A host based intrusion detection system (HIDS) monitors internal components of a computer.

Network Intrusion Detection Systems (NIDS):Network based intrusion detection systems (NIDS) analyzes network packets captured by one or more sensors, which are located in the network.

13

There are two types of IDS based on the choice of detection engine-

Anomaly DetectionAn anomaly based detection engine can trace deviations from the normal state of a system, which is possibly caused by an attack to the system. For this purpose, the detection engine must know how the system normally behaves.

Signature DetectionSignature based intrusion detection engines try to detect an attack from its fingerprints. Most recent signatures - also referred to as rules can be found in websites or discussion forums. It is also possible to create individual rules.

Protecting the IDS itself-

One major issue is how to protect the system on which your intrusion detection software

is running. If security of the IDS is compromised, you may start getting false alarms or no

alarms at all. The intruder may disable IDS before actually performing any attack.

Following are two special techniques that can be used with Snort to protect it from being

attacked:

Snort on Stealth Interface:You can run Snort on a stealth interface which only listens to the incoming traffic but does not send any data packets out. Snort with no IP Address Interface:You can also use Snort on an interface where no IP address is assigned. For example, on a Linux machine, you can bring up interface eth0 without assigning an actual IP address. The advantage is that when the Snort host doesn’t have an IP address itself, nobody can access it.

3.2 INTRUSION PREVENTION SYSTEMS

Intrusion prevention systems are network security appliances that monitor network and

system activities for malicious activity. The main functions of intrusion prevention

systems are to identify malicious activity, log information about said activity, attempt to

block/stop activity, and report activity.

14

Intrusion prevention systems are considered extensions of intrusion detection systems

because they both monitor network traffic and/or system activities for malicious activity.

The main differences are, unlike intrusion detection systems, intrusion prevention

systems are placed in-line and are able to actively prevent/block intrusions that are

detected.

3.3 WRITING SNORT RULES

Snort’s detection system is based on rules. These rules in turn are based on intruder

signatures. Snort rules can be used to check various parts of a data packet.

All Snort rules have two logical parts: rule header and rule options.

The rule header contains information about what action a rule takes. It also contains

criteria for matching a rule against data packets – protocol, source ipaddress and port,

destination ipaddress and port.

The rule options part usually contains an alert message and information about which part

of the packet should be used to generate the alert message. The options part contains

additional criteria for matching a rule against data packets.

3.4 MULTI-SENSOR SNORT

In the enterprise, usually people have multiple Snort sensors behind every router or

firewall. In that case you can use a single centralized database to collect data from all of

the sensors. You can run Apache web server on this centralized database server multiple

15

sensors connect to the same centralized database. All data generated by these sensors is

stored in the database. A user then uses a web browser to view this data and analyze it.

To achieve multiple sensor snort configuration, we start multiple instances of snort, all

pointing to the same database Snort.

Fig. 3.1 Multisensor configuration

3.5 INLINE SNORT

An IPS (Intrusion Prevention System) can be implemented with a device where the Snort

software does the IPS job in inline mod2, while Iptables endorses firewall duties and,

with additional modules, creates software queues for the packets to be analyzed. Snort in

IPS mode controls not all network traffic but only the traffic described with iptables

rules. It receives packets sent from the Netfilter firewall with the help of the lipipq

library, compares them with Snort signature rules and tags them as drop if they match a 16

rule, then finally sends them back to Netfilter where the Snort Inline tagged packets are

dropped.

For inline deployment, at least one pair of interfaces is required for traffic to flow

through. To achieve this, a network bridge is created between these two interfaces. In

inline mode, Snort works like an Ethernet bridge, that is, in order to monitor a network

segment, it has to be inserted transparently with two bridged NICs. With this setup, any

packet can flow through the bridge from a network card to the other, unless it matches the

drop rules; in that case, the switch opens and blocks the packet.

3.6 NETWORK BRIDGING

An ethernet bridge is a device commonly used to connect different networks of ethernets

together, so that these ethernets will appear as one ethernet to the participants. Each of

the ethernets being connected corresponds to one physical interface in the bridge. These

individual ethernets are bundled into one bigger ethernet, this bigger ethernet corresponds

to the bridge network interface. It doesn’t physically exist on your computer, but instead

it is a virtual interface that just takes the packets from one physical interface, and

transparently routes them to the other.

A bridge device filters data traffic at a network boundary. Bridges inspect incoming traf-

fic and decide whether to forward or discard it. The program needed to create a bridge is

called brctl and is included in bridge-utils package that needs to be installed before set-

ting up the bridge. Brctl is used to set up, maintain, and inspect the ethernet bridge con-

figuration in the linux kernel.17

3.7 WORKING WITH REGISTRIES

Registry is a central hierarchical database used in Microsoft Windows operating systems

used to store information that is necessary to configure the system for one or more users,

applications and hardware devices. The Registry contains information that Windows

continually references during almost all operations.The registry contains two basic

elements: keys and values.

Registry keys are similar to folders. In addition to values, each key can contain subkeys, which may contain further subkeys, and so on.

Registry values are name/data pairs stored within keys.

The Windows registry can be edited manually using programs such as regedit.exe. The

registry can be manipulated in a number of ways from the command line. Scripting

languages such as javascript and VB script also enable registry editing from scripts.

3.8 ABOUT SPPA-T3000

Siemens Power Plant Automation T3000 (SPPA-T3000) is an instrumentation & control

system developed by Siemens AG. This system can perform all power plant automation

tasks such as turbine control, boiler control including boiler protection and balance of

plant. With its full integration to the power plant, staff can easily control and manage all

the activity in the plant in real time.

The centralized and integrated application server of SPPA-T3000 connects the

automation layer with the plant control room and offices outside the facility. It is also

18

possible to use mobile devices to get data from application servers. Only a web browser

and certainly the required clearance is needed to access the application server, which

presents the data through its web server. On the one hand, such a feature provides

flexibility and speed to the management; on the other, it raises many security issues,

which were not considered earlier in conjunction with the power plants.

19

CHAPTER 4: DESIGN

20

CHAPTER 4: DESIGN

4.1 RESEARCH AND ANALYSIS

4.1.1 Threat to SPPA-T3000

There are three types of threat sources for SPPA-T3000:

Insiders: Backdoors, user stations, walk-in viruses Outsiders: Hackers Special insiders: Rogue devices, technician notebooks

Usually attackers collect information about the victim system before attacking it. The

IP addresses of hosts in victim network, open ports and the applications running behind

these open ports is valuable information for an attacker when planning his attack. In order

to get this information the attacker will use a port scanner.

An attacker can manipulate the traffic with a “man in the middle” attack, where the attacker sends manipulated packets from host A to host B and vice versa and both hosts assume that they are communicating with the right part-ner.

The attacker can launch Denial of Service (DoS) attacks from outside the network. The attacker causes heavy traffic in the network with a DoS attack and this may lead some computers to become unreachable, which harms the availability of the SPPA-T3000.

The computer viruses are also a threat with high probability. The viruses can easily harm the network without being detected because the components in SPPA-T3000 have no virus scanners. Such a virus that steals passwords from computers can harm the plant in long term with high damage factor.

21

4.1.2 Possible Positioning Of Sensors

Behind the firewall:

In this positioning, IDS will not be able to detect every attack because some parts of the packets belonging to the attack will be blocked by the firewall, thus IDS is unable to detect the signature of the attack. The attacker cannot detect the IDS easily and as a result, he cannot attack IDS itself.

Fig 4.1 Placing the sensor behind the firewall

In front of the firewall:

In this case, the IDS will monitor all attacks coming from the outside. The IDS must be able to monitor all the traffic coming in and going out. If an attacker detects the IDS, he can create heavy traffic and cause, the IDS to drop packets. The firewall will prevent this type of traffic from entering the network.

Fig 4.2 Placing the sensor in front of the firewall

22

4.1.3 Position Of Sensor In Our Setup

As our NIDS is Snort based which uses rules (or signatures) to detect an intrusion, so it

should be able to match the conditions mentioned in the rules to the signature of the

intrusion. Thus we place the sensor in front of the firewall because if we place it behind

the firewall, firewall will block some unwanted or harmful parts of the packet and our

snort based IDS will not be able to detect signature of the attack.

4.1.4 Position Of IPS In Our Setup

We must be careful to put our IPS at the right place in the network. A Snort IDS just

needs to be connected to a switch port where it receives the traffic coming from a

mirrored port. For our IPS, the network configuration above cannot be used because

Snort Inline must check the packets before deciding to drop or accept them. It must be

placed along the network link we want to analyze and configured as a bridge. So you

must have a minimum of two networks interfaces, three of them is better because you can

dedicate a port to the IPS management.

4.2 SYSTEM LEVEL DESIGN

4.2.1 Setup for one sensor snort

The NIDS sensor is placed in front of the firewall. The NIDS monitors traffic passing on

the dotted line between the switch and the firewall, as shown in the figure below. For

security purposes, the NIDS machine will only be accessible through SSH(secure shell)

from a specific host.

23

Fig. 4.3 Setup for one sensor snort

4.2.2 Setup for multi sensor snort

Our NIDS machine in multi sensor snort configuration has two sensors. One sensor is the

line connecting the switch in de-militarized zone and the firewall, and other is the line

connecting the thin client and the switch in application highway.

Fig. 4.4 Setup for two sensor snort

24

4.2.2 Setup for IPS using inline snort

In this configuration, the NIDS machine is removed, and an IPS machine is added

between the switch in de-militarized zone and the firewall.

Fig. 4.5 Setup for IPS using inline snort

4.3 DETAILED DESIGN

4.3.1 Installing Snort

Install OS and base software

Run this is so we can connect via SSH and copy\paste to the terminal.

sudo apt-get update && apt-get install sshrm /var/lib/dpkg/statuscp /var/lib/dpkg/status-old/var /lib/dpkg/statusrm –rf /var/lib/apt/lists/*dpkg –configure –aaptitude updateaptitude upgradeaptitude install –f

25

Go to source.list file- sudo vi /etc/apt/sources.listAdd the following lines:deb http://packages.dotdeb.org squeeze alldeb-src http://packages.dotdeb.org squeeze all

Install the dotdeb GnuPG key:cd /usr/srcsudo wget http://www.dotdeb.org/dotdeb.gpgsudo cat dotdeb.gpg | sudo apt-key add -

Install the following packages:sudo apt-get update && sudo apt-get install apache2 libapache2-mod-php5 libwww-perl mysql-server mysql-common mysql-client php5-mysql libnet1 libnet1-dev libpcre3 libpcre3-dev autoconf libcrypt-ssleay-perl libmysqlclient-dev php5-gd php-pear libphp-adodb php5-cli libtool libssl-dev gcc-4.4 g++ automake gcc make flex bison apache2-doc ca-certificates vim

Install Snort pre-requisites - libpcap, libdnet, and DAQ

Install libpcap:cd /usr/srcsudo wget http://www.tcpdump.org/release/libpcap-1.2.0.tar.gzsudo tar -zxf libpcap-1.2.0.tar.gz && cd libpcap-1.2.0sudo ./configure --prefix=/usr --enable-sharedsudo make && sudo make install

Install libdnet:cd /usr/srcsudo wget http://libdnet.googlecode.com/files/libdnet-1.12.tgzsudo tar -zxf libdnet-1.12.tgz && cd libdnet-1.12sudo ./configure --prefix=/usr --enable-sharedsudo make && sudo make install

Install DAQ:cd /usr/srcsudo wget http://www.snort.org/dl/snort-current/daq-0.6.2.tar.gzsudo tar -zxf daq-0.6.2.tar.gz && cd daq-0.6.2sudo ./configuresudo make && sudo make install

26

Update the shared library pathecho /usr/local/lib >> /etc/ld.so.conf /usr/lib && ldconfig

/usr/local/lib and /usr/lib are the two paths containing the libraries to be shared. The command ‘ldconfig’ enables liabraries to be shared.

Install, configure & start Snort

cd /usr/srcsudo wget http://labs.snort.org/snort/2912/snort.confsudo wget http://www.snort.org/dl/snort-current/snort-2.9.1.2.tar.gz -O snort-2.9.1.2.tar.gzsudo tar -zxf snort-2.9.1.2.tar.gz && cd snort-2.9.1.2sudo ./configure --enable-sourcefiresudo make && make installsudo mkdir /etc/snort /etc/snort/rules /var/log/snort /var/log/barnyard2 /usr/local/lib/snort_dynamicrulessudo touch /etc/snort/rules/white_list.rules /etc/snort/rules/black_list.rulessudo groupadd snort && sudo useradd -g snort snortsudo chown snort:snort /var/log/snort /var/log/barnyard2sudo cp /usr/src/snort-2.9.1.2/etc/*.conf* /etc/snortsudo cp /usr/src/snort-2.9.1.2/etc/*.map /etc/snortsudo cp /usr/src/snort.conf /etc/snort

sudo vi /etc/snort/snort.confChange these lines:Line #45 - ipvar HOME_NET 192.168.16.0/20– make this match your internal (friendly) networkLine #48 - ipvar EXTERNAL_NET !$HOME_NETLine #101 - var RULE_PATH ./rules – this assumes /etc/snort/rulesLine #252-256 comment out all of the preprocessor normalize_ linesLine #284 - add this to the end after “decompress_depth 65535” max_gzip_mem 104857600Line #499 - add this line output unified2: filename snort.log, limit 128Line #532 - delete or comment out all of the “include $RULE_PATH” lines except “local.rules”

sudo vi /etc/snort/rules/local.rulesEnter a simple rule like this for testing:alert icmp any any -> $HOME_NET any (msg:"ICMP test"; sid:10000001;)Now we can start and test snort. /usr/local/bin/snort -A console -q -u snort -g snort -c /etc/snort/snort.conf -i eth1

27

Ping the management IP address from another machine, alerts should be printed to the console.

Setup the MySQL server

sudo mysql -u root -p mysql> create database snort;mysql> grant CREATE, INSERT, SELECT, DELETE, UPDATE on snort.* to snort@localhost;mysql> SET PASSWORD FOR snort@localhost=PASSWORD(‘White123#'); # set user passwordmysql> exit;Now we have to import the database schema:# mysql -u root -p < /usr/src/snort-2.9.1.2/schemas/create_mysql snort # enter password again# mysql -u root -p # enter password againmysql> use snort;mysql> show tables; # you should see the list of new tables you just imported.mysql> exit;

Install & configure barnyard2

sudo cd /usr/srcsudo wget https://nodeload.github.com/firnsy/barnyard2/tarball/master -O firnsy-barnyard2-v2-1.10-beta2.tar.gzsudo tar -zxf firnsy-barnyard2-v2-1.10-beta2.tar.gz && cd firnsy-barnyard2-c8e30b8sudo autoreconf -fvi -I ./m4sudo ./configure --with-mysqlsudo make && make installsudo mv /usr/local/etc/barnyard2.conf /etc/snortsudo vi /etc/snort/barnyard2.conf

Line #215 change to output alert_fastAt the end of the file add this line:output database: log, mysql, user=snort password=<mypassword> dbname=snort host=localhostTo configure Ethernet manually without IP address, also add :Ip link set eth1 up

Now start snort and barnyard2 with these commands:

28

/usr/local/bin/snort -q -u snort -g snort -c /etc/snort/snort.conf -i eth1 &

/usr/local/bin/barnyard2 -c /etc/snort/barnyard2.conf -d /var/log/snort -f snort.log -w /etc/snort/bylog.waldo -G /etc/snort/gen-msg.map -S /etc/snort/sid-msg.map -C /etc/snort/classification.config &

Configure Apache2 & PHP

cp /etc/apache2/sites-available/default-ssl /etc/apache2/sites-enabledsudo vi /etc/php5/apache2/php.iniLine #514 – change line to read - error_reporting = E_ALL & ~E_NOTICEsudo a2enmod sslsudo pear config-set preferred_state alphasudo pear channel-update pear.php.netsudo pear install --alldeps Image_Color Image_Canvas Image_Graph sudo /etc/init.d/apache2 restart

Install and configure BASE

cd /usr/srcsudo wget http://sourceforge.net/projects/secureideas/files/BASE/base-1.4.5/base-1.4.5.tar.gzsudo tar -zxf base-1.4.5.tar.gzsudo cp -r base-1.4.5 /var/www/basesudo chmod 777 /var/www/base (just for now)

Open a browser and go to: https://192.168.18.176/base Click Continue, choose EnglishPath to adodb: /usr/share/php/adodbClick ContinueDatabase Name: snortDatabase Host: localhostDatabase Port: leave blankDatabase User Name: snortDatabase Password: mypassPut in values for the authentication system and click submit.Click "create baseag" which extends the DB to support BASE.Continue to step 5 to login.

Startup script for snort & barnyard

sudo vi /etc/init.d/snortbarnA startup script was written in this file to start snort and barnyard. Make it executable and create the startup symlinks:

29

sudo chmod +x /etc/init.d/snortbarnsudo insserv -f -v snortbarn

Snort & Barnyard will now start automatically at boot.

Now,

To start snort, type: sudo /etc/init.d/snortbarn start

To stop snort, type: sudo /etc/init.d/snortbarn stop

To restart snort, type: sudo /etc/init.d/snortbarn restart

4.3.2 Snort Rules

Create two different files in /etc/snort/variables . Declare variables for device ip address

and ports for different protocols in the two files and include these files in the snort

configuration file. Now, we design snort rules such that, when we start the workbench on

the application server from our thin client, the snort rules only show alerts for the

unwanted or the intrusive network packets. For this, first we write rules to pass or ignore

the non-intrusive packets , next we append rules to show alerts for the intrusive packets in

BASE. The rules are designed on the basis of contents of network packets related to

workbench, which are observed using Wireshark. The rules are written in

/etc/snort/rules/local.rules file.

4.3.3 Program To Manage Snort Variables

We write programs in BASH scripting to edit previously existing variables or add new

variables. We write two different shell scripts to carry out these functions. In both scripts,

first the user is asked, what kind of variables does he want to edit/add, ipaddresses or

ports. Then the user can mention details of variables to be edited or added.

4.3.4 Developing Multi sensor Snort

30

We use two sensors for this multisensory configuration, one on eth1 and another on eth2.

We have two snort configuration files in /etc/snort, snort.conf and snort2.conf. In snort.-

conf, the output unified command logs data in snort.log and in snort2.conf, the output

unified command logs data in snort2.log. Snort.conf reads rules from local.rules and

snort2.conf reads rules from local2.rules. We also have two barnyard configuration files

in /etc/snort, barnyard2.conf and barnyard22.conf. In barnyard2.conf, in output database

command, add sensor_name: sensor_eth1. In barnyard22.conf, in output database com-

mand, add sensor_name: sensor_eth2.The /etc/snort file also contains two waldo files, by-

log.waldo and bylog2.waldo. In /etc/snort file we create a file snortbarn_var, and write a

script which asks the sensor name of then runs snort and barnyard on these sensors.

Start two instances of snort simultaneously, one on eth1, another on eth2. To start corre-

sponding workbench, follow these steps:

Eth1: RDP from my pc to thin client, then start workbench on application server 1.

Eth2: RDP from my pc to application server 2, then RDP from this machine to terminal server, then start workbench on application server 2.

4.3.5 Iptable Rules

We write the iptables rules to allow ICMP, SSH and HTTP traffic from various machines,

block the unwanted traffic and log the details in /var/log/messages. These rules are written

in a file and executed. Variables are included for all ipaddresses and ports.

4.3.6 Iptable Template

A template was created using BASH Scripting which outputs an entire iptables chain rule

set to a file, only with a few parameters given as input to the template from another file.

31

The template also directly resolves ipaddresses and hostnames from /etc/hosts file and

outputs them in the form of iptables variables in the output file.

4.3.7 Iptables Webpage

Features:

Create new iptable rules and save them to a new file. View contents of a rules file created before. Add new rules to the rules contained in a previously created file. Create new machine and port variables.

The webpage consists of the following functionalities:

The web page is built using HTML, Javascript, XML and XSLT. The user has to select source and destination machines and ports, and action for the

iptable rules. Options in the drop down list for source and destination machines and ports are im-

ported from the xml file. Details about the machine ipaddresses and port values are imported from the xml

file and displayed on the webpage in a table. If you make changes in the xml file or add new nodes in the xml file, then the op-

tions in the corresponding drop down lists, as well as in the table giving details about the machine or port will be changed automatically.

The user can also add or remove machine or port options manually from the web page.

After selecting all options, user can view the preview of the rule. The user can then insert or append this new rule to the rule set. The text in the rules textboxes can only be edited after clicking on the Edit button. The user can store the generated rules to a file and give a suitable name to this file. The user can browse and select an existing rules file and view its content The user can also add new rules to this content and save the new content to a new or

existing file.

4.3.8 Snort Webpage

Features:

Create new snort rules and save them to a new file. View contents of a rules file created before. Add new rules to the rules contained in a previously created file. Create new machine and port variables.

The webpage consists of the following functionalities:

32

The web page is built using HTML, Javascript, XML and XSLT. The user has to select source and destination machines and ports, action, protocol

and enter a snort rule id for the snort rules. Options in the drop down list for source and destination machines and ports are im-

ported from the xml file. Details about the machine ipaddresses and port values are imported from the xml

file and displayed on the webpage in a table. If you make changes in the xml file or add new nodes in the xml file, then the op-

tions in the corresponding drop down lists, as well as in the table giving details about the machine or port will be changed automatically.

Concept of embedding one xml file in another is also used with help of ENTITY command. The radio options for actions and protocol are imported from two sepa-rate xml files which are embedded in the previous xml file.

The user can also add or remove machine or port options manually from the web page.

After selecting all options, user can view the preview of the rule. The user can add lots more options by selecting corresponding option parameters or

entering option parameters. There are 5 types of options provided in the web page: keyword type options, op-

tions where user has to enter a value, options where user has to select a value from the given set of options, options with multiple parameters and user defined options.

In the dropdowns for keyword type options and options where user has to enter value, the options are imported from new xml files which are embedded in the orig-inal xml file.

For the options where user has to select a parameter value from a given list, the op-tions for the parameters are also embedded from separate xml files for each option.

In multiple parameter options, whereever the user has to select an option parameters from a list, a new xml file is involved for each parameter of each option, which is embedded in the first xml file.

The user can then insert or append this new rule to the rule set. The text in the rules textboxes can only be edited after clicking on the Edit button. The user can store the generated rules to a file and give a suitable name to this file. The user can browse and select an existing rules file and view its content The user can also add new rules to this content and save the new content to a new or

existing file.

4.3.9 Snort Rules Databank Webpage

Features:

Create milti-sensor snort configuration with fully prepared rules file, variables file, snort.-conf and barnyard.conf

Prepare as many sensors as you want. View and edit an existing sensor configuration.

33

The webpage consists of the following functionalities:

The web page is built using HTML, Javascript, XML and XSLT. The folder “Rules path” contains various files containing rule templates corresponding to

various protocols. The webpage makes use of registries for creating, saving and opening files. You can change

the root directory of your webpage folder from this webpage if you move the webpage tool to another system or file location.

Enter your user id and click on “create user”. A new folder will be created in “output files” folder for your multi sensor configuration.

Enter the ipaddresses of the machines required to you. Leave the other ipaddress fields blank. Enter a name for your new sensor, select the protocols required and click on “Create sensor”.

A new folder will be created corresponding to this sensor in your user folder. Click on “Show rules”, “Show snort configuration”, “show variables” to view your rules file,

snort.conf file and variables file respectively. Click on the “Save” button next to these textboxes to save them.

Enter your snort database username and password and click on “Show barnyard configura-tion” to view the barnyard.conf file. Click on “Save” to save this file.

You can edit these files in their corresponding text boxes only after clicking on “Edit”. Browse and select rules file, snort.conf file, variables file and barnyard.cnf file separately to

edit them. You can add new rules and variables to these rules and variables files respectively. After saving these files, click on “CREATE NEW SENSOR” to start n fresh sensor configu-

ration, starting from name of the sensor. Add or remove machine ipaddresses, as per require-ment.

To view or edit an entire sensor configuration, go to “Edit an existing multisensory configuration” and select your user id. Now select the sensor you want to edit and click on “Edit sensor”. Your rules file, snort.conf file, variables file and barnyard.-conf file will be shown in the corresponding textboxes where you can modify them and resave. Also, the ipaddresses that you used for the sensor will be shown in their respective fields.

4.3.10 Setting up the network bridge

I created the bridge interface, added eth0 and eth1 to it, and brought them up:

brctl addbr br0brctl addif br0 eth0brctl addif br0 eth1ifconfig eth0 upifconfig eth1 upifconfig br0 up

34

After some iptables configuration, bridge0 should work. Assuming the system is

dedicated to being a bridge running Snort Inline, the only addition necessary to make

bridging work is the following:

iptables -I FORWARD -o br0 -j ACCEPT

Now bridge0 should be ready to pass packets. To check, run: iptables –vL

4.3.11 Setting up the IPS using inline snort

Configure and install the following tarballs in the given order:

123456

pcre-8.12.zip libpcap-1.1.1.tar.gz libdnet-1.11.tar.gz libnfnetlink-1.0.0.tar libnetfilter_queue 1.0.0.tar daq-0.5.tar.gz

Configure snort using following statement:

./configure --libdir=/usr/lib --includedir=/usr/include --enable-ipv6 --enable-gre --enable-targetbased --enable-decoder-preprocessor-rules --enable-active-response --enable-normalizer --enable-reload --enable-react –enable-zlib

Add this rule to the iptables:

Iptables -A FORWARD -i br0 -p tcp –s 172.18.21.2 –d 192.168.18.71 -j QUEUE

This rule will forward all tcp packets passing through the bridge br0, from machines 172.18.21.2 to 192.168.18.71 to a queue.Add this snort rule to /etc/snort/rules/local.rules:

drop tcp any any -> any any (sid:10000001;)

Now run snort inline using the following command:

sudo snort -A console -Q --daq-dir /usr/local/lib/daq --daq nfq --daq-var queue=2 -u snort -g snort -c /etc/snort/snort.conf

35

All the packets forwarded to the queue created before, will now be passed to snort, which

will drop the packets, according to the drop rule.

4.3.12 User manuals for the web tools

User manuals were created for the iptable rules webpage, snort rules webpage and snort

rules databank webpage with the following details:

Requirements Features of the webpage Input files Output files What to do before using the webpage How to use the webpage

36

CHAPTER 5: CODING AND TESTING

CHAPTER 5: CODING AND TESTING

5.1 CODING

5.1.1 Rules for one sensor snort

The rules are designed on the basis of contents of network packets related to workbench

from thin client to application server 1 in eth1, which are observed using Wireshark.

pass tcp $THIN_CLIENT any -> $APPLICATION_SERVER $RMI_REGISTRY_PORT (sid:10000011; content: "JRMI"; depth:4; flags: PA; )

pass tcp $THIN_CLIENT any -> $APPLICATION_SERVER $RMI_REGISTRY_PORT (sid:10000012; content: "P"; flags: PA; )

pass tcp $THIN_CLIENT any -> $APPLICATION_SERVER $RMI_REGISTRY_PORT (sid:10000013; content: "R"; dsize:1; flags: PA; )

37

pass tcp $THIN_CLIENT any -> $APPLICATION_SERVER $RMI_REGISTRY_PORT (sid:10000014; content: "T"; depth:1; flags: PA; )

pass tcp $THIN_CLIENT any -> $APPLICATION_SERVER $RMI_REGISTRY_PORT (sid:10000015; dsize:0;)

pass tcp $THIN_CLIENT any -> $APPLICATION_SERVER $RMI_REGISTRY_PORT (sid:10000059; content: "192.168.18.171";)

pass tcp $THIN_CLIENT any -> $APPLICATION_SERVER $RMI_COMM_PORT (sid:10000016; content: "JRMI"; depth:4; flags: PA; )

pass tcp $THIN_CLIENT any -> $APPLICATION_SERVER $RMI_COMM_PORT (sid:10000017; content: "P"; flags: PA; )

pass tcp $THIN_CLIENT any -> $APPLICATION_SERVER $RMI_COMM_PORT (sid:10000018; content: "R"; dsize:1; flags: PA; )

pass tcp $THIN_CLIENT any -> $APPLICATION_SERVER $RMI_COMM_PORT (sid:10000019; content: "T"; depth:1; flags: PA; )

pass tcp $THIN_CLIENT any -> $APPLICATION_SERVER $RMI_COMM_PORT (sid:10000020; dsize:0;)

pass tcp $THIN_CLIENT any -> $APPLICATION_SERVER $RMI_COMM_PORT (sid:10000060; content: "Q";)

pass tcp $THIN_CLIENT any -> $APPLICATION_SERVER $RMI_COMM_PORT (sid:10000066; content: "192.168.18.171";)

pass tcp $APPLICATION_SERVER any -> $THIN_CLIENT $RMI_TO_WORKB_PORT (sid:10000021; dsize:0; flags: S; )

pass tcp $APPLICATION_SERVER any -> $THIN_CLIENT $RMI_TO_WORKB_PORT (sid:10000022; dsize:0; flags: A; )

pass tcp $APPLICATION_SERVER any -> $THIN_CLIENT $RMI_TO_WORKB_PORT (sid:10000023; content: "JRMI"; depth:4;flags: PA; )

pass tcp $APPLICATION_SERVER any -> $THIN_CLIENT $RMI_TO_WORKB_PORT (sid:10000024; content: "R"; flags: PA; )

pass tcp $APPLICATION_SERVER any -> $THIN_CLIENT $RMI_TO_WORKB_PORT (sid:10000025; content: "P"; depth:1; flags: PA; )

pass tcp $APPLICATION_SERVER any -> $THIN_CLIENT $RMI_TO_WORKB_PORT (sid:10000026; content: "I"; flags: A; )

pass tcp $APPLICATION_SERVER any -> $THIN_CLIENT $RMI_TO_WORKB_PORT (sid:10000027; content: "N"; flags: PA; )

pass tcp $APPLICATION_SERVER any -> $THIN_CLIENT $RMI_TO_WORKB_PORT (sid:10000028; content: "X"; flags: PA; )

38

pass tcp $APPLICATION_SERVER any -> $THIN_CLIENT $RMI_TO_WORKB_PORT (sid:10000029; dsize:0; flags: AF; )

pass tcp $APPLICATION_SERVER any -> $THIN_CLIENT $RMI_TO_WORKB_PORT (sid:10000065; content: "V"; )

alert tcp $THIN_CLIENT any -> $APPLICATION_SERVER $HTTPS_PORT (sid:10000001;)

alert tcp $THIN_CLIENT any -> $APPLICATION_SERVER $RMI_REGISTRY_PORT (sid:10000002;)

alert tcp $THIN_CLIENT any -> $APPLICATION_SERVER $RMI_COMM_PORT (sid:10000003;)

alert tcp $APPLICATION_SERVER any -> $THIN_CLIENT $RMI_TO_WORKB_PORT (sid:10000004;)

5.1.2 Rules for two sensor snort

The rules for sensor 1 are designed on the basis of contents of network packets related to

workbench from thin client to application server 1 in eth1.The rules for sensor 2 are

designed on the basis of contents of network packets related to workbench from terminal

server to application server 2 in eth2.

The rules for sensor 1 are same as the rules for one sensor snort, mentioned in the section

above. The rules for sensor 2 are almost same as these rules, only the source and

destination address are different.

5.1.3 Iptable rules

We write the iptables rules to allow ICMP, SSH and HTTP traffic from various machines,

block the unwanted traffic and log the details in /var/log/messages.

# Rules for ICMP (Ping)iptables -A INPUT -p icmp --icmp-type 8 -s $TS -d $IDS -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

39

iptables -A OUTPUT -p icmp --icmp-type 0 -s $IDS -d $TS -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -p icmp --icmp-type 8 -s $AppSrv -d $IDS -m state --state NEW,ESTABLISHED,RELATED -j ACCEPTiptables -A OUTPUT -p icmp --icmp-type 0 -s $IDS -d $AppSrv -m state --state ESTABLISHED,RELATED -j ACCEPT

# Rules for SSHiptables -A INPUT -p tcp -s $TS -d $IDS --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPTiptables -A OUTPUT -p tcp -s $IDS -d $TS --sport 22 -m state --state NEW,ESTABLISHED -j ACCEPTiptables -A INPUT -p tcp -s $AppSrv -d $IDS --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPTiptables -A OUTPUT -p tcp -s $IDS -d $AppSrv --sport 22 -m state --state NEW,ESTABLISHED -j ACCEPTiptables -A OUTPUT -p tcp -s $IDS --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPTiptables -A INPUT -p tcp --sport 22 -d $IDS -m state --state NEW,ESTABLISHED -j ACCEPT

# Rules for HTTPiptables -A INPUT -p tcp -s $AppSrv -d $IDS --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPTiptables -A OUTPUT -p tcp -s $IDS -d $AppSrv --sport 80 -m state --state NEW,ESTABLISHED -j ACCEPTiptables -A INPUT -p tcp -s $AppHW -d $IDS --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPTiptables -A OUTPUT -p tcp -s $IDS -d $AppHW --sport 80 -m state --state NEW,ESTABLISHED -j ACCEPT

# Rules to block the unwanted traffic and log the details in /var/log/messagesiptables -A OUTPUT -p tcp -s $IDS -j LOG --log-prefix 'output blocked!' --log-level 4iptables -A INPUT -p tcp -d $IDS -j LOG --log-prefix 'input blocked!' --log-level 4iptables -A OUTPUT -s $IDS -j DROPiptables -A INPUT -d $IDS -j DROP

5.1.4 Rules for snort in IPS(inline) mode

The rules for inline sensor are designed on the basis of contents of network packets

related to workbench from terminal server to application server 2 passing from the bridge

br0. These rules are almost same as the rules for one sensor snort, mentioned in the

40

section above, only the source and destination address are different (from terminal server

to application server 2) and the action of the packets are drop in place of alert.

5.1.5 Iptable rules webpage screenshots

41

42

5.1.6 Snort rules webpage screenshots

43

44

45

46

47

48

49

50

5.1.7 Snort rules databank webpage screenshots

51

52

53

5.2 TESTING

5.2.1 Running the single sensor and multi sensor snort

When we start snort, either in one sensor configuration or multisensor configuration and

then start the workbench, BASE shows new alerts. Only the generic rules in our rule set

show alerts. These are the alerts for the unwanted packets or intrusions in the network. In

BASE we can filter the alerts on the basis of source or destination addresses, source or

destination ports, protocols or on the basis of the rule that generates alerts and then try

finding out a solution to prevent these intrusions in the network in the future.

5.2.2 Program To Manage Snort Variables

Output of the script to edit previously existing variables:

54

"What variables do you want to edit?" ports

"Enter name of the variable" ssh

"Enter the new value" 22

Now, the value of the port named “ssh” will be changed to 22.

Output of the script to add new variables:

"What variables do you want to add?" ipaddress

"Enter name of the variable" my_pc

"Enter the value of the variable" 121.14.15.67

Now, an ipaddress variable named my_pc will be added, with value 121.14.15.67

5.2.3 Running the iptable rules

When our new iptable rules are executed to be integrated in the table chains, the firewall

allows only ICMP, SSH and HTTP connections to be established between the mentioned

machines. All the rest of the network traffic is blocked from these machines. Also, the

traffic behavior is logged in the log files.

5.2.4 Using the iptable template

Input to the template:

tcp TS IDS SSHtcp AppSrv IDS HTTPicmp TS IDS

Output of the template (printed in the output file):

# Iptable rules:-iptables -F#Variables for ipaddresses:TS="172.18.21.2"IDS="192.168.18.176"AppSrv="192.168.18.31,192.168.18.32, 132.186.114.137"AppHW="192.168.16.0/21"ExtTC="192.168.18.10"localhost="127.0.0.1"

55

nids-ips.t3kids="192.168.2.176"#Variables for port numbers:SSH="22"HTTP="80"# Rules for SSH protocol:iptables -A INPUT -p tcp -s $TS -d $IDS --dport $SSH -m state --state NEW,ESTABLISHED -j ACCEPTiptables -A OUTPUT -p tcp -s $IDS --sport $SSH -d $TS -m state --state NEW,ESTABLISHED -j ACCEPT# Rules for HTTP protocol:iptables -A INPUT -p tcp -s $AppSrv -d $IDS --dport $HTTP -m state --state NEW,ESTABLISHED -j ACCEPTiptables -A OUTPUT -p tcp -s $IDS --sport $HTTP -d $AppSrv -m state --state NEW,ESTABLISHED -j ACCEPT# Rules for ping operations(ICMP protocol):iptables -A INPUT -p icmp --icmp-type 8 -s $TS -d $IDS -m state --state NEW,ESTABLISHED,RELATED -j ACCEPTiptables -A OUTPUT -p icmp --icmp-type 0 -s $IDS -d $TS -m state --state ESTABLISHED,RELATED -j ACCEPT# Rules to block the unwanted traffic and log the details in /var/log/messagesiptables -A OUTPUT -p tcp -s $IDS -j LOG --log-prefix 'output blocked!' --log-level 4iptables -A INPUT -p tcp -d $IDS -j LOG --log-prefix 'input blocked!' --log-level 4iptables -A OUTPUT -s $IDS -j DROPiptables -A INPUT -d $IDS -j DROP

5.2.5 Running the IPS using inline snort

After running the IPS, when we start the workbench from the terminal server to the

application server 2, the packets passing through the bridge that do not match the content

mentioned in the snort rules are dropped.

56

CHAPTER 6: CONCLUSION AND

FUTURE ENHANCEMENTS

57

CHAPTER 6: CONCLUSION AND FUTURE ENHANCEMENTS

6.1 CONCLUSION

Security is a big issue for all networks in today's enterprise environment. Hackers and

intruders have made many successful attempts to bring down high-profile company

networks and web services. Network Intrusion Detection System has a major role to play

in safeguarding the network resources against various kinds of attacks.

In the present framework of the project, the design and development of Signature based

Network Intrusion Detection System and Network Intrusion Prevention System are

discussed which are built on top of existing open source signature based network IDS,

called SNORT and network IPS called IPTABLES respectively. Alerts for the unwanted

packets can be seen in the output module called BASE which can be accessed on a web-

interface. These unwanted packets can then be blocked using snort in inline mode, that

acts as an IPS.

The tools developed such as program to manage variables file for snort, iptables template,

iptable rules webpage, snort rules webpage and snort rules databank webpage makes our

work of writing snort and iptable rules easier.

58

6.2 FUTURE ENHANCEMENTS

There is a lot of scope for future work to be done in the project domain. Some

enhancements that can be made to the current project are:

Snort can be extended to multiple more scenarios running in different interfaces

with different set of snort rules.

In IPS, multiple queues can be used for iptables and multiple inline snort

instances can be run parallel for different queues.

Pulledpork can be installed and configured to update the snort rules automatically

from time to time.

59

REFERENCES

1. http://www.snort.org/ docs

2. http://en.wikipedia.org/wiki/Snort

3. http://www.sourcefire.com/security/snort

4. http://www.debian.org

5. http://en.wikipedia.org/wiki/iptables

6. http://www.netfilter.org/projects/iptables

7. http://www.linuxguruz.com/iptables-tutorial

8. http://snort-inline.sourceforge.net/

9. http://wiki.debian.org/network-bridge

10. http://www.w3schools.com/html

11. http://www.w3schools.com/javascript

12. http://www.w3schools.com/xml

13. http://www.w3schools.com/xslt

60