Tài liệu Traffic Analysis Techniques 1 pdf

1
IDIC – SANS GIAC LevelTwo
©2000, 2001
1
Traffic Analysis Techniques 1
Traffic Analysis is a set of techniques for
arranging and visualizing data so that
patterns and relations can be identified,
tagged or tracked. This course serves as a
primer for taking logfiles of virtually any
format, organizing the data and performing
the analysis.
This section of the course will concentrate on externals, the fields in the packet header more than the
content. The purpose of this section is to teach the analysis of packets based on their behavior and
the fields. I hope that you find the material in this section to be something that you can use as you
analyze network traffic.
2
IDIC - SANS GIAC LevelTwo
©2000, 2001
2
Common External Dimensions
•Date, time
•To, From
• Service, Service port numbers
• Sequence numbers
Four W’s : Who, What, Where, When
Extra credit: Why
When we talk about columns and typing, we are approaching the subject of highly dimensional data.
Consider the date field a dimension, time another and so forth. By highly dimensional we mean “lots
of columns”.
Just about any field in the headers can be used to create another dimension. Most of the time, many

fields will contain normal non-descript values and will not add anything to our focus if we are trying
to analyze traffic. However, there are times when a crafted unique value in an inherently
uninteresting field may provide some kind of signature. For instance, sequence numbers when
normally generated are not of much interest to us as analysts. However, if we spy a static sequence
number or even a repeated acknowledgement number from what appears to be a reply from a static
sequence number, we may begin to see a pattern of some sort which will ultimately assist in the
analysis.
The more clues that you can find in the data, the more help you have in possibly explaining why you
are seeing what you are seeing.
3
In Geometry, height, length, and width are the three primary dimensions.
In traffic analysis, the primary dimensions are To, From, and Service. These functional dimensions
are part of the Traffic Analysis discipline. There are a large number of IP specific dimensions as
well that are important to analysis of IP traffic. These include:
ACK #’s
SEQ #’s
IP identification #’s
Arriving TTL values
Time
Flags
IDIC - SANS GIAC LevelTwo
©2000, 2001
3
From, To, Service Are Primary
Events of Interest
• Where do our “hits” come from?
• Who/What are they targeting?
• Can we find evidence of crafted
packets?
When we work without content we

focus on “externals”. “
From
” turns out
to be quite challenging and interesting.
4
IDIC - SANS GIAC LevelTwo
©2000, 2001
4
We don’t know anything about
port 17434, but what do we notice
about this pattern?
Primary focus – destination port
Secondary focus – source port, time
Many times the analyst has fragmentary data. I checked my entire databank and these ports did not
show up. There are programmable Trojans, but the prober appears to be looking for a service. Are
these spoofed IP addresses? Really, we can’t say with fidelity because this firewall sensor does not
record TCP flags. What we do see is the 4 attempt pattern, with repeated source ports; this is typical
of a retry. This is NOT likely a denial of service; these source addresses do want to connect to a
service.
Here’s a simple example of traffic analysis. User report is shown below:
Twice last week and again this week my network has been getting hit with some kind of what looks
like a distributed attack. The number of hits is limited (100-200), but has always employed what
appears to be a number of spoofed IPs, and usually aimed at a high numbered port, only one port to
an attack, one attack a day. So far they've been after ports 23702, 17434, and today 20931.
I'm enclosing a portion of my firewall logs. Can you advise what I'm seeing? I don't believe I've
been compromised yet, but this type of attack is highly unusual, and now coming almost every day.
Sorry to bother you, but if you could help I'd sure appreciate it. Thanks in advance.
5
IDIC - SANS GIAC LevelTwo
©2000, 2001

