In many ways, IP is the network. IP is a connectionless protocol that provides for the delivery of data to logically addressed hosts anywhere on the network. It is important to understand that IP is an unreliable delivery mechanism by design, leaving the responsibility of reliable delivery to higher- or lower-layer protocols such as TCP or IEEE 802.2 and 802.3. As far as IP is concerned, the data that is transmitted may be delivered, lost, sent out of order, duplicated, delayed, or otherwise mangled; it could not care less what the ultimate result is. When we say that IP is connectionless, we mean that each packet that is transmitted is done so independent of every other packet. Consequently, packets that are transmitted may take different paths through the network and be lost or delayed, whereas other packets are successfully transmitted. Although this concept of best-effort delivery may sound terribly unreliable, keep in mind that other protocols are designed that handle reliability, thus precluding the need for IP to handle such things. In addition, data is generally delivered successfully and true unreliability of data delivery is typically the result of an underlying network or communications failure of which IP would not be able to fix anyway (remember, each layer operates independent of each other, and a failure at the physical layer can only be fixed at the physical layer, not the network layer). Note IP is defined by the following RFCs:
IP Packet StructureAn IP packet (sometimes referred to as a datagram) has a distinct and defined structure. In simple form, an IP packet is the IP packet data (which is nothing more than the segment that was passed down from the session layer) and the IP packet header, as shown in Figure 3-5. Figure 3-5. Simple IP Packet Structure
The IP packet header is typically 20 bytes in length (unless IP options are used, in which case the length may be variable up to a maximum length of 60 bytes) and contains the information that allows systems to determine how to process the corresponding IP packet data. The IP packet data is a variable length, ranging from 1 to 65515 bytes in length in most cases. Obviously, if the header is larger than 20 bytes, the IP packet data maximum size will be reduced in size accordingly. This provides for a minimum IP packet size of 21 bytes (20-byte header, 1-byte data) and a maximum IP packet size of 65535 bytes (20-byte header, 65515-byte data). The IP Packet HeaderThe IP packet header is what tells an IP-based host what to do with the packet that was received. Think of it as an instruction manual that contains the "how to process this packet" information. Therefore, an attacker wanting to generate malicious traffic will frequently modify the IP packet header in such a way as to instruct the receiving host to do something harmful with the packet, or to instruct the host to do something it is not capable of doing in hopes that it causes the host to generate an error condition that may allow the attacker to gain access to the system. Because of this, it is not good enough to understand that there is an IP header. As a firewall administrator, we need to understand what the contents of the IP header are and what the values represent so that we can identify and block potentially malicious traffic. The IP packet header consists of 32-bit blocks of data known as words. These words are further broken down into numerous fields of various length and function. As mentioned previously, the typical IP packet header length is 20 bytes, which means that a typical IP packet header consists of 5 words. If any IP options have been configured, the packet header will contain the options values, and then the necessary padding to ensure that the header ends on a 32-bit boundary. Figure 3-6 depicts the structure of an IP packet header. Figure 3-6. IP Packet Header StructureThe fields of the IP packet header and their meanings are as follows:
Figure 3-7 shows a screen shot of a packet sniffer to show the IP packet header contents in a decoded fashion. Figure 3-7. Sample IP Packet Header ContentsBad IP PacketsIn most cases, the IP packets that are received on a network can be successfully processed and acted upon accordingly. As is true with all network communications, however, it is possible for an IP packet to either be accidentally or intentionally designed in such a way as to be a bad packet. When we say "bad packet," we mean a packet that for whatever reason cannot be processed properly. In some cases, this may be the result of unreliable delivery of the data (for example, if a portion of the datagram is lost [remember, IP is an unreliable delivery mechanism, so a datagram could be fragmented and a fragment lost or something similar]). In other cases, the packet may be intentionally crafted in such a way as to be an invalid or bad packet. This is normally done with the hope that when the destination receives the bad packet, it cannot properly deal with the packet, potentially leaving the host vulnerable to another attack. Some examples of bad IP packets are packets that do not contain higher-layer contents such as TCP, UDP, or Internet Control Message Protocol (ICMP) contents. Another example is receiving packets that claim to be fragments, when no other packets correspond with the fragments to allow the destination to properly reassemble the datagram. In fact, sending IP fragments is a relatively common method of attacking a host with the objective typically being to cause the host to inadvertently process the fragment data, frequently an exploit of some sort. A common utility that leverages this is the tool "fragrouter," which can be used to circumvent firewalls and IDSs. In general, the IP packet header should be interrogated to ensure that any fields that contain values contain accurate values. Any manipulation of this data could potentially cause a poorly designed host (see Windows systems for an example) to react in a negative fashion to the receipt of the data. |