Tài liệu Intrusion Detection Patterns and Analysis ppt

Trang 1

Intrusion Detection Patterns and Analysis

Stephen Northcutt

Version 4.0You have learned a lot already, our job is to build on this foundation and help you become a combat readyanalyst

Welcome! I’m Stephen Northcutt from the Global Incident Analysis Center and in the next series of course modules we are going to cover some new material, but also begin to wrap up everything that you have learned so far In our course we will continue to develop your analysis techniques and in addition expose some new patterns and signatures You will notice as we work though the material that many of the detects we use have been contributed by GCIA graduates Though we operate a number of sensors and have access to a large data repository of intrusions, we need your help Without you, there is no way that we will be able to make sense of the normal and anomalous traffic

on the Internet Please remember to give a little bit back to the community, we hope that you will become an active participant on GIAC at www.sans.org/giac.htm The next few slides contain a number links that students have tried and feel are helpful

Trang 2

Frequently referred to URLS

DTK Deception Toolkit: http://www.all.net/

CIDF, http://www.gidos.org/ and http://www.semper.org/idwg-public/

Tripwire: ftp://coast.cs.purdue.edu/pub/tools/unix/Tripwire and www.tripwiresecurity.com/

SPI: http://ciac.llnl.gov/cstc/

Popular vulnerability scanner: http://www.nessus.org/

Phonesweep: http://www.sandstorm.net/

Trang 3

More URLs

• Coast ( http://coast.cs.purdue.edu)

• http://ipindex.dragonstar.net/

• http://packetstorm.securify.com/archive s.shtml

Trang 4

Roadmap - What we will cover

• Intrusion Detection First Principles

– Threat, Terminology

– Firewalls, Firewall Detect Analysis

– Interoperability and architecture

• Hacking From a Network

– Mitnick Attack

When you started this course, you began with some very technical material as we learned TCP and technical traffic analysis Now we are going to make sure we have the fundamental concepts, terminology and principles This will be a slightly easier section that some of the material you have been working on, so hopefully it will give your brain a bit of a rest Listed in this slide and the next are the key topics we will be covering in this course

Trang 5

• Network Based Intrusion Detection

Tutorial

• Intrusion Detection Using Traffic

Analysis Techniques

• Traffic Analysis Patterns Primer

• A large number of trace examples

Roadmap - What we will cover

In the end, we will turn the fact flow rate back up to fire hose mode and close with some additional training in traffic analysis and then review a large number of signatures

Well, time to get to it The first topic we will cover is known as First Principles We will start on the following slide, and finish in the next section At the end of each section we will have a quiz

We have seen a number of anomalous network traces in our previous courses, on the next few slides

we will take a close look at software that serves as a nice example of the kind of tool that attackers use to clobber our networks The network trace we will look at on the next slide is an example of a trace that is created by the attack tool we will be looking at

Trang 6

Please examine notes pages to see DNS lookup response from site

protected by “realtime” IDS This could tip off an alert attacker

This trace is an example of the Pepsi UDP flooder code The idea is to just send out UDP packets as fast as you can This particular attack takes advantage of the echo port for amplification and also to hide the identity of the attacker

Be certain to notice the source port and destination port, that will be important in our analysis Also, if you look closely at the additional data in your notes pages, you can see how long it took to trigger the real time intrusion detection system Pretty neat trace, isn’t it? Notice two sites are under attack Also notice that eventually this is detected by the IDS and a DNS lookup is issued Think through those DNS lookups carefully, since a clever attacker can log the lookup We often run with just the IP addresses

23:50:15.751821 doomer.echo > 172.2076.2.666: udp 426 (DF)

Trang 7

#define REGISTERED_TO "David, 7h4 LiGHT m4574h"

#define VERSION "Pepsi.c v1.7+OSM+LM"

is why your sensor is picking up this traffic

Why is the packet size designated as 1450? If you look at the previous slide’s output you notice that the UDP datagram data lengths are pairs of 1024 and 426? Combined they equal 1450, but why don’t we see datagram data lengths of 1450 When you are dealing with UDP, there are two factors that can determine that maximum datagram length First, the application interface such as written above designates a length But, the Unix kernel might limit this size as well We speculate that the Unix kernel on the host on which this was executed had a maximum UDP datagram data length of

1024 and that is why you see two packets generated of different sizes Or, perhaps the code that generated the trace on the previous slide was slightly different than the code shown here Who can say?

Trang 8

printf("\t Source, where packets are comming from.\n");

printf("\t Number of UDP packets to send.\n");

printf("\t Packet Size Default is 1450\n");

printf("\t Dest Port - Default is \n", DSTPORT);

printf("\t Source Port - Default is \n", SRCPORT);

printf("\t Wait time between packets - Default is 1\n");printf("\t Destination/Victim \n");

exit(EXIT_SUCCESS);

}

