Accueil › Publications taguées Splunk › Page 2

Splunk

Cybersécurité et PowerShell – le livre !

Posté le de — Aucun commentaire ↓

Bonjour à tous ! Ça y est mon « gros projet » dont je vous parle depuis un mois est sorti sur le site d’éditeur. Et je vous ai donc concocté un livre sur la Cybersécurité et PowerShell !

Cybersécurité et PowerShell, De l'attaque à la défense du système d'information

Voilà c’est mon livre de chevet depuis 6 mois maintenant. Çà m’a occupé mes congés d’été, et d’automne pour le terminer. J’y ai mis tout ce que je pensais utile pour commencer en cybersécurité en se servant de PowerShell. J’y raconte plein de chose que j’ai vu en 10 ans de sécurité des systèmes d’information maintenant. Le tout en 2 grande partie : l’attaque et la défense pour répondre à toutes vos questions sur la sécurité et en traitant les parties techniques avec PowerShell (il y a même un peu de Splunk à la fin du livre).

Je ne peux pas faire ce post sans remercier plein de gens. D’abord : Arnaud (twitter) qui m’a gentiment balancé devant le train mis en contact avec l’éditeur et proposé mon nom pour écrire l’ouvrage ! C’est grâce à lui que je me suis fait laver le cerveau j’ai appris à apprécier PowerShell. Je ne le remercierai jamais assez ! Ensuite, … Lire la suite

Splunk – Filtrer ses logs avec un Lookup… efficacement !

Posté le de — Aucun commentaire ↓
Splunk Logo

Bonjour à tous, aujourd’hui je voudrais qu’on se penche sur un truc assez simple d’apparence qu’on a tous voulus faire avec Splunk : Filtrer ses logs avec un Lookup. Le use case que j’ai eu aujourd’hui au taf est assez simple. On avait une liste de domaine malveillant dans un petit CSV et on voulait croiser ça avec nos logs proxy (plusieurs dizaines de Go par jours) sur une semaine.

Filtrer ses logs avec un Lookup… sur des petits volumes de log !

Du coup le collègue qui a essayé en premier est parti avec la première méthode qu’on trouve sur Google (normal jusque-là). Faire une sous-recherche (subsearch) qui prend le lookup, « table » la colonne avec le nom qui match celui du champ dans les logs et cherches.

index=proxy [| inputlookup malwaredomainslist.csv | table site ]

Bilan : 1h après on avait pas fait 25% des logs et la recherche a même finis par planter en « Dag Execution Exception: Search has been cancelled. Search auto-canceled« . A ce stade il m’appelle, et je gratte un peu dans mes souvenirs. Il me semblait qu’on pouvait forger le texte de la recherche depuis une subsearch. Et je retombe … Lire la suite

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