Tài liệu Intrusion Detection Patterns doc

Trang 1

Patterns

Please send patterns to intrusion@sans.org

Those who do not know history are doomed to repeat it!

Welcome back We are getting ready to enter the final, major section of this intrusion detection course From here on out, we will be examining a number of intrusion detection signatures dating back as far as 1997 One of the things that is unique about this collection is that almost every pattern

is a bonafide detect from the wild, as opposed to lab created signatures There are a couple of exceptions to this; each of them is included for a reason and will be noted as an exception on its slide

Trang 2

•A Word of Warning

•Denial of Service Attacks

•Network Vulnerability Scanning

Even patterns that are not added to the main course can be kept in an appendix in case they are ever needed by an analyst Well, let’s get started The first section we will cover is common errors Your next slide is titled A Word of Warning

Trang 3

A Word of Warning

Certain patterns tend to be commonly

misinterpreted As an analyst,

strive to have the highest possible

degree of accuracy One day, you

may have to make a tough call and you

want as much credibility as possible.

It is OK to make a mistake Well, it had better be, because each of us will Granted, the mistake many analysts make is to hide their heads in the sand and ignore what is happening and keep their mouths shut and then later claim to know what is going on

This is not the philosophy we teach We have and will continue to share a number of stories with the goal of helping you see the process that we have gone through to attain the level of knowledge we have today Of course, we have made a number of mistakes For a given pattern there may be more than one possible interpretation; in fact, we will see this as we move through the material A good analyst knows how to play the odds and also when to question the accepted answer A good analyst also knows how to avoid the common errors

In this next section we will discuss some common errors If you will allow us to take a page from the Shriner’s mottos, “We screw up beyond all belief so you don’t have to.”

Trang 4

UDP “High Port Scan”

"209.67.29.9" "my.net.100.100" "udp" " len 64"

Correct analysis: F5Labs traceroute variant

This pattern is often mistaken as a UDP high port scan; please see the analysis by Ron Ryan, GCIA Port

33434 is the first port used in a UDP traceroute - see the IANA port assignments located at

http://www.isi.edu/innotes/iana/assignments/port-numbers Normally when a traceroute is performed, the destination port number is incremented on each attempt The first packet sent will use destination port 33434 and have a TTL of 1 The first router that receives the packet decrements the TTL value to 0, which causes

an ICMP time exceeded error The second and third packets will also have a TTL of 1, and they will use destination ports 33435 and 33436 The next three packets sent by traceroute will use a TTL value of 2 and destination ports of 33437, 33438 and 33439, respectively This activity will continue with the TTL values being decremented at each intervening router As the initial TTL values increase, the packets get through more routers before the TTL is decremented to 0

Assuming that you don’t know the TTL value, the destination port is normally a good indicator of how far away the tracing host is The larger the value, the more hops that have taken place You won’t normally see

a traceroute packet with a port value of 33434 that gets to your firewall Intervening routers will have caused traceroute to increment this value on each successive attempt

There are a number of products on the market today, from companies like Cisco, Resonate, Nortel, F5LABS and GTE, that perform distributed load balancing F5Labs’ 3DNS, GTE Hopscotch, Resonate Global Dispatch, and Cisco’s Distributed Director are all capable of performing load balancing across multiple Points of Presence, or POPs The hop count mechanism is a method of mapping the best route from the

Trang 5

Back Orifice!!!

(31337 is a default destination port for BO)

11:20:44 ns1.com.31337 > ns2 arpa.net.53: 38787 A? peoarbs.arpa.net (34) 11:52:49 ns1.com.31337 > ns1 arpa.net.53: 39230 ANY? hq arpa.net (36)

Keys to Understanding

A? is a request for an IP address, the most common DNS query.

ANY? is a request for all records; this is similar to a zone xfer.

(36) or (34) is the size of the payload All of this matches the

expected format of a DNS query It walks like a duck, quacks

like a duck, probably isn’t BO!

Historically, DNS server to server communications tended to come from port 53 and be addressed to port 53 This is no longer the case BIND 8 will simply choose a port above 1024, a non privileged,

or non assigned port One could also set the port for the DNS server to any arbitrary number In this case, the port was set to 31337, which upset some network defenders that were concerned it was Back Orifice

