tcpdump

• -i any : Listen on all interfaces just to see if you're seeing any traffic.
• -n : Don't resolve hostnames.
• -nn : Don't resolve hostnames or port names.
• -X : Show the packet's contents in both hex and ASCII.
• -XX : Same as -X, but also shows the ethernet header.
• -v, -vv, -vvv : Increase the amount of packet information you get back.
• -c : Only get x number of packets and then stop.
• -s : Define the size of the capture (use -s0 unless you are intentionally capturing less.)
• -S : Print absolute sequence numbers.
• -e : Get the ethernet header as well.
• -q : Show less protocol information.
• -E : Decrypt IPSEC traffic by providing an encryption key.
• -s : Set the snaplength, i.e. the amount of data that is being captured in bytes
• -c : Only capture x number of packets, e.g. 'tcpdump -c 3'

Basic Usage

So, based on the kind of traffic I'm looking for, I use a different combination of options to tcpdump, as can be seen below:

1. Basic communication // see the basics without many options
   
   # tcpdump -nS
2. Basic communication (very verbose) // see a good amount of traffic, with verbosity and no name help
   
   # tcpdump -nnvvS
3. A deeper look at the traffic // adds -X for payload but doesn't grab any more of the packet
   
   # tcpdump -nnvvXS
4. Heavy packet viewing // the final "s" increases the snaplength, grabbing the whole packet
   
   # tcpdump -nnvvXSs 1514

• host // look for traffic based on IP address (also works with hostname if you're not using -n)
  
  # tcpdump host 1.2.3.4
• src, dst // find traffic from only a source or destination (eliminates one side of a host conversation)
  
  # tcpdump src 2.3.4.5
  # tcpdump dst 3.4.5.6
• net // capture an entire network using CIDR notation
  
  # tcpdump net 1.2.3.0/24
• proto // works for tcp, udp, and icmp. Note that you don't have to type proto
  
  # tcpdump icmp
• port // see only traffic to or from a certain port
  
  # tcpdump port 3389
• src, dst port // filter based on the source or destination port
  
  # tcpdump src port 1025
  # tcpdump dst port 389
• src/dst, port, protocol // combine all three
  
  # tcpdump src port 1025 and tcp
  # tcpdump udp and src port 53

You also have the option to filter by a range of ports instead of declaring them individually, and to only see packets that are above or below a certain size.

• Port Ranges // see traffic to any port in a range
  tcpdump portrange 21-23
• Packet Size Filter // only see packets below or above a certain size (in bytes)
  tcpdump less 32
tcpdump greater 128
[ You can use the symbols for less than, greater than, and less than or equal / greater than or equal signs as well. ]
// filtering for size using symbols tcpdump > 32 tcpdump <= 128

Writing to a File

tcpdump allows you to send what you're capturing to a file for later use using the -w option, and then to read it back using the -r option. This is an excellent way to capture raw traffic and then run it through various tools later.
The traffic captured in this way is stored in tcpdump format, which is pretty much universal in the network analysis space. This means it can be read in by all sorts of tools, including Wireshark, Snort, etc.

Capture all Port 80 Traffic to a File

# tcpdump -s 1514 port 80 -w capture_file

Then, at some point in the future, you can then read the traffic back in like so:

Read Captured Traffic back into tcpdump

# tcpdump -r capture_file

Getting Creative

Expressions are nice, but the real magic of tcpdump comes from the ability to combine them in creative ways in order to isolate exactly what you're looking for. There are three ways to do combinations, and if you've studied computers at all they'll be pretty familar to you:

1. AND
   and or &&
2. OR
   or or ||
3. EXCEPT
   not or !

More Examples

# TCP traffic from 10.5.2.3 destined for port 3389

tcpdump -nnvvS and src 10.5.2.3 and dst port 3389

# Traffic originating from the 192.168 network headed for the 10 or 172.16 networks

tcpdump -nvX src net 192.168.0.0/16 and dst net 10.0.0.0/8 or 172.16.0.0/16

