DEV Community

andreagomez
andreagomez

Posted on

Coturn exposure: an unauthenticated TURN server is a relay, not a discovery endpoint

#zoomeyearticle #security #defensiveanalysis

Coturn exposure: an unauthenticated TURN server is a relay, not a discovery endpoint

Coturn is a STUN and TURN server that relays media for WebRTC and other NAT-traversal workloads. Its reachable ports are part of normal operation. Authentication determines whether an arbitrary client can use those ports to relay traffic.

On 2026-10-31 at 21:56 UTC, one count-only ZoomEye query returned 8,186 matches:

app="coturn" || title="coturn"
Enter fullscreen mode Exit fullscreen mode

The query used sub_type=all, page 1, and page size 1. It does not establish that a matching service is anonymous, misconfigured, or using coturn rather than another TURN implementation. The count is an inventory clue.

Authentication is not enabled by implication

The coturn turnserver manual page documents -a/--lt-cred-mech for long-term credentials, -z/--no-auth for anonymous access, and the REST credential option. It states that no credential mechanism is used by default when no authentication-related option is set.

That makes the effective configuration the primary question. A deployment that needs authenticated relay should verify it is using long-term credentials or a supported shared-secret mechanism. The coturn README describes classic long-term credentials, the TURN REST API, and an experimental OAuth option.

Do not rely on a client's configuration alone. The server must reject an unauthenticated allocation attempt when authentication is required. Test the TURN protocol path as well as the TLS login page and HTTP status.

Protect the REST secret

The coturn configuration reference includes options for authentication, TLS, relay ranges, and monitoring. The turnserver manual describes a static authentication secret for the TURN REST API and derives credentials from a timestamp and user identifier.

Store the shared secret outside the web client. Rotate it with a coordinated update to the service that mints TURN credentials. Use a bounded credential lifetime and confirm that an expired credential fails. Do not publish the secret in a frontend bundle, a repository, or a support transcript.

Restrict the relay address range and exposed media ports to the deployment design. Review whether the metrics or telnet management listener is exposed with the TURN service. The coturn project README describes Prometheus metrics as a build dependency and the project as a TURN/STUN gateway, so a broad network rule can expose more than media.

Test with the actual protocol

Use a controlled coturn instance and a test credential:

  1. Request an allocation without credentials when auth is required.
  2. Request an allocation with a valid credential.
  3. Try an expired REST credential.
  4. Try a credential for an unexpected user or realm.
  5. Verify the permitted relay address range.
  6. Check the source network allowed to reach the TURN port.

Do not print passwords or the shared secret. Record the protocol, realm, source network, credential type, and result. Test both TCP and UDP where the deployment advertises both.

The 8,186 matches can help identify TURN infrastructure outside an asset inventory. They do not prove anonymous relay. The answer comes from the running configuration, credential test, and firewall review on the organization's own deployment.

Operational checks

Keep the TURN service patched and its configuration under change control. Alert on anonymous auth flags, new exposed listeners, shared-secret rotation, and a relay address range that is wider than intended. Test the authentication path after every configuration change and before publishing a new WebRTC service.

References

Top comments (0)