#docker — Blog d'Ange Bonkoski

Mon coffre de mots de passe ne répondait plus, et le réseau n'y était pour rien

Mon, 19 Oct 2026 09:00:00 +0200

Le 20 septembre, mon gestionnaire de mots de passe auto-hébergé a cessé de fonctionner… à moitié. Le coffre s’ouvrait parfaitement dans le navigateur. Mais l’extension Firefox affichait une erreur obscure, et l’application iPhone refusait de se connecter.

J’ai passé des heures à chercher dans la mauvaise direction. Cet article raconte comment j’en suis sorti, et surtout la petite expérience qui a tout débloqué.

Le contexte

J’héberge Vaultwarden sur mon serveur maison. C’est une réécriture légère du serveur de Bitwarden : on garde les applications officielles de Bitwarden (extension, application mobile), mais elles parlent à mon serveur plutôt qu’à celui de l’éditeur.

À l’époque, le trafic passait par Cloudflare, puis par un reverse proxy, avant d’arriver au conteneur.

Le symptôme

Le coffre web : fonctionne.
L’extension Firefox : KDF config response does not contain a valid KDF type.
L’application iOS : « Nous ne sommes pas en mesure de traiter votre demande ».

Le KDF (key derivation function) est la fonction qui transforme le mot de passe maître en clé de chiffrement. Le client demande au serveur quels paramètres utiliser, puis fait le calcul lui-même. L’erreur disait donc : « la réponse du serveur ne ressemble pas à ce que j’attends ».

Pourquoi j’ai accusé le réseau

Ma première intuition : quelque chose entre le client et le serveur abîmait la réponse. C’était plausible, car proxys et CDN modifient parfois le trafic au passage. J’ai donc testé, une par une :

Piste testée	Résultat
Désactiver les protections anti-robots de Cloudflare	Aucun effet
Règle de pare-feu applicatif pour laisser tout passer	Aucun effet
Purger le cache Cloudflare	Aucun effet
Désactiver HTTP/3 et le 0-RTT	Aucun effet
Vérifier la compression de la réponse	JSON propre une fois décompressé
Corriger l’adresse publique déclarée dans la configuration	Vrai défaut, mais pas suffisant

Chaque test prenait du temps, et aucun ne changeait rien.

Le friend test

J’ai fini par emprunter le téléphone d’un proche. Il n’avait jamais été connecté à mon réseau, ni à mon compte iCloud, ni à mon Firefox. J’y ai installé l’application Bitwarden, je l’ai pointée vers mon serveur…

Même erreur, exactement.

Ce test a éliminé d’un coup toutes mes hypothèses réseau. Un problème propre à mon infrastructure, à mon cache ou à mes appareils n’aurait pas touché un téléphone neuf. Le problème venait de ce que tous les clients avaient en commun : la version de l’application.

Le friend test

Quand tout semble suspect, reproduisez le problème sur un appareil qui ne partage rien avec les vôtres. S’il plante pareil, ce n’est ni votre réseau, ni votre configuration locale.

La vraie cause : un contrat de version rompu

Pourquoi le coffre web, lui, fonctionnait-il ? Parce que Vaultwarden sert sa propre interface web, compilée avec lui, à la même version. Elle comprend forcément ses réponses. C’était le pire témoin possible.

L’extension et l’application, elles, sont publiées par Bitwarden et mises à jour automatiquement par les magasins d’applications, sans aucun lien avec mon serveur. Bitwarden avait fait évoluer la structure de la réponse KDF. Les clients avaient adopté le nouveau format ; mon serveur ne le parlait pas encore. Il fallait une version plus récente de Vaultwarden.

Pourquoi la mise à jour n’a pas marché du premier coup

J’ai lancé la mise à jour du conteneur… et rien n’a changé. En relisant mon fichier Compose, j’ai trouvé ceci :

image: vaultwarden/server:1.36.0@sha256:<empreinte>

Docker peut désigner une image de deux façons :

par une étiquette (1.36.0, latest) : un nom qui peut pointer vers une autre image demain ;
par une empreinte (sha256:…) : l’identifiant exact d’une image, qui ne change jamais.

Quand les deux sont présentes, l’empreinte l’emporte. J’avais beau télécharger de nouvelles versions, Docker relançait toujours la même image figée. Une fois l’empreinte retirée et une version récente demandée, l’extension et l’application se sont reconnectées immédiatement.

Épingler n'est pas une erreur, l'oublier si

Figer une image par son empreinte est une bonne pratique de sécurité : on sait exactement ce qui tourne. Le piège, c’est de l’avoir fait sans s’en souvenir. Depuis, chaque service a une politique d’image écrite : figé (et mis à jour à la main) ou suivi automatiquement.

Ce que j’en retiens

Vérifier la compatibilité client/serveur avant de chercher dans le réseau. Quand des clients mis à jour automatiquement cassent, la version est le premier suspect.
Choisir un bon témoin. Un client livré avec le serveur ne prouve rien sur les autres.
Lire le fichier réel avant de mettre à jour. Ce que je croyais avoir configuré et ce qui était écrit n’étaient pas la même chose.
Changer une seule chose à la fois. C’est ce qui m’a permis de repérer le seul vrai défaut parmi mes essais.

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.