A useful PDF on packet parameters and message types and more, a pocket guide, can be found at:

https://www.sans.org/onsite/description.php?tid=4377

Iĺl come back to that later on in the analysis.

TCPDUMP, amongst others, can be used to inspect packets to glean info on what it actually comprises in terms of protocol types (IP, TCP, UDP, ICMP etc.), what type of message it carries (ICMP type 0 echo reply etc.) and format (hex, ASCII etc). See my Snort page on ASCII wifi sniffing of telnet ASCII passwords :

0 Echo Reply

3 Destination Unreachable

0 Net Unreachable

1 Host Unreachable

2 Protocol Unreachable

3 Port Unreachable

4 Fragmentation Needed & DF Set

5 Source Route Failed

6 Destination Network Unknown

7 Destination Host Unknown

8 Source Host Isolated

9 Network Administratively Prohibited

10 Host Administratively Prohibited

11 Network Unreachable for TOS

12 Host Unreachable for TOS

13 Communication Administratively Prohibited

4 Source Quench...etc.

Some examples of basic packet analysis follow, using network traffic captured in TCPDUMP format (libpcap) using Wireshark, Snort or TCPDUMP.

Read the man pages for these apps to see the switch options and overview.

To find what interfaces are available to use:

# tcpdump -D

1.eth0

2.any (Pseudo-device that captures on all interfaces)

3.lo

# tcpdump -h

tcpdump version 3.9.8

libpcap version 0.9.8 (THIS IS THE STANDARD libpcap FILE FORMAT for TCPDUMP, SNORT and TSHARK)

Usage: tcpdump [-aAdDeflLnNOpqRStuUvxX] [-c count] [ -C file_size ]

[ -E algo:secret ] [ -F file ] [ -i interface ] [ -M secret ]

[ -r file ] [ -s snaplen ] [ -T type ] [ -w file ]

[ -W filecount ] [ -y datalinktype ] [ -Z user ]

[ expression ]

To listen on the first available iface:

# tcpdump

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes

12:38:51.758641 STP 802.1d, Config, Flags [none], bridge-id 8000.00:02:4b:b4:c6:80.8016, length 43

To capture and save a file in tcpdump format, using eth0, use the -w switch, which writes to a log file, sniiffing on an interface eth0, using Ctrl-C to stop the capture.

tcpdump -i eth0 -w /tcpdumptest

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes

^C4 packets captured

4 packets received by filter

0 packets dropped by kernel

Read back the contents of the file using the different apps and switches (snort -r /tcpdumptest or tshark -r /tcpdumptest can also be used):

# tshark -r /tcpdumptest

Running as user "root" and group "root". This could be dangerous.

1 0.000000 Cisco_b4:c6:89 -> Spanning-tree-(for-bridges)_00 STP Conf. Root = 32768/00:02:4b:b4:c6:80 Cost = 0 Port = 0x8016

2 2.005156 Cisco_b4:c6:89 -> Spanning-tree-(for-bridges)_00 STP Conf. Root = 32768/00:02:4b:b4:c6:80 Cost = 0 Port = 0x8016

3 4.008085 Cisco_b4:c6:89 -> Spanning-tree-(for-bridges)_00 STP Conf. Root = 32768/00:02:4b:b4:c6:80 Cost = 0 Port = 0x8016

4 6.008624 Cisco_b4:c6:89 -> Spanning-tree-(for-bridges)_00 STP Conf. Root = 32768/00:02:4b:b4:c6:80 Cost = 0 Port = 0x8016

Tshark shows my Cisco switch STP L2 traffic.

# snort -r /tcpdumptest

No run mode specified, defaulting to verbose mode

Running in packet dump mode

--== Initializing Snort ==--

Initializing Output Plugins!

Verifying Preprocessor Configurations!

TCPDUMP file reading mode.

Reading network traffic from "/tcpdumptest" file.

snaplen = 96

Preprocessor/Decoder Rule Count: 0

--== Initialization Complete ==--

,,_ -*> Snort! <*-

o" )~ Version 2.7.0 (Build 35)

