Does it make sense to secure the net.Receive?

Does it make sense to protect the net.Receive in case of spam from the client? For example, a simple notification of this to active administrators. Or does gmod by default have protection against abuse of the network channel, and there is no point in worrying about unnecessary requests?

1 Like

It always depends on what kind of logic you run in your receiver. I tend to just have some kind of quick permission check, cooldown or a Debouncer.

1 Like

Imagine if all the “net.” things are on players screen and they can send it how many times as they want / tweak values however they want.
Now do as much protection/checks on the server side as needed. Reason - it is not hard at all to inject any lua code client side and abuse it.

1 Like

Generally you don’t need it, the only times I’d consider adding one is if a cooldown is already present on the client or the function doesn’t really have any noticeable effect (making it obvious if someone is spamming it) and is doing a significant amount of processing on the server.

Definitely do permission/argument/sanity check everything though, those are a lot more important.

1 Like

Even with very simple logic in your receiver, if I am able to make it throw an error (by sending an invalid type for example) then it’s a vulnerability as the error will be written onto your disk (log file) which causes the server to freeze (when spammed). This is also the reason why you should not use net.ReadTable() serverside at all or at least only if the receiver is protected.

1 Like

There are no problems with the validation of the received data. It just suddenly became interesting how this kind of spam is critical for the server, even if the request does not pass the validation check and does not start processing the functionality.

1 Like

You probably shouldn’t be running a live server with lua_log_sv 1 and especially not with -condebug if you’re that concerned about people intentionally writing garbage net messages in order to spam your error log.

1 Like

I have it disabled but it is enabled by default, that’s why I thought its important to mention it.

1 Like

It’s not enabled by default, either you’re mistaken or your server provider is setting it.

2 Likes

no clue, ask the people who were affected by it. someone reported it to me back then.

1 Like

In response to your particular question:

  1. Don’t do expensive checks to validate requests. No SQL, no file access, nothing that may take any significant amount of time. Then you’re probably safe from DoS via this particular method.

Some extra rules of thumb:

  1. Always assume the client is malicious and wants to break your shit.
  2. Always assume the client is lying.
  3. You might want to preemptively ban/kick players who are exhibiting extremely strange behaviour (too many requests, too many access check failures, anything that might indicate an attempt to break your shit). This reduces their window of opportunity to look for vulnerabilities.

Another interesting artifact of gmod’s networking is that it’s severely rate-limited under default network settings and suffers from head-of-line blocking. This means that if a client is able to perform an action that results in data being sent to other clients (e.g. rebroadcasting a player’s action to all other players), then that single client can (maliciously) starve the network channels for the entire server. What happens then is that all networked traffic gets buffered up and virtually all networked events suffer extreme delays.

EDIT: An example of that vulnerability could be exploited via Wire’s E2 holograms. You could make an E2 chip that creates a bunch of holos and repeatedly changes their model scale (which is transmitted over the auxiliary net. channel, and not the other source channels for entity data), which would cause the above behaviour to occur. It could get so bad that even chat messages would take about 60 seconds to be sent, undos wouldn’t work, basically anything else that used gmod’s networking.

7 Likes

Yes, securing the net.Receive() callback makes complete sense.

You want to make sure the data received is not malicious and also to make sure that you’re not being spammed too. Implement everything you can to secure it, and implement it in a way so that you dont have to call it too often :smiley:

1 Like

Technically if you don’t use poor scripted add-ons it shouldn’t be a problem.

1 Like