The Linux kernel vulnerability CVE-2016-5696 disclosed last week affects a lot of devices, and a network administrator may not have root access to all of them (if owned by customer, or in the case of Android, root is held by the manufacturer and not the owner). It's unreasonable to think that patches will be coming anytime soon for all of these devices, and without root it isn't even possible to increase the global rate limit to mitigate the side channel.
However, the attack relies on the attacker being able to intentionally trigger a number of challenge-ACK packets back to themselves, in order to see whether the one on the spoofed connection causes the limit to be reached. If a border firewall were to restrict the number of challenge-ACK packets returning to an attacker to a lower number than the limit on the device being attacked, the information leak would be plugged.
For example, if a vulnerable device has a default global rate limit of 100, then implementing a per-node rate limit of 20 at a border router would prevent an outside attacker from executing the off-path attack, even if the device and firewall clock are not synchronized (best attacker can do is 20 at the end of one second followed immediately by 40 in the next, far short of the 100 that the attacked device is configured to send). Local devices could still communicate without being affected by the rate limit.
How would one implement such a mitigation using iptables on a Linux firewall running kernel version 4.x? What packets should be matched, what modules would keep track of the per-node rate and allow limiting?
Is it possible to detect an ongoing attack by counting challenge ACK packets (does the firewall have enough information to distinguish them?) and then blackhole the attacker? (This probably could not be accomplished using iptables alone, but using a reactive rule generator)
Detecting challenge-ACK packets may be a prerequisite, in order to not throttle ACK packets coming from the true peer.
I'm not really sure how realistic it is to worry about this vulnerability in a managed network for a few reasons I can think of.
*It is of course still possible that Bob tries to DoS devices on the LAN however that traffic won't be traversing the firewall anyway.
Worth nothing that Challenge ACKs are just ACKs with specific Sequence Numbers so you would likely need to implement custom tracking/packet parsing on your Firewall to pick them out. That sounds pretty pants.
Is it possible to mitigate CVE-2016-5696 using a perimeter firewall?
Probably not. At least, I would not expect any firewall vendors to officially support a form of mitigation against this. There are far too many scenerios where false positives would result in legit traffic being blocked.
The best you could likely do is update a config on your servers, or run one command at startup until you have a patched kernel. The vulnerability is due to Linux confirming to an RFC that nobody else conformed to.
To negate this behavior, update all of your servers
/etc/sysctl.confwith:Then run
sysctl -e -pon all of the servers you applied this setting to.If you plan on updating your kernel soon, you could simply run:
so that you do not need to change configuration files.
Why 131070? Anything over 1000 would suffice if the kernel was updated with randomization. The patch to the kernel sets the number to 1000 and adds randomization to mitigate the attack scenerio. Without the randomizion, you want a much larger number. I've seen some folks using 9 million.
[ Update ] To sum up: Based on your comments, a perimeter firewall would not likely help you. A perimeter layer 4 proxy would. I would seriously read up on haproxy.