'''' By Martin Roesch & The Snort Team: http://www.snort.org/team.html

(C) Copyright 1998-2007 Sourcefire Inc., et al.

Not Using PCAP_FRAMES

Run time for packet processing was 0.123 seconds

===============================================================================

Snort processed 4 packets.

===============================================================================

Breakdown by protocol:

TCP: 0 (0.000%)

UDP: 0 (0.000%)

ICMP: 0 (0.000%)

ARP: 0 (0.000%)

EAPOL: 0 (0.000%)

IPv6: 0 (0.000%)

ETHLOOP: 0 (0.000%)

IPX: 0 (0.000%)

FRAG: 0 (0.000%)

OTHER: 4 (100.000%)

DISCARD: 0 (0.000%)

InvChkSum: 0 (0.000%)

===============================================================================

Action Stats:

ALERTS: 0

LOGGED: 0

PASSED: 0

===============================================================================

Snort exiting

Interestingly, note that Snort shows ONLY info on packets types OTHER was captured in this quick 5 second capture example which only contains Cisco switch L2 frames from Cisco Discovery Protocol as Tshark stated, so later I will have to capture more interesting traffic, by opening a web page etc.

# tcpdump -r /tcpdumptest

reading from file /tcpdumptest, link-type EN10MB (Ethernet)

11:39:54.949408 STP 802.1d, Config, Flags [none], bridge-id 8000.00:02:4b:b4:c6:80.8016, length 43

11:39:56.954564 STP 802.1d, Config, Flags [none], bridge-id 8000.00:02:4b:b4:c6:80.8016, length 43

11:39:58.957493 STP 802.1d, Config, Flags [none], bridge-id 8000.00:02:4b:b4:c6:80.8016, length 43

11:40:00.958032 STP 802.1d, Config, Flags [none], bridge-id 8000.00:02:4b:b4:c6:80.8016, length 43

At this stage, tcpdump also sees only Cisco swich traffic by the presence of a spanning tree protocol frames STP bridge-ID.

Already an advantage using different tools to look at the same thing, as the defaults basic outputs give different information before looking deeper.

More verbosity:

# tcpdump -vr /tcpdumptest

reading from file /tcpdumptest, link-type EN10MB (Ethernet)

11:39:54.949408 STP 802.1d, Config, Flags [none], bridge-id 8000.00:02:4b:b4:c6:80.8016, length 43

message-age 0.00s, max-age 20.00s, hello-time 2.00s, forwarding-delay 15.00s

root-id 8000.00:02:4b:b4:c6:80, root-pathcost 0

11:39:56.954564 STP 802.1d, Config, Flags [none], bridge-id 8000.00:02:4b:b4:c6:80.8016, length 43

message-age 0.00s, max-age 20.00s, hello-time 2.00s, forwarding-delay 15.00s

root-id 8000.00:02:4b:b4:c6:80, root-pathcost 0

11:39:58.957493 STP 802.1d, Config, Flags [none], bridge-id 8000.00:02:4b:b4:c6:80.8016, length 43

message-age 0.00s, max-age 20.00s, hello-time 2.00s, forwarding-delay 15.00s

root-id 8000.00:02:4b:b4:c6:80, root-pathcost 0

11:40:00.958032 STP 802.1d, Config, Flags [none], bridge-id 8000.00:02:4b:b4:c6:80.8016, length 43

message-age 0.00s, max-age 20.00s, hello-time 2.00s, forwarding-delay 15.00s

root-id 8000.00:02:4b:b4:c6:80, root-pathcost 0

SOME USEFUL OPTIONS:

-A Print each packet (minus its link level header) in ASCII. Handy

for capturing web pages.

# tcpdump -A -i eth0

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes

12:28:13.561326 IP firewall.home.59770 > wy-in-f109.1e100.net.imaps: P 2054748859:2054748890(31) ack 301807006 win 2180 <nop,nop,timestamp 2713901 1131240898>

E..S..@.@..0.....U.m.z..zx....5.....u......

.)i-Cm]....../....qaZ.1Y....d.....M...

-c Exit after receiving count packets.

# tcpdump -A -c 2 -i eth0

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes

12:30:51.103990 STP 802.1d, Config, Flags [none], bridge-id 8000.00:02:4b:b4:c6:80.8016, length 43

BB..........K...........K.....................

12:30:51.821538 IP silver.home.52369 > 239.255.255.250.1900: UDP, length 133

E...CJ.....X...........l...BM-SEARCH * HTTP/1.1

Host:239.255.255.250:1900

ST:urn

2 packets captured

23 packets received by filter

0 packets dropped by kernel

-D Print the list of the network interfaces available on the system

and on which tcpdump can capture packets.

# tcpdump -D

1.eth0

2.any (Pseudo-device that captures on all interfaces)

3.lo

-e Print the link-level header on each dump line.

tcpdump -er /tcpdumptest

reading from file /tcpdumptest, link-type EN10MB (Ethernet)

11:39:54.949408 00:02:4b:b4:c6:89 (oui Unknown) > 01:80:c2:00:00:00 (oui Unknown), 802.3, length 60: LLC, dsap STP (0x42) Individual, ssap STP (0x42) Command, ctrl 0x03: STP 802.1d, Config, Flags [none], bridge-id 8000.00:02:4b:b4:c6:80.8016, length 43

11:39:56.954564 00:02:4b:b4:c6:89 (oui Unknown) > 01:80:c2:00:00:00 (oui Unknown), 802.3, length 60: LLC, dsap STP (0x42) Individual, ssap STP (0x42) Command, ctrl 0x03: STP 802.1d, Config, Flags [none], bridge-id 8000.00:02:4b:b4:c6:80.8016, length 43

-p Dont put the interface into promiscuous mode.

-r Read packets from file (which was created with the -w option).

Standard input is used if file is -.

-s Snarf snaplen bytes of data from each packet rather than the

default of 68 (with SunOSs NIT, the minimum is actually 96). 68

bytes is adequate for IP, ICMP, TCP and UDP but may truncate pro‐

tocol information from name server and NFS packets (see below).

Packets truncated because of a limited snapshot are indicated in

the output with [|proto], where proto is the name of the pro‐

tocol level at which the truncation has occurred. Note that tak‐

ing larger snapshots both increases the amount of time it takes to

process packets and, effectively, decreases the amount of packet

buffering. This may cause packets to be lost. You should limit

snaplen to the smallest number that will capture the protocol

information youre interested in. Setting snaplen to 0 means use

the required length to catch whole packets.

-t Dont print a timestamp on each dump line.

# tcpdump -ter /tcpdumptest

reading from file /tcpdumptest, link-type EN10MB (Ethernet)

00:02:4b:b4:c6:89 (oui Unknown) > 01:80:c2:00:00:00 (oui Unknown), 802.3, length 60: LLC, dsap STP (0x42) Individual, ssap STP (0x42) Command, ctrl 0x03: STP 802.1d, Config, Flags [none], bridge-id 8000.00:02:4b:b4:c6:80.8016, length 43

-ttt Print a delta (in micro-seconds) between current and previous line

on each dump line.

# tcpdump -ttter /tcpdumptest

reading from file /tcpdumptest, link-type EN10MB (Ethernet)

000000 00:02:4b:b4:c6:89 (oui Unknown) > 01:80:c2:00:00:00 (oui Unknown), 802.3, length 60: LLC, dsap STP (0x42) Individual, ssap STP (0x42) Command, ctrl 0x03: STP 802.1d, Config, Flags [none], bridge-id 8000.00:02:4b:b4:c6:80.8016, length 43

2. 005156 00:02:4b:b4:c6:89 (oui Unknown) > 01:80:c2:00:00:00 (oui Unknown), 802.3, length 60: LLC, dsap STP (0x42) Individual, ssap STP (0x42) Command, ctrl 0x03: STP 802.1d, Config, Flags [none], bridge-id 8000.00:02:4b:b4:c6:80.8016, length 43

2. 002929 00:02:4b:b4:c6:89 (oui Unknown) > 01:80:c2:00:00:00 (oui Unknown), 802.3, length 60: LLC, dsap STP (0x42) Individual, ssap STP (0x42) Command, ctrl 0x03: STP 802.1d, Config, Flags [none], bridge-id 8000.00:02:4b:b4:c6:80.8016, length 43

2.     000539 00:02:4b:b4:c6:89 (oui Unknown) > 01:80:c2:00:00:00 (oui Unknown), 802.3, length 60: LLC, dsap STP (0x42) Individual, ssap STP (0x42) Command, ctrl 0x03: STP 802.1d, Config, Flags [none], bridge-id 8000.00:02:4b:b4:c6:80.8016, length 43

-vvv Even more verbose output. For example, telnet SB ... SE options are printed in full. With -X Telnet options are printed in hex aswell.

These next options will be used to analyse some hex values of packets in more detail.

-n Dont convert addresses (i.e., host addresses, port numbers, etc.)

to names. (Speeds up processing)

-x When parsing and printing, in addition to printing the headers of

each packet, print the data of each packet (minus its link level

header) in hex. The smaller of the entire packet or snaplen bytes

will be printed. Note that this is the entire link-layer packet,

so for link layers that pad (e.g. Ethernet), the padding bytes

will also be printed when the higher layer packet is shorter than

the required padding.

-xx When parsing and printing, in addition to printing the headers of

each packet, print the data of each packet, including its link

level header, in hex.

-X When parsing and printing, in addition to printing the headers of

each packet, print the data of each packet (minus its link level

header) in hex and ASCII. This is very handy for analysing new

protocols.

-XX When parsing and printing, in addition to printing the headers of

each packet, print the data of each packet, including its link

level header, in hex and ASCII.

Capturing a more interesting dump, containing web page activity:

# tcpdump -c 8 -w /tcpdumptest

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes

8 packets captured

9 packets received by filter

0 packets dropped by kernel

Snort shows the smmary of what was captured:

Snort processed 8 packets.

===============================================================================

Breakdown by protocol:

TCP: 4 (50.000%)

UDP: 2 (25.000%)

ICMP: 0 (0.000%)

ARP: 0 (0.000%)

EAPOL: 0 (0.000%)

IPv6: 0 (0.000%)

ETHLOOP: 0 (0.000%)

IPX: 0 (0.000%)

FRAG: 0 (0.000%)

OTHER: 2 (25.000%)

DISCARD: 0 (0.000%)

InvChkSum: 0 (0.000%)

To read the hex output from 2 packets UDP and TCP - and look a bit deeper into what it all means:

# tcpdump -vXr /tcpdumptest

13:13:04.804342 IP (tos 0x0, ttl 64, id 41245, offset 0, flags [none], proto UDP (17), length 74) BThomehub.home.domain > firewall.home.58458: 43638 1/0/0 www.sans.org. A 66.35.45.201 (46)

0x0000: 4500 004a a11d 0000 4011 5735 c0a8 00fe

0x0010: c0a8 0002 0035 e45a 0036 1257 aa76 8180

0x0020: 0001 0001 0000 0000 0377 7777 0473 616e

0x0030: 7303 6f72 6700 0001 0001 c00c 0001 0001

0x0040: 0000 000a 0004 4223 2dc9

13:13:04.805360 IP (tos 0x0, ttl 64, id 22046, offset 0, flags [DF], proto TCP (6), length 60) firewall.home.33059 > 66.35.45.201.www: S, cksum 0x994c (correct), 1023998790:1023998790(0) win 5840 <mss 1460,sackOK,timestamp 3386712 0,nop,wscale 6>

0x0000: 4500 003c 561e 4000 4006 b407 c0a8 0002

0x0010: 4223 2dc9 8123 0050 3d08 fb46 0000 0000

0x0020: a002 16d0 994c 0000 0204 05b4 0402 080a

0x0030: 0033 ad58 0000 0000 0103 0306

Each hex number is a quarter byte ( 4 bit ) nibble of a 32 bit word or 8 bit byte so that it represents a hex number from 0 15 decimal, or 0 F, or 0000 - 1111 in binary.

The first things to notice is that some packets are longer than others, by the number of total offset lines listed - up to 0x0040 in the first packet, and only 0x0030 in the second packet. Also, both packets from different hosts - start with 4500, why? What do all the numbers mean?

From the sans.org PDF an IP packet header is made up of sections:

Version IHL Type of Service Total Length

Identification Flags Fragment Offset

Time to Live Protocol Header Checksum

Source Address

Destination Address

Options (optional)

IP Header Contents

Definitions:

Version

4 IP version 4

Internet Header Length

Number of 32-bit words in IP header; minimum

value = 5 (20 bytes) & maximum value = 15 (60 bytes)

Type of Service (PreDTRCx) --> Differentiated Services

Precedence (000-111) 000

D (1 = minimize delay) 0

T (1 = maximize throughout) 0

R (1 = maximize reliability) 0

C (1 = minimize cost) 1 = ECN capable

x (reserved and set to 0) 1 = congestion experienced

Total Length

Number of bytes in packet; maximum length = 65,535

Flags (xDM)

x (reserved and set to 0)

D (1 = Don't Fragment)

M (1 = More Fragments)

Fragment Offset

Position of this fragment in the original datagram,

in units of 8 bytes

Protocol

1 ICMP 17 UDP 57 SKIP

2 IGMP 47 GRE 88 EIGRP

6 TCP 50 ESP 89 OSPF

9 IGRP 51 AH 115 L2TP

Header Checksum

Covers IP header only

Addressing

NET_ID RFC 1918 PRIVATE ADDRESSES

0-127 Class A 10.0.0.0-10.255.255.255

128-191 Class B 172.16.0.0-172.31.255.255

192-223 Class C 192.168.0.0-192.168.255.255

224-239 Class D (multicast)

240-255 Class E (experimental)

HOST_ID

0 Network value; broadcast (old)

255 Broadcast

Options (0-40 bytes; padded to 4-byte boundary)

0 End of Options list 68 Timestamp

1 No operation (pad) 131 Loose source route

7 Record route 137 Strict source route

A clearer header section layout, from Wikipedia

http://en.wikipedia.org/wiki/IPv4

showing the number of bits in each section. The first four bits of the stream (0-3) (or 4 bits, up to 1111 in binary, so the maximum size in binary of each nibble is 1111 = 15 decimal = f in hex).

The above BOLD sections of the SANS and Wiki diagram breakdown into the 13 different sections of each IP packet header.

The start of the packet header in the dump below is made up of lines of 8 blocks of 2 bytes (16 bits),

or 128 bits per line (8 x 16 bits), starting at offset 0x000.

0x0000: 4500 004a a11d 0000 4011 5735 c0a8 00fe

0x0010: c0a8 0002 0035 e45a 0036 1257 aa76 8180

Each byte e.g the first = 45, is made of 2 half byte nibbles or 2 x 4 bits, and we count nibbles to move along the sections according to how many nibbles (or bytes) offset a particular section is.

From the sans PDF, the first section is Version:

Version

4 IP version 4

This first nibble shows the protocol version type = 4 for IP4 in my sample, denoted by the number 4 (=0100) in the 4500 of the first four nibbles of the captured hex above.

The 5 represents the second nibble (bits 4-7) and is the hex number that denotes the header length.

From the SANS PDF, the second section is IHL:

Internet Header Length

Number of 32-bit words in IP header; minimum value = 5 (20 bytes) & maximum value = 15 (60 bytes) by multiplying it by 5

Note that 5 x 32 bits = 160 bits, so 160/8its = 20 bytes

For an IP datagram with no options, the value found in the IP header length will be 5 (5 x 32-bit words)

If the value found in this field is greater than 5, it means that the IP header length contains IP options. This field (5) must be multiplied by 4 to convert to bytes.

So the 5 in the second nibble represents a header length of 5 x 4 = 20 bytes, so the first nibble AFTER this section sets any Options. This field has an IP option of 0 set, in the offset 21 below, and represents End Of Options List:

0x0000: 4500 004a a11d 0000 4011 5735 c0a8 00fe (16 bytes to here)

0x0010: c0a8 0002 0035 e45a 0036 1257 aa76 8180 (offset byte 21 bold = 0 = no IP options set)

From the SANS PDF, the last section is Options:

Options (0-40 bytes; padded to 4-byte boundary)

0 End of Options list 68 Timestamp

1 No operation (pad) 131 Loose source route

7 Record route 137 Strict source route

The next section is Type of Service or now, Differentiated services, bits 8-13, which in the sample are set to zero:

0x0000: 4500 004a a11d 0000 4011 5735 c0a8 00fe

Type of Service options can set upper layer protocol options such as precedence (high priority) delay, throughput and reliability.

Type of Service (PreDTRCx) --> Differentiated Services

Precedence (000-111) 000

D (1 = minimize delay) 0

T (1 = maximize throughout) 0

R (1 = maximize reliability) 0

C (1 = minimize cost) 1 = ECN capable

x (reserved and set to 0) 1 = congestion experienced

Bits 14-15 are Explicit Congestion Notification bits, and are part of the process of traffic flow control bewtween devices, not required in the example below.

0x0000: 4500 004a a11d 0000 4011 5735 c0a8 00fe

The Total Length field bits 16-31 define the size of the whoie packet:

Total Length

Number of bytes in packet; maximum length = 65,535

0x0000: 4500 004a a11d 0000 4011 5735 c0a8 00fe

The total length is located in the second bytes offset (bits 16-31) of the IP datagram. It is two bytes long, making it the next four hex characters.

To convert hex to decimal, multiply each column (0-f values) and add them together,

16^3 16^2 16^1 16^0

0 0 4 a

a = 10 decimal

4 = 4 x 16 = 64 decimal

64 + 10 = 74

The total packet length is 74 bytes long. This is confirmed by the initial dump summary:

# tcpdump -vXr /tcpdumptest

13:13:04.804342 IP (tos 0x0, ttl 64, id 41245, offset 0, flags [none], proto UDP (17), length 74) BThomehub.home.domain > firewall.home.58458: 43638 1/0/0 www.sans.org. A 66.35.45.201 (46)

0x0000: 4500 004a a11d 0000 4011 5735 c0a8 00fe

0x0010: c0a8 0002 0035 e45a 0036 1257 aa76 8180

0x0020: 0001 0001 0000 0000 0377 7777 0473 616e

0x0030: 7303 6f72 6700 0001 0001 c00c 0001 0001

0x0040: 0000 000a 0004 4223 2dc9

13:13:04.805360 IP (tos 0x0, ttl 64, id 22046, offset 0, flags [DF], proto TCP (6), length 60) firewall.home.33059 > 66.35.45.201.www: S, cksum 0x994c (correct), 1023998790:1023998790(0) win 5840 <mss 1460,sackOK,timestamp 3386712 0,nop,wscale 6>

0x0000: 4500 003c 561e 4000 4006 b407 c0a8 0002

0x0010: 4223 2dc9 8123 0050 3d08 fb46 0000 0000

0x0020: a002 16d0 994c 0000 0204 05b4 0402 080a

0x0030: 0033 ad58 0000 0000 0103 0306

c = 12 decimal

3 = 3 x 16 = 48

48 + 12 = 60

In a TCP packet, options can be seen set between the <> delimiters, but you can also check for them in the hex stream 12 bytes offset immediatley after the 20 byte IP header or byte 33:

13:13:04.805360 IP (tos 0x0, ttl 64, id 22046, offset 0, flags [DF], proto TCP (6), length 60) firewall.home.33059 > 66.35.45.201.www: S, cksum 0x994c (correct), 1023998790:1023998790(0) win 5840 <mss 1460,sackOK,timestamp 3386712 0,nop,wscale 6>

0x0000: 4500 003c 561e 4000 4006 b407 c0a8 0002

0x0010: 4223 2dc9 8123 0050 3d08 fb46 0000 0000

0x0020: a002 16d0 994c 0000 0204 05b4 0402 080a (byte 33 [a] TCP header start)

0x0030: 0033 ad58 0000 0000 0103 0306

The TCP header follows immediately after the IP header. The TCP header length is found in the 12th byte offset after the IP header, in the high-order nibble.

As with the IP header length, if the value found in the field is greater than 5, there are TCP options.

The TCP header length = a = 12 decimal > 5 so has options set.

The mac address of the source and destinations can be seen with the -e option:

13:13:04.805360 00:20:ed:35:ff:f4 > 00:1f:9f:7a:0f:59, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 22046, offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.2.33059 > 66.35.45.201.80: S, cksum 0x994c (correct), 1023998790:1023998790(0) win 5840 <mss 1460,sackOK,timestamp 3386712 0,nop,wscale 6>

As it was the machine I am on that sent the request, it is confirmed with ifconfig:

# ifconfig

eth0 Link encap:Ethernet HWaddr 00:20:ed:35:ff:f4

The destination MAC address is, obviously, the subnet next hop source routing device, my gateway in this case.

# nmap -T4 192.168.0.254

MAC Address: 00:1F:9F:7A:0F:59 (Unknown)

Confirmation of protocol types from SANS PDF:

Protocol

1 ICMP 17 UDP 57 SKIP

2 IGMP 47 GRE 88 EIGRP

6 TCP 50 ESP 89 OSPF

9 IGRP 51 AH 115 L2TP

A captured session containing ICMP pings and web info will serve to show how to ID the protocol type in bytes 9 (nibble 10), and write a FILTER for them.

Bytes 9 show a type 17 UDP (11) packet, a type 6 TCP (06) packet, an ICMP packet (01) in the second nibble of the 9^th byte:

20:05:48.013086 IP (tos 0x0, ttl 64, id 48841, offset 0, flags [none], proto UDP (17), length 74) 192.168.0.254.53 > 192.168.0.2.35585: 8208 1/0/0 isc.sans.org. A 66.35.45.157 (46)

0x0000: 4500 004a bec9 0000 4011 3989 c0a8 00fe E..J....@.9.....

0x0010: c0a8 0002 0035 8b01 0036 fa32 2010 8180 .....5...6.2....

0x0020: 0001 0001 0000 0000 0369 7363 0473 616e .........isc.san

0x0030: 7303 6f72 6700 0001 0001 c00c 0001 0001 s.org...........

0x0040: 0000 003c 0004 4223 2d9d ...<..B#-.

20:05:51.286963 IP (tos 0x0, ttl 64, id 1882, offset 0, flags [DF], proto TCP (6), length 52) 192.168.0.2.34490 > 66.35.45.201.80: ., cksum 0x6c7f (correct), ack 137895 win 1002 <nop,nop,timestamp 9578332 1203479577>

0x0000: 4500 0034 075a 4000 4006 02d4 c0a8 0002 E..4.Z@.@.......

0x0010: 4223 2dc9 86ba 0050 a431 2e38 5925 0f61 B#-....P.1.8Y%.a

0x0020: 8010 03ea 6c7f 0000 0101 080a 0092 275c ....l.........'\

0x0030: 47bb a419

..

20:05:52.223613 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.0.2 > 192.168.0.254: ICMP echo request, id 23403, seq 15, length 64

0x0000: 4500 0054 0000 4000 4001 b858 c0a8 0002 E..T..@.@..X....

0x0010: c0a8 00fe 0800 078f 5b6b 000f 903d bf4c ........[k...=.L

0x0020: 5769 0300 0809 0a0b 0c0d 0e0f 1011 1213 Wi..............

0x0030: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 .............!"#

0x0040: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 $%&'()*+,-./0123

0x0050: 3435

The order of switches and files is important when filtering a captured file for example:

# tcpdump -n udp -r /pingtest

reading from file /pingtest, link-type EN10MB (Ethernet)

20:05:44.939343 IP 192.168.0.2.45783 > 192.168.0.254.53: 5780+ A? blogs.sans.org. (32)

20:05:45.119618 IP 192.168.0.254.53 > 192.168.0.2.45783: 5780 1/0/0 A 66.35.45.139 (48)

OK 3 basic filter examples TCP UDP and ICMP after managing to capture a 16 packet session with some of each present...

# tcpdump -c 16 -w /pingtest2

Reading it back with Snort to see its content:

Snort processed 16 packets.

Breakdown by protocol:

TCP: 1 (6.250%)

UDP: 7 (43.750%)

ICMP: 0 (0.000%)

ARP: 0 (0.000%)

EAPOL: 0 (0.000%)

IPv6: 0 (0.000%)

ETHLOOP: 0 (0.000%)

IPX: 0 (0.000%)

FRAG: 0 (0.000%)

OTHER: 6 (37.500%)

DISCARD: 2 (12.500%)

InvChkSum: 0 (0.000%)

The whole file with:

# tcpdump -n -r /pingtest2

reading from file /pingtest2, link-type EN10MB (Ethernet)

21:29:07.034495 STP 802.1d, Config, Flags [none], bridge-id 8000.00:02:4b:b4:c6:80.8016, length 43

21:29:07.238432 IP 192.168.0.2 > 192.168.0.254: ICMP echo request, id 7212, seq 1, length 64

21:29:07.242246 IP 192.168.0.254 > 192.168.0.2: ICMP echo reply, id 7212, seq 1, length 64

21:29:08.239613 IP 192.168.0.2 > 192.168.0.254: ICMP echo request, id 7212, seq 2, length 64

21:29:08.242403 IP 192.168.0.254 > 192.168.0.2: ICMP echo reply, id 7212, seq 2, length 64

21:29:09.037190 STP 802.1d, Config, Flags [none], bridge-id 8000.00:02:4b:b4:c6:80.8016, length 43

21:29:09.243620 IP 192.168.0.2 > 192.168.0.254: ICMP echo request, id 7212, seq 3, length 64

21:29:09.246430 IP 192.168.0.254 > 192.168.0.2: ICMP echo reply, id 7212, seq 3, length 64

21:29:10.210284 IP 192.168.0.2.46832 > 192.168.0.254.53: 44152+ A? danielmiessler.com. (36)

21:29:10.247667 IP 192.168.0.2 > 192.168.0.254: ICMP echo request, id 7212, seq 4, length 64

21:29:10.250332 IP 192.168.0.254 > 192.168.0.2: ICMP echo reply, id 7212, seq 4, length 64

21:29:10.330218 IP 192.168.0.254.53 > 192.168.0.2.46832: 44152 1/0/0 A 74.207.229.242 (52)

21:29:10.331788 IP 192.168.0.2.59470 > 192.168.0.254.53: 64595+ A? ping.chartbeat.net. (36)

21:29:10.332492 IP 192.168.0.2.36051 > 74.207.229.242.80: S 3911009564:3911009564(0) win 5840 <mss 1460,sackOK,timestamp 10828094 0,nop,wscale 6>

21:29:10.374771 IP 192.168.0.254.53 > 192.168.0.2.59470: 64595 9/0/0 A 184.73.194.227,[|domain]

21:29:10.464609 IP 192.168.0.2.50061 > 192.168.0.254.53: 59400+ A? danielmiessler.com. (36)

Mostly ICMP is present so filtering it just for this:

# tcpdump -n icmp -r /pingtest2

reading from file /pingtest2, link-type EN10MB (Ethernet)

21:29:07.238432 IP 192.168.0.2 > 192.168.0.254: ICMP echo request, id 7212, seq 1, length 64

21:29:07.242246 IP 192.168.0.254 > 192.168.0.2: ICMP echo reply, id 7212, seq 1, length 64

21:29:08.239613 IP 192.168.0.2 > 192.168.0.254: ICMP echo request, id 7212, seq 2, length 64

21:29:08.242403 IP 192.168.0.254 > 192.168.0.2: ICMP echo reply, id 7212, seq 2, length 64

21:29:09.243620 IP 192.168.0.2 > 192.168.0.254: ICMP echo request, id 7212, seq 3, length 64

21:29:09.246430 IP 192.168.0.254 > 192.168.0.2: ICMP echo reply, id 7212, seq 3, length 64

21:29:10.247667 IP 192.168.0.2 > 192.168.0.254: ICMP echo request, id 7212, seq 4, length 64

21:29:10.250332 IP 192.168.0.254 > 192.168.0.2: ICMP echo reply, id 7212, seq 4, length 64

Or filtering out to find just udp and tcp:

# tcpdump -n 'tcp or udp' -r /pingtest2

reading from file /pingtest2, link-type EN10MB (Ethernet)

21:29:10.210284 IP 192.168.0.2.46832 > 192.168.0.254.53: 44152+ A? danielmiessler.com. (36)

21:29:10.330218 IP 192.168.0.254.53 > 192.168.0.2.46832: 44152 1/0/0 A 74.207.229.242 (52)

21:29:10.331788 IP 192.168.0.2.59470 > 192.168.0.254.53: 64595+ A? ping.chartbeat.net. (36)

21:29:10.332492 IP 192.168.0.2.36051 > 74.207.229.242.80: S 3911009564:3911009564(0) win 5840 <mss 1460,sackOK,timestamp 10828094 0,nop,wscale 6>

21:29:10.374771 IP 192.168.0.254.53 > 192.168.0.2.59470: 64595 9/0/0 A 184.73.194.227,[|domain]

21:29:10.464609 IP 192.168.0.2.50061 > 192.168.0.254.53: 59400+ A? danielmiessler.com. (36)

Or directly:

# tcpdump -n not icmp -r /pingtest2

reading from file /pingtest2, link-type EN10MB (Ethernet)

21:29:07.034495 STP 802.1d, Config, Flags [none], bridge-id 8000.00:02:4b:b4:c6:80.8016, length 43

21:29:09.037190 STP 802.1d, Config, Flags [none], bridge-id 8000.00:02:4b:b4:c6:80.8016, length 43

21:29:10.210284 IP 192.168.0.2.46832 > 192.168.0.254.53: 44152+ A? danielmiessler.com. (36)

21:29:10.330218 IP 192.168.0.254.53 > 192.168.0.2.46832: 44152 1/0/0 A 74.207.229.242 (52)

21:29:10.331788 IP 192.168.0.2.59470 > 192.168.0.254.53: 64595+ A? ping.chartbeat.net. (36)

21:29:10.332492 IP 192.168.0.2.36051 > 74.207.229.242.80: S 3911009564:3911009564(0) win 5840 <mss 1460,sackOK,timestamp 10828094 0,nop,wscale 6>

21:29:10.374771 IP 192.168.0.254.53 > 192.168.0.2.59470: 64595 9/0/0 A 184.73.194.227,[|domain]

21:29:10.464609 IP 192.168.0.2.50061 > 192.168.0.254.53: 59400+ A? danielmiessler.com. (36)

And for the single tcp packet, in more detail:

# tcpdump -nvX tcp -r /pingtest2

reading from file /pingtest2, link-type EN10MB (Ethernet)

21:29:10.332492 IP (tos 0x0, ttl 64, id 31778, offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.2.36051 > 74.207.229.242.80: S, cksum 0x4a84 (correct), 3911009564:3911009564(0) win 5840 <mss 1460,sackOK,timestamp 10828094 0,nop,wscale 6>

0x0000: 4500 003c 7c22 4000 4006 cd2d c0a8 0002 E..<|"@.@..-....

0x0010: 4acf e5f2 8cd3 0050 e91d 451c 0000 0000 J......P..E.....

0x0020: a002 16d0 4a84 0000 0204 05b4 0402 080a ....J...........

0x0030: 00a5 393e 0000 0000 0103 0306 ..9>........

The TCP packet is a SYN request, as seen in the destination IP above 74.207.229.242.80: S, but SYNs are filtered for using:

# tcpdump -n 'tcp[13] & 2 != 0' -r /pingtest2

reading from file /pingtest2, link-type EN10MB (Ethernet)

21:29:10.332492 IP 192.168.0.2.36051 > 74.207.229.242.80: S 3911009564:3911009564(0) win 5840 <mss 1460,sackOK,timestamp 10828094 0,nop,wscale 6>

Just got to work out why...? What hex values is it finding and where...?

The !=0 means the SYN flag is set, which is detailed in the SNAS PDF as:

Source Port Destination Port

Sequence Number

Acknowledgment Number

Offset Reserved Flags Window

(Header Length)

Checksum Urgent Pointer

Options (optional)

TCP Header Contents

Common TCP Well-Known Server Ports

7 echo 110 pop3

19 chargen 111 sunrpc

20 ftp-data 119 nntp

21 ftp-control 139 netbios-ssn

22 ssh 143 imap

23 telnet 179 bgp

25 smtp 389 ldap

53 domain 443 https (ssl)

79 finger 445 microsoft-ds

80 http 1080 socks

Offset

Number of 32-bit words in TCP header; minimum value = 5

Reserved

4 bits; set to 0

Flags (CEUAPRSF)

ECN bits (used when ECN employed; else 00)

CWR (1 = sender has cut congestion window in half)

ECN-Echo (1 = receiver cuts congestion window in half)

U (1 = Consult urgent pointer, notify server application

of urgent data)

A (1 = Consult acknowledgement field)

P (1 = Push data)

R (1 = Reset connection)

S (1 = Synchronize sequence numbers)

F (1 = no more data; Finish connection)

Or more clearly at WikiP again:

TCP Header

The 8 flags can be seen as single bit options from bits 105 on above:

CWR (1 bit) Congestion Window Reduced (CWR) flag is set by the sending host to indicate that it received a TCP segment with theECE flag set and had responded in congestion control mechanism (added to header by RFC 3168).

       ECE (1 bit) ECN-Echo indicates

       If the SYN flag is set, that the TCP peer is ECN capable.

       If the SYN flag is clear, that a packet with Congestion Experienced flag in IP header set is received during normal transmission (added to header by RFC 3168).

       URG (1 bit) indicates that the Urgent pointer field is significant

       ACK (1 bit) indicates that the Acknowledgment field is significant. All packets after the initial SYN packet sent by the client should have this flag set.

       PSH (1 bit) Push function. Asks to push the buffered data to the receiving application.

       RST (1 bit) Reset the connection

       SYN (1 bit) Synchronize sequence numbers. Only the first packet sent from each end should have this flag set. Some other flags change meaning based on this flag, and some are only valid for when it is set, and others when it is clear.

       FIN (1 bit) No more data from sender

Advanced Filters from

http://danielmiessler.com/study/tcpdump/

You can also filter based on specific portions of a packet, as well as combine multiple conditions into groups. The former is useful when looking for only SYNs or RSTs, for example, and the latter for even more advanced traffic isolation.

[ Hint: An anagram for the TCP flags: Unskilled Attackers Pester Real Security Folk ]

Show me all URG packets:

# tcpdump 'tcp[13] & 32 != 0'

Show me all ACK packets:

# tcpdump 'tcp[13] & 16 != 0'

Show me all PSH packets:

# tcpdump 'tcp[13] & 8 != 0'

Show me all RST packets:

# tcpdump 'tcp[13] & 4 != 0'

Show me all SYN packets:

# tcpdump 'tcp[13] & 2 != 0'

Show me all FIN packets:

# tcpdump 'tcp[13] & 1 != 0'

Show me all SYN-ACK packets:

# tcpdump 'tcp[13] = 18'

[ Note: Only the PSH, RST, SYN, and FIN flags are displayed in tcpdump's flag field output. URGs and ACKs are displayed, but they are shown elsewhere in the output rather than in the flags field ]

Keep in mind the reasons these filters work. The filters above find these various packets because tcp[13] looks at offset 13 in the TCP header, the number represents the location within the byte, and the !=0 means that the flag in question is set to 1, i.e. it's on.

As with most powerful tools, however, there are multiple ways to do things. The example below shows another way to capture packets with specific TCP flags set.

Capturing TCP Flags Using the tcpflags Option

# tcpdump 'tcp[tcpflags] & tcp-syn != 0'

Specialized Traffic

Display all IPv6 Traffic:

# tcpdump ip6

Show all traffic with both SYN and RST flags set: (should never happen)

# tcpdump 'tcp[13] = 6'

Show all traffic with the "evil bit" set:

# tcpdump 'ip[6] & 128 != 0'