From a traffic analysis standpoint, you know it is not BO For one thing, we are looking at source port 31337, not destination port 31337 However, 31337 is a great pattern to look for!

There are more clues here In the traffic analysis section, we learned to give some credence to where the packets are coming from Here we see nameserver nomenclature We can verify this is actually

a registered nameserver pretty easily Of course, that doesn’t preclude someone from compromising

a nameserver and using it for nefarious purposes In this case we simply called the owner of the system and he explained that he had chosen 31337 and was getting a lot of criticism for the choice

By the end of the phone call, he had decided that he probably wanted to make a change

Trang 6

Ftp99cmp Win Trojan

[**] FTP99cmp [**]

04/09-23:18:35.467634 151.164.1.8:53 -> 208.188.225.121:1492

UDP TTL:246 TOS:0x0 ID:35890 DF

Len: 175

07 11 81 80 00 01 00 01 00 02 00 02 03 32 32 35 225

03 31 38 38 03 32 30 38 07 69 6E 2D 61 64 64 72 .188.208.in-addr 04 61 72 70 61 00 00 06 00 01 C0 0C 00 06 00 01 .arpa

00 00 1A F3 00 31 03 6E 73 31 06 73 77 62 65 6C 1.ns1.swbel 6C 03 6E 65 74 00 0A 70 6F 73 74 6D 61 73 74 65 l.net postmaste 72 C0 3A 0B EA 5F 5A 00 00 0E 10 00 00 03 84 00 r.: _Z

09 3A 80 00 00 0E 10 C0 0C 00 02 00 01 00 00 1A :

F3 00 02 C0 36 C0 0C 00 02 00 01 00 00 1A F3 00 6

06 03 6E 73 32 C0 3A C0 36 00 01 00 01 00 00 1C ns2.:.6

20 00 04 97 A4 01 01 C0 81 00 01 00 01 00 00 1C

20 00 04 97 A4 01 07

Older BIND 4 server to server communications used source port 53 Some poorly implemented perimeter systems allow anything with source port 53 through This false positive also shows the danger of detection on a single packet as opposed to watching the whole stream According to one

of the GCIA students, FTPcmp99 opens up an FTP server on your Windows 95/98/NT system The FTP server registers itself under the key:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run

Obviously the default port must be 1492 So this is wired into a Snort rule, and it lights off when it sees this packet

The analyst takes one look at the asciification on the right and says, hmmm, source port 53 to 1492

1492 is a perfectly reasonable ephemeral source port This could be a DNS response, not a stimulus Judging from the fact that it looks like a DNS reply duck and quacks like a DNS reply duck, the analyst prefers this answer to the possible trojan

Trang 7

Is this a stimulus or a

response? (1)

07:17:09.615279 mysystem.echo > target1.24925: udp 64

07:17:10.978236 mysystem.echo > irc.some.where.40809: udp 60007:17:11.001745 mysystem.echo > irc.some.where.14643: udp 60007:17:11.146935 mysystem.echo > irc.some.where.49911: udp 60007:17:12.254277 mysystem.echo > irc.some.where.28480: udp 60007:17:12.350014 mysystem.echo > irc.some.where.20683: udp 60007:17:12.835873 mysystem.echo > target1.5134: udp 64

07:17:13.266794 mysystem.echo > irc.some.where.16911: udp 60007:17:13.862476 mysystem.echo > target1.32542: udp 64

07:17:14.032603 mysystem.echo > irc.some.where.32193: udp 60007:17:14.579404 mysystem.echo > irc.some.where.24455: udp 60007:17:14.619173 mysystem.echo > irc.some.where.5120: udp 600

07:17:14.792983 mysystem.echo > irc.some.where.47466: udp 60007:17:14.879559 mysystem.echo > target1.16878: udp 64

07:17:15.308270 mysystem.echo > irc.some.where.12234: udp 600

This is a tough one; in fact, we are going to use two slides to do this one First, let’s introduce the problem If one of our most powerful tools is sorting by stimulus or response, what do we see on this slide? Is this a stimulus or a response? The wise analyst might answer “maybe.” What do we know about this?

• One way dataflow from mysystem’s echo port to IRC

• The timing is pretty quick; we are sending packets quickly

