Tài liệu Intrusion Detection Patterns doc

1
IDIC – SANS GIAC LevelTwo
©2000, 2001
1
Intrusion Detection
Patterns
Patterns
Please send patterns to
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.
2
IDIC - SANS GIAC LevelTwo
©2000, 2001
2
Section Overview
•A Word of Warning
•Denial of Service Attacks
•Network Vulnerability Scanning
•Network Mapping
•Information Gathering
•Subtle and Stealthy Attacks
•Coordinated Attacks

This slide shows an overview of the topics we will cover. If you see patterns in these categories that
are not included in this course, we hope you will send them to so they can be
added to the collection. Keep in mind that intrusion detection is easy when you know the answer,

when it is a familiar pattern; however, it can be hard and frustrating when you do not know the
answer. Behind every pattern in this course is also a story. There was a time we did not know these
answers and had to find them out. This is why it is so important for each of us to help develop the
knowledge of the community.
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.
3
IDIC - SANS GIAC LevelTwo
©2000, 2001
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.
Common Errors
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.”

4
IDIC - SANS GIAC LevelTwo
©2000, 2001
4
UDP “High Port Scan”
"7252" "29Mar2000" "12:58:31" "drop" "33434"
"209.67.29.9" "my.net.100.100" "udp" " len 64"
"7253" "29Mar2000" "12:58:32" "drop" "33434"
"209.67.29.9" "my.net.100.100" "udp" " len 64"
"7254" "29Mar2000" "12:58:33" "drop" "33434"
"209.67.29.9" "my.net.100.100" "udp" " len 64"
"7255" "29Mar2000" "12:58:34" "drop" "33434"
"209.67.29.9" "my.net.100.100" "udp" " len 64"
Correct analysis: F5Labs traceroute variant
Common Errors
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
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
client to a POP. The latency, as measured by the traceroute mechanism used by the load balancer,
establishes an optimal path. The trace is initiated when a gethostbyname query is issued on behalf of the
client by the local DNS server or cacheing appliance. The trace is directed at the source of the query and
not at the client.
5
IDIC - SANS GIAC LevelTwo
©2000, 2001
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!
Common Errors
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.
6
IDIC - SANS GIAC LevelTwo
©2000, 2001
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
Common Errors
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.
7
IDIC - SANS GIAC LevelTwo
©2000, 2001
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 600
07:17:11.001745 mysystem.echo > irc.some.where.14643: udp 600
07:17:11.146935 mysystem.echo > irc.some.where.49911: udp 600
07:17:12.254277 mysystem.echo > irc.some.where.28480: udp 600
07:17:12.350014 mysystem.echo > irc.some.where.20683: udp 600
07:17:12.835873 mysystem.echo > target1.5134: udp 64
07:17:13.266794 mysystem.echo > irc.some.where.16911: udp 600
07:17:13.862476 mysystem.echo > target1.32542: udp 64
07:17:14.032603 mysystem.echo > irc.some.where.32193: udp 600
07:17:14.579404 mysystem.echo > irc.some.where.24455: udp 600
07:17:14.619173 mysystem.echo > irc.some.where.5120: udp 600
07:17:14.792983 mysystem.echo > irc.some.where.47466: udp 600
07:17:14.879559 mysystem.echo > target1.16878: udp 64
07:17:15.308270 mysystem.echo > irc.some.where.12234: udp 600
Common Errors

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.
8
IDIC - SANS GIAC LevelTwo
©2000, 2001
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 600
07:00:04.044893 myhost> irc.some.where: icmp: echo reply
07:00:04.062594 myhost.echo > irc.some.where.25057: udp 600
07:00:04.120963 myhost> irc.some.where: icmp: echo reply
07:00:04.138398 myhost.echo > irc.some.where.55640: udp 600
07:00:04.185552 myhost> irc.some.where: icmp: echo reply

