Secure your TURN servers against relay abuse and bandwidth theft with this comprehensive hardening guide covering Coturn configuration, credential management, and IP filtering.

Hardening Your TURN Infrastructure: Why Your Relay Server is a Secret Target

I still have the “emergency” Slack notification burned into my retinas from three years ago. It was 11:45 PM on a Friday, and rtc-relay-prod-02 was screaming. Our bandwidth egress was spiking so hard the cloud provider actually flagged us for suspicious activity. It turns out, we’d left a permissive configuration on our Coturn instance, and some “creative” actors were using our server as a free, anonymized tunnel to launch a brute-force attack on a major retailer. We weren’t just losing money on the data; we were technically the source of a cyberattack. I spent my weekend rotating secrets and rewriting firewall rules while my coffee went cold. Since then, I’ve made it my mission to ensure no one else at TechResolve—or in my network—makes those same mistakes.

The “Why”: Why TURN Servers are Security Nightmares

By design, a TURN (Traversal Using Relays around NAT) server is a middleman. It takes traffic from point A and shoves it to point B. If you don’t lock that down, you are essentially running an open proxy. The root cause of most TURN exploits is the “Relay Loop” or the “Internal Network Pivot.” Attackers love to use your TURN server to scan your internal network (the 10.0.0.0/8 range) or use your server’s IP to hide their tracks. Because the traffic is encrypted via SRTP, your standard deep-packet inspection (DPI) often won’t catch the malicious payload inside—you only see the massive spike in UDP packets.

Solution 1: The Quick Fix (The Configuration Baseline)

If you’re in a hurry because your CPU is pegged, start here. Most default Coturn installations are way too chatty. You need to disable the legacy stuff and enforce strong authentication immediately. We’re moving away from the old “plain text” feeling and forcing the long-term credential mechanism.

Pro Tip: Never, ever use --no-auth in production. I know it makes testing easier, but it’s like leaving your front door open with a “Free Beer” sign.

# Edit your /etc/turnserver.conf
# Enforce long-term credentials
lt-cred-mech
realm=relay.techresolve.io

# Disable insecure protocols
no-sslv3
no-tlsv1
no-tlsv1.1

# Limit the port range to keep your firewall tight
min-port=49152
max-port=65535

# Fingerprinting is good for debugging, but we keep it minimal
fingerprint

Solution 2: The Permanent Fix (IP Denylisting & Range Control)

This is where you stop the “Pivot Attack.” You must tell the TURN server exactly which IP addresses it is forbidden from talking to. Usually, this means every single private IP range. You don’t want a user on the public internet using your TURN server to talk to prod-db-01 on your internal subnet.

We use a strict denylist. It feels a bit hacky because you have to list every range manually, but it is the only way to be sure. Here is the standard table of ranges we block at the application level within Coturn:

In your turnserver.conf, apply it like this:

# Prevent the server from connecting to itself or internal resources
no-loopback-peers
no-multicast-peers
denylist-ip=10.0.0.0/8
denylist-ip=172.16.0.0/12
denylist-ip=192.168.0.0/16
denylist-ip=169.254.169.254

Solution 3: The ‘Nuclear’ Option (Ephemeral Tokens & DMZ Isolation)

If you’re running a high-scale app, static usernames and passwords in a config file are a death sentence. The “Nuclear Option” involves two steps: moving the TURN server into a completely isolated DMZ VPC and using Time-Limited REST API credentials.

With this setup, your frontend app requests a short-lived token from your backend, which generates a credential valid for only 24 hours. Even if a “bad actor” scrapes the credential from the client-side code, it’s useless by the next day.

Warning: Implementing the REST API auth requires a shared secret between your backend and the TURN server. Keep this secret in a Vault—do not hardcode it in your deployment scripts.

# Use the REST API secret instead of static users
use-auth-secret
static-auth-secret=your-ultra-secure-uuid-here

# Force the server to listen only on a specific public IP
external-ip=203.0.113.45

By isolating the server at the network level (VPC peering disabled) and using ephemeral tokens, you’ve turned a massive liability into a robust piece of infrastructure. It’s a bit more work up front, but trust me, your Friday nights will be a lot quieter.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions