LoginSign Up
← Back to all sparks
C

CrowdSec

INFRA · APIS
Velocity3.8

Collaborative behaviour-based intrusion prevention engine

crowdsec.net ↗

CrowdSec's WAF is growing a bot-detection challenge — log analysis meets active interception.

wafbot-detectionintrusion-detectionkubernetescorazarelease-candidates
◆Current state
The feed carries only release candidates, roughly one every two to three months, and the WAF has been the centre of gravity across all of them: OpenAPI schema validation, request body size limits, arbitrary AND/OR mixing in rule conditions, more Coraza transformations exposed, RE2 enabled by default on Linux. The 1.8.0 candidate breaks that pattern by adding challenge-and-fingerprint bot detection, serving an interstitial page and evaluating the result against configured rules. The same candidate adds a dedicated Kubernetes datasource that reads logs from the apiserver directly, and HTTP helpers so parsers and scenarios can query external services. Two earlier candidates in the window are pure refactoring with no user-visible change.
◆Where it's heading
CrowdSec started as a log-reading detection engine that handed decisions to external bouncers, and the WAF work has been steadily moving it into the request path. Bot detection completes that move: the product now generates its own signal by interrogating the client rather than only inferring from logs. The Kubernetes datasource and the expression-language HTTP helpers point the same way — fewer intermediaries between CrowdSec and both the telemetry and the enforcement point.
◆Prediction
Expect the fingerprinting rules to become a shared, community-curated resource in the same way detection scenarios already are, since that is the pattern this project applies to every new signal it collects.

◆Recent moves

  1. 7d ago

    CrowdSec 1.8 RC adds WAF bot detection and a Kubernetes datasource

    ⚡ SPARK

    The candidate that moves CrowdSec from inferring attacks out of logs to interrogating clients directly, via a challenge-and-fingerprint page in the WAF. Combined with a Kubernetes apiserver datasource and HTTP helpers in the expression language, it is the clearest step yet toward CrowdSec sitting in the request path rather than beside it.

    View source ↗
  2. 3mo ago

    1.7.8 RC: OpenAPI schema validation in the WAF

    Adds OpenAPI schema validation and request body size limits to the WAF, and switches the decision stream to chunked transfer by default. Schema validation is the API-aware half of the WAF story that bot detection later complements.

    View source ↗
  3. 4mo ago

    1.7.7 RC: flexible WAF rule conditions and RE2 by default

    Allows arbitrary mixing of AND and OR conditions in WAF rules, exposes more Coraza transformations, enables RE2 by default on Linux and adds LookupFile and FileMap expression helpers. Rule-authoring ergonomics, which is what determines whether a WAF gets tuned or left on defaults.

    View source ↗
  4. 6mo ago

    1.7.5 RC: acquisition and leaky-bucket refactoring

    A candidate consisting entirely of internal refactoring — datasource registration, configuration validation, injected state dumpers, error-handling cleanup. No user-visible change, but it is the groundwork the later Kubernetes datasource sits on.

    View source ↗
  5. 8mo ago

    1.7.4 RC2: acquisition module split and lint cleanup

    Another refactoring-only candidate, splitting acquisition modules per datasource and tightening lint rules. Housekeeping ahead of the datasource work that followed.

    View source ↗