tcp_bad_checksum

Description

This indicates that a TCP packet with a bad checksum was detected.

The calculation of the TCP checksum is done by including a pseudo-header that contains the following fields (a total of 12 bytes):

  . source IP address (4 bytes)
  . destion IP address (4 bytes)
  . reserved byte (1 byte and must be zero)
  . protocol (1 byte)
  . length (2 bytes)

This is a protocol anomaly. Many attack tools construct their own TCP headers but fail to include the required pseudo headers when TCP checksums are computed, therefore such malicious TCP packets will bear incorrect TCP checksums. For instance, distributed denial-of-service attack tools TFN and TFN2K make this mistake. Clearly, we can catch such attacks by checking the TCP checksums of their packets.

Affected Products

Any operating system.

Impact

All TCP packets with checksum errors will be discarded by end systems
according to RFC793, which states (see Section 1.5):

  Reliability:
    The TCP must recover from data that is damaged, lost, duplicated, or
    delivered out of order by the internet communication system.  This
    is achieved by assigning a sequence number to each octet
    transmitted, and requiring a positive acknowledgment (ACK) from the
    receiving TCP.  If the ACK is not received within a timeout
    interval, the data is retransmitted.  At the receiver, the sequence
    numbers are used to correctly order segments that may be received
    out of order and to eliminate duplicates.  Damage is handled by
    adding a checksum to each segment transmitted, checking it at the
    receiver, and discarding damaged segments.

It is clear from the last sentence of the above paragraph that any host should drop damaged segments that are detected by TCP checksum.

Recommended Actions

FortiGate IPS have multiple options to handle such malformed TCP packets: pass, drop, or reset. It is upto the system administrators to make the decision.

References