Engineering Internship Report - Network Intrusion Detection And Prevention Using Snort And Iptables

NETWORK INTRUSION DETECTION AND PREVENTION
USING SNORT AND IPTABLES
A practice school report submitted
To
MANIPAL UNIVERSITY
For Partial Fulfillment of the Requirement for the
Award of the Degree
Of
BACHELOR OF ENGINEERING
In
COMPUTER SCIENCE AND ENGINEERING
By
DISHA BEDI
Reg No: 080905220
Under the Guidance of
Prof. ASHWATH RAO
Assistant Professor, Department of Computer Science and Engineering
And
Mr. KISHORE DOMMETI
Consultant, 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 Department
Dept. of Computer Science & Engg.

i
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.

ii
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.

iii
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.

iv
TABLE OF CONTENTS
ACKNOWLEDGEMENT i
ABSTRACT ii
LIST OF FIGURES vii
ABBREVIATIONS viii
Chapter 1 INTRODUCTION 1
1.1 General Overview 2
1.2 Motivation 2
1.3 Objectives 3
1.4 Organization of Report 3
Chapter 2 SOFTWARE REQUIREMENTS AND SPECIFICATIONS 5
2.1 System requirements 6
2.2 Tools used to build security systems 6
2.2.1 Snort 6
2.2.2 BASE 8
2.2.3 Wireshark 9
2.2.4 Iptables 9
2.2.5 Bash scripting 10
2.3 Web page development tools 10
2.3.1 HTML 10
2.3.2 Javascript 11
2.3.3 XML 11
2.3.4 XSLT 11
Chapter 3 OVERVIEW OF THE LITERATURE 12
3.1 Intrusion Detection System 13
3.2 Intrusion Prevention System 14
3.3 Writing snort rules 15
3.4 Multi sensor snort 15
3.5 Inline snort 16
3.6 Network bridging 17
3.7 Working with registries 18
3.8 About SPPA-T3000 18

v
Chapter 4 DESIGN 20
4.1 Research and Analysis 21
4.1.1 Threats to SPPA-T3000 21
4.1.2 Possible positioning of sensors 22
4.1.3 Position of sensor in our setup 23
4.1.4 Position of IPS in our setup 23
4.2 System level design 23
4.2.1 Setup for one sensor snort 23
4.2.2 Setup for two sensor snort 24
4.2.3 Setup for IPS in inline snort setup 25
4.3 Detailed design 25
4.3.1 Installing snort 25
4.3.2 Snort rules 30
4.3.3 Program to manage snort variables 31
4.3.4 Developing multi sensor snort 31
4.3.5 Iptable rules 32
4.3.6 Iptables template 32
4.3.7 Iptables webpage 32
4.3.8 Snort webpage 33
4.3.9 Snort rules databank webpage 34
4.3.10 Setting up the network bridge 35
4.3.11 Setting up IPS using inline snort 35
4.3.12 User manuals for the web page 36
Chapter 5 CODING AND TESTING 37
5.1 Coding 38
5.1.1 Rules for one sensor snort 38
5.1.2 Rules for two sensor snort 39
5.1.3 Iptable rules 40
5.1.4 Rules for snort in inline mode 41
5.1.5 Iptable rules webpage screenshots 41
5.1.6 Snort rules webpage screenshots 44
5.1.7 Snort rules databank webpage screenshots 51
5.2 Testing 54
5.2.1 Running single sensor snort and multi sensor snort 54

vi
5.2.2 Program to manage snort variables 54
5.2.3 Running the iptable rules 55
5.2.4 Using the iptable template 55
5.2.5 Running then IPS using inline snort 56
Chapter 5 CONCLUSION AND FUTURE ENHANCEMENTS 57
5.1 Conclusion 58
5.2 Future Enhancements 59
REFERENCES 60

vii
LIST OF FIGURES
Figure No Figure Title Page No
2.1 Components of snort 8
3.1 Multi sensor configuration of snort 16
4.1 Placing the sensor behind the firewall 22
4.2 Placing the sensor in front of the firewall 22
4.3 Setup for one sensor snort 24
4.4 Setup for two sensor snort 24
4.5 Setup for IPS using inline snort 25

viii
ABBREVIATIONS
IDS Intrusion Detection System
IPS Intrusion Prevention System
NIDS Network Intrusion Detection System
NIPS Network Intrusion Prevention System
BASE Basic Analysis and Security Engine
HTML Hyper Text Markup Language
XML eXtensible Markup Language
XSLT eXtensible Stylesheet Language Transformations
SPPA-T3000 Siemens Power Plant Automation T3000
DMZ De-militarized zone
SSH Secure Shell
RDP Remote Desktop Protocol

2
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.

3
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
information 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.

4
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.

5
CHAPTER 2:
SOFTWARE REQUIREMENTS &
SPECIFICATIONS

6
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.

7
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.

8
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.

9
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).

10
2. NAT table: This table is used to change source of the IP.
 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.
 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

11
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.

12
CHAPTER 3:
OVERVIEW OF THE LITERATURE

13
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.

14
There are two types of IDS based on the choice of detection engine-
 Anomaly Detection
An 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 Detection
Signature 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.

15
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

16
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

17
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
traffic 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
setting up the bridge. Brctl is used to set up, maintain, and inspect the ethernet bridge
configuration in the linux kernel.

18
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

19
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.

21
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
partner.
 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.

22
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

23
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.

24
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

25
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

26
Install OS and base software
Run this is so we can connect via SSH and copypaste to the terminal.
sudo apt-get update && apt-get install ssh
rm /var/lib/dpkg/status
cp /var/lib/dpkg/status-old
/var /lib/dpkg/status
rm –rf /var/lib/apt/lists/*
dpkg –configure –a
aptitude update
aptitude upgrade
aptitude install –f
Go to source.list file- sudo vi /etc/apt/sources.list
Add the following lines:
deb http://packages.dotdeb.org squeeze all
deb-src http://packages.dotdeb.org squeeze all
Install the dotdeb GnuPG key:
cd /usr/src
sudo wget http://www.dotdeb.org/dotdeb.gpg
sudo 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/src
sudo wget http://www.tcpdump.org/release/libpcap-1.2.0.tar.gz
sudo tar -zxf libpcap-1.2.0.tar.gz && cd libpcap-1.2.0
sudo ./configure --prefix=/usr --enable-shared
sudo make && sudo make install
Install libdnet:

27
cd /usr/src
sudo wget http://libdnet.googlecode.com/files/libdnet-1.12.tgz
sudo tar -zxf libdnet-1.12.tgz && cd libdnet-1.12
sudo ./configure --prefix=/usr --enable-shared
Install DAQ:
cd /usr/src
sudo wget http://www.snort.org/dl/snort-current/daq-0.6.2.tar.gz
sudo tar -zxf daq-0.6.2.tar.gz && cd daq-0.6.2
sudo ./configure
Update the shared library path
echo /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/src
sudo wget http://labs.snort.org/snort/2912/snort.conf
sudo wget http://www.snort.org/dl/snort-current/snort-2.9.1.2.tar.gz -O snort-
2.9.1.2.tar.gz
sudo tar -zxf snort-2.9.1.2.tar.gz && cd snort-2.9.1.2
sudo ./configure --enable-sourcefire
sudo make && make install
sudo mkdir /etc/snort /etc/snort/rules /var/log/snort /var/log/barnyard2
/usr/local/lib/snort_dynamicrules
sudo touch /etc/snort/rules/white_list.rules /etc/snort/rules/black_list.rules
sudo groupadd snort && sudo useradd -g snort snort
sudo chown snort:snort /var/log/snort /var/log/barnyard2
sudo cp /usr/src/snort-2.9.1.2/etc/*.conf* /etc/snort
sudo cp /usr/src/snort-2.9.1.2/etc/*.map /etc/snort
sudo cp /usr/src/snort.conf /etc/snort
sudo vi /etc/snort/snort.conf
Change these lines:
Line #45 - ipvar HOME_NET 192.168.16.0/20– make this match your internal
(friendly) network
Line #48 - ipvar EXTERNAL_NET !$HOME_NET

28
Line #101 - var RULE_PATH ./rules – this assumes /etc/snort/rules
Line #252-256 comment out all of the preprocessor normalize_ lines
Line #284 - add this to the end after “decompress_depth 65535” max_gzip_mem
104857600
Line #499 - add this line output unified2: filename snort.log, limit 128
Line #532 - delete or comment out all of the “include $RULE_PATH” lines except
“local.rules”
sudo vi /etc/snort/rules/local.rules
Enter 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
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 password
mysql> 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 again
mysql> use snort;
mysql> show tables; # you should see the list of new tables you just imported.
mysql> exit;
Install & configure barnyard2
sudo cd /usr/src
sudo wget https://nodeload.github.com/firnsy/barnyard2/tarball/master -O firnsy-
barnyard2-v2-1.10-beta2.tar.gz
sudo tar -zxf firnsy-barnyard2-v2-1.10-beta2.tar.gz && cd firnsy-barnyard2-
c8e30b8
sudo autoreconf -fvi -I ./m4
sudo ./configure --with-mysql
sudo make && make install

29
sudo mv /usr/local/etc/barnyard2.conf /etc/snort
sudo vi /etc/snort/barnyard2.conf
Line #215 change to output alert_fast
At the end of the file add this line:
output database: log, mysql, user=snort password=<mypassword> dbname=snort
host=localhost
To configure Ethernet manually without IP address, also add :
Ip link set eth1 up
Now start snort and barnyard2 with these commands:
/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-enabled
sudo vi /etc/php5/apache2/php.ini
Line #514 – change line to read - error_reporting = E_ALL & ~E_NOTICE
sudo a2enmod ssl
sudo pear config-set preferred_state alpha
sudo pear channel-update pear.php.net
sudo pear install --alldeps Image_Color Image_Canvas Image_Graph
sudo /etc/init.d/apache2 restart
Install and configure BASE
cd /usr/src
sudo wget http://sourceforge.net/projects/secureideas/files/BASE/base-1.4.5/base-
1.4.5.tar.gz
sudo tar -zxf base-1.4.5.tar.gz
sudo cp -r base-1.4.5 /var/www/base
sudo chmod 777 /var/www/base (just for now)
Open a browser and go to: https://192.168.18.176/base
Click Continue, choose English
Path to adodb: /usr/share/php/adodb
Click Continue

30
Database Name: snort
Database Host: localhost
Database Port: leave blank
Database User Name: snort
Database Password: mypass
Put 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/snortbarn
A startup script was written in this file to start snort and barnyard.
Make it executable and create the startup symlinks:
sudo chmod +x /etc/init.d/snortbarn
sudo 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.

31
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
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 command, add sensor_name: sensor_eth2.The /etc/snort file also contains two
waldo files, bylog.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
corresponding 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.

32
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.
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
imported 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
options 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.

33
 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 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
imported 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
options 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
separate 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,
options 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
original xml file.
 For the options where user has to select a parameter value from a given list, the
options for the parameters are also embedded from separate xml files for each
option.

34
 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.
 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
configuration” 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
configuration, starting from name of the sensor. Add or remove machine ipaddresses, as per
requirement.

35
 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 br0
brctl addif br0 eth0
brctl addif br0 eth1
ifconfig eth0 up
ifconfig eth1 up
ifconfig br0 up
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:
1
2
3
4
5
6
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:

36
./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
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

37
CHAPTER 5: CODING AND TESTING

38
CHAPTER 5: CODING AND TESTING
5.1 CODING
5.1.1 Rules for one sensorsnort
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; )
(sid:10000012; content: "P"; flags: PA; )
(sid:10000013; content: "R"; dsize:1; flags: PA; )
(sid:10000014; content: "T"; depth:1; flags: PA; )
(sid:10000015; dsize:0;)
(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; )
(sid:10000017; content: "P"; flags: PA; )
(sid:10000018; content: "R"; dsize:1; flags: PA; )
(sid:10000019; content: "T"; depth:1; flags: PA; )
(sid:10000020; dsize:0;)
(sid:10000060; content: "Q";)
(sid:10000066; content: "192.168.18.171";)

39
pass tcp $APPLICATION_SERVER any -> $THIN_CLIENT
$RMI_TO_WORKB_PORT (sid:10000021; dsize:0; flags: S; )
$RMI_TO_WORKB_PORT (sid:10000022; dsize:0; flags: A; )
$RMI_TO_WORKB_PORT (sid:10000023; content: "JRMI"; depth:4;flags: PA; )
$RMI_TO_WORKB_PORT (sid:10000024; content: "R"; flags: PA; )
$RMI_TO_WORKB_PORT (sid:10000025; content: "P"; depth:1; flags: PA; )
$RMI_TO_WORKB_PORT (sid:10000026; content: "I"; flags: A; )
$RMI_TO_WORKB_PORT (sid:10000027; content: "N"; flags: PA; )
$RMI_TO_WORKB_PORT (sid:10000028; content: "X"; flags: PA; )
$RMI_TO_WORKB_PORT (sid:10000029; dsize:0; flags: AF; )
$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 sensorsnort
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.

40
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
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
iptables -A OUTPUT -p icmp --icmp-type 0 -s $IDS -d $AppSrv -m state --state
# Rules for SSH
iptables -A INPUT -p tcp -s $TS -d $IDS --dport 22 -m state --state NEW,ESTABLISHED
-j ACCEPT
iptables -A OUTPUT -p tcp -s $IDS -d $TS --sport 22 -m state --state
NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp -s $AppSrv -d $IDS --dport 22 -m state --state
iptables -A OUTPUT -p tcp -s $IDS -d $AppSrv --sport 22 -m state --state
iptables -A OUTPUT -p tcp -s $IDS --dport 22 -m state --state NEW,ESTABLISHED -j
ACCEPT
iptables -A INPUT -p tcp --sport 22 -d $IDS -m state --state NEW,ESTABLISHED -j
ACCEPT
# Rules for HTTP
iptables -A INPUT -p tcp -s $AppSrv -d $IDS --dport 80 -m state --state
iptables -A OUTPUT -p tcp -s $IDS -d $AppSrv --sport 80 -m state --state
iptables -A INPUT -p tcp -s $AppHW -d $IDS --dport 80 -m state --state

41
iptables -A OUTPUT -p tcp -s $IDS -d $AppHW --sport 80 -m state --state
# Rules to block the unwanted traffic and log the details in /var/log/messages
iptables -A OUTPUT -p tcp -s $IDS -j LOG --log-prefix 'output blocked!' --log-level 4
iptables -A INPUT -p tcp -d $IDS -j LOG --log-prefix 'input blocked!' --log-level 4
iptables -A OUTPUT -s $IDS -j DROP
iptables -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
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

44
5.1.6 Snort rules webpage screenshots

51
5.1.7 Snort rules databank webpage screenshots

54
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:

55
"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 SSH
tcp AppSrv IDS HTTP
icmp 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"

56
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
iptables -A OUTPUT -p tcp -s $IDS --sport $SSH -d $TS -m state --state
# Rules for HTTP protocol:
iptables -A INPUT -p tcp -s $AppSrv -d $IDS --dport $HTTP -m state --state
iptables -A OUTPUT -p tcp -s $IDS --sport $HTTP -d $AppSrv -m state --state
# Rules for ping operations(ICMP protocol):
iptables -A INPUT -p icmp --icmp-type 8 -s $TS -d $IDS -m state --state
iptables -A OUTPUT -p icmp --icmp-type 0 -s $IDS -d $TS -m state --state
# Rules to block the unwanted traffic and log the details in /var/log/messages
iptables -A OUTPUT -p tcp -s $IDS -j LOG --log-prefix 'output blocked!' --log-level 4
iptables -A INPUT -p tcp -d $IDS -j LOG --log-prefix 'input blocked!' --log-level 4
iptables -A OUTPUT -s $IDS -j DROP
iptables -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.

57
CHAPTER 6: CONCLUSION AND
FUTURE ENHANCEMENTS

58
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.

59
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.

60
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

Engineering Internship Report - Network Intrusion Detection And Prevention Using Snort And Iptables

More Related Content

What's hot (20)

Similar to Engineering Internship Report - Network Intrusion Detection And Prevention Using Snort And Iptables (20)

More from Disha Bedi (20)

Recently uploaded (20)

Engineering Internship Report - Network Intrusion Detection And Prevention Using Snort And Iptables