6
Common Protocols
When examining traffic you will have to determine whether or not what you are seeing is
“normal”. You have to determine if a DNS reply is correct based upon its matching DNS request,
if a DHCP client is communicating based upon being inside or outside of its lease time, or if a
TCP packet has the right flags set for a connection handshake. Of course, this can’t be done if
you don’t know to look at the DNS transaction ID field, if you don’t understand the DHCP
DORA process, or if you don’t know the difference between the SYN and RST flags.
The point is that in order to spot abnormal traffic, you must first have an understanding of
normal traffic. This principal applies to troubleshooting latency issues, identifying
malfunctioning applications, and zeroing in on security threats.
The purpose of this chapter is to help you better understand how normal network traffic
works at the packet level. We will look at all of the most common protocols. This includes
workhorse protocols such as TCP, UDP, and IP, along with the most commonly used application
layer protocols such as HTTP, DHCP, and DNS. Each protocol section contains at least one
capture file that you can download and work with directly, which I highly recommend doing.
I can’t stress enough how important this chapter is. As a matter of fact, it’s the most
important chapter in the book. Skipping it would be like cooking Sunday supper without
cornbread; without the cornbread the rest just doesn’t make sense. Even if you already have a
good grasp on what each protocol does, this chapter is worth a quick read in order to review their
packet structure.
NOTE: Although I will discuss several protocols in detail, I won’t be covering all of the
intricacies of each ones design and implementation; instead, I have provided the
associated RFC number for each. An RFC, or request for comments, is the official
document that defines the implementation standards for protocols. You can search for
RFC documentation at the RFC Editor home page, http://www.rfc-editor.org.
Address Resolution Protocol
Both logical and physical addresses are used for communication on a network. The use of logical
addresses allows for communication between multiple networks and indirectly connected
devices. The use of physical addresses facilitates communication on a single network segment
for devices that are directly connected to each other with a switch. In most cases, these two types
of addressing must work together in order for communication to occur.
Consider a scenario where you wish to communicate with another device on your network.
This device may be a server of some sort or even simply another workstation you need to share
files with. The application you are using to initiate the communication is already aware of the IP
address of the remote host, meaning it should have all it needs to build the layer 3 through 7
information of the packet it wants to transmit. The only piece of information it needs at this point
is the layer 2 data link information containing the MAC address of the target host. This last piece
of information is needed because a switch that interconnects devices on the network utilizes
something called a CAM table. This table contains a list of the MAC addresses of all the devices
plugged into each of its ports. When the switch receives traffic destined for a particular MAC
address it uses this table to know which port to send the traffic through. If the destination MAC
address is unknown the transmitting device will first check for the address in its cache, but if it is
not there then it must be resolved through additional communication on the network.
The resolution process TCP/IP networking uses to resolve an IP address to a MAC address is
called Address Resolution Protocol (ARP). The ARP resolution process is very simple and only
utilizes two packets, an ARP request and an ARP response (Figure 6-1).
Considering this scenario conversationally, the transmitting computer sends out an ARP
request that asks the question, “Howdy everybody, my IP address is XX.XX.XX.XX, and my
MAC address is XX:XX:XX:XX:XX:XX. I need to send something to whoever has the IP
address XX.XX.XX.XX, but I don’t know what their hardware address is. Will whoever has this
IP address please respond back with their MAC address?”
This packet is broadcasted to every device on the network segment. Any device that does not
have this IP address will simply discard the packet. The device that does have this address
however, will respond with an ARP reply. This response would effectively provide this answer,
“Hey transmitting device. I am who you are looking for with the IP address of XX.XX.XX.XX.
My MAC address is XX:XX:XX:XX:XX:XX.”
Figure 6-1: The ARP Resolution Process
Consider the analogy of a limousine driver at an airport. If you have ever flown, then chances
are when you get off of a plane you have seen a limo driver standing with a sign bearing
someone’s last name. Here, the driver knows the name of the person he is picking up, but doesn’t
know what they look like. The driver holds up the sign so that everyone can see it. All of the
people getting off of the plane see the sign, and if it isn’t them, they simply ignore it. The person
whose name is on the card however, sees it, approaches the driver, and identifies himself. The
ARP resolution process works in much the same manner.
Once this resolution process is completed, the transmitting device will update its cache with
the MAC to IP address association of this device, and can begin sending data.
Note: You can view the ARP table of a Windows host by typing “arp –a” from a command prompt.
Seeing this process in action should provide a greater understanding of how it works. Before
we do that, let’s examine the ARP packet header.
The ARP Header
The ARP packet structure is displayed in Figure 6-2 and is fairly simple.
Figure 6-2: The ARP Packet Structure
The ARP header includes the following fields:
Hardware Type: Specifies the layer two type used. In most cases this is Ethernet (type 1)
Protocol Type: Specifies the higher layer protocol the ARP request is being used for
(IPv6, IPv6, etc)
Hardware Length: The length (in octets) of the hardware address in use (6 for Ethernet)
Protocol Length: The length (in octets) of the logical address of the specified protocol
type
Operation: Defines the function of the ARP packet, either 1 for a request or 2 for a reply
Sender Hardware Address: The hardware address of the sender
Sender Protocol Address: The upper layer protocol address of the sender
Target Hardware Address: Hardware address of the intended receiver (ignored in ARP
requests)
Target Protocol Address: Upper layer protocol address of the intended receiver
If you open the file arp_resolution.pcap you can see the resolution process we just discussed.
Let’s focus on each packet individually.
Packet 1 – ARP Request
The first packet is the ARP request, and is displayed in Figure 6-3. We can confirm that this
packet is a true broadcast packet by examining the Ethernet header in the packet details pane.
The destination address of the packet is ff:ff:ff:ff:ff:ff . This address is the Ethernet broadcast
address, meaning anything sent to it will be broadcast to all devices on the current network
segment. This source address of this packet in the Ethernet header is listed as our MAC address
.
Given this structure, we can discern that this is indeed an ARP request on an Ethernet
network utilizing IP. The senders IP (192.168.0.114) and MAC (00:16:ce:6e:8b:24) are
listed, as is the IP of the target (192.168.0.1) . The MAC address of the target is the piece
of information we are trying to get, and since this information is unknown the target MAC is
listed as 00:00:00:00:00:00 .
Figure 6-3: The ARP Request Packet
Packet 2 – ARP Response
In our response to the initial request (Figure 6-4), the Ethernet header now has a destination
address of the source MAC address from the first packet. The ARP header looks very similar
with only a few minor changes. First, the OpCode of the packet is now 0x0002 , indicating a
reply rather than a request. Secondly, the addressing information is reversed. What was the
sender MAC and IP address is now the target MAC and IP address . Lastly, and most
importantly, all of the information is now present, meaning we now have the MAC address
(00:13:46:0b:22:ba)  of our host at 192.168.0.1.
Figure 6-4: The ARP Reply Packet
Gratuitous ARP
Where I come from, when something is done gratuitously that usually means so in a negative
context. A gratuitous ARP however, is actually a good thing. In many cases it is common for a
devices IP address to change. When this happens, the IP to MAC address mappings hosts on the
network have in their caches will no longer be valid. As a means to prevent this from causing
communication errors a gratuitous ARP packet is transmitted on the network with the purpose of
forcing anyone who receives it to update their cache with the new IP to MAC address mapping
(Figure 6-5).
Figure 6-5: Gratuitous ARP Process
There are a few different scenarios that can spawn a gratuitous ARP. One of the most
common is changing of an IP address. Opening the capture file gratuitous_arp.pcap you can see
this in action. This file only contains a single packet because that is all that’s involved in a
gratuitous ARP. This packet is displayed in Figure 6-6.
Figure 6-6: Gratuitous ARP Packet
Examining the Ethernet header you can see that this packet is sent as a broadcast so that all
hosts on the network receive it . The ARP header looks very similar to that of an ARP request,
the only difference is that sender IP address  and the target IP address  are the same. When
received by other hosts on the network, this packet will cause them to update their ARP tables
with the new IP to MAC address association. The fact that this ARP packet is unsolicited but
results in a client updating its ARP cache is it what makes it “gratuitous”.
You will notice gratuitous ARP packets in a few different situations. As mentioned, changing
the IP address of a device will generate one. Also, some operating systems will perform a
gratuitous ARP on startup. Additionally, you may notice gratuitous ARP packets on systems that
use them for load balancing incoming traffic.
Internet Protocol (IPv4)
The primary purpose of protocols at layer three of the OSI model is to allow for communication
between networks. As we just saw, MAC addresses are used for communication on a single
network at layer two, and in much the same fashion layer three will be responsible for addresses
for inter-network communication. There are a few different protocols available that can do this,
but the most common is the Internet Protocol. More specifically, we will examine IP version 4
(IPv4) right now.
Networks and Addressing
In order to understand the functionality of IPv4 you have to understand how traffic flows
between networks. IPv4 is the workhorse of the communication process and is ultimately
responsible for carrying data from one device to another regardless of where those endpoints are
located.
A simple network where all of the devices are connected together with hubs or switches is
called a LAN. When you want to connect two LANs together you can do so with a router.
Complex networks can consist of thousands of LANs connected thousands of routers across the
globe. This concept may seem simple, but the Internet itself is no more than a collection of
millions of LANs and routers.
IP Addresses
IP addresses are 32-bit long addresses used to uniquely identify devices connected to a network.
It is a bit much to expect someone to remember a sequence of 1’s and 0’s 32 characters long, so
IP addresses are written in what is called dotted-quad notation. In dotted-quad notation each of
the four sets of 1’s and 0’s that make up an IP address are converted to base 10 and represented
as a number between 1 and 255 in the format A.B.C.D (Figure 6-7). Consider the IP address
11000000 10101000 00000000 00000001. This value is obviously a bit much to remember or
notate, therefore using dotted-quad we can represent it as 192.168.0.1.
Figure 6-7: Dotted-quad IPv4 address notation
Network Masks
The IP address being divided into four distinct parts is not just by chance. An IP address consists
of two parts; a network address and a host address. The network address identifies the LAN the
device is connected to and the host address identifies the device itself on that network. The
determination of which part of the IP address belongs to the network or host address is not
always the same. This is actually determined by another set of addressing information called the
network mask (netmask), sometimes also referred to as a subnet mask.
The netmask is used to identify what portion of the IP address belongs to the network address
and which portion belongs to the host address. This number is also 32-bits long, and every bit
that is set to a 1 identifies the portion of the IP address that is reserved for the network address.
The remaining bits set to 0 identify the host address.
As an example, consider the IP address 10.10.1.22, represented in binary as 10100000
10100000 00000001 10110000. In order to determine the allocation of each section of the IP
address we will apply our netmask. In this case, our netmask is 11111111 11111111 00000000
00000000. This means that the first half of the IP address is reserved for the network address
(10.10 or 10100000 10100000) and the last half of the IP address identifies the individual host
on this network (.0.22 or 00000001 10110000) (Figure 6-8).
Figure 6-8: The Network Mask determines the allocation of the bits in an IP address
Just as with IP addresses, remember a 32 character sequence can be a bit challenge.
Netmasks can also be written in dotted quad notation. The netmask used in our previous example
of 11111111 11111111 00000000 00000000 would be written in dotted-quad notation as
255.255.0.0.
IP addresses and netmasks are commonly written in Classless Inter-Domain Routing (CIDR)
notation for shorthand. In this form, an IP address is written in full, followed by a forward slash
(/) and the number of bits that represent the network portion of the IP address. Given an IP
address of 10.10.1.22 and a netmask of 255.255.0.0, this would be written in CIDR notation as
10.10.1.22/16.
The IPv4 Header
The source and destination IP address are the crucial components of the IPv4 packet header, but
that’s not all of the IP information you will find within a packet. The IP header is actually quite
complex compared to the ARP protocol header we just examined and includes a lot of extra
functionality that helps IP do its job better (Figure 6-9).
Figure 6-9: The IPv4 header
The fields of the IPv4 header are:
Version: The version of IP being used.
Header Length: Declares the length of the IP header.
Type of Service: Contains a precedence and type of service field which are used by
routers to prioritize traffic.
Total Length: Declares the length of the IP header and the data included in the packet.
Identification: A unique identification number used to identify a packet or sequence of
fragmented packets.
Flags: Used to identify whether or not a packet is part of a sequence of fragmented
packets.
Fragment Offset: If a packet is a fragment then the value of this field is used to
reassemble the packets in the correct order.
Time to Live: Defines the lifetime of the packet, measured in hops through routers.
Protocol: Used to identify what type of packet is coming next in the sequence of packets.
Header Checksum: An error-detection mechanism that is used to verify the contents of
the IP header are not damaged or corrupted.
Source Address: The IP address of the host that sent the packet.
Destination Address: The IP address of the packets destination.
Options: Reserved for additional options of IP. Includes options for source routing and
time stamps.
Data: Contains the actual data being transmitted with IP.
We will look at most of these fields as we examine some of the intricacies of IPv4. There are
a few things we won’t cover as we won’t deal with them in this book, so if you want to get really
intimate with IPv4 I’d recommend reading RFC 791.
Time to Live (TTL)
Typically we are only concerned about the lifetime of a packet in terms of it traveling from its
source to its destination in a timely manner. However, imagine a scenario in which a packet must
travel to a host across the Internet who is separated by dozens of routers. At some point in its
path, there is potential for our packet to encounter a router who is misconfigured and does not
know the correct path to the packets final destination. In this case the router could do a number
of things, one of which could result in the packet being forwarded around in a never ending loop.
If you have any programming background you know that a loop that never ends can cause all
sorts of issues, typically resulting in a program or the entire operating system crashing.
Theoretically the same thing could occur with packets on a network. The packets would keep
looping between routers and as the number of looping packets increased, the available bandwidth
on the network would deplete until a denial of service condition is met. Luckily, this foresight
was put into the design of IP and they Time to Live (TTL) field of the IP header was created.
The TTL value defines the maximum number of routers a packet can traverse (called a hop)
before packet is discarded. A TTL is defined when a packet is created and is decremented by 1
every time it is forwarded by a router. For example, if a packet has a TTL of 2, the first router it
reaches will decrement the TTL to 1 and forward it to the second router. This router will then
decrement the TTL to 0, and if the final destination of the packet is not on that network the
packet will be discarded (Figure 6-10).
Figure 6-10: The TTL of a packet decreases every time it traverses a router
Let’s look at an example of this in Wireshark. If you open the file ip_ttl_source.pcap we see
two ICMP packets. We’ve not talked about ICMP yet but it utilizes IP in order to deliver packets
and we can see this by expanding the IP header section in the packet details window (Figure 611).
Figure 6-11: The IP header of the source packet
In this packet we can see a lot of the information we’ve already discussed. The version of IP
being used is clearly 4 , the IP header length is 20 bytes , and the total length of the header
and payload is 60 bytes . Overall, this is a pretty simple IP header to examine. Note that the
value of the time to live field is 128 .
The primary purpose of an ICMP ping is to test communication between devices by sending
data from one host to another in the form of a request, and the other host to send that data back in
the form of a reply. In this file, we have one device with the address of 10.10.0.3  sending this
type of request to a device with the address 192.168.0.128 . This initial capture file was created
at the source 10.10.0.3 host.
Given that information, now open the file ip_ttl_dest.pcap. Instead of this data being
captured at the source, it was captured at the destination host, 192.168.0.128. Expand the IP
header of the first packet in this capture and examine the TTL (Figure 6-12).
Figure 6-12: The IP header tells us that the TTL has been lowered by 1
You should immediately notice that the TTL is 127, which is one less than the original TTL
of 128. Without even knowing the architecture of the network we can come to the conclusion
that these two devices are separated by a single router.
IP Fragmentation
The fragmentation of packets is a feature of IP which allows for more reliable delivery of data
across varying types of networks.
The fragmentation of a packet is based upon the Maximum Transmission Unit (MTU) size of
the layer two data link protocol being used and the configuration of the devices utilizing these
layer two protocols. In most cases this is Ethernet, which has a default MTU of 1500. This means
that the maximum packet size that can be transmitted over an Ethernet network is 1500 bytes
(not including the 14 byte Ethernet header itself).
Note: Although there are standard MTU settings, the MTU of a device can be reconfigured
manually in most cases. An MTU setting is assigned on a per interface basis and can be
modified on Windows and Linux systems, as well as on the interfaces of managed routers.
When a device prepares to transmit an IP packet it makes the determination of whether or not
it must fragment the packets by comparing the data size of the packet to the MTU of the network
interface it will be transmitted from. If the data size is greater than the MTU, the packet will be
fragmented. When this happens the following actions are taken:
The device splits the data into however many packets are required for data transmission.
The total length field of each IP header is set to the segment size of each fragment.
The more fragments flag is set to 1 on all of the packets in the data stream, except for the
last one.
The fragment offset field is set in the IP header of the fragments.
The packets are transmitted
Let’s examine this process by opening the file ip_frag_source.pcap. This capture file was
taken from a computer with the address 10.10.0.3 transmitting a ping request to a device with the
address 192.168.0.128. Immediately you should notice that the Info column of the packet list
window lists two fragmented IP packets followed by the ICMP (ping) request.
Begin by examining the IP header of packet one (Figure 6-13).
Figure 6-13: The More Fragments and Fragment Offset values can indicate a fragmented packet
We can immediately determine this packet is part of a fragment based upon the more
fragments and fragment offset fields. Any packet that is a fragment will either have a positive
fragment offset value or will have the more fragments flag set. In the first packet the more
fragments flag is set  indicating that the receiving device should expect to receive another
packet in this sequence. The fragment offset is set to 0  indicating this packet is the first in the
series of fragments.
The IP header of the second packet (Figure 6-14) also has the more fragments flag set , but
in this case the fragment offset value is 1480 . This is indicative of the 1500 byte MTU, minus
20 bytes for the IP header.
Figure 6-14: The fragment offset values increase based upon the size of the packets
The third packet (Figure 6-15) does not have the more fragments flag set  which marks it
as the last fragment in the data stream, and the fragment offset is set to 2960  (1480+(150020)).
Figure 6-15: The fragment offset values increase based upon the size of the packets
All of these fragments can be identified as being part of the same series of data because they
all have the same value in the Identification field of the IP header .
Transmission Control Protocol (TCP)
The ultimate goal of the Transmission Control Protocol (TCP) is the provide end-to-end
reliability for the delivery of data. TCP operates at layer four of the OSI model and handles data
sequencing, error recovery, and is ultimately responsible for ensuring data is getting to where it
is supposed to go.
The majority of the most commonly used protocols rely on TCP and IP to deliver packets to
their final destination. As we just learned, IP handles the actual addressing and routing of packets
and TCP is used to ensure that those packets are actually getting to where they are supposed to
be going. TCP is utilized by such protocols including HTTP, SSH, FTP, and SMTP, all of which
we will examine in this chapter.
The TCP Header
TCP provides a great deal of functionality and the complexity of its header reflects this (Figure
6-16). We will be covering each of these with practical examples of their functionality.
Figure 6-16: The TCP Header
The fields of the TCP header are:
Source Port: The port used to transmit the packet
Destination Port: The port the packet will be transmitted to
Sequence Number: Contains the number that is used to identify a TCP segment. Used to
ensure parts of a data stream are not missing.
Acknowledgment Number: Contains the sequence number that is to be expected in the
next packet from the other device taking part in the communication.
Header Length: The length of the TCP header in four-byte increments
Flags: Contains the URG, ACK, PSH, RST, SYN, and FIN flags for identifying the type
of TCP packet being transmitted.
Windows Size: Defines the size of the TCP receiver buffer in bytes.
TCP Checksum: Used to ensure the contents of the TCP header and data are intact upon
arrival.
Urgent Pointer: If the URG flag is set then this field is examined for additional
instructions on where the CPU should begin reading the data within the packet.
TCP Options: Contains various optional fields that can be specified in a TCP packet.
TCP Ports
All TCP communication takes place using a source and destination port, which can be found in
every TCP header. One of the best ways to think about a port is to compare TCP/IP
communication to an old telephone switchboard. A switchboard operator would monitor a board
of lights and plugs. When your light lit up he would plug in, ask who you wanted to talk with,
and then plug a cable from your plug into the plug of the person you wanted to talk to. TCP ports
work in much the same fashion.
In order to transmit data to a particular application on a remote server or device the TCP
packet that is generated must know the port the remote service is listening on. This is important
because if you try to access that application on a port other than the one that it is configured to
use, the communication will fail. The source port in this sequence is not incredibly important and
can be selected randomly. The remote server will simply determine the port to communicate
back with from the original packet it is sent (Figure 6-17).
Figure 6-17: TCP uses ports to transmit data
There are 65,536 available ports for use when communicating with TCP. Of these, we
typically divide them into two groups. The standard port group is from 1-1,023 and the
ephemeral port group is from 1,024-65,536. There are particular services that have standard
ports of operation, and these ports generally lie within the standard port grouping. Only one
service can communicate on a port at a time, and it is because of this that when a source port is
chosen for communication by an operating system an ephemeral port is chosen.
Let’s examine a couple of different TCP packets and identify the port numbers they are using
by opening the file tcp_ports.pcap. In this file we have the HTTP communication of a client
browsing to two websites. As mentioned previously, HTTP uses utilizes TCP for communication
so this is a great example of standard TCP traffic.
If we examine the first packet in this file (Figure 6-18) and expand its TCP header in the
packet details window the first two values represent the source and destination port of the packet.
This packet is being sent from 172.16.16.128 to 212.58.226.142. The source port is 2826 ,
which is an ephemeral port. Remember that source ports are chosen at random by the operating
system. The destination port is a standard port, port 80 , which is the standard used port for
web servers using the HTTP protocol.
Figure 6-18: The source and destination port can be found in the TCP header
Note: You may also notice that Wireshark labels these ports as slc-systemlog (2826) and http
(80). Wireshark maintains a list of ports and there most common uses. Although these are
primarily standard ports, many ephemeral ports have commonly used services associated
with them. The labeling of these ports can be quite confusing so it’s typically best to
disable this by turning off transport name resolution. You can do this by choosing Edit
from the main drop-down menu, choosing Preferences, going to the Name Resolution
section, and removing the check box next to Enable Transport Name Resolution.
If you wish to leave this functionality enabled but want to change how Wireshark identifies a
certain port you can do so by modifying the Services file located in the Wireshark
program directory, which is based on the IANA common ports listing.
Moving to the second packet we see that this packet is being sent back from 212.58.226.142
to 172.16.16.128. As with the IP addresses, the source and destination port are now also switched
 (Figure 6-19). All TCP-based communication works in this same manner. A random source
