1
1
Network Traffic Analysis
Using tcpdump
Judy Novak
Judy Novak

Step by Step Analysis
All material Copyright  Novak, 2000, 2001. All rights reserved.
2
2
Step by Step Analysis
•
Introduction to tcpdump
•
Writing tcpdump Filters
•
Examination of Datagram Fields
•
Beginning Analysis
•
Real World Examples
•
Step by Step Analysis
This page intentionally left blank.
3
3
Objectives
•
Allow you to participate in the analysis process
•

fragmentation
•
IP filter looks for IP datagrams with more
fragments flag set and zero fragment offset
•
So we see only first fragment
•
Need to verify if this is normal or malicious
These records appeared on the hourly wrap-up because ip.filter examines the IP header for any
datagram that has the more fragments flag set and a zero fragment offset. This will display only the
first fragment. The reason that this was done was to alert you of the fragmentation, yet not
overwhelm you with all the records.
As mentioned before, fragmentation can be a normal by-product of a datagram travelling from a
larger to a smaller network. We’ve also seen where fragmentation can be used for malicious
purposes such as denial of service. We need to examine this fragmentation to see if it appears to be
normal - no overlaps or gaps in fragments and a complete fragment train.
6
6
Dump Fragmented Records
•
We attempt to see the other fragments using the
following command:
tcpdump –r tcpdumpfile ‘host 1.2.3.4 and port 2444’
In an effort to dump the records associated with this fragmentation, we examine the hour in question
with a filter of the host IP and the destination port number. We use the port number to isolate the
traffic we saw in case there are more connections to other ports that we don’t care to see.
7
7
Results
00:36:00.510000 1.2.3.4.2413 > 192.168.30.77.2444: udp 3850 (frag

Because we only see the first fragment of the fragment train, the initial guess is that this may be
some kind of malicious fragment attack perhaps a denial of service. We should see all fragments in
the fragment train, not just the first.
However, if we re-examine the filter we used, we qualified the traffic by port number. The port
number is located in the UDP header. Recall from the discussion on fragmentation that only the first
fragment in the fragment train inherits the protocol header, or UDP in this case. All subsequent
fragments only carry the remaining UDP data. Therefore, when we search by port number, only the
first fragment appears.
9
9
Another Attempt
•
We make another attempt to dump the
fragmented records, but we search by IP number
only
tcpdump –r tcpdumpfile ‘host 1.2.3.4’
Attempting to dump the traffic again, we filter by source IP only. The source IP is located in the IP
header and will be found in all the fragments.
10
10
Results
00:36:00.510000 1.2.3.4.2413 > 192.168.30.77.2444: udp 3850
(frag 21931:1480@0
+)
00:36:00.510000 1.2.3.4 > 192.168.30.77: (frag 21931:1480@1480
+)
00:36:00.510000 1.2.3.4 > 192.168.30.77: (frag 21931:898@2960
)
00:36:00.620000 1.2.3.4.2413 > 192.168.30.77.2444: udp 3850
(frag 28843:1480@0+)

protocol fields, in this case, the UDP port number, you will receive incomplete data and you may
come to false conclusions.
12
12
Event of Interest 2
•
The following records were dumped when 1.2.3.4
appeared in the Shadow’s scan output
19:45:38.650000 1.2.3.4.113 > 192.168.173.120.39426: S 11235938:11235938(0)
ack
614006785 win 32736 <mss 512>
19:47:21.490000 1.2.3.4.113 > 192.168.162.39.39426: S 6825290:6825290(0) ack
614006785 win 32736 <mss 512>
19:55:40.780000 1.2.3.4.113 > 192.168.213.61.39426: S 9268522:9268522(0) ack
614006785 win 32736 <mss 512>
19:57:17.210000 1.2.3.4.113 > 192.168.171.84.39426: S 4259938:4259938(0) ack
614006785 win 32736 <mss 512>
19:57:32.000000 1.2.3.4.113 > 192.168.21.26.39426: S 7249258:7249258(0) ack
614006785 win 32736 <mss 512>
19:57:49.800000 1.2.3.4.113 > 192.168.208.80.39426: S 4354234:4354234(0) ack
614006785 win 32736 <mss 512>
The hourly scan count from Shadow listed host 1.2.3.4 as exceeding 7 connections to internal hosts.
The records were dumped for this hour to investigate what kind of activity host 1.2.3.4 was involved
in. We see a scan from host 1.2.3.4 source port 113 directed at the internal 192.168 hosts going to
port 39426 (unknown port) with the SYN and ACK flags set.
It should be noted that all the destination IP’s in the 192.168 subnet are not assigned IP’s.
13
13
Initial Guess
•

Host 1.2.3.4 responds with a SYN/ACK directed
back to actual 192.168 network
Now, if you take a slightly different approach to viewing this traffic, it may appear that 1.2.3.4 was
simply an intermediate or victim host. What may be happening is that some malicious party for
whatever reason may be spoofing the internal 192.168 IP addresses and sending them to host 1.2.3.4
port 113. If port 113 is listening, it will reply with a SYN/ACK to the alleged source IP.
Port 113 is known as auth or ident. It is used to authenticate a user requesting a service. For
instance, when connections to some servers are made, for example sendmail, the server may try to
connect to the client host on port 113. This is a rather primitive way of trying to authenticate the
user. Not all servers query for port 113 and not all clients will offer port 113.
We see no RESETs from the 192.168 hosts because they are not live hosts.
15
15
More Clues
•
In order to get a SYN/ACK response back from
1.2.3.4 on port 113, port 113 must be active
telnet 1.2.3.4 113
Trying 1.2.3.4...
Connected to 1.2.3.4.
Escape character is '^]’
•
This confirms that the host 1.2.3.4 offers the auth
service (port 113)
To see if the spoofing theory is a viable one, host 1.2.3.4 must be listening on port 113. We try a
telnet to host 1.2.3.4 port 113 and see that it responds. This isn’t positive confirmation that this is
the answer, however it does lend more credence to the spoofing theory.
16
16
Assessment

tcpdump –r tcpdumpfile ‘host 1.2.3.4’
We see an initial SYN from a foreign host and would like to examine all the traffic from the
unknown source host. So, we dump the hourly records for the foreign IP 1.2.3.4.
18
18
Partial Results
•
Here is one TCP session extracted by looking at
the data exchanged between the hosts:
03:44:34.950000 1.2.3.4.3953 > myhost.com.135: S
409085715:409085715(0) win 8192 <mss 1460> (DF)
03:44:35.300000 1.2.3.4.3953 > myhost.com.135: P
409085716:409085788(72) ack 174349 win 8760 (DF)
03:44:35.360000 1.2.3.4.3953 > myhost.com.135: P 72:228(156)
ack 61 win 8700 (DF)
03:44:35.430000 1.2.3.4.3953 > myhost.com.135: F 228:228(0)
ack 213 win 8548 (DF)
In the TCP exchange above, we do not see the entire session. It appears we are only seeing traffic
from 1.2.3.4 directed to myhost.com, but none from myhost.com to 1.2.3.4. We know this because
we see a SYN from 1.2.3.4 to myhost.com, but no SYN/ACK in return. We see data pushed from
1.2.3.4 to myhost.com, but no ostensible acknowledgement. Finally, we see 1.2.3.4 end the session,
but no acknowledgement or session termination from myhost.com.
19
19
Initial Assessment
•
Is it possible for this to be a crafted session from
1.2.3.4?
•
If this were so, you should see RESET’s from

refutes the theory that we were capturing inbound traffic only. In fact, this appears to be a fairly
complete session except for the absence of the final ACK in the three-way handshake and some of
the expected termination protocol.
21
21
Another Assessment
•
See evidence in previous slide that we are
capturing some traffic outbound from
myhost.com
•
Appears we have some kind of intermittent
sensor capture
•
Dropping packets on the sensor?
•
Multiple ingress/egress points and we see only
traffic that passes by the sensor on a given
transfer
Since we’ve seen traffic going both ways, the sensor is obviously situated correctly to see inbound
and outbound traffic. But, it appears we are not capturing all the traffic. Is it possible that the sensor
is overloaded and dropping packets? This is a possibility and that could be happening. There is no
easy way to tell if packets are being dropped.
The other possibility is that there are multiple entry and exit points into the network and the route
taken each time doesn’t necessarily take the traffic by the sensor. The site configuration and sensor
placement should be re-examined.
22
22
Event of Interest 4
•

We detect some output from Shadow that appears to be abnormal. There is a value of 4294967289
in the UDP length field. There are a couple of problems with this. The first is that the UDP length
field is a 16 bit value in the UDP header. The maximum possible value for a length would be
65,535. How could tcpdump possibly report such a large value?
Also, how is it possible that fragmentation did not occur with a UDP datagram length so large?
What tools have we covered in this course to help us assess what is happening?
24
24
Investigation
•
First, check traffic from the hostile source IP for
the hour in question
•
Could there be some kind of catalyst for receiving
this datagram?
tcpdump –r tcpdumpfile ‘host hostile IP’
The first thing we do is examine the traffic for the hour in question. This will just help us put the
traffic in some kind of context. It may not explain the mutant UDP datagram length, but we might
be able to see why this record appeared.
Note that we search using the hostile IP number for wiley.ns.demon.net. Searching by IP is more
efficient and perhaps more accurate since additional resolution does not have to be done. If
resolution cannot be done for wiley.ns.demon.com, no records will appear even though there are
records in the tcpdump files for the IP number associated with wiley.ns.demon.com.
25
25
Results From tcpdump
05:52:21.560000 mydns.com.domain > wiley.ns.demon.net.domain: 25303 (38)
(DF)
05:52:21.650000 wiley.ns.demon.net.domain > mydns.com.domain: 25303*-
1/3/3 (176)