Intrusion Detection Systems (IDS)

• What is an IDS?– Definition– Characteristics– Examples of existing IDS

What is an IDS?

• Definition:– A piece of software– Monitors a computer system to detect:

• Intrusion: unauthorized attempts to use the system• Misuse: abuse of existing privileges

– Responds:• Log activity• Notify a designated authority• Take appropriate countermeasures

Why Use an IDS?

• Security is often expensive/cumbersome:– Cost

– Restrictions on users/functionality

• Designers try to offer users “reasonable” levels of security

• Security breaches will still occur

• Detection allows:– Finding and fixing the most serious security holes

– Perhaps holding intruders responsible for their actions

– Limiting the amount of damage an attacker can do

Goals of an IDS

• Run continually• Be fault tolerant• Resist subversion• Minimize overhead• Be easily configurable• Cope with changing system behavior• Be difficult to fool

– Minimize false positives and false negatives

Intrusion Detection Systems

• Three main components of an IDS:– Information source – provides a stream of event

records– Analysis engine – finds signs of intrusions– Response component – generates reactions

• What is the best information source for intrusion detection?

Information Sources

• Host-based– Operating System audit trails/system logs– Application information

• Examples: database audit records, web server logs

• Network-based– Network packets– Network devices

• Security appliances– Firewall– Access control system

IDS Characteristics

• Detection Model– Misuse detection vs. anomaly detection

• Scope– Host based, multihost based, network based

• Operation– Off-line vs. real-time

• Architecture– Centralized vs. distributed

IDS Detection Model

• Misuse detection - recognize known attacks– Define a set of attack signatures– Detect actions that match a signature– Add new signatures often

• Anomaly detection - recognize atypical behavior– Define a set of metrics for the system– Build a statistical model for those metrics during “normal”

operation– Detect when metrics differ significantly from normal

• Hybrid

IDS Scope

• Host based– Scrutinize data from a single host

• Multihost based– Analyze data from multiple hosts

• Network based– Examine network traffic (and possibly data from the

connected hosts)

Case Study: Tripwire

• A file integrity-checking tool– Developed at Purdue university (released in 1993)– Off-line, centralized, host-based, misuse detection– Utilizes digital signatures to check for added, deleted,

modified files– Popular

• Portable• Configurable• Scalable• Manageable• Automated• Secure

Background – File Systems

• Provide long-term storage for:– User data and programs

– System programs and databases

• A popular target for attackers:– Unauthorized access to user or system files to uncover private

information

– Modify system databases to allow future entry (e.g. SAM database)

– Modify system programs to allow future entry (e.g. back doors)

– Cleansing of system logs to thwart detection

Tripwire - Overview

• A checklist is created which contains one entry for each file being monitored

• Checklist should:– Be secure against unauthorized modifications

• Each entry in the checklist is a fingerprint for the corresponding file

• Fingerprints should:– Be efficient to compute– Be hard to invert– Depend on the entire contents of the file– Be very likely to change if the file changes– Be very unlikely to match fingerprints from other files

Tripwire – Overview (cont)

generate

New database

Config fileOld

database

compareApply masks

Report

Files residing on file system

Tripwire Database

• Unencrypted and world-readable• To prevent the database from being tampered

with, it is recommended it be:– Installed and updated in a secure manner (e.g. single-

user mode)

– Stored either:• On a read-only media

• On a write-protected disk

• On a “secure server” (e.g. read-only NFS)

Tripwire Configuration Files

• Contains:– A list of directories (or files) to be monitored– A mask for each that describes which attributes can change without being reported

• Mask bits (all fields stored in a file’s inode):– p: permissions– i: inode number– n: number of links– u: user id– g: group id– s: size of file– m: modification timestamp– a: access timestamp– [1-10]: signature #1, signature #2, etc.

• Signature algorithms supported (MD5, MD4, MD2, Snefru, SHA, CRC-32, CRC-16)

Tripwire Configuration Files (cont)

• Using masks:– Fields can be added (“+”) or subtracted (“-”) from the set of items

to be examined for a file– Example: +pinugsm12-a = report changes to all fields except

access timestamp

• Mask templates:– R = +pinugsm12-a = read-only files; only access timestamp is

ignored– L = +pinug-sma12 = log files; changes to file size, access time,

modification time, and signatures are ignored– N = +pinugsma12 = ignore nothing– E = -pinugsma12 = ignore everything

Tripwire Configuration File - Example

# file/dir mask

/etc R # all files under /etc are read-only

/etc/passwd N # ignore nothing

Tripwire - Overview

generate

New database

Config fileOld

database

compareApply masks

Report

Files residing on file system

Tripwire Reports

• New database is computed and compared with the old one

• Any differences are passed through the masks in the configuration file

• If not masked out differences are written to a report:

Changed: -rw-r—r– root 20 Sep 17 13:46:43 2012 /.rhosts

### Attr Observed Expected

### === ======= =======

m Fri Sep 17 13:46:43 2012 Tue Sep 13 20:05:10 2012

a Fri Sep 17 13:46:43 2012 Tue Sep 13 20:05:10 2012

Limitations of Host Based Intrusion Detection

• No global knowledge or context information

• Must run IDS on host being monitored– Does no scale– Overhead– Host compromise = IDS compromise

• Recovery options are limited

Snort

An open source, network-based IDS and IPSDetection:

Signature based Protocol based Anomaly based

Widely deployed “de facto” industry standardURL: www.snort.org

