Tcpdump notes: Difference between revisions

Revision as of 13:32, 20 June 2024

📃 These are primarily notes, intended to be a collection of useful fragments, that will probably never be complete in any sense.

TCPdump snoops network traffic going getting to the host it runs on.

It can also filter what packets it shows/writes.

It can summarize the traffic on-screen (the default) or write it to the fairly common pcap-style files.

The 'tcp' in the name is misleading, because it suggests it captures at the network layer, and then specifically TCP. Actually, it captures at link layer, so you can get at a lot of interesting stuff.

Wireshark (previously Ethereal) serves much the same purpose. It has a GUI, more protocol decoding, a more advanced filter language that includes substring and regexp content filtering.

You may also be interested in tshark, which can do more than tcpdump

Usage notes

If the line reporting "packets dropped by kernel" doesn't say 0: This refers to to the packet capture interface (a kernel feature) and doesn't mean the kernel is screwing up your networking, nor does it refer to firewall drops.

The network is moving packets faster than the capturing program is reading them from the capture interface. That is, the kernel isn't waiting around for the capturer (tcpdump) to catch up, it's removing the packets exposed to the capturing.

It seems one reason is that tcpdump is waiting on its own DNS lookups - try tcpdump -n (numeric, no names) to see if that helps.

Interesting command line options

-n: don't resolve hostnames (faster)

-i interfacename: listen on a specific interface. Default is the first it can find. ("-i any" will capture from all interfaces but ''not'' be promiscuous)

-w filename: dump packet data to a file, instead of decoding and printing (tcpdump -r and other utilities take this)

-s 0: capture the whole packet instead of the first 68 bytes (68 is faster and enough for the scrolling screen summary, but not for deeper inspection. You probably want whole packets when writing traffic to files for later inspection)

-t: don't show timestamps (less clutter, though also not as informative)

Print packet as

-A: ASCII (safe to print; command characters are removed)
-x: hex
-X: hex and ASCII
(-xx and -XX are variations that also show the link-level header)

Filter expressions

The filter expression is often enclosed in single quotes. This is not necessary, but is simpler than dealing with shell escaping.

Note that the predefined primitives require a backslash before them.

Apparently the format is the one from BPF, so see things like [1]

Host, net, port

Probably the most directly interesting types filters are things like:

port 53 (matches tcp and udp; "udp port 53" and "tcp port 53" are shorthands that imply the respective protos)
portrange 1024-65535
host 192.168.1.1 (shorthand for "ether proto \ip and host ...")
net 192.168 (shorthand for "ip net ..."), and also:
- net 192.168.5 mask 255.255.255.0
- net 192.168.5/24

When not mentioning src or dst, you accept an address, net, port or such if it appears as either source or destination. So: port 80 would capture your surfing and people connecting to your web server, while src port 80 and dst port 80 look at direction.

If you add a named hosts it is looked up, but redirects and round robin DNS resolving may throw you off (both may happen in the case of google.com).

Protocol constants

"ether proto" things
- ip (shorthand for "ether proto \ip", and actual value is 0x0800)
- arp (shorthand for "ether proto \arp", value is 0x0806)
- rarp ("ether proto \rarp")
- ip6, tr, fddi, decnet
- Others, e.g. 0x8863 for PPPoE Discovery, 0x8864 for PPPoE Session

Example:

ICMP other than pinging: tcpdump 'icmp[icmptype]!=icmp-echo and icmp[icmptype]!=icmp-echoreply'

"ip proto" things:
- tcp (shorthand for "ip proto \tcp")
- udp (shorthand for "ip proto \udp")
- icmp (shorthand for "ip proto \icmp")
- Also: gre, ipx, decnet

(note the absence of backslashes in shorthands)

Logic in filters

Logical booleans:

and, &&
or, ||
not, !

Examples:

'not arp and not port 67' (show all except arp and dhcp)
'net 192.168 && !host 192.168.1.1' (all traffic on this net not related to this specific host)
'net 192.168 || net 145.99' (traffic on my private and public IP net)

Comparison:

eq, == and =
ne, !=
gt, >
lt, <
ge, >=
le, <=

Repetition and omission: lists and short forms

If the predicate is missing, the last is assumed. For example:

net 10 or 192

...does the same as

net 10 or net 192

Lists are supported through a similar sort of expansion:

host ourrouter and not \( ourmailserver or ourwebserver \)

Raw bit/byte testing, and bitwise operations

You can get at packet data, with decimal (or hexadecimal) offsets for a frame/packet at apparently any layer/decoded protocol, including things like ether[], link[], ip[], tcp[], udp[], and icmp[]. Some examples:

ip[8] = 1 (picks out a byte. This tests for TTL being 1)
tcp[0:2] = 80 (picks out a word using [start offset:length]. This one is equivalent to "src port 80")
icmp[0]==8 || icmp[0]==0, ICMP packets that are either echo request or echo reply. Note that there are readable constants for these, used in an example somewhere above.

tcp[20:4] = 0x48454C4F (one page's example; those are ASCII bytes for HELO, part of SMTP mail sending)
port 80 and tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x47455420 HTTP GET - but note that such trick get awkward fast and may not work well when there is any variation you didn't consider

See links below for header references, and for further examples using this sort of test.

Value/bitwise operations that may be useful:

+, -, /, and *: integer math
& and |: bitwise and and or
<<, >>: bitshifts

Note that you only ever deal with whatever endianness is defined for the protocol. IP, TCP and UDP are always big-endian.

TCP flags

tcp-urg

tcp-ack

tcp-push

tcp-rst

tcp-syn

tcp-fin

e.g. to show any packets with any of these three flags:

'tcp[tcpflags] & (tcp-syn|tcp-rst|tcp-fin) != 0'

Length

Also interesting in this context is len, the packet packet length. I'm not sure at which level -- it seems that on Ethernet, filtering for 1514 gives results and not 1500 or 1518, which would suggest it's counting at link level, except it's NOT counting the CRC.

Copy-paste examples

ICMP packets: tcpdump icmp (ping and ICMP portscans)
non-ping ICMP: tcpdump 'icmp[0]!=8 && icmp[0]!=0' (often mostly 'port unreachable' replies)
ARP packets: tcpdump arp
ARP and DHCP: tcpdump 'udp port 67 or udp port 68 or arp'
SYN packets: tcpdump '(tcp[13]&0x2)!=0 and (tcp[13]&0x10)==0' (initial establishment of TCP connections, SYN portscans) (Specifically packets with SYN set, ACK not set, and ignoring the other flags)

MAC filter: tcpdump 'ether host 00:0B:6A:11:22:33' (also see ether src and ether dst)
Ethernet broadcasts: tcpdump 'ether broadcast' (shows ARP requests and more)
Small data packets: tcpdump '(tcp or udp) and len<100'
IPv6: tcpdump ip6

There are various tricks you can pull when you combine other networking tools, or even general tools. For example, you can add pv to see how much data of a specific type (say HTTP) is being moved (at ethernet level):

tcpdump 'tcp port 80' -s 0 -w - | pv > /dev/null

Wifi

Various wireless-related utilities dump or read the pcap format, so you can use tcpdump to read the results.

BSSIDs act as MACs, so you can filter for traffic to and from an AP using:

ether host 00:12:34:66:22:12

Tcpdump knows how to decode the 802.11 (WiFi) basics, but there seem to be no handy aliases yet. Since 801.11 is a different type of ethernet frame (the aliases seem for ethernetII), most of the interesting filters have to come from accessing the packet's link level data. See also wireless.

Interesting tests include

link[0]==0x80: Beacon
link[0]&0x0c==0x08: Data packets
- link[0:2]&0x0c02==0x0802: WEP-encrypted data packets