Mitigating TURN Amplification Attacks

The WebRTC ecosystem recently faced a new challenge as TURN servers became targets for large-scale reflection and amplification attacks. These attacks exploit a fundamental “misfeature” of the TURN protocol to launch denial-of-service attacks on remote victims, without the attack being traceable back to the origin. In this post, we’ll explore how these attacks work, measure their impact, and demonstrate a practical mitigation we’ve implemented in the popular pion/turn project.

The Anatomy of TURN Amplification Attacks

The below is a brief summary for the attack on TURN/UDP, see here for the technical details.

TURN (Traversal Using Relays around NAT) servers are an essential infrastructure for WebRTC applications, helping clients establish connections when direct peer-to-peer communication fails due to NAT or firewall restrictions. However, two key properties of TURN servers make them vulnerable to abuse:

Reflection: By design, TURN servers send UDP responses back to the source IP address of incoming requests. When attackers spoof their source IP, they can redirect these responses to any target they choose.

Amplification: TURN error responses are typically larger than the corresponding requests since they must include possibly long NONCE and REALM attributes for proper RFC-compliant authentication.

The attack flow is straightforward: an attacker sends small, spoofed TURN allocation requests to a server, which then sends larger error responses to the victim’s IP address. The amplification factor determines how effective the attack is: the higher the ratio between response and request size (the amplification factor), the more attractive the TURN server becomes as an attack amplifier.

Measuring the Problem

To understand the scope of the issue, we developed a small measurement tool that sends unauthenticated TURN allocation requests to a remote TURN server and analyzes the amplification factor by collecting the responses.

Our initial tests yielded amplification factors ranging from 4.22x for a proprietary public TURN server to 3.44–3.22x with the default pion/turn server and 2x — 2.5x for the popular coturn implementation. The exact factor depends on the specific configuration of the TURN server, e.g., the REALM size, software attribute length, etc. For instance, the default pion/turn server uses 80-byte NONCEs and a 7-byte REALM by default, yielding 124 bytes response for a request of 36 bytes. This means that an attacker with limited resources (say, with a 1 Gpbs spoofed TURN request stream) can launch a denial-of-service attack on a remote victim at a much higher rate via a vulnerable TURN server (i.e., 3 Gbps attack rate for the amplification factor of 3x). Note that this does not require the attacker to obtain valid TURN credentials: the attack uses the initial handshake mechanism that precedes authentication in the TURN connection setup phase and hence needs no credentials.

Mitigation: Configurable NONCE Sizes

We implemented a targeted mitigation in pion/turn. Our PR #460 introduces configurable NONCE generation with several optimizations:

Shorter timestamps: 4-byte timestamps at one-minute precision instead of longer formats. Truncated HMAC: 12-byte truncated HMAC by default, instead of full-length hashes. Efficient encoding: Optimized base36 encoding with reduced padding. Configurable size: Default 24-byte NONCEs (including encoding overhead) instead of 80 bytes.

This approach maintains cryptographic security while significantly reducing the attack surface.

In order to test the efficiency of our mitigation on pion/turn, we conducted a large-scale measurement campaign. Below is a short summary.

|-------------------------------------|----------------------|
| Server                              | Amplification factor |
|-------------------------------------|----------------------|
| undisclosed proprietary TURN server | 4.22x                |
| pion/turn (default)                 | 3.44x                |
| pion/turn (no realm)                | 3.22x                |
| short-nonce (default)               | 1.89x                |
| short-nonce (no realm)              | 1.44x                |
| short-nonce (maclen=2, no realm)    | 1.22x                |
|-------------------------------------|----------------------|

For pion/turn in particular, our mitigation reduces the amplification factor from 3.44x with the default server configuration down to 1.44x (using an empty REALM). Security savvy people can also set a custom NONCE size and recompile the server code, which can reduce the amplification factor to 1.22x. This should be enough to make TURN less attractive to attackers.

Our change has now been merged into the pion/turn master branch. However, this is just the first step. Beyond NONCE size optimization, several complementary strategies can help further mitigate amplification attacks, e.g., implementing per-source-IP rate-limits on unauthenticated requests, removing optional attributes (like SOFTWARE) from error responses, using very short realms, etc. There are ideas for changing the TURN protocol as well, like adding padding to Allocate Request messages of legitimate clients to reduce amplification below 1.0x, or using alternative TURN authentication and handshake mechanisms.

Conclusion

TURN amplification attacks represent a real threat to the WebRTC ecosystem, but the attacks are not insurmountable. Through measured analysis and targeted optimizations, we have demonstrated that significant improvements are possible. The measurement tool we have developed is freely available for the community to test their own deployments and verify the effectiveness of various mitigation strategies.

One final note: the above mitigation has been available immediately after the public announcement of the issue in the enterprise edition of our popular STUNner TURN server implementation, and it will included in the upcoming open-source release as well. If you’re interested in exploring what STUNner has to offer for your WebRTC service, feel free to reach out to us at L7mp.io!