1. Sécuriser #
Protéger le système de protection.
La LAPI #
- Ne l'exposez jamais sur Internet. Limitez le port 8080 à un réseau privé.
- Activez le TLS dès qu'agents ou bouncers traversent le réseau.
- Une clé par bouncer, stockée comme un secret et révoquée avec
cscli bouncers delete. - Protégez aussi le port 6060 : les métriques révèlent les adresses et les scénarios.
Ne pas se bloquer soi-même #
- Mettez vos adresses d'administration, VPN et supervision en allowlist avant d'installer un bouncer.
- Gardez un accès de secours : console de l'hébergeur.
- Retirez un ban en urgence :
cscli decisions delete --ip VOTRE_IP.
2. Fiabiliser #
Tenir dans la durée.
Le déploiement #
- Commencez sans bouncer ou en simulation, puis activez le blocage une fois les faux positifs traités.
- Fixez les versions des images et plugins, et testez les mises à jour.
- Persistez
/etc/crowdsecet/var/lib/crowdsec/dataen conteneur. - Passez à PostgreSQL ou MySQL si plusieurs agents écrivent beaucoup : SQLite convient aux petits déploiements.
- Combinez les bouncers : pare-feu pour les services d'infrastructure, proxy pour le web.
L’entretien #
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 # rapport pour le supportUne fois par mois : relisez les faux positifs, vérifiez que chaque source de logs est lue, et contrôlez que chaque bouncer a contacté récemment la LAPI.
3. Les limites #
Ce que CrowdSec ne fait pas.
Garder les idées claires #
- CrowdSec réagit : la première requête d'un attaquant inconnu passe souvent.
- Il voit des adresses : derrière un CGNAT ou un VPN, plusieurs personnes partagent une IP. Le captcha peut alors être préférable au ban.
- Il ne remplace ni les mises à jour, ni un mot de passe robuste, ni l'authentification SSH par clé.
- Il dépend de vos logs : une attaque qui ne laisse pas de trace reste invisible.
