Summary

Let's summarize some of the ideas conveyed in this chapter. First, although your NIDS is a necessary tool for risk mitigation, it is not a panacea for detecting all malicious traffic. One reason for this is that insertion and evasion attacks can cause the NIDS to incorrectly scrutinize network traffic. There are many different attacks that can be used and it is simply impossible for a NIDS to know how every different target host on a network will react to a packet. A NIDS cannot know the nuances of each individual host's implementation of the TCP/IP stack. As well, the NIDS is not aware of network topology differences that can be used in some of the attacks such as packets with low TTL numbers that will never reach the target host. The use of hostbased IDS can be used to fortify the security provided by the NIDS.

A savvy analyst should be aware of the types of fields and possible values that are found in the IP header. This is valuable knowledge when examining packets for anomalous values. Recognizing mutant values might not explain the intended purpose of the packet, but it should draw your attention to the packet. From there, it might be possible to determine the nature of the traffic.

Chapter 9. Examining Embedded Protocol Header Fields

This second chapter on examining header fields discusses the fields in the headers found after the IP header, namely the TCP, UDP, and ICMP headers. As we discovered in the previous chapter, it is imperative that anyone performing traffic analysis be familiar with the purpose of the fields and expected values. This is the only way to unearth values that are not normal and might be a reflection of some kind of malicious activity.

Because this is a fairly extensive topic, the chapter addresses fields in each of the protocols individually. Hopefully, this will partition the protocols into more manageable chunks of learning.

TCP

Back in Chapter 2, "Introduction to TCPdump and TCP," we discussed that TCP is a reliable protocol. This means that TCP oversees the exchange of data and knows when there is a possible problem by using fields such as sequence and acknowledgement numbers to order and keep track of the exchanged data. There are many more fields in the TCP header than UDP and ICMP have because TCP needs to maintain state and provide optimal flow control between sender and receiver. We'll examine these fields and others in the context of normal and

abnormal use.

Ports

The port fields are two separate 16-bit fields in the TCP header, one for source (bytes 0 and 1 offset from the TCP header) and another for destination (bytes 2 and 3 offset from the TCP header) port. The valid range of values is between 1 and 65535. The use of port 0 is anomalous

and considered to be a unique "signature" of an improper port setting.

When a source host wishes to connect to a destination host, an ephemeral source port is typically selected in the range of ports greater than 1023. For each new connection that the host attempts that is not a retry, a different ephemeral port should be selected. The concept of TCP retries or retransmission will be covered later in this chapter in the section, "Retransmissions." In a scan scenario, you will likely see the source port value incrementing by 1 for each new connection.

One of the telltale signs of an nmap SYN scan to find open TCP ports is a static source port

retained over multiple new TCP connections. For example: nmap –sS sparky

09:40:43.964215 verbo.47247 > sparky.1548: S 2401927088:2401927088(0) win 2048

09:40:43.964412 verbo.47247 > sparky.24: S 2401927088:2401927088(0) win 2048 09:40:43.964465 verbo.47247 > sparky.1547: S 2401927088:2401927088(0) win 2048

09:40:43.964553 verbo.47247 > sparky.2564: S 2401927088:2401927088(0) win 2048

09:40:43.964604 verbo.47247 > sparky.1484: S 2401927088:2401927088(0) win 2048

09:40:43.964642 verbo.47247 > sparky.1460: S 2401927088:2401927088(0) win 2048

09:40:43.964695 verbo.47247 > sparky.628: S 2401927088:2401927088(0) win 2048 09:40:43.964748 verbo.47247 > sparky.1112: S 2401927088:2401927088(0) win 2048

Although we would expect the source port of scanner verbo to change for each new SYN connection to new ports of target host sparky, the source port number remains constant as 47247.

In contrast, look at the default behavior exhibited by another scanning tool known as hping2. The –S option of hping2 performs a different kind of SYN scan. It increments the source port as expected, yet it attempts to open destination port 0 of its target. The intent of this type of scan obviously is not to find a listening port. This type of scan is used to elicit a RESET response to see if a host is alive, because there should be no hosts listening at port 0. Here's the output

from hping2: hping2 –S sparky

09:44:13.882207 verbo.1788 > sparky.0: S 1553132317:1553132317(0) win 512 09:44:14.876837 verbo.1789 > sparky.0: S 1894028093:1894028093(0) win 512 09:44:15.876836 verbo.1790 > sparky.0: S 2032501562:2032501562(0) win 512 09:44:16.876832 verbo.1791 > sparky.0: S 851202745:851202745(0) win 512

TCP Checksums

As mentioned previously, the embedded protocols have checksums as well. These cover the embedded header and respective data for TCP, UDP, and ICMP. Unlike the IP checksum, these are end-to-end checksums calculated by the source and validated by the destination host-only. The TCP checksum has been chosen to represent the embedded protocol checksums. UDP does not require a checksum to be computed, unlike IP, TCP, and ICMP. However, it is highly recommended.