• In terms of Size does matter, we have two flavors of packets, 600 and 64

• We are hitting random ports on IRC

Remember when we started this whole course series, the first thing we looked at was the pepsi UDP flooder software? While this is not exactly the same as that, can you see the family resemblance? And in our traffic analysis section, we mentioned that when we see an IRC server is involved, that can be helpful information since they get hammered a lot So it seems reasonable that a partial answer is that somehow our computer, mysystem, is mixed up in a denial of service attack against an IRC server That does not answer the core question of whether this is a stimulus or a response, however If it is a stimulus, it is probably software, such as trojan software that resides on mysystem and just happens to use echo, port 7, as the source port If it is a response, then why don’t we see the stimulus? So we pull some more traffic, and on the next slide we get an additional clue

Trang 8

Is this a stimulus or a

response? (2)

07:00:03.733316 myhost> irc.some.where: icmp: echo reply

07:00:03.749546 myhost.echo > irc.some.where.45932: udp 60007:00:04.044893 myhost> irc.some.where: icmp: echo reply

07:00:04.203068 myhost.echo > irc.some.where.65348: udp 600

Remember when we learned to draw a link diagram in the traffic analysis section with the Out of Spec traffic? We could surmise that we were probably dealing with two way traffic even though we couldn’t see both sides of the traffic The simplest explanation for the echo reply packets we see in front of us is that they were stimulated by echo requests We just don’t see them for some reason There are several possibilities for this:

• Asynchronous routing

• Back door connection

• Misconfigured switch

From Stephen Northcutt:

“Well, hopefully you are familiar enough with your site that you know how your routing is

configured My CIRT thought “back door” when they saw this In other words, they thought someone was stimulating my host through an illicit connection to attack IRC To do this, the attacker might need to use source routing, which isn’t commonly associated with dumb ol bash the IRC server denial of service attacks A backdoor connection could cause this pattern, but make that your second guess I will admit though, the first time I saw this pattern, my blood pressure went through the ceiling These days, I pick up the phone and dial the network operations folks at the site where the sensor is located This pattern is often caused by poorly configured VLANs in a switched network environment causing the sensor to only see one side of the traffic.”

Trang 9

SYN Flood

The real deal

14:18:22.5166 flooder.600 > server.login: S 1382726960:1382726960(0) win 4096 14:18:22.5660 flooder.601 > server.login: S 1382726961:1382726961(0) win 4096 14:18:22.7447 flooder.602 > server.login: S 1382726962:1382726962(0) win 4096 14:18:22.8311 flooder.603 > server.login: S 1382726963:1382726963(0) win 4096 14:18:22.8868 flooder.604 > server.login: S 1382726964:1382726964(0) win 4096 14:18:22.9434 flooder.605 > server.login: S 1382726965:1382726965(0) win 4096 14:18:23.0025 flooder.606 > server.login: S 1382726966:1382726966(0) win 4096 14:18:23.1035 flooder.607 > server.login: S 1382726967:1382726967(0) win 4096 14:18:23.1621 flooder.608 > server.login: S 1382726968:1382726968(0) win 4096 14:18:23.2284 flooder.609 > server.login: S 1382726969:1382726969(0) win 4096 14:18:23.2825 flooder.610 > server.login: S 1382726970:1382726970(0) win 4096 14:18:23.3457 flooder.611 > server.login: S 1382726971:1382726971(0) win 4096 14:18:23.4083 flooder.612 > server.login: S 1382726972:1382726972(0) win 4096 14:18:23.9030 flooder.613 > server.login: S 1382726973:1382726973(0) win 4096 14:18:24.0052 flooder.614 > server.login: S 1382726974:1382726974(0) win 4096

The trace above is a valid SYN flood; in fact, it is “the” SYN flood that we learned about in the

Mitnick attack On the next slide we morph the trace a bit to illustrate a point From our earlier studies on the “elegant” SYN flood, we learned that through a design flaw, it was possible to execute

a denial of service attack against a server with 6 – 10 packets per minute You can imagine that system designers have been trying to get this fixed ever since Most modern operating systems are not vulnerable to this particular SYN flood However, we keep hearing about SYN floods and not in ancient literature either; do they still work?

