How CrowdSec protects you
CrowdSec is the platform’s firewall. It analyzes the traffic of every site, bans attacking IP addresses across the whole platform, inspects requests for known exploits, and shares threat intelligence with the wider CrowdSec network. It runs in front of every site’s cache, so a blocked request never reaches Varnish or your origin.
Components
Section titled “Components”| Component | Role |
|---|---|
| Security Engine | Reads Traefik’s access logs, matches them against attack scenarios, and stores the resulting ban decisions. |
| AppSec component | Inspects each request in real time and rejects requests matching virtual patching rules. |
| Bouncer | A Traefik middleware that checks every request against the ban decisions and the AppSec component before it is routed to a site. |
| Central API | CrowdSec’s network service: it receives the attacks detected here and supplies the community blocklist. |
Two ways an attack is stopped
Section titled “Two ways an attack is stopped”CrowdSec stops attacks at two different moments.
Request inspection (AppSec) evaluates each request as it arrives. A
request matching one of the virtual patching rules is rejected immediately
with a 403, even if it is the first request ever seen from that IP. The
rule set targets exploitation of known vulnerabilities, many of them in
WordPress plugins, and currently contains 192 rules. A client that keeps
triggering these rules is also banned (scenario appsec-vpatch).
Behavioral detection analyzes the access logs of all sites and looks for patterns that no single request reveals, such as fifty failed logins in a minute. When a client’s behavior matches a scenario, its IP is banned and every following request from it is rejected.
Detection scenarios
Section titled “Detection scenarios”The scenarios installed on the platform, by category:
| Category | What triggers a ban |
|---|---|
| WordPress | Login brute forcing on wp-login.php (http-bf-wordpress_bf), XML-RPC brute forcing (http-bf-wordpress_bf_xmlrpc), plugin and theme scanning (http-wordpress-scan), user enumeration (http-wordpress_user-enum), attempts to read wp-config.php (http-wordpress_wpconfig) |
| Probing and scanning | Bursts of 404s (http-probing), aggressive crawling of non-static pages (http-crawl-non_statics), probing for sensitive files, admin interfaces and technologies, known scanner user agents |
| Exploitation attempts | Backdoor access attempts, SQL injection, XSS and path traversal probing, generic credential brute forcing, open proxy abuse |
| Known vulnerabilities | About thirty scenarios for specific CVEs (Log4Shell, Spring4Shell and vulnerabilities in widely deployed appliances), plus generic CVE probing (http-cve-probing) |
| Virtual patching | Repeated matches of AppSec rules (appsec-vpatch) |
Detection is shared across sites: a client scanning one site is banned from all of them.
Where ban decisions come from
Section titled “Where ban decisions come from”| Source | Description | Duration |
|---|---|---|
| Scenarios | IPs whose behavior on the platform matched a scenario | 4 hours by default |
| Community blocklist | IPs reported by many CrowdSec users around the world as actively attacking, synchronized every two hours | Managed by CrowdSec |
| Manual bans | IPs banned from the admin’s Firewall page or from a site’s live logs | 1 hour to permanent, chosen when banning |
A decision applies to the IP address platform-wide: a banned IP cannot reach any site.
Enforcement
Section titled “Enforcement”The bouncer runs inside Traefik on every edge node:
- Ban decisions are kept in memory on each node and refreshed every 15 seconds (stream mode). Checking an IP requires no network call, so it adds no measurable latency. A new ban takes effect on every node within about 15 seconds.
- AppSec inspection is a call from Traefik to the AppSec component for each request. It fails open: if the component is unreachable or returns an error, the request is allowed rather than blocked, so a firewall problem never takes sites offline.
A blocked client receives an HTTP 403 for every request, on every site,
until the decision expires.
Your origin is never banned
Section titled “Your origin is never banned”Some WordPress plugins make requests to their own site, sometimes frequently: Jetpack’s synchronization is a common example. Those requests travel through Edge Caching and can look exactly like scanning. To prevent your own server from being banned, every site’s origin IP address is automatically added to an allowlist, kept in sync as sites are added, removed or moved to another origin. Allowlisted IPs are never banned, even manually.
What is sent to CrowdSec
Section titled “What is sent to CrowdSec”Like every CrowdSec installation sharing signals with the network, the platform reports the IP addresses banned by its scenarios, with the scenario that triggered each ban and when. This is what makes the community blocklist possible. The contents of requests, such as URLs, cookies, form data and headers, are not sent.
Limits
Section titled “Limits”- HTTPS only. The bouncer runs on HTTPS traffic. A site served over plain HTTP, without TLS enabled, is not covered by bans or request inspection. Enable TLS on every production site.
- Shared IP addresses. A ban applies to an IP address. Visitors sharing an address with an attacker, such as users behind the same corporate NAT or carrier-grade NAT, are blocked too until the ban expires. See Firewall for how to lift a ban.
- Not a substitute for updates. Virtual patching blocks known exploit patterns, not every possible way to reach a vulnerability. Keep WordPress, themes and plugins up to date.