Script de veille serveur sous Linux et Docker : alertes CVE, silence radio et vrais pièges

Illustration Geekeries d'un script de veille serveur Linux et Docker filtrant le bruit pour détecter les mises à jour de sécurité CVE

Bonjour à tous, quand on administre un serveur Linux qui héberge une vingtaine de conteneurs Docker en production, on finit vite écartelé entre deux extrêmes. Soit on délègue tout à des mises à jour automatiques aveugles (ce que je vous racontais récemment dans mon article sur MariaDB et les surprises de Watchtower et comment ça peut casser silencieusement un schéma de base de données), soit on reprend le contrôle en manuel… au risque d’oublier de vérifier les correctifs pendant trois semaines et de se faire poncer bien comme il faut ! Pour sortir de ce dilemme, j’ai construit un script de veille serveur, léger, en Python, piloté par systemd, qui inspecte l’état réel de la machine deux fois par jour sans jamais toucher à la production.

L’idée de départ est très simple : je voulais un observateur strictement en lecture seule (observer-only), capable de croiser en quelques secondes les paquets APT en attente, les images Docker (qu’elles viennent de Docker Hub, de GitHub ou d’un build local), les extensions WordPress, la fraîcheur des sauvegardes et les unités systemd. Surtout, je voulais qu’il respecte une règle d’or : se taire quand tout va bien, mais ne jamais rater … Lire la suite

Build a CSIRT Second Brain with OpenCode, Obsidian, MCP, and an AbuseIPDB custom tool

CSIRT second brain: workshop introduction (French)

Bonjour à tous ! Le 1er octobre 2026, j’ai animé à Stockholm un atelier consacré au « CSIRT second brain » (ou « second cerveau » en français), pour les équipes de réponse à incident. Il s’inscrivait dans le cadre des 78e rencontres du TF-CSIRT, organisées en Suède du 29 septembre au 1er octobre (auxquelles j’ai aussi assisté 😊).

J’ai préparé cet atelier suite au meeting précédent du TF-CSIRT à Riga au printemps, où plusieurs personnes m’ont demandé de montrer comment on s’y prend au CERT pour qualifier nos incidents avec des agents. Et autant c’est « assez simple » à expliquer, autant l’implémentation réelle en prod est vite complexe à reproduire : entre le choix des LLM, les tools, les MCP, les skills et les bases de connaissances…

Mettre tout ça en musique dans un atelier suffisamment simple pour que tout le monde comprenne en une demi-journée, gratuitement, mais suffisamment complexe pour être représentatif de la réalité, c’était un beau challenge sur lequel je me suis fait des nœuds au cerveau… pour vous sortir la version la plus simple d’un agent SOC/CSIRT de qualification d’incidents.

L’idée de mon workshop est de conserver … Lire la suite

Codex en terminal avec un daemon local : mon plan B à VS Code Web

La licorne Geekeries utilise Codex en terminal relié à un daemon local pendant qu'une fenêtre web se déconnecte

Bonjour à tous, mon passage à Codex en terminal n’était pas vraiment prévu. Tout a commencé avec ce message dans VS Code Web :

Cannot activate the 'Codex – OpenAI’s coding agent' extension because it depends on the 'Codex Audio' extension which is disabled.

Le petit bricolage qui me permettait d’utiliser l’extension Codex dans mon VS Code Web venait peut-être d’atteindre sa limite. Je pouvais chercher une nouvelle rustine, mais ce genre de dépendance interne est précisément ce que je ne contrôle pas. J’ai donc préféré sortir Pwny de l’extension et revenir à une base officiellement prise en charge : le client Codex en ligne de commande.

L’objectif restait le même que dans mon article sur VS Code Web et Codex sur serveur : ouvrir un navigateur, retrouver mon espace de travail et discuter directement avec la licorne. La différence est que VS Code Web ne sert désormais plus que de fenêtre et de terminal. La session Codex vit indépendamment derrière.

Pourquoi sortir Codex de l’extension VS Code ?

Une extension intégrée reste plus confortable. Les liens vers les fichiers s’ouvrent mieux, les images se joignent plus naturellement et l’interface donne davantage l’impression de travailler dans un petit cockpit. Je … Lire la suite

CrowdSec et Nginx Proxy Manager : protéger Docker sans image custom

Une licorne Geekeries bloque un paquet web suspect avec CrowdSec Nginx Proxy Manager devant des conteneurs Docker

Salut les Geeks ! Après avoir protégé les Basic Auth avec Fail2ban devant Nginx Proxy Manager, je voulais compléter la défense contre les scans et comportements HTTP plus larges. Le résultat est un filtrage CrowdSec pour mon Nginx Proxy Manager qui conserve l’image officielle du proxy, observe d’abord, puis bloque les décisions au firewall, y compris pour les flux Docker.

Comme vous allez le voir, ce n’est pas un WAF HTTP. CrowdSec apprend à partir de l’activité déjà vue par le proxy qui lui est transféré, puis le firewall refuse les adresses IP décidées comme malveillantes depuis les liste souscrites chez CrowdSec. C’est moins riche qu’une inspection HTTP intégrée, mais c’est une solution simple, maintenable et adaptée à une installation NPM Docker existante.

Pourquoi je n’ai pas fabriqué une image NPM avec un bouncer Nginx

La première piste semblait évidente : intégrer le bouncer CrowdSec directement dans Nginx Proxy Manager. En pratique, cela suppose l’installation de Lua ou d’OpenResty, des modules spécifiques : donc une image dérivée de NPM, un fork ou une image communautaire. Certaines recettes existantes reposent sur des images peu suivies. Pour un reverse proxy exposé sur Internet, je ne voulais ni dépendre d’une image custom, … Lire la suite