Hoping someone with a distributed CrowdSec deployment can clarify how the Console counts engines. I'm getting a "too many engines" warning and want to understand the intended model before I restructure anything.

- One central Security Engine running the LAPI (SQLite). It aggregates alerts and serves the decision list.

- ~6 remote log processors on separate hosts (web, mail, a couple of app servers). These are configured as pure log processors: `api.server` section removed from `config.yaml`, `api.client` pointing at the central LAPI. They only forward alerts; they don't run their own LAPI.

- No local remediation on the CrowdSec boxes at all. My firewalls subscribe to the blocklist mirror (cs-blocklist-mirror) and do all the enforcement.

- The published decision list is mostly CAPI + subscribed third-party lists (firehol, tor exit nodes, etc.), plus a small amount from my own scenarios.

- Only the central LAPI is enrolled to the Console. I never ran `cscli console enroll` on the log processors.

The problem

The Console counts 7 engines (1 LAPI + 6 log processors) and warns that I have too many. I'm on a paid plan billed per Security Engine, with one engine included.

1. In the Console/billing model, do remote log processors count as separate Security Engines? The concepts docs describe a Security Engine as log processor(s) *plus* a LAPI together, which made me expect "1 LAPI + N log processors" to count as a single engine, not seven. Which is correct?

2. If log processors do count individually, how do people running distributed detection stay within plan limits: consolidate log collection into fewer processors, split across a second (free) org, or just pay per engine?

3. My central LAPI also runs a local processor that only reads `/var/log/messages` (100% unparsed noise). Any downside to making it LAPI-only by removing the `crowdsec_service` section? Does that change how it's counted?

Running CrowdSec v1.7.7 Anyone who's dealt with per-engine billing on a hub-and-spoke setup, I'd appreciate the clarification.

Anyone else noticing that the Security Report emails will claim "A lot more from previous period" under the attacks figure even when the number literally went DOWN?

Proof (copied straight from emails):

That was 2 weeks ago, let's see how last week was, shall we?

Now guys, I'm not a genius here, but I'm pretty sure I took basic math in elementary school, and I'm pretty certain that 12.3k is LESS than 13.8k. In fact, I'm pretty sure 12.3k is about 1.5k less than 13.8k, or approx 10.9% LESS.

This isn't math theory class where numbers mean the opposite, this is basic comparison of 2 real numbers in real life. And CrowdSec, in literally 100% of my Security Report emails, has claimed the number has significantly increased.

This is kinda hilarious if you ask me. I'm just gonna unsub from them because they are meaningless, but figured I'd post this because I find it kinda silly.

Currently several home servers are blocked in Crowdsec. Homeassistant, NAS, Docker all local IP's 10.10.x.x and 192.168.x.x

So i guessed there will be a simple methode to ad a whitelist in the application itself ( plugin in Opnsense)

But it seems i am to dumb to find the option. So i tried several commands from the prompt ( not secure at all!) to add those things.. to no avail it seems.

It should be a option in crowdsec to add a whitelist from the gui. Nothing difficult.

But maybe its worse and i am to dumb to find the option.. so any tip is welcome but better a simpeler GUI.

Subject: CrowdSec 1.7.8 on pfSense 26.03.1: Log Processor and LAPI failing to stay started

Hi everyone,

I recently installed CrowdSec 1.7.8 on pfSense 26.03.1 using the installation script (which completed successfully).

However, I'm running into an issue: while the CrowdSec Firewall Remediation service runs perfectly, both the CrowdSec Log Processor and the Local API (LAPI) service keep stopping and will not stay started.

Yes. I know Crowdsec isn't officially supported by Netgate.

Has anyone encountered this issue or have any ideas on how to troubleshoot this?

Thanks in advance!

I've been running CrowdSec + Traefik for a while and got tired of the same debugging loop every time something didn't add up — is LAPI actually reachable, is the bouncer actually registered, is the decision actually in the ban list, is it actually reaching the bouncer, etc. So I built a small tool for it.

What is it?

CrowdSec Troubleshooter is a standalone, unprivileged Docker image that runs once (docker run --rm, no daemon, no docker.sock, no --privileged, no NET_ADMIN) and tells you exactly what's working and what isn't, tier by tier depending on what credentials you give it:

• Tier 0 (nothing but the LAPI URL) — LAPI liveness, is it actually parsing logs, bouncer-type fingerprinting (legacy ForwardAuth bouncer vs the modern Traefik plugin), a heuristic on your LAPI URL itself, a cscli hub update/upgrade cron nag since nothing else keeps your scenarios current
• Tier 1 (a read-only bouncer key) — look up a specific IP's ban status and why, plus an automatic ban-count summary broken down by scope/origin so you can actually see it's doing something
• Tier 2 (a machine credential) — the real test: adds a real short-lived ban on itself, confirms the target actually returns 403, removes the ban, confirms access is restored. This is the one that actually proves blocking works end to end instead of just "looks configured"
• Tier 3 (read-only host mounts) — DOCKER-USER iptables chain evidence (the #1 reported "ping blocked but HTTP gets through" issue), duplicate acquisition entries, compose-file hardening audit, syslog hinting

It also ships with a curated, offline knowledge base baked into the image — no internet needed to browse it — of ~30 real CrowdSec/Traefik gotchas pulled from a research pass across the top GitHub issues on the core crowdsec repo, the firewall bouncer, and the Traefik plugin repo, each with a link to the actual fix. docker run --rm modem7/crowdsec-troubleshooter issues to browse it.

There's also a wizard.sh if you don't want to hand-build docker run flags — it auto-detects your running CrowdSec container's compose file and pre-fills what it can.

Who it's for

Anyone self-hosting CrowdSec, especially fronted by Traefik. Works the same whether CrowdSec itself is Dockerized or a bare-metal/apt install — the troubleshooter is always a container, but it's just talking to LAPI over HTTP either way.

On the AI question

I used Claude for a chunk of the docs and some of the implementation, as well as code optimisation — not going to pretend otherwise. But it's not vibe-coded: everything went through shellcheck, a real bats test suite (100+ tests, mock LAPI servers, happy path + failure path for every check), and multiple bugs only got caught by actually running things against a real LAPI instance rather than trusting what looked right on paper (there's a whole section in the repo's DESIGN.md documenting where assumptions turned out wrong and how they were caught — including one where an endpoint I assumed existed turned out to not exist at all in the real API). I reviewed and tested every change before it shipped.

Links

• GitHub: https://github.com/modem7/crowdsec-troubleshooter
• Docker Hub: https://hub.docker.com/r/modem7/crowdsec-troubleshooter

Also on GHCR if you'd rather pull from there. Multi-arch (amd64/arm64). MIT licensed.

Feedback/issues/PRs welcome — it's still early days for some of the tiers (a couple of checks are flagged as unverified placeholders rather than pretending to work), but the core wellness check and live-block test are solid.

I thought this was going to be something reasonable I could do out-of-the-box but there doesn't seem to be any direct way for parsers to use databases as their data sources which has taken me into a rabbit hole of "how do I get database tables into files so that they can be monitored by crowdsec?" I considered scheduled exports to file but this seems to have too high a latency for security monitoring for comfort. I'm now toying with triggers but it looks messy as well, so well, community, how would you approach this?

Scenario is we have a product that logs useful things like failed login attempts to a database table (stored in MariaDB) and we want to monitor that with crowdsec.

CrowdSec Installed but Showing No Decisions? Here's Why That's Normal

When I first fired up CrowdSec, I thought to myself, "Amazing! Job's done! No script kiddies or scanners are gettin' in here now".... I spent an hour last week staring at an empty log file, convinced I had broken my server somehow while working on something else!

Like me, if you installed CrowdSec, and ran:

cscli decisions list …and got: No active decisions

Naturally, your first thought is: Did CrowdSec fail? In most cases, no. This usually means CrowdSec is working exactly as intended!

📡 If you haven’t installed CrowdSec yet, start with my complete CrowdSec deployment guide inside the Digital Castle stack.

As you probably know, unlike Fail2Ban, CrowdSec blocks many attackers preemptively using community intelligence, so your local decision list may stay empty even while your server is actively protected.

In this guide, you'll learn how to verify CrowdSec is functioning correctly by checking:

• downloaded community decisions
• active metrics
• blocked attack attempts
• alert history
• whitelist configuration

All via CLI and also with CrowdSec WebGui!

Head on over to my CrowdSec deep-dive walk-through to begin your verification.

Disclaimer: Written, screen-shotted and tested/used by me. There are NO ads of any kind on this page nor affiliate links. Just sharing info & love for CrowdSec!

Edit: Title got mangled by Reddit some how upon posting? I slapped it above.

Hey everyone,

I’m working on Jabali Panel, a GPL open-source web hosting control panel, and CrowdSec is one of the main security layers behind it.

CrowdSec integration is a big part of the project, so I’d really love feedback from people here.

Please take a look at the images and tell me what do you think a good GUI around CrowdSec should add/change?

The project is still in development, but it’s already being used, and the community is slowly growing. I’m now looking for testers and early users who want to try it, give feedback, report bugs, and help shape the direction.

Jabali also supports Docker now, so it can be used not only as a normal web hosting panel, but also as a Docker proxy server, stand alone mail server or DDNS & DNS server and more.

Check it out:

GitHub: https://github.com/shukiv/jabali-panel
Demo: https://demo.jabali-panel.com

Thanks!

Hi all... Ive been reading up on crowdsec recently as I am starting to think about opening up more of my internally hosted services to the outside world to allow me to access them whilst on the move.

My understanding is that you have a main box (LAPI) for the controlling all the bouncers that are on the machines that make up my lab.

So in my instance, I have the following boxes...

• Proxmox
  • NAS (LXC)
  • DHCP/DNS (LXC)
  • NVR (LXC)
  • Media host (VM)
  • Home Automation (VM)
  • HTTP Reverse Proxy (VM)
  • Infrastructure Monitor (VM)

The way I see it, is I install crowdsec on all these machines, and set it up as a bouncer, and then create a new VM or LXC that can run as the main box for CrowdSec, the LAPI.

Is this the right kind of setup for this?

I was today years old year I learned that CrowdSec free has quota on alerts.

Today some IP started to hammer my OPNsense to find open ports.

The 3rd IP is still scanning at the time of this post 👀

I'm getting concerned about the number of prevented attacks on my CrowdSec instance. It seems every time a report comes in, the number of attacks prevented is significantly higher than the previous period, with the highest vector being "unknown behavior".

December of last year, I was seeing ~220k attacks prevented per week on my VPS, and now I'm seeing ~750k. This seems like a RIDICULOUS number of attempts... Is this normal? Is this just due to a rise in automated bot/AI attacks? Is anyone else seeing this? Perhaps I'm being targeted specifically?

Curious what others' experiences are like.

had to use custom blocklists but good riddance
thanks crowdsec

UPDATE: they are back :[

Hi-

I’m new to this world, so apologies in advance if I use words incorrectly or inconsistently.

Why is it that out of the box a single port scan merits a ban, but an IP that does the same vpatch-env or vpatch-cve 70 times in one minute doesn’t get a decision? Is there a solid reason for that, or should I do some tuning? None of my (homelab) users is hitting the same incorrect url multiple times in a short period of time.

Thanks.

Firstly a disclosure: I spent a couple of hours today to debug some appsec issues (manually and assisted by OpenCode). I then had OpenCode summarize it for this post so please don't diss this post as AI slop, there is a human writing this as well as replying to comments manually 😄

I’m running Pangolin/Traefik with CrowdSec and the maxlerebourg Traefik bouncer plugin v1.6.0, including AppSec.

Setup:

- Traefik + CrowdSec in the same Docker Compose stack

- CrowdSec watches Traefik access logs

- Traefik bouncer middleware is applied globally on `websecure`

- CrowdSec bouncer mode: `stream`

- AppSec enabled, host `crowdsec:7422`

- AppSec failure/unreachable currently set to fail-open

Original problem:

- Large uploads through apps behind Traefik, especially Paperless/FileRun-style ~15–17 MB PDFs, caused issues.

- CrowdSec/AppSec logs showed multipart/body read errors like EOF/unexpected EOF.

- CrowdSec CPU spiked heavily.

- Traefik bouncer logged many `appsecQuery:unreachable` messages.

- Requests could fail or stall depending on settings.

Things I found:

- The Traefik bouncer plugin’s AppSec path is synchronous: Traefik calls CrowdSec AppSec during request handling.

- `appsecQuery:unreachable` appears to be a generic transport/client error from the plugin’s AppSec HTTP call, not a WAF verdict.

- In v1.6.0 there is no separate AppSec timeout option; `httpTimeoutSeconds` applies to both LAPI and AppSec clients.

- `crowdsecAppsecBodyLimit` controls how much request body the plugin forwards to AppSec.

- Setting body limit to `0` means the plugin does not forward/read the request body for AppSec.

- CrowdSec log-based scenarios are asynchronous; they can ban future requests but cannot block the same first request before the access log exists.

- The bouncer IP decision cache is inline and cheap; AppSec is inline and more fragile under bursts.

Current tuning:

crowdsecAppsecEnabled: true
crowdsecAppsecHost: crowdsec:7422
crowdsecAppsecScheme: http
crowdsecAppsecBodyLimit: 0
crowdsecAppsecFailureBlock: false
crowdsecAppsecUnreachableBlock: false
httpTimeoutSeconds: 2
updateMaxFailure: -1

Traefik entrypoint middleware order:

- rate-limit@file

- in-flight-req@file

- crowdsec@file

- secHeaders@file

- compress@file

Also increased rate/in-flight limits because the Traefik dashboard itself makes many concurrent API calls and was getting 429s.

Results:

• Two test uploads of ~16.9 MB and ~15.0 MB to FileRun succeeded with HTTP 200.
• Paperless browsing/previews worked.
• Traefik dashboard works again.
• CrowdSec/Traefik memory stayed stable.
• Still seeing occasional appsecQuery:unreachable bursts during external scanner traffic, but fail-open prevents user-facing breakage.
• Rate limiting now catches many scanner requests with fast 429s.

Questions:

• For people using CrowdSec AppSec with Traefik in production: do you run AppSec globally, or only on selected routers/routes?
• Have you seen appsecQuery:unreachable bursts with v1.6.0?
• Did you keep AppSec fail-open?
• Did you disable body forwarding or only exclude upload routes?
• Any recommended tuning for high-request bursts/scanners?

We just published the CrowdSec skill! It can already be used with Claude (web/code), Codex etc.

Very concretely, it provides you with an actionable answer to questions and requests such as:

• “Why isn’t my crowdsec instance detecting attacks on my nginx server ?”
• “Set up the crowdsec WAF on my Traefik server”

Once an internal experiment, it yielded very convincing results, so now it’s time to put it into our users’ hands.

Documentation is really hard. Hard to read, because it’s hard to write, so hard that it’s not very far from “naming things” hard. While it would be easy to dismiss it as “people don’t read documentation”, it would be unfair.

Thus, this skill aims to be the CrowdSec handbook for LLMs, and I believe it can really help our users set up CrowdSec, debug it, and improve their existing setups.

The development process was funny and a good example of a feedback loop and self-correction:

• Once I had a detailed plan and structure of what the skill should cover or exclude, I dedicated an EC2 for Claude to test every setup and scenario. It then deployed various web servers, bouncers, and ecosystems (Docker, Kind, etc.) to validate and self-correct the skill’s content.
• Later, we moved on to present Claude with deliberately broken and misconfigured setups that reflect the most common issues we’re seeing. Again, once it had fixed the setup and identified the root cause (sometimes laboriously), session content was used to amend the plan.
• Last but not least, we extracted raw content from over a thousand threads in the Discord support channel to identify recurring topics and, using our test bed, try to reproduce the initial issue and ensure the skill contained the relevant pointers to fix it.

Stay safe! And as usual, don’t hesitate to reach out for feedback, suggestions or a rant 😄

I know, it's Kaspersky fault and not CrowdSecs, but it should be known that the Web Protection is blocking the Website

I'm just on a holiday and got banned again left and right (wifi, mobile, mobile + vpns) for using my services.

my internet is so slow right I'm struggling to find out why. I added my Ips to my allowlist and then it worked briefly. But I also ran into weird issues that made me reboot my VPS and ultimately led to a backup restore of my Pangolin setup. Briefly even my whitelisted home ip didn't work no idea why

I'm sorry I can't produce enough details as I had to fix my whole setup using an iphone and it was painful enough believe me...

What I realised is that the http-probing scenario - which I've disabled months prior- was reenabled. Probably through a CS upgrade I guess?

what's the point of this crap if it repeatedly blocks me and my other users from accessing simple services on m homelab?

is there no way to disable this thing for good??

I use an additional tool which can inject blocklists into crowdsec. Recently it got blocked by crowdsec despite me having an allowlist for all private ranges.

Any ideas what is going on?

The error:

crowdsec-monitor-api  | Deleting 26 alert(s) for blocklist "Abuse.ch" from CrowdSec...
crowdsec-monitor-api  | Error deleting alert 14609: 403 - {"message":"access forbidden from this IP (172.16.0.165)"}
crowdsec-monitor-api  | Background CrowdSec sync failed for blocklist "Abuse.ch": Failed to delete blocklist decisions from CrowdSec

The allowlist:

docker exec -ti crowdsec bash
root@crowdsec:/# cscli allowlist inspect PrivateRanges
──────────────────────────────────────────────
 Allowlist: PrivateRanges                     
──────────────────────────────────────────────
 Name                PrivateRanges            
 Description         Private IP Ranges        
 Created at          2026-04-22T10:32:54.492Z 
 Updated at          2026-04-30T07:26:02.981Z 
 Managed by Console  no                       
──────────────────────────────────────────────

───────────────────────────────────────────────────────────────────────────────────────────────
 Value           Comment                                      Expiration  Created at           
───────────────────────────────────────────────────────────────────────────────────────────────
 ::1                                                          never       2026-04-22T10:33:36Z 
 127.0.0.0/8                                                  never       2026-04-22T10:33:42Z 
 192.168.0.0/16                                               never       2026-04-22T10:33:50Z 
 10.0.0.0/8                                                   never       2026-04-22T10:33:59Z 
 172.16.0.0/12                                                never       2026-04-22T10:34:06Z 
 100.64.0.0/10   CGNAT range, used by Tailscale and Pangolin  never       2026-04-30T07:26:02Z 
───────────────────────────────────────────────────────────────────────────────────────────────
root@crowdsec:/# 

Hey guys - quick question.

Edit/Update: I'm leaving my original post/question below as-is, but in a moment of clarity, I realized what the directions were probably saying was that 99:99 wasn't key:variable but was <crowdsec_value>:<crowdsec-dashboard value>.
I had gotten it working earlier by manually changing permissions with chmod on the crowdsec.db file but after a restart of my containers a few days later the permissions returned to what it was before and dashboard was no longer able to read crowdsec.db.
Resolution:
In the crowdsec container I set key:variable to UID:99, GID:98.
The crowdsec-dashboard container has MUID:99, MGID:98 so it looks like these variables map between the containers like:
crowdsec UID = crowdsec-dashboard MUID, value is 99 for both.
crowdsec GID = crowdsec-dashboard MGID, value is 98 for both.

Once I updated crowdsec with UID:99, GID:98, crowdsec-dashboard can now read crowdsec.db again.

Original Post where my understanding of the directions wasn't correct:
I'm new to crowdsec and just got it up and running on Unraid. Now I'm following up with the metabase crowdsec-dashboard container install on Unraid.

Under "Additional Requirements" it states:

Add the following to your Crowdsec container as enviroment variables to give the dashboard appropriate permisions to read data:
UID: 99:99
GID: 98:98

Is that format in <variable name>: <key>:<value> ?

So I would go back to the crowdsec config and add this variable as shown in my screenshot and repeat for GID: 98:98, right? It just seemed a bit strange adding a numeric key so just wanted to double-check.

Crowdsec is banning my local IP when I try to view a .env file in my github repo. Other dot files work fine, even a env without the dot works.

[alert] 2885#2885: *141462 [lua] crowdsec.lua:783: Allow(): [Crowdsec] denied '[localIP]' with 'ban' (by appsec), client: [localIP], server: git.[domain], request: "GET /Docker/explo/src/branch/main/.env HTTP/2.0", host: "git.[domain]"

Any ideas?

so i’m a bit new to crowdsec and am concerned my setup isn’t operating as intended. ive been working out getting crowdsec setup with traefik in front of jellyfin and it goes

- from cloudflare proxied to -> pfsense box, cloudflare public ip’s get port forwarded to -> traefik instance, traefik serves to -> jellyfin backend with middleware chain that contains crowdsec bouncer/rate limit and security headers.

bouncer has app sec enabled with traefik, linux, custom jellyfin various http, crs, crs-inbound and virtual patching collections at the server.

crowdsec recognizes bouncer, bouncer can communicate with server, logs are parsed correctly (i’m getting what i’m sure are correct client ip’s as i’ve added cloudflare ip’s to forward trusted headers option at traefik entry point and traefik/jellyfin logs get public ip’s that don’t match any cloudflare proxy address). when i manually add a local ip to decisions list for ban testing, the bans work, but if i add a public ip from a friend of mine, they’re allowed right in and can watch stuff no problem.

my manual ban of their public ip shows up in my alerts panel on crowdsec website, but a “safe” cloudflare proxy ip is allowed through at the same time they access the site in traefik logs. i’m very confused. any ideas?

I am running crowdsec with npmplus. When I use Jellyfin android app (doesn't give me banso often) or Seerr android app (bans me very often) I get a ban on http probing. Is there a way to prevent this in a reasonable way.

Is the pfSense package going to get some love anytime soon? FreeBSD 15 based version of pfSense plus are now EOL which means i cant update to a supported versions as Crowdsec havent release a FreeBSD 16 based package yet.