[Rambetter]

My server was being hit for a very short while, and it's no longer being hit.

[apath0]

Rambetter, on 12 December 2011 - 12:46 AM, said:

I'd like to get some feedback for my fix.
Can anyone confirm that a "before and after", where the "before" is sending tons of data and "after" isn't?

hey ramb,

i installed it just now and don't have any malicious traffic right now... there are some connections, but the rate is not above 'legitimate' requests.

iftop -P:

myserver:27960              => bb115-66-101-144.singnet.com.sg:27960        0b    147b     37b
myserver:27960              => vm7.s7.tonbnc.fr:42155                    3.68Kb   754b    189b
myserver:27960              => fon59-1-88-182-197-194.fbx.proxad.:27960     0b    147b     37b
myserver:27960              => 212.187.209.72:43034                         0b      0b    189b
myserver:27960              => n1164957245.netvigator.com:27960           736b    147b    110b
myserver:27960              => 193.54.153.250:codasrv-se                    0b    147b     37b

even my ssh-connection causes more traffic! so i'd say good job ;)

i'll keep an eye on it and keep you informed in case of problems. i also didn't play yet, so i can't tell you anything about potential gaming- or b3-probs.

thanks a lot for helping us out, you're doing a great job!

apath0

This post has been edited by apath0: 13 December 2011 - 06:42 AM

[ipwnn00bs]

Hey ItsMe, do you mind on sharing your iptables script?
Maybe will be useful for other kind of services with some modification

And Thanks Rambetter, I have applied it to several servers now. But still I am not able to see if works, or just the attacks stopped.

The warnings are logged to the games.log file right?

Btw, I like the way you code :P

[farflame]

nitro

ldd ioUrTded.i386
./ioUrTded.i386: /lib32/libc.so.6: version `GLIBC_2.11' not found (required by ./ioUrTded.i386)
linux-gate.so.1 => (0xf77dd000)
libdl.so.2 => /lib32/libdl.so.2 (0xf77cf000)
libc.so.6 => /lib32/libc.so.6 (0xf767d000)
/lib/ld-linux.so.2 (0xf77de000)

you build the linux ver using a quite new version of GLIBC :)

on Lenny and other linux distros, not so new, it may fail to start :)

[Rambetter]

ipwnn00bs, you'll see a few small number of log messages in qconsole.log when the exploit fix is triggered, but you'll only see these log messages when "developer 1" is enabled. I don't recommend turning this on unless you want to see LOTS of log messages (like a line for each connectionless packet received).

I am only logging when "developer 1" is set because I didn't want to unintentionally mess up anyone's log parsing code. I could just as easily change my logging to be on even when "developer 0" is set.

[[DSG]Durandal]

Rambetter, on 12 December 2011 - 12:46 AM, said:

I'd like to get some feedback for my fix.
Can anyone confirm that a "before and after", where the "before" is sending tons of data and "after" isn't?

Didn't seem to make any difference. Had 3 servers under attack just now... two in one VPS in dallas, and one in a different VPS in norcal. I had one on dallas running the new binary... one running the vanilla binary.. and the norcal one running vanilla.

All of them showed the same traffic connections and the same huge lag spikes until the attack stopped.

--edit--

Is there a cvar that needs to be set or is this a hard coded limit on the app level with the new binary?

This post has been edited by Durandal: 16 December 2011 - 12:45 AM

[Rambetter]

The incoming packets won't change with the patch, only what gets sent by the game server. You should be seeing that a maximum of 3 getstatus/getinfo responses are sent every 2 seconds to a given IP address, if you have the latest code (I recommend compiling yourself because I'm still making changes to the code).

Also if you're running the latest code you should be seeing something like this in the qconsole.log, even with developer logging disabled:

Possible DRDoS attack to address 2.4.119.112, ignoring getinfo/getstatus connectionless packet

I tested the fix by sending lots of getstatus requests to my game server and sure enough it dropped most of the requests without sending a response.

So, I don't know to what extent it's not working for you.

This post has been edited by Rambetter: 16 December 2011 - 12:34 AM

[[DSG]Durandal]

Rambetter, on 16 December 2011 - 12:33 AM, said:

The incoming packets won't change with the patch, only what gets sent by the game server. You should be seeing that a maximum of 3 getstatus/getinfo responses are sent every 2 seconds to a given IP address, if you have the latest code (I recommend compiling yourself because I'm still making changes to the code).

Also if you're running the latest code you should be seeing something like this in the qconsole.log, even with developer logging disabled:

Possible DRDoS attack to address 2.4.119.112, ignoring getinfo/getstatus connectionless packet

I tested the fix by sending lots of getstatus requests to my game server and sure enough it dropped most of the requests without sending a response.

So, I don't know to what extent it's not working for you.

Well.. what I was seeing is that during the attacks there was a ton of data being received and sent so not only was there the flood of SV getinfo requests showing... but the netgraph in HLSW and in game were hammered and the game was unplayably lagged when I connected. All servers seemed to show this regardless of version.

I've changed nothing and now I'm seeing huge inbound getinfo requests with minimal lag... but then so is my vanilla server...

So I'm not sure what exactly is going on with it. I'm going to grab the latest code and compile it and see if it makes a difference.

Just to confirm, this is a hard coded limiter and not something you need to configure via server cvars or whatnot right?

[Rambetter]

Durandal, on 16 December 2011 - 12:56 AM, said:

Just to confirm, this is a hard coded limiter and not something you need to configure via server cvars or whatnot right?

Yes, hardcoded.

If you're running unpatched and patched servers on the same machine and they are all getting hammered by the DRDoS exploit, then the explanation for the huge lag spikes is that the unpatched servers are sending tons of data which is slowing down the connection. I'm interested if you can more accurately verify that the patched server is sending tons of data. "Huge lag spike" is not a very scientific proof. :-)

[|P|Nitro]

VPS servers share internet bandwidth, and with some people claiming to be recieving upto 10MB/s it could be that the game server is dropping the packets but the amount of bandwidth is maybe what s causing the spikes in game as usually the is some sort of limitation per server on VPS servers aswell, so although the packets are being dropped you still have to recieve them at the network level before you can drop them.