Search

Understanding IDS for Linux

Do you feel your network is safe? Do you
really know what is happening on your network right now? Once upon
a time, there were network administrators who thought that the
solution to their security was a simple firewall. In the past few
years, we have verified that this is not true anymore. The need for
some element that could alert and inform administrators about
something strange in near real time resulted in intrusion detection
systems (IDSes). In this article we discuss the types and models of
IDSes: the host-based intrusion detection system (HBIDS), the
network intrusion detection system (NIDS) and the new concept of
hybrid-IDS. How to analyze the data generated and how to create
signatures (the patterns that identify the attacks) also are
discussed, as well as some examples of IDSes for Linux, like the
open-source NIDS Snort.

What Is an IDS?

An IDS is a program that tries to detect strange packets and
behaviors that may compromise a network. The first IDS was the
host-based IDS, but the one that really got the market was the
NIDS, the network-based. There is usually some software or
appliance, called a sensor or agent, that has one or two network
interfaces (as we will see later, it may work perfectly with one
network interface), which works in promiscuous mode. In other
words, it will catch all the packets that come to the interface and
not just those with its particular destination IP address. In this
way, the IDS can analyze all the packets that cross the network,
check if they contain, for example, any suspicious strings and then
decide how to perform a reaction, such as interacting with the
firewall to create new rules to block the IP address, sending
pager/e-mail alerts to the security administrator and so on. One
important topic about the NIDS is where to deploy the sensor,
inside or outside the firewall. I like to quote an interesting
passage about this from SANS' GIAC Director Stephen Northcutt's
book, Network Intrusion Detection: An Analyst's
Handbook:

An IDS before the firewall is an Attack detection
and after the firewall is Intrusion detection....In a switched
network, since we don't have broadcasting, we have two better
options on deploying the NIDS, using a hub to force a broadcast or
using a mirroring-port in the switch.

Where is the best place? We may have a long discussion about
this since there are defenders of both points, but undoubtedly all
agree that the best option is the use of sensors inside and outside
the firewall.

IDS Models

To understand the IDS better, first we need to know how it
works. Basically we have two models of IDSes: the misuse or
signature-based model and the anomaly model.

The misuse or signature-based is the most-used IDS model.
Signatures are patterns that identify attacks by checking various
options in the packet, like source address, destination address,
source and destination ports, flags, payload and other options. The
collection of these signatures composes a knowledge base that is
used by the IDS to compare all packet options that pass by and
check if they match a known pattern. Later we will discuss a Nimda
worm signature example in the Snort IDS.

The anomaly model tries to identify new attacks by analyzing
strange behaviors in the network. To make this possible, it first
has to “learn” how the traffic in the network works and later try
to identify different patterns to then send some kind of alert to
the sensor or console. The disadvantage of this model is that you
will never know if your network has produced all types of behavior
in the IDS learning phase, so it may cause a high number of
false-positive alerts.

False-positives are false alerts produced by the IDS to
inform of an attack when in fact it is just nonconfigured variables
or an application that sent some packet to a different port than
usual, instead of a real backdoor, for example. To solve this, the
security administrator has to observe the alerts generated by the
IDS for some time and then fine-tune it.

Host-based intrusion detection systems usually are located in
servers and only detect events related to the machine in which it
is installed. The main purpose of the HBIDS is to avoid changes
that may compromise the machine and detect malicious queries.
Examples of changes that can prove the importance of this kind of
IDS are web defacement and rootkits installed in the machine to
attack other machines.

Rootkits are packages installed in the compromised machine by
the cracker, which contain files used to open backdoors, erase log
files to hide their presence and replace binaries like ps and
netstat, and also hide any dæmon or open port.

Besides this, the HBIDS has the function of trying to detect
attacks before they happen, analyzing logs to point out strange
behaviors and also detecting port scans.

Tripwire

Tripwire is an example of an HBIDS for Linux [see Michael
Rash's Paranoid Penguin, LJ February 2002 for
an open-source alternative to Tripwire]. It can be identified as an
HBIDS because it fills in for the lack of file-integrity detection
tools. With Tripwire, the user can define, in a configuration file,
a set of files that he or she wishes to protect against changes,
and then Tripwire uses a checksum of these files and attributes. In
the case of any changes, it can send alerts to the system
administrator. The default configuration file provides a good
starting point, but the user also must customize it to reduce the
chance of false positives. Pay special attention to the log files.
It doesn't make sense to include the log files into the set of
files that you select to be checked, since you know that they will
grow as soon as any event happens, such as a login.

