Introduction to the basic approaches and issues of Intrusion Detection

1
IDIC – SANS GIAC LevelTwo
©2000, 2001
1
Network Based Intrusion
Detection Tutorial 1
Introduction to the basic approaches
and issues of Intrusion Detection
Hello! Welcome to the first half of our network based intrusion detection tutorial, where we will
introduce you to the basic approaches of intrusion detection. In this section, we will discuss a rule-
based analysis process by going through the topics listed on your next slide. At the end of the section we
will talk about some of the methods currently used to perform intrusion detection.
2
IDIC - SANS GIAC LevelTwo
©2000, 2001
2
• False positives, False negatives
• EOI, dictionary signatures, profile
changes
• Severity = (criticality + lethality) –
countermeasures (system + network)
• Long term conditions
Before We Begin
We will begin our discussion by talking about false positives and false negatives, which are ever
present factors in the life of an intrusion analyst. We will then discuss the notion of Events of
Interest (EOI), and their relevance to the event analysis process. We will also go over techniques for
judging the severity of a particular event. Additionally, we will propose a way to handle long term
conditions that might result from a prolonged exposure to attacks.
3
IDIC - SANS GIAC LevelTwo
©2000, 2001

3
Sources of Data
All data: observable or not
Collectable
Events of Interest
There are very few situations in which we are able to collect all the data. We need to develop
techniques that allow us to routinely locate Events of Interest (EOI) in the data we are able to collect, so
that we know where to focus our attention.
4
IDIC - SANS GIAC LevelTwo
©2000, 2001
4
False Positives and Negatives
False positives
False negatives
All Data
Real EOI
False positives are “false alarms.” The detects match only some of the criteria for indicators of possible
intrusion. False positives tend to wear down incident handling resources and make us slower to react in
the future.
False negatives are the actual intrusions and intrusion attempts that we do not detect. These can allow
an adversary to establish a significant presence in our information systems before we begin to react.
5
IDIC - SANS GIAC LevelTwo
©2000, 2001
5
What Are Events Of Interest
• Since we can’t collect, store, or analyze
all possible events, we focus our
collection efforts on stuff that might

prove useful, EOI.
– Dictionary: known attack signatures,
known attackers
– Short term significant changes in
system or user profile
The reality of limited computing and personnel resources is such that we cannot collect, store, and
analyze all possible events. Therefore, analysts tend to focus their collection efforts on events that
might prove useful – Events of Interest (EOI).
Unfortunately, focusing helps reduce the false alarms or false positives, but increases the chance of
missing an EOI. One of the ways to help ensure that an EOI is not missed is to compare suspicious
events against a dictionary of known attacks or attackers. You can’t afford not to test against a
dictionary!
Another way to widen our field of vision is to monitor for changes in system or user profiles. Consider
the following example:
You have noticed an increase in the number of probes and intrusion attempts at your site. DNS and mail
relay systems are always high profile targets, so you are watching them closely. You see a series of
FTPs at 5:30 A.M. Looking across three months history, there are no other FTPs. That is a short term
significant change in system profile.
6
IDIC - SANS GIAC LevelTwo
©2000, 2001
6
Attack Metrics
• Severity is defined by the criticality of
the target and lethality of the attack,
and the effectiveness of system and
network countermeasures
• Impact is calculated by the analyst
• Delays in detection and reaction can
increase severity and impact

• Long term condition: green, yellow, red
Story: ICMP D.O.S. and the new Captain
One day I found our network being pounded by an ICMP attack. The packets were coming in so
furiously I could barely read my console. I went to our new Captain, requesting permission to block
web traffic long enough to get the bandwidth I needed to put filters in place. His response was: “Tell
everybody to turn off their computers.” This over-reaction created a self-imposed denial of service at
the Naval Surface Warfare Center, compounding the severity of the situation.
With intrusion, we are not dealing with nature or randomness. We are dealing with deliberate actions
from rational people. Be wary of simply reacting as some ID products (and people) do. Metrics can
help you triage, which is why we will spend some time in the next series of slides talking about a formal
approach to assigning severity metrics to events of interest.
7
IDIC - SANS GIAC LevelTwo
©2000, 2001
7
Severity at a Glance
No Risk
Compromise,
Core System
Compromise,
Non-core
System
Risk
Recon
Probe
Non-targeted
Ineffective
Script Exploit
Targeted
Exploit

Are non-targeted exploits for vulnerabilities that do not exist within your computer systems actually
no risk? The question kind of reminds me of a Zen Koan: “if a vulnerability is never targeted, is it
really a vulnerability?”
When we study risk more formally, we will learn that part of the equation is our level of certainty,
how sure we are that none of our systems have the vulnerability. We tend to be on the conservative
side. In the examples that will follow, we consider non-targeted non-vulnerable exploits to be of no
risk only if they are also blocked by a firewall or a filtering router. In fact, there is a sense in which
this is negative risk. The attacker using a non-targeted script exploit against a well-secured site is at
a higher risk than the site, since they will be reported. If the attacker succeeds in breaking in and
doing damage somewhere else, the odds are at least fair they can be tracked down.
8
IDIC - SANS GIAC LevelTwo
©2000, 2001
8
Severity is best viewed from
the target(s) of interest POV
• Criticality of target (DNS Server)
• Lethality of attack (slammer)
vs.
• Known countermeasures
(firewall/system)
(Critical + Lethal) - (System + Net Countermeasures) = Severity
There are two questions we need to answer in Intrusion Detection. They are: “Am I OK for now; are
my defenses sufficient for the moment?” and, “Am I holding up well for the long term?” Severity is
an effort to provide a metric for the first question.
In a large scale attack, it is important to develop a process for triage, which attacks do you respond to
and why. The formula shown on the slide covers the primary dimensions you want to consider.
How critical is the system, how lethal is the attack, what countermeasures are in place?
9
IDIC - SANS GIAC LevelTwo

©2000, 2001
9
Severity: Criticality
•5 point scale
• 5 points: firewall, DNS server, core
router
• 4 points: e-mail relay/exchanger
• 2 points: user Unix desktop system
• 1 point: MS-DOS 3.11
If a desktop system is compromised, it is bad in the sense that time and work could be lost. Also, that
system could be used as a springboard to attack other systems. However, if an organization’s Domain
Name System (DNS) server or electronic mail relay is compromised, it is a much more serious
problem. In fact, if an attacker can take over a site’s DNS server, they may be able to manipulate trust
relationships and thereby compromise most or all of a site’s systems.
10
IDIC - SANS GIAC LevelTwo
©2000, 2001
10
Severity: Lethality
•5 point scale
• 5: attacker can gain root across net
• 4: total lockout by denial of service
• 3: user access, e.g.
sniffed password
• 2: confidentiality attack, e.g.
null
session
• 1: attack is very unlikely to succeed,
e.g., wiz in 1999
The lethality of an exploit is the likelihood that the attack will do damage. Generally speaking, attack

software is either application or operating system specific. A Macintosh desktop system isn’t
vulnerable to a tooltalk buffer overflow or an rcp.statd attack. A Sun Microsystems box running
unpatched Solaris might quickly become the wholly owned property of hacker incorporated if hit with
the same attacks.
For example, in 1997, the IMAP exploit virtually consumed unprotected Linux systems across the
Internet. A fragment of that code is shown below:
/*
* IMAPd Linux/intel remote xploit by
* 1997-April-05
*
* Workz fine against RedHat and imapd distributed with pine
*
* Special THANKS to: b0fh,|r00t,eepr0m,moxx,Fr4wd,Kore and
* the rest of ToXyn !!!
*
* usage:
* $ (imap 0; cat) | nc victim 143
*|
* +--> usually from -1000 to 1000 (try in steps of 100)
*
* [ I try 0, 100 and 200 - so1o ]
*/
#include <stdio.h>
11
IDIC - SANS GIAC LevelTwo
©2000, 2001
11
Severity: System
Countermeasures
•5 point scale

• 5: modern operating system, all
patches, added security such as tcp
wrappers and secure shell
• 3: older operating system, some
patches missing
• 1: No wrappers/allows fixed passwords
On the plus side of the equation, we have the countermeasures – the steps that we have taken to protect
ourselves from potential attacks. The first type of countermeasure that we will examine is system
countermeasures, which involve the security of the operating system. More points are awarded for
systems that are running a modern operating system, that are current with all patches, and are using
additional security measures such as TCP wrappers, secure shell, and personal firewalls.
12
IDIC - SANS GIAC LevelTwo
©2000, 2001
12
Severity: Network
Countermeasures
•5 point scale
• 5: validated restrictive firewall, only one
way in or out
• 4: restrictive firewall and some external
connections (modems, ISDN)
• 2: permissive firewall (the key question
will be, does the firewall allow the
attack through)
Consider carefully the difference between system and network countermeasures. The system
countermeasures are the last line of defense, if an attacker is able to penetrate network
countermeasures.
In your organization, what gets more attention, system or network protections? Remember, it is
always best to think of network countermeasures as noise filters, not silver bullets.

13
IDIC - SANS GIAC LevelTwo
©2000, 2001
13
Severity: Example
07/28/97 00:02:09 128.111.117.1 10143 -> 192.168.142.59 143
07/28/97 00:02:15 128.111.117.1 10143 -> 192.168.143.59 143
...
07/28/97 00:11:53 128.111.117.1 10143 -> 256.38.0.60 143
incrementing the third octet 0 - 255 up to host 64
Our hosts don’t run IMAP; the firewall blocks it. This
appears to be a non targeted probe or attack.
(Critical + Lethal) - Countermeasures = Severity
(3 + 4) - (4 + 4) = -1
Let us examine the severity of an event, which is documented by the trace on this slide. The attacker
seems to be scanning a number of hosts on the organization’s network for the presence of IMAP, which
typically runs on port 143.
The attacker is targeting a non-discriminate mix of hosts, mostly desktops and some servers, so
criticality is assigned the value of 3.
As for the lethality of the attack, this is potentially a lethal exploit, so we think 5? 4? We choose 4; the
system works as long as the numbers are close.
Not all targeted systems have patches, but we do not run IMAP (we hope), so system countermeasures
are 4.
Our firewall blocks IMAP, which allows us to assign the value of 4 to system countermeasures.
If we put it all together using the severity formula that we introduced a few slides ago, we calculate that
the severity of this event is: (3 + 4) - (4 + 4) = -1.