Improve defense against status request spam

[Janmm14]

Related to #3815

Is there an easy way to close the connection if there are any bytes recieved and waiting to be processed, before we send StatusResponse? (At best without scheduling)

[Outfluencer]

As far as i know there is no easy way to achieve this

[Janmm14]

Maybe we could ensure channelReadComplete has been called at least once between recieving status request and ping request?

It may not be a solution covering all cases, but if a malicious entity is just sending handshake, status request and ping request all together it would definitely all end up in the same tcp packet as the size is quite small, be likely never split in the network and recieved in just a single read by netty from the os and therefore no call to channelReadComplete should be inbetween.

[Outfluencer]

I am not sure if this is really worth it as it can be bypassef by just sleeping a milisecond between the packets

[Outfluencer]

Wouldnt it be the safest way to just schedule it for a second or something anyway?

[Janmm14]

I wouldn't want to add such a signifcant delay of a whole second to the status response.

Otherwise I can only think of trying to work with epoll's internal access to tcp variables whether status response was recieved by the client at the time we recieve ping request (limited to epoll + internal access, so nothing really for bungee).

[Outfluencer]

Then you can also go for the readComplete, as far as i understand it should work counting it, but the attacker could just bypass it. Thats why i think its not worth to be added in bungee

[Outfluencer]

@Janmm14 i have created a minecraft xdp ddos protection, if those minecraft packets are sent in the same tcp packet my firewall should automaticly detect it and drop it.
Currently it supports only port 25565 and ipv4

If you want you can try it (you need root)

https://github.com/Outfluencer/Minecraft-XDP-eBPF

It generally drops all weird http traffic and stuff like this