tcpdump -i eth1.16 icmp <– to capture just PINGs on this interface
tcpdump -i Mgmt -vvv -s0 -w tcpdumpfile.log <– this captures the FULL packets to a file usefull for wireshark the -s0 stops the files being shortened
tcpdump -i INT port 67 <– view dhcp requests
tcpdump -eP -nni any host 10.9.4.30
tcpdump -i any
S – SYN (Start Connection) . – No Flag Set P – PSH (Push Data) F – FIN (Finish Connection) R – RST (Reset Connection)
“ack” means acknowledge, “win” means “sliding windows”, “mss” means “maximum segment size”, “nop” means “no operation”.
Flags are some combination of S (SYN), F (FIN), P (PUSH), R (RST), W (ECN CWR) or E (ECN-Echo), or a single ’.’ (no flags)
Selective Acknowledgment Permitted (SackOK): This option simply says that selective acknowledgments are permitted for this connection. SackOK must be included in the TCP options in both the SYN and SYN/ACK packets during the TCP three-way handshake, or it cannot be used. SackOK should not appear in any other packets.
The three-way handshake is simply the source host and the destination host requesting a connection, and then confirming to each other that a connection has been made. As mentioned above, to open a session a client determines a local source port and an Initial Sequence Number (ISN). The ISN is a randomly determined integer between 0 and 4,294,967,295. Communicating hosts exchange ISNs during connection initialization. Each host sets two counters: sequence and acknowledgement. In the context of a single TCP packet, the sequence number is set by the sending host, and the acknowledgement number is set by the receiving host.
Host A sends a TCP SYNchronize packet to Host B Host B receives A’s SYN Host B sends a SYNchronize-ACKnowledgement Host A receives B’s SYN-ACK Host A sends ACKnowledge Host B receives ACK. TCP socket connection is ESTABLISHED. tcp three-way handshake,syn,syn-ack,ack TCP Three Way Handshake (SYN,SYN-ACK,ACK) – See more at this URL:
Commands and Outputs Examples:
1. ICMP Example
[[email protected] CP1:0]#tcpdump -i Mgmt host 172.16.1.53 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on Mgmt, link-type EN10MB (Ethernet), capture size 96 bytes 09:37:38.370763 IP 10.9.20.14 > 172.16.1.53: ICMP echo request, id 1, seq 3, length 40 09:37:38.372210 IP 172.16.1.53 > 10.9.20.14: ICMP echo reply, id 1, seq 3, length 40 09:37:39.365648 IP 10.9.20.14 > 172.16.1.53: ICMP echo request, id 1, seq 4, length 40 09:37:39.366558 IP 172.16.1.53 > 10.9.200.14: ICMP echo reply, id 1, seq 4, length 40 09:37:40.363506 IP 10.9.20.14 > 172.16.1.53: ICMP echo request, id 1, seq 5, length 40 09:37:40.364318 IP 172.16.1.53 > 10.9.20.14: ICMP echo reply, id 1, seq 5, length 40 09:37:41.361947 IP 10.9.20.14 > 172.16.1.53: ICMP echo request, id 1, seq 6, length 40 09:37:41.362771 IP 172.16.1.53 > 10.9.20.14: ICMP echo reply, id 1, seq 6, length 40
So, let’s break down the components of that last one;
22:47:08.352707 – the datagram’s timestamp
IP (tos0×0, ttl60, id1457, offset0, flags [none], protoUDP (17), length72) – the layer three datagram’s header fields and values;
tos0×0 – the IP TOS value (more correctly in the present context, the DS and ECN fields (8bit, 2nd octet)
ttl60 – the IP TTL value (8bit, 9th octet)
id1457 – mostly used for identifying the parts of a fragmented datagram; incremented by one with every packet sent (16bit, 5th and 6th octets)
offset0 – the fragment offset, used with fragmented packets (13bits of the 7th and 8th octets)
flags [none] – any IP flags set; [DF] for Don’t Fragment and [MR] for More Fragments (3bits of the 7th octet)
protoUDP(17) – the higher layer (four) protocol and it’s number (8bits, 10th octet)
length72– the entire IP packet length, including headers (16bits, 3rd and 4th octets)
220.127.116.11.domain – the source IP address and port
18.104.22.168.16165 – the destination IP address and port
[udp sumok] – the datagram’s checksum status
Everything else relates to the DNS application response.
Notes on the proto(col) Field
You can find a full list of protocol number assignments here. Here’s a few more you might know;
Notes on Service Ports
I’m sure you all know this but anyway, valid port numbers are 0 through to 65535. If you want to live by IANA assignments (and we all should right?);
0 to 1023 are reserved for well known applications
1024 to 49151 are registered (with IANA) ports
49152 to 65535 are user and dynamic ports (aka ephemeral or temporary)
tcpdump provides data formatting for the following protocols amongst others (see Jens comments below for more information);
Thanks again to Jens for this: If you see ‘[|proto]‘ at the end of the verbose output, e.g. ‘[|radius]‘ the snap length is too small for the application data to be captured;. just increase it (using the -s0 parameter) to see the complete application data information.
Using tcpdump we can analyze the PDUs that establish and terminate a TCP/IP connection. TCP uses a special mechanism to open and close connections. The tcpdump output below display data from different connection scenarios between host 192.168.2.10 and 192.168.2.165. The following tcpdump command and options were used to generate output:
#tcpdump -nn host 192.168.2.165 and port 23
Before examining the output, let’s take a detour and get a brief overview of TCP/IP connection management. This small detour will assist those individuals who are new to protocols. To guarantee a reliable connection (startup and shutdown), TCP uses a method in which three messages are exchanged. The process is called a three-way-handshake. To startup a connection:
The requesting Host sends a synchronization flag (SYN) in a TCP segment to create a connection.
The receiving Host 192.168.2.165 receives the SYN flag and returns an acknowledgment flag (ACK).
The requesting Host 192.168.2.10 receives the SYN flag and returns it’s own ACK flag.
A similar handshake process is used to close a connection using a finish flag (FIN). To establish a connection, the sending host creates a segment containing the IP address and port number of the host it want to connect to. The segment contains a SYN flag and the sending hosts initial sequence number. Data is segmented before it is sent. The sequence numbers allow the segments to be assembled in the correct order.
20:06:32.845356 192.168.2.10.1249 > 192.168.2.165.23: S 3263977215:3263977215(0) win 16384 (DF)
The receiving hosts responds with its own SYN flag and its initial sequence number. This segment also contains an ACK flag to acknowledge the sending host’s SYN (segment 3263977215 +1). This type of acknowledgment is called expectational acknowledgment, because the receiver acknowledges the sequence number of the next segment it expects to receive.
Scenario 3: Telnet Connection Refused (no service offered at the host)
To establish a connection, host 192.168.2.10 sends a segment containing the IP address and port number of the host it want to connect to. The segment contains a SYN flag and the sending hosts initial sequence number.
05:28:00.080798 192.168.2.10.1063 > 192.168.2.165.23: S 3034008467:3034008467(0) win 16384 (DF)
Host 192.168.2.165 acknowledges the SYN from host 192.168.2.10 by sending another segment containing the R (connection reset) and ACK flags.
05:28:00.080979 192.168.2.165.23 > 192.168.2.10.1063: R 0:0(0) ack 3034008468 win 0
Host doesn’t take no for answer and tries again.
05:28:00.579420 192.168.2.10.1063 > 192.168.2.165.23: S 3034008467:3034008467(0) win 16384 (DF)
But it receives the same result from receiving host.
05:28:00.579524 192.168.2.165.23 > 192.168.2.10.1063: R 0:0(0) ack 1 win 0
A final attempt is made to establish a connection.
05:28:01.080114 192.168.2.10.1063 &glt; 192.168.2.165.23: S 3034008467:3034008467(0) win 16384 (DF)
Only three strikes in this ball game. Sending host gives up.
05:28:01.080225 192.168.2.165.23 > 192.168.2.10.1063: R 0:0(0) ack 1 win 0
Compare the outputs from an Establish Telnet Connection scenario and Telnet Connection Refusal scenario. The outputs from the receiving host are different. For the Telnet Connection Refusal scenario, the Telnet service was turned off at the receiving host using the /etc/inetd.conf file. If the service is not available, no connection can be established. Note to self: simple security measures turn off services not being used.
Scenario 3: Telnet Connection Refused (tcp wrappers security used at host)
The same opening as before is used to establish a connection.
05:40:39.838710 192.168.2.10.1064 > 192.168.2.165.23: S 3223709294:3223709294(0) win 16384 (DF)
The receiving host responds with its own SYN flag and its initial sequence number. This segment also contains an ACK flag to acknowledge the sending hosts SYN (segment 3223709294 +1).
Compare the outputs from an Establish Telnet Connection scenario and Telnet Connection Refusal (tcp wrappers) scenario. The outputs from the receiving host are different. In the Telnet Connection Refusal (tcp wrappers) scenario, tcp wrappers is enabled by adding the following line to the /etc/hosts.deny file: ALL:192.168.2.10. This means “deny all services to this host with address 192.168.2.10”. A similar connection test was done using a rule in iptables firewall. The resulting output was the same. The reader may gain some insight into how systems are at risk from the trappings of tcpdump. Before a system hack is possible, some effort is expended to engineer the hack. An examination of the data from a system can provide the hacker with some insight into where efforts might provide the greatest chance of success.
Scenario 4: No Telnet Connection (host removed from the network)
Same opening, different scenario.
05:55:21.557846 192.168.2.10.1065 > 192.168.2.165.23: S 3443876657:3443876657(0) win 16384 (DF)
There’s no response, so the sending host tries the same request again.
05:55:24.560891 192.168.2.10.1065 > 192.168.2.165.23: S 3443876657:3443876657(0) win 16384 (DF)
With still no response on the third try, the three-strike rule comes into effect. The sending host abandons the connection attempt.
05:55:30.569584 192.168.2.10.1065 > 192.168.2.165.23: S 3443876657:3443876657(0) win 16384 (DF)