Blog d'Ange Bonkoski

CrowdSec, et le test qui ne prouvait rien

Sun, 18 Oct 2026 12:00:00 +0200

J’ai installé CrowdSec sur mon homelab pour une raison simple : je voulais savoir si quelqu’un s’en prenait à mon serveur. L’installation s’est bien passée. Les alertes, elles, n’arrivaient pas sur Discord. Et la commande censée les tester me répondait… rien. Ni succès, ni erreur.

Cet article raconte comment j’ai trouvé la panne, et pourquoi la leçon dépasse largement CrowdSec.

CrowdSec en deux minutes

CrowdSec est un outil de détection d’intrusion. Il fonctionne comme une chaîne :

journaux → analyseurs → scénarios → alerte → notification
(SSH, web) (lisent (reconnaissent (décision) (Discord)
 chaque ligne) une attaque)

Il lit les journaux du serveur : ici, les connexions SSH et les accès au reverse proxy.
Des analyseurs découpent chaque ligne (adresse IP, utilisateur, résultat).
Des scénarios reconnaissent un comportement suspect, par exemple une rafale d’échecs de connexion SSH depuis la même adresse en quelques secondes : une attaque par force brute.
Une alerte est créée, et un plugin l’envoie ailleurs, ici vers un salon Discord privé.

CrowdSec peut aussi bloquer les adresses fautives, grâce à un composant séparé (un bouncer). Je ne l’ai pas installé, volontairement : mon serveur n’a aucun port ouvert sur Internet, donc aucune attaque extérieure ne peut l’atteindre. Mon but était d’apprendre la chaîne de détection et de surveiller ce qui se passe, pas de risquer de me bloquer moi-même.

Le symptôme

CrowdSec propose une commande pour tester une notification :

cscli notifications test http_default

Elle s’exécutait sans erreur. Sa sortie montrait le plugin qui démarre, puis qui s’arrête. Et sur Discord : rien. J’ai relancé plusieurs fois, en modifiant la configuration entre deux essais. Toujours rien.

Séparer les couches

Quand une chaîne de plusieurs maillons ne fonctionne pas, deviner ne sert à rien. J’ai testé chaque maillon seul, en partant du bout.

Maillon 1 : Discord reçoit-il quoi que ce soit ?

Un webhook Discord est une simple adresse à laquelle on envoie un message. On peut donc le tester sans CrowdSec. Problème : l’image de CrowdSec ne contient pas curl. Plutôt que d’installer quoi que ce soit, j’ai utilisé un conteneur jetable qui ne contient que curl et disparaît après usage :

docker run --rm --env-file .env curlimages/curl \
 sh -c 'curl -s -o /dev/null -w "%{http_code}\n" \
 -H "Content-Type: application/json" \
 -d "{\"content\":\"Test du webhook\"}" "$DISCORD_WEBHOOK"'

Réponse : 204, et le message est apparu sur Discord. Le webhook fonctionnait. Le problème était donc en amont.

Maillon 2 : CrowdSec lit-il le bon fichier ?

cscli notifications list indiquait bien http_default comme actif. Mais « actif » voulait seulement dire qu’un fichier portait ce nom. En regardant le fichier réellement présent dans le conteneur, sa date et sa taille, j’ai compris : c’était le fichier par défaut livré avec l’image, pas le mien. Ma configuration n’avait jamais été chargée.

« Actif » n'est pas « chargé »

Une commande qui liste une configuration ne prouve pas que c’est la vôtre. Allez voir le fichier réellement utilisé par le programme : sa date de modification et sa taille disent la vérité.

Maillon 3 : la commande de test teste-t-elle vraiment quelque chose ?

En corrigeant le fichier, j’ai aussi compris pourquoi le test restait muet. La commande démarre le plugin, lui confie le message… et s’arrête avant que l’envoi ait eu le temps de se faire. Ma configuration ajoutait en plus un délai de regroupement de 60 secondes avant chaque envoi : le test ne pouvait jamais aboutir. J’ai retiré ce délai, et j’ai cessé de me fier à cette commande.

La vraie preuve : une vraie alerte