Snort - Overview

Goals are performance, simplicity, and flexibilityPerformance depends on:

Number of rules (detection signatures) Performance of the machine on which Snort is running Load on the network

Use libpcap promiscuous packet sniffing library for:

Packet capture Filtering

Snort Components

Packet DecoderTakes packets from different types of network interfaces (e.g. Ethernet, SLIP, PPP)Has subroutines that correspond to various network layers/protocols:

Data link layer Network layer (IP) Transport layer (TCP, UDP, etc) Application layer (HTTP, FTP, DNS, SMTP, etc.)

Annotates raw packet data by overlaying data structures Pointers into the packet data for later analysis by the detection

engine

PreprocessorsArrange or modify data packets prior to processing by the detection engineExample, detection engine contains a rule to flag the string “scripts/iisadmin” in HTTP packetsAttackers try to evade IDS by disguising malicious strings using:

“scripts/./iisadmin” “scripts/examples/../iisadmin” “scripts\iisadmin” “scripts/.\iisadmin” Uniform Resource Identifier (URI) hexadecimal characters or Unicode

charactersA Snort preprocessor module converts all these representations into a canonical form

Preprocessor Modules (cont)

Attackers try to evade IDS by fragmenting packetsExample:

Packet 1: “scrip Packet 2: ts/ii Packet 3: sadmin”

No signatures match because half the payload is in one packet while half is in a subsequent oneA Snort preprocessor module is responsible for defragmenting packets

Preprocessor Modules (cont)

Attackers try to evade IDS by manipulating the TCP data streamExample:

“scdef<bs><bs><bs>ripts/ijk<bs><bs>isade<bs>min”

No signatures match if the TCP stream isn’t reassembledA Snort preprocessor module is responsible for TCP stream reassembly

Preprocessor Modules (cont)

Attackers try to evade IDS by showing the IDS different data than what is seen by the end hostExample:

Packet 1 (TTL set to reach end host): “scrip Packet 2 (TTL set to be dropped one hop beyond the IDS):

ABCDEFGHIJKLMNOP Packet 3 (TTL set to reach end host): ts/iisadmin”

Detection EngineDetection is guided by a set of rules

Standard rule database available from Snort Can add custom rules

Rules can apply to: IP header fields TCP, UDP, ICMP header fields Application header fields Data

Rules are stored in a (chained) data structure to optimize matching

Two dimensional linked list

Rule Chain Structure

Chain Header

Dest IP = 192.168.78.100Dest Port = 80

Chain Header

Dest IP = 192.168.78.101Dest Port = 25

Chain Option

Content = “scripts/iisadmin”

Chain Option

TCP Flags = URG

Chain Option

Chain Header

Logging and Alerting

Logging options Store packets flagged by the detection engine in decoded,

human readable format to an IP-based directory structure (slow)

Store packets in tcpdump binary format to a single log file (faster)

Do not store packets (fastest)

Logging and Alerting (cont)

Alerting options Send to syslog Send to an alert text file (different formats) Send as WinPopup messages using Samba Discarded (during security testing)

Output Modules

Process log entries and alertsGenerate final output:

Logging to a database Generating eXtensible Markup Language (XML) output Etc.

Execute response actions: Modifying configuration on routers and firewalls Sending Server Message Block (SMB) messages to

Microsoft Windows-based machines

Snort Rules

Rules tell the detection engine: What patterns to match What to do with packets that match a given rule

Three basic directives: Pass – silently drop the packet Log – write the packet to the logging routine Alert – log the packet and generate an event notification

Snort Rules - Examples

• Record all traffic inbound for port 79 going to the 10.1.1.0 subnet:

– log tcp any any -> 10.1.1.0/24 79Detect attempts to access the PHF service on any of subnet 10.1.1.0’s web serversGenerate an event notification alertLog the packet– alert tcp any any -> 10.1.1.0/24 80 (content: "/cgi-bin/phf";

msg: "PHF probe!";)

Snort Rules - Structure

Every Snort rule has two parts:

Rule header (required) What action a rule takes Some matching criteria

• Rule options (optional) - Enclosed in parentheses Additional actions and matching criteria

Rule Header Rule Options

Rule Header

Seven fields:

Action (e.g. pass, log, alert, etc.)Protocol (e.g. IP, ICMP, UDP, TCP, etc.)Address – IP address specifying a single host, multiple hosts, or network addressPort – UDP/TCP source and destination portsDirection – specifies which address and port number is the source and which is the destination

Rule Header – Action Field

Basics – pass, log, alertAdvanced:

Activate Create an alert Activate another rule for checking more conditions

Dynamic Invoked by other rules using the “activate” action

User defined actions

Rule Header – Direction Field

A -> symbol shows that address and port numbers on the left hand side of the direction field are the sourceA <- symbol shows that address and port numbers on the right hand side of the direction field are the sourceA <> symbol means that the rule will be applied to packets traveling in either direction

Intrusion Detection Systems (IDS)

• An Intrusion Detection System (IDS) is a piece of software that monitors a computer system to detect:

– Intrusion (unauthorized attempts to use the system) and Misuse (abuse of existing privileges)

• And responds by:– Logging activity, notifying a designated authority, or taking appropriate

countermeasures

• Many different IDSs are available and they can be categorized according to their:

– Detection model (misuse detection, anomaly detection, hybrid)– Scope (host based, multihost based, network based)

• Tripwire (file integrity checking IDS)• Snort (network-based IDS)