Protéger Vaultwarden, Forgejo, WordPress avec CrowdSec : tutoriel 2026

📍 Article principal de la série : CrowdSec 2026 : guide pratique.

Vos applications auto-hébergées sont exposées : Vaultwarden, Forgejo, WordPress, Coolify. CrowdSec offre des collections dédiées à chacune avec scenarios prêts à détecter brute-force login, enumeration utilisateurs, scan paths sensibles. Ce tutoriel détaille la configuration spécifique pour les 3 apps les plus déployées chez les PME francophones.

Prérequis

• CrowdSec installé (voir tutoriel installation).
• Bouncers Caddy/Nginx configurés.
• Vaultwarden et/ou Forgejo et/ou WordPress en production.
• Niveau attendu : intermédiaire.
• Temps estimé : 30-60 minutes.

Protection Vaultwarden

Étape 1 — Collection Vaultwarden

cscli collections install LePresidente/vaultwarden
cscli scenarios list | grep vaultwarden

Scenarios installés :

• LePresidente/vaultwarden-bf : brute-force login.
• LePresidente/vaultwarden-enum : enumeration utilisateurs (test multiples emails).

Étape 2 — Pointer parser sur logs Vaultwarden

Vaultwarden logs dans /var/lib/coolify/services/vaultwarden-prod/data/vaultwarden.log. Configuration acquisition :

nano /etc/crowdsec/acquis.yaml

filenames:
  - /var/lib/coolify/services/vaultwarden-prod/data/vaultwarden.log
labels:
  type: vaultwarden

systemctl restart crowdsec

Étape 3 — Test détection

Tenter 6 logins avec mauvais password depuis IP test. CrowdSec doit créer alerte :

cscli alerts list | grep vaultwarden

Protection Forgejo

Étape 1 — Collection Forgejo

cscli collections install crowdsecurity/gitea
# Forgejo est compatible Gitea

Étape 2 — Configuration acquisition Forgejo

cat >> /etc/crowdsec/acquis.yaml << EOF
filenames:
  - /var/lib/coolify/services/forgejo-prod/data/log/gitea.log
labels:
  type: gitea
EOF
systemctl restart crowdsec

Étape 3 — Scenarios Forgejo

• Brute-force login.
• Brute-force git push.
• Enumeration users via API public.

Protection WordPress

Étape 1 — Collection WordPress

cscli collections install crowdsecurity/wordpress

Étape 2 — Acquisition Caddy/Nginx

WordPress n’a pas de log natif utile. CrowdSec parse les logs Caddy/Nginx pour détecter :

• Brute-force /wp-login.php.
• Scan /wp-admin/, /xmlrpc.php.
• Probe plugins vulnérables (XSS, RCE patterns).
• Enumeration utilisateurs via /?author=N.

filenames:
  - /var/log/caddy/access.log
labels:
  type: caddy

Étape 3 — Whitelist legitimate plugins

Éviter de bloquer Updraft Plus, Wordfence, Yoast SEO qui font des appels API légitimes. Whitelist par user-agent ou path :

# /etc/crowdsec/parsers/s02-enrich/whitelists.yaml
whitelist:
  expression:
    - evt.Parsed.user_agent contains "WordPress/6"

Protection Coolify lui-même

filenames:
  - /var/log/coolify/access.log
labels:
  type: coolify

cscli scenarios install crowdsecurity/http-bf-wordpress_bf
cscli scenarios install crowdsecurity/http-cve-2024-XXXX

Dashboard CrowdSec Console

Une fois connecté à console.crowdsec.net :

• Vue temps réel des alertes.
• Top scenarios déclenchés.
• Géolocalisation attaquants.
• Top IPs bannies.

Erreurs fréquentes

Réalités locales : ce qui change à Dakar et Abidjan

Trois précisions. WhatsApp Business webhook : si plugin WP envoie webhooks Wave/Orange Money, whitelist leurs IPs. Plugins WordPress français : Yoast, WP Rocket, MonsterInsights tous légitimes, à whitelist par user-agent. Forgejo Actions runners : runners auto-hébergés font multiples appels API, exclure leur IP de la détection.

Tutoriels frères

• Installer CrowdSec sur VPS
• Bouncers Caddy et Nginx

FAQ

Combien de temps avant détection ? Premier ban dans 5-15 minutes après installation, selon trafic. Communautaire applique immédiatement 4M IPs connues.

Custom scenarios ? Oui, fichiers YAML dans /etc/crowdsec/scenarios/. Documentation détaillée.

Performance VPS petit ? CX23 (4 Go RAM) supporte CrowdSec + 5 apps + bouncers. Aucun lag.

Multi-app sur même VPS ? Oui, parsers détectent type log via labels.

Coolify built-in ? Coolify n’inclut pas CrowdSec par défaut. Installation manuelle sur l’hôte.

Pour creuser ce sujet

• 🔝 Retour au guide général : guide pratique CrowdSec 2026
• Hub Collections : hub.crowdsec.net

Étape A — Comprendre le modèle CrowdSec en 2 minutes

CrowdSec v1.6+ fonctionne en deux temps : un parser lit vos logs (Caddy, Nginx, Vaultwarden, Forgejo, WordPress) et normalise chaque ligne ; un scenario détecte un pattern d’attaque (force brute, scan, énumération) et déclenche une decision qui pousse l’IP malveillante dans une base locale. Le bouncer (côté Caddy/Nginx/firewall) consomme ces décisions et bloque le trafic. Sans bouncer, CrowdSec détecte mais ne bloque rien — erreur classique du débutant.