Pour prouver que toute la chaîne fonctionne, il faut un test qui la traverse entièrement, comme le ferait une vraie attaque. J’ai donc créé une décision manuelle contre une adresse fictive :

cscli decisions add --ip 203.0.113.99 --reason "test de bout en bout"

L’alerte est arrivée sur Discord en quelques secondes. Puis j’ai supprimé cette décision de test.

Pourquoi 203.0.113.99 ? Parce que cette plage (203.0.113.0/24) est réservée à la documentation : elle n’appartient à personne. C’est une bonne habitude, dans un test comme dans un article, pour ne jamais viser l’adresse de quelqu’un par erreur.

Le piège suivant : les adresses privées

J’ai voulu aller plus loin et simuler une vraie attaque par force brute SSH depuis mon propre PC. Rien ne s’est déclenché. Normal : par défaut, CrowdSec ignore les adresses privées (le réseau local, Docker, Tailscale). Une attaque venant de l’intérieur passe donc sous ses radars.

Pour vérifier qu’un scénario reconnaît bien une ligne de journal, CrowdSec propose cscli explain. On lui donne une fausse ligne avec une adresse de documentation, et il montre chaque étape : quel analyseur l’a lue, quels scénarios se sont activés.

cscli explain --type syslog \
 --log "Oct 18 10:00:00 serveur sshd[1234]: Failed password for invalid user test from 203.0.113.5 port 4242 ssh2"

Ce que j’en retiens

Un test qui ne dit rien ne prouve rien. Ni succès ni erreur, ce n’est pas « ça marche ».
Tester chaque maillon seul, en partant du bout. Le webhook, puis le fichier, puis le plugin : chaque étape élimine une hypothèse.
Préférer une vraie alerte à une commande de test. Elle emprunte le même chemin qu’une attaque réelle.
Connaître les angles morts de son outil. Ignorer les adresses privées est un choix raisonnable, mais il faut le savoir.
Un secret peut fuiter par un message d’erreur. Une erreur d’envoi peut afficher l’adresse complète du webhook, qui suffit à quiconque pour écrire dans mon salon Discord. Avant de partager un journal, je masque toujours ce genre d’information.

La sauvegarde qui s'est évaporée

Sun, 18 Oct 2026 11:00:00 +0200

Le 9 octobre, en cherchant où ajouter une nouvelle tâche planifiée sur mon serveur, j’ai tapé crontab -l. La réponse était vide. Ma sauvegarde nocturne, celle qui protège mon coffre de mots de passe, n’existait plus.

Elle ne s’était pas lancée la nuit précédente. Et aucune de mes alertes n’avait sonné.

Le dispositif de sauvegarde

Chaque nuit à 3 h 30, un script sauvegarde les données importantes du serveur avec restic, un outil qui produit des sauvegardes chiffrées, dédupliquées et versionnées. Le script :

fait une copie cohérente de la base de données du coffre, sans l’arrêter ;
l’envoie dans le dépôt restic, sur un disque séparé ;
supprime les anciennes versions selon une règle de rétention ;
vérifie un échantillon des données ;
signale « tout va bien » à ma supervision (Uptime Kuma), seulement si toutes les étapes ont réussi.

Uptime Kuma attend ce signal. S’il ne reçoit rien pendant 26 heures, il m’envoie une alerte sur Discord. Sur le papier, une sauvegarde manquée ne pouvait donc pas passer inaperçue.

La chronologie

Moment	Ce qui s’est passé
8 oct., 3 h 30	Dernière sauvegarde réussie.
8 oct., 17 h 40	Je redémarre le serveur pour valider un changement de configuration SSH, sans aucun rapport avec les sauvegardes.
9 oct., 3 h 30	Aucune sauvegarde. Aucun message.
9 oct., après-midi	Plusieurs redémarrages pour d’autres travaux. Uptime Kuma affiche toujours « en ligne ».
9 oct., 17 h 40	Je découvre par hasard que la tâche planifiée a disparu.

Première énigme : où est passée la tâche ?

Mon serveur tourne sous ZimaOS, un système conçu pour faire tourner des conteneurs. Pour être robuste, il ne ressemble pas à une distribution Linux classique :

