central defense by ASN or IP4 mask

[mcfnord]

feat(server): Add CentralDefense for ASN/CIDR blocking

This introduces the CentralDefense module, a server-side security mechanism designed to reject connections from specific Autonomous Systems (ASNs) and IP ranges (CIDRs). This allows a central service to filter out traffic from known abuse sources.

Key Implementation Details:

1. synchronous "Bouncer" Logic:

   • Hooks into CServer::OnNewConnection immediately after the mutex lock.
   • Uses Qt::DirectConnection to ensure the block check completes synchronously.
   • If a client is blocked, the connection is dropped before the server sends the "Welcome" message or updates the connected client list.

2. API Protection & Throttling:

   • Integrates with ip-api.com for ASN lookups but implements aggressive protection for the API provider.
   • Memory-First: Checks a local RAM cache and static CIDR list before attempting any network lookup.
   • Queuing: Limits concurrent requests to prevent bursts.
   • Throttling: Enforces a delay between outbound requests to respect API rate limits.
   • Negative Caching: Caches lookup results (allow or deny) to ensure subsequent connections from the same IP require zero network traffic.

3. Configuration:

   • Fetches a remote blocklist (ASN/CIDR format) on startup and refreshes periodically.
   • Parses blocklist entries robustly, ignoring comments and descriptive text.

Checklist

• I've verified that this Pull Request follows the general code principles
• I tested my code and it does what I want
• My code follows the style guide
• I waited some time after this Pull Request was opened and all GitHub checks completed without errors.
• I've filled all the content above

[ann0see]

Thanks!

ip-api.com

I'd prefer not to hardcode services.

[ann0see]

Very interesting! Thank you.
I believe that we'll have a long discussion here...

[ann0see]

You should write the code generic such that it supports ipv6 too

[stefan1000]

I’m concerned about moving network defense into an audio application, especially via a centralized blocklist. Beyond the performance overhead, this creates a central point of failure and raises privacy issues by sending client IPs to external APIs (once again).

These 'wrecking ball' blocks (ASN/CIDR) risk significant collateral damage and are more precisely managed at the firewall level. Furthermore, the governance of a central 'bad actor' list is an unsolvable problem for a decentralized project—it creates a gatekeeper role that doesn't belong in the Jamulus audio engine.

[softins]

I’m concerned about moving network defense into an audio application, especially via a centralized blocklist. Beyond the performance overhead, this creates a central point of failure and raises privacy issues by sending client IPs to external APIs (once again).

These 'wrecking ball' blocks (ASN/CIDR) risk significant collateral damage and are more precisely managed at the firewall level. Furthermore, the governance of a central 'bad actor' list is an unsolvable problem for a decentralized project—it creates a gatekeeper role that doesn't belong in the Jamulus audio engine.

I would agree. While anyone is free to create their own fork with modifications to support their use case, I'm not convinced this kind of functionality belongs within Jamulus itself.

[softins]

Aha! This would explain why Jamulus Explorer is no longer able to display City, Version, OS and connected clients for the "Duet" server that exists in each genre:

[ann0see]

the governance of a central 'bad actor' list is an unsolvable problem for a decentralized project—it creates a gatekeeper role that doesn't belong in the Jamulus audio engine.

While this is true, we should still think about:

1. How can server admins protect their server from bad actors? There could be valid reasons for this.
2. Server admins should be able to protect themselves from known bad actors - E-Mail servers for example have shared (configurable) blacklists.
3. Can users themselves be enabled to block (?) bad actors? Potentially just for themselves?

[rdica]

the governance of a central 'bad actor' list is an unsolvable problem for a decentralized project—it creates a gatekeeper role that doesn't belong in the Jamulus audio engine.

While this is true, we should still think about:

1. How can server admins protect their server from bad actors? There could be valid reasons for this.
2. Server admins should be able to protect themselves from known bad actors - E-Mail servers for example have shared (configurable) blacklists.
3. Can users themselves be enabled to block (?) bad actors? Potentially just for themselves?

All great examples for implementing @Rob-NY RPC firewall.
It doesn't make external calls, currently only blocks single IPs, could potentially be managed by clients directly via RPC.
Any further protection should be handled at the hoster/OS firewall level.

[stefan1000]

All great examples for implementing @Rob-NY RPC firewall. It doesn't make external calls, currently only blocks single IPs, could potentially be managed by clients directly via RPC. Any further protection should be handled at the hoster/OS firewall level.

A bad actor should not even reach the application, all of this can be done on firewall level (peek into the UDP payload if it is a jamulus client connect msg, then hand it over to some user space script that does further checking)

See e.g. https://tech-champion.com/ethical-hacking/linux-packet-payload-manipulation-netfilter-and-nfqueue-solutions/

[rdica]

A bad actor should not even reach the application, all of this can be done on firewall level (peek into the UDP payload if it is a jamulus client connect msg, then hand it over to some user space script that does further checking)

See e.g. https://tech-champion.com/ethical-hacking/linux-packet-payload-manipulation-netfilter-and-nfqueue-solutions/

While this is certainly one layer of protection, it doesn't address the ability to dynamically block bad actors after a client join. Not all bad actors are known beforehand. The RPC interface could provide that functionality, and wouldn't necessarily require a server operator or client to learn linux, and nft/iptables (or Mac/PF, Windows Firewall).

@stefan1000 Have you tested the RPC firewall?
You make a valid point about bad actors not reaching the application, but I can tell you based on my own testing that once a block has been implemented on the RPC firewall, the bad actor connection is dropped, can no longer see the server in Connect dialog, nor can any attempt to direct connect succeed. Exactly the same behaviour seen when an OS level firewall rule is implemented.

Your suggestion plus the RPC feature could provide a comprehensive level of protection for servers and users on them.

Ultimately I believe in server admin autonomy in dealing with bad actors, and as @softins previously mentioned, if anyone chooses to modify their servers they can do so. I've always advocated inclusion of the RPC firewall code into the core application, but I understand and respect the desire not to do so.