Pour un environnement Coolify type (Caddy reverse proxy + plusieurs applications self-hosted), installez CrowdSec sur l’hôte Docker, montez les sockets logs en lecture, et ajoutez le bouncer Caddy (crowdsec-caddy-bouncer) directement dans la config Caddy. Cette architecture évite de toucher chaque conteneur applicatif.

Étape B — Installer CrowdSec sur Ubuntu 24.04

Sur le VPS Hetzner qui héberge Coolify, installez CrowdSec via le repo officiel :

curl -s https://install.crowdsec.net | sudo sh
sudo apt install -y crowdsec crowdsec-firewall-bouncer-iptables
sudo systemctl enable --now crowdsec
sudo cscli capi register
sudo cscli console enroll YOUR-CONSOLE-TOKEN

Le cscli capi register connecte votre instance au Central API CrowdSec qui partage la blocklist communautaire (≈ 2 millions d’IPs malveillantes en temps réel). Sortie attendue : cscli metrics affiche un tableau avec parsers, scenarios et bouncers actifs. Si la colonne « Read » reste à 0 pour Caddy, le parser ne voit pas vos logs — vérifiez le chemin dans /etc/crowdsec/acquis.yaml.

Étape C — Collection Vaultwarden et règle force brute

Vaultwarden expose des logs JSON dans /var/log/vaultwarden/vaultwarden.log si vous avez activé LOG_FILE dans son env. Installez la collection officielle :

sudo cscli collections install crowdsecurity/vaultwarden
sudo systemctl reload crowdsec

Cette collection charge un parser qui détecte les tentatives Username or password is incorrect, et un scenario qui ban une IP après 5 échecs en 10 minutes. Testez en lançant 6 logins échoués depuis un VPN, puis cscli decisions list doit afficher l’IP avec un timer de bannissement.

Étape D — Collection Forgejo et règle énumération SSH

Forgejo (fork de Gitea) est souvent attaqué via SSH (port 222 ou 2222 si vous l’avez déplacé) et via l’API HTTP. Installez :

sudo cscli collections install crowdsecurity/forgejo
sudo cscli parsers install crowdsecurity/sshd-logs

Déclarez vos sources dans /etc/crowdsec/acquis.yaml en ajoutant le filepath des logs Forgejo (souvent /var/log/forgejo/forgejo.log ou via Docker socket). Sortie attendue : cscli scenarios list liste désormais crowdsecurity/forgejo-bf et crowdsecurity/ssh-bf en mode actif.

Étape E — Collection WordPress et hardening xmlrpc

WordPress reçoit en moyenne 80 % de requêtes malveillantes selon Sucuri. CrowdSec dispose d’une collection dédiée :

sudo cscli collections install crowdsecurity/wordpress
sudo cscli scenarios list | grep wordpress

Cette collection détecte : énumération auteurs (?author=N), brute force wp-login.php, scan plugins via /wp-content/plugins/, abus xmlrpc.php. Pour les sites e-commerce ouest-africains qui acceptent des paiements via plugins WooCommerce Wave/Orange Money, désactivez complètement xmlrpc dans Caddy : respond /xmlrpc.php 403. Vous coupez 90 % des tentatives sans casser le site.

Étape F — Protéger Coolify lui-même

Coolify expose son UI sur le port 8000. Ne l’ouvrez jamais directement. Utilisez plutôt l’authentification Magic Link de Coolify et placez son port derrière un sous-domaine Caddy avec authentification additionnelle si vous voulez le rendre accessible depuis Internet. Pour suivre les tentatives :

sudo cscli parsers install crowdsecurity/caddy-logs
sudo cscli scenarios install crowdsecurity/http-probing

Ces deux modules détectent les scans HTTP génériques (Acunetix, Nikto, Burp). Sortie attendue : après 24h, cscli alerts list affiche typiquement 30 à 200 IPs scannées et bannies, sans intervention manuelle.

Étape G — Bouncer Caddy pour bloquer en amont

Sans bouncer, CrowdSec ne fait que détecter. Installez le bouncer Caddy dans votre Caddyfile :

{
  order crowdsec first
  crowdsec {
    api_url http://localhost:8080
    api_key YOUR-BOUNCER-API-KEY
    ticker_interval 15s
  }
}
votre-domaine.io {
  crowdsec
  reverse_proxy vaultwarden:80
}

Générez la clé via cscli bouncers add caddy-bouncer. Compilez Caddy avec le module github.com/hslatman/caddy-crowdsec-bouncer via xcaddy build ou utilisez l’image Docker ghcr.io/hslatman/caddy-crowdsec-bouncer. Sortie attendue : un curl depuis une IP bannie renvoie HTTP 403 avant même d’atteindre Vaultwarden.

Étape H — Dashboard, backup et plan d’action incident

Activez la Console CrowdSec (gratuite jusqu’à 3 machines) sur app.crowdsec.net pour visualiser les attaques en temps réel et corréler entre vos serveurs. Sauvegardez régulièrement /var/lib/crowdsec/data/crowdsec.db avec vos backups Hetzner Object Storage.

Plan d’incident : si CrowdSec ban votre propre IP (ça arrive en debug), récupérez l’accès via la console Hetzner Rescue puis cscli decisions delete --ip VOTRE-IP. Whitelistez vos IPs admin avec cscli decisions add --type captcha --ip VOTRE-IP --duration 9999h ou créez un fichier /etc/crowdsec/parsers/s02-enrich/whitelist.yaml. Pour la stack complète, voir nos tutoriels Plausible sur Hetzner avec Coolify et Astro sur Cloudflare Pages ou Coolify.