07:00:04.203068 myhost.echo > irc.some.where.65348: udp 600
Common Errors
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.”
9
IDIC - SANS GIAC LevelTwo
©2000, 2001
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
Common Errors
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 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.”
10
IDIC - SANS GIAC LevelTwo
©2000, 2001
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.
Common Errors
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!
11
IDIC - SANS GIAC LevelTwo
©2000, 2001
11
Totally Hosed 1
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)
Full trace shown in notes pages
Common Errors
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)
14:41:13.918407 hosed.30971 > client.49172: SFP 2029764628:2029766080(1452) ack
2029764628 win 49172 urg 49172 <[bad opt]> (DF)
14:40:14.688407 hosed.30971 > client.17864: SFP 2029733320:2029734772(1452) ack
2029733320 win 17864 urg 17864 <[bad opt]> (DF)
14:40:15.708407 hosed.30971 > client.16408: SFP [bad hdr length] (DF)
14:41:16.738407 hosed.30971 > client.49708: SFP 2029765164:2029766616(1452) ack
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)
14:41:13.918407 hosed.30975 > client.12: SFRP 2029977612:2029977738(126) ack
2029977612 win 12 urg 12 <[bad opt]> (DF)
14:40:26.138407 hosed.30971 > client.50632: SFP 2029766088:2029767540(1452) ack
2029766088 win 50632 urg 50632 <[bad opt]> (DF)
14:40:27.288407 hosed.30975 > client.1480: SFRP 2029979080:2029980532(1452) ack
2029979080 win 1480 urg 1480 <[bad opt]> (DF)
12
IDIC - SANS GIAC LevelTwo
©2000, 2001
12
Totally Hosed 2
02/21-00:18:35 192.0.205.118:21 -> 216.229.234.199:3547
TCP TTL:126 TOS:0x0 ID:35117
SFRPAU1 Seq: 0x10000 Ack: 0x147 Win: 0x5014
00 01 00 00 00 00 01 47 16 BF 50 14 00 00 76 61 G P va
20 20 20 20 20 00 .
Key to Understanding: all the code bits are set; this
can’t be and so these packets are flagged as out of spec.
Common Errors

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.
13
IDIC - SANS GIAC LevelTwo
©2000, 2001
13
Totally Hosed 3
Service Provider comment in notes
14:40:16.858407 hosed.30726 > client.44: SR
2013659180:2013660632(1452) win 44 (DF)
30726 Decimal = 000110 for binary 6 lowest bits
UAPRSF
000110
14:40:19.168407 hosed.30975 > client.1480: SFRP
2029979080:2029980532(1452) ack 2029979080 win 1480

urg 1480 <[bad opt]> (DF)
30975 Decimal = 111111 for binary 6 lowest bits
UAPRSF
111111
Common Errors
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:
> 1999.11.08-18:18:00 193.238.132.110:30971
194.248.132.204:17864
> fin syn psh ack urg Tcp-packet
> 1999.11.08-18:18:00 193.238.132.110:30972
194.248.132.204:16404
> rst psh ack urg Tcp-packet
> 1999.11.08-18:18:00 193.238.132.110:30973
194.248.132.204:1480
> fin rst psh ack urg Tcp-packet
> 1999.11.08-18:18:00 193.238.132.110:30973
194.248.132.204:16488
14
IDIC - SANS GIAC LevelTwo
©2000, 2001
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
UAPRSF
111011
The pattern described will persist through the entire
scan shown. The analyst’s conclusion is that the pattern
is in fact non-hostile.
Common Errors
Let’s do it together in case we went too fast for you. First, a quick refresher in binary math, yup,
Start -> Programs -> Accessories -> Calculator -> View Scientific, welcome to the real world. Plug
it in; just like your slide says, the practice is good for you. Remember one day you may be the
analyst trying to figure out which way is up.
30971 decimal, hit binary, focus on the 6 least significant bits (the ones on the right). Match them
against the flags that are set; they are shown in order on your slide, FIN as the lowest, URG as the
highest. That pattern occurred consistently. It was a compelling argument that it was a hardware
problem since it was so repeatable, it quacked like a duck, and it did no discernable harm, it waddled,
and it came as a result of an action, a stimulus from one of your site’s internal hosts. Heck, this duck
even has feathers, what more could we ask?
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.
15
IDIC - SANS GIAC LevelTwo
©2000, 2001
15
Scanned by IRC server
unet.chatsystems.com
Dec 22 10:33:22 irc[20436]: connect host=unknown/172.16.140.52

destination=206.138.230.200/6667
Dec 22 10:33:30 tn-gw[20454]: deny host=unknown/206.138.230.251
use of proxy
Dec 22 10:33:30 unix: securityalert: tcp if=hme1 from
206.138.230.251:4878
to inetgw on unserved port 1080
If this is a problem for you, block outgoing TCP 6667
Common Errors
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 proxy
Dec 27 13:23:13 unix: securityalert: tcp if=hme1 from 207.114.24.98:2582 to
inetgw on unserved port 1080
16
IDIC - SANS GIAC LevelTwo
©2000, 2001
16

