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

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

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 >

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

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.