Certainly, just not at a packet rate of 6 – 10 per minute Modern SYN floods exhaust resources by sending a much larger number of SYN packets and though there are countermeasures, there comes a point where there isn’t much you can do, just too many packets flying around

One last point before we go to the next slide: just how do intrusion detection systems report a SYN flood? Essentially, you would count the number of SYNs over a time period like 5 seconds If the IDS had no notion of state, that would be the end of it If you had too many SYNs, raise an alarm If you have a more sophisticated system, you can decrement the counter when you get lone ACKs completing the 3-way handshake and possibly on RST as well

[Narrator – historical information, do not read.]

Source: tsutomu@ariel.sdsc.edu (Tsutomu Shimomura), comp.security.misc Date: 25 Jan 1995

“About six minutes later, we see a flurry of TCP SYNs (initial connection requests) from 130.92.6.97

to port 513 (login) on server The purpose of these SYNs is to fill the connection queue for port 513

on server with "half-open" connections so it will not respond to any new connection requests In particular, it will not generate TCP RSTs in response to unexpected SYN-ACKs.”

Trang 10

SYN Flood

Common Error

14:18:22.5166 host.600 > server.25: S 1382726960:1382726960(0) win 4096

14:18:22.5660 host.601 > server.25: S 1382726961:1382726961(0) win 4096

14:18:22.7447 host.602 > server.25: S 1382726962:1382726962(0) win 4096

14:18:22.8311 host.603 > server.25: S 1382726963:1382726963(0) win 4096

14:18:22.8868 host.604 > server.25: S 1382726964:1382726964(0) win 4096

14:18:22.9434 host.605 > server.25: S 1382726965:1382726965(0) win 4096

14:18:23.0025 host.606 > server.25: S 1382726966:1382726966(0) win 4096

14:18:23.1035 host.607 > server.25: S 1382726967:1382726967(0) win 4096

14:18:23.1621 host.608 > server.25: S 1382726968:1382726968(0) win 4096

14:18:23.2284 host.609 > server.25: S 1382726969:1382726969(0) win 4096

14:18:23.2825 host.610 > server.25: S 1382726970:1382726970(0) win 4096

Note: This is a fabricated trace; compare sequence numbers

to the previous slide Most modern OSes are resistant Most IDS SYN Flood detects are actually false positives.

Kind of hard to tell the difference between this page and the previous, yes? In fact, impossible, if you notice the sequence numbers We simply altered the previous trace with find and replace What

is the point?

It is not unusual to see a mailer “syn flood”… If your mail server is down After all, mail is queued

up and processed (generally) every hour The longer the server is down, the more mail gets queued

up and the bigger the “SYN flood” becomes The other very common false positive is Microsoft Internet Explorer visiting a web page; it will create a connection for each gif, jpeg, html etc., up to

a limit of 32

The bottom line: As a general rule, be very slow to report a SYN flood; there is a high chance of

reporting a false positive You don’t need an IDS to detect a bonafide modern SYN flood; hints this

is happening include:

• Cursor echo on an affected system takes over a minute

• Network operations starts making groaning sounds like Red October clearing 600 meters

• Smoke rising from your router

We are sure you get the general idea!

Trang 11

urg 16404 <[bad opt]> (DF)

Full trace shown in notes pages

This is another multi-slide discussion Let’s start off by noticing that the destination port and the window size are the same On the slide examples and in your notes you have some similar packets, but with screwy URG pointers What is going on? Let’s go to the next slide

14:40:16.858407 hosed.30726 > client.44: SR 2013659180:2013660632(1452) win 44 (DF) 14:40:19.168407 hosed.30975 > client.1480: SFRP 2029979080:2029980532(1452) ack

2029979080 win 1480 urg 1480 <[bad opt]> (DF)

14:40:19.498407 hosed.30971 > client.16404: SFP 2029731860:2029732319(459) ack

2029731860 win 16404 urg 16404 <[bad opt]> (DF)

2029764628 win 49172 urg 49172 <[bad opt]> (DF)

2029733320 win 17864 urg 17864 <[bad opt]> (DF)

14:40:15.708407 hosed.30971 > client.16408: SFP [bad hdr length] (DF)

2029765164 win 49708 urg 49708 <[bad opt]> (DF)

