Alors comme ça, vous vous êtes improvisé DSI de votre maison

Thu, 11 Jun 2026 00:00:00 +0000

Personne ne m’a embauché. Il n’y a eu ni entretien, ni lettre d’offre, ni négociation salariale. Un jour j’ai installé un NAS, et quelque part entre le troisième conteneur Docker et le premier VLAN, j’étais silencieusement devenu le Directeur des Systèmes d’Information d’une organisation petite mais extrêmement exigeante : ma maison.

Le poste vient avec tout ce qu’un vrai service informatique possède, sauf les parties qui le rendent vivable. Il y a un support technique (c’est moi), un centre opérationnel de sécurité (moi aussi), un comité de validation des changements (moi, en train de me parler tout seul sous la douche), et une procédure d’escalade (moi, mais plus stressé). Il y a aussi des utilisateurs avec un SLA zéro tolérance, dont tout le système de tickets tient en une phrase : « le WiFi ne marche pas ».

Aujourd’hui je voudrais partager deux incidents récents de cette prestigieuse carrière. Les deux sont entièrement de ma faute. Les deux m’ont appris quelque chose. Aucun des deux n’était la faute du WiFi, mais vous devinez ce que disaient les tickets.

Incident 1 : mon système de sécurité a arrêté mon système de sécurité

J’utilise Frigate comme NVR, avec une poignée de caméras Tapo qui diffusent en RTSP sur un VLAN dédié aux caméras. J’ai déjà écrit sur cette installation, ça marche très bien. Toute la stack est déployée via Komodo, mon plan de contrôle GitOps, donc mettre à jour un service se résume à un clic : « pull et restart ».

Côté pare-feu, mon OPNsense fait tourner CrowdSec, un système de prévention d’intrusion qui surveille le trafic et bannit les IP au comportement suspect. Il fait un excellent travail pour expédier le défilé incessant de bots qui frappent à la porte côté WAN, et il sert de jolie couche de protection pour mes sites web auto-hébergés. J’en étais très fier. Retenez bien ça, c’est important pour la suite.

Un soir, j’ouvre Frigate et chaque caméra affiche « No frames received ». Toutes. En même temps.

Une caméra en panne, c’est un problème de caméra. Toutes les caméras en panne, c’est un problème de moi. J’ai donc commencé à creuser, dans l’ordre qu’adopterait n’importe quel professionnel aguerri de l’informatique domestique : accuser les caméras, accuser le switch, accuser le NAS, accuser Frigate, redémarrer des choses au hasard, et seulement ensuite, regarder les vraies preuves.

Les preuves étaient dans les logs du pare-feu OPNsense. Elles étaient là : une règle qui jetait discrètement des centaines de tentatives de connexion de mon NAS vers les caméras sur le port 554, le port RTSP. Le nom de la règle ? « CrowdSec (IPv4) out ».

Voici ce qui s’était passé, dans la langue sèche du post-mortem :

Komodo a fait un pull-et-restart de routine de la stack Frigate.
Au démarrage, les processus ffmpeg de Frigate ont tous tenté de se reconnecter à toutes les caméras en même temps, en réessayant agressivement quand les flux ne revenaient pas instantanément. Environ 770 tentatives de connexion vers le port 554 en une courte rafale.
CrowdSec a observé ce déluge de tentatives de connexion et en a conclu, assez raisonnablement, qu’une attaque était en cours.
CrowdSec a banni les caméras. Pas la machine qui martelait : les machines qui se faisaient marteler. Il a regardé une agression et a arrêté les victimes.

Mon système de prévention d’intrusion avait décidé que mes caméras de sécurité étaient la menace et les avait jetées en prison. Les caméras n’avaient rien fait. Elles étaient tranquillement sur leur VLAN, occupées de leurs affaires, quand mon NVR s’est mis à frapper à leur porte quelques centaines de fois par minute. Le vigile avait menotté les témoins.

Le correctif a tenu en une ligne sur le pare-feu, une fois par caméra :

cscli decisions delete --ip <IP de la caméra>

suivie de l’étape que j’aurais dû faire dès le premier jour : mettre en liste blanche mes propres sous-réseaux pour que CrowdSec concentre son zèle sur le vrai internet, là où sont les vrais attaquants.

Dans une vraie entreprise, c’est le moment où l’équipe sécurité et l’équipe infrastructure ont une réunion tendue avec une slide intitulée « Leçons apprises ». Dans mon entreprise, les deux équipes c’est moi, donc j’ai juste soupiré sur deux tons différents.

Épilogue : chat échaudé se trompe deux fois

Deux jours plus tard, une caméra disparaît à nouveau de Frigate. Fort de mon expérience durement acquise, je savais exactement ce que c’était. CrowdSec. Encore. Le vigile trop zélé avait encore frappé. Je suis allé droit au pare-feu, prêt à rendre justice.

Les logs du pare-feu montraient zéro paquet rejeté. La table ARP montrait que la caméra n’était même pas sur le réseau. Elle s’était simplement… éteinte. Un débranchage-rebranchage de la caméra a tout réglé en trente secondes.

C’est l’autre piège quand on est son propre service informatique : après le premier incident dramatique, chaque nouveau symptôme ressemble à la dernière cause racine. La panne précédente ne vous coûte pas qu’une soirée, elle installe un biais dans votre tête, gratuitement, pour toujours.

Incident 2 : le serveur d’automatisation qui a poliment refusé toutes les adresses IP de la maison

Deuxième histoire. Je fais tourner n8n, un outil d’automatisation de workflows, dans un petit conteneur sur mon cluster Proxmox. Il trie mes e-mails, range mes notes, fait un tas de petits travaux de colle que je ferais sinon à la main. Il est, ironiquement, censé me faire gagner du temps. Il tournait sans accroc depuis six jours. Vous vous souvenez des caméras ? Même ambiance.

