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.
>
>
> DESCRIPTION
>
> 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,
Holly
