Accueil › Archive pour Projets

Projets

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

Connecteur OpenCTI – AbuseIPDB Blacklist

Posté le de — Aucun commentaire ↓
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

The percentage of small buckets… – Splunk

Posté le de — 2 commentaires ↓

Bonjour à tous, aujourd’hui je vous partage un bug que j’ai rencontré avec un instance Splunk il y a quelques temps de ça. L’erreur en question était celle-ci : « The percentage of small buckets (40%) created over the last hour is high and exceeded the yellow thresholds (30%) for index« . J’ai mis un moment à la détricoter.

The percentage of small buckets (40%) created over the last hour is high and exceeded the yellow thresholds (30%) for index

Après quelques recherches (ici, là), j’ai fini par identifier la root-cause : des logs sui arriveraient avec « trop de retard » par rapport à leur date réelle d’émission. Ce délai forcait Splunk, qui range les données dans les Bucket de manière temporellement ordonnée, à recréer des bucket pour ces évènements car ceux correspondant à cette plage temporelle avaient été fermés.

A la recherche des logs pétés

A partir de mon erreur, je me lance donc dans le SPL ci-dessous et effectivement j’ai bien une des sources de logs qui arrivent avec des latences pas normales.

index=<monindex>
| eval latency=_indextime-_time
| stats min(latency),
max(latency),
avg(latency),
median(latency)
by index sourcetype host
| sort - "avg(latency)"
The percentage of small buckets (40%) created over the last hour is high and exceeded the yellow thresholds (30%) for index

Du coup j’ai gratté un peu sur l’hôte en question et il s’avère qu’on a régulièrement des grosses latence à l’indexation, à … Lire la suite