client_max_body_size 2m in /api/ location blocks the large blocklists

[imc67]

Following the fix in #10547 that raised the ipset limit to 262,144 elements, we ran into the next bottleneck: the nginx client_max_body_size 2m on the /api/ location in the dashboard config prevents actually reaching anywhere near that element count via the API.

In /home/yellowtent/platformdata/nginx/applications/dashboard/<hostname>.conf:

location /api/ {
    proxy_pass   http://127.0.0.1:3000;
    client_max_body_size 2m;   ← limits POST body to ~86k entries
}

At ~23 bytes per entry (JSON-encoded), 2MB caps the blocklist at roughly 86,000 entries — well below the 262k ipset capacity. Anything larger returns HTTP 413.

Workaround: changing 2m to 10m in that location block fixes it immediately.

Request: could this limit be raised (or set to 0) in a future Cloudron release? Given the server-level client_max_body_size 0 already applies to all app traffic, the 2m restriction on /api/ seems overly conservative for the network blocklist endpoint.

[james]

Hello @imc67
Thanks for the report.
Can you give me that JSON object so I can use it for testing?
Maybe via. paste.cloudron.io?

[imc67]

@james the current blocklist payload (~2.03 MB) link I've sent you via PM

Note: this is the GET response (Python-encoded by our nightly geo sync, which doesn't escape /). The actual PHP POST payload was ~68 KB larger because PHP's json_encode() escapes all forward slashes as / by default — one extra byte per CIDR entry, ~68,000 CIDR entries total. This pushed the payload to ~2.10 MB, triggering the 413.

Workaround applied: json_encode($body, JSON_UNESCAPED_SLASHES) in our PHP code reduces it back to ~2.03 MB. We also manually patched the nginx config to client_max_body_size 10m as a structural fix.

Both are a temporary workaround as the list is increasing with 300-500 IP's a day.

[nebulon]

wow those are a lot of IPs! How come that IP list grows by hundreds per day?

[imc67]

@nebulon I created CRMON — Cloudron Security Monitor, CRMON is a self-built security monitoring platform I run to monitor three Cloudron servers. It combines several threat intelligence sources and pushes a consolidated blocklist nightly to each Cloudron's network firewall via the /api/v1/network/blocklist API.

Beyond the blocklist, CRMON also uses the Cloudron API to continuously monitor event logs: mail delivery events, IMAP/SMTP authentication failures, user login anomalies and nginx failed login attempts are fetched every few minutes and cross-referenced against AbuseIPDB. IPs exceeding configurable abuse score thresholds are auto-blocked and immediately (hourly alas because the API is not per IP) synced to the firewall.

The blocklist has 5 layers, each with a different purpose:

Layer	Count	Source
Individual auto-blocks	~6,200	IMAP brute-force, login anomalies, mail abuse — auto-blocked based on AbuseIPDB score thresholds
Wordfence (WordPress)	~4,200	A MU-plugin on ~25 WordPress sites reports attacker IPs in real time to CRMON, which syncs them to the firewall
AbuseIPDB blacklist	~9,600	Daily import of the top-scoring IPs from the AbuseIPDB API
FireHOL level1	~4,500	Known malicious network CIDR ranges (botnets, scanners, exploits)
Geo/country blocking	~63,000	IP ranges (IPv4 + IPv6) for ~23 high-risk countries (CN, RU, IR, KP, etc.)

Why it grows: The Wordfence layer is the fastest-growing (+150–280 IPs/day) as WordPress sites under management continuously see new attackers. The geo layer is the largest by far — country-level CIDR ranges, especially for China and Russia, account for the bulk of entries.

The geo ranges alone explain why we're pushing well over 80,000 entries. Without geo blocking, the list would be ~20,000 entries and the 2 MB limit would never be an issue.

[robi]

@imc67 Can you make CRMON a custom app?