14:40:16.948407 hosed.30975 > client.12: SFRP 2029977612:2029979064(1452) ack

2029977612 win 12 urg 12 <[bad opt]> (DF)

2029766088 win 50632 urg 50632 <[bad opt]> (DF)

2029979080 win 1480 urg 1480 <[bad opt]> (DF)

Trang 12

Key to Understanding: all the code bits are set; this

can’t be and so these packets are flagged as out of spec.

Note that all the flags in this older Snort detect are set In October 2000, Marty updated Snort and put the flags in the correct order Note that the reserved bits are also set A good analyst does not say ECN congestion notification at this point; that would be out of context with the other six flags

Per the discussion of exactly what a Christmas tree packet is, we see no evidence that any major OS crashes when exposed to this So, it is not a denial of service attack Could it be TCP stack analysis, TCP fingerprinting? Sure, but notice the source port though; this actually could be a response of some sort, albeit weird

Today, we refer to these most correctly as Out of Spec or Out Of Specification (OOS) packets You may also hear these referred to as “Demon net” In late 1997 and throughout 1998, the Demon Internet, a service provider in the UK and Europe, was known as the source for a large number of anomalous patterns In the next slides we will look at one of the famous signatures of the Demon Internet pattern to help you practice your technical analysis skills However, the more important lesson is to never let your technical analysis get in the way of the fundamentals The most important signature for the Demon Internet patterns were that one of your hosts was always the stimulus One

of your hosts would visit a web server, and a while later a crazy looking packet would come back at you This means if your site didn’t record outgoing packet traffic, you wouldn’t be able to ascertain this

Trang 13

urg 1480 <[bad opt]> (DF)

30975 Decimal = 111111 for binary 6 lowest bits

UAPRSF

111111

We don’t take credit for the analysis on your slide Take a look at the reflexive destination port and window size Even more fun, check out the binary pattern for the flags that are set and the source port Here are the comments from the Service Provider:

“Thanks for this As I said in my second phone call, we are seeing problems with one of our routers corrupting packets in some manner; work is being done to resolve this

As an indication of the problem, consider the first block of packets you sent me:

Trang 14

Totally Hosed 4

14:40:19.498407 hosed.30971 > client.16404: SFP

2029731860:2029732319(459) ack 2029731860 win 16404

urg 16404 <[bad opt]> (DF)

30971 Decimal = 111011 for binary 6 lowest bits

UAP RSF

111011

The pattern described will persist through the entire

scan shown The analyst’s conclusion is that the pattern

That said, let’s take one last second for a conspiracy theory Suppose, just suppose you were seeing lots of broken packets from a source and it was generally accepted that it was in fact a hardware problem Does that mean you could let your guard down and assume that every weird packet was benign? Remember, for many patterns there is more than one reasonable interpretation With large packet flows there may be patterns inside the patterns The wise analyst plays the odds, calls it with the odds, but remains alert for other possibilities

Trang 15

Scanned by IRC server

to inetgw on unserved port 1080

If this is a problem for you, block outgoing TCP 6667

The stimulus in these cases is one of your internal hosts connecting to an IRC server IRC operators commonly test to see if the incoming connection is from a host that has these ports open; they aren’t just scanning your site They attempt to avoid connections through proxies as a best effort to avoid problems Tim White has mapped a couple additional servers and documented their patterns:

starchat.net

Dec 23 13:53:39 irc[998]: connect host=unknown/172.16.57.138

destination=208.213.162.254/6667

Dec 23 13:53:39 unix: securityalert: tcp if=hme1 from 208.213.162.254:3343

to inetgw on unserved port 1080

starchat.net

Dec 24 16:05:38 irc[27541]: connect host=unknown/172.16.57.138

destination=208.213.162.254/6667

Dec 24 16:05:38 unix: securityalert: tcp if=hme1 from 208.213.162.254:4000

to inetgw on unserved port 1080

WebChat.MD.US.Undernet.Org

Dec 27 13:23:13 tn-gw[5979]: deny host=unknown/207.114.24.98 use of proxyDec 27 13:23:13 unix: securityalert: tcp if=hme1 from 207.114.24.98:2582 toinetgw on unserved port 1080

Trang 16