This slide shows the usage screen For most attacker code this is all the documentation that you get Note the attacker can override the default source and destination ports as well as other parameters When the attacker executes the compiled version of the code, and manages to get it to print out the usage, he/she is given the parameters that can be overridden to change the default execution of the program

Trang 9

if (srchost && *srchost)

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);

Constructing the packet

What this code represents is setting the fields of the actual IP datagram Once the datagram is

constructed it will be sent using system calls to be sent to the network

Some of the fields that have to be supplied in the IP datagram are shown; a resolution of source and destination hostnames to IP numbers has to be done to put them in the datagram Remember IP speaks

IP numbers not host names Next you see the version of IP is the current version of IP 4 The IP header length is assigned the value of 5 This metric is 5 32-bit words and since a byte is 8 bits, a word is 4 bytes So, the actual header length is 20 bytes which is normal Then you see an initial TTL of 255 assigned This gives the attack the maximum possible range, but also would help to serve as a partial signature You also see where this is constructed to have UDP as the embedded protocol Other fields are assigned as well, and then the data is formatted for the network Note that the source address is spoofed, but has a valid name since it is being resolved

There is a function executed above known as htons which converts the hosts byte order of data to the

network byte order This ensures that the source code will be portable to any host regardless of byte order

Trang 10

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);

}

Delivering the packet

This final code segment takes the datagram created in the previous slide, and attempts to send it to the socket interface The actual code is not much larger than this To date this has been a

characteristic of Denial of Service flooder code, small tight loops To summarize what we have seen, in this case we are able to match an actual detect in the wild with code found on an exploited system When possible, we prefer to use detects in the wild over laboratory created traces to make sure the course is as accurate as possible From time to time this will not be feasible, but we will make every lab created trace appropriately We looked at the definitions part of the program where default values were initialized We saw the usage screen which we pointed out is a hacker man page

We constructed the packet with the values we wanted it to have and finally we fired it out on the network This is the same type of software we commonly see in attacker code As we continue with first principles we will begin to consider the effects of firewalls and perimeters on anomalous traffic

Trang 11

First Principles Objectives

• Relationship of firewalls and firewall

policy to intrusion detection

• Introduction to the common intrusion

detection framework architecture

• Familiarity with issues related to push

and pull Be very skeptical of the

Over the years I have been fascinated by the evolution of firewalls My first experience was with the

“TIS Toolkit” This was a proxy based firewall, the software was freely available and fairly easy to read, at least the proxies were fairly easy to read Needless to say firewalls have become more complex, but also more removed from the user Today, the primary trend seems to be appliances, boxes that you put on your DMZ or internally, and as the name appliance implies, essentially forget them So what does any of this have to do with intrusion detection? Well, when I was teaching in Monterey in October 2000, I ran into three vendors that were all excited about their integrated intrusion detection and firewall developing products Depending on where they take the products this could be a wonderful trend since the firewall/IDS could have the ability to fake out the attacker with techniques similar to the Raptor firewall’s active defense In the following slides we will look

at firewalls a bit more, and also consider the architecture for intrusion detection

Trang 12

Firewalls and Intrusion Detection

• Firewalls perturb traffic – disrupt 3-way

handshake

• Firewall logs are still the primary

method of doing intrusion detection

• Consider the fidelity of the logging

when purchasing a firewall

It's nạve to assume that just installing a firewall is going to

protect you from all potential security threats Kevin Mitnick

September 2000

Firewalls are an important factor in intrusion detection More people use firewalls as their primary sensor than intrusion detection systems, if the reports to GIAC can be considered a guide If you are not factoring in your firewall logs to your analysis, this may be the time to start! It is critical to see how they perturb the traffic so you can understand what is actually going on We will show examples of this

Trang 13

INTERNET ISP

S

DMZ

DMZ (Demilitarized Zone),

is the area between an ISP

and the outermost firewall

interface

A sensor, or event detector, is used to instrument the DMZ

Firewall

Firewall as IDS Sensor

This slide shows a firewall with an IDS sensor A firewall is a pretty good sensor if and only if the packet is addressed to one of its interfaces Firewalls don’t care about the traffic on the DMZ; they only care about the traffic that they pass from the outside to the inside and vice versa Firewalls also tend to be TCP-centric which means that they miss a lot

If a packet tries to pass through a firewall that violates the policy, it will probably detect it

Trang 14

Alternate Definition DMZ

INTERNET ISP

Trang 15

DMZ

Getting the DMZ Thing Straight

This slide shows the most famous active DMZ in the world, the border between North and South Korea Take a close look at the picture and then notice the network architecture on the previous slide Which do you think is closest to a DMZ?

Trang 16

The firewall log gives us a fact, but we do not have enough

Information to interpret what is going on.

This is a soho firewall log

We might want to know why the firewall is blocking port 1880 Well that is simple enough, it probably has a deny all policy and simply doesn’t have a rule for 1880

But 1880 is a reasonable number for an ephemeral port, what if this is a SYN/ACK? This could be a response to something initiated from the inside, or, someone spoofing the address space of the computers inside There simply is no way to know Compare this to the next trace

Trang 17

This is a trace route This time we get additional information,

we get the source port as well as the destination port This

begins to create a picture

This trace is from a SonicWall firewall A system from the site went out to a web server and the load balancing technique used to trace back is a traceroute from multiple backbones The high number 33,400 range UDP is very typical of a traceroute The point of the slide, though, is to show an example of better firewall logging

Trang 18

A deny all except which is allowed makes a wonderful policy for

intrusion detection and security in general An allow everything

not specifically denied firewall policy makes site customized

intrusion detection very hard In either case, the firewall or

filtering router logs can and should be used as ID sensors.

Firewalls and Access Denied

Firewalls work! In fact, with a few caveats, filtering routers work quite well If a site adds internal firewalls then they are in much better shape

What is in a word :) Many analysts switch to call the attack attempts that do not penetrate the firewall “network detects”; this is a fairly good word We can then restrict the term intrusion to describe attempts that penetrate our defenses

If one denies all first and then adds back the things that are allowed by exception, then the odds of getting blindsided by an attack you didn’t know about, a service you didn’t know you were running,

or something that you did know about, but overlooked, goes way down This is certainly the recommended approach

Allow everything and then deny what you are afraid of is a risky approach, but may be necessary in organizations where freedom is valued above security, such as in research labs or educational institutions

Trang 19

A Day in the Life of a Cable

Dec 24 11:49:06 cc1014244-a kernel: securityalert: tcp if=ef0

from attacker6:1894 to victim on unserved port 12345

This is one of the best arguments for desktop firewalls that we have seen If you don’t think your home computer is being attacked while you are online, just look at the trace above The trace is truncated, on the slide, the rest is shown below Nine different attackers over a 24 hour period to this cable modem Trojans and PC-Anywhere seem to be the targets of interest

Dec 24 17:27:46 cc1014244-a kernel: securityalert: udp if=ef0 fromattacker8:2902 to victim on unserved port 5632

Dec 24 22:21:04 cc1014244-a kernel: securityalert: tcp if=ef0 from

Tiêu đề	Intrusion Detection Patterns and Analysis
Tác giả	Stephen Northcutt
Trường học	Global Incident Analysis Center
Chuyên ngành	Intrusion Detection
Thể loại	bài giảng
Năm xuất bản	2001
Thành phố	Unknown

Định dạng
Số trang	29
Dung lượng	514,02 KB