Tcpdump notes

From Helpful

This article (or section) isn't finished, and may contain temporary best guesses. Feel free to fix and add, but consider that the original or last may be working on it on and off.

TCPdump snoops network traffic going getting to this host. It can summarize the traffic on-screen (the default) or write it to the fairly common pcap-style files. It can also filter what packets it shows/writes.

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 all the interesting stuff: ethernet, wifi, and more.

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.


Contents

[edit]

Usage notes

Usually, the filter expression is enclosed in single quotes. This is not necessary, but is simpler than dealing with than various types of shell escaping.


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.

[edit]

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)


  • -s 0: capture the whole packet instead of the first 68 bytes, which is faster and enough for the scrolling screen summary, but little else. You probably want the whole packets when inspecing packets in detail and writing them to a file.


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


  • -t: don't show timetamps (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)
[edit]

Filters

[edit]

Host, net, port

As to filters: Avoid shell interpretation of filter string by using single quotes. Also: note that the predefined primitives require a backslash before them.


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).

[edit]

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 that isn't 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: ipx, decnet

(note the absence of backslashes in shorthands)

[edit]

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, <=
[edit]

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 \)


[edit]

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")
  • tcp[20:4] = 0x48454C4F (one page's example; those are ASCII bytes for HELO, part of SMTP mail sending)
  • 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.

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.

[edit]

Length

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


[edit]

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
[edit]

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
[edit]

See also

Examples:

Header reference / byte/bit-tests

Reference:


[edit]

Some interesting ports

For longer lists, see:


Summary:

  • 22:SSH (also SCP, SFTP, also rsync over SSH and others), 23:telnet
  • 513:rlogin, 514:rsh/rcp, 544:rsh/rcp with kerberos


  • 53/UDP:DNS (apparently 53/TCP is used to sync DNS servers), 43: WHOIS


  • 80:HTTP, 443:HTTPS
  • 119:NNTP (news), 563:NNTP/SSL
  • 110:POP3, 995:POP3/SSL, 153:IMAP, 993:IMAP/SSL, 25:SMTP, 465:SMTP/SSL (or cisco)


  • 67 and 68:DHCP/BOOTP server and client, 69:TFTP


  • 21:FTPcommand, 20:FTPdata, 873:rsync (unless over ssh),
  • 137/UDP:NETBIOS nameservice, 138/UDP:NETBIOS datagram, 139/UDP:NETBIOS session, 445/TCP:SMB-over-TCP
  • 1512:WINS
  • 2049:NFS, 111:sunrpc portmapper


  • 524:NCP (Netware Core Protocol)
  • 631:IPP (Internet Printing Protocol)
  • 860:iSCSI
  • 5000:UPnP, 1900:SSDP (UPnP discovery)


  • 5432:PostgreSQL, 1521:OracleSQL, 1433:MSSQL, 3306:MySQL
  • 389:LDAP, 636:LDAP/SSL
  • 1812 and 1813:RADIUS


  • 5222:Jabber-client/server, 5269:Jabber-server/server, 5223:Jabber-secure, 5050:Yahoo, 1863:MSN, 5190:AIM,ICQ, 1550:Gadu-gadu
  • 6667:IRC (but may differ)


  • 177:XDMCP, 6000~:X windows, 5900~:VNC, 5800~:VNC, (~ means 'starts at', and you usually see only a few)


  • 161:SNMP (also 162),
  • 520:RIP, 521:RIPng, 513


  • 1194:OpenVPN, 1723:MS PPTP VPN, 1701:l2tp
Retrieved from "http://helpful.knobs-dials.com/index.php/Tcpdump_notes"