[undead]

Barbatos, on 17 January 2012 - 09:14 PM, said:

Yeah the source code will be posted on Github.

Great. :) It's too bad ioquake3 are dragging their feet on moving away from SVN and/or setting up an official SVN mirror in hg/git. They talked about moving to hg over a year ago. It would be better if you could create a fork of their ioquake3 hg/git-svn mirror but they don't have one.

Could you post updated clients too based off of the latest ioquake3? The current ioUrT is from r1142 (2007) or so which is over 1,000 commits behind the trunk. There are client bug fixes in that time frame too.

This post has been edited by undead: 18 January 2012 - 12:13 AM

[undead]

Barbatos,

I suggest a few changes. You shouldn't have to modify the Makefile. Use Makefile.local instead since the Makefile is full of ifndef.

No need to delete the body of CheckPak0 because ioUrT should be using #define STANDALONE. Set that in the Makefile.local as well. I see a couple places where the code is deleted when it was already protected by a #ifndef STANDALONE. It would also disable some code that isn't needed in a standalone game like the authorize server.

I don't think you need to change the PROTOCOL_VERSION. You should enable the legacy protocol (68) instead by setting LEGACY_PROTOCOL=1 in q_shared.h. There are many other parts of the code that use the LEGACY_PROTOCOL so it would be better to set it than change PROTOCOL_VERSION. Or do you plan on moving the server/client to the new protocol? You don't need to mess with demo_protocols either if you define LEGACY_PROTOCOL.

Is including the pak headers legal? I didn't include them in my github repository because it's id software's proprietary data.

Setup a README.md so it overrides the ioquake3 one. Github will display that when people load the page.

Here's my github where I have the above changes and more. It's not a fork of yours, but it's also based on r2214. I noticed some changes in yours that I'll grab. :) I didn't know the dedicated memory was upped to 256 etc.

https://github.com/u.../undeadzy_iourt

I have the full history and it's a fork of https://github.com/u...ioquake3_mirror It doesn't show up as a fork because github doesn't let you create a fork of your own software. Kinda annoying :/

Edit: Also, you should move the defines to a different location in server.h. They are inside the #ifdef USE_VOIP but the code that uses them is outside of a #ifdef USE_VOIP so the code won't build if you have USE_VOIP=0 in the Makefile.local.

Edit: I would use VERSION in the Makefile.local so you don't have to change it in the code (becomes PRODUCT_VERSION).

Edit: Why did you remove devmap, spmap and spdevmap? Also, why remove the call to Com_ExecuteCfg()? Neither of those changes were in ioUrT before. Are those related to some fix or is it a result of moving up 1,000+ commits and something changed?

I noticed you have #define GAMENAME_FOR_MASTER "q3ut4" and #define HEARTBEAT_FOR_MASTER "QuakeArena-1". I don't know about the server, but the client works fine without those changes. Is that related to a fix too?

This post has been edited by undead: 18 January 2012 - 02:04 AM

[|P|Nitro]

rfx, on 17 January 2012 - 10:22 PM, said:

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.

it was my understanding that the IP's listed in console where the source address which is most likely spoofed so that all server send their status updates to the same IP creating the DDoS?

Therefore these IP's wont indicate the person(s) behind this but rather the victims?


or have I misunderstood this?

[gXS.looza]

Quote

Therefore these IP's wont indicate the person(s) behind this but rather the victims?

I understood it like this:

The ips you can see there are the targets/victims for the attack.
the attacker send a getstatus query with a faked ip (address of the target) to your server.
your server send the answer to the target then and not back to the attacker.

the reason for this is that the attacker only send the ip and the getstatus cmd and your server answer with a much higher load of informations(like hosname, playernames, pings, frags, mapname and so on).
with that the attacker can produce a much higher traffic flood for his attacs.

its like : the attacker send querys with 0,5 mbit and your server attack the target with 20 mbit.

Thats why this attack is so bad... you see what you can do with 1200 urt servers? :D

and you really can get in trouble when the victims complain about your ip address,
so its very important that server admins fix this.

This post has been edited by looza: 18 January 2012 - 07:47 AM

[rfx]

Doh. I guess you're right. So what I posted would be the actual victims (which they aren't anymore because this patch is active). Darn.

@Rambetter: is it technically possible to output the source IP of the attacker in anyway?

This post has been edited by rfx: 18 January 2012 - 10:24 AM

[Rambetter]

rfx, on 18 January 2012 - 10:00 AM, said:

@Rambetter: is it technically possible to output the source IP of the attacker in anyway?

If that were possible, then the server code could make a simple check: is the source IP of the getstatus request the same as the IP to send the response to? If not, ignore.

But you can't do that. D'oh! You only have one address, which is the reported source address (which is oftentimes fake especially during these attacks).

