POTENTIONAL FIX: etded.x86 getstatus exploit Options

[Guest_Dutchman_*]

Hi,

since a few months there is a exploit floating around abusing the getstatus requests to launch dos attacks against random targets and as a side effect creating massive lags on clients and the server.
Cause of this Yada from Staatsschutz.org made a patch for linux wich reduces the effectivity of this exploit.

etfix_getstatus 0.2 by yada / staatsschutz.org / jan. 2011
------

This patch will ratelimit etded.x86 2.60b getstatus requests to 1 per IP every
4 seconds. This approach is not ideal as the real fix would be to change the
protocol to require some kind of handshake but this would break compatibility
with existing clients so its not really practical. The worst part is that the
patch is (in theory) vulnerable to a dos where legitimate clients could be
denied access to the getstatus command but i feel this is less of a headache
than kiddies using the server to flood random targets and thereby lagging the
server and pushing bandwith usage through the roof (master server is excluded
from ratelimit so no need to worry about it being denied using spoofed
packets).

Download the file right here.

A readme.txt, the sourcecode and a small howto are included.

Your free to distribute this file.

This post has been edited by Dutchman: Jan 6 2011, 11:33 AM

[Sickboy]

i've noticed on our server a few slower attacks packetting us just below our threshold. yesterday i reduced the threshold too low and legitimate game clients were dropped upon connecting. what i decided to do was run a second instance with a longer check time (10 mins) and higher packet #. seems to be working well along with the 3 sec script. wouldn't it be possible to write an iptables rule to only allow those packets from specific ips? ie legitimate trackers: et master server, trackbase, splatterladder, etc? the downside being that game clients couldn't do a /serverstatus, but i think its a small price to pay until theres a permanent solution.