Zone	Comportement
`/` (le système)	en lecture seule
`/etc` (la configuration)	modifiable et conservée
`/var`	en mémoire vive (tmpfs) : vidée à chaque démarrage
la partition de données	modifiable et conservée

Or, quand on crée une tâche avec crontab -e, cron l’enregistre dans /var/spool/cron/. Sur ZimaOS, ma tâche vivait donc dans la mémoire vive. Elle a fonctionné parfaitement jusqu’au premier redémarrage, qui l’a effacée sans un bruit.

Attention

Sur un système dont /var est en tmpfs, crontab -e semble fonctionner : la tâche s’affiche, elle se lance, tout a l’air normal. Le problème n’apparaît qu’au redémarrage suivant, parfois des semaines plus tard.

Deuxième énigme : pourquoi aucune alerte ?

C’est la question qui m’a le plus appris. Deux défauts se sont cumulés.

Un script qui ne se lance pas ne peut rien signaler. Mon script envoie « échec » quand une étape échoue. Mais là, il n’a jamais démarré. Il ne restait que le délai de 26 heures pour me prévenir.

Le chien de garde redémarrait avec ce qu’il surveillait. Uptime Kuma tourne sur le même serveur. À chaque redémarrage de l’après-midi, son compte à rebours de 26 heures repartait de zéro. Il aurait fini par m’alerter… si j’avais arrêté de redémarrer.

Leçon

Un chien de garde doit vivre ailleurs que ce qu’il garde. Quand le serveur tombe, la supervision qui tourne dessus tombe avec lui.

La correction : un timer systemd

Puisque /etc est conservé, la tâche doit être déclarée là. J’ai remplacé la ligne cron par un timer systemd : un couple de deux petits fichiers.

Le service dit quoi lancer :

# /etc/systemd/system/sauvegarde.service
[Unit]
Description=Sauvegarde restic nocturne

[Service]
Type=oneshot
ExecStart=/chemin/vers/sauvegarde.sh

Le timer dit quand le lancer :

# /etc/systemd/system/sauvegarde.timer
[Unit]
Description=Lance la sauvegarde chaque nuit à 3 h 30

[Timer]
OnCalendar=*-*-* 03:30:00
Persistent=true

[Install]
WantedBy=timers.target

La ligne Persistent=true est le vrai gain par rapport à cron : si le serveur était éteint à 3 h 30, la sauvegarde est lancée dès le démarrage suivant au lieu d’être simplement sautée.

On active le timer, puis on vérifie la date du prochain lancement :

sudo systemctl daemon-reload
sudo systemctl enable --now sauvegarde.timer
systemctl list-timers sauvegarde.timer

Je n’ai pas considéré le problème réglé avant de l’avoir prouvé : un redémarrage, puis systemctl list-timers à nouveau. Le timer était toujours là.

L’erreur pendant la correction

J’ai aussi fait une erreur en corrigeant. J’ai deux scripts aux noms proches : celui qui fait la sauvegarde complète, et un petit outil qui transmet ses arguments à restic. Mon premier service lançait… le second. Résultat : le journal ne contenait que l’aide de restic.

Depuis, ma documentation distingue clairement les deux, avec une phrase pour chacun : ce qu’il fait, et quand on l’utilise.

Ce que j’en retiens

Un changement peut casser quelque chose qui n’a rien à voir avec lui. J’avais redémarré pour tester SSH, pas les sauvegardes.
Connaître son système avant d’y appliquer ses habitudes. crontab -e est un bon réflexe sur une Debian, un piège sur ZimaOS.
Une absence de nouvelles n’est pas une bonne nouvelle. Le silence peut vouloir dire « tout va bien » comme « rien ne s’est lancé ».
Vérifier les tâches planifiées après chaque redémarrage, au moins tant qu’on n’a pas prouvé qu’elles survivent.

Il me reste un chantier ouvert : déplacer ce chien de garde hors du serveur, pour qu’une panne complète déclenche enfin une alerte.

Zéro port ouvert : Cloudflare Tunnel pour le public, Tailscale pour le privé

