STUN server misuse

Looks like someone pointed their client base at our STUN server, average usage went up from about 10 Mbps on average to about 100 Mbps on average over the last couple of weeks.

If you’re reading this, can you please not? :grimacing:

3 Likes

Do we know what region the clients are connecting from? This may help to trace the origin.

1 Like

Here’s the packet count by first three octets of the source addresses of clients for about 30 seconds of traffic, sorted:

https://cdn.kastelo.net/tfi/30-sek-ips.txt

There’s a lot of Chinese networks at the bottom.

Would it make sense to drop or tarpit STUN connections that don’t coincide with an IP visible in the Global Discovery servers list? I’m no expert on STUN or Syncthing’s public infrastructure, so if this is a bad idea for some reason, it won’t hurt my feelings.

1 Like

That was one of my thoughts as well. Apart from it being a big and churning list of addresses, STUN will predate the announcement to discovery, since that address is supposed to be in the discovery, so there’s a chicken and egg problem.

That said, I think we mainly use STUN for port discovery? The source address seen by the discovery server should be the same as for the STUN packets presumably, even before STUN is completed… Maybe this would in fact be a workable mechanism, even though it’s a bit heavy handed…

There’s an authentication field we could use in STUN, and we could set a client ID and filter on that, but that’s only effective for new clients…

(There are quite a few packets with a client ID that’s not Syncthing though, StunClient which is the default for at least the Go STUN library, but most seem to be using blank client ID like Syncthing currently does…)

1 Like

Adding a drop rule for Chinese sources skips about 65 % of the traffic.

root@stun:~# iptables -L -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
4840K  288M DROP       all  --  any    any     anywhere             anywhere             match-set china src
2646K  156M ACCEPT     all  --  any    any     anywhere             anywhere
1 Like

Doing a github code search shows quite a few projects and libraries using the syncthing servers. Because there are libraries using it, there may be projects using those servers without even realizing.

1 Like

Yeah. I don’t mind the ones having it as one entry in a big list of STUN servers, we kind of do that as well, but the ones using just stun.syncthing.net is a bit :frowning_face:

2 Likes

Dropping incoming from China has brought our outgoing traffic down to under 20 Mbps which is a significant improvement. Unfortunately this leaves Chinese Syncthing users without access to our STUN server, but there are others they can use… Clearly I realise the hypocrisy of this, nonetheless we do need to keep the infrastructure running in a reasonable way.

1 Like

Should we add some china based STUN servers to our list? I fear that most of our default servers are blocked by the Great Firewall.

e.g:

2 Likes

Sure, why not.

1 Like

I tested a few services for Add China-based STUN servers · Issue #9842 · syncthing/syncthing · GitHub and came across this one:

stun.cdnbye.com:3478

It came up pretty often when looking for STUN servers in China. Now comes the fun part:

https://dns.google/query?name=stun.cdnbye.com

They’re pointing to stun.syncthing.net using a CNAME :clown_face:

7 Likes

fucks sake

4 Likes

A “could you fucking not?” mail might or might not help.

2 Likes

Oh the irony :grinning:

2 Likes

Wonder if they’re actually using Syncthing under the hood? :slight_smile:

1 Like

I know what you’re thinking and you really should.

1 Like

According to them, “[SwarmCloud is] Powered by WebRTC”.

Sorry for the n00b question, but are you sure these connections are coming from Syncthing, and that they’re just not some misconfigured program/system doing regular HTTP(S) requests?

Neither.

STUN is a protocol that allows something behind a NAT device (typically a firewall) to discover its public IP address.

The nice people (not me, I don’t know who they are) who host the Syncthing infrastructure host some STUN server architecture, but without using any authentication at this time.

In other words, this big increase in traffic and load is coming from freeloaders who are using Synchthing’s infrastructure to do something else.

1 Like