Installing an Up
date open source IDS to monitor network security on a tightly
controlled Operating System
University of Colorado Colorado Springs
Network attacks, viruses, and malware are
prevalent across the internet today.
Organizations must monitor and detect these threats to ensure their data is safe from
accidental or malicious agents. One monitoring and detection engine put into place in many
organizations is called a Network Intrus
ion Detection System.
The purpose for building this
project and building an IDS was to find out what was going on inside the network aside from
what we already block on the firewall side.
This system can detect malicious activity, track
viruses, and moni
The system can be implemented a number of different ways,
but the most secure, in my opinion, is a system built upon a tested, production operating
system, and that has up to date code.
In any organization, information technology
s have a set of standards that are thoroughly tested before they are put into a
production environment. The reason they are tested is because they don’t know how the
software is going to react with the rest of the environment. There are compatibility iss
work out, security hole
s that may need to be patched,
and performance issues both on the
hardware and network side that need to be looked at. For the University of Colorado Colorado
Springs, this is no exception. We thoroughly test our software
nd hardware before we put it
into production. We do not tend to install beta software and perhaps can be a version behind
on some software updates except in the cases of security patches which are always up to date.
This paper is going to talk about the
steps that have been taken to ensure that a network
intrusion detection system (Snort) is installed on a thoroughly
tested, known to be compatible,
security patched information technology built image. This causes problems along the way
because some of the
software that is required of the NIDS is not standard for our base image.
There are plenty of pre
packaged appliances out there that can instantly install the software we
need, however they are typically not customized
based upon the organization
We’ll talk about the base operating system and what features it has on it
that we must have in any production system, the network intrusion detection system itself and
the installation process, and how we have tweaked our NIDS.
irst let’s talk about the operating system. The operating system that we have chosen is
CentOS The major version of CentOS, version 5.0, came out in 2007. The latest version of
CentOS is version 6.0, which came out July 10, 2011. The installation of Cen
tOS and the NIDS
took place the week of
June 20, 2011, when the latest version of CentOS was 5.6. The reason
we have chosen CentOS is because it is 100% binary compatible with Red Hat Enterprise Linux.
use CentOS because it is based up
on Red Hat Enterprise Linux. Red Hat
Enterprise Linux is thoroughly tested before it is released to market. Since Linux is open source
and there are many developers working on different packages that are included in Linux,
the base OS must be tightl
y controlled. Repositories of software may not include the latest
versions of software because they haven’t
been fully tested by Red Hat
to be included in the
release. Another reason
use CentOS is because it is free. Red Hat Enterprise
inux costs $50/year/license. If organizations have hundreds of servers, this could
add up to a
hefty expenditure. The repositories of CentOS and RHEL (Red Hat Enterprise Linux) include
many different software packages that are used for security and auditi
In any organization information security and auditing must be thought of first and
foremost in order to have a safe computing environment. Organizations such as UCCS develop
server images to
that base server operating systems are the same from installation
to installation and are compatible with their environme
nt, while maintaining strict access to the
server. UCCS includes many packages to ensure that security and auditing remain the same
rom server to server. While I cannot talk about exactly what is installed in the base image,
some components are standard such as log auditing packages, user access packages,
These packages help us control the server environment ag
attacks, accidental data breaches, and also help user access and control. All these packages are
standard and are available from the main CentOS and EPEL repositories. Customizing servers
can then be the challenging part since many packag
es that are offered do not come in a
repository or standard package or the packages are older and we need a newer version.
customizing a server to serve a specific purpose, the software that is installed may require
packages or binaries that are not
a part of any repository or may not be compati
ble with the
kernel of the operating system.
Such is the case with some of the packages needed for the
installation of Snort.
Snort is a Network Intrusion System (NIDS) or can be used as a Network Intrusio
Prevention System (NIPS).
Snort was created in 1998 by Martin Roesch and is still being actively
maintained today. One of the primary drivers why I chose Snort is because it has a large
community following and allows a user to integrate their own custo
m rules. Snort identifies
intrusions via signature matching, protocol analysis and anomaly based packet inspection. This
is key for an environment like UCCS where you must monitor protocol activity, intrusions based
off signatures and be alerted to anoma
lies in the network.
Since attacks on a network and
users are always changing it is best to keep up to date with the latest IDS/IPS signatures and
major Snort software
Snort’s latest version is at 220.127.116.11 which was released in April of 2011.
Version 2.9.0 was
released in September 2010 and changed the way packets are processed therefore resulting in
software requirements that were outside RHEL
like repositories. Snort version 2.9.0 introduced
the Data AcQuisition library for packet input and
output. The library replaces direct use of
older pcap libraries with an abstraction layer that makes it easier to add additional software or
hardware packet capture implementations. Basically it allows you to turn IDS into IPS without
recompiling. It al
so adds AFPACKET support which allows you to quickly turn the system into an
IPS without messing around with iptables and packet queues. While this new library helps with
packet processing, it requires that we use a libpcap library that is newer than the
libpcap in a RHEL repository. This means that we must download and compile libpcap on our
Before we start to download and recompile libpcap, let’s first remove the old libpcap.
yum remove libpcap libpcap
Next let’s start downloading the
packages necessary for the installation of libpcap and Snort
These packages are easy to install because they are a part of the RHEL repository.
yum install gcc gcc
c++ mysql mysql
While we’re at it, let’s also install packages that
will be necessary to look at our output of Snort
The following packages
are necessary to install for BASE, which is the web front end for viewing
and analyzing Snort
yum install httpd php mod
Now we need to download
the source code of all the other packages that we can’t
get via a RPM or via repository.
Now let’s configure a couple of
things before we actually start installing code. First we’ll need to
create a new user and group for all snort activities and files. We don’t want them running as a
groupadd snort useradd
Next we’ll need to configure the mysql database.
echo “SET PASSWORD FOR root@localhost=PASSWORD(‘xxxxxxxx’);
D snort <./schemas/create_mysql
echo “grant create,insert on root.* to snort@localhost” | mysql
ho “SET PASSWORD FOR snort@localhost=PASSWORD(‘xxxxxxxx’);
echo “grant create, insert, select, delete, update on snort.* to
snort@localhost” | mysql
We always keep downloaded source code in the same place so we can
Libpcap 1.1.1 source code
Data Acqusistion soruce code
Snort 2.9.0 source code
We’ll also need to download and install the rules for processin
g. There are 2 places I like
to get the rules. First is from Snort. These are 30 days old, but they still work.
have to register for them at
and then download them to another
machine and then scp them over to your snort di
Second is from Emerging
Both of these will unzip the files
in the /etc/snort/rules/ folder, except for the so_rules
which we need to copy over
since they are specific to the OS architecture
We now need to con
figure Snort where to look for these rules and add the emerging
Change the following lines:
“var RULE_PATH ../rules” to “var RULE_PATH /etc/snort/rules”
“var SO_RULE_PATH ../so_rules” to “var SO_RULE_PATH /etc/snort/
Add the following line past “Output”
output unified2: filename snort.log, limit 128
dd the following lines to the bottom of the file
dodb. Adodb is a database abstraction library for PHP. This is for use with BASE.
BASE is a front end GUI for reviewing Snort alerts.
mv base_conf.php.dist ba
Add the following lines:
$DBlib_path = ‘/var/www/adodb’
$DBtype = ‘mysql’;
$alert_dbname = ‘snort’
$alert_host = ’localhost’
$alert_port = ‘’;
$alert_user = ‘snort’;
$alert_password = ‘xxxxxx’
need to go to a web browser and continue the setup
Click on “Setup Page” then “Create BASE AG”
I really don’t want anyone looking at these alerts except me, so I
’ll lock it down with
c /opt/password/passwords base
You’ll be prompted to enter a password.
Next you’ll have to edit your httpd.conf file.
Add the following lines:
Require user base
Now restart Apache.
service httpd restart
processing to a separate process so that
snort can focus on processing packets
tar xvzf barnyard2
cp /etc/barnyard2.conf /etc/snort
chmod 666 /var/log/barnyard2
chown snort:snort /var/log/snort/barnyard2.waldo
Find and change the following entries
config hostname: localhost
output database: log,mysql, user=snort password=’xxxxxxxxx’
All we have left is to create the processes for starting Snort and Barnyard2. We’ll put these in
startup scripts in case the server dies.
We can now start the installation by typing in /etc/rc.local start
After Snort is running, we can see the interface by typing in
we must enter our username and password in that we created with htpassword. Then we’ll
come to a screen like this:
From here we can see all alerts that are coming through without looking through the logs.
e have collected the logs for a while we can start to tweak our installation of Snort.
There are two ways in which I have tweaked my installation. The first way is
suppressing alerts that are either too chatty and are false positives, or are alerts that I
don’t care about, meaning they are alerts that I don’t mind if they are
real or not. The problem
an IDS that is signature based is that it will produce quite a few false positives. These false
positives can easily be filtered out within the
threshold.conf file. The threshold.conf file is
located in /etc/snort/. We want to suppress findings, so the lines that we’ll put in look like this:
suppress gen_id 1, sig_id 16008
where 16008 is the
. We can also rate limit
alerts in this file as well.
The second way I have tweaked my installation is building my own
custom rule sets and networks.
Snort allows you to create your own signatures in the local.rules file located within
older. A user can always add more files, but they will just need to include
them in the snort.conf file for processing. Building custom rules is fairly straight forward. If you
know what you want to search for within a packet, you can create a rule with
alert tcp $HOME_NET any
> any $HTTP_PORTS (msg:custom message alert";
content:”content of the packet"; nocase; uricontent: "part of the uri
msg: What message do you want displayed
on the alert
content: What is the c
ontent contained with the packet that you are alerting for
uricontent: is there are particular
string that you are searching for within the URL
sid: this is the
unique signature id of the rule
must have a different sid.
Another aspect of
is the network (NET shown above). I have also created new
networks to monitor for different data in different places within our large
example, I only want to monitor for sensitive data in a couple different subnets, not the enti
a new network within snort.conf called
CC_NET. This is defined as
var $CC_NET xxx.xxx.xxx.xxx/24. I
the $HOME_NET string found in most of
with my custom $CC_NET network and Snort will only look f
or those signatures
and the network.
must be updated with new rules to keep up
with new threats. Overall it has taken weeks of tweaking to fine tune my Snort installation.
This will always be an ongoing process. In addit
ion to tweaking the system, you must also view
alerts and act upon those alerts.
A network intrusion detection system is only one piece of many in our security arsenal.
Catching viruses that antivirus can’t catch or botnets is one thing an IDS can do wel
you have to be monitoring your IDS for this information then act upon them.
monitoring security incidents from outside a system is the only way to truly know you have an
incident. The next phases of the project will be two
first phase will be to implement a
commercial IPS which will be in front of the open
source IDS. The reason for this is that I can
still create custom rules with the open
source IDS to monitor different network activity. It will
also help gauge how effe
the commercial IPS really is. The final phase will be to implement
a honeynet and create rules based upon known
All organizations need to know what is going on with their network. An IDS
excellent way of knowing what is going on with your network. It can help identify problem
areas within your network, such as systems with ports open that shouldn’t be, or it can help
identify where a rogue system is sending out massive amounts of s
pam. An edge firewall
cannot always block everything, so together with an IDS/IPS, your network is a little safer.