Sockstress mitigation on Linux using Shorewall

This week’s hot security issue in the networking world is sockstress.

Nasty little vulnerability, found in all known TCP implementations. Given the right circumstances (read up on it) it allows a very neat DoS attack to be mounted on a large destination with minimal attacking resource. And the really elegant part is that it exploits a fundamental weakness in the very architecture of TCP as implemented on all major platforms.

This short post is not going to go in to details of sockstress, nor even the various fixes that vendors have made available – for those read the widely-available advisories and get patched! All I want to document here is how to implement the Linux iptable mitigation solution published by Red Hat on a host using Shorewall as its iptables front-end. An interesting aside is that Linux vendors, as Red Hat here being an example, are not directly issuing patches for this. Given the nature of the vulnerability they appear to be adopting an approach of leaving the base implementation of TCP unchanged but using existing tool sets to protect the system. Whether this is a good or bad approach depends on your technological ideology more than anything. Personally I like it, but I can see that for a desktop, non-technical user environment it may be less than ideal. Still, I’m protecting servers here, so the point is moot.

So, how to mitigate on a machine using Shorewall? Actually very simple, but for some reason I couldn’t even find a clear pointer to this on the Shorewall site, let alone anywhere else. All you need to do is drop the set of iptables mitigation rules in to file /etc/shorewall/start and then restart Shorewall. Easy as that.

You might typically expect to find a dummy of such a file (and its partner /etc/shorewall/stop – not used here) in situ. However, on my systems anyway (Ubuntu Server Edition) neither was present.

But create them as required, add these (or other arbitrary) iptables commands, check the persmisions are -rw-r–r–, owner:group are root:root, and restart Shorewall. If you want to check the rules have “taken” you can do an iptables -S and/or iptables -L to observe them.

Note that the exact values used in the rules are, as the Red Hat advisory points out, going to be site specific. However the values given are a pretty good starting (and for many of us, finishing) point.

For completeness, here are the iptables rules as per the Red Hat advisory, 16 Sep 2009. If in doubt, check the original!

# The following rule accepts a packet that is associated with an established connection,
# or that is starting a new connection that is associated with an existing connection:
iptables -A INPUT -p tcp -m conntrack –ctstate RELATED,ESTABLISHED -j ACCEPT
# The following rule removes the source address (from the recent list) of a packet
# that has the FIN flag set and that is also in the recent list:
iptables -A INPUT -p tcp –tcp-flags FIN FIN -m recent –remove
# The following rule adds the source address of the packet to the recent list.
# If an entry for the packet already exists in the recent list, the entry is updated:
iptables -A INPUT -p tcp -m recent –set
# The following rule drops the packet if it is seen at least 10 times in the last
# five minutes:
iptables -A INPUT -p tcp -m recent –update –seconds 300 –hitcount 10 -j DROP