How to stop "TURN" service

[nebulon]

@p44 agreed it looks like at least some throttling or rate-limiting is required.

So far there is no logic yet to start services on-demand based on the apps installed.

[girish]

You can docker stop turn that will stop the service if you don't use it. But you have to do this on every server reboot.

[d19dotca]

@girish @p44 - Thinking out loud here, I guess the workaround would be to run docker stop turn and then stick that in a cronjob on the server to run on boot, assuming it runs after the turn container is actually running. That way you don't have to remember to do that after every boot.

[p44]

@nebulon @girish @d19dotca Thank's a lot @d19dotca ! For me is a little bit complex append that command in cronjob and I don't know if Cloudron make some integrity test at boot time to try to check if turn is on or off.

Another solution is to use VPS provided firewall to lock that doors... But as @nebulon wrote, one improvement could be add rate-limiting and/or start that services on demand.

Thank's all for your answer

[crazybrad]

@girish @nebulon @james I am seeing a flood of unauthorized attempts to connect to the TURN server on each Cloudron. I have no apps installed that are using TURN. It seems like a potential security vulnerability and certainly a waste of CPU/RAM (256MB Cloudron min)/Disk resources. One TURN log was already up to 50MB! In the absence of a "switch" in Cloudron to disable this, I wanted some advice on two temporary solutions:

(1) docker stop turn coupled with docker update --restart=no turn

(2) Adding a crontab entry: @reboot /usr/bin/docker stop turn

Option 1 prevents the container from starting. Option 2 allows it to start, but stops it when rebooting. @d19dotca Thanks for starting my thinking on this!

Option 1 seems better, but I wanted an expert opinion on the consequences of using either.

Lastly, I guess I will need to be aware that installing any apps that require the TURN service could fail (unless I enable the TURN container once again). If I forget and install an app like Jitsi, will Cloudron restart the TURN container and revert the --restart=no option?

[joseph]

256MB is the max limit and when not in use linux will just swap it out. As for the logs in the big scheme of things, 50MB is not much.

That is not to say this is not a problem. @crazybrad what kind of log messages are you seeing? It's the nature of the internet that publicly exposed services can be accessed. The TURN server is public and has to be. Do you have a firewall? It's easiest to just block it there if it bothers you. The ports to block are:

    TURN_PORT: 3478, // tcp and udp
    TURN_TLS_PORT: 5349,  // tcp and udp
    TURN_UDP_PORT_START: 50000,
    TURN_UDP_PORT_END: 50100,

[crazybrad]

@joseph What I see appears to be "normal" attempts to connect to a TURN server. The problem is that there is no application "publishing" my TURN server to make it usable by potential WebRTC connections. So these are people trying to leverage a misconfigured TURN server or a software vulnerability. In my mind, it's no different than people probing to SSH to a server - hence the reason to use Fail2Ban and other tools to restrict this.

Since Cloudron manages "allowed ports" internally, I think that TURN server ports should be added to that list as follows:

(1) If an app requires TURN server access (it should be declared in the app manifest), then TURN ports should be opened)
(2) If no apps use TURN, then those ports should be closed by CLoudron automatically.

[joseph]

@crazybrad yes, I think that's a good approach. Not opening ports unless needed is a good security measure.

[crazybrad]

@joseph is this a security enhancement that the Cloudron team can add to a future maintenance release? I would prefer to have Cloudron maintain control of the TURN service so it could enable it based on installed dependencies or leave it off if there are none. Much safer and won't create support issues if someone has disabled TURN ports themselves and then forgets to manage this properly externally.

[girish]

@crazybrad I think that would be ideal yeah. I can look into it. Can you make a feature request thread?

[dbruehlmeier]

We're seeing a similar issue and our server was even temporarily blocked by our hosting provider. I agree with @crazybrad that it would be preferrable if Cloudron would maintain control of the TURN service, based on the actual needs of installed apps.

[crazybrad]

@girish @dbruehlmeier Will make a Feature Request thread.

[joseph]

Link to feature request . Thanks @crazybrad