Co-Relating Alerts for Snort Intrusion Detection System
Introduction
Intrusion is used to describe attacks on a network or host from the outside; whereas,
misuse is used to describe an attack that originates from the internal network.
Intrusion Detection is the art of detecting inappropriate, incorrect, or anomalous activity.
ID systems that operate on a host to detect malicious activity on that host are called hostbased ID systems, and ID systems that operate on network data flows are called networkbased ID systems.
Intrusion Detection encompasses those techniques that seek to discriminate intrusion
attempts from normal system usage and alert the administrator. Typically, system audit
data is processed for signatures of known attacks, anomalous behavior, and/or specific
outcomes of interest. Intrusion detection, and particularly profiling, is generally
predicated upon the ability to access and analyze audit data of sufficient quality and
quantity.
The most common approaches to ID systems are statistical anomaly detection and known
pattern approach. In statistical anomaly detection any deviation from normal behavior is
considered intrusive. In the known pattern approach system vulnerabilities are based on
characteristics of known attacks and any action that conforms to the pattern of a known
attack or vulnerability is considered intrusive.
Snort is an open source network intrusion prevention and detection system utilizing a
rule-driven language, which combines the benefits of signature, protocol and anomaly
based inspection methods
Shortfalls with current IDS.
While the ability to develop and use signatures to detect attacks is a useful and viable
approach there are shortfalls to only using this approach.



Variants. Signatures are developed in response to new vulnerabilities or exploits
which have been posted or released. This must be unique enough to only alert on
malicious traffic and rarely on valid network traffic. However exploit code can
often be easily changed. It is not uncommon for an exploit tool to be released and
then have its defaults changed shortly thereafter by the hacker community.
False positives. Current Intrusion detection tools either generate lots of false
positives (i.e. signaling attack when there is none) or miss attacks. Even tools
based on attack signatures generate a large number of false alarms, in the most
unexpected cases.
False negatives …detecting attacks for which there are no known signatures. This
leads to the other concept of false negatives where an IDS does not generate an
alert when an intrusion is actually taking place. If a signature has not been written
for a particular exploit there is an extremely good chance that the IDS will not
detect it.

Data overload. Depending on the intrusion detection tools employed by a
company and its size there is the possibility for logs to reach millions of records
per day.
Need for co-relation:
One of the most obvious reasons why false alarms occur is because tools are stateless. To
detect an intrusion, simple pattern matching of signatures is often insufficient.
There are many events happening in the course of the normal life of any system or
network that can be mistaken for attacks. A lot of sysadmin activity can be catalogued as
anomalous. Therefore, a clear correlation between attack data and administrative data
should be established to cross-check that everything happening on a system is actually
desired.
Traditional intrusion detection systems (IDSs) focus on low-level attacks or anomalies,
and raise alerts independently, though there may be logical connections between them. In
situations where there are intensive attacks, not only will actual alerts be mixed with false
alerts, but the amount of alerts will also become unmanageable. As a result, it is difficult
for human users or intrusion response systems to understand the alerts and take
appropriate actions.
Consider the network intrusion caused due to a Distributed Denial of Service (DDoS)
attack. During a DDoS, the adversary usually launches attacks against the chosen victims
indirectly. Specifically, the adversary first probes a network to locate the “up”
hosts(phase 1). After determining which hosts are alive, the adversary breaks into some
of them, installs relevant tools (phase 2) and launches DDoS via these victims (phase 3),
which serve as the springboard of the attack.
In such a case tracing the true source through the alerts is infeasible and a large volume
of false alerts tend to be raised by an IDS. Hence, it is necessary to reduce the irrelevant
alerts and fuse related ones before they are presented to the administrators, which will
facilitate alert processing and ultimately improve the detection performance.
Various Approaches to Alert Co-relation
Our Approach
In the approach taken in our project, we decided to do Rule Classification in order to do
Alert Correlation. The rationale behind this approach is that all alerts are due to some rule
match in a packet. For an attack to be successful there have to be different stages, which
means multiple packets will be sent. Rules could be classified depending on the different
stages of the attack. For instance all alerts generated due to an ICMP echo request, or a
ping which leads to network discovery could be classified under one class. We decided
on the following Rule Classes:




Network Discovery
2 Scan for entry points
3 Information Gathering
4 Exploit
Snort Rules
Snort has some 3000 odd rules in its rules database. The information available with a rule
is typically as follows:


Message
DOS Land attack
Summary
A DoS attack known as Land has been launched. Some TCP/IP stacks crash or hang when sent
a spoofed TCP SYN packet with the same source and destination host and the same source and
destination port.
 Attack Scenarios
 Ease of Attack
 False Positives
 False Negatives
 Corrective Action
nmap –sS –O 172.26.1.0/29
There are three distinct phases with the above nmap command. They are:
1) Host discovery
2) Port scanning
3) OS fingerprinting