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: