# CrowdSec: crowdsourced IP blocking with a log-parsing security engine

> CrowdSec parses logs and HTTP requests to detect attacks, then hands verdicts to separate remediation components. Here is how the engine, the hub and the community blocklist fit together, and what the README leaves out.

**crowdsecurity/crowdsec** — CrowdSec - the open-source and participative security solution offering crowdsourced protection against malicious IPs and access to the most advanced real-world CTI.

- Repository: https://github.com/crowdsecurity/crowdsec
- Website: https://crowdsec.net
- Stars: 14,995 · Forks: 722
- Language: Go
- License: MIT
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/crowdsecurity-crowdsec

## What CrowdSec actually detects and who it is built for

CrowdSec is a log-driven detection engine. The README describes the Security Engine as an all-in-one IDS/IPS and WAF that detects bad behaviour by analysing log sources and HTTP requests. Detection is behavioural: scenarios such as brute force, port scan and web scan ship by default, and more can be pulled from the hub. The target user is someone running more than one service and more than one log format, who wants a single place to decide that an IP is hostile and several places to act on that decision.

The design phrase the README uses is "Detect Here, Remedy There". That split is the whole point. The engine does not block anything by itself. It writes decisions, and separate remediation components, called bouncers, enforce them at the applicative, system or infrastructural layer. If you only want one daemon that watches one log and drops packets, this architecture is more moving parts than you need.

## The engine, the hub and the community blocklist

Three pieces do the work. The engine runs locally, parses logs and HTTP requests, and applies scenarios to produce decisions. The hub is the distribution channel for parsers, scenarios and remediation components; the README states that detection rules are available there under MIT licence. The community blocklist is a curated set of IP addresses that the engine blocks proactively, aggregated from what other users reported.

That last piece is the participation model. Sharing a signal about an attacking IP means other installs block it before it reaches them. It also means your install talks to a central API, which is a governance question as much as a technical one. The README links to the console for visualisation, management, extra blocklists and premium features, so some operational surface sits outside the open source binary.

The engine is written in Go, and go.mod shows the HTTP server stack (gin), an entity framework (ent), a WAF library (coraza), SQLite drivers and cloud log integrations for AWS Kinesis, SQS, CloudWatch Logs and S3. That dependency list is a fair summary of scope: this is a service with a database, an API and its own HTTP-facing WAF, not a shell script.

## Installing CrowdSec and getting a first decision

The README does not inline install commands. It points to the documentation for Linux, Windows, Docker, OpnSense and Kubernetes, and the repository ships a wizard.sh at the top level plus debian and rpm packaging directories. So the honest first step is the documentation, and the closest thing the repository offers to a guided start is that wizard script.

The README gives no command to run it and no package name to install, so there is nothing here that can be copied verbatim into a shell. What the repository does show is the build side, in the Makefile, which states the default toolchain requirements in its own comments. Anyone compiling rather than installing a package deals with these:

```make
include build/mk/platform.mk
include build/mk/gmsl/gmsl
```

Those two lines pull in the platform detection and the GMSL macro library the rest of the Makefile depends on. The Makefile also documents its external dependencies in comments rather than commands: on Debian or Ubuntu the C++ re2 library comes from libre2-dev, on Fedora or CentOS from re2-devel, on FreeBSD from the re2 package, on Alpine from re2-dev, on Windows from choco install re2 and on macOS from brew install re2. Building without it is possible with BUILD_RE2_WASM=1, which the file itself says is slower and introduces a short delay when starting a process, including cscli, so it is not recommended for production use.

The SQLite backend is another build-time choice. BUILD_SQLITE defaults to mattn, and setting it to modernc switches to a pure Go implementation that the Makefile describes as slower, not extensively tested and not meant for production. The default GO_TAGS line in the file is netgo,osusergo,expr_debug,nomsgpack, and a static build is requested with BUILD_STATIC=1, which the comments warn may fail at link time if the static library is not provided for your distribution.

None of this tells you how to enrol a log source. That lives in the documentation the README links to, and the repository does not repeat it.

## Where CrowdSec is the wrong tool

The engine is a detector, and the README is explicit that active remediation comes from remediation components. If you install the engine and stop there, you have built an observability tool, not a firewall. That gap surprises people who expect a package named as a security solution to start blocking on its own.

The second constraint is data quality. Scenarios are behavioural, so they need log lines that a parser understands. A service writing an unusual format, or logging to a destination the engine cannot read, produces no decisions no matter how many scenarios you install. The hub mitigates this for popular software, not for your in-house application.

