[jahtariii]

Rambetter, on 07 March 2012 - 12:49 AM, said:

The logic I'm planning on is to trigger the temp ban once more than 3 getinfo+getstatus requests are sent in a period of 2 seconds from a single IP address. So if you sent 4 in 2 seconds you're temp banned.

I think the temp ban should last about an hour. This would really cut down on the traffic.

Hi Rambetter,

I think your idea is great, the only thing I can think of is players that will be temp-banned accidently because of "refreshing" to fast.

I discovered this behaviour even myself especially on my favourite-list, I click the refresh button quite often (more then 3 times per sec.) So it would be good if some code could be added to the client-code which disables clicking the button more than (maybe once in 2 sec).

I made some caps with wireshark and (sry I dont know much about game-src and how it works) it seems that while connecting to a specific server there is some Challenge-Response scheme.
So one possibility which of course would require much more change could be to add some kind of Challenge-Response scheme as well before requesting the servers with getinfo+getstatus queries.

This would rate the attack as rather ineffective since the response is only about 20bytes bigger then the challenge.
What do you think?

Greetings

This post has been edited by jahtariii: 07 March 2012 - 02:20 PM

[Rambetter]

Adding a challenge thingy to the getstatus might be an OK idea, but we can't change the protocol at this point, unless all the tools change, like the client, server, and master server. I don't think that will happen.

Yes, if you click "refresh" too fast it will temp ban you with my new proposed code. I do this too actually. Just don't click it so fast.

The "temp ban" logic is definitely not a foolproof solution to prevent DRDoS abuse. Here is why. An intelligent attacker will throttle the getstatus request to one per second (or so). Thus they'll be able to reflect 1 getstatus every second for an indefinite period of time.

However the way the attacks currently work is that they cause many getstatus requests in a very short period of time.

So I guess we can keep adjusting the server code with improvements, but in the end an attacker who is on top of it will probably find a way to beat my system.

[jahtariii]

first of all thx a lot for your answer!

jepp I fully agree and think so too. It really depends on the attackers incentive. Of course if the goal is to only disturb and stress the urt-community and cause higher traffic load and server bills for the admins, there is not much we can do about it as you pointed out. (At least unless changing the whole codebase/protocol as you said.)

If the motivation is a DDOS or DRDOS attack to bring down the victims service your fix is perfect to stop this.

Still, I have doubts and I think the main problem is to inform the people (urt-community) about this fix + to make them aware of not pressing the refresh-button too fast...

So dont get me wrong I do not want to critize your work or sth. just wanna help to improve and maybe solve things. Again I don't know if its feasible but what do you think about changing or adding the following functionality to your code:
1) Instead of adding the src-IP directly to the temp-ban list, you could add them to a "second-chance list".
2) If later there is a request or flood-attempt from this src-IP again, you could change the getinfo+gestatus msg to show the user a msg saying sth. like: "Warning stop clicking refresh that fast or you will be banned."
3) If the IP continues flooding enforce your temp-ban.

I dont know if its possible but if so, it could be an idea to prevent people beeing confused or pissed of and avoiding servers with your new patch. Ok I know this will look messy when there are unpatched servers in the list but at least it's a chance to let the players know about it and avoid it in the future.

Again it would be nice to hear some suggenstions/comments from you and the community about it...

greetings jahtari

This post has been edited by jahtariii: 07 March 2012 - 11:35 PM

[|PWNY|Nitro]

I like the idea of having a buffer system like the "second chance list" its allows for short burst/spam from an accidental player but on repetition enforces a ban.

also instead of 3 getstatus every 2 seconds you could do something like 7 getstatus in less than 5 seconds give ample room for an initial burt/spam but enforced ban afterwards the worst case scenario would be 7 packets every hour (or less if ban time is increased) or 5 every 5 seconds (1 per sec) but that can already happen with the current system also.

[Rambetter]

FYI I have now deployed a new patch to my 3 servers. I'm in the process of testing this new patch. The code is just straight from my SVN repository svn://svn.clanwtf.net/repos/ioquake3-UrT-server-4.1 . (Note this is the branch with the "newer code".)

The new feature is that once a particular IP address exceeds the 3 getstatus/getinfo limit in a period of 2 seconds, that IP address is added to a "temporary ban list". Each temporary ban expires in 2 minutes. The temporary ban list holds at most 24 entries.

This post has been edited by Rambetter: 09 March 2012 - 05:58 AM

[|PWNY|Nitro]

why only 2 minutes? is this only for testing purposes? what happened to the 1 hour rule you were thinking about?

also what happens when you reach the limit of 24 IP addresses? what if an attacker spams 24 fake addresses?

when you say "newer code" what do you mean? you seem to have 3 repos now for exploit fixes?! which is the most stable/upto date one you recommend following, I thought svn://svn.clanwtf.net/repos/ioquake3-UrT-server-4.1 was the most recent?

I hope I am not coming across as rude, I am just really confused lol.

This post has been edited by NITRO: 09 March 2012 - 03:41 AM

[[UZF]zombiebob]

Just throwing this out there without thinking about it too much, but i am intrigued by a white-list method..i guess that could be done with iptables...at least then i could open my server for my clan members.

[|PWNY|Nitro]

zombiebob, on 09 March 2012 - 03:22 AM, said:

Just throwing this out there without thinking about it too much, but i am intrigued by a white-list method..i guess that could be done with iptables...at least then i could open my server for my clan members.

1) why isn't your server open as is?

2) unless all your members have static IP addresses it would be a nightmare.

[[UZF]zombiebob]

well its quite a big flaw that all the servers can be suspect to ipspoofing or however its done to dos attack other servers, and it seems to me that the problem will never actually be fixed.

Again my comments are made with little thought, don't read too much into them i guess. [and i am absolutely no expert on the matter]

(and appreciate the work you done Rambetter, and see you pointing to the fact the exploit can never really be plugged, at least my understanding)

This post has been edited by zombiebob: 09 March 2012 - 04:00 AM

[[UZF]zombiebob]

also i didn't thank you for your iptables post nitro, ty :)