How to stop a COTURN Server being exploited by a SOCKs server acting as a proxy chain

Question

We have a webrtc video stream that uses our own self hosted COTURN service. https://github.com/coturn/coturn Version Coturn-4.5.2 'dan Eider'

The stream comes from internal devices and are presented to users via a web page application.

The web page application provides the user with a user name and password to access the COTURN server.

Its possible with Stunner (https://github.com/firefart/stunner) to connect to the COTURN using all the data supplied to the user (during normal operation) and setup a socks proxy server.

./stunner socks -s x.x.x.x:3478 -u username -p password -x

The conf file is setup as follows.

fingerprint
listening-ip=0.0.0.0

external-ip=x.x.x.x
listening-port=3478
min-port=10000
max-port=20000
#no-udp
no-tcp
no-tls
no-dtls
no-cli
log-file=/var/log/turnserver.log
verbose
no-multicast-peers
no-loopback-peers
denied-peer-ip=127.0.0.1
denied-peer-ip=0.0.0.0-0.255.255.255
denied-peer-ip=10.0.0.0-10.255.255.255
denied-peer-ip=100.64.0.0-100.127.255.255
denied-peer-ip=127.0.0.0-127.255.255.255
denied-peer-ip=169.254.0.0-169.254.255.255
denied-peer-ip=172.16.0.0-172.31.255.255
denied-peer-ip=192.0.0.0-192.0.0.255
denied-peer-ip=192.0.2.0-192.0.2.255
denied-peer-ip=192.88.99.0-192.88.99.255
denied-peer-ip=192.168.0.0-192.168.255.255
denied-peer-ip=198.18.0.0-198.19.255.255
denied-peer-ip=198.51.100.0-198.51.100.255
denied-peer-ip=203.0.113.0-203.0.113.255
denied-peer-ip=240.0.0.0-255.255.255.255
user=name:password
lt-cred-mech

The issue we are seeing is that we can stop the socks server processing traffic, but we cant stop people setting the server up in the first place.

no-tcp stops traffic, but still allows the creation of the socks, but no-udp stops the creation but also stops the normal functioning of the system.

Even with dynamic user creation and auth systems we still have to give users details to connect to the COTURN server and they can still abuse it (we can just see who is abusing it)

Is there a setting missing in the conf file to stop the socks exploit, or is no-tcp good enough that they can still make the socks server they just cant use it for much?

Also with udp access still open to allow for the webrtc streams is this exploitable by socks?

Answer 1

Try putting the service behind some form of gateway service and setup firewall rules to only allow the traffic to the coturn service from that gateway. Then have the gateway act as a kind of relay to pass the necessary connection information back to the client.