Chapter 2. Technical Fundamentals

“If you know the enemy and know yourself, you need not fear the results of a hundred battles.”

—Sun Tsu, The Art of War¹

1. Sun Tsu (Author), Lionel Giles (Translator), The Art of War, El Paso Norte Press, 2005.

The Internet ecosystem is varied and complex. In any network forensic investigation, there are an enormous number of places where evidence may live, some more accessible than others. Often, network-based evidence exists in places that local networking staff may not have considered, leaving it up to the investigator to review the network diagrams and make suggestions for evidence collection.

On the flip side, many networks are configured for functionality and performance, not for monitoring or auditing—and certainly not for forensic investigations. As a consequence, the specific instrumentation or evidence that an investigator might wish for may not exist. Many vendors do not include rich data recording capabilities into their products, and even when they do, such capacities are often disabled by default. For example, local switches may not be configured to export flow record data, or server logfiles might roll over and overwrite themselves on a daily basis.

From Nortel’s line of enterpise-class networking equipment to Linksys’ ubuquitous WRT54G router series in homes and small businesses, organizations can select from a wide variety of equipment for any networking function. As a result, the experience of the network forensic analyst is sure to be varied, inconsistent, and challenging.

In this chapter, we take a high-level look at classes of networking devices, discuss their value for the forensic investigator, and briefly touch upon how their contents might be retrieved. Subsequently, we review the concept of protocols and the OSI model in the context of network forensic investigations. Finally, we talk about key protocols in the Internet Protocol suite, including IPv4, IPv6, TCP, and UDP. This will provide you with a strong technical and conceptual foundation, which we build upon throughout the remainder of this book.

2.1 Sources of Network-Based Evidence

Every environment is unique. Large financial institutions have very different equipment, staff, and network topologies than local government agencies or small health care offices. Even so, if you walk into any organization you will find similarities in network equipment and common design strategies for network infrastructure.

There are many sources of network-based evidence in any environment, including routers, web proxies, intrusion detection systems, and more. How useful is the evidence on each device? This varies depending on the type of investigation, the configuration of the specific device, and the topology of the environment.

Sometimes data from different sources can overlap, which is useful for correlation. Other times the data sources are merely complementary, each containing snippets of evidence not found elsewhere. In this section, we review the types of network equipment that are commonly found in organizations and discuss the types of evidence that can be recovered from each.

2.1.1 On the Wire

Physical cabling is used to provide connectivity between stations on a LAN and the local switches, as well as between switches and routers. Network cabling typically consists of copper, in the form of either twisted pair (TP) or coaxial cable. Data is signaled on copper when stations on the shared medium independently adjust the voltage. Cabling can also consist of fiber-optic lines, which are made of thin strands of glass. Stations connected via fiber signal data through the presence or absence of photons. Both copper and fiber-optic mediums support digital signaling.

Forensic Value

Network forensic investigators can tap into physical cabling to copy and preserve network traffic as it is transmitted across the line. Taps can range from “vampire” taps, which literally puncture the insulation and make contact with copper wires, to surreptitious fiber taps, which bend the cable and cut the sheathing to reveal the light signals as they traverse the glass. Many commercial vendors also manufacture infrastructure taps, which can plug into common cable connectors and are specifically designed to replicate signals to a passive station without degrading the original signal. (Please see Chapter 3, “Evidence Acquisition,” for more details.)

2.1.2 In the Air

An increasingly popular way to transmit station-to-station signals is via “wireless” networking, which consists of radio frequency (RF) and (less commonly) infrared (IR) waves. The wireless medium has made networks very easy to set up. Wireless networks can easily be deployed even without “line-of-sight”—RF waves can and do travel through air, wood, and brick (though the signal will be degraded substantially by particularly dense materials). As a result, enterprises and home users can deploy wireless networks without the expense and hassle of installing cables.

Forensic Value

Essentially, wireless access points act as hubs, broadcasting all signals so that any station within range can receive them. As a result, it is often trivial for investigators to gain access to traffic traversing a wireless network. The traffic may be encrypted, in which case investigators would have to either legitimately obtain the encryption key or break the encryption to access the content.

However, investigators can still gather a lot of information from encrypted wireless networks. Although data packets that traverse a wireless network may be encrypted, commonly management and control frames are not. In the clear, wireless access points advertise their names, presence, and capabilities; stations probe for access points; and access points respond to probes. Even when analyzing encrypted wireless traffic, investigators can identify MAC addresses of legitimate authenticated stations, unauthenticated stations and suspicious stations that may be attacking the wireless network. Investigators can also conduct volume-based statistical traffic analysis and analyze these patterns.

With access to unencrypted or decrypted wireless traffic, of course, investigators can review the full packet captures in detail.

2.1.3 Switches

Switches are the glue that hold our LANs together. They are multiport bridges that physically connect multiple stations or network segments together to form a LAN. In modern deployments, we tend to see switches connected to other switches connected to other switches ad nauseum to form a complex switched network environment.

In a typical deployment, organizations have “core” switches, which aggregate traffic from many different segments, as well as “edge” switches,² which aggregate stations on individual segments. Consequently, traffic from one station to another within an enterprise may traverse any number of switches, depending on the physical network topology and the locations of the stations within it.

