Network and Security: October 2012

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.

Once 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: