LINUX:Wazuh: HIDS
→ retour au menu pour contrer les attaques
But
Wazuh est un HIDS. Un HIDS (Host Intrusion Detection Systems) est une application qui analyse ce qui se passe sur une machine et sur ses interfaces réseaux. Quand elle repère une activité anormale, elle active une action. Autrement dit elle tache de repérer ceux qui effectuent une activité malveillante à son encontre.
Au contraire les NIDS (Network Intrusion Detection Systems) analysent le trafic réseau qui veut traverser une machine et de repérer les activités anormales pour les contrecarrer. Il sera donc placé sur un noeud du réseau (router, bridge,...).
Notons que l'attaque peut aussi arriver de l'intérieur.
Wazuh est basé à l'origine sur le logiciel OSSEC. Il corrige beaucoup de fonctionnalités et va plus loin.
La documentation se trouve à l'URL suivante (version 4): https://documentation.wazuh.com/4.0/user-manual/overview.html
Schéma fonctionnel
Dans sa configuration de base, Wazuh est constitué de deux composants: le serveur (Wazuh-manager) et de l'agent (Wazuh-agent). L'ensemble du logiciel Wazuh a des extensions permettant une visualisation des résultats et des conseils. Nous n'aborderons par ce second aspect.
- Wazuh-manager le serveur: Le serveur est l'élément central qui rassemble tous les éléments, les analyse et entame des actions éventuelles. On choisit une machine (A) sur laquelle on installe le serveur; mais en même temps un client local sera installé. Cet agent local portera le n° "000"; les échanges avec le serveur se feront via un socket Unix. La partie serveur n'existe que pour Linux.
- Wazuh-agent le client: Sur la machine du serveur (A), on a déjà un agent local. Cette première machine est surveillée. A côté, il faut aussi surveiller d'autres machines. Sur celles-ci, on installe l'agent distant. Les échanges avec le serveur se font via le port TCP 1514 par défaut. Dans le schéma ci-dessous, la pointe de la flèche désigne le serveur au sens service réseau.
A côté un autre service est présent via le port TCP 1515. Ce service est utile lors de la première connexion de l'agent distant au serveur; il récupère auprès du serveur une clé unique qui servira par la suite aux échanges sécurisés entre des deux. Dès ce premier échange fait, il ne sert plus. Par défaut, le n° s'incrémente au fur et à mesure pour chaque agent ("001", "002",...). Le groupe par défaut est "default". La partie agent existe pour divers Unix, Linux et MacOS compris, et Windows.
L'agent est chargé de rassembler les informations locales: journaux, analyse des fichiers, repérage de fonctions malfaisantes (Trojans, Rootkits,...), de problèmes de configurations,... Il envoie ces informations au serveur.
Le serveur décode, analyse ces éléments en suivant un ensemble de règles. En fonction des résultats, des actions sont effectuées: la journalisation, l'envoi de mails et enfin l'exécution d'une action spécifique sur l'agent émetteur (ou autres). Tous ces échanges se font via le port TCP 1514 par défaut entre le serveur et les agents distants.
Recommandation: Le serveur doit être une machine à part, protégée et non celle qui subira de plein fouet les attaques. Car si l'agent est compromis, il aura normalement eu le temps d'envoyer quelques informations au serveur qui aura eu tout le temps de traiter.
Remarque: Nous n'abordons pas la récupération de journaux via le port 514 (UDP ou TCP) suivant la fonctionnalité "Syslog". De même un port TCP 55000 est activé sur le serveur pour l'utilisation des APIs. Il est utile si on ajoute les paquets "elasticsearch", "filebeat", "opendistroforelasticsearch-kibana" qui ajoutent des interfaces Web d'analyses des résultats. Cette facette ne sera également pas abordée. Notons que ce dernier point demande pas mal de ressources.
Installation
Dépôt
Avant l'installation, il faut pouvoir accéder au dépôt. On procède par la création d'un fichier "wazuh.repo" dans le répertoire "/etc/yum.repos.d". Ce fichier est à créer sur le serveur et sur chaque agent distant.
Voici son contenu:
[wazuh] gpgcheck=1 gpgkey=https://packages.wazuh.com/key/GPG-KEY-WAZUH enabled=1 name=EL-$releasever - Wazuh baseurl=https://packages.wazuh.com/4.x/yum/ protect=1
Il est préférable ensuite de procéder à un nettoyage:
dnf clean all
Installation sur le serveur
On installe le paquet suivant sur le serveur:
dnf install wazuh-manager
Installation sur chaque agent distant
On installe le paquet suivant sur l'agent:
dnf install wazuh-agent
Configurer le mur de feu ou FireWall
Comme des échanges se font via le réseau entre le serveur et les agents, il faut ajouter deux règles au FireWall dans le fichier "/etc/sysconfig/iptables".
- Voici ces règles pour IPTABLES à mettre sur le serveur:
-A INPUT -p tcp -m tcp --dport 1514 -s 192.168.1.0/24 -m conntrack --ctstate NEW -j ACCEPT -A INPUT -p tcp -m tcp --dport 1515 -s 192.168.1.0/24 -m conntrack --ctstate NEW -j ACCEPT
Ici on ouvre l'accès à tous le LAN local. On peux être plus restrictif:
- En activant la seconde règle que quand on veut ajouter une nouvelle machine agent.
- En nommant explicitement les adresses IP des agents plutôt que de l'ouvrir à tout le réseau local.
- Voici ces règles pour IPTABLES à mettre sur les agents en supposant que l'adresse IP du serveur est 192.168.1.110:
-A OUTPUT -p tcp -m tcp --dport 1514 -d 192.168.1.110 -j ACCEPT -A OUTPUT -p tcp -m tcp --dport 1515 -d 192.168.1.110 -j ACCEPT
On peut faire la même remarque pour la seconde règle que pour le serveur. Dès que l'agent est reconnu par le serveur, elle peut être éliminée.
Configuration
Configuration du serveur (manager et agent local)
Cette partie concerne la machine dénommée "A".
Le logiciel est installé dans le répertoire "/var/ossec". Le fichier de configuration se trouve dans le sous-répertoire "/var/ossec/etc" et se nomme "ossec.conf". Cette configuration regroupe les options pour la partie Manager et celle concernant l'agent local.
Nous allons modifier quelques sections.
Manager
Le manager nécessite quelques aménagements.
En premier lieu, on modifie le fichier "/var/ossec/etc/ossec.conf".
La première étape est d'être averti par mail si une alerte de déclenche. On définit les paramètres de messagerie. On utilise le serveur de messagerie Postfix local ("smtp_server") et on envoie le message à l'utilisateur "root" local ("email_to"). On nomme l'adresse mail de l'émetteur selon les contraintes du serveur de messagerie ("email_from").
<global> <email_notification>yes</email_notification> <smtp_server>localhost</smtp_server> <email_from>'ossecm@home.dom'</email_from> <email_to>'root@home.dom</email_to> </global>
Ensuite on définit le niveau à partir duquel l'alerte est envoyée dans les journaux ("log_alert_level") et par mail ("email_alert_level"). Chaque alerte possède un niveau qui va de 0 à 16. Le n° 0 signifie l’absence d'alerte. Ces niveaux sont à adapter progressivement en fonction des besoins. Au début, il faut observer ce qui se passe. On adapte les niveaux en fonction.
<alerts> <log_alert_level>4</log_alert_level> <email_alert_level>5</email_alert_level> </alerts>
On élimine le bloc concernant l'option "cluster".
<cluster> </cluster>
Un autre fichier de configuration est central: "/var/ossec/etc/internal_options.conf". Ce fichier comporte des paramètres importants liés au fonctionnement de Wazuh. Ces options sont à manipuler avec précautions. On ne le change pas. Tout paramètre que l'on veut modifier, est à faire dans le fichier local "/var/ossec/etc/local_internal_options.conf". S'il n'existe pas, on le crée.
Nous avons modifié un de ces paramètres afin que le sujet de l'email soit plus explicite. Ceci me facilite la vie en me permettant de classer automatiquement certains mail d'alerte.
maild.full_subject=1
Agent local
Les agents ont leur lot de modifications. On effectue des modifications dans le fichier "/var/ossec/etc/ossec.conf". Ces modifications se retrouveront aussi dans les machines hébergeant l'agent distant (machines "B" et suivantes).
On définit les fichiers journaux que vous voulez surveiller.
<localfile> <log_format>apache</log_format> <location>/var/log/httpd/error_log</location> <age>1d</age> </localfile> <localfile> <log_format>apache</log_format> <location>/var/log/httpd/access_log</location> <age>1d</age> </localfile> <localfile> <log_format>audit</log_format> <location>/var/log/audit/audit.log</location> <age>1d</age> </localfile> <localfile> <log_format>syslog</log_format> <location>/var/log/messages</location> <age>1d</age> </localfile> <localfile> <log_format>syslog</log_format> <location>/var/log/secure</location> <age>1d</age> </localfile> <localfile> <log_format>syslog</log_format> <location>/var/log/maillog</location> <age>1d</age> </localfile> <localfile> <log_format>syslog</log_format> <location>/var/log/dnf.rpm.log</location> <age>1d</age> </localfile>
Dans mon cas, le fireWall a son journal particulier ("/var/log/iptables"); nous l'ajoutons.
<localfile> <log_format>syslog</log_format> <location>/var/log/iptables</location> </localfile>
S'il y en a d'autres, on les ajoute.
Le bloc suivant est nécessaire si vous activez la réaction à une tentative d'intrusion; nous verrons cet aspect par la suite.
<localfile> <log_format>json</log_format> <location>/var/ossec/logs/active-responses.log</location> </localfile>
Dans mon cas, j'ai modifié une autre option. Pour une question de clarté, je ne reprend que l'option concernée située dans ses blocs parents.
On garde la définition de cette commande.
<command> <name>restart-wazuh</name> <executable>restart-wazuh</executable> </command>
La définition de cette commande est nécessaire. Plus bas, nous verrons comment mettre à jour dynamiquement, automatiquement la configuration des agents distants grâce à la configuration "Shared". Ce changement distant de la configuration nécessite que le service de l'agent distant redémarre. Ce bloc défini quel quel exécutable utiliser; ces derniers se trouvent dans le répertoire "/var/ossec/active-response/bin".
Nous gardons également celle que nous utiliserons par la suite dans le cadre de la réaction à une tentative d'intrusion.
<command> <name>firewall-drop</name> <executable>firewall-drop</executable> <timeout_allowed>yes</timeout_allowed> </command>
Les autres "command" peuvent être éliminées.
Configuration de l'agent
Comme sur le serveur, le logiciel est installé dans le répertoire "/var/ossec". Le fichier de configuration se trouve dans le sous-répertoire "/var/ossec/etc" et se nomme "ossec.conf".
Wazuh possède la capacité de centralisation de la majeure partie de la configuration des agents. Cette partie sera placée sur le serveur "Manager" et le "Manager" enverra une copie de cette configuration à chaque Agent. Après réception, l'agent redémarre pour intégrer cette configuration partagée grâce à la commande gardée plus haut ("restart-wazuh").
Agent distant
Cette partie concerne les machines dénommées "B" et suivantes potentielles.
Sa configuration se trouve dans le fichier "/var/ossec/etc/ossec.conf". Nous ne gardons que la section "client"). Elle est fondamentale car on y définit l'adresse IP du serveur partie "Manager". Le reste est à mettre de côté pour un usage ultérieur.
<ossec_config>
<client>
<server>
<address>192.168.1.110</address>
<port>1514</port>
<protocol>tcp</protocol>
</server>
<config-profile>fedora, fedora40</config-profile>
<notify_time>10</notify_time>
<time-reconnect>60</time-reconnect>
<auto_restart>yes</auto_restart>
<crypto_method>aes</crypto_method>
</client>
</ossec_config>
Au passage, remarquons que l'installation a reconnu le nom de notre distribution.
Le fichier de configuration "/var/ossec/etc/internal_options.conf" déjà évoqué sur le serveur, existe aussi sur l'agent distant (machines "B" et suivantes). Il y a deux options qu'il est utile d'activer.
Ces paramètres sont à ajouter dans le fichier local "/var/ossec/etc/local_internal_options.conf". S'il n'existe pas, on le crée.
wazuh_command.remote_commands=1 logcollector.remote_commands=1
Maintenant passons à la partie partagée. L'installation ne comprend pas cette configuration; il faut donc la créer. Cette configuration sera à faire sur la machine "A".
On se base sur la partie du fichier de configuration d'origine de l'agent distant que nous avons mis de côté plus haut. Elle est à placer dans un fichier nommé "agent.conf". Elle doit être incluse entre les balises suivantes:
<agent_config> </agent_config>
en remplacement des balises:
<ossec_config> </ossec_config>
On y applique les modifications effectuées pour l'agent local vues plus haut.
Ce fichier est à placer sur le serveur. Il est possible de définir des groupes d'agents ayant chacun une configuration appropriée. Un groupe est défini par défaut et se nomme "default". Tout nouvel agent y est intégré d'office; il est possible de créer d'autres groupes et ensuite de migrer un agent d'un groupe à l'autre. Nous n'utiliserons ici que ce groupe "default". Les fichiers de configuration des agents de ce groupe se retrouvent dans le répertoire "/var/ossec/etc/shared/default". On remarque que le nom de ce répertoire est le même que celui du groupe. On y ajoute le fichier "agent.conf" créé ci-dessus.
Dès que l'agent se connecte au serveur, le contenu de ce répertoire sera recopié sur la machine agent dans le répertoire "/var/ossec/etc/shared". L'agent intègre automatiquement cette configuration. Toute modification ultérieure sur le serveur de ce fichier "agent.conf" est automatiquement répercutée et activée sur les agents de ce groupe.
Si on crée un autre groupe, on recopie ces fichiers dans un répertoire parallèle portant le nom de ce groupe. On personnalise en conséquence le fichier "agent.conf".
Remarque
On ne touche pas au reste. Sur le site Web de Wazuh, la documentation vous aidera pour aller plus loin. De nombreuses sections peuvent être éliminées, activées ou désactivées en fonction de vos préférences.
Activer et lancer les services
Le service du serveur
Le service à lancer est Wazuh-manager. La première commande active le service pour qu'à chaque démarrage du serveur, le service se lance. La seconde lance directement le service. La troisième relance le service.
systemctl enable wazuh-manager systemctl start wazuh-manager systemctl restart wazuh-manager
Le service de l'agent
Le service à lancer est Wazuh-agent. La première commande active le service pour qu'à chaque démarrage du serveur, le service se lance. La seconde lance directement le service. La troisième relance le service.
systemctl enable wazuh-agent systemctl start wazuh-agent systemctl restart wazuh-agent
Dès que l'agent sera lancé, il essaye de se connecter au serveur et si c'est la première fois, il y a échange de clés entre eux via le port TCP 1515 afin que l'agent soit reconnu par la suite.
Activation des réactions à une tentative d'intrusion
Le but d'un HIDS est de détecter des actions malveillante. En fonction du type d'attaque, il est primordial de réagir pour la contrer. Le type d'action présentée consiste à ajouter une règle dans le firewall qui exclu l'accès à cet personne via son adresse IP et ceci pendant un certain temps. Nous utilisons IPTABLES comme firewall.
Journaux
Sur le serveur et sur les agents distants, il faut consulter les journaux de ces services. Ce journal se nomme "/var/ossec/logs/ossec.log". Repérez tout message d'erreur et tachez d'y remédier.
Si c'est possible, essayez de provoquer une alerte. Sinon attendez le lendemain; si vous êtes présent sur Internet, des actions malveillantes sont très fréquentes. Vous recevrez un mail et cette alerte sera enregistrée dans le fichier "/var/ossec/logs/alerts/alerts.log" du serveur selon les niveaux limites définis dans le fichier de configuration du serveur.
Quelques utilitaires
Ces utilitaires se trouvent dans le répertoire "/var/ossec/bin". Ceux-ci sont à exécuter sur le serveur. Elles permettront aussi de valider la reconnaissance de l'agent distant.
- wazuh-logtest : Vérifier la réaction aux règles
- agent_control -lc : Lister des agents
- agent_control -i 000 : Lister le détail de l'agent local "000"
- agent_control -i 001 : Lister le détail de l'agent distant "001"
- agent_groups -l : Lister des groupes
- agent_groups -l -g default : Lister des agents distants du groupe "default"
- agent_groups -s -i 001 : Lister le nom du groupe de l'agent distant "001"
Analyse: décodeurs et règles
Le serveur manager de Wazuh récolte les journaux auprès des agents. Ces journaux sont ensuite analysés. Une première phase consiste à décoder le journal pour y repérer des informations utiles. Sur cette base, un ensemble de règles analysent cette information prédigérée pour au final émettre un alarme graduée de 0 à 16, le niveau 0 étant l’absence d'alarme.
Statistiques
Au fur et à mesure, les attaques se diversifient et s'accumulent. A partir des adresses IP, on peut connaitre le pays d'origine et de là établir des statistiques.
Actions préventives
Jusqu'ici nous avons traité de l'aspect des actions immédiates à toute attaque. Wazuh dispose de divers autres modules ayant une action préventives. Ils tentent à repérer des problèmes potentiels de sécurité afin que nous puissions combler ces trous de sécurité.
API
Wazuh dispose d'un interface de type HTTP qui permet d'interagir avec Wazuh Manager.
Interface Utilisateur Web (WUI)
Wazuh dispose d'un outil additionnel sous forme d'interface utilisateur Web. Il permet de consulter les résultats des diverses analyses effectuées accompagnées de nombreux graphiques, d'avoir accès à la configuration,... Les alertes sont regroupées par jour et les graphiques qui en découlent sont présentés sous forme chronologiques.
→ retour au menu pour contrer les attaques