2. “Encyclopedia—PC Magazine,” http://www.pcmag.com/encyclopedia_term/0,2542,t=edge+switch&i=42362,00.asp.

Forensic Value

Switches contain a “content addressable memory” (CAM) table, which stores mappings between physical ports and each network card’s MAC address. Given a specific device’s MAC address, network investigators can examine the switch to determine the corresponding physical port, and potentially trace that to a wall jack and a connected station.

Switches also provide a platform from which investigators can capture and preserve network traffic. With many types of switches, network staff can configure one port to “mirror” (copy) traffic from any or all other ports or VLANs, allowing investigators to capture traffic from the mirroring port with a packet sniffer. Please see Section 3.1.4.1 for more detail.

2.1.4 Routers

Routers connect different subnets or networks together and facilitate transmission of packets between different network segments, even when they have different addressing schemes.

Routers add a layer of abstraction that enables stations on one LAN to send traffic destined for stations on another LAN. Internetworking using routers is what allows us to build campus-wide metropolitan area networks (MANs) or connect remote offices around the globe via wide area networks (WANs). From a certain perspective, the entire global Internet is nothing but a global area network (GAN), connected through a complex multilayer web of routers.

Forensic Value

Where switches have CAM tables, routers have routing tables. Routing tables map ports on the router to the networks that they connect. This allows a forensic investigator to trace the path that network traffic takes to traverse multiple networks. (Note that this path can vary dynamically based on network traffic levels and other factors.)

Depending on the specific device’s capabilities, routers may also function as packet filters, denying the transmission of certain types of traffic based on source, destination, or port. Routers may log denied traffic (or sometimes maintain statistics on allowed traffic). Many enterprise-class routers can be configured to send logs and flow record data to a central logging server, which is extremely helpful for investigators, as this makes it very easy to correlate events from multiple sources. Logs stored on the router itself may be volatile and subject to erasure if the device is rebooted or if the available storage is exceeded.

In short, routers are the most rudimentary network-based intrusion detection systems in our arsenal, and also the most widely deployed.

2.1.5 DHCP Servers

The Dynamic Host Configuration Protocol (DHCP) is widely used as the mechanism for assigning IP addresses to LAN stations, so that they can communicate with other stations on the local network, as well as with systems across internetworked connections. In the early days of networking, administrators had to manually configure individual desktops with static IP addresses. DHCP was developed to provide automated IP address assignments, which could change dynamically as needed, dramatically reducing manual workload for administrators. DHCP service is often provided by the edge devices that perform routing between networks (routers, wireless access points, etc.), but it is not uncommon to find this service provided by infrastructure servers instead.

Forensic Value

Frequently, investigations begin with the IP address of a host that is suspected of being involved in some sort of adverse event—whether it was the victim of an attack, the origin, or perhaps both. One of the first tasks the investigator must undertake is to identify and/or physically locate the device based on its IP address.

When DHCP servers assign (or “lease”) IP addresses, they typically create a log of the event, which includes the assigned IP address, the MAC address of the device receiving the IP address, and the time the lease was provided or renewed. Other details, such as the requesting system’s hostname, may be logged as well. Consequently, DHCP logs can show an investigator exactly which physical network card was assigned the IP address in question during the specified time frame.

2.1.6 Name Servers

Just as we need a mechanism to map MAC addresses to IP addresses, we also need a mechanism to map IP addresses to the human-readable names that we assign to systems and networks. To accomplish this, enterprises typically use the Domain Name System (DNS), in which individual hosts query central DNS servers when they need to map an IP address to a hostname, or vice versa. DNS is a recursive hierarchical distributed database; if an enterprise’s local DNS server does not have the information to resolve a requested IP address and hostname, it can query another DNS server for that information.

Forensic Value

DNS servers can be configured to log queries for IP address and hostname resolutions. These queries can be very revealing. For example, if a user on an internal desktop browses to a web site, the user’s desktop will make a DNS query to resolve the host and domain names of the web server prior to retrieving the web page. As a result, the DNS server may contain logs that reveal connection attempts from internal to external systems, including web sites, SSH servers, external email servers, and more.

DNS servers can log not only queries, but also the corresponding times. Therefore, forensic investigators can leverage DNS logs to build a timeline of a suspect’s activities.

2.1.7 Authentication Servers

Authentication servers are designed to provide centralized authentication services to users throughout an organization so that user accounts can be managed in one place, rather than on hundreds or thousands of individual computers. This allows enterprises to streamline account provisioning and audit tasks.

Forensic Value

Authentication servers typically log successful and/or failed login attempts and other related events. Investigators can analyze authentication logs to identify brute-force password-guessing attacks, account logins at suspicious hours or unusual locations, or unexpected privileged logins, which may indicate questionable activities. Unlike analysis of authentication logs on a single hard drive, a central authentication server can provide authentication event information about all devices within an entire authentication domain, including desktops, servers, network devices, and more.

2.1.8 Network Intrusion Detection/Prevention Systems

