Low Cost Intrusion Detection
and Prevention System
Charles Beckmann, Anthony Magee, Vijay Iyer
Abstract—This Paper focuses on the creation of a Low Cost alternative for an Intrusion Detection System with
dynamic prevention.
Index Terms— Snort, IDS, Intrusion, Detection, Guardian, SnortReport, MySql
I.
Introduction
As we become increasingly reliant on computing and Internet access for our daily activities, the
exploitation of these systems so increases in both frequency and profitability to attackers. The very
same improvements in technology that serve to make our lives so much easier also place tools in the
hands of would-be attackers that have no real expertise. At this time, a complex and dangerous attack
such as a Dedicated Denial of Service (DDOS) can be accomplished by an average user, using software
readily available for free on the Internet. As system administrators and IT security personnel create
defense mechanisms to protect their assets from cyber attacks, attackers will likewise engineer more
creative and destructive attack methodologies. This cycle is unlikely ever to be broken, a consequence
of which is the addition of new network administration roles that focus entirely on network security and
intrusion prevention. No longer is checking for static signatures and blocking known attack vectors
enough – we need a defense mechanism that can detect attacks dynamically, without the constant
vigilance of a human observation. The need for such a system is evident in particular to this group, as a
machine at the VAST lab here at UCCS was briefly compromised by remote attack only weeks before
this project was assigned.
Many systems with this goal already exist, and have for years. The primary issue faced by network
administrators is the prohibitive cost of such solutions. Examples of such commercial Intrusion
Detection Systems (IDS) include Cisco Secure IDS, Dragon IDS, ISS Real Secure and Symantec
NetProwler. These systems can cost anywhere from $7,500 to $25,000 for each piece of equipment
[1]. Purchasing a commercial solution from one of the above providers may be appropriate for a large
organization with an equally large budget for network security, but smaller organizations are vulnerable
to attack as well. Smaller organizations need not house valuable data to make worthwhile targets for
attackers, as illustrated by several common uses of compromised machines:
•
Stealing bandwidth in which the attacker uses a foreign system to transmit data
•
Altering server-side data for their gain or another's loss
•
Vandalization of websites or other publicly viewable information.
•
Using the computer as a node in botnet in which the "infected" computer then performs
attacking tasks for the attacker autonomously.
•
File hiding in which the attacker stores his/her files on a compromised computer for various
reasons.
Fortunately, low-cost solutions also exist for smaller organizations such as the VAST lab. Our
goal was to construct a fully functional intrusion detection system using only commodity hardware and
open source software. The result has been a working IDS that incurs little or no network overhead, and
effectively detects and stops attacks. This paper describes the architectural layout of the system, the
decisions behind each piece of software, and the manner in which they are able to work together to
form a cohesive protection system.
II. Software
An open-source package called “Snort” is the main component of our design. It is a rule-based
IDS that analyzes incoming packets individually and can be configured to log data to multiple sources.
Snort is an open source piece of software originally written by Martin Roesh. Sourcefire currently
maintains snort. Our configuration logs Snort's data to standard Linux log files and to a MySQL
database. To configure MySql with snort we followed the directions in the file READMEdatabase.Debian found /usr/share/doc/snort-mysql. The instructions are quite explicit and enable those
not familiar with administrating a database to allow snort to use MySql. An example of what it
provides as directions is below :
For Mysql you can do this:
[ running as an mysql user with admin privileges ]
$ mysql
mysql> CREATE DATABASE snort
mysql> grant CREATE, INSERT, SELECT, UPDATE on snort.* to snort@localhost;
mysql> grant CREATE, INSERT, SELECT, UPDATE on snort.* to snort;
mysql> SET PASSWORD FOR snort@localhost=PASSWORD('snort-db');
mysql> flush privileges;
[ you can confirm the changes above running ]
mysql> show grants for 'snort'@'localhost';
And then you can run the command above as:
$ zcat create_mysql.gz | mysql -u snort -D snort -psnort-db
The problem with snort is that it produces a lot of data within its logs. Reading and analyzing
the logs by hand would prove quite a task to any system administrator. In order to analyze the data in a
more human readable format, we installed “Snort Report”, which is a simple web application written
PHP for parsing the data into logical blocks such as time frames, attack types, and IP addresses. It reads
directly from the Snort log files and so is updated in real-time[4]. An example of the report is shown
in the Figures Appendix. The report provides details such as number of alerts, sources, destinations,
the attack's signature and the severity level of the attack.
Configuring Snort thus far had allowed us to detect and view attacks in progress, but we needed
a means of updating the network’s firewall without intervention from the system administrator. The
final piece of the puzzle for this configuration is the Guardian Active Response package. Guardian is a
perl script that runs as a daemon and actively parses Snort’s log files as they are generated. When an
intrusion is detected, a script will be run to modify the firewall using IPTables, with the goal of
blocking the attacking traffic by port or IP address. Guardian was chosen due to its simplicity, and
compatibility with multiple firewall packages, including IPTables. Additionally, Guardian is able to
block ports and then unblock them after a predetermined period of time, allowing for better dynamic
response to individual attacks. Protection against an attack is important, but it is also important that the
IDS not compromise the functionality of the network for legitimate users. It should be noted that
Guardian suggests that Snort be run for a two-week trial period so that any inclination towards false
positives can be noted and excluded before automatic firewall modification is enabled [4].
This entire system is running on the Debian Linux distribution. Debian provides an easy
configuration, community support, and a small footprint. To block attacks, the VAST lab’s existing
router was used, running IPTables. The IPTables rules syntax is fairly simple making it easy to write
Guardian scripts to block potential intrusions. An example IPTables rule is below:
iptables -A FORWARD -p tcp -m tcp -s 0.0.0.0/0 -d <some IP> --dport 3306 -m
state
IPTables is supported by Guardian making it an easy choice. We added a rule to the firewall to
only allow connections from our IDS machine for changes to the firewall itself. This allows for a
secure model to dynamically block attacks as necessary, without compromising the security of the
router. The scripts guardian calls to block and unblock have to be install in /usr/local/bin and must be
named guardian_block.sh/ guardian_unblock.sh An example of the block and unblock scripts of
guardian are below:
block script:
#!/bin/sh
# this is a sample block script for guardian. This should work with ipchains.
# This command gets called by guardian as such:
# guardian_block.sh <source_ip> <interface>
# and the script will issue a command to block all traffic from that source ip
# address. The logic of weither or not it is safe to block that address is
# controlled by guardian itself.
source=$1
interface=$2
/sbin/iptables -I INPUT -s $source -i $interface -j DROP
unblock script:
#!/bin/sh
# this is a sample unblock script for guardian. This should work with ipchains.
# This command gets called by guardian as such:
# unblock.sh <source_ip> <interface>
# and the script will issue a command to remove the block that was created with # block.sh address.
source=$1
interface=$2
/sbin/iptables -D INPUT -s $source -i $interface -j DROP
Because Guardian uses standard shell scripts, any action can be taken, in addition to blocking
and unblocking ports in IPTables. This proves useful during debugging and testing of the system – for
example, rather than blocking an actual port, this could be simulated by appending the commands that
would have run to a file, allowing Guardian’s decision making process to be checked. In the case of a
particular type of attack or port, an email could be dispatched immediately to the system administrator
letting them know that a serious action has been taken.
III. Hardware
The machine running Snort is an older Pentium 4 with 1GB of ram. A second network card was
installed to allow it to sniff traffic on our network while retaining a standard connection to the internal
network. The only other piece of hardware added was a standard hub before the router to broadcast
traffic to our passive sniffing network card. While we could have easily installed Snort on an existing
machine we decided that due to the CPU overhead caused by Snort and the database it was best to use
dedicated hardware. This also demonstrated that the system can be set up with zero overhead using
inexpensive, used hardware. A high-level view of the network with the IDS installed is shown below in
Figure 1.
IV. The Setup
To allow Snort to sniff packets and remain transparent, we configured one of the machine’s two
network interfaces in promiscuous mode without an IP address. Because the hub repeats all the traffic it
receives to every outgoing port, the IDS machine sees all the traffic going in and out of the network.
The second network interface is configured with an IP on the internal network. This allows Guardian
to make changes to the router’s IPTables. The router was configured to allow connections from the
machine running Snort, so that Guardian can SSH into the router and run IPTables commands.
Figure 1: Network Design Flow
There are several important checks to ensure that the normal flow of network traffic is not
interrupted:
•
A quality hub must be used to ensure that collisions and drop packets are kept to a
minimum.
•
High quality cabling is required to lessen the chance of connectivity issues.
•
The hub must maintain the same uptime and power redundancy as the router or else it
becomes the weakest point in the network.
There are some advantages to installing multiple hubs and IDS machines throughout a network.
By configuring a similar system internally, internal traffic can be monitored for harmful traffic between
local computer systems. This can be helpful if the network is large enough that internal transmission of
viruses and other unwanted traffic is a potential problem. This could very quickly prevent large
amounts of malicious traffic from traversing your network and infecting or destroying the entire system
base.
V. Conclusion
As demonstrated by our appendix figures, the VAST lab network is being actively attacked.
While many are blind attacks targeted to vulnerabilities in software we do not run (notably the
Microsoft SQL exploits), there are also quite a few things like DNS spoofing attempts and port
scanning going on. Some of these exploits were detected by snort within seconds of activation. Any
network connected to the Internet is vulnerable.
This project has demonstrated that an effective intrusion detection system can be built and
configured exclusively using commodity hardware and free software. Not only is the cost of this
system minimal, but it is transparent to the users and incurs no network traffic overhead due to the
passive nature of the system. While this may not be the ultimate solution to dynamic attack response, it
does allow organizations with a limited budget to employ comparable defense against attackers to
larger, commercial solutions. Though this snort-based intrusion detection system has proven to be
effective, it can never replace the vigilance of a network administrator, as attacks are still possible,
even some that may attempt to exploit the IDS itself [5].
VI.
Future Research
Because this was a semester project, we had limited time and resources to build a stable,
reliable, and well tested system. However, we are pursuing more research, testing, and viability for this
endeavor. Some areas that we would like to further pursue are: staggered drop rates, QoS testing, a full
featured reporting system with a web front-end, and a web based control interface for monitoring and
manual control of the system.
The staggered drop rates we would like to implement will have several variable factors that
determine how, when, and where traffic can travel. Some of the controlling variables are:






Time of day.
Day of week.
Current network load.
Transmission protocol.
Requested transmission rate.
Nature of sources and destinations (server, wireless connection, remote machine location, VPN,
etc.)
A few examples for clarity are given here.
We want to limit our BitTorrent traffic during the day when the network load is higher and
other users need good connectivity and transmission speeds. We also want to deny all such traffic to
and from our servers because we are not serving any torrent files from them. We want to allow valid
torrent traffic to users and cannot completely lock the service out therefore we must devise some rules
for general user traffic. These rules might look something like this: max transfer rate 256KB/s, time
frame 9AM to 6PM Monday - Friday, maximum connections 10, deny use of known illegal sources
(censorship I know, but we've had one RIAA incident already and sometimes the users don't think
before they act).
We have several web servers that hold a good amount of data that while not a direct security
risk there is data that we want to protect. As many of these sites are public they are frequently attacked
by bots and sometimes experienced hackers. This is a fact we must live with and we cannot ignore the
risk. One way to provide some protection is to block specific IP addresses that implement known
attacks. This approach can be tailored to allow the offending party access to the website after a static or
dynamic period of time that can be designed to extend the blockage length with persistent attacks.
Because we are not using our servers to host data that is heavily relied upon by the public, i.e.
they are for research computing and storage, we are not really concerned about DoS or DDoS attacks
on our network. However we would like to know if such things are happening in quasi-real time and
would like to develop a system, web based, smart phone, or both, that can alert all the system
administrators in case of such an event. Some of the requirements for this system are:
 All transmitted traffic about the state of the system must be encrypted.
 Status alerts must have multiple, meaningful levels of severity.
 A simple configuration file must be maintained to describe contact information and