The third is the community blocklist. It is the feature that distinguishes CrowdSec from a local log watcher, and it depends on an outbound relationship with a central API. Environments that forbid egress, or that cannot accept an externally sourced blocklist as authoritative, lose the main advantage and are left with a heavier local IDS than they need. The README does not document how to operate the blocklist in a fully air-gapped way, and it does not document rollback of a decision or of a hub item.

## CrowdSec and fail2ban solve the same problem differently

The comparison people search for is CrowdSec versus fail2ban. Both watch logs and both end up blocking an address, but they sit at different layers. fail2ban is a per-service jail: you point it at a log file, give it a regex, and it adds a local firewall rule. The decision and the enforcement live in the same process on the same host.

CrowdSec separates them. Parsers and scenarios produce decisions in one engine, and bouncers enforce them wherever they run, which is what allows logs from several sources to be analysed in one place and blocked at several levels of the stack. That is more configuration, and it is the reason a CrowdSec setup can protect an application through its reverse proxy and a host through its firewall from the same decision. The trade-off is operational surface: more components, a database, and a hub whose items you update over time. fail2ban needs none of that, and for a single host watching a single SSH log it remains the smaller answer.

## Maintenance, upgrade cost and the MIT licence

The repository is not archived, and the last push was on 2026-09-18, with v1.8.1 released on 2026-09-03 after v1.8.0 on 2026-08-31. That is a project shipping releases and commits on a short cadence, which cuts both ways: fixes arrive quickly, and so do changes you have to absorb.

The upgrade cost is not the binary. It is the hub. Parsers, scenarios and bouncers are versioned artefacts you install and update, and a new engine release can change what a hub item expects. The Makefile shows the build side of that complexity: a C++ re2 dependency by default, with BUILD_RE2_WASM=1 as a fallback that the file itself calls slower and not recommended for production, and a choice between the mattn and modernc SQLite backends where the modernc path is described as slower and not meant for production. Anyone building from source rather than installing a package inherits those decisions, and the Makefile's own first check is that GNU make is at least 4.1.

The licence is MIT for the repository, and the README states that detection rules on the hub are also under MIT. The console, extra blocklists and premium features are separate offerings reached through an account, so the open source core and the commercial surface are not the same thing. Whether that matters depends on which features you need; this is a description of the split, not legal advice.

## Conclusion

CrowdSec suits operators who already collect logs from several sources and want one detection layer feeding several enforcement points, especially where the community blocklist adds value. It is a poor fit if you want a single self-contained firewall daemon with no outbound calls, or if you cannot run a remediation component next to the service you want to protect. Before adopting it, verify that the hub has a parser for your log format and a remediation component for your enforcement point, and check whether the console features you want sit behind an account.

## FAQ

### What does CrowdSec do?

It is an open source security engine that analyses log sources and HTTP requests to detect bad behaviour, then produces decisions that separate remediation components enforce. The README calls it an all-in-one IDS/IPS and WAF.

### Is CrowdSec free?

The repository is MIT licensed and the README states that detection rules on the hub are available under MIT. The console is a separate offering that the README describes as adding visualisation, management, extra blocklists and premium features.

### Can I use CrowdSec with OPNsense?

The README lists OpnSense among the platforms the documentation covers for installation, alongside Linux, Windows, Docker and Kubernetes. It does not describe the OPNsense setup steps themselves.

### How do I install CrowdSec?

The README does not inline install commands; it points to the documentation for Linux, Windows, Docker, OpnSense and Kubernetes. The repository also ships a wizard.sh at the top level and debian and rpm packaging directories.

### How do I install CrowdSec with Docker?

The README lists Docker among the supported installation targets and links to the documentation for it. The repository also includes a .dockerignore at the top level, and the config and data directories need to persist across container restarts.

### How do I install CrowdSec on Ubuntu?

The README does not give Ubuntu-specific steps; it points to the documentation for installation, and the repository ships debian packaging and a wizard.sh at the top level. The documentation is the source for the exact commands.

## Sources

- [crowdsecurity/crowdsec on GitHub](https://github.com/crowdsecurity/crowdsec)
- [License: MIT](https://github.com/crowdsecurity/crowdsec/blob/master/LICENSE)
- [Project website](https://crowdsec.net)
- [README](https://github.com/crowdsecurity/crowdsec/blob/master/README.md)
- [Releases](https://github.com/crowdsecurity/crowdsec/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/crowdsecurity-crowdsec