Simply a no-brainer service to run on any public facing servers
Use Cases and Deployment Scope
CrowdSec was first implemented at the most basic level, directly on a webserver running WordPress sites. This worked great as there were ways to connect CrowdSec to WordPress and capture failed logins, DDoS attacks, malicious users, etc. However, as I quickly realized that the true potential of CrowdSec would be to have it on the servers pointing a central Crowdsec Local API on the router, this way it would protect the entire network from malicious users/IPs, no matter which server or domain they were hoping to target.
Pros
- Provides great integrations with tools you already use, such as fail2ban, Cloudflare, WordPress, NGINX, Linux Firewalls, etc.
- Lightweight agents can run on individual servers and report to a main security engine so that if there's an attack on one server and a block is implemented, the entire network can be protected
- There are a lot of ways to receive alerts and store logs
- CrowdSec Central API is a nice way to manage everything externally
Cons
- Getting CrowdSec to run on OPNsense can be a challenge, but that's also a limitation of the OS
- You can only subscribe to a couple of feeds before paying an unknown amount of money that's part of their "Enterprise" package. So, there could be better transparency.
Likelihood to Recommend
Since I've only used CrowdSec in a homelab/small-medium sized business setup, that's really the only market I can safely recommend it and say it's well suited for, because I don't know how much it would cost to run it in an enterprise environment. I've heard some pricing and how they plan on rolling out a subscription model, but it's still in talks.
Either way, if you have publicly exposed web applications hosted locally or on a virtual private server, then CrowdSec should be part of every virtual machine and/or network. Even with the lmited number of filter you get out of the free subscription, it provides a nice layer of constantly updated data,