methodologies.
 Only senior levels of administration should have direct access to the configuration and the
daemon or machine itself.
 An automated system of identifying and marking false positives is desired.
In effect we want to build a dynamic and well documented system that can thwart most
attackers and be easily maintained. This can eventually, if developed correctly, be a packaged network
security system throughout the Linux community. While many components are well documented and
easy to setup individually, getting everything to work together took some trial and error to make work.
The setup is not always intuitive. For example setting up a network interface with no IP address but
still letting it capture all packets. If we could develop a total package installation that asked the
necessary questions for setup for less educated users it would be beneficial in getting more people to
adopt an intrusion detection system.
VI. References
[1] Angela Cearns, “Design of an Autonomous Anti-DDoS Network (A2D2)”. Thesis, University of
Colorado at Colorado Springs, 2003.
[2] "Guardian Active Response for Snort", General Configuration Reference. Retrieved May 15, 2009.
Available at: http://www.chaotic.org/guardian/
[3] Snort Documentation: http://www.snort.org/docs/
[4] “Intrusion Detection with Snort”, General Configuration Reference. Retrieved May 15, 2009.
Available at: http://www.linux.org/lessons/advanced/x370.html
[5] Jason Larsen and Jed Haile, "Understanding IDS Active Response Mechanisms". Symantec
Security Focus. Retrieved May 15, 2009. Available at: http://www.securityfocus.com/infocus/1540
Appendix: Figures
A snapshot of actual data captured by Snort. More details on the MS-SQL attack provided below
courtesy of Microsoft and Common Vulnerabilities and Exposures (CVE).