Introduction to the basic approaches and issues of Intrusion Detection

Trang 1

Network Based Intrusion Detection Tutorial 1

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

Trang 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

Trang 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

Trang 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

Trang 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

Trang 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

Trang 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

Trang 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?

Trang 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

Trang 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

For example, in 1997, the IMAP exploit virtually consumed unprotected Linux systems across the Internet A fragment of that code is shown below:

* Special THANKS to: b0fh,|r00t,eepr0m,moxx,Fr4wd,Kore and

* the rest of ToXyn !!!

Trang 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

Trang 12

Severity: Network Countermeasures

Trang 13

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

Trang 14

Severity: Example

07/28/97 00:02:09 128.111.117.1 1014 -> 256.38.100.59 111

07/28/97 00:02:15 128.111.117.1 1014 -> 256.38.100.64 111

A subnet with Sun-based computers; the attack was picked

up on an internal logger, but it did not pass through the

firewall This appears to be a focused attack.

For which attack would you mobilize the Incident Handling team?

(5 + 4) - (4 + 2) = 3

Let us go through another example together In a different case, the attacker seems to be scanning our network of Sun-based hosts for the presence of Portmapper (port 111)

Criticality: this is a valuable set of targets with research data Basically, every country on planet earth

has taken a shot at these boxes at some point One target is a desktop, one is a server Because the targets are so important, the criticality is 5

Lethality: this is potentially a lethal exploit and is being delivered with accuracy since source routing is

involved This must be a follow-up to earlier successful reconnaissance and could be a setup forrpc.statd or any other RPC attack However, not all our Sun-based hosts are vulnerable Therefore, the lethality is 4

The systems that the attack is directed against are well administered and generally patched properly, so

system countermeasures are 4.

The firewall would block this, but a back door and source routing appear to be involved, which allows

us to assign a value of 2 for network countermeasures.

Adding this up, we have severity = (5 + 4) - (4 + 2) = 3

Trang 15

Impact per IDWG

Earlier in the course, we talked about the Intrusion Detection Working Group (IDWG) and its efforts

to define formats and procedures for information sharing between intrusion detection systems and components In their Intrusion Detection Message Exchange Format (IDMEF) specifications, IDWG

introduced the notion of impact, which is defined as the “evaluated impact of the event on the

system.” (http://www.silicondefense.com/idwg/draft-ietf-idwg-idmef-xml-02.txt)

The impact of the event, in the IDMEF sense, is somewhat different than its severity that we have

been calculating in the last few slides, since impact does not necessarily account for as many factors

of the event as our severity formula In fact, a better term would have probably been “evaluated classification” of the event instead of “evaluated impact” However, we learn to use the terminology

as it is If you can say “Smurf” and “Back Orifice” without embarrassment, how bad can “evaluated impact” be?

Trang 16

Severity and Impact: Example

Correlated statd exploit

Feb 7 02:07:47 marlin statd[343]: attempt to create

"/var/statmon/sm/; echo "ingreslock stream tcp nowait

root /bin/sh sh -i" >>/tmp/bob ; /usr/sbin/inetd -s

/tmp/bob &"

Key to Understanding: This is from a system log, so

keep in mind for your calculations that there are no

effective network countermeasures in place The system

does have all security patches installed, including statd.

What is the impact?

This attack was particularly effective against Solaris systems in the 1998 timeframe until a patch was released Below we have some correlating activity Note the first trace below is similar to the one on the slide; then we have a PortSentry alert Finally, we see a Snort log entry which shows that the same host has attacked Portmap itself

Apr 30 18:09:14 dns3 statd[166]: statd: attempt to create "/var/statmon/sm/; echo "ingreslock stream tcp nowait root /bin/sh sh -i" >>/tmp/bob ;

/usr/sbin/inetd -s /tmp/bob &"

Apr 30 18:09:27 dns3 portsentry[6017]: attackalert: Connect from host:

165.201.138.30/165.201.138.30 to TCP port: 1524

[**] IDS015 - RPC - portmap-request-status [**]

04/30-18:15:31.121104 165.201.138.30:980 -> z.y.w.34:111

UDP TTL:239 TOS:0x0 ID:64739 DF

Len: 64

39 05 6A 1A 00 00 00 00 00 00 00 02 00 01 86 A0 9.j

00 00 00 02 00 00 00 03 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 01 86 B8 00 00 00 01

00 00 00 11 00 00 00 00

Let’s consider the factors for our severity formula This seems to be a targeted attack, so the criticality

could be 4 The attack is pretty effective, if it takes place in 1998, so the lethality could be 4 The system is well patched and runs PortSentry IDS software, so the system countermeasures could be 5 Due to the lack of a firewall on the network, we will assign 2 to network countermeasures Of course, the exact values are somewhat subjective, and require detailed knowledge of the organization involved,

but our ballpark figures should be applicable in most situations As for the impact, the exploit was

meant to gain root access on the machine, so for the lack of evidence of successful penetration, we will assign the value of “attempted-admin” to this event

Trang 17

Severity and Impact: Your Turn

Telnet probe of mail relay

Three way handshake:

What do you think the severity of this event is? What about the impact? Could the attacker be collecting information for use later? Does the attacker succeed in transferring data to the mail server?

Here is our trusted severity formula:

(Critical + Lethal) - (System + Net Countermeasures) = Severity

Since the targeted system is a mail server, we can assume that the criticality value is pretty high The target is well patched and maintained, so there is a high degree of system countermeasures Network countermeasures are relatively low, since the mail relay is not screened for incoming packets

Lethality is pretty interesting in this case The three-way handshake is completed, so a connection is established Note that data is transferred from the mail relay to the attacker, but not the other way around What kind of information did the attacker receive? Most likely, the attacker is collecting banner

information from the server, such as its operating system version, possibly to better target a future attack

So the lethality of this particular event is probably not very high, though it does serve as a good indicator

of possible future activity

Tiêu đề	Introduction to the Basic Approaches and Issues of Intrusion Detection
Trường học	SANS Institute
Chuyên ngành	Computer Security / Intrusion Detection
Thể loại	tutorial
Năm xuất bản	2000

Định dạng
Số trang	34
Dung lượng	741,8 KB