Hi guys.
As a lot of you know, exploters can do this:
local Crasher = string.rep("Crash", 10000)
while true do
for i = 1, 10000, 1 do
SomeUnsecuredRemote:FireServer(Crasher)
end
task.wait() --to not crash ourself.
end
This will overload server and cause a lot of problems, if we won’t handle that.
But will this work with unreliable remote events? I know that I need secure them too, but IDK if I should make fire rate limiter for it - maybe it will fail on itself if overloaded?
The #1 rule while developing the game is to NEVER TRUST THE CLIENT.
So yes, you need to secure anything that talks between the server and the client. RemoteEvents, RemoteFunctions, e.t.c need sanity checks on the server.
You can stop exploiters from causing your remote event handler code from throwing errors on the server side but you can’t do anything to actually stop data being sent to the server from a client. An exploiter could totally eat up all the bandwidth available to the server but that never happens in our game plus you can’t do anything as a developer to stop it anyway. We just get the standard speed and fly hacks. No server crashes.
I like to ratelimit my RemoteEvents and UnreliableRemoteEvents, then if the user is sending above the ratelimit, I usually flag the user (not automatically kick/ban, as regular users could sometimes set off false flags, like spamming a interaction (to prevent this I would use debounce on both client and server)
This is a decent way to prevent this, if not the only way.
Actually we can, and this thing called Rate limiting.
For example, let’s assume that we have custom inventory system. Player can equip/unequip items from it with use of remotes.
We can limit amount of possible calls to like 600 per 10 seconds.
Ofc, there will be some stupid people which will try to just spam switch tools for fun, but giving such “big” numbers will allow to handle even them, while exploiters will be able to exceed this limit and get detected → kicked.
As the article that was posted on UnreliableRemoteEvent release states:
There are a couple of things to keep in mind when using UnreliableRemoteEvents:
There is no ordering guarantee between UnreliableRemoteEvents and anything else. UnreliableRemoteEvents may be processed in a different order than they were sent.
UnreliableRemoteEvents may be dropped to prioritize bandwidth or CPU usage in addition to any loss that occurs over the network.
UnreliableRemoteEvents may be dropped to prioritize bandwidth
It should automatically rate limit it at some point and discard extra fires.
Big issue when you dont secure the events in some way is hackers just triggering them when they want, so if it is connected with currency in an incremental for example you are cooked, they can do whatever they want. Basicly dont let them trigger any event that can cause you harm, like ban remote event if you would use it for any reason
This is only applicable to events that you yourself fire. There is nothing you can do to prevent an exploiter firing a remote event with their own malicious code, but you can use rate limiting to identify them
and kick them.
Just make it on client side that you cant send more than rate limit.
And if rate limit is reached on server just straight up ban them.
Be very careful doing that tho.
what i decided to do is lock an logics question behind every event so for example when i trigger “upgrade” remote event all calculations are done on server, so even if a hacker sends remote event they cant do anything as server will check their values