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

admin at frinkel.tech admin at frinkel.tech
Wed Apr 28 19:36:48 UTC 2021

On 2021-04-28 14:55, Jonas Schäfer wrote:
> 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):
> https://tools.ietf.org/html/rfc5389#section-16.1.2
>>    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
> effort.
> kind regards,
> Jonas

This seems concerning to me. Is there really no way for an operator to 
mitigate this beyond choosing a random port and hoping no prospective 
attacker figures out or otherwise deduces which port it is?

Very Respectfully,

More information about the Operators mailing list