Socks or Wingate?
[**] WinGate 1080 Attempt [**]
04/08-11:51:29.539770 207.114.4.46:4121 ->
MY.NET.97.172:1080
[**] WinGate 1080 Attempt [**]
04/08-12:27:43.270849 207.114.4.46:2343 ->
MY.NET.203.158:1080
Key to Understanding:
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.
Common Errors
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
one thing, wingate has had a number of vulnerabilites. Also, SOCKS is an Application Programming

Interface designed specifically for the purpose of penetrating perimeters. So in this case we judge
this benign, but this was after an analysis of the source, NOT saying that all 1080s should also be
considered benign.
17
IDIC - SANS GIAC LevelTwo
©2000, 2001
17
SUN RPC or ICQ?
[**] Attempted Sun RPC high port access [**]
04/06-08:11:24.804269 205.188.179.34:4000 ->
MY.NET.220.198:32771
[**] Attempted Sun RPC high port access [**]
04/06-08:12:25.149650 205.188.179.34:4000 ->
MY.NET.220.198:32771
Key to Understanding:
Instead of only evaluating the destination port, it is a good
idea to consider the source port and address as well.
Common Errors
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.”
18
IDIC - SANS GIAC LevelTwo
©2000, 2001
18
Killer Time Packets
Common Errors
59 2000-01-26 19:38:53 2003502 UDP port
probe 207.172.73.197 rcn.com 198.189.18.5
port=123 1
59 2000-01-26 19:42:43 2003502 UDP port
probe 207.172.73.197 rcn.com 128.102.16.10
port=123 1
Key to Understanding:
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
illustrates well that caution and objectivity are required when analyzing any detect.
19
IDIC - SANS GIAC LevelTwo
©2000, 2001
19
Did you see where I put my keys?
89515 20:20:13.1565 63.145.178.500 ->
my.net.21.4.500 UDP
ISAKMP Identity Protection (Main Mode)
This is a common error to commit to memory. We tend to agree with Bill’s analysis of a confused
Windows 2000 system. As you already know, you have to have a policy to do a key exchange. Also
note this was a response, not a stimulus. Be a bit slow to fear the worst when one of your systems is
the stimulus.
Detect and analysis by Bill Royds, GCIA:
“There are no known common attacks as yet with IPSEC, the odds are highest a system is
misconfigured or tries for IPSEC first.
User Datagram Protocol Source port: 500 Destination port: 500 so this is ISAKMP. (Internet
Security Association and Key Management Protocol.)
Identify Protection format, used to initiate a key exchange. These packets follow this format fairly
precisely except for the last entry in the SA Attributes set which uses a code for pre-agreed private
attributes. See for assignments of these
Data Attributes. The data in these last items appears to be Unicode representations of the name
athena$@ONLINE. The FQDN name for the host that sent these packets is athena.vninc.com which
corresponds to this text. Perhaps the server is running Windows 2000 with IPSEC enabled since it
responded to a SMTP request with: this connection”

20
IDIC – SANS GIAC LevelTwo
©2000, 2001
20
Denial of Service
We hope you enjoyed the last section; you had a large number of opportunities to practice your
traffic analysis skills against some patterns that have been known to throw analysts in the past.
In the next section of the course, we will look at denial of service attacks. If you are willing to be a
shade liberal and not spend your life worrying if something is a “Boink” or a “Teardrop”, these are
pretty easy to identify and classify.
Let’s start at a high level, the notion of an asymmetric attack. In warfare, we use asymmetric attacks
against a stronger enemy. For instance, if you are above a huge army on a plain, and can hack a dam
(or blow it up) and wash them all away, that is an example of an asymmetric attack.
When you look at Denial of Service (DoS) attacks, try to ask yourself what is the level of
amplification, or to what degree is this attack asymmetric. For instance, a SYN flood requires a
stimulus packet (SYN) for every response (SYN/ACK). In that sense it is symmetric, which means it
is not really worth doing. However, you know that the server is committing resources at a higher
rate than the client and of course, the solution to the symmetry is to use multiple systems to send the
SYNs and with optimized software. Finally, there is one more DoS class to be aware of: the one
packet kill. A system gets hit with this packet and it is dead, boom, game over. In the early days of
nmap we learned these were more common than we could have ever guessed.
21
IDIC - SANS GIAC LevelTwo
©2000, 2001
21
Boring Ol Smurf
00:00:05 spoofed.net > 192.168.15.255: icmp: echo request
00:00:05 spoofed.net > 192.168.1.255: icmp: echo request
00:00:14 spoofed.net > 192.168.15.255: icmp: echo request
00:00:14 spoofed.net > 192.168.1.255: icmp: echo request

