Introduction to TCPDUMP

this video is a look at using TCP dump for capturing and analyzing packets on network interfaces it will look at how to use TCP dump by example on a demo virtual machine the topics covered will include starting captures understanding the capture display output saving captures to a file reading from existing capture files using filter expressions to isolate traffic for capture or for display and changing display options for more information on TCP dump please go to ww2 CPG org or review the TCP dump man page before we jump in a quick definition TCP dump is utility used to capture and analyze packets on network interfaces details about these packets can either be displayed to the screen or they can be saved to a file for later analysis TCP dump utilizes lib pcap library for packet capture when troubleshooting or investigating network conditions TCP dump is like taking the cover off the network to look inside and see what is really going on so let's jump right in and start using it version checking assuming TCP dump is installed version information can be obtained with TCP dump - H on this system we can see the TCP dump version is 4.4 to zero and the lid P cap version is 1.4 to zero in this video all examples are on an in Boone - VM we have running in VirtualBox running TCP dump the first thing to note is TCP dump requires super user privileges therefore in this video all commands are prefaced with the sudo keyword to run TCP dump the available interfaces for packet captures needs to be determined if these are not already known they can be checked with TCP - D on this VM eat zero eighth one any and the loopback interfaces are available the any option is the sudo interface that can display packets from all interfaces let's capture packets on all interfaces by using the any option now we see packets are moving by way too fast to read TCP dump will not stop without an interrupt signal so to stop the capture I'll use ctrl + C instead of letting TCP dump run until interrupted you can use the lowercase C option this option instructs the utility to stop after the specified number of packets are captured in the output we can see host names are being used instead of IP addresses also commonly known ports are replaced with application names usually however it is easier to work with IP addresses and port numbers instead of these names the lowercase n option will take care of this now the output shows IP addresses and port numbers when TCP dump is run without the - an option the utility will trigger reverse or PTR DNS lookups to find host names for IP addresses as it captures them this is good to keep in mind to realize TCP dump is itself triggering DNS traffic as it captures if the - end option is not used capture packet size and the second line you can see it says the capture size is 65,535 bytes this means that for every packet TCP dump will keep 65,000 bytes for analysis this is much larger than the typical packet size so essentially this is saying TCP dump is capturing full packets it's important to note the default capture size some versions of TCP dump default - much smaller capture sizes for example 96 bytes this would mean just the first 96 bytes of every packet is captured and the rest is thrown away the capture size can be altered with the lowercase s option here you can see I've requested just 96 bytes for each packet instead of the default I had of 65,000 specifying 0 with the - s option means maximum size or 65,000 as was seen in the default when performing captures it's important to think about the goal when deciding the packet size to set for example if you're just looking for evidence of lost or out of order packets on a large file transfer you probably don't need much more than 64 or 96 bytes of each packet alternatively if you're troubleshooting problems at the application layer you may require having full packets with nothing thrown out in that case the max size of 65,000 should be plenty TCP dump output here's a look at the fields displayed in the TCP dump output for some TCP packets first there is a time stamp for in lid P cap picked up the Paquette on this VM we can see values down to milliseconds and even to microseconds next the protocol is specified after this is the source IP of the packet a dot and then the source port of the packet after the source IP in port is the destination IP import these addresses are followed by TCP flags which could be syn ACK reset fin urgent and push all the flags are represented by the first letter with the exception of ACK which is represented by simply a dot for an example I'll generate some traffic over my eath one interface to another VM first to a closed port on the other VM and then to an open port when connecting to the closed port we can see a syn packet from IBM and immediately we see a reset from the other VM then when connecting to port 22 through SSH which is open we see the normal three-way handshake first the syn and then the syn ACK and return and finally the ACK the next fields are the sequence and acknowledgement numbers TCP dump by default uses relative numbers here let's look at an example for now you can ignore the filter expression I use because I'll cover that later this capture just looking at one direction of traffic on one TCP session in the first captured packet the real sequence numbers are displayed these long numbers here sequence numbers are 32 bits long after that first packet TCP dump switches over to showing relative sequence members because they are easier to track so here in the second packet was three of a sequence number of 196 and it goes up through sequence number 359 the last number on the right here 360 is actually the first expected byte number on the next packet so here we have bytes 196 to 359 then on the next one we have 362 for 91 and on the next packet 492 to 623 and if you follow this down you'll see these sequence numbers increasing as we would expect after the sequence numbers we have acknowledgment numbers which again TCP dump changes to relative numbers so as an example in this capture we can see that we have here in the middle sequence number 1308 through 1535 then 1536 there's 1683 we have all those bytes passed through and then the receiving host sends back in acknowledgment 1684 saying it expects to see sequence number or byte number 1680 for next and after this we do see the sending host sends packet number 1680 for up through 1831 and then 1832 up to 1963 and again we see a new knowledge meant for 1964 the next expected sequence number incidentally relative secrets numbers can be turned off of the uppercase s option after the sequence an acknowledgement numbers is the receive window size here we can see a window size of 333 however this is actually not the real receive window because window scaling is enabled to be able to see that window scaling is enabled you need to go back to the three-way handshake this is where the window scaling option would be noted and where the scaling factor is defined here in the syn packet from IP 74 dot 125 that 224 46 a scaling factor of seven is seen this actually means to multiply the receive window by 2 to the power of 7 so down here we're looking at the receive window size of 333 you actually need to multiply this by 2 to the power of 7 which is 128 this means the real receive window is 128 times 333 which comes out to over 42,000 bytes for a receive window finally there is the packet length this shows how many bytes are present inside the layer 4 headers for example here a length of 108 assuming this matches up with the sequence numbers discussed a moment way to go on this packet we can see it says 1 to 109 if you subtract 109 from 1 you get the length of 108 on this packet is 1 to 577 again subtracting 577 minus 1 gives the length of 576 let's look at sample output for DNS requests here is a capture on port 53 DNS of course uses UDP port 53 now I'll do a double you get to youtube.com to generate some DMS traffic in the capture display we can see the demo VM made two requests back-to-back first in a record query which is an ipv4 query for youtube.com after that is a quad a query for youtube.com so this is for ipv6 next there are the responses for the a query there are 11 IPs returned back from IEEE DNS server for quad a for ipv6 one record came back in response after this is some interesting activity it looks like there is an HTTP redirect 2ww youtube.com/ so my VM query DNS for that fqdn on ipv4 and ipv6 the responses for www.youtube.com/user/stielv is used to save captures to a file for later analysis this is done using the lowercase W option now the capture is being written to the file captured pcap an issue here is there is no indication of how many packets are being written or if any at all are being captured so when writing packets to a file the lowercase V option is very helpful now we can see the number of packets captured again TCP dump will continue to run until interrupted when writing to a file and capturing on high traffic interfaces the file can grow quite large very fast this can pose a problem on a system which lacks sufficient storage space a good way to limit the file size is to use the lowercase C option here this capture will write to the file captured pcap but it will stop after 20 packets reading capture files existing capture files can be read with the - our option the same output a scene as when packets were displayed straight to the screen again pack is go by too quickly on large files so I'll use a pipe and less and that'll help me so I can scroll up and down through the capture TCB dumped filter expressions the use of filters is important when using TCP dump especially when working with very large capture files filters let you lock in on just the types of traffic you are interested in and ignore the rest so let's see some examples host keyword with this capture I'm using the host keyword to specify that I only want to capture traffic going to or from the IP at 10 0 to 0-3 if I now ping that VM in the capture window immediately the ICMP packets are seen all the traffic not relating to 10 dat 0.03 is being ignored for analysis the source and destination keywords this is the same capture as before except that now you added the source keyword SRC destination would have been DST now only one direction of traffic is seen packet sourced from 1000 three the return traffic to tend at zero two zero three in this case is being skipped filter expressions support the use of the logical operators and and or in this capture we only get packets between the two hosts 10 0.01 and 10.0.0.0 we won't see any other traffic for those two IP addresses only traffic between those two IPs filters can be used to isolate traffic to define TCP or UDP ports here only port 80 traffic is captured I'll do a double you get to Google comm and in the capture window the HTTP traffic only on port 80 is seen here is an example of a compound expression port 80 or port 443 traffic is shown but only for the address 192 dot 168 at 191 as the source or destination note the parentheses around the port numbers these are important to include both ports as part of the and statement here if they were not used I would not get the intended result also note when using compound expressions the use of quotes around the entire expression this is required due to the use of parentheses otherwise the parentheses will be interpreted as special bash characters and the capture will not work you more filters filters can be used to include or ignore an entire subnet here is a filter are used to look for traffic heading towards public internet IPs the source of this traffic should be from the network 192 168 0 0 with the slash 16 subnet mask I'm using the net keyword to accomplish this also the destination networks should not be local they should not be in the 192 168 0 0 / 16 or the 1000 0 / 8 subnets filters can be applied based on MAC addresses as well using the ether host keyword this capture is restricted to traffic chewer from this MAC address in the capture output MAC addresses aren't visible by default so to see MAC addresses and captures we use the lowercase e option note we're capturing on the any interface you may not see full Mac information some more filters include protocol type these can include the TCP UDP icmp ARP and r are keywords ipv6 traffic can be viewed with the IP six keyword I'll do a ping to an ipv6 IP and in the capture window that ICMP traffic shows up finally here are some filters based on TCP flags this capture will only show packets with a sin flag set you similarly here is an example to look only for TCP resets you adjusting TCP Dems output TCP dump has some options to adjust the output seen when looking at capture data the - X X option displays more detail about packets specifically in hex format as well as ASCII format here we can see the HTTP GET as asking often the hex is actually not needed so the - a option can be used instead I'll do another W again and here are some ASCII HTTP data the - V option is used to provide more detail or verbosity and packet captures - VV and - vvv will provide increasing levels of detail respectively when displaying more verbosity on my VM TCP dump displays an error indicating there is a checksum error this message is usually because the system has checksum offloading enabled and at the point at which lippy cap grabs packets the correct checksum hasn't yet been inserted this error can be ignored by using the uppercase K option somewhat opposite to the - V options is the - queue option which provides minimal quiet display output one last option I'll look at here is the time stamp display option which uses lowercase T depending on how many T's are used this changes the display for example one T removes time stamps completely three T's shows that difference between consecutive packets in the output this one is useful to look for spikes or slowdowns on particular packet types five T's shows the time since the first packet in the capture which is useful when measuring how long certain transactions take to complete that wraps up this look at tcpdump I hope you found it useful if you'd like to see more videos like this please subscribe to this channel special thanks to those who have subscribed and commented on my videos it's great to hear back from the community as usual if you'd like to contact me directly you can do so through WWI ENCOM /i + / David Muller

Channel: David Mahler

Views: 117,311

Keywords: tcpdump, David Mahler, Linux

Id: hWc-ddF5g1I

Length: 18min 47sec (1127 seconds)

Published: Tue Dec 16 2014