Defend the public space

[mcfnord]

I believe our community is Jamulus’s most compelling feature. Ease-of-use is very compelling, reliability is very compelling, but ease of collaboration with strangers, especially over a long time frame (both in hours and years), is the strongest, most compelling feature and differentiator for us.

The geographically diverse, long-running servers provided by our volunteers are a key ingredient of that feature.

Over about a year, I have observed the development of code that can:

1. Send a chat to every public server.
2. Fill up every public server with connections.
3. Insert audio on every public server (same as any connection).
4. Draw from a vast supply of IP addresses.

If used maliciously, this code represents an existential threat to our public community.

Thankfully, we can eliminate most of this threat.

Most malicious code reaches our servers from "anonymizing" networks like Tor or VPNs. These networks provide many unique IP address subnets, and are often used for abuse and evasion, but they all come with high latency, so they’re never used by genuine musicians for music-making.

By excluding ASNs known to support anonymized traffic, we can dramatically reduce the risks posed by malicious connections.

[ann0see]

I fear that we could block valid users too.
Best we could fix something in the Jamulus code.

[mcfnord]

I cannot imagine a valid use case for these networks. I know one person who uses them to listen, but I don't know why, or why they don't use their native ISP. I'll ask.

I'm not sure what you mean by fixing something in the Jamulus code. An IP-ARN mapping could be embedded statically, though I'm concerned it will age quickly. I think @DrBrad publishes one.

I use the service at http://ip-api.com/json/185.199.111.153, but it would make more sense to implement https://github.io/screen/185.199.111.153. Jamulus Servers could cache results, and just proceed without screening if the endpoint is down.

I've written a Python script that monitors the journalctl log and blocks an IP from a prohibited ARN using an iptables command. I think I'd have a better user experience if Server gave my script prior notice of a proposed connection, so I can block it earlier. Maybe I just need to add one log line plus one tiny delay to Server.

[DrBrad]

I believe your talking about ip to asn not arn. But the purpose for this is because we dont know if someone is spoofing an ip and asn checks will stop ip spoof attacks.

[NickVeit]

After receiving annoying spam text several times in our server, I reached out to the alleged sender who claimed to be recording and offered false ways to prevent the annoyance.

I now understand, from a pleasant email reply, that the alleged sender is also a victim of these "attacks".

Our musicians would really appreciate a method of blocking this on our Linode-hosted Ubuntu server.

[DrBrad]

These are the methods i would use:

Cookie and session everything if its a custom protocol.

• elaborations
  Force a cookie that stores a session token
  If the key doesnt exist dont reply just give a session token
  Block anon vpn ips like mullvad and proton
  Block tor exit nodes
  Use async for each response dont single thread
  Bloom filter ip packets IE dont allow more than 5 packets per ip per second
  Deny any unusually formed packets

[NickVeit]

Thanks. I just operate a server. These technical terms are probably for developers not users like me suffering the invasion.
Perhaps someone can take this advice and turn it into a usable solution?

[mcfnord]

Update: The threat actor began "outrage farming" about a week ago, spamming chats of active servers and attributing the spam to me. I know the threat actor's networks because he has attacked my servers persistently over two years. I see this as a hardening opportunity, so I haven't said much about it in this forum. However, this new phase of provocative chat spamming crosses a line by seeking to hurt a much larger audience, while operating in an unblockable way using multiple IP addresses, listed above as attack vectors 1 and 4.

Based on @ann0see 's concern about blocking valid users, I began examining all traffic reaching public servers from the 8 networks routinely used by this threat actor. Today I found a Filipino pianist/drummer who uses one of the networks. He said his latency is 250ms without the VPN, and just 50ms with it, so the VPN bypasses bad routes. This makes blocking entire networks more risky, but it also reveals which commercial VPN the threat actor might use. One interesting detail: "I snatched a lifetime deal a few years ago with them." If the threat actor also has a low-price lifetime deal, it would be sad if they lost it for abusing people at scale.

Have Jamulus operators approached VPNs in the past seeking to stop abusive behavior?

[NickVeit]

Thanks MFCNORD. I don't understand the weird way a Linode host firewall blocks IPs with Jamulus (it is certainly not immediate and it perhaps makes the server invisible in the list of servers?).

As valid users don't use VPN for Jamulus, I'd love to try and block the VPN provider's entire range if we can identify it/them.

Last night I noticed no such "attack" so possibly it is being done manually on busy servers rather than routinely?

[DrBrad]

I can send you a list and show you how to implement this if you would like.

[NickVeit]

DrBrad, I would be very grateful, thanks. If email is easier, I am on goodcompany@btinternet.com.