Release Found: Red Hat Enterprise Linux 3, 4, 5, and Red Hat Enterprise MRG.

Update 14th September 2009: This article has been updated to include explanations of the example iptables rules in the Mitigation section.

Update 5th October 2009: This article has been updated with clearer iptables rules to avoid confusion (the changed rules use the same logic as the previous rules).

Problem

Denial of service flaws in the way TCP connections are handled have been disclosed by Robert E. Lee and the late Jack C. Louis of Outpost24 AB. These flaws allow an attacker to create crafted TCP connections, which can eventually exhaust the receiver's system resources and lead to a denial of service. These flaws are assigned CVE-2008-4609 (Red Hat Bugzilla bug 465932). Details of the attacks are described in the CERT-FI advisory.

Exploiting these flaws requires the attacker to have access to a subnet where they have routable IP addresses that they can make use of. These need to be different from the IP address being used by the attacker's machine. The attacking system must send from IP addresses that are not being competed for by other hosts, and it must guarantee that its ARP poisoning is completely effective. The attacking system must create an attack which can not only generate the three-way handshake but can avoid sending RST frames in a response.

Red Hat would like to thank CERT-FI and Outpost24 AB for reporting these issues.

Mitigation

These attacks target design limitations of the TCP protocol. Due to upstream's decision not to release updates, Red Hat do not plan to release updates to resolve these issues; however, the effects of these attacks can be reduced.

The following iptables example limits the number of new connections over a time period. It checks if packets are part of an existing or associated connection. If they are, the packets are accepted. Otherwise, if 10 connection attempts to any TCP port are received within 1 minute, they are dropped:

This example is a connection rate limit, not a concurrent connection count limit, as simply closing existing connections is not enough to enable new ones as it is the number of connections over the time period that matters. This example can be extended with TCP matches to separate limits per destination port. Note that this is only an example. Mitigation should be dealt with on a site-by-site basis.

Once you know you are under attack, block the IP address or subnet since this will be revealed in the attack packets. Furthermore, contact your upstream Internet provider to get those IP addresses blocked at their ingress.

Note: Support for connlimit in the kernel was added in Red Hat Enterprise Linux 5 via the advisory RHSA-2009:1243. At the time of writing, a bug is preventing it from working correctly, and as such, connlimit was not used in the above example. Future updates will address this issue.

Further Assistance

If you require assistance with mitigating this issue, please contact Red Hat support.