1
THE BASICS OF NETWORKING
To attack network protocols, you need to understand the basics of computer networking. The more you understand how common networks are built and function, the easier it will be to apply that knowledge to capturing, analyzing, and exploiting new protocols.
Throughout this chapter, I’ll introduce basic network concepts you’ll encounter every day when you’re analyzing network protocols. I’ll also lay the groundwork for a way to think about network protocols, making it easier to find previously unknown security issues during your analysis.
Network Architecture and Protocols
Let’s start by reviewing some basic networking terminology and asking the fundamental question: what is a network? A network is a set of two or more computers connected together to share information. It’s common to refer to each connected device as a node on the network to make the description applicable to a wider range of devices. Figure 1-1 shows a very simple example.
Figure 1-1: A simple network of three nodes
The figure shows three nodes connected with a common network. Each node might have a different operating system or hardware. But as long as each node follows a set of rules, or network protocol, it can communicate with the other nodes on the network. To communicate correctly, all nodes on a network must understand the same network protocol.
A network protocol serves many functions, including one or more of the following:
Maintaining session state Protocols typically implement mechanisms to create new connections and terminate existing connections.
Identifying nodes through addressing Data must be transmitted to the correct node on a network. Some protocols implement an addressing mechanism to identify specific nodes or groups of nodes.
Controlling flow The amount of data transferred across a network is limited. Protocols can implement ways of managing data flow to increase throughput and reduce latency.
Guaranteeing the order of transmitted data Many networks do not guarantee that the order in which the data is sent will match the order in which it’s received. A protocol can reorder the data to ensure it’s delivered in the correct order.
Detecting and correcting errors Many networks are not 100 percent reliable; data can become corrupted. It’s important to detect corruption and, ideally, correct it.
Formatting and encoding data Data isn’t always in a format suitable for transmitting on the network. A protocol can specify ways of encoding data, such as encoding English text into binary values.
The Internet Protocol Suite
TCP/IP is the de facto protocol that modern networks use. Although you can think of TCP/IP as a single protocol, it’s actually a combination of two protocols: the Transmission Control Protocol (TCP) and the Internet Protocol (IP). These two protocols form part of the Internet Protocol Suite (IPS), a conceptual model of how network protocols send network traffic over the internet that breaks down network communication into four layers, as shown in Figure 1-2.
Figure 1-2: Internet Protocol Suite layers
These four layers form a protocol stack. The following list explains each layer of the IPS:
Link layer (layer 1) This layer is the lowest level and describes the physical mechanisms used to transfer information between nodes on a local network. Well-known examples include Ethernet (both wired and wireless) and Point-to-Point Protocol (PPP).
Internet layer (layer 2) This layer provides the mechanisms for addressing network nodes. Unlike in layer 1, the nodes don’t have to be located on the local network. This level contains the IP; on modern networks, the actual protocol used could be either version 4 (IPv4) or version 6 (IPv6).
Transport layer (layer 3) This layer is responsible for connections between clients and servers, sometimes ensuring the correct order of packets and providing service multiplexing. Service multiplexing allows a single node to support multiple different services by assigning a different number for each service; this number is called a port. TCP and the User Datagram Protocol (UDP) operate on this layer.
Application layer (layer 4) This layer contains network protocols, such as the HyperText Transport Protocol (HTTP), which transfers web page contents; the Simple Mail Transport Protocol (SMTP), which transfers email; and the Domain Name System (DNS) protocol, which converts a name to a node on the network. Throughout this book, we’ll focus primarily on this layer.
Each layer interacts only with the layer above and below it, but there must be some external interactions with the stack. Figure 1-2 shows two external connections. The link layer interacts with a physical network connection, transmitting data in a physical medium, such as pulses of electricity or light. The application layer interacts with the user application: an application is a collection of related functionality that provides a service to a user. Figure 1-3 shows an example of an application that processes email. The service provided by the mail application is the sending and receiving of messages over a network.
Figure 1-3: Example mail application
Typically, applications contain the following components:
Network communication This component communicates over the network and processes incoming and outgoing data. For a mail application, the network communication is most likely a standard protocol, such as SMTP or POP3.
Content parsers Data transferred over a network usually contains content that must be extracted and processed. Content might include textual data, such as the body of an email, or it might be pictures or video.
User interface (UI) The UI allows the user to view received emails and to create new emails for transmission. In a mail application, the UI might display emails using HTML in a web browser.
Note that the user interacting with the UI doesn’t have to be a human being. It could be another application that automates the sending and receiving of emails through a command line tool.
Data Encapsulation
Each layer in the IPS is built on the one below, and each layer is able to encapsulate the data from the layer above so it can move between the layers. Data transmitted by each layer is called a protocol data unit (PDU).
Headers, Footers, and Addresses
The PDU in each layer contains the payload data that is being transmitted. It’s common to prefix a header—which contains information required for the payload data to be transmitted, such as the addresses of the source and destination nodes on the network—to the payload data. Sometimes a PDU also has a footer that is suffixed to the payload data and contains values needed to ensure correct transmission, such as error-checking information. Figure 1-4 shows how the PDUs are laid out in the IPS.
Figure 1-4: IPS data encapsulation
The TCP header contains a source and destination port number ➊. These port numbers allow a single node to have multiple unique network connections. Port numbers for TCP (and UDP) range from 0 to 65535. Most port numbers are assigned as needed to new connections, but some numbers have been given special assignments, such as port 80 for HTTP. (You can find a current list of assigned port numbers in the /etc/services file on most Unix-like operating systems.) A TCP payload and header are commonly called a segment, whereas a UDP payload and header are commonly called a datagram.
The IP protocol uses a source and a destination address ➋. The destination address allows the data to be sent to a specific node on the network. The source address allows the receiver of the data to know which node sent the data and allows the receiver to reply to the sender.
IPv4 uses 32-bit addresses, which you’ll typically see written as four numbers separated by dots, such as 192.168.10.1. IPv6 uses 128-bit addresses, because 32-bit addresses aren’t sufficient for the number of nodes on modern networks. IPv6 addresses are usually written as hexadecimal numbers separated by colons, such as fe80:0000:0000:0000:897b:581e:44b0:2057. Long strings of 0000 numbers are collapsed into two colons. For example, the preceding IPv6 address can also be written as fe80::897b:581e:44b0:2057. An IP payload and header are commonly called a packet.
Ethernet also contains source and destination addresses ➌. Ethernet uses a 64-bit value called a Media Access Control (MAC) address, which is typically set during manufacture of the Ethernet adapter. You’ll usually see MAC addresses written as a series of hexadecimal numbers separated by dashes or colons, such as 0A-00-27-00-00-0E. The Ethernet payload, including the header and footer, is commonly referred to as a frame.
Data Transmission
Let’s briefly look at how data is transferred from one node to another using the IPS data encapsulation model. Figure 1-5 shows a simple Ethernet network with three nodes.
Figure 1-5: A simple Ethernet network
In this example, the node at ➊ with the IP address 192.1.1.101 wants to send data using the IP protocol to the node at ➋ with the IP address 192.1.1.50. (The switch device ➌ forwards Ethernet frames between all nodes on the network. The switch doesn’t need an IP address because it operates only at the link layer.) Here is what takes place to send data between the two nodes:
The operating system network stack node ➊ encapsulates the application and transport layer data and builds an IP packet with a source address of 192.1.1.101 and a destination address of 192.1.1.50.
The operating system can at this point encapsulate the IP data as an Ethernet frame, but it might not know the MAC address of the target node. It can request the MAC address for a particular IP address using the Address Resolution Protocol (ARP), which sends a request to all nodes on the network to find the MAC address for the destination IP address.
Once the node at ➊ receives an ARP response, it can build the frame, setting the source address to the local MAC address of 00-11-22-33-44-55 and the destination address to 66-77-88-99-AA-BB. The new frame is transmitted on the network and is received by the switch ➌.
The switch forwards the frame to the destination node, which unpacks the IP packet and verifies that the destination IP address matches. Then the IP payload data is extracted and passes up the stack to be received by the waiting application.
Network Routing
Ethernet requires that all nodes be directly connected to the same local network. This requirement is a major limitation for a truly global network because it’s not practical to physically connect every node to every other node. Rather than require that all nodes be directly connected, the source and destination addresses allow data to be routed over different networks until the data reaches the desired destination node, as shown in Figure 1-6.
Figure 1-6: An example of a routed network connecting two Ethernet networks
Figure 1-6 shows two Ethernet networks, each with separate IP network address ranges. The following description explains how the IP uses this model to send data from the node at ➊ on network 1 to the node at ➋ on network 2.
The operating system network stack node ➊ encapsulates the application and transport layer data, and it builds an IP packet with a source address of 192.1.1.101 and a destination address of 200.0.1.50.
The network stack needs to send an Ethernet frame, but because the destination IP address does not exist on any Ethernet network that the node is connected to, the network stack consults its operating system routing table. In this example, the routing table contains an entry for the IP address 200.0.1.50. The entry indicates that a router ➌ on IP address 192.1.1.1 knows how to get to that destination address.
The operating system uses ARP to look up the router’s MAC address at 192.1.1.1, and the original IP packet is encapsulated within the Ethernet frame with that MAC address.
The router receives the Ethernet frame and unpacks the IP packet. When the router checks the destination IP address, it determines that the IP packet is not destined for the router but for a different node on another connected network. The router looks up the MAC address of 200.0.1.50, encapsulates the original IP packet into the new Ethernet frame, and sends it on to network 2.
The destination node receives the Ethernet frame, unpacks the IP packet, and processes its contents.
This routing process might be repeated multiple times. For example, if the router was not directly connected to the network containing the node 200.0.1.50, it would consult its own routing table and determine the next router it could send the IP packet to.
Clearly, it would be impractical for every node on the network to know how to get to every other node on the internet. If there is no explicit routing entry for a destination, the operating system provides a default routing table entry, called the default gateway, which contains the IP address of a router that can forward IP packets to their destinations.
My Model for Network Protocol Analysis
The IPS describes how network communication works; however, for analysis purposes, most of the IPS model is not relevant. It’s simpler to use my model to understand the behavior of an application network protocol. My model contains three layers, as shown in Figure 1-7, which illustrates how I would analyze an HTTP request.
Here are the three layers of my model:
Content layer Provides the meaning of what is being communicated. In Figure 1-7, the meaning is making an HTTP request for the file image.jpg.
Encoding layer Provides rules to govern how you represent your content. In this example, the HTTP request is encoded as an HTTP GET request, which specifies the file to retrieve.
Transport layer Provides rules to govern how data is transferred between the nodes. In the example, the HTTP GET request is sent over a TCP/IP connection to port 80 on the remote node.
Figure 1-7: My conceptual protocol model
Splitting the model this way reduces complexity with application-specific protocols because it allows us to filter out details of the network protocol that aren’t relevant. For example, because we don’t really care how TCP/IP is sent to the remote node (we take for granted that it will get there somehow), we simply treat the TCP/IP data as a binary transport that just works.
To understand why the protocol model is useful, consider this protocol example: imagine you’re inspecting the network traffic from some malware. You find that the malware uses HTTP to receive commands from the operator via the server. For example, the operator might ask the malware to enumerate all files on the infected computer’s hard drive. The list of files can be sent back to the server, at which point the operator can request a specific file to be uploaded.
If we analyze the protocol from the perspective of how the operator would interact with the malware, such as by requesting a file to be uploaded, the new protocol breaks down into the layers shown in Figure 1-8.
Figure 1-8: The conceptual model for a malware protocol using HTTP
The following list explains each layer of the new protocol model:
Content layer The malicious application is sending a stolen file called secret.doc to the server.
Encoding layer The encoding of the command to send the stolen file is a simple text string with a command SEND followed by the filename and the file data.
Transport layer The protocol uses an HTTP request parameter to transport the command. It uses the standard percent-encoding mechanism, making it a legal HTTP request.
Notice in this example that we don’t consider the HTTP request being sent over TCP/IP; we’ve combined the encoding and transport layer in Figure 1-7 into just the transport layer in Figure 1-8. Although the malware still uses lower-level protocols, such as TCP/IP, these protocols are not important to the analysis of the malware command to send a file. The reason it’s not important is that we can consider HTTP over TCP/IP as a single transport layer that just works and focus specifically on the unique malware commands.
By narrowing our scope to the layers of the protocol that we need to analyze, we avoid a lot of work and focus on the unique aspects of the protocol. On the other hand, if we were to analyze this protocol using the layers in Figure 1-7, we might assume that the malware was simply requesting the file image.jpg, because it would appear as though that was all the HTTP request was doing.
Final Words
This chapter provided a quick tour of the networking basics. I discussed the IPS, including some of the protocols you’ll encounter in real networks, and described how data is transmitted between nodes on a local network as well as remote networks through routing. Additionally, I described a way to think about application network protocols that should make it easier for you to focus on the unique features of the protocol to speed up its analysis.
In Chapter 2, we’ll use these networking basics to guide us in capturing network traffic for analysis. The goal of capturing network traffic is to access the data you need to start the analysis process, identify what protocols are being used, and ultimately discover security issues that you can exploit to compromise the applications using these protocols.