Bad IP Packets
In 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.
4 PREY
Continue reading here: TCP Segment Header
Was this article helpful?