I've added rate limiting to getchallenge in 7b15415. As far as the DDoSing goes, the numbers used are deliberately not that aggressive. The reason for this is that it is impossible to tell the difference between legitimate inbound requests from genuine clients and those from a DDoS cluster. If you prevent the DDoS, you also prevent legitimate use of your server. By all means try playing with the numbers if you think you have a set which is acceptably more aggressive without disrupting normal access. The existing limits were all picked with a finger in the air.

Can you add a feature whereby the server administrator can adjust the numbers via a variable in the command line or server configuration file (the default being the current settings)? This way depending on the severity of the attack the server administrator can adjust numbers until he/she is content with the outcome.

Can you add a feature whereby the server administrator can adjust the numbers via a variable in the command line or server configuration file (the default being the current settings)? This way depending on the severity of the attack the server administrator can adjust numbers until he/she is content with the outcome. 

Additionally, if the settings can be changed happen while the server is running, this would be optimal. This way the administrator can adjust the numbers via rcon as the attack is occurring. 

Thank you. =)

Whilst the server suffers from getinfo and getstatus, it does cope with it.  The getchallenge is the only critical concern.  If there is indeed no actual way to allow legitimate connections then we have to wait out the attack.  According to the attacker this should only take a decade.

I notice a person is assigned to this, does this mean it's being addressed?
Either way, I've noticed a flaw in the flood protect of getchallenge.

The server was successfully lagged by one person with one IP with a repeated packet which shows in the logs (developer 1) thusly: -
SV packet 12.4.2.5:-7392 : getchallenge
SV packet 12.4.2.5:-7392 : getchallenge
SV packet 12.4.2.5:-7392 : getchallenge
SV packet 12.4.2.5:-7392 : getchallenge
SV packet 12.4.2.5:-7392 : getchallenge
SV packet 12.4.2.5:-7392 : getchallenge
SV packet 12.4.2.5:-7392 : getchallenge
SV packet 12.4.2.5:-7392 : getchallenge
SV packet 12.4.2.5:-7392 : getchallenge
SV packet 12.4.2.5:-7392 : getchallenge
SV packet 12.4.2.5:-7392 : getchallenge
SV packet 12.4.2.5:-7392 : getchallenge

There was 134 on that port, then 156 on port -29022, then 192 on port -20149 etc
All told there was over 300,000 getchallenge's in less than 1 minute from IP 12.4.2.5

It could be a spoofed packet via a DDOS, but unlikely that so many bots would all be on ISP without Ingress filtering.  It may just be a spoofed packet from one person but not that IP.  Either way, it completely bypassed the flood filter.  I can't give anymore information here as the server is hosted and I don't have remove virtual control, and its unlikely EscapedTurkey was running wireshark for the 5 minutes this attack lasted.

This is a community project so whether or not something is being addressed is really down to time, inclination and charity on the part of the people who occasionally contribute.

Anyway, are you definitely running a version with the changes? You should be seeing messages along the lines of "SV_GetChallenge: rate limit from ... exceeded, dropping request", if you are. Presumably you have recompiled and updated the copy you're running since I made the change I mentioned in comment 1? If not an auto build for that change is available here: http://ioquake3.org/files/jenkins/7b1541504216ce09ef2c7987eb5a7117a2125a5a/gcc/no_options/

A little over 2 years ago was when we last asked for information and received no response. Please consider this the "going twice" before the bug is marked resolved and let us know if there is still an issue that needs to be fixed.