Categories
Troubleshooting

tcpdump filters

A common step in troubleshooting is finding out what not to troubleshoot. With a packet capture you can confirm things such as routing, firewall rules, and remote services.

OSI Model from wikipediaOnce you can prove that a packet is coming back, then you can prove that all layers of the OSI model below are working. For example, if you get an ACK, then you know a few things:

  • Layer 1 hardware is probably on and functioning
  • Layer 2 Addressing is likely working
  • Layer 3 Routing would appear to be working
  • Layer 4 Transport is likely working

Session, presentation and application might not be working at this point, but you’ve ruled out several things that don’t need to be tested.
You can do detailed packet captures that look for additional information to verify if layers 5,6 and 7 are working, but this should save you some time to know that layers 1-4 are operational.
It’s possible that intermittent errors, or bandwidth related errors could be hiding, and a packet capture can still help you find this type of error too.
Every serious network and security professional should know how to use tcpdump.
Here are my tcpdump notes, perhaps you’ll find them handy too:

Basic tcpdump flags

-i <interface>
Specify which intterface to capture, defaults to lowest numbered interface
-q
Quick output. Print less protocol information so output lines are shorter, easier to read.
-X
Show binary and hex data
-n
Do not perform DNS lookup, just show the IP
-v
Show additional information, -vv shows more, -vvv shows even more
-s <size>
Size of the Packet, (-s 1514)
-S
Print absolute, rather than relative TCP sequence numbers
src (net)
The source IP of the filter (src 1.1.1.1). src net can be used to specify a network, in CIDR: (dst net 1.1.1.0/24)
dst (net)
The destination IP of the filter (dst 1.1.1.1). dst net can be used to specify a network, in CIDR: (dst net 1.1.1.0/24)
(src|dst) port
which port specifically, can be named ports, or specific port. (dst port 80)
-w <filename>
The name of the file to write out your packet capture to (-w filename.cap)
and
combine filters (and src net 1.1.1.0/24)
not
negate filters (and not dst port 22)

tcpdump filter examples

Here is a list of several ways to build filters, and some of the more common ways that you might want to view data.

tcpdump -nS
Very basic communication.
tcpdump -nnvvS
Basic, verbose communication.
tcpdump -nnvvXS
Get the packet payload, but that’s all
tcpdump -nnvvXSs 1514
Full packet capture with all details
tcpdump host 1.2.3.4
Show traffic to and from 1.2.3.4
tcpdump src 1.2.3.4
Show all traffic from 1.2.3.4
tcpdump dst 4.3.2.1
Show all traffic to 4.3.2.1
tcpdump net 1.2.3.0/24
Look at traffic to and from 1.2.3.0/24
tcpdump port 3389
Remote Desktop example
tcpdump udp and src port 53
specify protocol combined with src port (DNS filter example)
tcpdump portrange 1000-2000
Do you need an explanation? If so, perhaps another article is better for you.
tcpdump -i any -nnvvXSs 1514 -c 100 src 1.2.3.4 port 443 -w capturefile
Capturing full packet, fully verbose, limit to 100 of them, with IP and port filter, write to capturefile for later analysis.
tcpdump -nnvvXSs 1514 src net 192.168.0.0/16 and dst net 10.0.0.0/8 not dst port 22
Like previous tcpdump filter, but also limiting between 2 networks, and ignoring port 22

3 way Handshake Troubleshooting With tcpdump

We are able to confirm routing, firewall rules, and remote service response by looking at the type of packet that comes back:


tcpdump ‘tcp[13] & 2!=0’
SYN messages tell us that at least our client is sending it’s initial outbound message. If that’s all we see, then nothing is coming back and routing could be bad, or the remote server could be down.
tcpdump ‘tcp[13] & 16!=0’
ACK is the acknowledge message. We can see that the traffic is going all the way to and from the client/server and the server is responding.
tcpdump ‘tcp[13]=18’
SYN ACK packets shows active communication between client and server. Routes, ACLs, and Firewall rules are good.
tcpdump ‘tcp[13] & 4!=0’
RST packets. RST packets are sent back from the service, so at least you know the path is good and not blocked by an ACL or firewall.
tcpdump ‘tcp[13] & 1!=0’
FIN packets. FIN packets are sent back from the service, so you also know path and firewall or ACL rules are not blocking.

tcpdump Statistics

Often, on a network a few hosts will be infected, but it’s hard to tell which ones those hosts are. Here is a quick method to help you determine who is spewing the most traffic:
First, get a packet capture of the data that is of interest to you, you can get basic packets, or all of it if you want to review it later. In my example I want to review it later, so I’m capturing the entire packet, with a bit of detail:

#  tcpdump -i any -nn -X -vv -s 1514 -c 1000 -w packetcap.cap 

Next run it through awk to display some statistical information:

# tcpdump -nr packetcap.cap | awk '{print }' | grep -oE '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}' | sort | uniq -c | sort -n

Which produces:
Now I could use tools like nslookup, whois, etc to determine what the most trafficked IP addresses are and adjust my firewall rules accordingly.

Sample tcpdump Output

tcpdump packet capture example


basic communications tcpdump packet capture example

References and Credits:

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.