Unlike the devices we’ve discussed so far, network intrusion detection systems (NIDSs) and their newer incarnations, network intrusion prevention systems (NIPSs), were specifically designed to provide security analysts and forensic investigators with information about network security–related events. Using several different methods of operation, NIDS/NIPS devices monitor network traffic in real time for indications of any adverse events as they transpire. When incidents are detected, the NIDS/NIPS can alert security personnel and provide information about the event. NIPSs may further be configured to block the suspicious traffic as it occurs.

The effectiveness of NIDS/NIPS deployments depends on many factors, including precisely where sensors are placed in the network topology, how many are installed, and whether they have the capacity to inspect the increasing volumes and throughputs of traffic we see in the modern enterprise environment. While NIDS/NIPS may not be able to inspect, or alert on, every event of interest, with a well-engineered deployment, they can prove indispensable.

Forensic Value

At a high level, the forensic value of a NIDS/NIPS deployment is obvious: They are designed to provide timely data pertaining to adverse events on the network. This includes attacks in progress, command-and-control traffic involving systems already compromised, or even simple misconfigurations of stations.

The value of this data provided by NIDS/NIPS is highly dependent upon the capabilities of the device deployed and its configuration. With many devices it is possible to recover the entire contents of the network packet or packets that triggered an alert. Often, however, the data that is preserved contains little more than the source and destination IP addresses, the TCP/UDP ports, and the time the event occurred. During an ongoing investigation, forensic investigators can request that network staff tune the NIDS to gather more granular data for specific events of interest or specific sources and destinations. (Please see Chapter 7 for more detail.)

2.1.9 Firewalls

Firewalls are specialized routers designed to perform deeper inspection of network traffic in order to make more intelligent decisions as to what traffic should be forwarded and what traffic should be logged or dropped. Unlike most routers, modern firewalls are designed to make decisions based not only on source and destination IP addresses, but also based on the packet payloads, port numbers, and encapsulated protocols.

These days, nearly every organization has deployed firewalls on their network perimeters—the network boundaries between the enterprise and their upstream provider. In an enterprise environment, firewalls are also commonly deployed within internal networks to partition network segments in order to provide enclaves that are protected from each other. Even home users often have at least rudimentary firewall capabilities built into home routers, which are leased from their ISPs or purchased off-the-shelf.

Forensic Value

Originally, event logging was of secondary importance for firewall manufacturers. Firewalls were not initially designed to alert security personnel when security violations were taking place, even though they were most definitely designed to implement security policies to prevent violations.

Today, modern firewalls have granular logging capabilities and can function as both infrastructure protection devices and fairly useful IDSs as well. Firewalls can be configured to produce alerts and log allowed or denied traffic, system configuration changes, errors, and a variety of other events. These logs can help operators manage the network and also serve as evidence for forensic analysts.

2.1.10 Web Proxies

Web proxies are commonly used within enterprises for two purposes: first, to improve performance by locally caching web pages and, second, to log, inspect, and filter web surfing traffic. In these deployments, web traffic from local clients is funneled through the web proxy. The web proxy may either allow or deny the web page request (often based on published blacklists of known inappropriate or malicious sites or on keywords in the outbound web traffic).

Once the page is retrieved, the web proxy may inspect the returned content and choose to allow, block, or modify it. For performance, the web proxy may cache the web page and later serve it to other local clients upon request so that there is no need to make multiple requests across the external network for the same web sites within a short period of time. The precise functionality of the web proxy is strongly dependant upon the specific configuration; some organizations choose to limit logging and run their web proxy only for performance reasons, whereas other organizations heavily monitor and filter incoming and outbound web traffic for security reasons.

There are also “anonymizing proxies,” which are set up with the explicit purpose of providing anonymity to clients who deliberately funnel web surfing traffic through them. End clients send their traffic through an anonymous web proxy so that the remote web server only sees the proxy’s IP address rather than the end-user’s IP address. Depending on the precise configuration of the anonymizing proxy, the proxy server may still cache extensive information regarding the end-user’s web surfing behavior.

Forensic Value

Web proxies can be a gold mine for forensic investigators, especially when they are configured to retain granular logs for an extended period of time. Whereas forensic analysis of a single hard drive can produce the web surfing history for users of a single device, an enterprise web proxy can literally store the web surfing logs for an entire organization.

There are many commercial and free applications that can interpret web proxy logs and provide visual reports of web surfing patterns according to client IP address or even username (i.e., when correlated with Active Directory logs). This can help forensic analysts gather lists of users who may have succumbed to a phishing email, investigate a roving user’s inappropriate web surfing habits, or identify the source of web-based malware. If the web proxy is configured to cache web pages, it is even possible to retrieve the content that an end-user viewed or carve malware out of a cached web page for further analysis.

2.1.11 Application Servers

Every organization has a variety of application servers, which vary depending on the organization’s industry, mission, size, budget, and many other factors. Common types of application servers include:

• Database servers

• Web servers

• Email servers

• Chat servers

• VoIP/voicemail servers

Forensic Value

There are far too many kinds of application servers for us to review every one in depth (there have been dozens if not hundreds of books published on each type of application server). However, when you are leading an investigation, keep in mind that there are many possible sources of network-based evidence. Review local network diagrams and application documentation to identify the sources that will be most useful for your investigation.

2.1.12 Central Log Servers

