DRDoS
Rate Topic:
1 Votes

Server used as reflector fro DRDoS

Are you sure that these iptables rules works? Because I am unable to block all the UDP even with...

iptables -A INPUT -p udp -m state --state NEW -j DROP

Because the packets are always in the ESTABLISHED state and not the NEW state (despite the unexisting connection :P )

Also

Quote

willthese patches being created be enough to prevent unpatched servers from accidentally send the return data to patched servers or will all servers require this patch in order to prevent the attack from spoofing the source ip as a patched servers ip

I don't understand, our UrT servers doesn't send the data to other UrT servers, take another read to the problems :P
So, all the servers need be patched or will be used as tools for these script kiddies.

@WizardOfGore

Thanks man! I still don't understand some lines :P
This code doesn't filter by IP right? Is a global limit too?

Are you sure that these iptables rules works? Because I am unable to block all the UDP even with...

I put these into iptables a while back when the problem was first noticed, my servers have not seen an attack yet so It has not been put to the test.

or perhaps the firewall hardware my server is connected to is detecting the X packets per second and dropping it there (i wouldn't know I would have to contact the admin team that runs it).

ipwnn00bs said:

I don't understand, our UrT servers doesn't send the data to other UrT servers, take another read to the problems :P
So, all the servers need be patched or will be used as tools for these script kiddies.

if the servers are tricked into thinking the source address is another urt server then a direct DDoS attack would happen on that specific server because all servers would send their replies to the victim spoof address.

Thanks man! I still don't understand some lines :P
This code doesn't filter by IP right? Is a global limit too?

Aye, it's not very well commented, but I was kind of in a hurry^^. It limits packets per IP and imposes a global limit, but it does not have any advanced logic to ban IPs for a longer period of time if that's what you're asking:

Mass queries are limited to 5 getstatus/getinfo packets per 2 seconds per IP - but since the buffer for IPs sending in the past 2 seconds only holds 32 entries, there is also a global limit of 32x5 requests per 2 seconds from different IPs.

The values I chose are quite conservative indeed. If you want to set more restrictive filtering, you have to edit the following lines:

I committed the DRDoS exploit fix to both of my branches (ioUrT-server-4.1 and ioquake3-UrT-server-4.1). It's part of the base code, so you don't need an "extra patch" to enable it. There are no server cvars to control it either.

I'm still sort of testing the fix but I think it may be OK.

If you want to be an early bird please feel free to proofread the code and/or run the new server binary. I'm running the new binary on all 3 of my servers right now.

I'll do a little more documenting and bookkeeping once I feel certain that this fix is OK.

I committed the DRDoS exploit fix to both of my branches (ioUrT-server-4.1 and ioquake3-UrT-server-4.1). It's part of the base code, so you don't need an "extra patch" to enable it. There are no server cvars to control it either.

I'm still sort of testing the fix but I think it may be OK.

If you want to be an early bird please feel free to proofread the code and/or run the new server binary. I'm running the new binary on all 3 of my servers right now.

I'll do a little more documenting and bookkeeping once I feel certain that this fix is OK.

I committed the DRDoS exploit fix to both of my branches (ioUrT-server-4.1 and ioquake3-UrT-server-4.1). It's part of the base code, so you don't need an "extra patch" to enable it. There are no server cvars to control it either.

I'm still sort of testing the fix but I think it may be OK.

If you want to be an early bird please feel free to proofread the code and/or run the new server binary. I'm running the new binary on all 3 of my servers right now.

I'll do a little more documenting and bookkeeping once I feel certain that this fix is OK.

THX for providing this patch.
On my Box I did a quick and dirty iptables scipt that drops those udp packets witch contain getinfo/ getstatus after a count of 4 per IP. <-- Is this sentence good english? dunno :)

How sad a fate that the Developers from FS did not take this serious Problem in their Hands and solved it nor say anything about it.
Or did I miss a comment of a FS member in this thread?

I will be compiling the updated windows and linux executables available on the server setup guide to include this new exploit fix, they should be up by the end of tonight, I will make a post in that thread and this one to let everyone know.

these binaries will include all rambetters latest exploit patches only, no additional features will be added that way they follow normal expected official behaviour except will have the Rcon/Kick exploit fix plus the DRDoS fix and any more exploits ram patched upto this point.

The reason for not included the "extra_patches" is so that FS if they see fit can use the binaries in their download section for new server owners and for third parties such as gameservers.com to use with increase server security without the need for additional support on unofficial mods/features.

ok i have updated the setup / support forum to includes the patch for DRDoS, and will update it in the near future should and changes be required. however for those of you that require the latest bleeding edge version that ram still hasn't fully tested can get it here.

Update your server!

Warning: These patches are unofficial and provided by the community, these are not supported by frozen sands. Use at your own risk!
These updated server binaries fix an exploit in the game code which could allow an attacker to gain RCON access to the unpatched server.
Now Includes a patch to prevent DRDoS attack exploit discussed here