port is chosen to communicate to a known destination port. Once this initial packet is sent the
remote device communicated back to the source device using the established ports.
Figure 6-19: The source and destination port number are switched for reverse communication
There is one more communication stream included in this sample capture file. See if you can
locate what port numbers it uses for communication.
As we progress through this book you will learn more of the ports associated with common
protocols and service. Eventually you will begin profiling services and devices by the ports they
use. You can view a thorough list of common ports by browsing to
http://www.iana.org/assignments/port-numbers.
The TCP Three-Way Handshake
All TCP based communication must begin with a handshake between the two hosts that are
communicating. This handshake process serves a few different purposes. First, it allows the
transmitting host to ensure that the destination host is up and able to communicate, and that it is
listening on the port the source is attempting to communicate on. The process also allows the
transmitting host to send its starting sequence number to the recipient so that both hosts can keep
the stream of packets in proper sequence.
The TCP handshake occurs in three separate steps (Figure 6-20). In the first step, the device
which wants to communicate (Host A) sends a TCP packet to its target (Host B). This initial
packet contains no data other than the lower layer protocol headers. The TCP header in this
packet has the SYN flag set and includes the initial sequence number and maximum segment
size (MSS) that will be used for the communication process. Host B responds to this packet by
sending a similar packet with the SYN and ACK flags set, along with its initial sequence
number. Finally, Host A sends one last packet to Host B with only the ACK flag set. Once this
process is completed both devices should now have all of the information they need to begin
communicating properly.
Note: TCP packets are often referred to by the flags they have set. Rather than referring to a
packet as a TCP packet with the SYN flag set, this type of packet will most commonly just
be called a SYN packet. This being the case, the packets used in the TCP handshake
process would be referenced as SYN, SYN/ACK, and ACK.
Figure 6-20: The TCP Three-Way Handshake
This process can be seen in action by opening tcp_handshake.pcap. Wireshark includes a
feature which replaces the sequence numbers of TCP packets with relative numbers for easier
analysis, but for our purposes here we want to disable this so we can see the actual sequence
numbers. To do this:
Choose Edit from the main drop-down menu
Select Preferences
Expand the Protocols heading
Choose TCP
Uncheck the box next to Relative Sequence Numbers and Window Scaling and press
OK
The first packet in this capture represents our initial SYN packet (Figure 6-21). The packet is
transmitted from 172.16.16.128 on port 2826 to 212.58.226.142 on port 80. We can see here that
the sequence number transmitted is 3691127924 .
Figure 6-21: The Initial SYN Packet
The second packet in the handshake is the SYN/ACK response from 212.58.226.142 (Figure
6-22).
Figure 6-22: The SYN/ACK Response
This packet also contains this host’s initial sequence number (233779340), but also
contains an acknowledgement number (3691127925) . You will notice that the
acknowledgement number here is one more than the sequence number included in the previous
packet. This is because the acknowledgement number field is used to specify the next sequence
number the host expects to receive.
The final packet is the ACK packet sent from 172.16.16.128 (Figure 6-23).
Figure 6-23: The final ACK
This packet, as expected, contains the sequence number 3691127925  as was defined in the
previous packets acknowledgement number field.
This process occurs before every TCP communication sequence. If you are sorting through a
busy capture file and need to locate the beginning of a communication sequence, the sequence of
SYN-SYN/ACK-ACK is a great marker to look for.
The TCP Teardown
With every greeting there must eventually be a goodbye, and in terms of TCP with every
handshake there must eventually be a teardown. The TCP teardown is used to gracefully end a
connection between two devices once they have finished communicating. This process involves
four packets, and utilizes the FIN flag which is used to signify the graceful end of a connection.
In a teardown sequence, host A will signify that it is done communicating with host B by
sending a TCP packet with the FIN and ACK flags set. Host B responds with an ACK packet,
and transmits a FIN/ACK packet of its own to host A. Host A responds with an ACK packet,
ending the communication process. In summary, this process is FIN/ACK, ACK, FIN/ACK,
ACK (Figure 6-24).
Figure 6-24: The TCP Teardown Process
Once again, we can view this process in Wireshark by opening the file tcp_teardown.pcap.
Beginning with the first packet in the sequence we can see that the device at 67.228.110.120 is
initiating the teardown sequence by sending a packet with the FIN and ACK flags set  (Figure
6-25).
Figure 6-25: The FIN/ACK initiates the teardown process
Once this packet is sent, 172.16.16.128 responds with an ACK packet to acknowledge its
receipt of the first packet, and sends its own FIN/ACK packet. The process is completed when
67.228.110.120 sends a final ACK. At this point, the communication between the two devices
has ended, and they must complete a new TCP handshake in order to begin communicating
again.
TCP Resets
In an ideal world, every connection would end gracefully with a TCP teardown. Realistically,
connections often end abruptly. This is one situation in which a TCP packet with the RST flag
set would be used. The RST flag is used to indicate the abrupt closing of a connection, or to
refuse a connection attempt.
Let’s look at an example of network traffic that includes a RST packet. Open the file
tcp_refuseconnection.pcap. This file contains two packets, and in the first the host the host at
192.168.100.138 is attempting to communicate with 192.168.100.1 on port 80. What this host
doesn’t yet know is that 192.168.100.1 isn’t listening on port 80 because it’s a Cisco router
without a web interface. As a result of this, the second packet is sent from 192.168.100.1 to let
192.168.100.138 know that communication will not be possible over this port. You can see this
abrupt end in the TCP header of the second packet (Figure 6-26). There is no data with this
packet, but the RST and ACK flags are set , and no more communication follows.
Figure 6-26: The RST and ACK flags signify the end of communication
Whether it is a potential attacker performing a port scan or simply a misconfigured host, a
RST means that communication is over, or in the case we just saw, will never begin. A good way
to think about the difference between a TCP teardown and a RST is to liken their communication
to couples in a relationship. A TCP teardown is a lot like thirteen year-olds on the phone: “You
say goodbye”, “no you say goodbye”, “no you say goodbye”, until eventually they get tired, go
to sleep, and dream about the Jonas Brothers and Miley Cyrus all night. A RST is quite the
opposite and more akin to a married couple. When one person gets done talking they abruptly
say bye, and hang up.
User Datagram Protocol (UDP)
The User Datagram Protocol is the other layer four protocol primarily in use on modern
networks. The key difference between UDP and TCP is that where as TCP is focused on reliable
data delivery with error checking capabilities, UDP is primarily focused on speedy transmission.
It is because of this that UDP is a best-effort service and is commonly referred to as a
connectionless protocol.
The most immediate problem with this concept is that with no reliability services it would
seem that UDP traffic would be flaky at best. That would normally be true, but the protocols that
rely on UDP typically have their own reliability services built in, or use the features of ICMP
which we will discuss in the next section. Application layer protocols such as DNS and DHCP
are examples of this. They are highly dependent upon the speed of the of packet transmission
across the network, so they use UDP as their transport layer protocol and any error checking and
retransmission timers are handled by the application layer protocols themselves. We will see that
first hand when we begin looking at some of those protocols.
The UDP Header
The UDP header is significantly simpler than the TCP header. It is smaller and size and has very
little complexity.
Figure 6-27: The UDP Header
The fields of the UDP header are:
Source Port: The port used to transmit the packet
Destination Port: The port the packet will be transmitted to
Header Length: The length of the TCP header in four-byte increments
UDP Checksum: Used to ensure the contents of the UDP header and data are intact upon
arrival.
For an example of a UDP packet, you can open the file udp_dnsrequest.pcap. This contains a
single packet, representative of a DNS request, which utilizes UDP. If you expand the UDP
header of this packet you can see the four fields it includes (Figure 6-28).
Figure 6-28: The UDP contents of a packet are very simple
There really isn’t a whole lot to examine with UDP specifically, but we will revisit it as we
cover protocols that rely on it for transport services. The key thing to keep in mind is that UDP
relies on the application layer protocol it is paired with, and ICMP, for reliability of delivery.
Internet Control Message Protocol (ICMP)
If I were stranded on a desert island and could only take one protocol it would probably be
ICMP. That’s because ICMP is the utility protocol of the TCP/IP communication suite. ICMP is
responsible for providing information regarding the availability of devices, services, or routes on
a TCP/IP network. Most network troubleshooting techniques and tools are centered around
common ICMP message types, which we will examine here. I like to think if I were stranded on
that desert island, ICMP would be the protocol to let me know if eating that weird colored berry
is such a good idea.
The ICMP Header
ICMP is actually a part of IP, and relies on IP to transmit its messages. ICMP isn’t too terribly
complex and contains a relatively small header that changes in structure depending upon its
purpose.
Figure 6-29: The ICMP Header
The ICMP header contains the following fields:
Type: Identifies the type or classification of ICMP message, based upon RFC
specification
Code: Identifies the sub classification of ICMP message, based upon RFC specification
Checksum: Used to ensure the contents of the ICMP header and data are intact upon
arrival
Variable: The variable portion of an ICMP packet is dependent upon the Type and Code
fields
ICMP Types and Messages
The structure of an ICMP packet is entirely dependent upon its purpose. The purpose of the
packet is defined by the Type and Code fields and the value within them as defined by RFC 792.
You can consider the ICMP type as the classification of the packet and the Code as its
subclassification. For example, type 3 indicates “Destination Unreachable”. This may not be
enough information to adequately troubleshoot an issue you may be having communicating with
a device, but if that packet were to also specify code 3, indicating “Port Unreachable”, we could
conclude there is an issue with the port we are attempting to communicate with. You can view a
full list of available types and codes at http://www.iana.org/assignments/icmp-parameters.
Echo Requests and Responses
The biggest claim to fame ICMP has is a result of ping. Ping is a utility used in both Windows
and Linux to test for connectivity to a device. Most IT professionals are pretty familiar with ping.
I’d even venture to say that it’s probably a tool that is used a few times a day every day by
consultants and engineers and most of them don’t even know that it utilizes the ICMP protocol to
perform its test.
If you’ve never used the ping command you can do some from a command prompt by typing
ping 172.16.16.1, replacing the IP address listed with the IP address of a device on your
network. If the device is turned on, your computer has a communication route to it, and there is
no firewall blocking the communication you should see that the ping command reports a reply to
your transmission (Figure 6-30). If any of these conditions is not true, you will see a different
message telling you why the transmission was not responded to.
Figure 6-30: The ping command being used to test connectivity
Basically, the ping command sends a piece of data to a device and listens for a reply to
determine if there is connectivity to that device (Figure 6-31).
Figure 6-31: The ping command is very simple and involves only two steps
Note: Although ping has long been the bread and butter of IT, it’s becoming a bit deceiving as
more and more people are deploying host based firewalls. Great deals of firewalls
deployed today have functionality that limits the ability of a device to respond to ICMP
packets. This is great for security because potential attackers using ping to determine if a
host is accessible might be deterred. Of course, when troubleshooting a device it sure can
be a headache to ping something to test for connectivity and not receive a reply when you
are in fact able to communicate with the device.
The ping utility is a great example of simple ICMP communication so we will take a look at
it in the file icmp_echo.pcap. The packets in this capture file are a representation of what
happens at the packet level when you run the ping tool. In this case, the first packet shows that
we have the host 192.168.100.138 sending a packet to 192.168.100.1 . If you expand the ICMP
portion of this packet we can determine what type of ICMP packet it is by examining the type
and code fields. In this case, the packet is type 8 , code 0 , indicating an echo request.
The terms echo and ping are often used interchangeably, but the traffic type in use by the
ICMP protocol is actually echo, and the tool that uses this type of traffic is ping.
Along with the type and code designations and the checksum, we also have an identifier,
sequence number (used to pair requests with replies), and a random text string in the variable
portion of the ICMP packet (Figure 6-32).
Figure 6-32: The ICMP echo request packet
The second packet in this sequence is the reply to our request (Figure 6-33).
Figure 6-33: The ICMP echo reply packet
The ICMP portion of the packet indicates this with type 0 , code 0 . The sequence
number in the second packet matches that of the first , so we know that this response matches
the request appropriate request. This packet also contains the same 32 byte string of data that was
transmitted with the initial request . Using variations of the ping command you can actually
increase the size of this data padding to force these packets to be fragmented for various types of
network troubleshooting.
Once this second packet has been received by 192.168.100.138, the ping utility will report a
success.
Note: The text string padding used in an ICMP echo request can actually be a topic of great
interest to a potential intruder. Attackers can use this type of traffic to profile the
operating system used on a device. This is a form of steganography.
Traceroute
The second most common use of the ICMP protocol as a utility protocol is invoked by using the
traceroute utility. This utility is used to identify the path from one device to another. On a simple
network, a path may only go through a single router or no router at all. On a complex network
however, a device may have to go through dozens of routers to reach its final destination.
Because of this, being able to trace the exact path a packet takes from one destination to another
is crucial for troubleshooting communication.
Traceroute is able to map the path packets take through the use of ICMP with a little help
from IP as well. Let’s look at how this happens in the file icmp_traceroute.pcap. The first packet
in this capture is pretty similar to the echo request we looked at in the previous example (Figure
6-34). At first glance, it appears to be a simple echo request  from 192.168.100.138 to 4.2.2.1
 everything in the ICMP portion of the packet is identical to the formatting of an echo request