00:00:19 spoofed.net > 192.168.15.255: icmp: echo request
05:20:48 spoofed.net > 192.168.0.0: icmp: echo request
05:20:48 spoofed.net > 255.255.255.255: icmp: echo request
05:21:35 spoofed.net > 192.168.0.0: icmp: echo request
05:21:35 spoofed.net > 255.255.255.255: icmp: echo request
05:22:16 spoofed.net > 192.168.0.0: icmp: echo request
05:22:16 spoofed.net > 255.255.255.255: icmp: echo request
The source IP address is spoofed, and the echo requests
are addressed to broadcast addresses. The point is
simply to chew up bandwidth.
In this slide, you see three flavors of broadcast:
• A standard “all ones” broadcast, represented in this case by 192.168.15.255 and 192.168.1.255
• A non-standard “all zeros” BSD legacy broadcast, represented by 192.168.0.0
• A directed, or limited, or expanded broadcast represented by 255.255.255.255
Note that the name of the source host is spoofed.net. This implies that the packet does not really
come from the source address. By now, we are very familiar with spoofing addresses. If the
destination site is what we call a smurf amplifier, then spoofed.net could be in a spot of trouble here,
as shown on the next slide.
22
IDIC - SANS GIAC LevelTwo
©2000, 2001
22
ICMP Denial of Service
(Illustrated)
Attacker spoofs address of victim.com so he potentially receives
thousands of ICMP echo replies responding to the broadcast.
InternetIntranet
172.16.255.255
172.16.1.*
172.16.2.*

172.16.2.*
In the illustration above, the attacker is inserting pings (ICMP echo requests) into the network with
fake source addresses. The recipients of the pings respond with echo replies that are sent to the fake
address (pound me). This can be a problem for sites with slow internet feeds or high traffic levels.
This clearly is an example of an asymmetric attack.
Please notice there are really two victims in this attack. The big arrow gives the sense there is only
one, but the 172.16 network is losing a lot of bandwidth and CPU cycles clobbering the poor “pound
me” PC.
Also note that two sites have to be lousy network neighbors for this attack to work. Look closely at
the PC generating the spoofed packet. The owner of that site should NEVER allow Internet
addresses to leave their site that do not belong to that site. This is known as egress filtering, and
every Internet site should be responsible enough to implement this. The 172 site should NOT be
allowing incoming ICMP echo request broadcasts into their site.
23
IDIC - SANS GIAC LevelTwo
©2000, 2001
23
Denial of Service Attacks
Smurf Attacks or Mapping?
05:20:48 spoofed.net > 192.168.1.0: icmp: echo request
05:20:48 spoofed.net > 192.168.1.255: icmp: echo request
05:21:35 spoofed.net > 192.168.1.0: icmp: echo request
05:21:35 spoofed.net > 192.168.1.255: icmp: echo request
05:22:16 spoofed.net > 192.168.1.0: icmp: echo request
05:22:16 spoofed.net > 255.255.255.255: icmp: echo request
05:22:58 spoofed.net > 192.168.0.0: icmp: echo request
Zero: Old style BSD broadcast
05:22:58 spoofed.net > 255.255.255.255: icmp: echo request
Probably a broadcast to the network the sensor is on.
The source IP address is spoofed, and the echo requests are

directed to broadcast addresses.
In this example, the old BSD zero broadcast form is used. Many Unix systems will honor a zero
broadcast while Windows systems do not. In fact, everybody loves to slam Windows, but they
figured out a long time ago that they could help prevent forest fires. They will not honor an ICMP
echo request broadcast, period! That was pretty good thinking. It does have one small side effect,
but we can live with it.
The BSD stacks will honor both 255 and zero, so you can find all the systems whose network stack
derives from BSD, and that is most. Non BSD stacks will not honor a zero broadcast, so they stand
out like a sore thumb. And if you can perform some other form of network mapping, you can
separate the Windows systems that keep their traps closed regardless when it comes to broadcasted
echo requests.
Time for a conspiracy theory moment. This allows for the possibility of appearing to be the
“innocent” victim of a smurf attack while mapping the Internet. WAKE UP! If your site allows
someone to send broadcasted ICMP echo requests and get responses, you ARE being mapped. We
will explore this concept in greater detail as we continue to work through the material. However, the
bottom line is this: if those response packets leave your network, you have given away
reconnaissance data. Whenever you are the victim of successful reconnaissance, you need to do
battle damage assessment, since you are now in a more vulnerable position than you were before the
reconnaissance.
24
IDIC - SANS GIAC LevelTwo
©2000, 2001
24
The good guys?
09:52:20.392092 ops.netscan.org > our.class-B.0.255: icmp: echo request
09:52:20.465109 ops.netscan.org > our.class-B.1.255: icmp: echo request
09:52:20.567738 ops.netscan.org > our.class-B.10.255: icmp: echo request
09:52:20.656040 ops.netscan.org > our.class-B.100.255: icmp: echo request
09:52:20.750615 ops.netscan.org > our.class-B.101.255: icmp: echo request
09:52:20.849288 ops.netscan.org > our.class-B.102.255: icmp: echo request

