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…