The embedded protocol checksums for TCP and UDP are computed using a pseudo-header in addition to the embedded protocol header and data. A pseudo-header consists of 12 bytes of data depicted in Figure 9.1: the source and destination IPs, the 8-bit protocol found in the IP header, and a repetition of the embedded protocol length (this is the protocol header length plus the number of data bytes). The zero-pad field found in the 8th byte offset is used to pad the 8-bit protocol field to 16 bits because checksums are performed on 16-bit blocks of data.

Figure 9.1. TCP checksum pseudo-header fields.

Why is the pseudo-header necessary? This is a double check that is used by the receiving host to validate that the IP layer has not accidentally accepted a datagram destined for another host or that IP has not accidentally tried to give TCP a datagram that is for another protocol. If there is some errant corruption that occurs in transit, the validation of the IP checksum may or may not discover this, but some fields from the IP header are included in the pseudo-header checksum computation to help protect against this.

Let's examine a very specific example of how the pseudo-header protects against delivering the packet to the wrong host. Figure 9.2 is offered to assist in visualizing the process. Assume that we have a host that sends a packet to destination IP 1.2.3.4. We will use TCP as the embedded protocol, but it really doesn't matter if the transport layer is TCP or UDP because both use the pseudo-header. The transport layer checksum includes the pseudo-header fields in the checksum computation. Therefore, for the destination IP, a value of 1.2.3.4 is used in the TCP checksum computation.

Figure 9.2. Pseudo-header checksum protection.

On its way from the sending host, the packet travels through a router that, as you remember,

must validate the IP checksum before forwarding it. Suppose the router validates the IP checksum, decrements the TTL, and then needs to recompute the new IP checksum. For some unforeseen reason, the IP layer of the router somehow corrupts the destination IP to be 1.2.3.5. The IP checksum is recomputed using the corrupted destination IP. The IP checksum is valid so the packet continues on towards the wrong destination, IP 1.2.3.5.

Assume that the IP 1.2.3.5 exists. The corrupted packet arrives at the wrong destination IP. The IP layer validates the checksum and it is correct because destination IP 1.2.3.5 was used in the IP checksum computation by the corrupting router. The packet is pushed up to the transport layer where TCP uses the pseudo-header fields in the checksum validation. But, the TCP checksum validation uses destination IP 1.2.3.5 in the corrupted packet IP header for validation comparison against the packet's actual TCP checksum. However, this does not match the TCP pseudo-header checksum from the sending host that used 1.2.3.4 as the destination IP in the pseudo-header checksum. Host 1.2.3.5 then discards the packet because the embedded protocol checksum does not match the computed checksum done by the destination host.

A Cry for Help

While reading literature on the purpose of the pseudo-header, it made perfect sense to me that it is used as an additional check to make sure that the packet isn't sent to the wrong host or protocol. Yet, for the life of me, I couldn't envision how this was done. I asked several colleagues, but they too shared my confusion when it came to giving an example. I ended up writing noted author and TCP/IP expert, Doug Comer, who shared the example of a router corrupting the destination IP number. I would like to extend many thanks to Mr. Comer for clearing up the confusion.

TCP Sequence Numbers

The TCP sequence numbers are used to uniquely identify the beginning byte of each TCP segment that is sent. This is a way to keep track of all the TCP data that is sent and received in a TCP stream. Most times, there is more TCP data than can be sent in one TCP segment. Or, some services such as rlogin might send a character at a time over a TCP stream requiring multiple streams per session. Because TCP is a reliable protocol, we must have a mechanism to account for data being sent and received. In part, that is done using TCP sequence numbers. These sequence numbers should not be repeated unless there is a retry of the same connection if an initial attempt fails and the sender receives no error from either the intended receiver or some kind of packet-filtering device. The initial sequence number (ISN) is the first sequence number that is used in the TCP exchange between the sending and receiving hosts. Each host in the exchange selects a unique initial sequence number when sending the initial SYN connection to the other host.

The formula that TCP/IP stacks use to select their initial sequence number is examined by nmap to help fingerprint the operating system. There is a file that comes with nmap, nmap-os- fingerprints, that has a list of many different operating systems and versions. Nmap performs a given set of tests against a target host. Nmap can categorize a particular operating system by matching the values in responses to different normal and abnormal stimuli sent by the scanning host with the expected values for a given operating system.

The first test executed by an operating system fingerprinting nmap scan is one that examines the initial sequence numbers generated by a receiving host from sent connections to a listening port. Different TCP/IP stacks use different formulas to generate the ISN. Some of the older operating systems used a predictable increment for the ISN for each new connection. But someone watching and sniffing could possibly predict and hijack a connection using this information, as was done in the infamous Mitnick attack. Other operating systems have a timedependent formula that predictably increases the ISN based on a given time change. This, too, is not considered very secure. The most secure formula for ISN generation is a random, unpredictable one. As a tidbit of information, the SYN that we refer to as the flag to start a TCP connection is actually an abbreviation for synchronize sequence numbers. The following execution of nmap using the operating system fingerprint scan option (-O) shows open ports,