Limit the amount and data size of incoming packets

[Outfluencer]

It is possible to make netty threads lag by spamming a massive amount of packets.
And you can make players time out with it.

I am not sure if i should say how specifically you can achieve that, publicly.

A simple packet limiter should mitigate those attacks.

A vanilla client should never exeed the default value of 2000 packets per second, but we can disguss about this if any concerns

[Janmm14]

Would it maybe be useful to change this to have just have a task per connection on the netty thread every second setting the counter to 0? I think calling the currentTimeMillis method and checking for seconds elapsed for every packet is a waste of time.

[Outfluencer]

As you can see we dont get the millis every packet, we check for the millis every 2000th packet

Normally a client send 20-60 packets per second so this should not have any Performance impact at all

Edit: If you would set the limit to 1000 in the config every 1000th packet would be checked

[Janmm14]

Oh, I somehow missed that part of the logic. My bad.

[andreasdc]

I saw that in 1 fork they also check the packet size in bytes, maybe it will be a good idea? Does it check every possible connection from player? Pretty nice idea for the counter.

[Outfluencer]

I saw that in 1 fork they also check the packet size in bytes, maybe it will be a good idea? Does it check every possible connection from player? Pretty nice idea for the counter.

i dont think a data size check is needed

[andreasdc]

I saw that in 1 fork they also check the packet size in bytes, maybe it will be a good idea? Does it check every possible connection from player? Pretty nice idea for the counter.

i dont think a data size check is needed

What if you have many large packets under the limit?

[Janmm14]

What if you have many large packets under the limit?

Too large packets are causing kicks by bungee or spigot already.

[andreasdc]

What if you have many large packets under the limit?

Too large packets are causing kicks by bungee or spigot already.

That depends, but I guess we talk about the thing when pakets are received earlier on bungee than spigot.

[Outfluencer]

What if you have many large packets under the limit?

Too large packets are causing kicks by bungee or spigot already.

That depends, but I guess we talk about the thing when pakets are received earlier on bungee than spigot.

if the packet exceeds the protocol limits we throw an exception on bungee side, if we do not read the packet the minecraft server throws the exception
or did you mean something else?

[andreasdc]

What if you have many large packets under the limit?

Too large packets are causing kicks by bungee or spigot already.

That depends, but I guess we talk about the thing when pakets are received earlier on bungee than spigot.

if the packet exceeds the protocol limits we throw an exception on bungee side, if we do not read the packet the minecraft server throws the exception or did you mean something else?

I mean the packets that are handled on bukkit, I suppose it's possible to lag it before it even reaches the spigot.

[Outfluencer]

I mean the packets that are handled on bukkit, I suppose it's possible to lag it before it even reaches the spigot.

i dont get your point

[andreasdc]

I mean the packets that are handled on bukkit, I suppose it's possible to lag it before it even reaches the spigot.

i dont get your point

I think it's possible to mass spam packets, the netty thread on bungeecord will be lagged it even reaches the spigot.

[Outfluencer]

I mean the packets that are handled on bukkit, I suppose it's possible to lag it before it even reaches the spigot.

i dont get your point

I think it's possible to mass spam packets, the netty thread on bungeecord will be lagged it even reaches the spigot.

how can you mass spam if there is a packet limit?

[andreasdc]

I mean the packets that are handled on bukkit, I suppose it's possible to lag it before it even reaches the spigot.

i dont get your point

I think it's possible to mass spam packets, the netty thread on bungeecord will be lagged it even reaches the spigot.

how can you mass spam if there is a packet limit?

Spam under the packet limit with massive packets, I was more worried without the limiter.

[Outfluencer]

I mean the packets that are handled on bukkit, I suppose it's possible to lag it before it even reaches the spigot.

i dont get your point

I think it's possible to mass spam packets, the netty thread on bungeecord will be lagged it even reaches the spigot.

how can you mass spam if there is a packet limit?

Spam under the packet limit with massive packets, I was more worried without the limiter.

thats not a bungeecord issue but this pr should mitigate that

[xism4]

I mean the packets that are handled on bukkit, I suppose it's possible to lag it before it even reaches the spigot.

i dont get your point

I think it's possible to mass spam packets, the netty thread on bungeecord will be lagged it even reaches the spigot.

how can you mass spam if there is a packet limit?

Spam under the packet limit with massive packets, I was more worried without the limiter.

thats not a bungeecord issue but this pr should mitigate that

Wouldn't an external plugin be better just for this?

[andreasdc]

I mean the packets that are handled on bukkit, I suppose it's possible to lag it before it even reaches the spigot.

i dont get your point

I think it's possible to mass spam packets, the netty thread on bungeecord will be lagged it even reaches the spigot.

how can you mass spam if there is a packet limit?

Spam under the packet limit with massive packets, I was more worried without the limiter.

thats not a bungeecord issue but this pr should mitigate that

Wouldn't an external plugin be better just for this?

Too much resources for the plugin I think.

I mean the packets that are handled on bukkit, I suppose it's possible to lag it before it even reaches the spigot.

i dont get your point

I think it's possible to mass spam packets, the netty thread on bungeecord will be lagged it even reaches the spigot.

how can you mass spam if there is a packet limit?

Spam under the packet limit with massive packets, I was more worried without the limiter.

thats not a bungeecord issue but this pr should mitigate that

I think it would be really nice to limit bytes too and maybe avoid checking instances of handler every packet.

[Outfluencer]

I mean the packets that are handled on bukkit, I suppose it's possible to lag it before it even reaches the spigot.

i dont get your point

I think it's possible to mass spam packets, the netty thread on bungeecord will be lagged it even reaches the spigot.

how can you mass spam if there is a packet limit?

Spam under the packet limit with massive packets, I was more worried without the limiter.

thats not a bungeecord issue but this pr should mitigate that

Wouldn't an external plugin be better just for this?

Too much resources for the plugin I think.

I mean the packets that are handled on bukkit, I suppose it's possible to lag it before it even reaches the spigot.

i dont get your point

I think it's possible to mass spam packets, the netty thread on bungeecord will be lagged it even reaches the spigot.

how can you mass spam if there is a packet limit?

Spam under the packet limit with massive packets, I was more worried without the limiter.

thats not a bungeecord issue but this pr should mitigate that

I think it would be really nice to limit bytes too and maybe avoid checking instances of handler every packet.

checking for the handler should make no performace decrease at all

[andreasdc]

If it can be avoided I think it's good to not do that or check it just once. What do you think about the byte limiter?

[Outfluencer]

unnecessary the packet amount limit is enought

Edit: pardon its not

[Outfluencer]

Also we dont know the lenght of the packet if its compressed, we would need to read the lenght of every compressed packet. I think thats not worth

[andreasdc]

Also we dont know the lenght of the packet if its compressed, we would need to read the lenght of every compressed packet. I think thats not worth

Incoming compressed packet?

[Outfluencer]

Yes

[andreasdc]

Yes

I don't know about such packets, but if I do it in MinecraftDecoder the bytes are already read.

[Outfluencer]

Ah yes we decompress them anyway.

But this would have no benefits for bungee.

[andreasdc]

Ah yes we decompress them anyway.

But this would have no benefits for bungee.

Won't it be good idea to avoid spam with big packets?

[Outfluencer]

Ah yes we decompress them anyway.
But this would have no benefits for bungee.

Won't it be good idea to avoid spam with big packets?

big packets are not a problem i guess

[xism4]

Ah yes we decompress them anyway.
But this would have no benefits for bungee.

Won't it be good idea to avoid spam with big packets?

Packets that are too large will simply be cancelled by disconnecting to that connection by the backend itself

[andreasdc]

Ah yes we decompress them anyway.
But this would have no benefits for bungee.

Won't it be good idea to avoid spam with big packets?

Packets that are too large will simply be cancelled by disconnecting to that connection by the backend itself

But you need the protection on the backend too and you need to listen there for every packet and check the size there too.
Great patch, many of which should have been applied earlier, but it's better later than never :D

[Outfluencer]

@md-5 what do you think about a packet amount limitation?

[md-5]

If the Vanilla server can handle it, why not Bungee?

[andreasdc]

If the Vanilla server can handle it, why not Bungee?

Weird question, also I don't think that vanilla server can handle huge amount of packets.

[Outfluencer]

If the Vanilla server can handle it, why not Bungee?

The vanilla server also has a packet limiter that is kicking the player.
Specially for the case where packets are not forwarded to the backend, the client can send infinte amount of packets and maybe lag out a netty thread.

This is the vanilla packet limiter btw

EDIT: its disabled by default (i thought its not)

If you want to we could also disable it by default but i think its not a bad idea to use a default value like 2000, it should protect against packet spam and should not false flag.

[Outfluencer]

I'll add a second check, to check for the decompressed size of incoming packets soon.

[Outfluencer]

I will heavily test the default values of 2048 max packets per second and 33554432 bytes (33MB) max data per second.
After i am done i will share my results and change defaults if necessary.

[Outfluencer]

the default limits are now 4096 packet per second and 33554432 bytes per second (33,5mb/s)
These values should filter any spam attacks for any kind of packets while not kicking legit players

I did a test on a hardcore pvp network for about 8 hours

The results where that there was a maximum amount of packets of 2737 per second. (probably a lagging player with autoclicker)
And a maximum of 60364 bytes per second, the server doesnt have big items like citybuild servers or factions, thats why i drasticly increased the max packets size to 33MB/s

but the vanilla client should never exeed these value
Only way to hit this limit is if the server gives the player an 8MB item and the player is clicking very fast on that item
BUT in all version where items was nbt the limit was on 2mb for the nbt so its also hard to achieve this values

@md-5 in my tests this fixed the issue we talked about.

[md-5]

Thanks
556a15a