How to read Tcpdump Output

Continuing our tcpdump series (read this if you are new here) we will present an easy to understand how to about reading tcpdump output and running advanced commands for and advanced tcpdump use.

First we need a packet, I used from the command line hping, for sending just a SYN packet to my web server, and here is the first packet hitting tcpdump.

[cc lang="VHDL"]19:57:06.748557 IP (tos 0×0, ttl 64, id 33646, offset 0, flags [DF], proto TCP (6), length 60)
192.168.1.4.33922 > 68.178.254.190.80: Flags [S], cksum 0x83ae (correct), seq 4011514848, win 5840, options [mss 1460,sackOK,TS val 612494 ecr 0,nop,wscale 6], length 0[/cc]

19:57:06.748557 this is the timestamp of the request, I made it on h 19, min 57, sec  06

IP – this are all IP (protocol) related settings

tos 0×0 => type of service field

ttl 64 stands for time to live and is => number of hops that the packet has to reach its destination i.e throw how many routers the packets should pass, this is for not living the packets travel the net for ever. After 64 hops the packet will “die”.

id 33646 this is the packet ID, so in this case this is a SYN request, the reply will be an ACK if the host is online and the packet ID will be the same.
In a case of hijacking , the attacker should be able to hack the packet ID and present as a response a packet with the same ID but with malicious data.

[DF] means don’t fragment, so the packet is entire and not fragmented [F]

proto TCP is the protocol type it will be some times UDP and some times ICMP.

length 60 length of the packet

The mos important part of the packet:

192.168.1.4.33922 192.168.1.4 is the original IP and 33922 is the port used by the client

> (destination)

68.178.254.190.80 the destination is 68.178.254.190 (my poor shared server IP address) and .80 is the port used to contact the web-server (apache).

Flags [S] this is not anymore the IP flag, but is the TCP flag SYN , it could be [S.] in this case is an ack reply from the server, or it could be [R] wich means RESET, and in this case the connection is reset-ed, or could be [F] FIN for finalising a transfer etc, or [P] PUSH which means that the data should be transferred immediately,or URG.

cksum 0x83ae (correct) this is the TCP-header check-sum of the packet (for checking packets integrity)

seq 4011514848 this is the TCP sequence number

win 5840 the amount that I will send before requiring an ACK packet back from the server

options [mss 1460,sackOK,TS val 612494 ecr 0,nop,wscale 6] just TCP options, don’t bother your self finding out the meaning

length 0 this is the length of the packet (hey wait a min, I’m seeing another length just above) yes it’s true but it is the IP packet length and this is the TCP (IP – encapsulated) length , so why is 0 ? Because we sent just a SYN packet, and a SYN packet contain only the header of a TCP packet and doesn’t contain any data.

Ok, the second packet received is an ACK reply from the web server:

20:04:53.213020 IP (tos 0×0, ttl 26, id 48589, offset 0, flags [none], proto TCP (6), length 44)
68.178.254.190.80 > 192.168.1.4.1158: Flags [S.], cksum 0xaaab (correct), seq 2217564751, ack 882823260, win 0, options [mss 1460], length 0

In this case it’s almost the same except the flag [S.] which means SYN . response => ack  and the generating IP this time is the server and the response is send to my local nat-ed IP.

Tcpdump Advanced Use

First let’s rock with some protocols

tcpdump protocol

protocol can be: icmp, icmp6, igmp, igrp, pim, ah, esp, vrrp, udp, tcp, ip6, arp, rarp
Note: filters can be applied only to protocols that support them, i.e we ca not use host filter when using arp as protocol because this filter need and IP to track (layer 3), and arp is an layer 2 protocol, so for arp there is no IP address, there is only MAC address.
Check wikipedia if you don’t understand any of this protocols (you should understand at least tcp,udp,icmp,ipv6, arp if you are reading this how-to).
We can also just:

tcpdump -i br0 ip proto \\udp

if we want to specify the protocol, so udp is part of IP like icmp and tcp so we can use proto \\ for specifying the protocol.

