Let's capture some TCP traffic and analyse it using tcpdump. I am using an ubuntu server on CITC (cumulus in the cloud) for this demonstration

To check the version of Ubuntu
cumulus@server01:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.1 LTS
Release: 16.04
Codename: xenial

To see the list of network interfaces
cumulus@server01:~$ ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 44:38:39:00:08:00 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.31/16 brd 192.168.255.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::4638:39ff:fe00:800/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 44:38:39:00:08:01 brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 44:38:39:00:08:02 brd ff:ff:ff:ff:ff:ff
c

Let's focus on a single interface eth0
To get the detail of eth0
cumulus@server01:~$ ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 44:38:39:00:08:00 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.31/16 brd 192.168.255.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::4638:39ff:fe00:800/64 scope link
valid_lft forever preferred_lft forever

Let's now try to capture some traffic associated with eth0
cumulus@server01:~$ sudo tcpdump -i eth0 -w eth0.cap
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
^C2 packets captured
4 packets received by filter
0 packets dropped by kernel

-i is the flag for pointing at an interface, and -w is for writing the output on to a file in this case eth0.cap, it's better to store packet captures onto a file to read/analyse at a later stage, if the -w flag is not used, the captures would be displayed directly on the screen, we have to press Ctrl c when we need to stop the capture

To see the content of the packet capture file
cumulus@server01:~$ cat eth0.cap
Ôò¡*9Q\õ>
¾¾D89DE°œ³@@/ƒ
èÂL°pÖ#ŽޤóqÉ5…Ïî5UvΕ#ñ”=ZÜêD–¢ù MNôaK¥¶ÎÅtÝìXèø:5aςygÓìԸîÿ\%²ʕ °Ý6…»Ybd·¨Çç³JoéíÊy¡ŠÈÚ.ԈÚœ",¿Q
7x»Öˬ„i„`C*´%{Ã*9Q\ÉC
BBD8D89E4!g@@–ßÀ¨þÀ¨©fÄ;1»†TŽ€ނ”
L°QèÂ

cat is what we would normally use to read the contents of a file, however here the contents are all encrypted

To read the content in plain text
cumulus@server01:~$ sudo tcpdump -r eth0.cap
reading from file eth0.cap, link-type EN10MB (Ethernet)
05:42:02.802549 IP 192.168.0.31.ssh > 192.168.0.254.43366: Flags [P.], seq 3146142738:3146142862, ack 3292213507, win 303, options [nop,nop,TS val 1239234 ecr 5025813], length 124
05:42:02.803785 IP 192.168.0.254.43366 > 192.168.0.31.ssh: Flags [.], ack 124, win 222, options [nop,nop,TS val 5025873 ecr 1239234], length 0

-r is the flag for reading a file in this case eth0.cap

let's analyse the capture now

  • 05:42:02.802549 - timestamp
  • 192.168.0.31.ssh > 192.168.0.254.43366 - this is the reverse traffic associated with the ssh (port22) session from the management server(0.254)'s random port 43366
  • Flags [P.] - (P)ush flag to signal immediate push of data from the sender(server01) to the receiver(management server), requests the receiver to respond as soon as possible, this is usually set with interactive applications such as Telnet/SSH, in this case SSH, the second flag '.' indicates ACK(Acknowledgement)
  • seq 3146142738:3146142862 - if we see the difference between these two 32-bit sequence numbers separated by ':', it implies the length of this TCP payload is 124 bytes
  • ack 3292213507 - this is the 32-bit acknowledgement number for the corresponding seq. no. sent by the management server(sometime earlier), this has no relation to the sequence number that server01 has generated
  • win 303 - server01 tells the management server that it's window size is 303, which is the TCP receive window and means it can receive upto 303 bytes of data until an acknowledgement is sent, this 16-bit value can grow or shrink as the connection progresses
  • options [nop,nop,TS val 1239234 ecr 5025813] - TCP options are displayed as multiples of 8-bits each, i.e. one TCP options is of 8-bit length, and if we have 4 TCP options that would be 32-bit in length, nop means 'no-operation' and it's usually operating system dependent, we have 2 nops which comprise of 2*8 = 16 bits, TS val is a 32-bit time stamp value, ecr is a 32-bit timestamp echo reply value which is equivalent to the TS val sent by the opposite host(management server), ecr is only set when acknowledge is sent, else its set as 0, however with rare exceptions such as when during the first SYN phase with out an ACK, in our case we have an ecr set as we also have an ack number in the TCP header
  • length 124 - the TCP payload's length is 124 bytes, we have seen this at the seq no. section, note that the length of the data section is not specified in the TCP segment header. It can be calculated by subtracting the combined length of the TCP header and the encapsulating IP header from the total IP datagram length (specified in the IP header).
  • 05:42:02.803785 - timestamp
  • 192.168.0.254.43366 > 192.168.0.31.ssh - this is the forward SSH traffic from the management server to the local server(01)
  • Flags [.] - only ACK
  • ack 124 - Acknowledgement number 124
  • win 222 - TCP window size 222 bytes
  • options [nop,nop,TS val 5025873 ecr 1239234] - as explained earlier
  • length 0 - TCP payload length is 0, so there is no data, as it's only used for Acknowledgement

--end-of-post--