5
ircsrv.6666 > ourhost.1630: S 1234316212:1234316212(0)
ack 674711610 win 4096 (DF)
ircsrv.6666 > ourhost.1630: S 1306722499:1306722499(0)
ack 674711610 win 4096 (DF)
ircsrv.6666 > ourhost.1630: R 1:1(0) ack 1 win 4096 (DF)
Key to understanding:
Note IRC in the hostname. While 6666 is not the most
common IRC port (6667 is), it is a fairly common IRC port.
We see the packets coming from ircsrv. They think they
are under attack from us, but aren’t.
Primary focus – source host and port
Secondary focus – acknowledgement #, TCP flags
Collateral Damage (1)
This slide illustrates an important point; one of the important rules is where is the traffic coming
from! Odds are this is collateral effects of a denial of service attack on the IRC server.
This appears as if someone has earlier spoofed the source IP of ourhost with an initial sequence
number of 674711609 and sent the traffic to ircsrv destination port 6666. In the first two records,
you see that ircsrv was listening and able to respond and replied with the SYN and ACK flags set and
an acknowledgement number of 674711610. We don’t have the timestamps to analyze how closely
the third record is timewise to the first two records. But, it appears that ircsrv can no longer reply or
is not listening on port 6666 and responds with a reset. It is possible that someone is engaged in a
SYN flood of ircsrv using ourhost as one among many decoy source IP numbers.
6
IDIC - SANS GIAC LevelTwo
©2000, 2001
6
ns2> 172.20.137.48: icmp: ns2 udp port 51 unreachable [tos 0xc0]
ns2> 172.20.114.23: icmp: ns2 udp port 5006 unreachable [tos 0xc0]
ns2> 172.20.211.116: icmp: ns2 udp port 5592 unreachable [tos 0xc0]

ns2> 172.20.249.110: icmp: ns2 udp port 2605 unreachable [tos 0xc0]
ns2> 172.20.110.43: icmp: ns2 udp port 1362 unreachable [tos 0xc0]
ns2> 172.20.180.85: icmp: ns2 udp port 2686 unreachable [tos 0xc0]
ns2> 172.20.176.18: icmp: ns2 udp port 1608 unreachable [tos 0xc0]
ns2> 172.20.3.124: icmp: ns2 udp port 8358 unreachable [tos 0xc0]
We see a response; where did the stimulus originate from?
We will probably never know. We do know a name server
probably isn’t UDP flooding us on purpose!
Primary focus – source host, dest hosts
Secondary focus – port unreachables
Collateral Damage (2)
This second example of collateral damage shows a pattern that could be attributed to the Trinoo.
Again, the source addresses are faked and we see the result of the attack.
What is happening here is that a host at the attacked site, ns2, is responding back, trying to be
helpful, and telling us that the UDP port that we tried to reach is not in service. Note how many
UDP ports we supposedly tried.
How can you know if the traffic you see is truly a hostile source host or just indirect collateral
damage? First and foremost, you must have an audit trail of all activity into and out of your network
from all possible ingress and egress points. If you are certain that you have this completely covered,
you can pretty much rest assured (assuming your audit trail tool isn’t dropping packets and is not
experiencing any other malfunctions) that if you see no outbound traffic that elicited these responses,
your source IP numbers have been spoofed. Also, another indication is that if you see replies to
hosts that are not active in your network, then the IP’s had to have been spoofed and it is collateral
damage.
7
IDIC - SANS GIAC LevelTwo
©2000, 2001
7
RingZero Pattern
07:58:32.586953 lan213.huntingdon.edu.3304 >

192.168.58.240.80: S 105977495:105977495(0)
win 8192 (DF) (ttl 19, id 37127)
07:59:17.552178 lan213.huntingdon.edu.3352 >
192.168.58.240.8080: S 106022445:106022445(0)
win 8192 (DF) (ttl 19, id 8201)
08:00:02.603811 lan213.huntingdon.edu.3393 >
192.168.58.240.3128: S 106067447:106067447(0)
win 8192 (DF) (ttl 19, id 50956)
OK, we need to be candid with you about something. This next pattern is a bit challenging, and the
team spent a lot of time deciding whether to include it and how to explain it. However, we think you
will enjoy this, but we want to warn you upfront that this is an unsolved pattern. That happens
sometimes. So please relax and let’s take it by the numbers.
History: RingZero was identified as a trojan that used ports 80, 8080 and 3128 to report IP
addresses and proxy ports to a central server (www.rusftpsearch.net). This particular trace highlights
what is possibly a mutation of this trojan. Note the IP ID field is not consistent with the normal
behavior, incrementation.
In the next slide we gain further information about this pattern.
8
IDIC - SANS GIAC LevelTwo
©2000, 2001
8
RingZero? 1
00:50:49.091588 212.209.62.2.1040 >
142.62.0.108.80: S 79134:79134(0) win 8192
<mss 1460> (DF) (ttl 18, id 16384)
00:50:49.091774 212.209.62.2.1040 >
142.62.0.108.80: S 79134:79134(0) win 8192
<mss 1460> (DF) (ttl 17, id 16384)
...
00:50:49.093137 212.209.62.2.1040 >

