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

[Ligustah]

It is certainly possible to make iptable rules that work like the script i posted. I actually experimented with that for quite a while,
though i can't remember why i went for the script in the end.

Blocking getstatus alltogether might not be a good idea. Game trackers are not the only ones who send getstatus requests.
Programs like XFire, HLSW or RCON Unlimited all rely on getstatus and will probably show the server offline if you block them.
You might however apply the script i posted above only to getstatus packets. At the moment it will count all connectionless packets (getinfo, rcon, getchallenge, etc).

QUELLTEXT

filter = "udp and src host 123.456.789.123 and udp[8:4] = 0xFFFFFFFF"

The last part of the filter checks the next 4 bytes at offset 8. You can change that to check for a longer byte sequence so as to catch getstatus only. I never bothered doing that.


I have been using a limit of 300 packets for quite a while now and it seems to work out very smoothly, haven't heard of legit clients getting dropped or being unable to connect. You will however have to adapt that limit depending on the number of game servers you run on your machine.

This post has been edited by Ligustah: Aug 29 2011, 09:36 AM