Wazuh HIDS Présentation & Installation

https://homputersecurity.com/2018/06/10/wazuh-hids-presentation-installation/

By mrigonnaux | June 10, 2018

Bonjour à tous,

Aujourd’hui je vais vous présenter Wazuh qui est un HIDS (Host Intrusion Detected System),
ce logiciel Open Source est un Fork du célèbre logiciel du même type OSSEC, il est même
entièrement basé sur ce dernier.

Wazuh en plus du HIDS peut également faire du FIM (File Integrity Monitoring) et IPS
(Intrusion Prevention System), comme OSSEC il est basé sur le modèle client – serveur,
c’est-à-dire que cet outil a besoin d’un serveur central pour fonctionner.

Tout d’abord les avantages que je lui trouve comparé à OSSEC :

 Une meilleure gestion des agents (Agent AIX, Linux, Windows).

o En effet il permet d’ajouter très simplement des agents Windows avec son
fichier msi exécutable via PowerShell et il propose aussi un agent AIX
fonctionnel
 Intégration de base des règles PCI DSS
 Possibilité de mise en place de la suite ELK (ElasticSearch Logstash Kibana) très
facile

Tout d’abord qu’est qu’un HIDS ? C’est un logiciel qui va surveiller les différents agents qui
lui sont connectés et remonter des alertes de sécurité en se basant sur les informations qu’il
analyse, dans notre cas des hashs de fichier, des clés de registres et des logs.

Concrètement que va donc faire Wazuh :

 Analyser les logs des différents agents

 Remonter des alertes avec différents niveaux de criticité (0 à 15)
 Vérifier l’intégrité des fichiers systèmes
 Détection de rootkits
 IPS (lancement de script en cas d’alerte pour bloquer des attaques comme du
bruteforce, etc.)
Avant d’installer notre serveur Wazuh Manager (qui dans mon cas sera un Centos7), nous
allons voir ensemble son fonctionnement.

La communication entre le serveur et les agents se fait sur le port 1514 UDP dans les deux
sens et nécessite un échange de clé pour assurer l’intégrité et la sécurité des données, cet
échange de clé peut se faire de plusieurs façons comme nous le verrons un peu plus tard. Par
défaut le port 1515 TCP est utilisé pour les échanges de clé automatiquement.

Une fois les échanges de clés effectués, les agents et le serveur ne communiquent plus que par
le port 1514 en UDP.

Voici un schéma du fonctionnement du manager avec un agent :

On peut y retrouver les différentes étapes, notamment sur l’agent avec :

 Log collector qui est un service de collecte de log

 Syscheck qui est le service chargé de la vérification de l’intégrité des fichiers systèmes
 Rootcheck qui lui est chargé de la détection des rootkits
Et sur le serveur avec les différents décodeurs de log et les différentes règles de détection, de
base Wazuh intègre un grand nombre de règles et décodeurs (Cisco, WordPress, Nginx,
Apache, Windows, etc.)

Voyons maintenant comment installer Wazuh Manager sur un serveur Centos 7.

Pour installer le serveur ou les agents Linux il y a 2 solutions, la première (celle que je vais
montrer) qui est d’ajouter les repos de Wazuh sur nos machines et de lancer l’installation avec
Yum, ou la seconde qui est de récupérer l’archive directement sur leur site et d’exécuter le
script install.sh qui est le même pour le serveur ou les agents. Avec ce script vous aurez
besoin d’un compilateur C, concernant Windows comme dit un peu plus haut un fichier msi
est fourni et pour AIX une archive pré-compilée est également fournies.

Attention le serveur Manager peut être installé seulement sur une machine Linux.

Installation du serveur
Ajout des repos sur le serveur Manager :

# cat > /etc/yum.repos.d/wazuh.repo <<\EOF

[wazuh_repo]
gpgcheck=1
gpgkey=https://packages.wazuh.com/key/GPG-KEY-WAZUH
enabled=1
name=Wazuh repository
baseurl=https://packages.wazuh.com/3.x/yum/
protect=1
EOF

Une fois le repo ajouté il ne reste qu’à lancer l’installation de Wazuh Manager :

yum install wazuh-manager

Notre logiciel serveur dans sa dernière version est donc installé.

De base il s’installe dans /var/ossec/, voici son architecture :

