[Operators] STUN/TURN servers are being abused in DDoS attacks (even with auth enabled)

Jonas Schäfer jonas at wielicki.name
Wed Apr 28 18:55:13 UTC 2021

Hi Philipp,

Thanks for you reply.

On Mittwoch, 28. April 2021 20:21:09 CEST Philipp Hancke wrote:
> Am 28.04.21 um 17:37 schrieb Jonas Schäfer:
> > Hi fellow operators,
> > 
> > TL;DR: STUN/TURN servers are vulnerable to abuse to facilitate reflected
> > amplified DDoS attacks even with authentication enabled. Roll a few dice
> > and choose a random port number for your STUN server for the better of
> > the internet.
> > 
> > 
> > 
> > With the advent of widespread A/V calling support in client connections,
> > many of us have deployed STUN/TURN servers.
> > 
> > Because of inherent flaws in the UDP, STUN and TURN protocols, STUN/TURN
> > servers are easy to detect and to abuse in Distributed Denial of Service
> > attacks.
> > By using source IP address spoofing [1] and exploiting that UDP is
> > connectionless, attackers can make the STUN server send traffic to
> > arbitrary IP addresses via an reflected attack [2].
> which is described in
> https://tools.ietf.org/html/rfc5389#section-16.2.1, no?

No, not quite. As I read it, that one describes a malicious STUN server which 
replies with forged addresses to make STUN *clients* send traffic to targets 
of the server’s choice.

The attack I am talking about is described in 16.1.2 (inside attacks):

>    A rogue client may use a STUN server as a reflector, sending it
>    requests with a falsified source IP address and port.  In such a
>    case, the response would be delivered to that source IP and port.
>    There is no amplification of the number of packets with this attack
>    (the STUN server sends one packet for each packet sent by the
>    client), though there is a small increase in the amount of data,
>    since STUN responses are typically larger than requests.  This attack
>    is mitigated by ingress source address filtering.

I love how they say it is mitigated by ingress source address filtering, which 
is sadly still not deployed throughout the internet :( and nothing any single 
operator can do anything about.

> > In some cases, the response of the STUN server will also be larger than
> > the
> > request sent by the client, adding an amplification [3] factor to it.
> which from what I can see is less than two and can be brought closer to
> 1 with minimal tuning.
> Why do you think that is attractive as an attack vector?

I have no idea.

The UDP payload is (with a default coturn installation) only amplified by 
factor 5 (20 bytes request payload, 100 bytes response payload), which makes 
for something like 2.7 (48 bytes in, 128 bytes out) when looking at the entire 
IPv4 packet.

There are much more lucrative targets out there in the internet which are much 
harder to shield.

And yet: I do see live attack traffic on my server on port 3478. I am certain 
it is attack traffic based on the behaviour and specifics, but I won’t go into 
details on a public mailing list (feel free to contact me off-list though).

I also know that other operators see the same issue on their STUN servers.

The cost of relocating your STUN server to another port is small, especially 
if it’s only used by an XMPP service. IMO, the amount of mitigated attack 
traffic (even if it’s just a few kbps per STUN server) is worth that little 

kind regards,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/operators/attachments/20210428/864c4267/attachment.sig>

More information about the Operators mailing list