Le premier symptôme est arrivé par le canal de supervision habituel, qualité entreprise : les habitants de la maison signalant que le WiFi faisait des siennes. Les appareils déjà connectés allaient bien, mais tout ce qui était nouveau (un téléphone qui sort de veille, un portable qui rentre à la maison) refusait obstinément de se connecter. Cette ambiance générale de « l’internet est hanté » que les utilisateurs signalent par, vous l’avez deviné, « le WiFi ne marche pas ».

Le WiFi était innocent. Les ondes ondulaient. Le problème était une couche au-dessus : les nouveaux appareils ne pouvaient plus obtenir d’adresse IP, parce qu’il n’y avait, techniquement parlant, plus d’adresses IP.

Une recherche rapide suggérait un problème de compatibilité connu entre mon serveur DHCP (Kea, sur le pare-feu OPNsense) et WireGuard. Internet était confiant. Internet avait aussi tort, ce qui mérite d’être retenu : quand on est tout le service informatique à soi seul, son seul collègue est un moteur de recherche, et ce collègue a des opinions tranchées et zéro responsabilité.

La table des baux, sur le pare-feu à 192.168.1.1, racontait la vraie histoire. Sur les 253 adresses utilisables du pool, 224 étaient marquées DECLINED. Pas utilisées. Pas expirées. Déclinées, c’est-à-dire : le serveur les avait proposées à quelqu’un, et ce quelqu’un avait répondu « non merci, celle-là est prise ». Deux cent vingt-quatre fois de suite.

Voici la boucle qu’une seule et unique machine déroulait, une adresse toutes les dix secondes environ, pendant 75 minutes d’affilée :

Demander une adresse IP.
Recevoir une offre.
Sonder le réseau pour vérifier que l’adresse est bien libre (un comportement responsable et conforme aux standards).
Entendre son propre sondage renvoyé en écho par un pont virtuel confus, et en conclure que l’adresse est prise.
DÉCLINER l’adresse, que le serveur met alors en quarantaine pour 24 heures.
Retour à l’étape 1, avec l’adresse suivante.

Elle a traversé tout le pool comme ça, refusant poliment chaque adresse IP de la maison et les faisant enfermer une par une pour la journée. À 12h21, le log du serveur disait tout : allocation impossible, sous-réseau vide. Les appareils détenteurs d’un bail existant n’ont rien remarqué. Les nouveaux n’obtenaient que du silence. (Ce qui ressemble à du DNS en panne. Ce qui ressemble au WiFi. Ce qui est ce que disait le ticket.)

Restait à trouver qui. La table des baux n’avait qu’une adresse MAC avec un préfixe constructeur Proxmox, alors je suis parti à la chasse à travers les 49 VM et conteneurs du cluster. Le coupable : le conteneur 152. La machine n8n. Mon serveur d’automatisation. La machine dont tout le métier est de faire des choses pour moi avait passé sa pause déjeuner à me faire ça.

Le correctif avait deux volets : supprimer en masse les 224 baux en quarantaine sur le serveur DHCP et le redémarrer, puis redémarrer le conteneur n8n pour reconstruire sa plomberie réseau. Et c’est là que l’histoire a livré son meilleur rebondissement : n8n a refusé de démarrer. Pourquoi ? Son disque était plein. Pourquoi son disque était-il plein ? Parce qu’il avait passé 75 minutes à écrire des lignes de log sur chaque adresse IP qu’il déclinait. La machine avait documenté son propre saccage avec un tel sérieux qu’elle s’était bloquée elle-même sous la paperasse. Le pyromane est mort d’avoir respiré sa propre fumée. Un agrandissement de disque plus tard, elle a démarré, pris une adresse, l’a gardée, et est retournée trier mes e-mails comme si de rien n’était.

Le mot de la fin

Alors, est-ce que tout ça m’arrête ? Pas le moins du monde.

Apprendre, ça fait partie du plaisir. C’est tout l’intérêt de faire tourner sa propre infrastructure : chaque incident est stressant pendant une heure et fascinant pour toujours. Une caméra cloud qui s’arrête de fonctionner est un mystère que vous ne résoudrez jamais. Mes caméras se sont arrêtées et j’ai eu droit à un roman policier avec des logs de pare-feu, des caméras accusées à tort, et des aveux. Mes adresses IP ont disparu et j’ai eu droit à un whodunit avec une adresse MAC en guise d’empreinte digitale et une séance d’identification de 49 machines virtuelles.

Bien sûr, sur le moment, c’est un peu stressant. Il y a des gens qui attendent ce WiFi, et la personne qui l’a cassé, statistiquement parlant, c’est moi. Mais l’instant où la cause finit par s’emboîter, quand le symptôme bizarre, la théorie trompeuse et la ligne de log d’apparence innocente se rangent soudain en une seule histoire cohérente, cette sensation est dure à battre. On ne l’obtient pas avec des choses qui marchent tout simplement, et encore moins avec des choses qui cassent à un endroit où on n’a pas le droit de regarder.

Le support technique reste ouvert. Les tickets restent « le WiFi ne marche pas ». Et le DSI reste, malgré tout, joyeusement pas viré.

DHCP | Antoine Weill--Duflos

Alors comme ça, vous vous êtes improvisé DSI de votre maison

Incident 1 : mon système de sécurité a arrêté mon système de sécurité

Épilogue : chat échaudé se trompe deux fois

Incident 2 : le serveur d’automatisation qui a poliment refusé toutes les adresses IP de la maison

Le mot de la fin