CrowdSec in production: best practices

1. Securing #

Protecting the protection system.

The LAPI #

• Never expose it on the Internet. Limit port 8080 to a private network.
• Enable TLS as soon as agents or bouncers cross the network.
• One key per bouncer, stored as a secret and revoked with cscli bouncers delete.
• Also protect port 6060: metrics reveal addresses and scenarios.

Not blocking yourself #

• Put your admin, VPN and monitoring addresses in an allowlist before installing a bouncer.
• Keep an emergency access: hosting provider console.
• Lift a ban in an emergency: cscli decisions delete --ip YOUR_IP.

2. Making it reliable #

Lasting over time.

Deployment #

• Start without a bouncer or in simulation, then enable blocking once false positives are handled.
• Pin versions of images and plugins, and test upgrades.
• Persist /etc/crowdsec and /var/lib/crowdsec/data in containers.
• Move to PostgreSQL or MySQL if several agents write a lot: SQLite suits small deployments.
• Combine bouncers: firewall for infrastructure services, proxy for the web.

Maintenance #

sudo cscli hub update && sudo cscli hub upgrade
sudo systemctl reload crowdsec

sudo cscli metrics
sudo cscli bouncers list
sudo cscli machines list
sudo cscli support dump   # report for support

Once a month: review false positives, check that each log source is read, and verify that each bouncer has recently contacted the LAPI.

3. The limits #

What CrowdSec does not do.

Keeping a clear head #

• CrowdSec reacts: the first request from an unknown attacker often passes.
• It sees addresses: behind CGNAT or a VPN, several people share one IP. A captcha may then be preferable to a ban.
• It replaces neither upgrades, nor a strong password, nor SSH key authentication.
• It depends on your logs: an attack leaving no trace stays invisible.

Sources #

• CrowdSec Documentation
• Shattered : CrowdSec, bloquer les attaques