La plupart des noms de dossiser sont parlants pour vous j’imagine, je vais présenter les
principaux dossiers :

 active-response : Ce dossier contient les scripts à exécuter en cas d’alerte (à configurer

dans la partie HIDS
 agentless : Ce dossier contient les fichiers pour se connecter et assurer des machines
ou des agents ne peuvent pas être installé
 api : Il contient les fichiers de configuration de l’API de Wazuh (API Rest en NodeJS
qui n’est pas installée de base)
 etc : Qui va contenir les fichiers de configuration principaux de l’ensemble de
l’application
 ruleset : Contient toutes les règles de déclenchement ainsi que les décodeurs de log
 bin : Ce dossier contient l’ensemble des scripts nécessaires aux tests et aux
fonctionnalités de Wazuh (ajout d’agent, test de configuration, etc.)

Ce sont les dossiers que nous allons principalement utiliser pour la configuration de notre
outil.

Installation d’un agent Linux

Je vais maintenant ajouter un agent sur une machine Ubuntu, comme tout à l’heure, il faut
ajouter les repos :

# apt-get install curl apt-transport-https lsb-release

# curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | apt-key add –
# echo “deb https://packages.wazuh.com/3.x/apt/ stable main” | tee
/etc/apt/sources.list.d/wazuh.list
# apt-get update
# apt-get install wazuh-agent

Il suffit de remplacer agent par manager si vous voulez réaliser une installation sous Debian
ou Ubuntu.
Une fois l’installation effectuée, comme sur le manager les fichiers de notre agent sont dans le
dossier /var/ossec :

L’architecture est sensiblement la même sur les agents Linux/AIX. Les configurations de
l’agent se feront donc aussi dans le dossier /var/ossec/etc, et plus principalement dans le
fichier /var/ossec/etc/ossec.conf.

L’agent est maintenant installé mais il n’est pas ajouté sur notre serveur, aucun échange n’a
lieu. Il existe 2 manières de faire pour ajouter un agent :

1ère méthode

Sur le serveur Manager, se rendre dans /var/ossec/bin et lancer le script manage_agents :

Une fois ce script, choisissez l’option A :

Une fois l’agent ajouté sur le serveur, une clé a été automatiquement créée, il est donc
nécessaire de la récupérer et de l’ajouter sur notre agent, toujours dans le script
manage_agents de notre serveur, choisissez l’option E :

Il reste plus qu’à copier notre clé et à l’ajouter sur notre agent.

Sur notre agent Ubuntu, il faut se rendre dans le même script afin d’insérer notre clé :

L’option I a été sélectionnée et la clé a été copié, l’agent est maintenant ajouté correctement à
Wazuh.

2ème méthode

Cette 2nd façon de faire est sensiblement plus simple, elle consiste à automatiser le
déploiement des clés sur les agents.

Sur le serveur manager de Wazuh il est nécessaire une nouvelle fois de se rendre
/var/ossec/bin et d’exécuter la commande suivante :

./ossec-authd -a
Cette commande va lancer le processus authd de Wazuh et commencer à écouter sur le port
1515 en TCP, dans l’attente de connexion d’agent pour un échange de clé (l’option -a est
présente pour régler des problèmes de compatibilité sous Windows).

Sur notre agent Ubuntu il faut maintenant lancer la commande suivante (dans /var/ossec/bin
toujours) :

./agent-auth -m <IP de votre serveur Manager>

Exemple :

Cette méthode est pour moi beaucoup plus rapide et c’est celle que j’utilise le plus souvent.

L’agent est maintenant installé avec l’échange de clé effectué mais il ne peut toujours pas
fonctionner, tout simplement car dans son fichier de configuration principal qui est
/var/ossec/etc/ossec.conf, l’IP du serveur Manager n’est pas renseignée. Il faut donc ce rendre
dans se fichier sur l’ensemble des agents et ajouter cette IP :

Il suffit de remplacer MANAGER_IP par l’IP de votre serveur manager et de relancer votre
agent avec la commande suivante :

systemctl restart wazuh-agent

Il est aussi à noter que si vous avez choisi l’installation directement depuis l’archive proposée
par Wazuh pour vos agents, il n’est pas nécessaire d’ajouter l’IP dans vos fichiers de
configuration, cela est réalisé automatiquement lors de l’installation.

On peut maintenant vérifier depuis notre manager que l’agent est bien connecté avec la
commande suivante qui affiche seulement les agents connectés actifs :
Et même avoir plus d’informations sur l’agent avec une option différente (004 correspond à
l’ID de l’agent) :

On sait maintenant ajouter des agents Linux à notre serveur Wazuh, passons maintenant aux
agents Windows.

Installation d’un agent Windows

Sur Windows l’ajout d’un agent est très simple, il suffit de récupérer le fichier d’installation
msi sur le site de Wazuh : https://packages.wazuh.com/3.x/windows/wazuh-agent-3.2.4-1.msi

Une fois le fichier téléchargé, je le place à la racine de ma partition C: et je lance la

commande suivante :

cd C:
.\wazuh-agent-3.2.4-1.msi /q APPLICATIONFOLDER=”C:\ossec\”
ADDRESS=”192.168.1.56″ AUTHD_SERVER=”192.168.1.56″

La 1ère option correspond au dossier d’installation, la 2nd et la 3ème correspondent à notre

serveur Wazuh qui est à la fois manager et serveur d’authentification.

Avec le fichier msi, tout est automatisé, l’installation de l’agent, l’échange de clé et la
modification du fichier ossec.conf pour l’ajout de l’IP du manager, cela peut être vérifié
directement sur notre manager comme pour le agents précédents.
Au niveau de l’architecture, elle est similaire à celle de l’agent Linux, on remarque juste
l’absence du dossier etc et l’ajout de win32ui.exe qui est une petite interface graphique pour
vérifier rapidement l’agent et interagir avec lui :

Nous avons donc maintenant un notre serveur Wazuh Manager avec un agent Linux (Ubuntu)
et un agent Windows (10 Entreprise). Au niveau de la configuration, cela va se dérouler en 2
articles, le 1er sur la configuration du FIM et un second sur la configuration de la partie
HIDS.

J’espère que cet article vous aura plu, si vous avez des questions ou des remarques sur ce que
j’ai pu écrire n’hésitez pas à réagir avec moi par mail ou en commentaire !

Merci pour votre lecture et à bientôt !

MRigonnaux
 Elastic, Wazuh et IDS suricata
https://www.elastic.co/fr/blog/improve-security-analytics-with-the-elastic-stack-wazuh-and-ids

La Suite Elastic propose des fonctions d'analyse de la sécurité qui sont largement utilisées en matière
de détection des menaces, de visibilité et de réponse aux incidents. La vitesse et l'échelle en fonction
desquelles Elasticsearch est capable d'indexer et de rechercher des informations de sécurité rendent
le travail des analystes de sécurité plus efficace, tandis que les tableaux de bord Kibana offrent une
visibilité élargie et permettent de débusquer les menaces interactives. En outre, le moteur de
machine learning est capable d'automatiser l'analyse d'ensembles complexes de données, et permet
ainsi d'identifier des intrus qui seraient autrement passés inaperçus.

Les systèmes populaires de détection d'intrusion (IDS), tels que Wazuh ou Suricata, utilisent une
approche basée sur les signatures pour détecter les menaces. Autrement dit, ils comparent les
modèles identifiés dans les fichiers, les logs et le trafic réseau à une base de données de modèles
connus et associés à des activités malveillantes, puis alertent l'utilisateur lorsqu'une correspondance
est établie. Ces systèmes proposent des ensembles de règles utiles pour analyser et mettre en
corrélation les données, et génèrent généralement des milliers ou des millions d'alertes par jour dans
un environnement de production.

Tendre un vaste filet permet d'intercepter la totalité des événements de sécurité, mais cela implique
de devoir trier des milliers (voire des millions) d'alertes par jour. Les fonctionnalités de machine
learning d'Elastic permettent de réduire ce bruit de fond en identifiant automatiquement les
comportements inhabituels. Ce cas d'utilisation met en évidence la complémentarité des
technologies basées sur les anomalies et celles basées sur les signatures, facilitant ainsi la détection
des menaces tout en rendant les analyses plus efficaces.

Fréquemment déployé avec la Suite Elastic, Wazuh est un système open source de détection
d'intrusion basé sur l'hôte (HIDS). Il permet d'analyser les logs, de monitorer l'intégrité des fichiers,
de détecter les rootkits et les vulnérabilités, d'évaluer les configurations et de répondre aux
incidents. L'architecture de la solution Wazuh repose sur des agents multiplateformes de transfert
léger. Ces agents s'exécutent sur des systèmes monitorés et communiquent avec un serveur
centralisé sur lequel les données sont analysées. En outre, ce système propose un plug-in Kibana
complet pour gérer la configuration, monitorer les statuts, effectuer des recherches et visualiser les
données d'alerte.

D'autre part, Suricata est un moteur open source de détection de menace réseau, capable de
détecter les intrusions réseau (NIDS) en temps réel, de prévenir les intrusions en ligne (NIPS), de
monitorer la sécurité réseau (NSM) et d'utiliser pcap hors ligne. Suricata examine le trafic réseau en
appliquant ses règles et sa langue de signature pour identifier les menaces connues, les violations de
politique et les comportements malveillants. La prise en charge des scripts lui permet de détecter des
menaces complexes.

Dans cet article de blog, nous nous pencherons sur la détection d'intrusions en intégrant Wazuh et
Suricata aux tâches de machine learning d'Elastic pour classer les analyses par ordre de priorité.
Intégration de Wazuh, de Suricata et de la Suite Elastic

Pour les besoins de cet article, nous avons configuré un environnement lab dans lequel les agents
Wazuh ont été déployés dans plusieurs serveurs connectés à Internet pour monitorer les logs
système et d'applications, l'intégrité des fichiers ainsi que les appels système.

De plus, nous utilisons un capteur Suricata chargé de monitorer le trafic réseau. Ce capteur est
généralement configuré de façon à monitorer le trafic au moyen d'un TAP réseau, d'un port de mise
en miroir ou d'un port SPAN (Switched Port Analyzer), mais il peut aussi être déployé directement
dans vos serveurs.

Pour bénéficier au maximum de ces deux outils, nous avons décidé d'analyser les alertes de Suricata
en appliquant les règles de Wazuh pour unifier le format des alertes, effectuer des corrélations (avec
des sources de Threat Intelligence, par exemple) et déclencher des réponses automatiques.

Cette intégration a été obtenue en configurant un agent Wazuh pour qu'il puisse lire les fichiers JSON
produits par Suricata. Cet agent fait office de collecteur. Il transmet les alertes NIDS de Suricata au
serveur Wazuh pour les traiter conformément aux règles d'analyse de logs de Wazuh et ainsi
produire de nouveaux événements de sécurité enrichis.

Résultat : les alertes NIDS et HIDS sont envoyées à Elasticsearch par l'intermédiaire de Filebeat
(configuré pour lire les alertes Wazuh) et Logstash (également utilisé pour enrichir les données de
géolocalisation). C'est là que nous utiliserons les tâches de machine learning pour détecter les
anomalies et les comportements inhabituels.

Voici l'exemple d'un déploiement de technologies IDS hôte et réseau combinées à la Suite Elastic :

Détection d'acteurs malveillants grâce aux tâches de machine learning

Après avoir activé la totalité des règles dans notre environnement lab, nous avons constaté que
notre agent Wazuh produit entre 4 000 et 10 000 alertes IDS par jour pour un seul serveur Web
connecté à Internet. Ces alertes sont pour la plupart liées à des attaques Web, à des échecs
d'authentification, à des problèmes de configuration (détectés grâce aux vérifications de sécurité
renforcée), à des variations de l'intégrité des fichiers ou à des logiciels vulnérables.
Pour faciliter le travail des analystes de sécurité, des métadonnées, telles que les valeurs de niveau
ou les groupes, enrichissent les alertes IDS de Wazuh pour qu'elles puissent être filtrées par priorité
ou par type. En outre, le plug-in Kibana de Wazuh propose des tableaux de bord préconfigurés qui
contiennent des informations utiles sur le statut de l'agent, la configuration et les alertes. Examinez
la capture d'écran ci-dessous :

L'information fournie par Wazuh est certes utile, mais ne met pas le doigt sur les comportements
inhabituels. C'est là que les tâches de machine learning d'Elastic entrent en scène.

Le machine learning d'Elastic nous offre la possibilité de créer plusieurs types de "tâches". La tâche
est l'élément de base de l'analyse par le machine learning. Dans le cas qui nous intéresse, nous avons
décidé de créer une "analyse de population". Nous avons demandé au moteur de machine learning
de construire un modèle de référence du comportement type des adresses IP sur une période
donnée pour identifier celles qui se comportent de façon anormale par rapport au reste de la
population.

Pour être plus précis, nous souhaitons identifier les adresses IP sources qui, lorsqu'elles sont
comparées à toutes les autres adresses IP, sont à l'origine d'un nombre inhabituellement élevé de
types d'alertes. La création de tableaux d'agrégation ne suffit pas pour obtenir un tel résultat, car les
anomalies se produisent à un moment précis que notre analyste de sécurité ne connait pas. Aussi,
nous disposons de plus de 60 jours d'alertes (nous avons détecté des attaques qui duraient moins de
deux minutes).
Suite à cette analyse de population, nous avons identifié plusieurs comportements anormaux (sous la
forme d'une liste d'adresses IP) que nous avons décidé d'analyser. Nous avons utilisé l'"Anomaly
Explorer" pour savoir quand chacun de ces acteurs potentiellement malveillants a attaqué notre
environnement.

Analyse d'une tentative d'intrusion

Attardons-nous sur l'une des adresses IP identifiées par la tâche de machine learning. Cette adresse
IP a été à l'origine de plusieurs alertes NIDS et HIDS en moins d'une minute. Cela a déclenché une
action Wazuh automatique qui a bloqué l'adresse IP dans le pare-feu local de notre serveur Web.
Comme l'illustre la capture d'écran ci-dessus, le NIDS Suricata a détecté du trafic malveillant
provenant des adresses IP spécifiées. Le trafic entrant a permis de vérifier quatre règles et est à
l'origine des alertes suivantes :

 ET DROP Dshield Block Listed Source group 1

 ET CINS Active Threat Intelligence Poor Reputation IP group 77

 SURICATA HTTP URI terminated by non-compliant character

 SURICATA HTTP METHOD terminated by non-compliant character

Les deux premières règles appartiennent à l'ensemble de règles Emerging Threats. Elles indiquent
que l'adresse IP source a mauvaise réputation d'après les sources de Threat Intelligence (TI) : Dshield
et Active Threat Intelligence.

De plus, deux autres signatures ont détecté une activité HTTP anormale provenant de la même
adresse IP source, probablement dans le cadre d'une phase d'analyse durant laquelle l'assaillant
recueille des informations pour identifier les vulnérabilités potentielles.

Le composant HIDS de Wazuh a également généré différentes alertes suite à l'analyse des logs
d'accès au serveur Web. Cette approche qui se différencie complètement de l'inspection des paquets
réseau a permis de générer les alertes suivantes :

 IP address found in AlienVault reputation database

 Host Blocked by firewall-drop.sh Active Response

 Host Unblocked by firewall-drop.sh Active Response

La première alerte indique que l'adresse IP source est également signalée par une autre source de
Threat Intelligence (TI) : la base de données de réputation IP AlienVault OTX.

Les deux alertes suivantes ont été déclenchées par le module Wazuh Active Response qui, suite aux
alertes déjà mentionnées, a automatiquement ajouté une règle de pare-feu pour bloquer le trafic
provenant de cette adresse IP source pendant exactement 60 secondes (ceci est configurable). Cette
action a suffi à bloquer les activités d'analyse de l'acteur malveillant qui a immédiatement cessé sa
tentative d'intrusion.
Conclusion

Avec des technologies comme Wazuh, Suricata et le machine learning d'Elastic, l'utilisation des
techniques de détection d'intrusion basées sur les signatures et les anomalies permettent de
simplifier la détection des menaces et de rendre leur analyse plus efficace.

D'autre part, l'intégration d'un IDS hôte (pour monitorer les systèmes au niveau de l'hôte) et d'un IDS
réseau (pour inspecter le trafic réseau) permet aussi d'améliorer la détection des menaces et la
visibilité en matière de sécurité. Wazuh simplifie tout cela, car il permet d'intégrer les systèmes IDS
hôte et réseau à la Suite Elastic, et est en mesure de fournir des mécanismes pour déclencher des
réponses automatiques et bloquer des attaques en temps réel.

3333