Central log servers aggregate event logs from a wide variety of sources, such as authentication servers, web proxies, firewalls, and more. Individual servers are configured to send logs to the central log server, where they can be timestamped, correlated, and analyzed by automated tools and humans far more easily than if they resided on disparate systems.

The precise contents of a central logging server vary enormously depending on the organization and applicable regulations. Once a luxury that many enterprises did not bother to invest in, deployment of central logging servers has been spurred by regulations and industry standards. As a result, they are much more common today than they were just a few years ago.

Forensic Value

Much like intrusion detection systems, central log servers are designed to help security professionals identify and respond to network security incidents. Even if an individual server is compromised, logs originating from it may remain intact on the central log server. Furthermore, devices such as routers, which typically have very limited storage space, may retain logs for very short periods of time, but the same logs may be sent in real time to a central log server and preserved for months or years. Some organizations have installed commercial log analysis products that can provide forensic analysts with complex reports and graphical representations of log data, correlated across a variety of sources.

2.2 Principles of Internetworking

Communication on the Internet involves coordinating hundreds of millions of computers around the world. In order to connect these systems together, we must have standards for everything from physical cabling to application protocols. We must also ensure that our system includes modularity and abstraction so that a change in the agreed-upon voltages sent across a wire would not require that software engineers rewrite web applications. To accomplish this, various software and hardware manufacturers, public standards bodies, and individual hackers have developed protocols for communication. Since the late 1970s, network designers have developed “layered” standards, such as the Open Systems Interconnection (OSI) model, to coordinate the design of networking infrastructure.

2.2.1 Protocols

Protocols take on new meaning when viewed in the context of forensic investigation. Attackers bend and break protocols in order to smuggle covert data, sneak past firewalls, bypass authentication, and conduct widespread denial-of-service (DoS) attacks. While network designers and engineers view protocols as rules for facilitating communication between stations, forensic investigators must view them as guidelines that attackers can leverage to produce unexpected results.

Every computer that is designed to communicate with another computer over a data network must overcome the same problem as our Japanese and American diplomats. They must first be programmed to use some coordinated scheme for exchanging data, from “hello” to “goodbye”—protocols for communication. Furthermore, they must have a system for gracefully dealing with ambiguous messages and erroneous conditions because it’s simply not possible to specify a reaction for every conceivable action.

The Free On-line Dictionary of Computing defines “protocol” as:

A set of formal rules describing how to transmit data, especially across a network.

Some protocols are fairly simple. For example, imagine that I dial your number and your phone rings, signaling to you that I wish to communicate. You acknowledge my request and faciliate communication with me by taking the phone off the hook and saying “Hello, Jonathan!” I acknowledge your signal by saying something like “Hi, Sherri . . .” And so in three easy steps we’ve established a reliable bidirectional conversation.

The ubiquitous Transmission Control Protocol (TCP) similarly uses three distinct steps to establish a reliable bidirectional communication between stations. My computer might send your computer a segment with the TCP “SYN” (“synchronize”) flag set, signaling that I wish to communicate. Your computer acknowledges my request and faciliates communication with me by sending a TCP segment with the “SYN/ACK” (“synchronize”/“acknowledgment”) flags set in return. My computer acknowledges this signal by responding with a segment that has the TCP “ACK” (“acknowledgment”) flag set. In three steps, we’ve conducted a TCP handshake and established our reliable communications channel.

The Internet Engineering Task Force (IETF) and other standards bodies have published thousands upon thousands of protocol standards in minute detail, as we discuss extensively in Chapter 4. However, despite all of these specifications, we still manage to get things wrong and win black eyes on occasion.

2.2.2 Open Systems Interconnection Model

The Open Systems Interconnection (OSI) Model (Figure 2-1) was designed by the International Organization for Standardization (ISO) to provide network architects, software engineers, and equipment manufacturers with a modular and flexible framework for development of communications systems. When data is transmitted across a network, output from one layer is encapsulated with data designed for use by the lower layer processes. Conversely, when data is received by the destination host, input from each layer is demultiplexed for use by the higher layer processes.³

3. Hubert Zimmerman, “OSI Reference Model—The ISO Model of Architecture for Open Systems Interconnection,” IEEE Transactions on Communications, Vol. COM-28, No. 4, April 1980.

Figure 2-1 Layers in the OSI model. Every network analyst should be fluent in the OSI model labels. Make sure you have memorized the numbers and descriptions of each of the layers so that you can converse about them easily.

This is similar to the way that people put letters in envelopes and write the recipient’s address on the outside. With letters in the real world, sometimes encapsulation happens multiple times. Imagine that an employee puts a letter in a yellow envelope for interoffice mail, specifying the recipient by name and office. The mail room receives this envelope and puts it in a national postal service envelope with a street address of the recipient’s building. The government mail carrier delivers it to the appropriate building, where the destination mail room removes the outer envelope and delivers the yellow envelope to the recipient. Finally, the recipient opens the yellow envelope and removes the letter inside.

Similarly, computers “encapsulate,” or wrap, data from one layer with standard headers and/or footers so that the software at a lower layer can process it. This is how data is transmitted from one server to another across the Internet.

