Archives mensuelles : octobre 2016

ElasticSearch: Création d’un Index avec PowerShell

La suite de produits ElasticSearch et Beats permettent de créer des index très facilement sans avoir à se soucier du format. Tout est fait pour nous.

Il est bien sûr possible de créer son propre index avec des données propres et je propose dans cet article de voir comment avec PowerShell.

Imaginons que nous voulons stocker dans ElasticSearch des informations relatives à un folder. Par exemple, le chemin complet du répertoire, ainsi que le groupe qui y à accès, de quel domaine, avec quel droit, et pourquoi pas le type de groupe.

Dans notre cas, les données à créer au format json ont le format suivant:

A noter l’attribut @timestamp, il sera utilisé lors des recherches dans ElasticSearch, c’est ici la date et l’heure à laquelle la donnée est insérée dans ElasticSearch.

Il faut qu’il soit au format utilisé par ElasticSearch et on peut le créer ainsi:

Les autres données proviennent d’autres scripts qui ont pour but d’aller chercher ces information en utilisant Get-Acl, Get-ChildItem, ou toute autre méthode.

Nous allons créer le hashtable qui nous servira à générer la donnée au format JSON ainsi:

Une fois $body créé on pourra le transformer en JSON ainsi:

Dernière conversion, il faut absolument que le JSON soit au format UTF8 sinon nous allons avoir des problèmes avec les accents et autres caractères complexes.

 

Une donnée dans ElasticSearch est toujours insérée en mentionnant trois propriétés:

  • Le nom de l’index, par exemple Shares-2016.10.30, ce qui veut dire Shares est la collection des index du même type, suivi de la date de création de l’index.
  • Le Type d’objet à insérer, dans notre cas par exemple Share
  • un identifiant unique optionnel, il vaut mieux d’ailleurs ne pas le mentionner, ainsi ElasticSearch va le créer pour nous.

La ressource URL que nous pouvons créer est alors:

L’adresse à utiliser pour envoyer nos données devient donc:

$server est le serveur où ElasticSearch est installé et $port est par défaut 9200, port de ElasticSearch.

Si nous utilisons des credentials avec ElasticSearch (avec Shield par exemple), nous devons créer un header:

Nous pouvons maintenant utiliser Invoke-RestMethod et envoyer nos données:

 

Nous pouvons faire du tout une cmdlet, la voici:

Bonne indexation!

ElasticSearch 5.0 Mise à jour

ElasticSearch 5.0 est désormais disponible et dans cet article je revisite le dernier article sur installation de ELK pour la consolidation  d’événements.

Pour la mise à jour, j’en ai profité pour mettre Java à jour avec la version 64 bits. J’ai ensuite modifié le script d’installation pour que Java s’installe tout seul, et que la variable d’environnement JAVA_HOME soit créée de façon automatique.

Avant d’exécuter le script suivant, j’ai copié les dernières versions de ELK depuis http://elastic.co.

J’ai également supprimé les services des anciennes versions avec NSSM:

Ceci pour ElasticSearch, Kibana, Filebeat, WinLogBeat et Logstash, car ils étaient tous installés.

Voici le nouveau script d’installation en PowerShell:

 

Le script ajoute le paramètre -Xss1m à C:\ELK-stack\elasticsearch\config\jvm.options. Ce paramètre définit le thread stack size pour la JVM et sans ça nous avons une erreur lors de l’installation.

Attention à bien éditer le fichier winlogbeat.yml et ajouter:

Et voici le résultat:

kibana5-0

Une fois la vérification effectuée qu’on reçoit bien les événements, nous pouvons importer les dashboards pré créés par ElasticSearch en exécutant import_dashboards.exe qui se trouve dans le dossier scripts de winlogbeat.

Et nous avons ceci:

winlogbeatdashboard

C’est quand même super cool.

ElasticSearch, Logstash, Winlogbeat et Kibana et la consolidation d’événements Windows

Dans cet article je vais parler de la consolidation d’événements de sécurité avec Windows 2012R2 et la stack ELK.

Je me suis appuyé sur deux excellents articles pour y arriver.

Le premier explique comment à partir de PowerShell, on peut installer et configurer ELK par Rob Willis et on le trouve ici.

Le deuxième est un article sur le forwarding d’events Windows, et explique bien ce qu’il faut faire pour que les événements soient transférés vers une machine collecteur. On le trouve ici.

EVENT FORWARDING

Pour la consolidation d’événements nous avons besoin d’un serveur collecteur qui servira pour consolider les événements d’un ou plusieurs domaine controleurs Active Directory.

Il y a plusieurs façons de consolider les events Windows mais le forwarding est la méthode la plus simple à mettre en place et la plus optimisée car c’est une fonctionnalité native de l’Event Viewer. De plus il’ y a pas besoin de donner des droits à un compte utilisateur car on peut habiliter la machine collecteur directement.

SUR LE DOMAINE CONTROLEUR

Il n’ y a vraiment que deux opérations à faire sur un DC. La prèmière consiste à ajouter le compte machine du serveur collector dans le groupe builtin appelé Event Log Readers.

On démarre notre DSA.MSC favori.

dsa

Et on y ajoute le compte machine du serveur collector, dans mon cas, SRV1$.

eventlogreaders

La deuxième opération est un peu plus délicate. Il s’agit de modifier les droits d’accès du log Security.

Il faut pour cette opération une commande CMD en mode Administrator (click droit sur CMD, ou PowerShell puis Run as Administrator)

Puis on regarde les droits d’accès (channelAccess) du log security, voici la commande:

Ce qui devrait avoir comme output:

On voit que par défaut le SID S-1-5-32-573 (Builtin\Event) a les droits d’accès.

Comme le processus de récupération des events utilise le compte Network Service (SID S-1-5-20), nous allons l’ajouter à la liste.

Ainsi:

Pour finalement avoir:

Voilà c’est tout. On reviendra sur le DC plus tard pour vérifier l’Event Log et nous assurer que les événements sont bien envoyés au collecteur.

SUR LE SERVEUR DE COLLECTION

On démarre l’Event Viewer et on fait un click droit sur Subscriptions, puis Create Subscription.

newsubscription

Dans la fenêtre Subscription Properties (qui vient d’apparaître), on va nommer notre subscription, par exemple Event Subscription.

eventsubname

Ensuite on click sur Computers et on y ajoute un domaine contrôleur, dans mon exemple DC1.AD.LOCAL

computers

On clic sur Test pour vérifier la connectivité.

test

On crée un filtre pour ne sélectionner que les événements Sécurité:

 

queryfilter

Et voilà nous avons notre souscription. Et nous allons la tester en faisant un clic-droit dessus, suivi de Runtime Status:

runtimestatus

On devrait avoir ceci:

runtimestatus2

Si jamais ce n’est pas le cas. Il se peut qu’une étape soit à revoir:

Coté DC il faut vérifier que l’event 100 est bien créé dans le Log Applications and Service Logs\Microsoft\Windows\Eventlog-ForwardingPlugin/Operational.

Si vous voyez un event 102 en Erreur, c’est pas bon. Il faudra alors revoir les étapes ci-dessus.

Finalement, au bout de quelques minutes vous devriez voir arriver pal mal d’events dans le journal Forwarded Events:

 

 

fwevents

Et on voit bien qu’ils viennent de notre DC (DC1.ad.local).

INSTALLATION D’ELK+WINLOGBEAT

L’article de Rob Willis est vraiment bien fait, de plus il a ajouté une video youtube pour les explications (voir lien plus haut).

Ceci étant dit, je vais quand même revenir dessus, car certaines choses ont évolué et il a fallu faire de petites adaptations.

Tout d’abord il faut récupérer plusieurs sources dont, ELK, NSSM, Java et WinlogBeat:

Sur https://www.elastic.co/downloads récupérer ElasticSearch, Logstash, Kibana et la Beta 5.0 de Winlogbeat.

Sur https://www.java.com/   récupérer Java.

Sur https://nssm.cc récupérer NSSM.

Le script de Rob Willis se trouve ici.

Se créer un répertoire C:\ElK-Stack et pour chaque produit créer un sous-répertoire et y extraire chaque zip.

S’assurer que la variable d’environnement JAVA_HOME est créée et qui pointe vers le répertoire où Java est installé, par exemple C:\Program Files (x86)\Java\jre1.8.0_101.

Attention de redémarrer ISE si vous venez de créer la variable JAVA_HOME pour qu’elle soit prise en compte.

Modifier le script de Rob Willis à la ligne

Remplacer les lignes 91 et 119

par

Il s’agit des dépendances des services Kibana et Logbeat au service Elasticsearch lors de l’étape de création des services avec NSSM. Cette partie sera à adapter en fonction de la version de ElasticSearch.

S’assurer que les services elasticsearch, kibana, logstash et winlogbear, soient tous bien démarrés.

Modifier le fichier c:\elk-stash\winlogbeat\winlogbeat.yml

et remplacer

qui sont les journaux locaux, par

Exécuter en mode step by step le script de Rob Willis.

Il est suffisamment bien documenté pour comprendre comment mettre en place chaque service.

Et finalement pour vérifier le tout on se connecte à Kibana via l’adresse http://localhost:5601

kibana

Et là on voit bien que ça fonctionne.

On peut chercher avec la barre de recherche des events venant d’un computer_name en particulier, par exemple computer_name:DC1.ad.local qui est notre DC.

kibana2

Et on voit bien les events de notre DC.

Maintenant il faut creuser un peu plus l’aspect recherche des events avec PowerShell.

Voici quelques exemples avec Invoke-RestMethod

Résultat:

 

ou encore

 

On a le nombre d’éléments trouvés.

 

Et pour récupérer tous les éléments dans l’index:

 

Tous les éléments dont le computer_name est DC1.ad.local

 

Un grand classique comme petit dernier, la liste des locked accounts sur DC1.

 

A suivre…