09:52:20.936554 ops.netscan.org > our.class-B.103.255: icmp: echo request
09:52:21.038335 ops.netscan.org > our.class-B.104.255: icmp: echo request
09:52:21.161844 ops.netscan.org > our.class-B.105.255: icmp: echo request
09:52:21.272485 ops.netscan.org > our.class-B.106.255: icmp: echo request
Key to Understanding:
www.netscan.org and www.powertech.no scan networks
looking for smurf amplifier sites.
To understand this slide, please start at the bottom and work up. There are sites that “register” smurf
amplifiers. They provide lists of these sites for the “public good”. It isn’t worth a conspiracy theory
moment to point out these same lists can be for the public harm.
Call us paranoid, but we like to take a look from time to time at these lists. When we teach the
course we admit that yes, there have been times when we screwed up beyond all belief and our own
sites were smurf amplifiers. Then we ask the class if it has ever happened to them and about 10% of
the hands come up. Those are the honest and clueful students! We aren’t saying every site has been
a smurf amplifier at some point, just most. Do you remember the pattern in the common errors
section when our site was being used to attack an IRC server with a variation of pepsi, the UDP
flooder? Surely we knew better than to allow port 7, echo, into our site from the Internet. And we
did, but late night during a weekend a technician was tired and trying to get home and reloaded the
firewall rules just a bit too fast. These things happen.
And we leave this slide with an opportunity to point out the importance of considering where the
packets come from. Is this network mapping? You can bet your bottom dollar on that. Is it benign?
It is so long as you can trust netscan.org and EVERYONE that downloads information from them.
That means, if you aren’t first, if you don’t check, you may find your site on the wall of shame. If
you see a site that will not fix their problem, they are probably mapping targets of opportunity; more
on that later.
25
IDIC - SANS GIAC LevelTwo
©2000, 2001
25
Twinge – multi-ICMP

168.152.83.40 > my-fw: icmp: type-#6 (ttl 241, id 10128)
216.66.110.92 > my-fw: icmp: type-#7 (ttl 241, id 64928)
143.178.141.17 > my-fw: icmp: echo request (ttl 241, id 15680)
227.22.3.71 > my-fw: icmp: router advertisement lifetime 0 0: [size
0]
171.3.201.123 > my-fw: icmp: router solicitation (ttl 241, id 37064)
251.38.69.48 > my-fw: [|icmp] (ttl 241, id 61264)
251.38.69.48 > my-fw: [|icmp] (ttl 241, id 61264)
127.45.148.101 > my-fw: icmp: parameter problem - octet 0
195.245.45.90 > my-fw: icmp: time stamp request (ttl 241, id 24320)
106.46.101.79 > my-fw: icmp: time stamp reply (ttl 241, id 56272)
117.208.1.4 > my-fw: icmp: information request (ttl 241, id 56832)
182.129.70.57 > my-fw: icmp: information reply (ttl 241, id 37664)
91.0.231.109 > my-fw: icmp: address mask request (ttl 241, id 59232)
Having covered echo requests thoroughly, we are going to blaze through the rest of ICMP. Robert
Currie was one of the folks that was instrumental in the mafiaboy investigation and bust. Who was
mafiaboy? The kid that zapped Yahoo (did you know Yahoo thinks SANS is a postcard trading
site???), CNN and others in March 2000 with Distributed Denial Of Service (DDOS) attacks. Look
at the trace and then the analysis carefully. Is this symmetric or asymmetric?
Detect and analysis by Robert Currie, RCMP:
“This traffic was generated by a Denial of Service tool called twinge. It cycles through all 18 icmp
types and sub codes. It was designed to DoS Windows boxes. Many Microsoft networking stacks
won’t handle a steady ‘diet’ of this kind of traffic. Research indicates it only works on Windows
95/98 and some early NT 4.0 Service Packs. It is interesting to note that during the Mafiaboy
investigation, this tool was found with DoS tool imp used by Mafiaboy to attack many prominent US
commercial sites.”
In a busy world, twinge is not the stuff nightmares are made of; this is a very symmetric attack. Still,
it is a good signature to be aware of.