Wazuh - Remontée et analyse des logs (puit)

La sécurité d'un environnement passe par l'analyse en continu des logs des systèmes et des applicatifs.

Généralement, on récupère les logs sur chaque système puis ils sont envoyés vers un puit de logs. Ce puit est un service ou un serveur dont l'objectif premier est de stocker les logs sur une durée déterminée et réglementaire.

Les logs sont ensuite envoyés vers une stack d'analyse et d'alerting.

De nombreuses stacks d'analyse existent sur le marché, wazuh en fait partie à travers sa fonctionnalité Log Data Collection.

Cette fonctionnalité permet :

De remonter les logs vers le wazuh server,
De les stocker,
De les analyser,
De créer des alertes pour déclarer des incidents de sécurité par exmeple.

Normes des logs

Les logs du système respectent les normes RFC. Cependant, certains logiciels peuvent ne pas les appliquer et ces logs ont alors leur propre format.

Dans ce cas :

par défaut le log ne respecte pas un format, mais le logiciel permet tout de même de « personnaliser » le format des logs,
ou bien utiliser rsyslog permet de transposer un log non conforme vers un log conforme aux RFC.

Configurer la remontée de log système et applicatif

La configuration par défaut du wazuh agent inclus déjà l'envoi des fichiers de logs suivants (entre autres):

  <localfile>
    <log_format>syslog</log_format>
    <location>/var/ossec/logs/active-responses.log</location>
  </localfile>

  <localfile>
    <log_format>syslog</log_format>
    <location>/var/log/auth.log</location>
  </localfile>

  <localfile>
    <log_format>syslog</log_format>
    <location>/var/log/syslog</location>
  </localfile>

  <localfile>
    <log_format>syslog</log_format>
    <location>/var/log/dpkg.log</location>
  </localfile>

  <localfile>
    <log_format>syslog</log_format>
    <location>/var/log/kern.log</location>
  </localfile>

On constate dans cette configuration qur les logs remontés ont tous un format : syslog.

Selon l'OS et le logiciel, plusieurs formats peuvent être pris en charge par wazuh.

Configurer la remontée de log via rsyslog vers le wazuh server

Wazuh peut récupérer les logs via rsyslog.

Dans quels cas de figure ?

Un équipement sur lequel l'agent wazuh ne peut pas être installé mais qui est capable d'envoyer des logs.
Un choix stratégique d'utiliser des configurations rsyslog sur chaque OS pour ensuite centraliser sur Wazuh.

Configuration

Sur le serveur wazuh, il faut ajouter à sa configuration /var/ossec/etc/ossec.conf l'écoute de tout log syslog sur son port 514 :

<remote>
  <connection>syslog</connection>
  <port>514</port>
  <protocol>tcp</protocol>
  <allowed-ips>10.0.10.0/24</allowed-ips>
  <local_ip>192.168.56.30</local_ip>
</remote>

Port 514 : port en écoute sur le serveur wazuh pour la réception des logs syslog
Protocol TCP : l'envoi des logs peut être UDP ou TCP, selon l'environnement le TCP est vivement recommandé afin de s'assurer que l'ensemble des logs arrivent
Allowed IP : IP ou subnet à autoriser
Local IP : IP du serveur wazuh

Puis il faut redémarrer le manager :

systemctl restart wazuh-manager

Dans la configuration /etc/rsyslog.conf, il faut indiquer ce que l'on souhaite envoyer et vers quelle destination :

input(type="imfile" ruleset="squid-logs" Tag="squid-logs" File="/var/log/squid/access.log")

ruleset(name="SquidLogs") {
        action(
        type="omfwd"
        target="192.168.56.30"
        port="514"
        protocol="tcp"
        template="LogTemplate"
        queue.SpoolDirectory="/var/spool/rsyslog"
        queue.FileName="squid-logs"
        queue.MaxDiskSpace="1g"
        queue.SaveOnShutdown="on"
        queue.Type="LinkedList"
        ResendLastMSGOnReconnect="on"
        )
        stop
}

Ici, nous envoyons vers le wazuh serveur les logs /var/log/squid/access.log.

Un exemple

Nous allons ajouter la surveillance du log sudo.log sur le wazuh agent dans /var/ossec/etc/ossec.conf

On génère un log sudo:

sudo -u user_non_existant

Logs /var/log/sudo.log :

Jan  5 14:08:10 ubuntu-jammy sudo:     root : unknown user user_non_existant ; TTY=pts/1 ; PWD=/var/ossec/etc ; USER=user_non_existant ;

Nous avons maintenant un log généré :

Comme pour chaque évènement wazuh, nous avons un nombre important d'informations (en autres):

data.command : on retrouve notre commande sudo
data.pwd : le répertoire à partir duquel la commande a été éxecutée
agent.ip : ip de l'agent wazuh

Pre-decoding, Decoding, Rule Matching

Le processus pour passer du log système à la remontée sur wazuh est le suivant :

Pre-decoding : extraction des informations suivantes : timestamp, hostname, programme + segmentation de la ligne de log,
Decoding : identification des composants clés de chaque entrée de log,
Rule Matching : wazuh compare les logs décodés aux règles définies, selon la correspondance le log est remonté en alerte ou pas.

Aller plus loin

Cette fonctionnalité permet de simplifier la gestion, le stockage et l'analyse des logs.

Néamoins, nous pouvons dire qu'il y a 3 stratégies principales :

Avoir un wazuh agent qui remonte les logs pour l'analyse vers le wazuh server,
Avoir un rsyslog qui stocke les logs vers un serveur ou service rsyslog dédié, ainsi que le wazuh agent qui envoie en parallèle vers le wazuh server les logs, uniquement à des fins d'analyse et non de stockage,
Avoir un wazuh agent installé sur le rsyslog qui stocke les logs pour les envoyer au wazuh server uniquement pour de l'analyse.