When data is received by the destination server, it is “demultiplexed,” or unwrapped. The receiving process examines the protocol metadata to determine which higher-layer process to hand it to, and then removes the current layer’s protocol metadata before sending it along.

Very complex challenges can often be solved more easily if they are broken down into parts. Using the OSI model, or similar frameworks, designers can partition the big complicated problem of communicating across the Internet into discrete subproblems and solve them each independently. The great benefit of the layered approach is that, even though there may be multiple competing protocols used for any one purpose, there exists a layer of abstraction and modularity that allows us to swap out a solution at one layer without affecting any of the solutions at the other layers.

There are other layered models in use for this type of network communication abstraction, such as the “TCP/IP Model,” which uses four layers instead of seven.⁴ Throughout this book, we use the OSI model (arguably the most popular) as our standard.

4. R. Braden, “Requirements for Internet Hosts—Communication Layers,” IETF, October 1989, http://www.rfc-editor.org/rfc/rfc1122.txt.

2.2.3 Example: Around the World . . . and Back

Let’s explore a simple web surfing scenario using the OSI model, as shown in Figure 2-2. Imagine that you are an American sitting in front of a Mac OS X laptop. You are sitting in an airport in Salt Lake City, and a small box has popped up indicating that you can get online via a T-Mobile wireless “hotspot.” You have no idea what that is, but it sounds nice, so you click “Yes!” Now your laptop is connected to the Internet.

Figure 2-2 An HTTP “GET” request, shown in the framework of the OSI model.

You launch Firefox, your web browser, and tell it that you’d like to ask the Chinese version of Google a question (www.google.cn). Somehow, a page pops up with Hanzi characters. You ask this Google (in Chinese) for “Chinese food in Bozeman, Montana” and get a new page back from somewhere in the universe that tells you there’s a place named Bamboo Garden Asian Grille, which will serve you when you get there. It even includes a phone number and a map.

2.2.3.1 Questions

You stop for a moment and wonder:

• How did your web browser know how to speak Mandarin to some web server somewhere?

• How did your web browser know where to find that faraway web server, in order to speak to it in the first place?

• How did your laptop manage to send it a signal in such a way that the wireless access point sent the request along to the destination?

• How was it that your laptop established itself on the Internet and could communicate with other systems?

• What was the route that your laptop used to talk to that remote web server, and how did it figure that out?

• How did the destination web server know what your request meant and how to format a reply so that your Mac would be able to interpret it (both with Hanzi and in English)?

All you did was point, click, and type a few characters, and within seconds a web server told you in Chinese about a restaurant in Montana. Pretty slick—and pretty complex. Was this all caused by voltage variations in copper cables? Was it perhaps also photons through fiber? Clearly there was some RF too, as your laptop never physically connected to anything at all!

Hard to believe this problem is solved a billion times a second.⁵

5. Not an official measure.

2.2.3.2 Analysis

Now, let’s analyze this web surfing scenario using the OSI model. As illustrated in Figure 2-2, we will step through one piece of this example in a simplified manner, using only a few layers but all the same concepts.

