Intrusion Detection Systems

Intrusion Detection Systems

Francis Chang <[email protected]>

Systems Software Lab

OGI

The Papers

[1] M. Crosbie, B. Kuperman, "A Building Block Approach to Intrusion Detection"

[2] M. Wetz, Andrew Hutchison, "Interfacing Trusted Applications with Intrusion Detection Systems"

[3] Y. Zhang, W. Lee, "Intrusion Detection in Wireless Ad-Hoc Networks"

[4] G. Mansfield, K. Ohta, Y. Takei, N. Kato, Y. Nemoto, "Towards Trapping Wily Intruders in the Large"

A building Block Approachto Intrusion Detection

Let’s first look at the first paper…

[1] M. Crosbie, B. Kuperman, "A Building Block Approach to Intrusion Detection"

A new spin on how to build an IDS –

“..motors the system looking for misuse actions that are indicative of attack. These misuses actions are called building blocks.”

Need for a better data source for IDS (IDDS – Intrusion Detection Data Source)


Examples of building blocks:


Modification of a system file

Unexpected change user privileges of a running process

Modify log files

Change a global symbolic link

Creating setuid programs

So what did they do?

Build an in-kernel IDDS.


Crosbie/Kuperman argue that traditional IDS data sources are insufficient – let’s take a look at their argument.


syslogd:


Often a popular IDS data source

Often syslogd is used when a daemon “starts up, change configuration, encounter an error, or some other unusual behaviour occurs”

syslogd: (continued)


Crosbie/Kuperman argues that the quality of the log messages is completely dependent on the programmers who wrote the system daemons.

Early versions of syslogd could be attacked – buffer overflows, abnormal exits

Network Packet Traces:


If only using network packet traces, you often lose context, and thus, cannot detect certain types of attacks.

Why is an in-kernel approach good?


Time inside the kernel is “frozen”

In-kernel design is more resilient to attack

Interfacing Trusted Apps

The next paper - [2] M. Wetz, Andrew Hutchison, "Interfacing Trusted Applications with Intrusion Detection Systems"

This is funny:


The basic suggestion: Rewrite existing applications to take advantage of a syslogd/IDS system.


Intrusion Detection in Wireless Ad-hoc Networks

Open Medium – attacks can come from anywhere, an go anywhere

No clear topology – network is continually changing – no central points

The problem:

Intrusion Detection in Wireless Ad-hoc NetworksThe solution: An IDS at every node

Let’s take a closer look at the IDS…


Detecting Abnormal Routing Updates –

Give each IDS a built-in GPS, and watch for unexpected # of route changes. (Statistical analysis)


Detecting abnormal activities in other layers:

Various independent monitors to detect anomolies in other protocol layers, and combine results into a confidence rating.


Respond to intrusion detection by reconstructing the routing tables, and routing around the compromised node.

Towards Trapping Wily Intruders in the Large

G. Mansfield, K. Ohta, Y. Takei, N. Kato, Y. Nemoto, "Towards Trapping Wily Intruders in the Large"

The Basics: Monitor the network, and collect statistics. When the statistics deviate from “normal” behaviour, flag it.Extend SNMP to allow various networks to collaborate to track down the intruder


When a network is under attack, there is often a lot of suspicious network traffic – There are usually more:

TCP-RESET packets

ICMP echo & response

ICMP Destination unreachable messages


ICMP Echo:Often occur in high volume when a network is under attack:

Mapping out a network

DDOS attacks

SMURF Attacks – let’s take a look


1.1.1.1

1.1.1.2 1.1.1.3

2.2.2.2 3.3.3.3

SMURF Attack

Ping 1.1.1.255 from 3.3.3.3


1.1.1.1

1.1.1.2 1.1.1.3

2.2.2.2 3.3.3.3

SMURF Attack

Echo Reply Echo Reply


1.1.1.1

1.1.1.2 1.1.1.3

2.2.2.2 3.3.3.3

SMURF Attack

Many Echo Responses


TCP Resets:They do not occur too frequently in normal network traffic – but very often when a network is being attacked.Eg.

Port Scanning

Inverse Mapping – let’s take a look at this.


1.1.1.1

1.1.1.2 1.1.1.3

2.2.2.2 2.2.2.3ACK from1.1.1.2

Inverse Mapping (Successful routing)


1.1.1.1

1.1.1.2 1.1.1.3

2.2.2.2 2.2.2.3

TCP Reset



1.1.1.1

1.1.1.2 1.1.1.3

2.2.2.2 2.2.2.3

No Response



1.1.1.1

1.1.1.2 1.1.1.3

2.2.2.2 2.2.2.3ACK from1.1.1.4

Inverse Mapping (Unsuccessful routing)


1.1.1.1

1.1.1.2 1.1.1.3

2.2.2.2 2.2.2.3

TCP Reset



1.1.1.1

1.1.1.2 1.1.1.3

2.2.2.2 2.2.2.3


ICMP No Route to Host


So, now that we know what we’re looking for, how do we find it?

Let’s just use some simple math – isolate patterns with least-squares curve fitting, and find corelations between network traffic.

Towards Trapping Wily Intruders in the LargeTracing an attack


This system does not rely on specific types of attack/patterns/signatures, and does not attempt to reconstruct a detailed transaction log, relying only on statistics.

Can traceback the flow of the attack

Intrusion Detection Systems

Documents

Transcript of Intrusion Detection Systems