[bc`ItsMe]

undead, on 18 January 2012 - 01:02 AM, said:

I noticed you have #define GAMENAME_FOR_MASTER "q3ut4" and #define HEARTBEAT_FOR_MASTER "QuakeArena-1". I don't know about the server, but the client works fine without those changes. Is that related to a fix too?

Not at all. This is an addition to the legacy Protocoll used by Q3A in the DarkPlaces Protocoll.

You should set this as empty string so its not transmitted to the Master. Else this String will be submitted to the Masterserver as first value and than it is not recognized as Urbanterror Server from the Master anymore.
As a Result the Server _disapears_ from the Masterlist.

Set it like this will work fine:

#define GAMENAME_FOR_MASTER           ""      // must NOT contain whitespace

You can set this to any Value you want to when you run UrT as Q3A Mod with the original pak0 File


_Edit_

After a short thought I've uploaded prebuilded binarys (i386 and x86_64) from the latest ioquake trunk (without the changes that I've made to the sourcecode) for downloading.
I use the x86_64 binary since December without any Problems.

They should work out of the box - so I hope :) Just Test it or take a Look at the Spoiler for the used glibc.

Download:
Both: http://www.bubbleclu.../binarys.tar.gz

i386: http://www.bubbleclu...rt/ioq3ded.i386
MD5: e0321c3412347c4508f092e21d9ff116

x86_64: http://www.bubbleclu.../ioq3ded.x86_64
MD5: 6c4645d764a31cdc5b2c585e900189ba


Build against:

Spoiler

depencies i386 build:
---------------------
[urbanterror@jumps:~]$ ldd -v ioq3ded.i386

linux-gate.so.1 => (0xffffe000)
libdl.so.2 => /lib/libdl.so.2 (0x00310000)
libm.so.6 => /lib/libm.so.6 (0x00317000)
libc.so.6 => /lib/libc.so.6 (0x0019a000)
/lib/ld-linux.so.2 (0x0017b000)

Version information:
./ioq3ded.i386:
libm.so.6 (GLIBC_2.1) => /lib/libm.so.6
libdl.so.2 (GLIBC_2.1) => /lib/libdl.so.2
libdl.so.2 (GLIBC_2.0) => /lib/libdl.so.2
libc.so.6 (GLIBC_2.3) => /lib/libc.so.6
libc.so.6 (GLIBC_2.1) => /lib/libc.so.6
libc.so.6 (GLIBC_2.0) => /lib/libc.so.6
/lib/libdl.so.2:
ld-linux.so.2 (GLIBC_PRIVATE) => /lib/ld-linux.so.2
libc.so.6 (GLIBC_2.1.3) => /lib/libc.so.6
libc.so.6 (GLIBC_2.1) => /lib/libc.so.6
libc.so.6 (GLIBC_2.0) => /lib/libc.so.6
libc.so.6 (GLIBC_PRIVATE) => /lib/libc.so.6
/lib/libm.so.6:
ld-linux.so.2 (GLIBC_PRIVATE) => /lib/ld-linux.so.2
libc.so.6 (GLIBC_2.1.3) => /lib/libc.so.6
libc.so.6 (GLIBC_2.0) => /lib/libc.so.6
/lib/libc.so.6:
ld-linux.so.2 (GLIBC_PRIVATE) => /lib/ld-linux.so.2
ld-linux.so.2 (GLIBC_2.3) => /lib/ld-linux.so.2
ld-linux.so.2 (GLIBC_2.1) => /lib/ld-linux.so.2

depencies x86_64 build:
---------------------
[urbanterror@jumps:~]$ ldd -v ioq3ded.x86_64
linux-vdso.so.1 => (0x00007fff349fd000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000003602200000)
libm.so.6 => /lib64/libm.so.6 (0x0000003603200000)
libc.so.6 => /lib64/libc.so.6 (0x0000003601e00000)
/lib64/ld-linux-x86-64.so.2 (0x0000003601a00000)

Version information:
./ioq3ded.x86_64:
libdl.so.2 (GLIBC_2.2.5) => /lib64/libdl.so.2
libm.so.6 (GLIBC_2.2.5) => /lib64/libm.so.6
libc.so.6 (GLIBC_2.3) => /lib64/libc.so.6
libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6
/lib64/libdl.so.2:
ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2
libc.so.6 (GLIBC_PRIVATE) => /lib64/libc.so.6
libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6
/lib64/libm.so.6:
libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6
/lib64/libc.so.6:
ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2
ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2

HTH

--
ItsMe

This post has been edited by ItsMe: 20 January 2012 - 11:43 AM

[FS Barbatos]

You can now download the official patched builds:
http://www.urbanterr...loads/security/

Here is the source code:
https://github.com/B...r-UrbanTerror-4

A news post will be posted soon.

[ro||pab]

good news thank you

[Rambetter]

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

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 servers are laggy not because of the code I added to address the exploit.
In fact one of my servers is experiencing an extreme DRDoS attack at the moment. I mean _extreme_. I'm getting a constant flood of getstatus trying to attack multiple IP addresses. The CPU usage on the server process is not elevated at all. In-game, there are absolutely no hiccups.