[|PWNY|Nitro]

Barbatos, on 17 January 2012 - 05:23 PM, said:

That's approximately what I am doing. I took the latest ioquake3 sources, changed it a bit to fully support Urban Terror and added the patches.
Both linux builds are done, I'm now compiling the windows build.

thats awesome thanks FS :D now all we need is front page news to get everyone to update their server code otherwise this attack will still happen.

are these files now part of the 4.1.1 package available to new comers? that way new servers already have the right build/?

This post has been edited by nitro: 17 January 2012 - 05:34 PM

[CMM|xandaxs]

Mind releasing the Linux builds? :D

[FS Barbatos]

Linux and Windows builds are done. I have to test it now.

[CMM|xandaxs]

Good job!
Good Luck aswell! :D

[CMM|Rylius]

Don't forget to post the source, ioquake3 guys are pissed already

[rfx]

Rylius, on 17 January 2012 - 08:38 PM, said:

Don't forget to post the source, ioquake3 guys are pissed already

Ack; a github repository would be a plus.

[Rambetter]

ioquake3 trunk already contains a DRDoS fix. However they're still not handling getinfo, only getstatus is handled in their code.

Their way of fixing the DRDoS exploit is slightly different from mine. I would not say that mine is better than theirs, nor would I say that theirs is better than mine.

In their version of the code, they are using a "leaky bucket" algorithm. For any specific IP address, they allow 10 getstatus responses in a "burst". It takes 1 second for each record from a specific IP to "expire", so that during a sustained attack to a specific IP address only 1 getstatus response per second gets sent.

They also do a leaky bucket for non-IP-specific responses. They allow 10 getstatus responses to any IP address in burst mode, then each record expires in 100 milliseconds. So, during a hypothetical attack which sends getstatus responses to arbitrary IP addresses, only 10 getstatus responses per second are possible. Yeah, in fact 10 getstatus responses per second is kind of a small number in my opinion.

The way my code works is it allows a total of 48 getinfo+getstatus (combined) responses per the previous 2 seconds. To any specific IP address, the number of responses (getinfo+getstatus) is throttled to 3 per the previous 2 seconds.

One additional thing that my code does is when throttling to specific IP addresses it only looks at A.B.C.* in an IP address such as A.B.C.D. So for example 64.156.193.115 and 64.156.193.234 are treated as the same IP address for purposes of throttling. Just a minor thing for attempting to prevent an entire network from being DDoS'ed.



One last thing. If you're looking for the code differences that were made to the ioUrTded binary (changed from original ioquake3) back when 4.1 was released, you can see svn://porky.nerius.com/repos/ioUrT-server-4.1/urt-patch/ioUrT-4.1-server-r1240-ioquake3.patch . This has the changes that were made from ioquake3 code to the UrT server binary.

Barbatos if you need any help let me know.

This post has been edited by Rambetter: 17 January 2012 - 09:34 PM

[FS Barbatos]

Yeah the source code will be posted on Github.

@Rambetter, for the moment we will test with ioquake3's fix about the DRDoS exploit. If it doesn't solve the issue I'll use your patch.

[QA|ButterdBread]

Good job at everyone trying to solve the problem, both the dev team and rambetter!

I'm using rambetter's patch and the server traffic went down. But still, servers are laggy and I hope this will be solved by the official build.
The mix of iptables and the patch seems to be the best for me, because many connections can still cause high traffic and server lags.

Any clues who is behind the attack and what may be the reason for it (except for disturbing the services)?

This post has been edited by ButterdBread: 17 January 2012 - 09:37 PM

[rfx]

ButterdBread, on 17 January 2012 - 09:35 PM, said:

Any clues who is behind the attack and what may be the reason for it (except for disturbing the services)?

That's an interesting question. I guess only crowdsourcing can answer this; i.e. as much server owners as possible who have this problem should consolidate the IP information; maybe that will reveal some kind of pattern which would allow to isolate something ...

Edit:
Ok, so here's my contribution in that spirit:

cat qconsole.log | ruby1.9.1 -rresolv -e 'ips = Hash.new(0); while line = gets; if m = /DRDoS attack to address (\d+\.\d+\.\d+\.\d+)/.match(line) ; ips[m[1]] = ips[m[1]] + 1; end; end ; puts "Count\tIP (Host)";ips.sort_by { |k,v| v }.reverse.take(15).each { |k,v| puts "#{v}\t#{k} (#{Resolv.getname(k) rescue ""})" } '

results in

Count   IP (Host)
82143   86.19.188.193 (cpc8-midd15-2-0-cust192.11-1.cable.virginmedia.com)
43325   216.108.224.236 (lasvegas-nv-datacenter.com)
27039   176.31.101.119 (ks389328.kimsufi.com)
25836   99.122.50.253 (99-122-50-253.lightspeed.sntcca.sbcglobal.net)
20660   208.101.15.155 (rez1.netrulers.com)
14526   66.147.244.58 (box758.bluehost.com)
12813   99.71.220.87 (99-71-220-87.lightspeed.sndgca.sbcglobal.net)
12689   91.213.8.34 (s34.justhost.in.ua)
12197   91.233.20.40 (www.potenzladen.org)
9763    79.142.67.211 ()
7088    207.58.167.102 (vps.eminternational.net)
6454    69.42.223.147 ()
6100    66.147.242.193 (box593.bluehost.com)
5946    75.102.38.133 (chi.artofwarcentral.com)
4663    206.125.46.173 (unassigned.calpop.com)

I.e. these are my top-fifteen (arbitrary number) IPs triggering the "Possible DRDoS attack to address" line. Note: if you use the oneliner, it may take some time. qconsole may be big and resolving the IPs will also take some time.

This post has been edited by rfx: 17 January 2012 - 10:56 PM