Accueil › Archive pour TP Linux

TP Linux

Codex en Remote SSH : moderniser un backup directement sur le serveur

Posté le de — Aucun commentaire ↓
Codex en Remote SSH pour auditer et valider un backup Docker sur un serveur distant

Bonjour à tous, aujourd’hui je vais vous parler de Codex en Remote SSH et d’un vieux script de backup qui traînait sur mon serveur. Vous savez, le genre de script qu’on a écrit quelques années plus tôt, qui a toujours plus ou moins fait le boulot et qu’on évite de regarder de trop près tant que les sauvegardes semblent tomber quelque part…

Sauf qu’entre-temps, j’ai migré le serveur de Debian 12 vers Debian 13 (Cf. Crowdsec), quelques containers ont disparu, d’autres ont changé, et j’avais finalement très peu retouché au script de sauvegarde d’origine. Un retour aux sources après ma série sur Docker et Portainer, en quelque sorte. Il était donc temps de vérifier si ce machin sauvegardait encore réellement quelque chose.

Pour le coup, je n’ai pas commencé par ouvrir une console SSH et modifier le Bash au petit bonheur. J’ai ouvert le serveur directement dans VS Code avec l’extension Remote SSH, puis j’ai travaillé avec Codex de manière interactive sur la machine.

L’objectif n’était pas de demander à une IA : « fais-moi un script de backup ». L’objectif était de lui faire auditer l’existant, confronter ses hypothèses au vrai serveur, proposer une nouvelle version, puis … Lire la suite

Crowdsec

Posté le de — Aucun commentaire ↓

Bonjour à tous. Oui, je sais, cela fait presque deux ans que je n’ai rien écrit sur le blog, mais je ne suis pas encore mort, et ce n’est pas faute d’avoir des brouillons plein les placards… Bref, la vie de Head of CERT est bien remplie ! Tout ça pour vous dire que j’ai migré le serveur geekeries.org vers un nouveau. Debian 12 se rapprochait doucement de sa fin de vie, et comme dirait Marc Fred, je n’avais pas envie de mériter de m’en prendre une. Donc on ne réfléchit pas, on patch 😉 Bref, quelques heures plus tard, et le temps de tout bien reconfigurer (iptables, fail2ban, docker, etc.), je vais pouvoir vous parler de CrowdSec et de la version free que vous pouvez déployer sur vos machines.

CrowdSec, c’est quoi déjà ?

CrowdSec se présente lui-même comme un IPS open source et participatif. Vous vous souvenez de mes posts sur AbuseIPDB? Eh bien CrowdSec, c’est globalement le même principe qu’un AbuseIPDB en mode “boosté aux hormones”. Je m’explique : comme pour AbuseIPDB, CrowdSec s’installe en tant qu’agent sur votre ou vos serveurs. Il surveille les journaux d’événements locaux à la recherche d’événements en … Lire la suite

Modification et stockage des logs avec syslog-ng

Posté le de — Aucun commentaire ↓

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

Posté le de — Aucun commentaire ↓

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