Another interesting use of tcpdump is monitoring vlan traffic, we can select packets by their VLAN ID i.e:
[cc lang="VHDL"]
tcpdump -i eth1 -vv vlan 3 -X
tcpdump: WARNING: eth1: no IPv4 address assigned
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
17:17:44.698741 IP (tos 0×0, ttl 255, id 7394, offset 0, flags [none], proto 17, length: 60) 192.168.1.253.52811 > 192.168.1.15.domain: [udp sum ok] 3366+ A? www.google.com. (32)
0×0000: 0003 0800 4500 003c 1ce2 0000 ff11 1a72 ….E..<…….r 0×0010: c0a8 01fd c0a8 010f ce4b 0035 0028 10f3 ………K.5.(.. 0×0020: 0d26 0100 0001 0000 0000 0000 0377 7777 .&………..www 0×0030: 0667 6f6f 676c 6503 636f 6d00 0001 0001 .google.com….. 17:17:44.718772 IP (tos 0×0, ttl 64, id 0, offset 0, flags [DF], proto 17, length: 232) 192.168.1.15.domain > 192.168.1.253.52811: 3366 q: A? www.google.com. 2/4/4 www.google.com. CNAME[|domain]
0×0000: 0003 0800 4500 00e8 0000 4000 4011 b5a8 ….E…..@.@…
0×0010: c0a8 010f c0a8 01fd 0035 ce4b 00d4 4319 ………5.K..C.
0×0020: 0d26 8180 0001 0002 0004 0004 0377 7777 .&………..www
0×0030: 0667 6f6f 676c 6503 636f 6d00 0001 0001 .google.com…..
0×0040: c00c 0005 0001 0000 0000 0008 0377 7777 ………….www
0×0050: 016c .l
17:17:44.719394 IP (tos 0×0, ttl 64, id 12187, offset 0, flags [none], proto 1, length: 84) 192.168.1.253 > mil01s07-in-f104.1e100.net: icmp 64: echo request seq 0
0×0000: 0003 0800 4500 0054 2f9b 0000 4001 55f2 ….E..T/…@.U.
0×0010: c0a8 01fd 480e ea68 0800 cfcd 5e02 0000 ….H..h….^…
0×0020: 4c6e 9c98 000a f61b 0809 0a0b 0c0d 0e0f Ln…………..
0×0030: 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f …………….
0×0040: 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f .!”#$%&’()*+,-./
0×0050: 3031 01
17:17:44.721422 IP (tos 0×0, ttl 54, id 15156, offset 0, flags [none], proto 1, length: 84) mil01s07-in-f104.1e100.net > 192.168.1.253: icmp 64: echo reply seq 0
0×0000: 0003 0800 4500 0054 3b34 0000 3601 5459 ….E..T;4..6.TY
0×0010: 480e ea68 c0a8 01fd 0000 d7cd 5e02 0000 H..h……..^…
0×0020: 4c6e 9c98 000a f61b 0809 0a0b 0c0d 0e0f Ln…………..
0×0030: 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f …………….
0×0040: 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f .!”#$%&’()*+,-./
0×0050: 3031 01

4 packets captured
4 packets received by filter
0 packets dropped by kernel
[/cc]

In this case, my firewall monitored an icmp request in hexadecimal from an host in VLAN.

We can monitor broadcast traffic as well

tcpdump -i eth3 broadcast

And we are able to see all packets broadcast to our network, or multicast if we want multicast.

Ok, now we want some TCP, on other tuts you will find unreadable 0þ@#þßøðj→ß  commands, here we are more human , this is easy to remember when you are in a real life situation:

tcpdump -nnvv -i eth3 'tcp[tcp-syn] & (tcp-syn)' != 0 and not port 22

So what is this?
I’m saying to tcpdump to monitor using tcp protocol only tcp-syn packets that are not 0 and I don’t want port 22 crap (I’m currently connected with ssh).

Lets detect a SYN scan now

tcpdump -nnvv -i br0 'tcp[tcp-syn]  & (tcp-syn)' != 0 and not port 22 and host 192.168.0.4

Ok, I’m at 192.168.0.4 scanning with nmap, and here is the output on the scanned machine.
[cc lang="VHDL"]

17:58:40.369468 IP (tos 0×0, ttl 64, id 0, offset 0, flags [DF], proto 6, length: 44) 192.168.0.1.80 > 192.168.0.4.39578: S [tcp sum ok] 481284648:481284648(0) ack 749969547 win 5840
17:58:40.369790 IP (tos 0×0, ttl 38, id 29797, offset 0, flags [none], proto 6, length: 44) 192.168.0.4.39578 > 192.168.0.1.5900: S [tcp sum ok] 749969546:749969546(0) win 3072
17:58:40.369910 IP (tos 0×0, ttl 39, id 31675, offset 0, flags [none], proto 6, length: 44) 192.168.0.4.39578 > 192.168.0.1.554: S [tcp sum ok] 749969546:749969546(0) win 4096
17:58:40.372776 IP (tos 0×0, ttl 47, id 29521, offset 0, flags [none], proto 6, length: 44) 192.168.0.4.39578 > 192.168.0.1.993: S [tcp sum ok] 749969546:749969546(0) win 4096
17:58:40.373049 IP (tos 0×0, ttl 50, id 12150, offset 0, flags [none], proto 6, length: 44) 192.168.0.4.39578 > 192.168.0.1.8080: S [tcp sum ok] 749969546:749969546(0) win 3072
17:58:40.373245 IP (tos 0×0, ttl 64, id 0, offset 0, flags [DF], proto 6, length: 40) 192.168.0.1.8080 > 192.168.0.4.39578: R [tcp sum ok] 0:0(0) ack 749969547 win 0
17:58:40.376608 IP (tos 0×0, ttl 52, id 8971, offset 0, flags [none], proto 6, length: 44) 192.168.0.4.39578 > 192.168.0.1.587: S [tcp sum ok] 749969546:749969546(0) win 1024
[/cc]
The “easy” way to detect port-scans is the src port, it is always the same as you can see in this situation nmap is using 3957.

Monitoring ICMP-Traffic with tcpdump

Ok, now I want to monitor ICMP traffic but I don’t want random icmp echo and I want to save this capture to a file.
[cc lang="VHDL"]
tcpdump -vvi wlan0 -w icmp.cap ‘icmp[icmptype] != icmp-echo and icmp[icmptype] != icmp-echoreply’
tcpdump: listening on wlan0, link-type EN10MB (Ethernet), capture size 65535 bytes
Got 0
[/cc]
So this is how we sniff icmp traffic, of course not just echo reply/requests.

Ok, but how to monitor only icmp echo traffic with tcpump ?
[cc lang="VHDL"]
tcpdump -vvi wlan0 -w icmp.cap icmp and ‘icmp[icmptype] == icmp-echo || icmp[icmptype] == icmp-echoreply’
[/cc]
Ok, in this case we have specified to capture only icmp-echo || (OR) icmp-echoreply packets. How about and?
Is impossible that an icmp packet could be echo and echoreply at the same time, don’t you think ?

You should use the above examples with the following ICMP packet types.

Other ICMP types could be:

icmp-echoreply, icmp-unreach,
icmp-sourcequench, icmp-redirect, icmp-echo,
icmp-routeradvert, icmp-routersolicit, icmp-
timxceed, icmp-paramprob, icmp-tstamp, icmp-
tstampreply, icmp-ireq, icmp-ireqreply,
icmp-maskreq, icmp-maskreply.

Ok, now I want to read what I captured before:
[cc lang="VHDL"]
tcpdump -vvAr icmp.cap
reading from file icmp.cap, link-type EN10MB (Ethernet)
11:58:47.244942 IP (tos 0×0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
1.122.143.82 > p3slh045.shr.phx3.secureserver.net: ICMP echo request, id 15513, seq 1, length 64
E..T..@.@.fl.z.RD……d<…..pL….. ……………… !”#$%&’()*+,-./01234567 11:58:47.423368 IP (tos 0×0, ttl 44, id 42889, offset 0, flags [none], proto ICMP (1), length 84) p3slh045.shr.phx3.secureserver.net > 1.122.143.82: ICMP echo reply, id 15513, seq 1, length 64
E..T….,…D….z.R…d<…..pL….. ……………… !”#$%&’()*+,-./01234567 11:58:48.246803 IP (tos 0×0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 1.122.143.82 > p3slh045.shr.phx3.secureserver.net: ICMP echo request, id 15513, seq 2, length 64
E..T..@.@.fl.z.RD……\<…..pL….. ……………… !”#$%&’()*+,-./01234567 11:58:48.426344 IP (tos 0×0, ttl 44, id 42890, offset 0, flags [none], proto ICMP (1), length 84) p3slh045.shr.phx3.secureserver.net > 1.122.143.82: ICMP echo reply, id 15513, seq 2, length 64
E..T….,…D….z.R…\<…..pL….. ……………… !”#$%&’()*+,-./01234567 11:58:53.436798 IP (tos 0×0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 1.122.143.82 > p3slh045.shr.phx3.secureserver.net: ICMP echo request, id 15513, seq 3, length 64
[/cc]
This is some nice output

In this example you have learned also how to read and write with tcpdump.

Monitoring TCP-Traffic with Tcpdump

tcpdump -vv tcp and 'tcp[tcpflags] & tcp-syn == tcp-syn' and 'tcp[tcpflags] & tcp-ack == tcp-ack'

For monitoring TCP syn/ack packets only.
So this is if we want to monitor only replies received from the Internet, it’s a good command to execute when we want to know with ho our host is communicating in that precise moment.

What about monitoring only specific packet types with tcpdump?

[cc lang="VHDL"]
tcpdump -vv tcp and ‘tcp[tcpflags] & tcp-fin == tcp-fin’

tcpdump: listening on wlan0, link-type EN10MB (Ethernet), capture size 65535 bytes
12:31:53.682928 IP (tos 0×0, ttl 64, id 5985, offset 0, flags [DF], proto TCP (6), length 52)
1.122.143.82.54140 > mil01s07-in-f104.1e100.net.www: Flags [F.], cksum 0x5c10 (correct), seq 4026359992, ack 2774872111, win 111, options [nop,nop,TS val 44332924 ecr 3098814989], length 0
12:31:53.689434 IP (tos 0×0, ttl 55, id 61029, offset 0, flags [none], proto TCP (6), length 52)
mil01s07-in-f104.1e100.net.www > 1.122.143.82.54140: Flags [F.], cksum 0x5c0e (correct), seq 1, ack 1, win 106, options [nop,nop,TS val 3098814995 ecr 44332924], length 0
12:31:57.184582 IP (tos 0×0, ttl 64, id 8132, offset 0, flags [DF], proto TCP (6), length 52)
1.122.143.82.54141 > mil01s07-in-f104.1e100.net.www: Flags [F.], cksum 0xd8af (correct), seq 4067714265, ack 2940968668, win 111, options [nop,nop,TS val 44333975 ecr 3100781064], length 0
12:31:57.194547 IP (tos 0×0, ttl 55, id 37010, offset 0, flags [none], proto TCP (6), length 52)
mil01s07-in-f104.1e100.net.www > 1.122.143.82.54141: Flags [F.], cksum 0xd8a4 (correct), seq 1, ack 1, win 106, options [nop,nop,TS val 3100781079 ecr 44333975], length 0
[/cc]
If you see, there are only FIN packets, and the following examples should be valid with this packet types also:
tcp-rst,
tcp-push,
tcp-urg

Ok, how to detect an XMAS scan?

An XMAS scan, is a port scan typo with flags set to Fin, Push & Urg at the same packet.
At least, this is what tcpdump says:
[cc lang="VHDL"]
tcpdump: listening on wlan0, link-type EN10MB (Ethernet), capture size 65535 bytes
12:47:30.778407 IP (tos 0×0, ttl 47, id 41535, offset 0, flags [none], proto TCP (6), length 40)
1.122.143.82.53136 > 1.122.143.1.22: Flags [FPU], cksum 0x77eb (correct), seq 2476122955, win 4096, urg 0, length 0
12:47:30.789526 IP (tos 0×0, ttl 128, id 60248, offset 0, flags [none], proto TCP (6), length 40)
1.122.143.1.22 > 1.122.143.82.53136: Flags [R.], cksum 0x87ff (correct), seq 0, ack 2476122956, win 0, length 0
[/cc]

So the working tcpdump command should be:

tcpdump -nnvvi wlan0 'tcp[tcpflags] & (tcp-push & tcp-fin & tcp-urg) == (tcp-push & tcp-fin & tcp-urg)'

And this is what tcpdump captured while I was XMAS-ing my router:
[cc lang="VHDL"]
13:10:21.847432 IP (tos 0×0, ttl 39, id 50647, offset 0, flags [none], proto TCP (6), length 40)
1.122.143.82.52216 > 1.122.143.1.22: Flags [FPU], cksum 0xce5b (correct), seq 2453623242, win 4096, urg 0, length 0
13:10:21.850590 IP (tos 0×0, ttl 128, id 60248, offset 0, flags [none], proto TCP (6), length 40)
1.122.143.1.22 > 1.122.143.82.52216: Flags [R.], cksum 0xde6f (correct), seq 0, ack 2453623243, win 0, length 0
[/cc]

Ok, thank you for watching