CrowdSec + Traefik: IDS/IPS for web apps, no appliance

An IDS (Intrusion Detection System) watches traffic and flags hostile behaviour; an IPS (Intrusion Prevention System) goes one step further and blocks it. For web applications this traditionally meant a dedicated appliance or a commercial WAF in front of the servers. If you already run a reverse proxy such as Traefik, you have everything you need for a software, open-source alternative that runs next to your applications.

CrowdSec is an open-source, behaviour-based detection engine. It reads logs (from Traefik, Nginx, SSH, the operating system), turns them into events through parsers and runs them through scenarios — *leaky bucket* rules that count events over a time window. When a bucket overflows (for example, too many 404s on distinct paths from one IP), CrowdSec issues a decision: ban, captcha or another remediation, with a duration.

The difference from a classic firewall: CrowdSec does not look at packets but at what the client does inside your application. That makes it a good fit for vulnerability scans, brute force against login forms, aggressive crawling and exploitation of known CVEs.

To understand where things can go wrong, it helps to separate the three roles:

A request then flows: client → :443 entrypoint → bouncer middleware → router → application. The bouncer can run in live mode (queries LAPI for each new IP, with a cache) or stream mode (periodically downloads the full decision list and decides locally). Stream mode adds less latency per request, but a new decision only takes effect at the next pull.

1. Enable the access log in Traefik's static configuration (accessLog with filePath) and mount the log directory read-only into the CrowdSec container.
2. Install the right collection: cscli collections install crowdsecurity/traefik brings the parser and the basic HTTP scenarios. Add web CVE collections if you expose popular applications.
3. Declare the source in the acquisition file (acquis.yaml): the file path and the label type: traefik, so the logs reach the right parser.
4. Generate a bouncer key: cscli bouncers add traefik-bouncer. The key is shown once — keep it in a secret, not in code.
5. Declare the plugin in Traefik's static configuration (the plugins section) and create a middleware in the dynamic configuration with the LAPI address, the key and the mode (live or stream).
6. Attach the middleware to the websecure entrypoint or to each router. On the entrypoint it is harder to forget a new site.
7. Verify end to end: add a test decision for your own IP (cscli decisions add --ip X.X.X.X --duration 5m), confirm you get a 403, then delete it.

Hub scenarios cover the common patterns: probing of sensitive paths (/.env, /.git/config, wp-config.php), WordPress scanning, login brute force, aggressive crawling of non-static pages and known exploits for popular CVEs. Layer 7 flood detection lives in separate collections that are worth enabling only after you have tested them against your real traffic.

A custom scenario is a YAML file with a filter (an expression on event fields), a grouping key, a capacity and a leak speed. Two practical rules:

• Always group by something — usually the source IP (groupby: evt.Meta.source_ip). A scenario without grouping puts every event into one shared bucket and may ban whichever IP fills it first, letting everyone else through.
• Calibrate thresholds on real data, not intuition: look at how many requests a legitimate visitor makes in the worst case and set the capacity above that, with margin.

Through the Central API (CAPI) your instance receives a community blocklist — IPs reported by other installations for similar behaviour — and in turn sends the signals it detects. The value is the network effect: a scanner that has already hit thousands of other servers can be blocked before it reaches you.

The AppSec component adds WAF capabilities: it inspects the request before it reaches the backend and applies virtual patching rules for known vulnerabilities. The Traefik plugin can query it alongside the decision check. One detail to watch: requests refused by AppSec appear in the access log as proxy responses, not application responses, so they will not automatically feed log-based scenarios — check separately how repeated AppSec blocks turn into a ban decision.

An IPS that bans real customers is worse than one that misses a scanner. The classic sources of false positives:

• Legitimate crawlers. Googlebot or Bingbot may request many distinct URLs. Do not identify them by User-Agent — that is trivially forged. Verify the operator via forward-confirmed reverse DNS or published IP ranges, and use the good-actors whitelist collection.
• The amplification loop. CrowdSec reads the Traefik log, including the 403 responses produced by the bouncer itself. A banned IP that keeps browsing generates 403s, probing scenarios count them, and the ban renews forever. Exclude, via a parser, responses produced by the proxy rather than the application.
• Prefetching and modern apps. SPA frameworks may fire dozens of distinct requests when a page loads, with no user action. To a crawling scenario this looks like a robot.
• Clients that cancel requests. A mobile browser closing connections is not a slowloris attack.

The working tool is cscli explain --file line.log --type traefik: it shows step by step which parser processed the line and which scenarios it reached. Test both ways — the legitimate line must stay untouched, and the attack request must still trigger.

When the bouncer cannot reach the Local API it has two options: let traffic through (fail-open, availability before protection) or refuse it (fail-closed, protection before availability). Fail-closed sounds safer, but it turns any CrowdSec problem — a slow database, an invalid key after a reinstall, a restarted container — into a full outage of your sites. Choose deliberately, monitor the bouncer's last sync, and do not set the update interval shorter than the real duration of a full pull, or requests can pile up under load.

If CrowdSec protects essential services, tie it into the rest of the technical controls NIS2 requires — see NIS2 Art. 21: the technical controls and Linux server hardening with CIS.