Sun, 18 Oct 2026 10:00:00 +0200

Pendant des semaines, mon serveur maison était joignable depuis Internet de la façon la plus classique qui soit : deux redirections de ports sur ma box, le 80 et le 443, vers un reverse proxy. Ça marchait. Et c’est justement le problème : ça marchait pour tout le monde.

Aujourd’hui, ma box n’a plus aucune redirection. Mon portfolio est toujours en ligne, et j’accède toujours à mes services privés depuis mon téléphone en 4G. Voici comment, et surtout pourquoi.

Le point de départ

Mon homelab est un vieux PC portable sous ZimaOS, qui fait tourner une dizaine de services dans des conteneurs Docker : mon portfolio, un gestionnaire de mots de passe (Vaultwarden), de la supervision, un filtre DNS…

Pour les rendre accessibles de l’extérieur, j’avais fait ce que font la plupart des tutoriels :

un enregistrement DNS qui pointe vers l’IP publique de ma box ;
une redirection des ports 80 et 443 de la box vers le serveur ;
un reverse proxy (Nginx Proxy Manager) qui répartit les requêtes entre les services selon le nom de domaine demandé.

Pourquoi ce n’était pas acceptable

Un port ouvert, c’est une porte d’entrée que n’importe qui peut essayer de pousser. Et sur Internet, quelqu’un essaie en permanence : des robots balayent toutes les adresses IPv4 en continu, à la recherche d’un service mal configuré ou pas à jour.

Trois choses me gênaient en particulier :

mon coffre de mots de passe était joignable par le monde entier. Il était protégé par un mot de passe maître et une double authentification, mais une seule faille dans Vaultwarden aurait suffi ;
mon IP publique apparaissait dans mon DNS. N’importe qui pouvait savoir où se trouve mon serveur, et donc ma connexion personnelle ;
toute la sécurité reposait sur un seul logiciel, le reverse proxy, en première ligne face à Internet.

Je me suis fixé une règle simple : ce qui doit être public l’est ; tout le reste ne doit même pas être visible.

L’idée : inverser le sens de la connexion

Une redirection de port, c’est la box qui accepte des connexions entrantes. Le pare-feu de la box, lui, bloque déjà tout ce qui entre sans avoir été demandé. Il suffit donc de ne rien lui demander d’accepter.

Le principe est le suivant : c’est le serveur qui ouvre lui-même une connexion sortante vers un service extérieur, et c’est par ce tuyau déjà ouvert que les visiteurs arrivent. Vu de la box, il n’y a qu’une connexion sortante, comme quand vous ouvrez un site web. Rien n’entre.

J’ai utilisé deux outils construits sur cette idée, un pour chaque usage.

Le chemin public : Cloudflare Tunnel

Mon portfolio doit rester accessible à n’importe quel recruteur, sans logiciel à installer. Pour lui, j’utilise Cloudflare Tunnel.

Un petit conteneur, cloudflared, tourne sur le serveur. Au démarrage, il ouvre une connexion chiffrée vers Cloudflare et la garde ouverte. Le domaine pointe vers Cloudflare, plus vers ma box :

Visiteur → DNS → Cloudflare (pare-feu applicatif, cache)
 → tunnel (connexion sortante ouverte par le serveur)
 → cloudflared → serveur web du portfolio

Le fichier Compose tient en quelques lignes. Le jeton qui identifie le tunnel n’y est pas écrit : il est lu dans un fichier .env séparé, lisible seulement par son propriétaire.

services:
 cloudflared:
 image: cloudflare/cloudflared:latest
 restart: unless-stopped
 command: tunnel --no-autoupdate run
 environment:
 - TUNNEL_TOKEN=${TUNNEL_TOKEN}  # lu dans .env, jamais en clair ici

Au passage, mon IP publique a disparu du DNS : on ne voit plus que celles de Cloudflare.

Le prix de ce confort

Cloudflare termine le chiffrement TLS : il voit passer le trafic du site en clair avant de le renvoyer dans le tunnel. Pour un portfolio public, ça ne me dérange pas. Pour un service qui manipule des données sensibles, c’est une vraie question de confiance. C’est d’ailleurs pour ça que mon coffre de mots de passe n’emprunte pas ce chemin.