142.62.0.108.80: S 79134:79134(0) win 8192
<mss 1460> (DF) (ttl 1, id 16384)
Can we find evidence of crafted packets?
Please note the TTLs on this slide; they are descending. This is not normal, obviously. Why would
someone send that many packets with descending TTLs (to port 80, in this case)?
The MOST important thing to keep in mind is that without being able to see the TTL and IP ID, this
would just look like a noisy scan to port 80. In fact, the analyst might decide it is a SYN flood. And
in fact, that is one possibility to explain this traffic – just a bandwidth, CPU wasting attack.
However, since we are working on traffic analysis, let’s dig a bit deeper.
Now, please notice the IP ID; it is not changing. Clearly something is wrong; what could it be? One
possibility is that someone is crafting packets and this is being used as a type of traceroute.
However, if that is true, they are not doing it in a clever manner. If you were going to do a
traceroute, it would be much more logical to have the TTLs count up, 1, 2, 3 instead of down, 255,
254, 253. If you count up then the other site does not see every packet. If you count down, the other
site has a big signature since so many packets get to them. Scan detect code will probably notice
what the attacker is doing, even if you don’t have a signature for that particular port.
9
IDIC - SANS GIAC LevelTwo
©2000, 2001
9
RingZero? 2
00:51:36.515153 212.209.62.2.1170 >
142.62.0.108.8080: S 126571:126571(0) win
8192 <mss 1460> (DF) (ttl 18, id 9986)
00:51:36.515310 212.209.62.2.1170 >
142.62.0.108.8080: S 126571:126571(0) win
8192 <mss 1460> (DF) (ttl 17, id 9986)
...
00:51:36.521579 212.209.62.2.1170 >
142.62.0.108.8080: S 126571:126571(0) win

8192 <mss 1460> (DF) (ttl 1, id 9986)
Can we find evidence of crafted packets?
Notice we are seeing the packets coming to port 8080, also a part of the RingZero pattern. Please
note that the IP ID is lower here than in the previous slide. The fact that they are hitting proxy ports
and that the IP ID is not acting normally makes this suspicious.
Since IP IDs are issued sequentially, the non-packet craft explanation is that the source machine is
actually sending packets that fast. How fast? Now we need to look at the time fields. If we look at
the difference between the TTL 18 packet and the TTL 17 packet in the previous slide, this slide and
the next slide, we see the time between packets is somewhere in the range of .000151. What good is
that information? It means that the source machine is capable of cycling through ALL of its IP IDs
in just under 10 seconds. Since the delay time is much higher than that between port numbers, about
a minute, the IP ID might well not be crafted, but simply the result of turnover.
Obviously, you don’t want to calculate speed from only three data points, so as a sanity check, you
can compare the delta between the first two packets and the TTL 1 packet. You see that all the
packets kept streaming at about the same speed; this is also true on the next slide. On this slide there
was some huge delay (compared to the speed we are able to achieve). Either the sending system got
busy or the Internet got congested. At the end of the exercise though, you know that the source host
is able to send packets at a high rate of speed.
10
IDIC - SANS GIAC LevelTwo
©2000, 2001
10
RingZero? 3
00:52:24.638450 212.209.62.2.1248 > 142.62.0.108.3128:S
174756:174756(0) win 8192 <mss 1460> (DF) (ttl 18,id
14851)
00:52:24.638597 212.209.62.2.1248 > 142.62.0.108.3128: S
174756:174756(0) win 8192 <mss 1460> (DF) (ttl 17,id
14851)
...

00:52:24.640191 212.209.62.2.1248 > 142.62.0.108.3128: S
174756:174756(0) win 8192 <mss 1460> (DF) (ttl 1, id
14851)
Can we find evidence of crafted packets?
Key to Understanding: What would most analysts see?
A BIG RingZero scan (TTLs are counting down) and
would report it as such.
There is one other possibility to consider, that there is a routing problem and the packets are ping
ponging back and forth. Obviously, if we could examine the link layer and see the MAC addresses,
we could answer this in short order. We think this is NOT correct, however. If it was a routing
problem resulting in ping ponging, the packets would begin to saturate the link of the screwed up
router. After all, the problem should not only happen with one address. So, if each group of packets
was slower than the first, a routing problem should be considered.
So what do we know? This certainly appears to be proxy scanning. The IP IDs can be explained as
a natural result of the system’s potential speed. The TTLs cannot be explained naturally unless you
decide this is a misconfigured router. 18 packets/minute is not enough to be an effective Denial of
Service.
The bottom line: who can say! But this was a great opportunity to apply analysis to the packet fields.