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.
Return on Investment
- It flat-out blocks malicious IPs from accessing any PC on my network.
- It's free-tier makes this a no brainer to implement
Other Software Used
Cloudflare, Cloudflare Workers, WordPress, NGINX, Debian OS, Ubuntu Linux, Docker, Proxmox VE, Azure Functions, Azure Logic Apps, Azure Service Bus, Azure Blob Storage, RabbitMQ, Synology DiskStation, MongoDB, Azure Cosmos DB, MariaDB Platform, PostgreSQL, Portainer