Basic TCP/IP Principles

• Describe, recognize, or select basic weaknesses in TCP/IP networking.

TCP/IP has seen few changes over the years from its earliest inception, when security wasn't much of a concern. As the use of TCP/IP grew, in 1985 Bob Morris started to realize inherent problems with how TCP/IP connection handshakes between servers and client systems were generated that could allow a hacker to force a connection, despite whether or not they were allowed to. Findings such as these caused changes to the basic TCP/IP design over the years, but as mentioned, the fundamental TCP/IP design, and thus security model, has not changed very much for quite a while.

In addition to the basic TCP/IP security model, you will encounter a variety of security models that may or may not actually refer to a protocol or other network component. For example, in the security model for your office building, you may possibly have key cards, no access after a certain hour, or other similar guidelines and rules that make up the security model for your office. This variance in descriptions is mainly because of a discrepancy in terminology, although technically neither is incorrect. A security model is simply a different way to discuss how security is implemented or designed around a protocol (or other network component). It can also be defined as a security concept that is applied to a network security plan or piece of software.

The level of security you receive on your TCP/IP-enabled network is entirely dependent on the capability and design of your operating systems or software used on the network. In fact, the way that the implementation of TCP/IP (and other network resources) handles security is entirely dependent on the way TCP/IP is designed. TCP/IP security includes how that particular implementation of TCP/IP performs connection handshaking, monitoring of established connections, and handling of errors between systems on a network, among other aspects, such as additional security features or models that are applied alongside or on top of the core TCP/IP protocol. Variances in the security abilities (or entire lack of security) of third-party applications that use TCP/IP can cause you considerable grief. In many cases, the people working with this software package lack the expertise of a major vendor, such as Microsoft, Cisco, or similar companies, in programming TCP/IP security features; however, these companies fall victim themselves more often than not. Pay close attention to these types of specialized or obscure software packages for TCP/IP-related security issues.

TCP Handshakes and Headers

The TCP handshake process and TCP headers are some of the most important issues to keep in mind because they can be some of the most common targets of hackers. There are three main phases to the connection process that are handled by the TCP header:

• SYN. Synchronizes the sequence numbers (the numbers used to identify the packets).

• FIN. Signifies that there is no additional data being sent from the sender.

• ACK. Identifies the acknowledgment information contained within the packet.

Establishing a TCP connection is a basic three-way handshake that can be considered very similar to the way many people interact. The overall process happens very quickly even though the following steps may seem to contain a lot of information being exchanged.

The process is rather simple, but sometimes can be hard to imagine based on the previous steps, which are outlined in Figure 2.1.

Figure 2.1. The TCP handshake process.

[View full size image]

After the two systems complete their communication, they need to indicate to each other that the connection is ending. They end the communication cleanly in four steps, as follows (see Figure 2.2):

Figure 2.2. The TCP disconnection process.

[View full size image]

Sometimes, failing to start or end a TCP connection cleanly can result in hackers taking advantage of this in the form of a DoS attack. If the system isn't aware that the communication has ended, it keeps that particular resource open. This becomes a problem because there are not infinite network resources available. Available network resources are often dictated by network performance and the actual capabilities of the server itself in regard to memory. After the available resources are depleted, the server either stops accepting new connections or crashes. To take advantage of this problem, a hacker simply executes hundreds of thousands of connections and forces them to fail. This, in turn, takes up available resources and brings the server to a slow crawl or worse yet, crashes it completely. With many current TCP/IP stacks, you will see this type of problem less frequently; however, these types of attacks are still more than possible and should be kept in mind.

SYN Flood Attacks

Now that you have taken a closer look at how TCP connections are established and completed, you are better prepared to understand the most common attack against TCP, a SYN flood attack. In a SYN flood attack, the connection is established by issuing a SYN request (as it would normally), except this SYN request is not complete (bad data or the request is left without completing). The hacker then continues to send these same modified SYN requests until the server cannot respond to actual requests by valid client systems, effectively taking it offline. (A system could be taken offline by this type of attack because without any resources available to receive new connections, the system is more or less unavailable for regular use.)

You may have heard of a man-in-the-middle attack, or, as it's sometimes known, hijacking. So, how is this type of attack actually done? As mentioned earlier in this chapter, a vulnerability found in the mid-1980s showed a flaw in how TCP generated the ISN. It was found that determining this number was terribly easy, which led to hackers being able to predict what the sequence number of each following TCP packet would be (remember, each packet has its own number in sequence); by doing so, they could hijack a connection by jumping into the connection with the proper sequence of packets. This is much harder to do today, but it is still more than possible.