This certainly is a connect to 1080, but it requires looking

at the source host, ProxyScan.MD.US.Undernet.Org, to

start figuring out the pattern.

Detect by Andy Johnston, GCIA; analysis by Julie Lefebvre, GCIA

Andy is a co-author of the Intrusion Signatures and Analysis book; here, one of his detects is being used for a student practical We will let Julie tell it in her own words, but we want to come back with the wrapup

“When I first noticed these ‘WinGate 1080 Attempts’ originating from the same IP address

207.114.4.46 and directed to port 1080 on several hosts of the network MY.NET, I immediately thought that this was a scan for SOCKS servers (as we discussed in the IDIC)

The packets were arriving slowly (roughly 8 per day) at random times throughout the day and were directed to different hosts (IP numbers not chosen in any order) except in one case, on April 7 at 18:28, where two packets were sent to MY.NET.97.164

So I did an nslookup on the source IP address 207.114.4.46 and found out that it belongs to

ProxyScan.MD.US.Undernet.Org With a bit more research, I learned that Undernet.org has an IRC server and checks for a mis-configured Wingate or SOCKS proxy when a user attempts to establish a connection to the IRC server As long as the destination IPs belong to existing hosts on MY.NET, then this is what is happening in this trace

The intent is not malicious and this trace isn’t anything to be alarmed by.”

This was a great analysis That being said, 1080 is another one not to let your guard down on For

Trang 17

Instead of only evaluating the destination port, it is a good

idea to consider the source port and address as well.

Before we go into the specifics of this detect, notice again what is going on The Snort rule is firing because a particular packet matches a particular signature If you don’t get lucky and have a nice clean case using traffic analysis techniques like Julie’s case, it can be very hard to run this to ground without a sniffer or TCPdump trace so you can analyze if this is a response or a stimulus We will follow this slide with the same situation from two different sources, BlackIce and Ipchains for the case of NTP

Detect and Analysis by Julie Lefebvre, GCIA:

“Traffic directed towards port 32771 can be hostile since Sun Solaris puts most of its RPC services in the range 32770-32900 and these can be exploited However in this case, the source port is 4000 which is usually an ICQ server In fact, with an nslookup, I found that 205.188.179.34 corresponds

to fes-d022.icq.aol.com (AOL’s ICQ server) It is normal to see UDP packets going from source port 4000 to some random high number port It looks like MY.NET.220.198 happened to use port

32771 This is a good example of a false positive.”

Trang 18

Killer Time Packets

Black Ice Defender alerts on a reply to a time request sent out

by this computer We are often the stimulus for “attacks”.

Detect and analysis by Fred Kolbrener, GCIA:

(The monitored computer uses a program that checks the internet for the correct time and updates the computer’s clock The program makes use of the standard port 123 to effect this transfer of time data Since I had not been running a firewall prior to the installation of the firewall, I was not aware

of the manner in which the program operated and no need to reconfigure it or any other program to make sure it ran correctly.) Based on this series of recorded activity, I modified the firewall ‘ini’ file

to open port 123 for incoming time data The problem has not recurred The IDS portion of

BlackICE revealed a need for reconfiguration for normal operations

Variation by Paul Stillwell, GCIA:

Mar 12 04:05:35 hostname kernel: Packet log: input - eth0 PROTO=17

snort.someplace.net:123 me.nowhere.com:61218 L=76 S=0x10 I=63671

F=0x4000 T=245

At first I thought that this was the tail end of a slow UDP port scan But the source address and consistent source port (below 1024) were bothering me The domain is known and the source port was always 123 (xntp) After some research, I discovered that it was actually a misconfiguration of

my IPChains rules (I had the source and dest ports reversed) for valid xntp traffic What threw me off initially is that the reverse lookup returns snort.someplace.net A different name than what is in the xntp configuration file The config file points to a server called clock.someplace.net which resolves to a.b.c.d, the reverse lookup on a.b.c.d returns snort.someplace.net This example

Tiêu đề	Intrusion Detection Patterns
Trường học	SANS Institute
Chuyên ngành	Cybersecurity
Thể loại	tài liệu hướng dẫn
Năm xuất bản	2001
Thành phố	Unknown

Định dạng
Số trang	36
Dung lượng	752,19 KB