# Non-ICMP traffic destined for 192.168.0.2 from the 172.16 network

tcpdump -nvvXSs 1514 dst 192.168.0.2 and src net and not icmp

# Traffic originating from Mars or Pluto that isn't to the SSH port

tcpdump -vv src mars and not dst port 22

As you can see, you can build queries to find just about anything you need. The key is to first figure out precisely what you're looking for and then to build the syntax to isolate that specific type of traffic.

Well, for those that deal with TCP/IP a lot, I thought it might be helpful to have a mnemonic for the TCP flags as well. What I've come up with and use regularly is:
Unskilled Attackers Pester Real Security Folks
Unskilled = URG
Attackers = ACK
Pester = PSH
Real = RST
Security = SYN
Folks = FIN

TCP flag information is most helpful to me when looking for particular types of traffic using Tcpdump. It's possible, for example, to capture only SYNs (new connection requests), only RSTs (immediate session teardowns), or any combination of the six flags really. As noted in my own little Tcpdump primer, you can capture these various flags like so:
Find all SYN packets
tcpdump 'tcp[13] & 2 != 0'
Find all RST packets
tcpdump 'tcp[13] & 4 != 0'
Find all ACK packets
tcpdump 'tcp[13] & 16 != 0'

Notice the SYN example has the number 2 in it, the RST the number 4, and the ACK the number 16. These numbers correspond to where the TCP flags fall on the binary scale. So when you write out:
U A P R S F
...that corresponds to:
32 16 8 4 2 1===============

Writing tcpdump captures to a file and displaying them at the same time (source:https://community.mcafee.com/people/sliedl/blog/2010/12/15/writing-tcpdump-captures-to-a-file-and-displaying-them-at-the-same-time)

When you capture packets using tcpdump, you can either display them to the screen (standard out), redirect standard out to a file (using >), or write the raw packets to a binary file (using the -w flag in tcpdump).

What if you wanted to both capture packets to a file AND display them on a screen at the same time?

For this, you can use the 'tee' command.  From the man page of tee, here's the description: "The tee utility copies standard input to standard output, making a copy in zero or more files.  The output is unbuffered."  The syntax of the command is tee output_file, where tee writes the output of whatever command precedes it to a file named output_file.

As a small test, let's see what this command does:

$> hostname | tee host_output
sw1.fwdomain.com

$> cat host_output
sw1.fwdomain.com

The first command displayed the output of 'hostname' to my shell and wrote it to a file.  The second command simply opened the text file and displayed it to our screen.  You can see that the tee command allows you to see the output of a command and write it to a file at the same time.

To use this with tcpdump, our first instinct would be to simply put 'tcpdump -npi em0 | tee output_file'.  If you do that though, you'll see that tcpdump does not instantly write all its packets to the screen (or to the file).  You need to use the -l (lowercase L) flag with tcpdump to make standard out line-buffered, so that it will write each packet as it arrives:

$> tcpdump -l -npi em0 | tee output_file

This will cause every packet tcpdump receives to be written to standard out (and thus to 'tee' and its output_file) whenever a packet is received.

You can do the "same thing" (sort of) if your tcpdump command is writing to a raw binary file (using the -w flag).  You must use the -U flag in this case:

$> tcpdump -U -npi em0 -w dump.cap

This command will never write to the screen (it's writing to the dump.cap file).  But, in a different shell on the firewall (a different SSH session let's say) you can run this command to read this file as it's written:

$> tcpdump -r dump.cap

Every time you run this command it will open and display the dump.cap file to your screen.  If the tcpdump command is continuing to capture packets you will have to re-run this command to display those newly-captured packets as well.

Example

So as you read the SYN capture tcpdump 'tcp[13] & 2 != 0', you're saying find the 13th byte in the TCP header, and only grab packets where the flag in the 2nd bit is not zero. Well if you go from right to left in the UAPRSF string, you see that the spot where 2 falls is where the S is, which is the SYN placeholder, and that's why you're capturing only SYN packets when you apply that filter.

# tcpdump 'tcp[13] & 2 != 0'