Les chemins privés : Tailscale

Pour tout le reste (coffre de mots de passe, administration, partage de fichiers, SSH), il n’y a qu’un seul public : moi. Pas besoin de les exposer au monde ; il suffit que mes appareils puissent les joindre.

Tailscale crée un réseau privé chiffré (basé sur WireGuard) entre mon serveur, mon PC, mon Mac et mon iPhone. Chaque appareil reçoit une adresse dans une plage réservée, qui n’a de sens que sur ce réseau. Et là encore, chaque appareil n’ouvre que des connexions sortantes : aucune redirection n’est nécessaire.

Restait un détail : je voulais garder une vraie adresse, avec un vrai certificat HTTPS, pour que les applications de mon gestionnaire de mots de passe fonctionnent comme avant. La solution tient en trois morceaux.

1. Un DNS qui pointe vers une adresse privée. Le sous-domaine du coffre renvoie l’adresse Tailscale du serveur. Tout le monde peut lire cet enregistrement, mais cette adresse ne mène nulle part si l’on n’est pas dans mon réseau Tailscale.

2. Un certificat obtenu sans port ouvert. Let’s Encrypt doit vérifier que je contrôle bien le domaine avant de délivrer un certificat. La méthode habituelle (le défi HTTP) consiste à venir chercher un fichier sur mon serveur… ce qui est impossible, puisque plus rien n’est joignable. J’utilise donc le défi DNS : le reverse proxy crée lui-même un enregistrement temporaire dans ma zone DNS, grâce à un jeton d’API Cloudflare limité à cette seule zone.

3. Un relais pour le port 443. Sur mon serveur, l’interface de ZimaOS occupe déjà le port 80, et le reverse proxy écoute sur d’autres ports. C’est Tailscale qui reçoit le 443 sur son interface et le relaie vers le reverse proxy :

tailscale serve --bg --tcp 443 tcp://localhost:<port-https-du-proxy>

La commande à ne jamais lancer

tailscale serve reset efface tous les relais configurés. Je l’ai appris en la lançant : mon coffre est devenu injoignable jusqu’à ce que je recrée le relais.

Vérifier, plutôt que supposer

Une fois les redirections supprimées dans l’interface de la box, je n’ai pas considéré que c’était fini. J’ai vérifié chaque promesse depuis l’extérieur, avec mon iPhone en 4G (donc hors de mon réseau local) :

Test	Tailscale coupé	Tailscale actif
Portfolio	accessible	accessible
Coffre de mots de passe	injoignable	accessible
IP publique de la box	aucune réponse	—
Partages de fichiers	injoignables	accessibles

J’ai aussi balayé l’adresse IPv6 publique du serveur. Contrairement à l’IPv4, une adresse IPv6 désigne directement la machine, sans traduction d’adresse par la box : c’est un oubli classique. Résultat : tous les ports testés fermés ou filtrés.

L'échec qui prouve que ça marche

Plus tard, en ajoutant un nouveau service, j’ai oublié de cocher le défi DNS : la demande de certificat en défi HTTP a échoué. Let’s Encrypt n’avait pas pu joindre mon serveur depuis Internet. Cette erreur était la meilleure preuve possible que l’isolement tenait.

Ce que j’en retiens

Ne pas confondre « accessible » et « exposé ». Mes services privés sont accessibles partout où je vais, mais ne sont exposés à personne.
Séparer les chemins selon le public. Un visiteur anonyme et moi n’avons pas besoin d’emprunter la même porte.
Tester depuis l’extérieur. Depuis le Wi-Fi de la maison, tout semble toujours fonctionner. C’est en 4G qu’on voit ce qui est vraiment exposé.
Chaque choix a un coût. Le tunnel me rend dépendant de Cloudflare : si le conteneur cloudflared s’arrête, le portfolio tombe. Ma supervision me prévient dans ce cas.

Il reste une limite que j’assume : à l’intérieur de mon réseau local, les services écoutent encore sur toutes les interfaces. La prochaine étape est de réduire aussi cette surface-là.