Your web browser, an application, operates at Layer 7 of the OSI model. When you type a URI into the address bar and hit Enter, it sends a DNS request to the local DNS server in order to map the search engine’s URI (http://www.google.cn) to an IP address. The local DNS server responds with the IP address mapped to the requested hostname.

Once the remote IP address is known, your local computer sends out an HTTP “GET” request (Layer 7), destined for the remote web server’s IP address. In order to get this request to the destination web server, your web browser hands the Layer 7 request to your operating system. The operating system chops this data up into discrete packets and prepends a TCP header (Layer 4), which includes the source port that web client is bound to, the destination port (TCP 80) that the server is expected to be listening on, and a variety of other information to support the Layer 4 connection.

Next, the operating system prepends an IP header (Layer 3), which describes the source and destination endpoint IP addresses so that the traffic can be properly routed from network to network across the Internet. Each packet is then framed with 802.11 information for transmission across the wireless LAN (Layer 2). Finally, the entire frame is turned into an RF (Layer 1), and sent out into the world.

The local wireless access point (WAP) receives the RF transmission and strips off the 802.11 header, replacing it with a new Layer 2 header. Next, the WAP transmits the entire frame to the next station over a copper wire (Layer 1). This station is a router that replaces the Layer 2 information and sends the frame over a copper wire (Layer 1) to its next hop. This process continues until the packet finally reaches its destination, the remote web server.

At the destination, the process works in reverse: The destination server is connected via a copper wire (Layer 1) and receives a series of voltage changes. The server’s network card interprets this as an Ethernet frame (Layer 2), removes the Layer 2 header, and sends it to the operating system. The operating system sees that the IP packet (Layer 3) contains its own IP address (“Yay, it’s for me!”). The operating system removes the IP packet header and notes the TCP header information (Layer 4), which of course includes a destination port, among other information. The operating system then looks to see what process is listening on the specified destination port. Finding a web server, it removes the TCP header and hands the payload to the destination web server (Layer 7).

In this manner, the OSI model can be used to describe the process of sending a web page request across the Internet, by examining the various layers of protocol interaction.

For the forensic analyst, it is very important to be fluent in the numbers and names of the different layers in the OSI model. The layered model both reflects and impacts the design of networking protocols, which we dissect throughout this book.

2.3 Internet Protocol Suite

The Internet Protocol Suite, also known as the TCP/IP protocol suite, is a collection of protocols that are used to implement important functions on the Internet and in many other packet-switched networks. For network forensic investigators, the protocols that make up the Internet Protocol Suite are as important as waves are to surfers or cooking pans are to Julia Child.

Your effectiveness as a network forensic investigator will depend in part on your familiarity with the Internet Protocol Suite, including key protocols and header fields. Nearly every network forensic technique in this book relies on your understanding of these protocols, from flow record analysis to packet analysis to web proxy dissection, and more. To get the most out of this book, we highly recommend that you become proficient at recognizing and recalling the important features and basic structures of key protocols in the Internet Protocol Suite.

In this section, we briefly review the history, specification, and features of IPv4, IPv6, TCP, and UDP. A full treatment of these protocols is beyond the scope of this book. For more details, we highly recommend TCP/IP Illustrated Volume 1, by W. Richard Stevens.

2.3.1 Early History and Development of the Internet Protocol Suite

Protocols do not simply fall from the sky, or emerge chiseled in stone—although it can seem that way when you’re tasked with analyzing or implementing them. Excellent network forensics investigators intuitively understand that protocols are not perfect: They change over time, implementations vary greatly, and hackers manage to bend and break them in weird and interesting ways. To help build your intuition, we now briefly review how the most important protocols used on the Internet came to exist.

The most famous protocols in the Internet Protocol Suite, the Transmission Control Protocol (TCP) and the Internet Protocol (IP), were initally developed during the 1970s by Vinton “Vint” Cerf, Jon Postel, and many others. The research was primarily funded by the United States Defense Advanced Research Projects Agency (DARPA). The first published versions of TCP, created by the “Stanford University TCP Project,” actually incorporated functions that have since been split between TCP and IP. We will henceforth refer to the original monolithic protocol as “[TCP/IP],” even though at the time it was actually called simply “TCP,” so as to distinguish it from the modern “TCP” protocol.⁶

6. Cerf, Vinton G., “FINAL REPORT OF THE STANFORD UNIVERSITY TCP PROJECT,” Internet Experiment Note #151, April 1, 1980, http://www.rfc-editor.org/ien/ien151.txt.

The purpose of the original protocol was to allow processes on different computers in different networks to easily communicate with each other. Vint Cerf later recalled that “[t]he initial concept behind [TCP/IP] was very simple. Two processes wishing to communicate had only to know the other’s ‘address.’”⁷

7. Ibid.

The original 1974 “Specification of Internet Transmission Control Program” stated:⁸

8. Cerf, Vinton; Dalal, Yogen; Sunshine, Carl. “RFC 675: SPECIFICATION OF INTERNET TRANSMISSION CONTROL PROGRAM,” IETF, December 1974, http://www.rfc-editor.org/rfc/rfc675.txt.

Processes are viewed as the active elements of all HOST computers in a network. Even terminals and files or other I/O media are viewed as communicating through the use of processes. Thus, all network communication is viewed as inter-process communication.

Since a process may need to distinguish among several communication streams between itself and another process [or processes], we imagine that each process may have a number of PORTs through which it communicates with the ports of other processes.

Since port names are selected independently by each operating system, [TCP/IP], or user, they may not be unique. To provide for unique names at each [TCP/IP], we concatenate a NETWORK identifier, and a [TCP/IP] identifier with a port name to create a SOCKET name which will be unique throughout all networks connected together.

Later, the Specification of Internet Transmission Control Program went on to compare the [TCP/IP] protocol to a post office:

The [TCP/IP] acts in many ways like a postal service since it provides a way for processes to exchange letters with each other . . . In addition to acting like a postal service, the [TCP/IP] insures end-to-end acknowledgment, error correction, duplicate detection, sequencing, and flow control.

By 1977, pressure mounted to split the original [TCP/IP] into two separate protocols. At that time, Jon Postel insightfully wrote:⁹

9. Postel, Jon, “Comments on Internet Protocol and TCP,” Internet Experiment Note #2, August 15, 1977, http://www.rfc-editor.org/ien/ien2.txt.

We are screwing up in our design of internet protocols by violating the principle of layering. Specifically we are trying to use TCP to do two things: serve as a host level end to end protocol, and to serve as an internet packaging and routing protocol. These two things should be provided in a layered and modular way. I suggest that a new distinct internetwork protocol is needed, and that TCP be used strictly as a host level end to end protocol.

Shortly thereafter, work emerged on the Draft Internetwork Protocol Specification,¹⁰ which was eventually published as RFC 791, “Internet Protocol” in September 1981.¹¹ TCP was revised to excise the network layer functions, and was also published in September 1981 as RFC 793, “Transmission Control Program.”¹²

10. Postel, Jonathan B., “Draft Internetwork Protocol Specification: Version 2,” Internet Experiment Note #28, February 1978, http://www.rfc-editor.org/ien/ien28.pdf.

11. J. Postel, “RFC 791—Internet Protocol,” Information Sciences Institute, University of Southern California, September 1981, http://www.rfc-editor.org/rfc/rfc791.txt.

12. J. Postel, “RFC 793—Transmission Control Protocol,” Information Sciences Institute, University of Southern California, September 1981, http://www.rfc-editor.org/rfc/rfc793.txt.

And thus, there was light and darkness, TCP and IP.

2.3.2 Internet Protocol

The Internet Protocol (IP) is designed to handle addressing and routing. It includes a method for uniquely identifying source and destination systems on a network (the “IP address”), and provides support for routing data through networks. To accomplish this, data is prepended with the IP header, as shown in Figures 2-3 and 2-4. The combination of the IP header and encapsulated payload together are referred to as an IP packet. There is no footer; the length of the IP packet is specified in its header. The packet is sent from the source through any intermediate routers to its destination, where the IP header is removed by the recipient operating system and the encapsulated payload is recovered.

The Internet Protocol (version 4) specification sums it up nicely as follows:¹³

13. J. Postel, “RFC 791—Internet Protocol,” Information Sciences Institute, University of Southern California, September 1981, http://www.rfc-editor.org/rfc/rfc791.txt.

The internet protocol is specifically limited in scope to provide the functions necessary to deliver a package of bits (an internet datagram) from a source to a destination over an interconnected system of networks. There are no mechanisms to augment end-to-end data reliability, flow control, sequencing, or other services commonly found in host-to-host protocols. The internet protocol can capitalize on the services of its supporting networks to provide various types and qualities of service.

IP operates at Layer 3 of the OSI model (the network layer). It is a connectionless protocol, meaning that it does not explicitly identify individual packets as being part of a related series, and therefore also does not have a method for indicating the intiation or closing of a conversation.

The IP is also not designed to ensure reliability of transmission (the designers envisioned that this function would be handled by TCP or another higher-layer protocol). The Internet Control Message Protocol (ICMP), which was released in 1981 at the same time as Internet Protocol version 4 (IPv4), is often used in conjunction with IP to “provide feedback about problems in the communication environment.”¹⁵ For more information about ICMP, see Section 11.3.4, “ICMP Tunneling.”

15. J. Postel, “RFC 792—Internet Control Message Protocol,” IETF, September 1981, http://www.rfc-editor.org/rfc/rfc792.txt.

There have been several versions of IP. The most widely deployed version is IPv4, which was officially standardized in 1981 and first deployed on January 1, 1983. During the past thirty years, IPv4 has become globally supported. However, work has continued on IP development, fueled primarily by concerns about address space exhaustion. In 1998, the specification for Internet Protocol version 6 (IPv6) was released, and support for it is increasing, slowly but surely.¹⁶

16. Deering, S.; Hinden, R. “Internet Protocol, Version 6 (IPv6) Specification,” IETF, December 1998, http://www.rfc-editor.org/rfc/rfc2460.txt.

Characteristics of IP include:

• Support for addressing and routing

• Connectionless

• Unreliable

• Includes a header (no footer)

• Header plus payload is called an IP packet

In the following sections, we briefly summarize the features of IPv4 and IPv6, and discuss key differences between them.

2.3.2.1 IPv4

IPv4 uses a 32-bit address space to identify the source and destination systems. Typically, human-readable IP addresses are divided into four octets, separated by periods, and written in decimal. Each octect has 2⁸ possible values, ranging from 0 to 255. For example, here is a 32-bit IP address written in binary and human-readable form:

Binary:

00001010.00000001.00110010.10010110

Human-readable:

10.1.50.150

There are 2³², or 4,294,967,296 (approximately 4.3 billion) possible IPv4 addresses. Theoretically, the smallest possible IP address is 0.0.0.0 and the largest is 255.255.255.255. However, many IPv4 addresses are reserved for specific purposes. For example, three ranges of addresses were reserved for private networks by RFC 1918 Address Allocation for Private Internets, and are not routed across the Internet.¹⁷ These ranges are:

17. Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, E. Lear, “RFC 1918: Address Allocation for Private Internets,” IETF, February 1996, http://www.rfc-editor.org/rfc/rfc1918.txt.

10.0.0.0        -   10.255.255.255  (10/8 prefix)
172.16.0.0      -   172.31.255.255  (172.16/12 prefix)
192.168.0.0     -   192.168.255.255 (192.168/16 prefix)

Each IPv4 packet header includes a checksum. Routers along the packet’s path recalculate the checksum based on the data in the header and, if it is not correct, they discard the packet. IPv4 does not include any built-in support for encryption.

The full structure of the IPv4 packet header is shown in Figure 2-3.

Figure 2-3 The IPv4 packet header.

2.3.2.2 IPv6

Although 4.3 billion possible IP addresses may seem like a lot, it’s not enough for the long-term needs of the global Internet. In February 2011, the last five IPv4 address ranges were allocated by the Internet Assigned Numbers Authority (IANA) to each of the five Regional Internet Registries (RIRs) around the world.¹⁸

18. Lawson, Stephen. “IPv6 Doomsday Won’t Hit in 2012, Experts Say.” PCWorld, December 29, 2011, http://www.pcworld.com/businesscenter/article/247091/ipv6_doomsday_wont_hit_in_2012_experts_say.html (accessed December 31, 2011).

The address space exhaustion occurred in part because of the explosion of mobile devices and the sheer numbers of people connected to the Internet. It is also partly due to inefficient address allocation; for example, in the infancy of the Internet, MIT was allocated an entire “Class A” range (18.*.*.*), with over 16 million possible IP addresses, even though the university uses a fraction of that number.

In response to the IPv4 address space exhaustion, the IPv6 protocol was developed with 128 bits for each of the source and destination addresses. There are approximately 2¹²⁸, or 340 undecillion possible IP addresses. Human-readable IPv6 addresses are written in hexadecimal and are divided into 8 groups of 16 bits each.

Here is an example of a human-readable IPv6 address:

2001:0db8:0000:0000:0001:0000:0000:0001

Here is a shorthand way of writing the same IPv6 address:

2001:db8::1:0:0:1

Developers of IPv6 also disposed of packet header checksums, as you can see in Figure 2-4. Instead, error detection is left entirely to higher-layer protocols. This helps to improve throughput, since routers no longer have to calculate the packet header checksum at each hop while the packet is in transit. In addition, IPv6 headers are of fixed length, rather than variable length as in IPv4. This eliminates the need for routers to parse the IP header length in order to find and evaluate fields in the embedded protocol (i.e., for packet filtering).

Figure 2-4 The IPv6 packet header.

Perhaps most importantly for security purposes, IPv6 is designed to interoperate with IPSEC, providing network-layer confidentiality and integrity.

The key changes introduced in IPv6 compared with IPv4 can be summarized as follows:

• Larger address space (128 bits)

• No packet header checksums

• Fixed-length IP packet header

• Designed to interoperate with IPSEC

2.3.3 Transmission Control Protocol

The Transmission Control Protocol (TCP) is designed to handle multiplexing of process communications on the host, as well as reliability and sequencing. Data is prepended with a TCP header, as shown in Figure 2-5. The combination of the TCP header and the encapsulated payload together is referred to as a TCP segment. As with IP, there is no footer. To communicate, a process encapsulates data in a TCP segment header for transmission to another process, possibly on a remote system (in which case the segment would subsequently be encapsulated in an IP packet for transmission across the network and demultiplexed at the receiving end).

Figure 2-5 TCP

The TCP header includes 16-byte fields for “source port” and “destination port.” Recall that according to the original “Specification of Internet Transmission Control Program,” a process “may have a number of PORTs through which it communicates with the ports of other processes.”²⁰ The possible values for TCP ports range from 0 to 65,535.

20. Cerf, Vinton; Dalal, Yogen; Sunshine, Carl. “RFC 675: SPECIFICATION OF INTERNET TRANSMISSION CONTROL PROGRAM,” IETF, December 1974, http://www.rfc-editor.org/rfc/rfc675.txt.

TCP is a connection-oriented protocol. It indicates the state of transmissions using flags in the TCP header. As described earlier in Section 2.2.1, TCP uses three steps to establish a reliable bidirectional communication between stations. First, the initiating station sends a segment with the SYN flag set. Next, the responder sends back a segment with the “SYN” and “ACK” flags set. Finally, the initiator responds with a segment that has an “ACK” flag set. This initiation sequence is referred to as the three-way handshake. There is also a corresponding two-step sequence for closing a connection using the “FIN” and “ACK” flags.

Key characteristics of the TCP protocol include:

• Reliable

• Connection-oriented

• Handles sequencing

• Port numbers range from 0 to 65535

• Includes a header (no footer)

• Header plus payload is called a TCP segment

2.3.4 User Datagram Protocol

The User Datagram Protocol (UDP) is an extremely simple protocol. As you can see in Figure 2-6, it doesn’t do much—it is merely designed to facilitate muliplexing of process communications on the host, without any of the reliability, sequencing, connection setup and teardown, or any of the frills of TCP. This is very useful for some applications, such as real-time data streaming (Voice over IP, music, or videos). For these applications, there is no point in attempting to detect if packets arrive out of order or are dropped because the real-time requirements leave no room for retransmission. It is better to simply drop datagrams when errors occur than to slow down the entire transmission with transport-layer error checking.

Figure 2-6 UDP

Like TCP, the UDP header includes 16-byte fields for “source port” and “destination port.” The possible values for UDP ports range from 0 to 65,535.

Key characteristics of the UDP protocol include:

• Unreliable

• Connectionless

• Port numbers range from 0 to 65535

• Includes a header (no footer)

• Header plus payload is called a UDP datagram

2.4 Conclusion

Network investigators must always be ready to learn and adapt. From wires to routers to web proxies to DNS servers, there are innumerable potential sources of network-based evidence. Although most environments are built from the same general types of network devices, there exists a wide variety of equipment, software, and protocols that are constantly changing.

In this chapter, we reviewed common classes of network devices and discussed the types of evidence typically found on each, and the value for forensic investigators. We followed up by discussing the concept of protocols and the OSI model, which form the framework for our studies throughout the remainder of this book. Finally, we discussed the Internet Protocol Suite and highlighted key features of IPv4, IPv6, TCP, and UDP.

With this framework in mind, remember that every environment is different and every investigation is different. Your mileage will vary based on the specific devices and communications protocols involved in each investigation. Always be prepared to encounter something new.