Crowdsec : Détection, Remédiation Et Console

Trois rôles, pas un seul logiciel

• Le moteur de sécurité lit des journaux ou des requêtes HTTP, les comprend, et produit des décisions. Il n'écrit pas dans le pare-feu tout seul.
• Le composant de remédiation (encore souvent appelé bouncer) applique ces décisions : nftables, Nginx, Traefik, ou la liste d'IP côté Cloudflare.
• La console inscrit le moteur, montre les alertes, et abonne le serveur à des listes de blocage. Les signaux partagés bloquent une adresse avant qu'elle n'ait essayé votre machine.

Un moteur sans bouncer enregistré est un détecteur. cscli bouncers list vide signifie qu'aucune décision n'est appliquée sur place. C'est acceptable seulement si le blocage est fait ailleurs, par exemple sur Cloudflare, et que ce moteur ne sert qu'à voir et à partager.

Du journal à la décision

Le moteur ne lit pas une ligne au hasard. Une collection du Hub apporte trois pièces.

1. L'acquisition désigne le fichier ou le flux : /var/log/auth.log, le journal Nginx, le journal du conteneur.
2. Le parser en sort une adresse, un utilisateur, un code HTTP, un chemin.
3. Le scénario compte un comportement. Cinq échecs SSH en peu de temps, un balayage d'URLs, un remplissage de formulaire. Le seuil franchi crée une alerte, puis une décision.

Une décision a un type, une durée et une portée. Les types utiles au quotidien sont ban (refus), captcha (défi dans le navigateur) et throttle (débit limité). Quatre heures sur une IP qui tente des mots de passe est un réglage de départ raisonnable. Une décision permanente sur une seule erreur ne l'est pas.

On vérifie avec cscli alerts list et cscli decisions list. Une alerte sans décision, ou une décision sans bouncer, ne change pas le trafic.

Où bloquer

On choisit le point le plus en amont que l'on maîtrise vraiment.

• cs-firewall-bouncer écrit les adresses bannies dans nftables ou iptables. SSH, les panels et les ports qui ne passent pas par le web sont couverts. C'est le premier bouncer sur un VPS.
• cs-nginx-bouncer ou le bouncer du reverse proxy (Traefik, HAProxy) répond au HTTP avant l'application. Il peut renvoyer un captcha, pas seulement un refus silencieux.
• Bouncer Cloudflare pousse les décisions vers le compte Cloudflare. L'IP est refusée au edge. Elle ne consomme plus la bande passante du serveur, et elle ne voit pas l'origine si le proxy orange est en place.

Le bouncer s'enregistre auprès du moteur à l'installation. S'il n'apparaît pas dans cscli bouncers list, on reprend la clé d'API dans sa configuration et on le redémarre. Une clé d'un autre moteur, ou une URL locale fausse, donne un bouncer qui tourne sans rien appliquer.

AppSec, le volet WAF

Les scénarios sur les journaux voient l'attaque après coup, ou après plusieurs essais. Le composant AppSec, dans le moteur depuis la branche 1.5, regarde la requête en cours. Le bouncer web compatible lui transmet la requête sur un port local (souvent 127.0.0.1:7422). Les règles in-band répondent tout de suite : refus ou captcha. Les règles hors bande nourrissent les scénarios et les décisions plus longues.

Le Hub fournit le virtual patching (CVE connues), des signatures génériques et une configuration par défaut. Installer la collection ne suffit pas : il faut le fichier d'acquisition appsec, le redémarrage du moteur, et un bouncer réglé sur la même adresse d'écoute. Un scénario de test, crowdsecurity/appsec-generic-test, confirme le circuit sans bannir personne. L'alerte doit apparaître dans cscli alerts list.

AppSec ne dispense pas de corriger l'application. Il coupe les requêtes qui ressemblent à une faille déjà connue, le temps d'appliquer le correctif.

Console, listes et plusieurs serveurs

L'enrôlement se fait avec cscli console enroll et le code affiché dans la console. Le moteur envoie des signaux et reçoit les listes auxquelles il est abonné. Ce partage est le point qui distingue CrowdSec d'un fail2ban local : une IP déjà vue en train de balayer d'autres serveurs peut être refusée chez vous à son premier paquet.

La console montre, par moteur, les alertes, les décisions actives et les composants de remédiation. Un bouncer inactif y apparaît : c'est souvent là qu'on découvre qu'un redémarrage a perdu la clé. Les métriques de rejet disent si la liste communautaire travaille, ou si seul le scénario local produit des bans.

Avec plusieurs machines, la synchronisation des remédiations pousse une décision prise sur un moteur vers les autres moteurs enrôlés, et vers les intégrations de listes (le edge Cloudflare, par exemple). Un bruteforce SSH vu sur le serveur de secours ferme aussi la porte du serveur principal.

On peut aussi alimenter un bouncer sans moteur local, depuis une intégration de liste dans la console : une clé et une URL, et le composant télécharge les adresses. Utile pour un équipement de bord qui ne sait pas lire les journaux. Dès que le serveur produit lui-même des journaux, le moteur local reste le bon choix, parce que vos propres scénarios ne sont pas dans la liste communautaire.

Ordre d'installation

1. Moteur, puis la collection qui correspond aux journaux réellement écrits (SSH, Nginx). Un parser pointé vers un fichier vide n'alertera jamais.
2. Pare-feu bouncer. Contrôle : cscli bouncers list montre une ligne, et une décision de test disparaît du pare-feu à son expiration.
3. Enrôlement console et abonnement à la liste communautaire. On surveille les faux positifs une semaine avant d'allonger les durées.
4. Bouncer du reverse proxy, puis AppSec si le site est exposé.
5. Bouncer Cloudflare une fois le domaine en proxy orange. Les bans web quittent le VPS.
6. SSH par clé uniquement, sans mot de passe, sans connexion root directe. CrowdSec limite les scans. Il ne répare pas un mot de passe réutilisé.

Ce qu'il ne faut pas lui faire porter

• Bannir large sur un scénario trop sensible. Un réseau d'entreprise ou un opérateur mobile partage des adresses : un ban d'une heure vaut mieux qu'un ban d'une semaine sur un premier réglage.
• Oublier les journaux des conteneurs. Si Nginx tourne dans Incus et que le moteur lit les journaux de l'hôte, il ne voit pas les échecs du site.
• Laisser la clé d'API du bouncer dans un dépôt. Elle se régénère avec cscli bouncers add.
• Compter sur la détection seule le jour d'un incident. Le composant de remédiation fait partie de la mise en service, pas d'une étape ultérieure.

La référence des composants est dans la documentation des remédiations, et le volet WAF dans AppSec. Le tableau de bord des moteurs enrôlés est la console CrowdSec.

Devant le même site, Cloudflare absorbe le trafic public et CrowdSec décide qui n'entre pas. L'un sans l'autre laisse soit l'origine exposée, soit les décisions sans effet.