packet; however, if you expand the IP header of this packet you should notice one value that is a
bit odd. The TTL value of this packet is set to 1 . This means that the packet will reach the first
router it comes to and be dropped. The destination 4.2.2.1 address is an Internet address so there
has to be at least one router between our source and destination devices, so there is no way this
packet will reach its destination. Good for us, because we don’t want it to.
Figure 6-34: An ICMP echo request packet with a TLL value of 1
The second packet is what we would expect to result from the transmission of the first
packet. It is a reply from the first router we reached along the path to our destination (Figure 635). This packet reached this device at 192.168.100.1, its TTL was decremented to 0, and the
packet could not be transmitted further so the router sent an ICMP response back to us.
Figure 6-35: An ICMP response from the first router along the path
This packet with type 11 , code 0 , indicates the destination was unreachable because the
time to live value of the packet was exceeded during transit. An interesting thing about this
ICMP packet is that it is what we call a double headed packet. This is because the tail end of the
ICMP portion of this packet actually contains a copy of that IP header  and ICMP data  that
was sent in the original echo request. This can prove to be very useful for troubleshooting.
This process happens two more times before moving to packet 7 where we will see the same
thing we did in the first packet, except this time the TTL value in the IP header is set to 2. This
ensures the packet will make it to the second router along the path to its destination before it is
dropped. As expected, we receive a reply from the next hop router, 12.180.241.1 with the same
ICMP destination unreachable and time to live exceeded messages.
This process continues with the TTL value increasing by one until the destination 4.2.2.1 is
finally reached. This process communicates with each router along the path, building a profile of
the path data must take for this communication to happen (Figure 6-36).
Figure 6-36: An example output of the traceroute utility
ICMP has a lot of different functions and we will rely on it a lot as we begin looking at
practical analysis scenarios further along in the book.
Dynamic Host Configuration Protocol (DHCP)
Prior to the advent of DHCP and its predecessor BOOTP, the addressing of devices on a network
was a completely manual process. Any time a device needed to communicate on the network an
address had to be assigned to it by hand. In the early days of networks and the Internet this
wasn’t a very big deal, but as networks grew in size it quickly became cumbersome. In light of
this, the Bootstrap Protocol (BOOTP) was created to handle the automatic assignment of
addresses to those devices. Eventually, this protocol was replaced with the more sophisticated
Dynamic Host Configuration Protocol, which is what we still use.
Ultimately, DHCP is an application layer protocol that is responsible for providing a means
for a device to automatically obtain an IP address when it doesn’t have one. Most DHCP servers
in use today will also provide other parameters to clients such as the addresses of the default
gateway and DNS servers in use on the network.
The DHCP Packet Structure
A DHCP packet can be quite lengthy depending on the amount of information it is providing to a
client (Figure 6-37).
Figure 6-37: The DHCP Packet Structure
OpCode: Indicates whether the packet is a DHCP Request or a DHCP reply
Hardware Type: Identifies the type of hardware address (10 MB Ethernet, 100 MB
Ethernet, etc)
Hardware Length: The length of the hardware address
Hops: Used by relay agents to assist in finding a DHCP server
Transaction ID: Contains a random number used to pair requests with responses
Seconds Since Boot: Identifies how long has elapsed (in seconds) since the client initially
requested an address from the DHCP server
Flags: Used to identify the types of traffic the DHCP client can accept (unicast,
broadcast, etc)
Client IP Address: Contains the clients IP address when it receives one
Your IP Address: Contains the IP address being offered by the DHCP server
Server IP Address: Contains the IP address of the DHCP server
Gateway IP Address: Contains the IP address of the network default gateway
Client Hardware Address: Contains the MAC address of the client
Server Host Name: Contains the host name of the server (optional)
Boot File: Contains a boot file for use by DHCP (optional)
Options: Used to expand the structure of the DHCP packet, increasing its functionality
The DHCP Renewal Process
The primary goal of DHCP is to assign addresses to clients, and that’s what happens during the
renewal process. This process isn’t too entirely complicated and takes place between a single
client and a DHCP server. We can see this happening in the file dhcp_nolease_renewal.pcap.
The renewal process is often referred to as the DORA process. This is because it uses four types
of DHCP packet: Discover, Offer, Request, and Acknowledgement (Figure 6-38).
Figure 6-38: The DHCP DORA Process
Discover
The first packet is sent from 0.0.0.0 on port 68 to 255.255.255.255 on port 67. The address of
0.0.0.0 is used because the client does not yet have an IP address. The packet is sent to
255.255.255.255 because this is the broadcast address, ensuring this packet will be sent out to
every device on the network. Not only does the device not know its own IP address, it doesn’t
know the address of a DHCP server either, so the purpose of this first packet is to attempt to find
any DHCP server that will listen.
Examining the packet details window, the first thing you will notice is that DHCP relies on
UDP as its transport layer protocol. DHCP is very concerned with the speed at which a client
receives the information its requesting and has its own built in reliability measures, which means
UDP is a perfect fit.
We can see the details of the process by examining the DHCP portion of the packet in the
packet details window (Figure 6-39).
Note: Wireshark actually still references BOOTP when dealing with DHCP. This can been in
packet details window where you won’t find a DHCP section, but rather a Bootstrap
Protocol section. I’ll be referring to this as the DHCP portion of the packet throughout
this book, so make sure you remember this as to not get confused.
Figure 6-39: The DHCP Discover Packet
This packet is a request and is identified by the value of 1 in the message type field . The
majority of the fields in this discovery packet are either blank (the IP address fields ) or pretty
standard (hardware type, length, etc). The “meat” of this packet is in its options. You can see that
this packet has four option fields. The first of these options is option type 53, with a length of 1
and a value of 1 indicating that this is a DHCP Discover packet . You will notice that the real
flexibility of the DHCP protocol actually lies in its available options. There are a whole bunch of
options available and we won’t cover all of the ones that are available, or even all of the ones
seen in this capture file, but you can view a full list at http://www.iana.org/assignments/bootpdhcp-parameters/.
Of the other options the client identifier provides some additional information about the
client requesting an IP address, the requested IP address option supplies the IP address to client
would like to receive (typically its previously used IP), and the parameter request list contains a
listing of the different configuration items the client would like to receive from the DHCP server.
Offer
The second packet in this file actually lists valid IP addresses in its IP header, showing a packet
from 192.168.0.1 traveling to 192.168.0.10 (Figure 6-40). The client does not actually have the
192.168.0.1 address yet, so the server will first attempt to communicate back to the client using
its hardware address as provided by ARP (if this is not possible then it will simply broadcast the
offer).
Figure 6-40: The DHCP Offer Packet
The DHCP portion of this packet indicates that the message type is a reply . This packet
also contains the same transaction ID as the previous packet, so we can be sure that this
reply is indeed to response to our original request.
The purpose of the offer packet is for the DHCP server to offer its services to the client. It
does this by supplying information about itself and the addressing it wants to provide back to the
client. We see this here where the Your IP Address field has 192.168.0.10 listed, indicating that
this is the IP address the DHCP server would like to give to the client . We also see a value of
192.168.0.1 in the Next Server IP Address field, indicating that our DHCP server and default
gateway share the same IP address .
Of the options listed, the first identifies the packet as a DHCP Offer . The remaining
options are all supplied by the server and indicate the additional information it can offer along
with the clients IP address. Here we can see that it offers a subnet mask of 255.255.255.0, a
renewal time of 30 minutes, a rebinding time value of 52 minutes and 30 seconds, and IP address
lease time of 1 hour, and a DHCP server identifier of 192.168.0.1.
Request
Once the client has received an offer from the DHCP server it must accept the offer by formally
requesting the information that was offered to it, which is done by the DHCP Request packet
(Figure 6-41).
Figure 6-41: The DHCP Request Packet
The third packet listed in the capture file still comes from the IP address 0.0.0.0 because we
have not completed the process of obtaining an IP address . The packet now knows the DHCP
server it is communicating with so it can communicate to it directly.
This packet is a request , and although it is part of the same renewal process it has a new
transaction ID since this is a new request/reply transaction . This packet is similar to the
discover packet in that all of the IP addressing information in the packet is blank. The options
fields identify this as a DHCP Request , provide client identifier information, provide a
requested IP address (no longer blank), provide the DHCP server identifier, and provide the
additional parameters that are requested.
Acknowledgement
The final step in this process is the final acknowledgement in which the DHCP server officially
sends the addressing information to the client and records it in its database (Figure 6-42).
Figure 6-42: The DCHP Acknowledgement Packet
The client now has an IP address and can begin communicating on the network with it.
In-Lease Renewal
When a DHCP server assigns an IP address to a device it does so on a leased basis. This means
that the client is only allowed to use the IP address for a limited amount of time before it must
renew the lease. The DORA process we just covered is what happens the first time a client gets
an IP address or when its lease time is expired. In either situation the device is considered to be
“out of lease”. When a client that already has an IP address and is “in lease” reboots, it must
perform a truncated version of this process in order to reclaim its IP address. This process is
called an in-lease renewal.
If you understand how an out of lease renewal works then you actually already know how an
in-lease renewal works. Think of it as the same DORA process as the out of lease renewal,
except the in-lease renewal doesn’t really “DO” as much. That’s because the Discover and Offer
packets are no longer necessary. All that is necessary are the Request and Acknowledgement
packets. There isn’t much new to see here, but if you are curious I’ve included a sample of an inlease renewal in the file dhcp_inlease_renewal.pcap.
DHCP Options and Message Types
As we’ve seen, the DHCP options portion of the packet can vary in size and can include a lot of
information. There are a great deal of DHCP options available, and you can view a full list of
these options at http://www.iana.org/assignments/bootp-dhcp-parameters/. The overall size of the
packet is dependent upon the combination of options used.
The only option that is required in all DHCP packets is the Message Type option (option 53).
This identifies how the DHCP client or server will process the information contained within the
packet. There are eight message types, define in Table 6-1.
Table 6-1: DHCP Message Types
Type Number
Message Type
Description
1
Discover
Used by the client to locate available DHCP servers
2
Offer
Sent by the server to the client in response to a discover packet
3
Request
Sent by the client to formally request the offered parameters from
the server
4
Decline
Sent by the client to the server to indicate invalid parameters
within a packet
5
ACK
Sent by the server to the client with the configuration parameters
requested
6
NAK
Sent by the client to the server to refuse a request for
configuration parameters
7
Release
Sent by the client to the server to cancel a lease by releasing its
configuration parameters
8
Inform
Sent by a client to the server to ask for configuration parameters
when the client already has an IP address
Domain Name System (DNS)
The Domain Name System is one of the most crucial protocols in use on the Internet because it is
the proverbial molasses that holds the bread together. That’s because it is what ties IP address
such as 209.85.225.99 to names such as www.google.com. Whenever we want to communicate
with something we typically don’t know its IP address by memory, so we access it via its DNS
name. You won’t see DNS names in the middle of an IP header, so we have to have a
mechanism to convert those DNS names to IP addresses so we can construct packets and
communicate properly.
A DNS server itself works by storing a database of entries (called resource records) of IP
address to DNS name mappings, communicating those resource records to clients, and
communicating those resource records to other DNS servers. The architecture of DNS servers
throughout enterprises and the Internet is something that can be a bit complicated. As a matter of
fact, there are whole books dedicated to DNS architecture. We won’t cover architectural aspects
or even all of the different types of DNS traffic (you can review the various DNS related RFC’s
at http://www.dns.net/dnsrd/rfc/), but we will look at some common types of DNS traffic.
The DNS Packet Structure
The DNS packet structure is somewhat unique compared to previous packet types we’ve seen
thus far (Figure 6-43).
Figure 6-43: The DNS Packet Structure
DNS ID Number: Used to associate DNS queries with DNS responses
Query/Response (QR): Denotes whether the packet is a DNS query or response
OpCode: Defines the type of query contained in the message
Authoritative Answers (AA): If this value is set in a response packet it indicates that the
response is from a name server who is the authority for the domain
Truncation (TC): Indicates that the response was truncated because it was too large to fit
within the size limits of the packet
Recursion Desired (RD): If this value is set in a query it indicates that the DNS client
requests a recursive query if the target name server does not contain the information
requested
Recursion Available (RA): If this value is set in a response it indicates that the name
server supports recursive queries
Reserved (Z): Defined by RFC 1035 to be set as all 0’s, however, sometimes used as an
extension of the RCode field
Response Code (RCode): Used in DNS responses to indicate the presence of any errors
Question Count: The number of entries in the Questions section
Answer Count: The number of entries in the Answers section
Name Server Count: The number of name server resource records in the Authority
section
Additional Records Count: The number of other resource records in the Additional
Information section
Questions Section: Variable sized section that contains one or more queries for
information to be sent to the DNS server
Answers Section: Variable sized section that carries one or more resource records that
answer queries
Authority Section: Variable sized section that contains resource records that point to
authoritative name servers that can be used to continue the resolution process
Additional Information Section: Variable sized section that contains resource records that
contain additional information related to the query that is not absolutely necessary to
answer the queries
A Simple DNS Query
As you may have picked up by now, DNS functions in a query/response type format. A client
wishing to resolve a DNS name to an IP address sends a query to a DNS server, and the server
sends the requested information in its response. In its simplest form this process takes two
packets, and can be seen in the capture file dns_query_response.pcap.
The first packet is a DNS query sent from the client 192.168.0.114 to the server
205.152.37.23 on port 53, which is the standard port used by DNS (Figure 6-44).
Figure 6-44: The DNS Query packet
When you begin examining the headers present in this packet you will be able to see that
DNS also relies on UDP . Moving to the DNS portion of the packet you can see that smaller
fields near the beginning of the packet are condensed by Wireshark into a single Flags section. If
you expand you can determine that the message is indeed a standard query , it is not truncated,
and that recursion is desired if necessary. Only a single question is identified. This question can
be found by expanding the queries section of the packet where you can see the query is for the
name wireshark.org for a host (type A) Internet (IN) address . This packet is basically saying
“What is the IP address associated with the wireshark.org domain?”.
The response to this request can be found in packet two (Figure 6-45). The packet contains
an identical identification number  so know this is the correct response to match the original
query.
Figure 6-45: The DNS Response packet
The flags section indicates that this is indeed a response and that recursion is available if
necessary . The packet indicates that there is one question as well as one resource record .
This is because the packet includes the original question in conjunction with its answer.
Expanding the answers section will yield the response to the query, that the IP address of
wireshark.org is 128.121.150.122 . With this information, the client can now construct IP
packets and begin communicating with wireshark.org.
DNS Question Types
The Type fields used in DNS queries and responses are used to indicate the resource record type
the query or response is for. Some of the more common message/resource record types are
defined in Table 6-2.
Table 6-2: Common DNS Resource Record Types
Value
Type
Description
1
A
IPv4 host address
2
NS
Authoritative name server
5
CNAME
Canonical name for an alias
15
MX
Mail exchange
16
TXT
Text string
28
AAAA
IPv6 host address
251
IXFR
Incremental zone transfer
252
AXFR
Full zone transfer
You will be seeing these more common types throughout normal traffic and this book. This
list is brief and by no means thorough, so if you wish to review all DNS resource record types,
you can do so at http://www.dns.net/dnsrd/rr.html/.
DNS Recursion
Due to the hierarchical nature of the DNS structure of the Internet, DNS servers need the ability
to communicate with each other in order to locate answers for the queries submitted by clients.
After all, it might be fair to expect our internal DNS server to know the name to IP address
mapping of our local intranet server, but we can’t expect it to know the IP address correlated
with Google or Dell. This is where recursion comes into play. Recursion is when one DNS
server queries another DNS server on behalf of a client who has made a request. Basically, this
turns a DNS server into a client itself.
We will view the recursion process from both the DNS client and server perspective, starting
with a capture of the clients DNS traffic in the file dns_recursivequery_client.pcap.
This file contains two packets. The first is our initial query sent from the DNS client
172.16.0.8 to its DNS server 172.16.0.102 (Figure 6-46).
Figure 6-46: The DNS Query with the Recursion Desired Bit Set
If we expand the DNS portion of this packet we can see that this is a standard query for an A
type record for the DNS name www.nostarch.com . We can learn more about the packet by
expanding the flags section where you will see that recursion is desired if it is necessary .
The second packet looks exactly like what we would expect to see in response to the initial
query (Figure 6-47).
Figure 6-47: The DNS Query Response
The transaction ID of this packet matches that of our query , no errors are listed, and we
receive the A type resource record associated with www.nostarch.com .
With that being all of the information we are given, how can we see that this query was
answered by way of recursion? Well, we can’t unless we are listening to the traffic of the DNS
server where the recursion is taking place. Lucky for you, we have that traffic in the file
dns_recursivequery_server.pcap.
This file is a capture of the traffic on the local DNS server during the time in which the query
was initiated. The first packet will look familiar as it is the same initial query we saw in the
previous capture file. At this point the DNS server has received this query, checked its local
database, and realized it does not know the answer to the question that it has been asked. Being
as the packet was sent with the recursion desired bit set, the DNS server can ask another DNS
server this question in an attempt to locate the answer, which is what is happening in the second
packet.
In this packet the DNS server at 172.16.0.102 transmits a new query to 4.2.2.1, which is the
server it is configured to forward upstream requests to (Figure 6-48). This query mirrors the
original query, effectively turning the DNS server into a client.
Figure 6-48: The Recursive DNS Query
We can tell that this is indeed a new query by examining the transaction ID number, which
his different than the transaction ID number in the last capture file. Following this packet, the
local DNS server receives a response from the DNS server at 4.2.2.1 (Figure 6-49).
Figure 6-49: Response to the Recursive DNS Query
Once received, the local DNS server can transmit the fourth and final packet to the DNS
client with the information it has requested.
Although we only showed one layer of recursion in this example, recursion can occur many
times for a single DNS request. Although we received an answer from the DNS server at 4.2.2.1
there is nothing to say that it didn’t retransmit the query recursively to another server in order to
find the answer. A simple query can travel all over the world before it finally gets a correct
response (Figure 6-50).
Figure 6-50: A Recursive DNS Query
DNS Zone Transfers
One term we’ve not yet examined as it pertains to DNS is a DNS zone. A zone is the namespace
a DNS server has been delegated the authority to manage. For instance, if your organization is
named Emma’s Diner, you might have a single DNS server responsible for emmasdiner.com.
Any device inside or outside of your organization that wishes to resolve emmasdiner.com to an
IP address would then have to contact your DNS server because it is the authority for that zone.
If Emma’s Diner starts to grow and decides they need a second DNS server to handle the e-mail
portion of their DNS namespace, they could have a second DNS server responsible for
mail.emmasdiner.com. This server would only be the authority for the mail subdomain of
emmasdiner.com (Figure 6-51).
Figure 6-51: DNS Zones Divide Responsibility for Namespaces
A zone transfer occurs when zone data must be transferred between two devices. There are
many reasons why a zone transfer may occur, with the most common being redundancy. In
organizations with multiple DNS servers it is common for administrators to configure a DNS
server to maintain a copy of another servers DNS zone information in case the primary DNS
server were to become unavailable. In order to do this, zone data must be replicated on a frequent
basis which is where a zone transfer comes into play.
You can look at an example of a zone transfer by opening the file dns_axfr.pcap. There are
two types of zone transfers, a full zone transfer, abbreviated as AXFR, and an incremental zone
transfer, abbreviated as IXFR. The former transfers an entire zone between devices and the latter
only transfers a portion of the zone. As the filename denotes, this example is a full zone transfer
and is occurring between the hosts 172.16.16.164 and 172.16.16.139.
When you first look at the contents of this file you may be drawn to double check whether or
not you’ve opened the right file because rather than seeing the UDP packets you’re used to
seeing in the DNS packets we’ve examine thus far, you are presented with a collection of TCP
packets. Although I did indeed state earlier that DNS relies on UDP, it actually can use TCP for a
few select tasks in which it is required due to the size or importance of the data being
transmitted. A zone transfer is one of those instances in which UDP can’t be relied on because of
the importance that the complete set of zone data be received. Because the zone transfer is using
TCP, the first three packets seen in this capture file are the TCP three-way handshake that sets up
the communication process.
The fourth packet is the beginning of the actual zone transfer request sent from
172.16.16.164 to 172.16.16.139. This packet doesn’t actually contain any DNS information and
is noted as being a “TCP segment of a reassembled PDU”. This just means that the data sent in
the zone transfer request packet was larger than could be contained in a single packet and took
both packets 4 and 6 to contain all of this data, with packet 5 being an acknowledgement that
packet 4 was received. The packet is displayed in this manner because of the Wireshark TCP
dissectors TCP reassembly option, designed to make the packets easier to follow. For our
purposes here, we can reference packet 6 as the complete DNS zone transfer request (Figure 552).
Figure 6-52: DNS Full Zone Transfer Request
The zone transfer request is actually just a standard query, but instead of requesting a
single record type it requests the AXFR type , signifying it wishes to receive the entire DNS
zone from the server it is communicating with. The server responds in kind with the zone records
in packet 7 (Figure 6-53).
Figure 6-53: The DNS Full Zone Transfer Occurring
The zone transfer contains quite a bit of data, and this is only for a very simple DNS
configuration with no client records. The amount of data a zone transfer can give is something
that can be very valuable in the wrong hands. Enumerating a single DNS server can map out the
entire infrastructure of a network, which is why we will revisit this concept later when we are
looking security applications of packet analysis. For now, the zone transfer has been completed
and the capture file ends with the TCP connection teardown process.
Hypertext Transfer Protocol (HTTP)
The Hypertext Transfer Protocol is the language of the World Wide Web. It works in a
client/server type of architecture in which clients can use web browsers to connect to web servers
to view web pages. In most organizations HTTP is by far the highest percentage of traffic seen
going across the wire. Every time you do a Google search, connect to Twitter to send a tweet, or
check University of Kentucky basketball scores on ESPN you are using HTTP to do so.
At this point we won’t be covering packet structures because the remaining protocols we will
be looking at have widely varying structures depending on their purposes. Also, by now you
should be fairly comfortable with the packet details window in Wireshark so that you can
determine the contents of a packet yourself. That being said, we can look at some practical
applications of HTTP.
Browsing with HTTP
The most common use of HTTP is the browsing of web pages hosted on a web server, by use of
a web browser on a client. A sample of this can be seen in the file http_google.pcap. HTTP
utilizes TCP as its transport layer protocol, thus the communication begins with a three-way
handshake between the web browser client 172.16.16.128 and the Google web server
74.125.95.104.
Once communication has been established the first packet we see is marked as an HTTP
packet from client to server (Figure 6-54).
Figure 6-54: The Initial HTTP GET Request Packet
The HTTP packet is delivered over TCP to the servers port 80 , which is the standard port
for HTTP communication (8080 is also commonly used).
HTTP packets are identified by one of eight different request methods which indicate the
action the transmitter of the packet will be performing on the receiver. This packet identifies its
method as GET, its request URI (Uniform Resource Indicator) as /, and the request version as
HTTP 1.1 . Essentially, this is saying that the client is sending a request to download (GET)
the root web directory (/) of the web server using version 1.1 of HTTP (HTTP 1.1). Following
this portion of the initial HTTP packet the host sends information about itself to the web server.
This information includes things such as the user-agent (browser) being used, languages
accepted by the browser, and cookie information. The server can then take this information and
use it to determine what data it sends back to the client to ensure it is compatible.
When the server receives the HTTP GET request in packet four, it responds with a TCP
ACK, acknowledging that it received the packet, and begins transmitting the requested data from
packets 6 to 11. Take note that although we are talking about HTTP traffic, HTTP is only used to
issuing application layer commands between the client and server. When it comes time to
actually transfer data no application layer control is needed, and the data packets are simply TCP
packets. TCP handles transmission with data sent from the server in packets 6 and 7, an
acknowledgement from the client in packet 8, two more data packets in packets 9 and 10, and
another acknowledgement in packet 11 (Figure 6-55).
Figure 6-55: TCP Transmitting Data between the Client Browser and Web Server
Once the data is transferred the server sends another HTTP packet, but rather than having a
request method, this packet has a response code (Figure 6-56).
Figure 6-56: Final HTTP Packet with Response Code 200
HTTP has a number of predefined response codes used to indicate the results of a request
method. In this case we see a packet with the response code 200 , which indicates a successful
request method. The packet also includes a timestamp and some additional information about the
encoding of the content and configuration parameters of the web server. One the client receives
this packet the transaction is completed.
Posting Data with HTTP
We’ve just looked at downloading data from a web server and will now turn our attention to
uploading data instead. In the file http_post.pcap there is an example of this as a user posts a
comment to a website. After the initial three way handshake the client (172.16.16.128) sends an
HTTP packet to the web server (69.163.176.56) (Figure 6-57).
Figure 6-57: The HTTP POST Packet
This packet uses the POST method , which is used to upload data to a web server for
processing. The POST method used in this packet specifies the URI /wp-comments-post.php ,
and the HTTP 1.1 request version. You can actually see the contents of the data that was posted
by expanding the Line-based Text Data portion of the packet . After the data is transmitted in
this POST, an ACK packet is sent.
The server then responds with packet 6, which transmits the response code 302 , Found
(Figure 6-58).
Figure 6:58: HTTP Response 302 is used to Redirect
This may seem a like a bit of an odd response, but the 302 response code is actually a
common means of redirection in the HTTP world. In the case of this packet you should note the
Location field . This field specifies where the client is to be directed to. In this case, the client
is redirected back to the same page it was originally on, with an anchor point to the comment that
was just posted.
The content of this page is transmitted over the next several packets and the server transmits
its status code 200 to complete the transmission.
These example are about as simple as web traffic can get. In most cases web pages are much
more complex and will often make calls to other domains for additional content, which will
spawn completely new TCP connections that will be occurring simultaneously. Try going to
busier sites such as CNN.com or ESPN.com to view some very busy HTTP traffic and see if you
can keep track of all that’s going on.
Final Thoughts
The goal of this chapter has been to give you an introduction into the most common protocols
you will experience when examining traffic and to provide practical examples of real traffic
captures on the wire. If you already have a good grasp on individual protocols then you may feel
that this chapter was a bit light, but remember that this book isn’t meant to be a complete
reference guide to every single protocol you may encounter, and it isn’t going to cover every
facet of the protocols discussed. The goal here is to begin looking at practical situations in which
we examine network misconfigurations, application issues, network latency, security incidents,
and more. The rest of this book is devoted to those practical scenarios and we will examine new
protocols and newer features of other protocols we’ve covered here.
If you still have a thirst for learning more about individual protocols then you can read their
associated RFC, or you can take a look at some of the other resources I have listed in the last
chapter of this book.