SWAG, mon reverse proxy 🔒 CrowdSec cscli, Metabase, homepage widget... (10/XX)

En bref

Cette vidéo fait partie de ma série sur le reverse proxy SWAG. Elle couvre trois points progressifs autour de CrowdSec : accéder à cscli directement depuis la machine hôte, déployer Metabase pour avoir un dashboard de supervision, et ajouter le widget CrowdSec dans homepage.

---

Le contexte : pourquoi chercher des alternatives à l’interface web CrowdSec

CrowdSec est une solution open source très puissante pour surveiller ce qui se passe sur vos services exposés sur internet — détection de comportements suspects, bots, tentatives d’exploitation de failles. Mais son interface graphique officielle, disponible sur crowdsec.net, est très limitée dans sa version gratuite. La gestion des décisions (débannir une IP, par exemple), les blocklist premium, les interactions avancées — tout ça est derrière un paywall.

Ce qui manque concrètement : une petite corbeille pour débannir une adresse IP depuis l’interface web. Ce n’est pas grand-chose, mais sans elle, il faut obligatoirement passer par la ligne de commande à l’intérieur du conteneur Docker. C’est pour ça que j’ai cherché trois solutions complémentaires, de la plus simple à la plus avancée.

---

Étape 1 — cscli directement depuis la machine hôte

cscli, c’est la ligne de commande de CrowdSec. Pour l’utiliser, il faut normalement faire un docker exec dans le conteneur CrowdSec. Ce n’est pas très pratique au quotidien.

La solution : créer un alias dans le .bashrc de la machine hôte. L’alias cscli devient une réécriture de docker exec -t crowdsec cscli — avec les arguments qui suivent propagés automatiquement. Il faut éditer le .bashrc avec nano ou vi, ajouter l’alias, sauvegarder, puis se reconnecter ou sourcer le fichier pour que ça prenne effet.

alias cscli='docker exec -t crowdsec cscli'

Une fois l’alias en place, on peut par exemple lister les décisions actives ou supprimer un ban directement depuis la machine hôte :

cscli decisions list
cscli decisions delete -i <adresse_ip>

J’ai le même principe pour OCC, la ligne de commande Nextcloud — bonus si vous l’utilisez :

alias occ='docker exec -t nextcloud occ'

---

Étape 2 — Dashboard Metabase pour superviser CrowdSec

Il n’existe pas d’interface graphique open source complète pour CrowdSec en auto-hébergement. La solution quasi-officielle était cscli dashboard — une commande qui générait automatiquement un conteneur Metabase préconfiguré. Mais cette fonctionnalité est maintenant dépréciée et ne fonctionne plus (not supported).

Il faut donc le faire à la main. Ce n’est pas très compliqué mais il y a quelques pièges.

CrowdSec fournit un Dockerfile personnalisé qui part de l’image officielle Metabase et y injecte automatiquement les assets préconfigurés pour CrowdSec — les dashboards, les requêtes SQL, tout. Le résultat : Metabase démarre déjà avec les dashboards CrowdSec prêts à l’emploi. Le lien vers ce Dockerfile est dans la description de la vidéo.

Ce nouveau service crowdsec-dashboard s’ajoute dans le docker-compose SWAG. Quelques points importants à comprendre :

Le volume de données est partagé avec CrowdSec — Metabase lit directement la base de données CrowdSec. Il faut donc que les deux services pointent vers le même répertoire. Le PUID et PGID dépendent de votre machine — sur OpenMediaVault c’est 998 et 1000, mais à vérifier sur votre installation. Si les droits ne sont pas bons, Metabase ne pourra pas lire la base.

Je ne publie pas de port direct sur la machine hôte — le service sera accessible uniquement via le reverse proxy SWAG. Je le configure en restart: unless-stopped : il redémarre sur crash mais pas sur arrêt explicite.

Les identifiants par défaut pour se connecter à Metabase sont précisés dans la description de la vidéo. Une fois connecté, vous retrouvez les dashboards préconfigurés : cartes géographiques des attaquants, tableaux des alertes, décisions actives.

Mettre le dashboard derrière SWAG

SWAG fournit un fichier de configuration exemple pour CrowdSec dashboard. Il suffit de le copier et de le renommer en crowdsec-dashboard.subdomain.conf. Deux conditions pour que ça fonctionne sans modification : le conteneur doit s’appeler crowdsec-dashboard et le sous-domaine aussi.

Je configure ce service en accès interne uniquement — aucune raison d’exposer ce dashboard sur internet. Une fois le fichier de config en place, SWAG avec auto-reload le prend en compte automatiquement. Authelia s’applique dessus comme pour les autres services.

Dernier point : une fois le dashboard accessible via le reverse proxy, je supprime le port direct exposé sur la machine hôte. Le dashboard n’est plus accessible directement — uniquement via le reverse proxy sécurisé.

---

Étape 3 — Widget CrowdSec dans homepage

Homepage peut afficher un widget CrowdSec qui montre en temps réel les alertes actives et les bans. C’est le niveau le plus délicat — pas forcément complexe, mais si on n’a pas une bonne maîtrise des réseaux Docker et des API, on peut y perdre beaucoup de temps.

Pour que homepage puisse joindre le conteneur CrowdSec sur son port 8080 (l’API locale), plusieurs conditions doivent être réunies.

Le réseau Docker : homepage doit être sur le même réseau que CrowdSec. Il faut ajouter le réseau homepage aux réseaux du conteneur CrowdSec dans le docker-compose.

L’adresse de l’API locale : vérifier avec cscli lapi status que l’API locale écoute bien sur 0.0.0.0:8080 et non 127.0.0.1:8080. En 127.0.0.1, elle n’est accessible que localement dans le conteneur — homepage ne pourra pas la joindre depuis un autre conteneur.

Les trusted IPs : CrowdSec refuse par défaut les appels depuis des machines non autorisées. Il faut ajouter les plages IP Docker dans la configuration trusted_ips de CrowdSec. Vous pouvez mettre toutes les plages Docker, c’est un peu large mais ça reste dans les réseaux internes Docker. Sinon, fixer une IP statique pour le conteneur homepage — mais attention, Docker peut changer les IPs entre les redémarrages si elles ne sont pas fixées.

La clé d’API locale : se trouve dans le fichier local_api_credentials.yaml du répertoire CrowdSec. Je l’externalise dans une variable d’environnement dans le docker-compose.

La configuration du widget se fait via des labels sur le service CrowdSec dans le docker-compose — le type du widget, les champs à afficher (alerts et bans), l’URL de l’API locale, et la clé d’API. La documentation homepage couvre ça en détail.

Déboguer quand ça ne marche pas

Les logs homepage sont très utiles. Un 401 signature invalide indique que la clé API est incorrecte. Un timeout ou une erreur réseau indique que le réseau Docker n’est pas correctement configuré entre homepage et CrowdSec. Redémarrer les deux conteneurs après chaque modification de configuration.

---

En résumé

Trois niveaux de supervision pour CrowdSec, du plus simple au plus avancé :

1. Alias cscli — 2 minutes, immédiatement utile pour gérer les bans depuis la machine hôte sans rentrer dans le conteneur
2. Dashboard Metabase — quelques dizaines de minutes, supervision visuelle complète, accessible via le reverse proxy
3. Widget homepage — plus délicat à configurer, mais résultat immédiat : un coup d’œil sur la page d’accueil suffit pour voir l’état de CrowdSec

CrowdSec reste un outil puissant même sans payer. Ces trois solutions permettent de compenser les limitations de l’interface gratuite et d’avoir une supervision correcte de son installation.