Accueil › Archive pour TP Linux › Page 3

TP Linux

Docker et Portainer part 9 – Monitoring des performances docker avec Splunk

Posté le de — 2 commentaires ↓
Docker et Portainer

Salut à tous, ça fait longtemps qu’on a pas parlé de docker, non. ? Et je vous avais promis de parler du Monitoring des performances docker avec Splunk. Ça fait quelques mois que j’ai mis en place un truc sur le serveur mais que je n’ai pas eu le temps de vous mettre sur le blog.

Rappel des articles de la série « Docker et Portainer » :

V1, dans le doute : script…

Ma première tentative a … Lire la suite

Changer le sourcetype après un Universal Forwarder

Posté le de — Aucun commentaire ↓
Splunk Logo

Bonjour à tous, aujourd’hui, je veux vous parler d’une configuration possible dans une infra Splunk pour changer le sourcetype après un Universal Forwarder. En effet dans une infra Splunk, lorsque vous utilisez un UFW (Universal Forwarder), dans votre fichier Inputs.conf vous devez définir le sourcetype des logs.

Par exemple :

[monitor:///splunk-inputs-dir/PROXY/*/*.log]
disabled = 0
index = proxy
host_segment = 3
sourcetype = editor:proxy

Comme on le voit le sourcetype est affecté pour le dossier surveillé. Et il n’est pas possible de placer des règles pour définir des sourcetypes custom en fonction du host ou du format de la ligne de log par exemple. En lisant sur les forums Splunk, la plupart des postes que j’ai vu disent qu’il faut remplacer l’UFW par un heavy forwarder, sauf… qu’en regardant bien la doc, on a une option pour faire faire le travail à nos indexeur.

En effet, il est possible de jouer avec les fichiers props.conf (et transforms.conf) pour lui faire appliquer un TRANSFORMS sur les logs. Par exemple, le props.conf qui défini vos extractions du champs pour votre sourcetype devrait ressembler à quelques chose comme :

[editor:proxy]
EVAL-bytes = bytes_out+bytes_in
EXTRACT-proxy = ^une méchante regex
TIME_FORMAT = %s%3N
TIME_PREFIX
… Lire la suite

Spiderfoot, un outil pour votre OSINT

Posté le de — Aucun commentaire ↓

Bonjour à tous, aujourd’hui je vous parle rapidement d’un outil que je ne connaissais pas pour faire de l’OSINT : Spiderfoot. Spiderfoot est un outil assez rigolo de recherche en source ouverte (OSINT) qui permet de bien préparer ses prestations, ses redteam & pentests ou simplement stalker les collègues ;-). C’est pratique aussi pour repérer l’informatique grise ou simplement faire de la veille.

L’installation de Spiderfoot se fait tout simplement sur une Debian avec python 3, et même si le projet ne propose pas d’image docker officielle tout prête, ça reste possible et on en trouve aussi sur le docker hub faites par la communauté. Bref pas d’excuses !

Après l’étape relou c’est de créer tout les comptes de vos bot et API : google bing, linkedin, twitter, facebook et compagnie pour pouvoir allez récupérer les informations accessibles qu’aux abonnés sur les plateforme. Mais une fois que c’est fait : vous récupérerez une IHM comme celle-ci pour configurer vos scans. Notez qu’il est possible de régler la discrétion du scan 🙂

Spiderfoot search

Et ensuite les résultats comme ça au bout d’un moent:

Spiderfoot results

Voilà, je vous laisse tester Spiderfoot du coup, c’est bien marrant et pratique et pas si long à mettre … Lire la suite

CTFd et Splunk : utilisez SQL pour du SPL !

Posté le de — Aucun commentaire ↓

Bonjour à tous, Il y quelques temps (environ :-)) on m’a demandé d’organiser un CTF en interne au taf. Je pourrais vous parler un moment du projet, des contributions au challenges, de l’organisation ou de la com’ mais bon, c’est pas trop le but du blog de vous parler des trucs chiant…^^ Je voulais juste pour partager quelques requêtes SQL et SPL pour CTFd et Splunk que j’ai faites en fin de CTF pour générer des graphiques et quelques stats sur le déroulement du challenge.

Alors je l’ai pas indiqué mais on a utilisé un CTFd customisé (un peu, merci Keny) pour l’occasion. Derrière la plateforme on trouve donc une base MariaDB (ex-mysql) tout bête qu’on peut requêter avec du SQL tout ce qu’il y a de plus classique.

SQL over CTFd

Par exemple la liste des utilisateurs inscrit au CTF vers un CSV :

Select u.id as user_id, u.name as username, u.email as user_email, u.type as user_type, u.team_id as team_id, t.name as team_name, captain_id, u.created as user_created 
INTO OUTFILE '/tmp/ctfd_users.csv' 
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
LINES TERMINATED BY '\n' 
FROM users as u 
LEFT JOIN teams as t ON t.id=u.team_id ORDER BY team_name;

Ça vous sort … Lire la suite