CrowdSec could be perceived as a modern form of Fail2ban, though for Cloud and container-based infrastructure as well, and capable of taking way more advanced decisions a lot faster. Mainly, it’s using a decoupled and distributed approach (detect here, remedy there) and an inference engine that leverages leaky buckets, YAML & Grok patterns to identify aggressive behaviors. It acquires signals from various data sources like files, syslogd, journald, AWS Cloudwatch and Kinesis, Docker logs, and Windows Event Log, normalizes them, enriches them to apply heuristics and triggers a bouncer to deal with the threat if need be. Since it’s written in Go, it’s compatible with almost any environment, fast in execution, and resource-conservative.

The endgame is the Reputation engine, though. If you want to partake in the network to benefit from its findings, CrowdSec captures all aggression signals (timestamp, IP, behavior) and sends them for curation. That way, it establishes a reliable IP blacklist that is constantly redistributed to the network members to achieve a form of Digital Herd Immunity. An IP caught aggressing WordPress sites will quickly be banned by all members using CrowdSec that subscribed to the WordPress defense collection. In that way, we share the IPs that are relevant to your technical context.

While Crowdsec is in charge of the detection, the reaction is performed by "bouncers" that aim to be deployable at any level of the applicative / infrastructure stack :

• via nftables/iptables/pf based on an IP set
• via Nginx lua plugin
• via Traefik middleware
• on Cloudflare via our bouncer that integrates with Cloudflare API
• Or GCP/AWS/Azure firewall, slack or scripting, notifications, etc.

.. or in many other ways. Over time the possibilities will increase as the application design basically supports anything.

This approach, combined with a declarative configuration and a stateless behavior, will make it an ideal candidate to enhance the security of modern stacks (containers, Kubernetes, serverless, and more generally automatically deployed infrastructures).

Furthermore, we intend to create and share the most accurate database of malevolent actors possible in the form of a real-time IP reputation system accessible through API. Whenever an attack is locally blocked/detected by Crowdsec, the "meta" information of the attack is shared amongst participants (source IP, date, and triggered scenario) for redistribution to network members.

We are committed to building a strong community with all that it implies : * a public hub to find, share and amend parsers, scenarios, and blockers * permissive open-source license to stay business-friendly * and overall a strong commitment to transparency and community-first mentality by tooling and behavior

The microservice architecture is the most significant security challenge in a Kubernetes cluster. Every application you deploy opens a new potential entry for attackers, increasing the attack surface. In this talk, we'll present the Crowdsec project and see how we can protect a Kubernetes cluster using Crowdsec and the power of the Crowd.