Server used as reflector fro DRDoS
Posted 06 December 2011 - 06:28 PM
seems that now also the UrT server are used as reflectors for a DRDoS attacks.
The usage of COD series servers as reflectors is done since about one year. The attacker sends spoofed packets with a status o serverinfo request to flood the IP of the "victim" server. The outgoing traffic is 5 - 10 times higher than the incoming traffic.
Did anybody noticed this increasing "reflection" activity in the last days?
I'm not sure if there is a way in iourt to limit the maximum number of requests to the server.
An experimental patch for the linux version of the COD4 linux server was released some months ago and it works fine, it could be interesting to implement something similar if not yet available.
Posted 06 December 2011 - 09:44 PM
Posted 07 December 2011 - 04:30 PM
iftop looks like this:
muehsam.trendless.net:27960 => customer.worldstream.nl:http 2.28Mb 1.81Mb 1.79Mb
most likely theres just 1 or two connections like this (various hosts) with outgoing rates between 1 and 5 mb/sec... this adds up to around 6-8gigs of traffic per day and the server lags occasionally. there is nothing in the logs.
technical background for this kind of attack can be found here: http://www.lemuria.o...tion-drdos.html
Posted 07 December 2011 - 07:08 PM
I think that he is talking about the following patch available in the SVN
I'm not sure if this will fix this kind of attack as it's mentioned the client connection but the server status and serverinfo are available via UDP even if you're not "connected".
Introduces two new server cvars: sv_limitConnectPacketsPerIP and
sv_maxClientsPerIP. If sv_limitConnectPacketsPerIP is set to any value
greater than zero, the server will ignore "connect" packets coming from a
single IP address in excess of four in the past six seconds. This is a
safeguard against a flood of connect packets from a single IP address source.
Hope to be able to build the server binary and try it.
Posted 08 December 2011 - 10:59 AM
the connectlimit.patch just exists for ioquake3-UrT-server-4.1!
so i compiled that one, but the issues are not resolved =/ i'm pretty sure sv_limitConnectPacketsPerIP worked though, because b3 behaved strangely (announcing 'player from country connected' every single round)
any other ideas on how to stop this attacks instead of dropping the packets for every single host via iptables?
i think there are actually a lot more servers 'infected' with this exploit right now, the admins just didnt recognize it yet. the offender(s) should be getting the list of gameservers by querying the masterserver, so i would find it very unlikely if only farflame and me are suffering from it. to be clear: you wont be able to see anything in your gameserver-logs, there a no random people connecting or anything else. the only way to see if your server is affected is to monitor the traffic on the port(s) of your gameserver(s).
really hope there is a way to fix this,
This post has been edited by apath0: 08 December 2011 - 11:03 AM
Posted 09 December 2011 - 12:48 AM
Since this is a problem with how the actual game code works... I would hazard that every UrT server on the master list is contributing to the ddos.
We did notice regular "shark tail" yellow spikes on the netgraph and occasional connection interrupts while in play on the affected servers. So if you are seeing this out of nowhere... it could be an indication.
Posted 09 December 2011 - 02:22 PM
You're right. The "bug" it's in the core of Id's code. A lot of servers based on Id's code suffer this bug (COD, ET, Q3 ...).
What I've noticed is that it seems that the tool they use to flood the server has a minimum of logic in it. In the first attacks, taking into account also the ones versus for example COD2-4 servers, the spoofed ip's where used even if the server was empty. An empty server of course replies with a small status packet as no players are in. Now it seems that the attack starts only when the server has some players, in this way they take the maximum damage to the destination host as the reply status packet is bigger, and they maximize the use of their upload bandwidth.
I'm not sure about this but that's what i suppose.
Regarding the ability to stop attack using iptables I think that only combining length module and recent module but don't know if I have time to experiment. Should be something like what's reported here and here but with some changes.
This post has been edited by farflame: 09 December 2011 - 02:43 PM
Posted 09 December 2011 - 08:20 PM
If you get something with iptables let me know, despite isn't the best solution for all, because some people uses Windows, or uses a machine without root privileges.
This post has been edited by ipwnn00bs: 09 December 2011 - 08:20 PM