On Thu, Jan 12, 2012 at 10:23 PM, Tim Angus wrote:
> It's a leaky bucket rate limiter; r1762.
>
TODO: also apply rate limiting in SVC_Info().
___
ioquake3 mailing list
ioquake3@lists.ioquake.org
http://lists.ioquake.org/listinfo.cgi/ioquake3-ioquake.or
On Thu, 12 Jan 2012, 18:45:34 GMT, Nerius Landys wrote:
> > Do you mean to say you're using the same rate limiting code as ioq3,
> > but with tighter constraints?
>
> I actually have not looked at ioquake3 code trunk in a while.
>
> One of my "versions" of UrT server source code is based on ioqu
> Do you mean to say you're using the same rate limiting code as ioq3, but
> with tighter constraints?
I actually have not looked at ioquake3 code trunk in a while.
One of my "versions" of UrT server source code is based on ioquake3
1.36 (svn://svn.icculus.org/quake3/tags/1.36/) and I could have
On 12/01/2012 17:41, Nerius Landys wrote:
I created a special patch for Urban Terror 4.1 server code (open
source, based off an old ioquake3) a month ago when the exploit became
severe.
My code limits the total number of getinfo+getstatus responses to 48
for the previous 2 seconds elapsed. In a
I created a special patch for Urban Terror 4.1 server code (open
source, based off an old ioquake3) a month ago when the exploit became
severe.
My code limits the total number of getinfo+getstatus responses to 48
for the previous 2 seconds elapsed. In addition, the code limits the
number of getin
> I'd like to hear what people think about this.
The distribution of the attack over a lot of game servers cannot be
avoided AFAIK. But to protect a single server, limiting the number of
requests per IP sounds like the only solution to me. This can easily be
done using iptables (so also works for
On 12/01/2012 10:59, RawShark wrote:
I'd like to hear what people think about this. We have shut down our
server to avoid the IP being blacklisted until a solution presents
itself. I'm thinking ioquake3 should be patched in some way to detect
this exploit? I can't really think of any combination