Tripwire can be used together with the cron scheduler
dæmon. In this mode, users can automatize the process and
define wherever they want to run it.

PortSentry

PortSentry [see also “PortSentry” by Anthony Cinelli on the
LJ web site,
/article/4751]
is part of the Abacus Project, from Psionic Software, whose goal is
to “produce a suite of tools to provide host-based security and
intrusion detection free to the internet community”. It is an
important kind of HBIDS because it detects packets addressed to the
host and can be used with TCP Wrappers and iptables. This type of
detection is useful because a port scan is often a precursor to an
attack. PortSentry can detect TCP and UDP port scans, making you
aware of other hosts that run a service in the scanned port. The
next step is to verify for new patches or updates, or even
configure it to create ACLs (access control lists) to block future
connections from the host scanner, using TCP Wrappers. It also can
create rules in the firewall, i.e., iptables, to drop everything
from the host scanner. The following is an example of PortSentry
alerts from Syslog:

Swatch is a log watcher that observes the logs and alerts the
security administrator about predefined strings found in the log
file, i.e., /var/log/messages. In the example below, I created a
very simple Swatch configuration file and chose to define the
strings “snort” and “portsentry” and send the alert to screen
in different colors (and with a beep) every time that it finds
these strings:

watchfor /snort/
echo red
bell
watchfor /portsentry/
echo blue
bell

I also could ask Swatch to send an e-mail or execute a
command when it finds something. As the result of the previous
Swatch config file, I received these alerts:

LIDS stands for Linux intrusion detection system. It is a
project that tries to give Linux some extra security features
deployed as kernel patches. In these features we can include file
and process protection and port-scan detection. The first two
deserve a little more explanation. File and process protection will
guard even against root superuser changes. This is very useful
because when a cracker exploits a bug in your system, such as a
buffer overflow, that person will have root access that permits him
or her to do almost anything, such as install rootkits, change
logs, erase your HTML pages, etc. With these features you can
define ACLs to control files and include passwords to access/change
them, avoiding changes from unauthorized users, even root. The same
is valid for process because it will protect your system from
altered binaries/dæmons. Another good feature is that it
offers a port-scan detector in kernel space.

NIDS

Network intrusion detection systems are the kind of IDSes
responsible for detecting attacks related to the network. One point
of discordance is where it should be deployed. You may encounter
network topology where it is before a firewall, and you may find it
after a firewall. As I said before, there are good arguments for
both; it depends on your needs. In these examples I will use the
open-source Snort.

Snort

Snort was created by Marty Roesch and currently has over
1,000 rules used to detect attacks like simple port scans and even
new attacks such as the SSH CRC32 exploit [see “Snort: Planning
IDS for Your Enterprise” by Nalneesh Guar on the
LJ web site at
/article/4668]. One of the
greatest advantages of Snort is its flexibility to create new rules
on demand. Whereas with some IDS vendors you have to wait until
they release new packages, you may customize and create signatures
as soon as the attacks are exposed. One good example was the
wu-ftpd exploit in mid-December 2001. Just a few hours after the
release of the exploit, the Snort filter was released on security
mailing lists. Snort also has the capability to interact with
firewalls, i.e., Check Point FireWall-1, using the OPSEC feature or
using other plugins to interact with Linux's iptables. Besides the
fact that Snort has a large signature database and is mainly based
on the misuse model, it offers a beta feature to introduce it to
the anomaly model. This feature, called SPADE, does a statistical
analysis of the data it gathers and tries to find out what the
ordinary behavior is. As with many open-source applications, Snort
has a lot of additional applications that you may want to use
together.

One nice application from Silicon Defense is SnortSnarf,
which creates HTML reports based on the data gathered by
Snort.

Snort also works perfectly well with just one network
interface card (NIC). Instead of other NIDSes, which need two NICs,
one to gather the data and other to be used by the administration
interface, Snort can work with one NIC in the promiscuous mode and
also can be used to administrate it, inserting new rules or
upgrading it.

Hybrid-IDS

