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

[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!

[imc67]

A follow-up, because raising nginx client_max_body_size alone turns out not to be enough — there is a second, hard-coded ceiling that hits right after.

Even with the /api/ location bumped to 10m, a blocklist POST now fails with HTTP 500 and this JSON body:

{"status":"Internal Server Error","message":"request entity too large"}

Note it is a 500, not an nginx 413 — the body passes nginx and is then rejected
inside box. The cause is the JSON body-parser limit in:

box/src/server.js  (9.0.0, ~line 41)
const QUERY_LIMIT = '2mb', // max size for json queries (see also client_max_body_size in nginx)
...
const json = middleware.json({ strict: true, limit: QUERY_LIMIT }, true);

That QUERY_LIMIT applies to every JSON POST route, including
POST /api/v1/network/blocklist. So there are two coupled limits — the nginx one
and this one — and the box default (2mb = 2,097,152 bytes) is the real wall for
large blocklists.

Concrete numbers from a live install: the combined blocklist is ~90,600 entries and
the JSON request body is 2,096,109 bytes — about 1 KB under the 2 MiB limit. One of my
servers already fails as soon as a few hundred new IPs are added, while others with a
slightly shorter list still squeak through. (JSON encoding inflates it further: each
newline becomes \n → \n, ~90 KB on top of the raw list. JSON_UNESCAPED_SLASHES is
already applied.)

Request: please raise both limits, ideally toward the ipset capacity (262,144
entries). At minimum, give the blocklist route a QUERY_LIMIT that matches a raised
client_max_body_size (e.g. 8–10 MB) — otherwise raising the nginx value has no effect
for this endpoint. The in-code comment already acknowledges the two are meant to track
each other.

Happy to provide a sample 90k-entry blocklist for testing if useful.

[imc67]

any update on this? Can it be implemented in Cloudron v10?

[girish]

@imc67 I have bumped it up to 20mb. thanks!