DDoS against virtualserver - server doesn't accept new connections

[maxi1990]

I've just had the following issue (thrice during the last 4 days):

DDoS against a specific virtualserver port on udp (about 10MBit/s) for about 100 secods (3 bursts), all connected clients dropped. After the attack, nobody was able to reconnect unless I restarted the specific virtualserver. All other running virtualservers were not affected and continued running smoothly.

I can provide a tcpdump if neccessary. While I understand that there is nothing much I can do about DDoS, the virtualserver should continue running/accepting clients after the attack stopped which is the main reason for this bug report.

Server data:
GNU/Linux Debian Wheezy (kvm virtual machine)
Current server version 3.0.11.4
Database backend sqlite
Server load was normal ~0.25 around the attack
Network connection 1GBit/s shared
Note: the linux server uses CET while the teamspeak server seems to use utc timestamps in logs.

[dante696]

Please check your server logs (instance and vserver), when user has dropped.
The server has a mechanism, that blocks connections for a while and prints a message then.

the message looks like:

2015-10-18 18:27:52.445215|INFO    |              |   | Increased protection level to: 1

I'm not sure if it was in instance or vserver log and i'm not 11% sure how this mechanism works.

[maxi1990]

No such message is shown in any logs. I am logging all except serverquerycommands.
Here is ts3server.ini: https://pbot.rmdir.de/RkS5T-s3eFbAZ6fZM2y94g

One attack took place at 01:19 a.m. and no new clients were able connect until I restarted the server at 10:54 a.m. Again, no entry in any log is found about any kind of protection.

I doubt that this is the desired behaviour. Please inform Ralf about the issue.

Regards,

Max

[dante696]

I will talk to a server dev* about that issue.
It's something we never experienced while our test server was attacked over months.


*no it's not Ralf.

[maxi1990]

I will talk to a server dev* about that issue.
It's something we never experienced while our test server was attacked over months.

Thanks, I appreciate that.

If you guys need the tcpdump, just let me know.

[dante696]

Our dev has an idea about that. It's problem with a race condition in boost.
We fixed this already in an upcomming* server release 3.0.12.

No release date yet

[maxi1990]

Our dev has an idea about that. It's problem with a race condition in boost.
We fixed this already in an upcomming* server release 3.0.12.

Thanks for the quick answer.