Security of a TURN server

[Eirikr70]

Hello all you Wise Experts of the TURN World,
So here is my question. I have set up a TURN server with Coturn. In order to achieve that, I have open ports 3478 and 5349 on both UDP and TCP, and the range 49152-49272 on UDP.
How can I make this setup secure ? Usually my services stand behind an Nginx revese proxy, itself being secured by Corwdsec. But I don't know how I should manage my TURN server in terms of security. Any hint ?

[eakraly]

This is a very broad question.
Each company, system, requirements, use-case, and team are different and the answer should take that into account.
As such it is hard to provide you with a recipe. Also, I am not a security person - so take my recommendations with a lot of scepticism.
I can ask a few guiding questions that will help you find the answers for your use-case:

1. What are the attack vectors that you want to prevent? This will guide you into looking into scenarios, how they apply to turnserver, and what you may do to prevent the attack (or make it unfeasible, expensive, etc).
2. What are you using turnserver for? Is it a classical WebRTC relay between 2 public internet clients? Or is it a public internet client connecting into an internal service through turn? Or something else?
3. What is your infrastructure setup? If you consider turn servers dangerous - can you segregate them from the rest of the infra (so that if turn servers are compromised - there is nothing valuable there except turn servers)? Using "REST API TURN" credentials and prometheus monitoring helps with that.
4. Are you running your own hardware in your own data center, or are you running on a cloud provider? Do you use bare metal or containers? Kubernetes? Different setups require different approaches and have different risks. Also, each one of them have their own best practices.
5. I think this is the only turn specific advice: make sure to block internal IPs (that you do not want access to). See https://www.rtcsec.com/article/cve-2020-26262-bypass-of-coturns-access-control-protection/ article.

I hope others can contribute.

[Eirikr70]

Thanks a lot for writing such a detailed answer.
As for your first question, my setup being selfhosted on my own hardware and limited to the extent of my family, but hosted together with other services (photos, passwords, ..., each of them in separate containers). My main concern would be

• that an attacker might access other data in other containers,
• that malicious software might infect my setup,
• that my server might be used as a badbot.
  My turn server is meant to allow communications between members of my family (and maybe friends in a future), mainly all ends being out of the LAN, sometimes one of them inside of it.
  As I said, my other services are hosted in other containers, but on the same server. I might consider deploying the turn server on another host, which would give it an additional layer of security.
  For the link you sent to me, it helps me in understanding how specific is the technology of a turn server and thus the dedicated risk mitigations, and that I shouldn't think about it in terms of the usual reverse proxy and intrusion detection system. The main point remaining is I see that I can't deny all 192.168.x.x addresses, but I can hardly figure out which ones I should leave open, since they are dynamically affected by Docker, and I suppose that leaving them all open leaves me at risk.
  EDIT : got that last point fixed with the creation of a dedicated Docker network.
  Thanks a lot !

[eakraly]

For docker container there a few tricks you can use to reduce the risks:

1. Use latest version of coturn, of course - there were a lot of memory related fixes. Should be released as part of 4.7.0 but if you can use master this should be enough
2. Run coturn container in read-only mode - that would prevent (or make harder for) attacker to download and install additional software or run scripts. If there is no curl/wget/python and FS is RO - running anytihng becomes much harder
3. Do not run as root - drop all permissions except what you need (only network access). You do not even need binding to 443...
4. Good trick with dedicated docker network - that is exactly "segregation" I meant...

Also, short lived secrets - I assume an external client cannot just get one so it also adds another layer of security

[henriquebol]

Enjoying the excellent topic. Here we use coturn with bigbluebutton.

Due to company policy regarding security, we will have to close port 3478 (UDP). They want to avoid udp ports with STUN exposed to internet.

Does the Turn server still work only on 3478 (TCP)?

Any idea what we can do?

Thanks!

[eakraly]

TURN will work with TCP - should be no problem with that
Moreover, using TURN with TLS may give you even better compatibility with firewalls as it will look standard TLS from the outside (even using 443). Use turns:turn-server.address.com:443 for that.

[Eirikr70]

So, I have to say a big thank you for answering so kindly !
What I have done

• dedicated docker network and extended blacklist according to the example,
• last version of Coturn (that was my default),
• read-only mode,
• withdrawall of any capacity apart from NET_BIND_SERVICE and NET_RAW,
• cheked that I was not user root (I appear as user nobody, I guess it is the default).
  I think my server is now quite hardened thanks to you.