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
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:
1 parent
9562a75378
commit
7392b843ad
5 files changed
+24
-14
No files matched your search
@@ -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
|
||||
|
||||
|
||||
Reference in new issue
Block a user