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?

[imc67]

@robi I'm not a developer but a security concerned Cloudron user. The reason I started this application (LAMP-app, php and py) was that one of the users was lured into a phishing mail, his password was used for almost 2 months to send spam (via a direct SMTP connection, so no traces in IMAP). I was not able to discover this in Cloudron, that made me angry and extremely concerned: "what is happening more in the 3 Cloudrons I don't know because I can't see".

So I took a Claude AI subscription and in about 10 weeks daily coding, step-by-step I created this application but never with the thought of distributing it. So there is functionality (GUI) to add one or more Cloudrons, but ie. there is no user management (only 1 user) and the access is IP restricted to my 2 WAN IP's via DDNS reversed IP lookup, but on the other hand API keys (Cloudrons, AbuseIPDB, Pushover, ClaudeAI for daily email summary) etc. are managed via GUI.

To make it even a community app is totally out of my knowledge and comfort zone, moreover updating the app and being (feeling) responsible for others is too much. Maybe @staff can have a look with me to get inspired?

[james]

Hello @imc67
Sounds like an interesting project you got there, and I would be interested to have a look.

@imc67 said:

To make it even a community app is totally out of my knowledge and comfort zone, moreover updating the app and being (feeling) responsible for others is too much.

That good part about community apps is that they come with zero responsibility.
It is up to the maintainer of a community app to maintain, support or improve it.
I know that this statement might not do much about your feelings which I can fully understand.
Since your project is security related, having this burden on your mind for others that might use it, is much.

But, I would be happy to have a look and give my feedback.

[robi]

@james Thank you for the offer James!

@imc67 There is a loving community here for useful Cloudron solutions and you have one there by your own account.

I am sure we can find help making a custom community app and possibly even a maintainer who will use it and love it daily.

Like @timconsidine who has been scratching his own itches for some time, you did too and I for one am grateful for that!