More recently, another concept of IDS is becoming popular. It
is the hybrid intrusion detection system. Marcus Ranum, founder of
NFR (Network Flight Recorder, Inc.), wrote that “The shim-type
hybrid IDSes are an interesting blend of the strengths and weakness
of HBIDSes and NIDSes.” This means that it has most of the
features of the NIDS but on a per-host basis. This has a lot of
advantages, as it will try to detect attacks to the host
exclusively, and the traffic that it will analyze will be only
packets with the host destination IP address. The disadvantage of
this kind of IDS is that it needs to be deployed in every
host.

Prelude-IDS

Prelude is an example of a hybrid-IDS. It is divided into two
different parts: the sensor, called Prelude NID, that is
responsible for the packet capture and analysis, and the report
server, used by the sensor to report an intrusion attempt. Prelude
has an interesting feature that deserves some comments: the
capability to read rules from Snort IDS. In other words, it has a
complete rule set ready to use. From its web site, it is also
capable of reading rules from any NIDS. Prelude was built with the
cluster concept in mind. This explains the idea of deploying
information into a different machine called a report server, which
has the job of translating all the information received into a
user-friendly format, such as HTML.

Understanding and Creating Signatures

As we learned before, signatures are attack patterns. It's
important to understand how they work, so we can create them
on-demand or when a new exploit is discovered. In our examples, we
will see how Snort handles its signatures. In the second half of
2001 we observed new and powerful worms on the Net, such as Code
Red, Code Red II and Nimda. When these attacks started to happen,
Linux users (and I was one of them) felt very lucky because the
worms mainly were attached to Microsoft's IIS (Internet Information
Server). These worms had some particular patterns, for example,
trying to access the cmd.exe file through Microsoft's IIS. By
knowing this, we easily could create a Nimda Snort rule as
mentioned in the section “IDS types and Models”:

Okay, but what does it mean? Snort rules are nothing more
than sequential parameters divided in two sections that we use to
inform Snort of what we want it to pay attention to. The first
section is called rule header and includes everything before the
first brackets. The first parameter in this header tells Snort what
to do when the packet matches this rule—in this case, “alert”
indicates that Snort will generate an alarm and then log the
packet. The second parameter tells Snort what kind of protocol we
want—in this case, just TCP. The next five parameters indicate the
source IP address and port, direction of the packet, destination IP
address and port. In this way, we know that a packet from any
address outside of our network, with any source port, going to an
IP address in our internal network at port 80 (usually web servers
listen to this port) will be checked by the internal parameters of
the rule, called rule options. The rule option section contains
alert messages and information about which parts will be checked in
the packet, and then with the result of this inspection, the
appropriate action will be taken.

Rule options in our example:

msg: “WEB-IIS cmd.exe access”—description of the alert.

flags: A+—logical operator (+) to test all flags in the packet.

content: “cmd.exe”—sets the specific content (cmd.exe) in the packet payload.

nocase—will match the specified string with
case-insensitivity.

classtype: web-application-attack—classification
of the alert.

sid:1002—Snort rule ID.

rev:2—rule revision number.

In the Snort Users Manual you can find
more than 30 rule options that you can use to satisfy your needs.
Too complicated? No, it is not! Let's try to create a simple rule
to alert any porn web access attempt from your network using the
few rule options above:

Learning how to interpret log files is one of the most
important things that an intrusion or security analyst must learn
in order to decide what action to take in a given situation. The
excerpt from the PortSentry alert above was obtained from the
syslog file. This alert states that on December 9 at 03:03, the
host called flamengo, which has PortSentry installed, detected an
SYN-flag Normal port scan in the TCP port 111 which, in general,
runs the service portmap, from host IP 200.185.61.132.

Conclusion

A firewall is a primary security element in a network, but it
will not detect attacks on a service that is already opened, such
as an attack to your DNS or web server. An IDS by itself will not
solve all your problems as a security element, but if you customize
it for your needs, it certainly will help alert you to strange
behaviors and unauthorized attempts to your host or network. With
this information, you should contact the administrator of the
network in which the intrusion's IP is located and then inform them
of what is going on. Being in contact with the security community
is also the best way to keep up to date on new attacks and the
signatures to detect them. Be aware—install an IDS!

Pedro Bueno
(bueno@ieee.org) is a
former data engineer from Lucent Technologies and currently is a
security engineer at Open Communications Security. He also
contributes at Best Linux as a volunteer, and his favorite hobby,
besides soccer, is analyzing the alerts generated by Snort.