fix(security): LAPI-only engine boot, import via stdin, correct compose service
Gitea Actions Runner Test / test-job (push) Successful in 1s
CI / check (push) Successful in 29s
CI / tests-integration (push) Successful in 1m46s
CI / tests-unit (push) Successful in 1m59s
CI / tests-ui (push) Successful in 2m53s
CI / preflight (push) Skipped
CI / deploy (push) Failing after 1m54s

This commit is contained in:
openhands committed 2026-09-24 18:59:13 +02:00
1 parent 9562a75378
commit 7392b843ad
5 files changed
+24 -14

No files matched your search

+17 -7
View File
@@ -778,12 +778,21 @@ Open **DevOps → Anti-DDoS protection**
## Local CrowdSec Engine (opt-in)
The repository ships a self-contained CrowdSec engine that runs on the same
Docker host. It reads the host Nginx access log, runs
`crowdsecurity/crowdsec:1.8.1` in its own Compose project and exposes LAPI only
on `127.0.0.1:18080`. When enabled, the app-layer anti-DDoS gate
(`src/lib/crowdsec-local.ts`) asks the local LAPI per client IP (short-cached)
and blocks `ban` / `captcha` decisions before its own rate buckets run.
No reverse-proxy, Traefik, Cloudflare or firewall configuration is changed.
Docker host. It runs `crowdsecurity/crowdsec:v1.8.1` in its own Compose project
and exposes **LAPI only** on `127.0.0.1:18080`. When enabled, the app-layer
anti-DDoS gate (`src/lib/crowdsec-local.ts`) asks the local LAPI per client IP
(short-cached) and blocks `ban` / `captcha` decisions before its own rate
buckets run. No reverse-proxy, Traefik, Cloudflare or firewall configuration is
changed.
The engine boots in **LAPI-only mode** (`DISABLE_AGENT=true`): it does not
consume the host Nginx access log and needs no outbound access to
`crowdsec.net`, which is often blocked on hardened hosts. Combined with
`DISABLE_ONLINE_API=true` (no CrowdSec Central API) the engine needs no account
and no inbound internet — blocking comes from the imported blocklists
(Step 4) and the app's own rate buckets. Re-enable the agent only on a host
with outbound internet by removing `DISABLE_AGENT: "true"` from
`deployment/crowdsec/compose.crowdsec.yml`.
### Step 1 — Enable the engine and register the bouncer
@@ -794,7 +803,8 @@ bash cms security
This generates `CROWDSEC_LAPI_API_KEY` (random 64 hex chars), writes the
CrowdSec flags into `.env`, starts the engine and registers the `cms` bouncer
against the local LAPI. The engine does **not** enroll into the CrowdSec
Central API (`DISABLE_ONLINE_API=true`): detection stays local.
Central API (`DISABLE_ONLINE_API=true`) and runs without the agent
(`DISABLE_AGENT=true`), so it never phones home.
### Step 2 — Restart the CMS so it loads the bouncer credentials