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

Modification et stockage des logs avec syslog-ng

Bonjour à tous, la semaine dernière je vous ai partagé une configuration rsyslog pour recevoir, écrire dans des fichiers tampon et re-forwarder des logs vers d’autres sources. Cette semaine, on refait la même chose avec la modification et stockage des logs avec syslog-ng.

Et vous allez voir, c’est quasiment la même chose.

Syslog-NG ?

Syslog-ng est une alternative « semi-opensource » à rsyslog pour gérer vos syslog. Il remplace rsyslog si vous l’installer sur votre Debian par exemple. Le produit est disponible sous licence LGPL en version Community et vous pouvez y ajouter des licences premium (payantes) pour avoir des consoles de gestion ou des Appliances spécifiques incluant de la recherche dans vos log (micro SIEM).

La solution est plus récente que rsyslog et est donc un poil plus facile à aborder (notamment au niveau des fichiers de confs) et la présence d’une version payante permet de s’appuyer sur le support éditeur en production (toujours souhaitable). En revanche c’est un poil moins connus dans la communauté et il peut parfois être plus dur de trouver de la ressources documentaires (la où rsyslog en a trop de son côté et pour 40 version différentes…^^)

Installation et configuration.

Bref, on veut ici … Lire la suite

Dynamic file name rsyslog

Bonjour à tous, allez je dépile mon backlog. Aujourd’hui je vous partage une configuration de dynamic file name rsyslog. Elle m’a bien servis y’a 1 an et demi pour diminuer le volume de log dans mon SIEM et configurer une plateforme de relais syslogs devant ce dernier. En effet, pour ceux qui auront écouté mon podcast No Limit Sécu sur les dix commandements du SIEM se rappelerons que le 1er commandements est de mettre en place une infrastructure de relais syslog .Celle ci permet le retraitement des logs, la diffusion et la conservation d’un buffer local.

En gros si on parle Splunk, le schéma retenu pour l’arrivée des logs n’est pas d’utiliser l’universal forwarder en reception « directe » des syslog. Mais bien de configurer un serveur RSYSLOG (ou Syslog-ng) intermédiaire qui écrit les logs dans des fichiers sur le serveur et l’universal forwarder surveille alors ces dossiers. Cette pratique présente de nombreux avantage :

  1. Les serveurs de collecte syslog « frontaux » avec les clients sont indépendant de la technologie de SIEM utilisé derrière. En cas de changement de SIEM, ces serveurs peuvent être maintenu.
  2. L’utilisation de fichier permet de conserver un cache local sur le serveur qui permet d’avoir un tampon de quelques
… Lire la suite

Connecteur OpenCTI – AbuseIPDB Blacklist

Connecteur OpenCTI

Bonjour à tous, aujourd’hui, je continue avec OpenCTI parce que je vous ai développé un petit connecteur OpenCTI. J’en ai un peu chié :’-) entre le python qui n’est pas ma tasse de thé et le fait que je démarre avec OpenCTI : je suis pas parti avec des bonus là…^^
Mais du coup je me dis que ca vaut le coup de vous partager un peu de ce que j’ai fait, car il y avait de bon trucs à apprendre notamment autour du format Stix.

L’environnement de development.

Alors c’est probablement la partie la plus simple au départ, il suffit quasiment de suivre le guide du projet il peut y avoir quelques subtilité pour déployer Python sur votre Windows avec VSCode et pip mais globalement ça ne se passe pas si mal.

Une fois votre environnement de dev en place, il faut :

  1. Forker le projet OpenCTI connectors sur votre Github
  2. Faire une branche dédié et basculer dessus
  3. Si comme moi vous créer un nouveau connecteur :
    1. Copier le répertoire template
    2. renommer quelques variables/chemin comme indiqué dans la doc.

Jusqu’ici tout va bien.

Le development

Alors la bonne nouvelle c’est comme il existe déjà plein de connecteurs, vous … Lire la suite