Structure of an IP Datagram

Every IP address used on the Internet is 32 bits long (this is not the case when using Ipv6, which is 64 bits) and is used to uniquely identify a system on a TCP/IP network, such as the Internet or a local area network in your office. This address information is typically contained within the IP header, which holds different pieces of TCP/IP-related information, and is 20 bytes in size. Among the information contained within an IP header is the IP version number, length of the packet, type of IP service, and other configuration information. In addition to this other configuration information, the destination address (which is also 32-bit, assuming Ipv6 hasn't been implemented) is included with the source address in the datagram. This information is tacked on to a piece of data and called an IP datagram (or more commonly called a packet). These are the data items that are actually transferred among systems. Larger files have many thousands of packets because they need to be broken up into smaller chunks for transmission. Each one of these smaller chunks has the header information in the datagram so that they will be delivered properly. The basic structure of an IP datagram is shown in Figure 2.3.

Figure 2.3. Structure of an IP datagram.

[View full size image]

When the data is received by the recipient system (sometimes out of order), it is rebuilt, using all the received datagrams, into a proper set of data. It is this segmentation and potential jumble of datagrams that allows hackers to potentially take advantage of the TCP/IP protocol by slipping in data or modifying the header information. Unfortunately, this situation is an inherent problem with the TCP/IP design that cannot be changed without a major revision on the specification (which is in the works). Using an add-on software package or additional configuration, such as Secure Internet Protocol (IPSec) or authentication and data encryption, can curb many of the issues associated with this design flaw.

Network Reference Models and TCP/IP

There are many different types of network models that you will encounter, including both TCP/IP and general network security models, the latter leaning toward an actual security implementation on your network. In the following sections, take a look at the two network models that comprise much of the inner workings of networking as we know it today: the OSI model and the TCP/IP (DARPA) model. It is important to understand the two major models that form the basis for most internal networks and the fundamental networking design of the Internet (and as such, the main delivery of attacks by hackers). Later, you take a look at the issues you may run into with different protocols and services, including possible considerations when trying to secure them.

The OSI Network Reference Model

Years ago, the International Standards Organization (ISO) created a networking model that consists of seven individual layers, called the Open Systems Interconnection (OSI) reference model. Each layer of the model (top to bottom) represents a different element of a network communication protocol, as follows:

• Application

• Presentation

• Session

• Transport

• Network

• Data Link

• Physical

In the next sections, some of the major elements are covered in more detail starting from the bottom (Physical layer), including possible security issues or attacks that can be levied against each one.

Physical Layer

• Identify the basic security issues associated with system/network design and configuration.

This layer comprises the actual physical connection medium, such as the network cable or network card. Little can be done to actually secure a physical medium, outside of locking away sensitive network equipment, such as hubs, switches, and servers, and allowing access only to authorized people. Effectively, if a hacker has direct access to your physical network, there isn't much they can't do unless you make use of encryption to protect any data captured using a network sniffer or data copied down from systems and servers.

One glaringly simple security concept that I have seen in my travels is the consideration of disabling unused network access ports in unused offices or in odd places, such as waiting rooms or in the middle of hallways (these aren't as rare as you might think with the amount of office shuffling that occurs in this day and age). For most organizations, typical practice is to simply wire up to the network any jacks in case a user needs one (for instance, a new employee starts and occupies an office that was otherwise vacant). By disconnecting these types of unused connections from your physical network, you minimize a potential avenue for a hacker to squirrel away in an unoccupied office and hack away on your network with an otherwise unused, but still connected, network jack.

Network Layer

The Network layer is often referred to as the IP layer (see Figure 2.4) and is the layer used mainly for addressing host systems and routing traffic. This layer does not provide any kind of error correction or flow control; rather, it relies on other layers to provide delivery of data from one system to another. Other protocols, such as TCP, User Datagram Protocol (UDP), ICMP, and Internet Gateway Message Protocol (IGMP), are used to provide the delivery of IP traffic, although TCP and UDP are the most common methods of delivery you will encounter. The other two protocols—ICMP and IGMP—are relegated to the IP layer only. Protocols that operate on the Network layer of the OSI are used only to assist in communication between two hosts, rather than the actual delivery of data. Few potential attacks against the Network layer of the OSI model exist because most current operating systems are patched to protect against them.

The IP (Network) layer uses ICMP to transfer information about communication errors and other information relating to the layer. A good example of ICMP in action is when you perform a simple ping on another system—the information you get back is an ICMP-generated message. Although there is little that can be levied against ICMP, it can be used to attack a remote network or host.

Among some of the more high-profile attacks that use ICMP are the Tribal Flood Network (TFN) programs and Winnuke. The TFN series of programs varied in name, but all carried the same basic attack plan. This attack plan was to use ICMP traffic to consume all the available bandwidth a site had and, more or less, take the Web site, or any type of server, offline because it would be unable to respond to any requests made by client systems. This attack was, in effect, one of the earliest types of Denial-of-Service attacks in which available resources are consumed to stop or limit the capabilities of a system or server.

The other high-profile attack, Winnuke, plagued many people for some time, especially users of the older Windows 95 operating systems (newer operating systems are protected against this particular attack). Winnuke was designed by a hacker to send very specialized ICMP data in the form of a plain and harmless-looking ping request. Any system with an older version of the Microsoft TCP/IP stack, mainly Windows 95, could not properly handle this fake request and caused the network connection to fail and, often, the entire system to crash (hence the nuke part of the name). Another similar attack is called the Ping of Death, which is when a modified packet is sent that is larger than TCP/IP can handle and it causes the system to consume resources, quite possibly crashing the system. Because of attacks such as Winnuke, TFN, or Ping of Death, many networks and Web sites, including http://www.microsoft.com and other popular Web portals, do not respond to ICMP traffic any longer.

Transport Layer

The Transport layer is used to control the flow of data between systems. There are two protocols that reside on this layer, TCP and UDP. Each protocol is different in how it provides services and as such requires a slightly different approach when dealing with security.

The main protocol that you will undoubtedly be dealing with is TCP; this protocol is termed as being connection oriented. This means that for two systems to communicate with each other, they must go through a handshaking procedure and information exchange for the communication to progress. By performing this handshaking process, as you read earlier in the TCP handshake process section of this chapter, you gain the ability to have validated delivery of your information, as much as it is possible to validate with the potential for attack. This is a bit different when compared to other protocols, such as UDP, that do not require a negotiated connection prior to sending data, which is somewhat like firing a gun in the dark—you don't really know where the bullet may go.

The real benefit to the negotiated connection is that, as you learned earlier, when data is sent in segments, it can get scrambled and sometimes lost en route to its final destination. If this happens, a TCP connection retries sending the data to complete the data delivery. TCP is used by nearly every major service, such as Web surfing, file transfers, and email.

Application Layer

The final and often most difficult network layer to protect is the Application layer. The problem with securing the Application layer is that TCP/IP-enabled applications are able to perform in any fash ion they want and typically different applications are programmed differently, greatly increasing the potential problems in securing this layer. The Application layer can best be described as where the actual software interacts with the network. Applications that use this layer include Web browsers, File Transfer Protocol (FTP) clients, games, and similar software.

As mentioned, securing the Application layer is difficult because a wide variety of configurations, as well as ports and protocols, are being used. For instance, a single application could make use of any number and combination of TCP or UDP plus the 65,536 ports for each protocol, leaving you any number of the possible 131,000 ports to which you could restrict access. As you can imagine, this process would be very counterproductive if it were attempted on an application-by-application process. Instead, it is far more logical and practical to simply allow only a few select applications to send data through your network (using a firewall or similar technology) rather than to stop each application one by one.

The TCP/IP DARPA Network Model

The TCP/IP DARPA network model is fundamentally the same as the OSI network reference model, except that it has fewer layers (only four) and some of the OSI model layers are combined into one TCP/IP DARPA model layer. The four main layers of the TCP/IP network model, starting at the topmost layer, are as follows:

• Applications

• TCP & UDP (often referred to as the IP stack)

• IP & ICMP

• Data Link & Physical

As you can see, there isn't much in the way of core differences between the way OSI and TCP/IP models work. They contain the same information, but the TCP/IP model is much simpler and groups layers together in a more logical method.

Some people, including experts, sometimes interpret the associations in different ways. Many opinions differ on exactly where the TCP and UDP layer matches with the OSI model. Sometimes, it's considered to correlate to the Session layer; sometimes it's considered to match up with the Transport layer. Neither answer is wrong; it's an entirely personal consideration. Figure 2.5 shows the relationship between OSI and TCP/IP models.

One of the benefits of seeing how the TCP/IP model (often called the TCP/IP stack for its layers) compares with the OSI model is that if someone references the TCP layer of the TCP/IP stack, you can relate that to one of the layers of the OSI model to gauge where it resides in the scheme of things. Because no real functional difference exists between the number and names of the layers and how they are grouped, there is no need to go into more depth on the TCP/IP model. Suffice it to say that it's important to understand both models.