1 1 Network Traffic Analysis Using tcpdump Judy Novak Judy Novak jhnovak@ix.netcom.com 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 • tcpdump event of interest will be displayed • We’ll walk through the analysis process complete with missteps to see how it is actually done In this section, we’ll examine the practical day-to-day aspects of analyzing traffic. 4 4 Event of Interest 1 • The following records appear in the hourly wrap-up 00:36:00.510000 1.2.3.4.2413 > 192.168.30.77.2444: udp 3850 (frag 21931:1480@0+) 00:36:00.620000 1.2.3.4.2413 > 192.168.30.77.2444: udp 3850 (frag 28843:1480@0+) 00:36:00.710000 1.2.3.4.2413 > 192.168.30.77.2444: udp 3850 (frag 33707:1480@0+) 00:36:00.830000 1.2.3.4.2413 > 192.168.30.77.2444: udp 3329 (frag 40875:1480@0+) 00:36:00.910000 1.2.3.4.2413 > 192.168.30.77.2444: udp 3850 (frag 46251:1480@0+) 00:36:01.020000 1.2.3.4.2413 > 192.168.30.77.2444: udp 3850 (frag 52907:1480@0+) On the hourly wrap-up we see fragmented UDP packets arriving from source host 1.2.3.4. One of the first questions should be what filter extracted these records followed by why are they being brought to your attention. 5 5 Initial Assessment • Records appeared on hourly wrap-up because of 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 21931:1480@0+) 00:36:00.620000 1.2.3.4.2413 > 192.168.30.77.2444: udp 3850 (frag 28843:1480@0+) 00:36:00.710000 1.2.3.4.2413 > 192.168.30.77.2444: udp 3850 (frag 33707:1480@0+) 00:36:00.830000 1.2.3.4.2413 > 192.168.30.77.2444: udp 3329 (frag 40875:1480@0+) 00:36:00.910000 1.2.3.4.2413 > 192.168.30.77.2444: udp 3850 (frag 46251:1480@0+) 00:36:01.020000 1.2.3.4.2413 > 192.168.30.77.2444: udp 3850 (frag 52907:1480@0+) What appears in the output is exactly what we saw on the hourly wrap-up. Although we asked to see all fragments, we still see only the first fragment. At this point, we have to wonder why we see the same records as before. Do we see these results because this is what is truly all there is in the hourly files? Or, perhaps, for some reason, we haven’t extracted the records. 8 8 Re-examination • tcpdump output on the previous slide appears to indicate only first fragment was sent • Is this some kind of malicious attack or denial of service that sends only an initial fragment? • Examine filter used to select records, we used ‘host 1.2.3.4 and port 2444’ • Remember subsequent fragments don’t carry UDP header with port number 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+) 00:36:00.620000 1.2.3.4 > 192.168.30.77: (frag 28843:1480@1480+) 00:36:00.620000 1.2.3.4 > 192.168.30.77: (frag 28843:898@2960) 00:36:00.710000 1.2.3.4.2413 > 192.168.30.77.2444: udp 3850 (frag 33707:1480@0+) 00:36:00.710000 1.2.3.4 > 192.168.30.77: (frag 33707:1480@1480+) 00:36:00.710000 1.2.3.4 > 192.168.30.77: (frag 33707:898@2960) The results yield all fragments. If you look at the individual fragments and examine the fragment lengths and the offsets, it appears that this is normal fragmentation in terms of not having any overlaps or gaps of repeated offsets. Look at the second set of fragments with fragment ID 28843. The first fragment is 1480 bytes and the offset is byte 0. The second fragment starts at byte 1480 and has a length of 1480; this is normal. Finally, the third fragment begins at the expected offset of 2960 for a length of 898 bytes. [...]... that the length is 1 byte long What is wrong with this value? Remember that the UDP header has fields such as the source and destination ports These ports, if you recall, have a range of values from 1 to 65,535 How many bytes are needed to represent the maximum value of 65,535? 216 -1 represents two 8 bit fields or 2 bytes for each port Minimally, you can see we need at least 4 bytes in the UDP header... minimum datagram length is 8 bytes The UDP datagram length includes the UDP header; there are always 8 bytes in the UDP header The culprit in translation of the UDP datagram length appears to be tcpdump tcpdump must not do error checking before trying to compute the UDP length Somehow, the algorithm goes awry on computation and we end up with the wrong UDP length What was the 1 byte UDP length all about... 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 21 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... 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 21 Event of Interest 4 • The following output appears in the hourly wrap-up: 05:52:23.040000 wiley.ns.demon.net.15770 >mydns.com.80:... 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... >mydns.com.80: udp 4294967289 4500 00c8 58d2 0000 3411 f19c 2222 3333 4444 5555 3d9a 0050 0001 a3c7 0904 18ba 5010 2238 27b5 0000 0469 6373 7705 6465 6d6f 6e02 636f 27 We examine the UDP datagram length by dumping the datagram in hexadecimal We also try to zero in on the exact record using the port number in the mutant record This will prevent us from dumping all the previous traffic between those two... Initial Guess • What is your initial assessment of Event of Interest 2? • Did you guess a SYN/ACK scan from hostile host 1.2.3.4 to destination port 39426? • An unsolicited SYN/ACK can trigger a RESET by the receiving host • Possible way to scan for live hosts? 13 A good initial guess is that this is some kind of scan originating from hostile host 1.2.3.4 An unsolicited SYN/ACK combination to a destination... port Minimally, you can see we need at least 4 bytes in the UDP header to represent the port fields 28 Assessment • Actual datagram has a UDP length of 1 • Minimum UDP length 8 - UDP header requires 8 bytes • UDP length field has been crafted • tcpdump does not have any error checking rules when it attempts to compute decimal UDP length • tcpdump algorithm used to compute UDP length is inaccurate when... 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 17 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 (DF) 03:44:35.300000 1.2.3.4.3953 > myhost.com.135: P 409085716:409085788(72)... world • Many hit non-existent IP’s • Appeared to be a random (no previous reconnaissance) scan of our IP’s • Received reports from other sites they were seeing same kind of activity 31 We were alerted by the Naval Surface Warfare Center of scans on port 3128 Port 3128 is a web proxy server known as squid We had not been viewing traffic to this port because of the rate of false positives, however we . 1 1 Network Traffic Analysis Using tcpdump Judy Novak Judy Novak jhnovak@ix.netcom.com Step by Step Analysis All material Copyright  Novak,. rights reserved. 2 2 Step by Step Analysis • Introduction to tcpdump • Writing tcpdump Filters • Examination of Datagram Fields • Beginning Analysis • Real