lid's Wiki

title: Sécurité des infrastructures: HIDS et NIDS - Introduction
description:
published: true
date: 2026-02-19T18:15:08.470Z
tags:
editor: markdown
dateCreated: 2023-12-19T17:45:17.308Z

Logistique

Nous allons avoir besoin de 3 VMs:

Monitoring et Supervision

Les années précédentes, nous avons vu les différents types de supervision des infrastructures.

Pour rappel, on distingue trois grands axes de supervision:

Réseau

Ici, on va principalement surveiller l'état du réseau et de ses différents composants:

Le protocole de choix reste ici SNMP, avec des solutions spécialisées comme Observium ou LibreNMS. Des visualisations de type WeatherMap permettent en un coup d'oeil de vérifier l'état du réseau et d'identifier les comportements anormaux.

Système

La supervision Système se concentre, elle, sur la collecte et l'aggrégation de métriques purement système:

Applicative

La supervision Applicative elle se focalise sur le bon fonctionnement des applicatifs de l'infrastructure. On peut citer pêle-mêle:

Ici, on utilisera généralement conjointement des solutions de supervision classiques ainsi que de l'aggrégation de logs, et potentiellement des outils comme Sentry qui nous remontera, notamment, les erreurs applicatives ainsi que leur origine dans le code source de notre applicatif.

Solutions

Il existe pléthore de solutions de supervision, de Nagios à Zabbix en passant par Prometheus/Grafana, couplée à des solutions d'aggrégation de logs telles qu'ELK, Graylog ou bien Loki (très prometteur)

On utilise en général conjointement plusieurs solutions de supervision afin d'obtenir la meilleure visibilité possible sur notre infrastructure.

Malwares

Maintenant, lorsqu'on administre un système d'information, qu'il s'agisse de postes de travail ou de serveurs, d'un site Web à fort trafic, ou de tout autre système traitant des données personnelles, il est important de s'assurer non seulement du bon fonctionnement de l'infrastructure, mais aussi de la bonne "santé" de la dite infrastructure, c'est à dire de l'absence de logiciels malveillants. Pour celà, il est important d'être proactif et de partir du principe que notre infrastructure sera, un jour ou l'autre, compromise, et de mettre en place les outils nécessaires à la détection de cette compromission afin d'assurer la meilleure réactivité possible.

En effet, les facteurs d'infection ne manquent pas:

Tout autant de failles, humaines, logicielles voire matérielles pouvant ouvrir la porte à des invités indésirables tels que:

Heureusement, il existe des outils permettant de sécuriser son infrastructure en respectant de bonnes pratiques, et permettant de repérer les comportements anormaux sur nos réseaux, ou sur nos machines:

HIDS et NIDS

On a vu qu'avec différents outils de supervision, on peut obtenir une bonne visibilité sur l'état matériel, système et applicatif, voire des indications sur des tentatives d'intrusion (notamment grâce à l'aggrégation de logs).

Cependant, il est tout aussi essentiel d'avoir une bonne visibilité sur l'état, les versions, et les potentielles failles de sécurité des différents applicatifs exécutés sur notre infrastructure, ainsi que d'être capable de détecter de potentiels comportements anormaux sur notre réseau, afin d'être alerté en temps réel si l'un des logiciels utilisés présente une faille de sécurité, ou si un comportement réseau est anormal.

Pour cela, on utilise deux types de solutions:

HIDS: Wazuh

Wazuh est un HIDS basé sur OSSEC, ElasticSearch et Kibana. Il permet de s'assurer de la bonne conformité de notre infrastructure par rapport aux différentes recommandations et normes (MITRE, PCI-DSS, etc). Bonus, il peut intégrer les données de différentes NIDS (Suricata par exemple) dans son dashboard. La classe 😃

Il nécessite l'installation d'un agent sur les machines à surveiller. Cet agent procèdera à la recherche de rootkits, au monitoring des logs et aux modifications apportées aux fichiers du système ainsi qu'aux fichiers de configuration, et bien évidemment à la collecte et à la centralisation de ces données sur notre serveur Wazuh. Cet agent est compatible:

Installation

On va se créer une VM Debian classique avec la config suivante: (là encore, faut de la ressource)

En effet Wazuh utilise, en /backend/, ElasticSearch et Kibana qui, s'ils sont des logiciels très utiles et performants dans leurs domaines respectifs, n'en restent pas moins très gourmands par rapport aux configurations de nos laptops.

Installons déjà les prérequis sur notre VM Wazuh:

sudo apt install docker.io docker-compose
# on ajoute notre utilisateur au groupe docker
# ici, l'utilisateur s'appelle "michel":
sudo usermod -aG docker michel

De plus, Elastic Search va nécessiter que nous modifions la configuration du /kernel/ en éditant son fichier de configuration:

$ sudo nano /etc/sysctl.d/10-vmmaxmap.conf
# ajouter en fin de fichier:
vm.max_map_count=262144
# sauvegarder et quitter puis:
$ sudo systemctl restart systemd-sysctl
# pour recharger la conf' noyau.

On va ensuite installer git, puis cloner le repository wazuh-docker contenant un docker-compose préconstruit qui va nous permettre de tester Wazuh (attention ce n'est pas une install à utiliser en production, je vous ai mis le lien de la doc' d'install "de prod" en fin de document 😉)

# on installe git:
$ sudo apt install git
# on clone le repo
$ git clone https://github.com/wazuh/wazuh-docker.git -b v4.7.0

Il ne nous reste plus qu'à lancer la /stack/ docker-compose de wazuh:

Note: si on a pensé à ajouter notre utilisateur au groupe docker, il n'est plus nécessaire d'utiliser sudo, c'est mieux! sudo usermod -aG docker nom-de-votre-utilisateur

$ cd wazuh-docker/single-node
$ sudo docker-compose -f generate-indexer-certs.yml run --rm generator
$ sudo docker-compose up

on peut désormais accéder à l'interface (kibana) de Wazuh à l'adresse: https://ip_de_la_vm. Par exemple, si votre VM docker a pour IP '192.168.144.12' on se connectera à https://192.168.1.144.12. Vous pouvez ignorer l'erreur de certificat de votre navigateur, en effet nous utilisons un certificat auto-signé fourni dans le container.

Dans une install "de prod" nous utiliserions soit de "vrais" certificats soit des certificats auto-signés que nous aurions générés par nos propres moyens (par exemple en générant une autorité de certification racine (CA) dont nous aurions ajouté les certificats à la configuration de nos machines, etc).

Note: le login par défaut est admin et son mot de passe est SecretPassword. Bien évidemment... changez ça en prod! voire, utilisez un gestionnaire d'identité (LDAP/AD, KeyCloak, Authentik, Dex...) pour authentifier vos utilisateurs et utilisatrices, de préférence avec une méthode de 2FA!

On peut maintenant passer à l'installation de l'agent Wazuh sur nos VMs Web et BDD.

Configuration de l'agent

Pour installer l'agent Wazuh sur nos machines, il faut:

/Note: autre solution, installer à la main l'agent Wazuh, cf doc officielle/

C'est parti 😃

# on installe les prérequis
$ sudo apt install curl apt-transport-https gnupg
# on installe la clef GPG dans le trousseau
$ curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | sudo apt-key add -
# on cree le fichier source pour le depot Wazuh
$ echo "deb https://packages.wazuh.com/4.x/apt/ stable main" | \
       sudo tee -a /etc/apt/sources.list.d/wazuh.list
# on met à jour la base des paquets:
$ sudo apt update

On souffle un peu 😃

Et on installe l'agent. Attention, il y a une feinte: on précise une variable d'environnement (man environment) sur la ligne de commande, qui doit contenir l'IP de notre VM docker-wazuh. On installe (enfin), en supposant ici que l'IP de notre vm docker est 10.50.0.1:

$ sudo WAZUH_MANAGER="10.50.0.1" apt install wazuh-agent

On vérifie ensuite le contenu du fichier de configuration d'ossec:

$ sudo nano /var/ossec/etc/ossec.conf
# on doit avoir une ligne du style:
<client>
  <server>
    <address>10.50.0.1</address>
    ...
  </server>
</client>
# et surtout pas:
<address>MANAGER_IP</address>
# si c'est le cas
# on remplace

Et on a plus qu'à activer le service de l'agent et le lancer:

$ sudo systemctl enable wazuh-agent
$ sudo systemctl start wazuh-agent
# on checke qu'il tourne bien
$ sudo systemctl status wazuh-agent

Maintenant, on peut aller regarder tout ce qui remonte de cette machine comme infos sur l'interface web de Wazuh. Vous verrez que par défaut, si une Debian de base est "safe" point de vue réseau (enfin si vous avez mis en place les règles iptables qui vont bien, que ssh n'est pas en mode login/mot-de-passe, etc), du point de vue local, il y a plusieurs choses à faire suivant les normes qu'on veut respecter (PCI-DSS, etc).

Et Wazuh nous propose, en prime, les actions à effectuer (ou pas) pour régler le problème - c'est le genre de choses que je vous enjoins fortement à recetter via des logiciels comme Ansible ou Puppet notamment pour des questions de reproducibilité.

Mise en pratique

Nous allons installer sur notre VM "poste de travail" un pseudo-rootkit: Diamorphine. Il va falloir le compiler à la main. Il s'agit d'un module kernel qui va se "cacher" (i.e. qui ne permet pas de le lister sur un lsmod) et qui permet une élévation de privilèges lorsqu'on lui envoie un signal spécifique.

On va d'abord installer git et le nécessaire pour le compiler sur notre VM "poste de travail" (bien vérifier la version de son kernel, et adapter le nom du paquet linux-headers-* en fonction):

apt install git build-essential linux-headers-6.1.0-16-amd64
git clone https://github.com/m0nad/Diamorphine
cd Diamorphine
make
sudo insmod diamorphine.ko

Sur un lsmod, on ne verra pas le module installé:

lsmod

Maintenant, si on désire "masquer/démasquer" le module:

kill -63 0

Et si on veut que notre utilisateur passe root:

kill -64 0

Et enfin, si on veut décharger le module du kernel (une fois le module "révélé"):

rmmod diamorphine

On va aussi tester les détecteurs de rootkits habituels: chkrootkit, rkhunter. On les installe sur notre poste de travail, puis on les exécute. Détectent-ils Diamorphine (lorsque diamorphine est "caché", et lorsqu'il est "démasqué" via kill -63 0)?

Testez plusieurs options!

Maintenant, retournons à notre Wazuh, a-t-il pris note d'un évènement particulier? (Je vous laisse chercher un peu 😃)

NIDS: Suricata, Snort, Zeek...

En règle générale, notre NIDS sera placé entre nos points d'entrées (routeurs) et notre infrastructure. Cela signifie qu'en règle générale, une des interfaces de notre NIDS sera reliée à un port miroir de nos commutateurs, le but étant de transférer une copie de l'activité réseau à notre NIDS pour analyse. Bien évidemment, plus il y a d'activité, plus le réseau est de taille importante, et plus les ressources requises par notre NIDS seront importantes... 😃

Afin de pouvoir quand même tester le fonctionnement de notre ami Suricata, on peut utiliser la recette docker-compose suivante, sur un VM fraîchement créée:

version: '3'

services:
  suricata:
    image: jasonish/suricata:latest
    network_mode: "host"
    cap_add:
      - NET_ADMIN
      - SYS_NICE
    volumes:
      - log:/var/log/suricata
      - lib:/var/lib/suricata
      - /run/suricata:/run/suricata
    environment:
      - SURICATA_OPTIONS=-i eth0
      
volumes:
  log:
    driver: local
  lib:
    driver: local

Qui va nous lancer un suricata de base préconfiguré (cool).

Une fois lancé, on va exécuter un shell dans notre container suricata, afin de mettre à jour sa base de définitions:

docker exec -it suricata_suricata_1 /bin/bash
suricata-update

Une fois l'update terminée, on peut sortir de notre container, et on va tester le fonctionnement de notre IDS via une règle de test. On va d'abord vouloir /tail/ notre fichier de log suricata qui va se trouver dans /var/lib/docker/volumes/suricata_log/_data/fast.log, puis installer curl si ce n'est déjà fait et enfin curl une URL de test:

apt install curl
curl http://testmynids.org/uid/index.html

On devrait obtenir une ligne du style (les antislash sont pour la mise en page):

01/06/2023-09:25:02.090949  [**] [1:2100498:7] GPL ATTACK_RESPONSE id check returned root [**] \
[Classification: Potentially Bad Traffic] [Priority: 2] {TCP} \
2600:9000:244f:c600:0018:30b3:e400:93a1:80 -> 2a01:0e0a:0b83:9d50:64e4:80ff:fe6d:6e41:52776

Cool, ça fonctionne! Maintenant, on voudra agréger ces logs dans une solution de type ELK/Graylog/Loki/Splunk/whatever afin d'avoir un visuel en temps réel du trafic de notre infrastructure.

On peut aussi utiliser une solution comme SELKS: https://github.com/StamusNetworks/SELKS (open-source) ou IDSTower (https://www.idstower.com/ , propriétaire)

Pour SELKS, on peut se le tester si on a 8Go de RAM dispo (minimum!! donc idéalement, 12 à 16Go de RAM sur notre laptop, et il nous faudra aussi docker 1.27+ 😂).

On installe d'abord git sur notre VM docker, puis on clone le dépôt SELKS:

git clone https://github.com/StamusNetworks/SELKS
cd SELKS/docker
./easy-setup.sh
docker-compose up -d

On peut ensuite accéder à la WebUI de SELKS: https://ip_vm/

Mais comme Wazuh permet via son agent de récupérer les logs de suricata (eve.json, au format JSON, donc), on va utiliser Wazuh!

Tout d'abord, on va configurer notre VM Suricata en routeur, en éditant le fichier sysctl.conf:

sudo nano /etc/sysctl.conf

Et en décommentant la ligne:

net.ipv4.ip_forward=1

Enfin, on va activer le NAT entre notre sous-réseau 192.168.110.0/24 et l'extérieur:

sudo iptables -t nat -A POSTROUTING -s 192.168.110.0/24 -d 0.0.0.0/0 -j ACCEPT
sudo iptables-save > /etc/iptables.rules
sudo vim /etc/network/interfaces
# modifier le fichier: (adapter au nom de votre interface réseau)
iface eth1 inet static
  address 192.168.110.1/24
  up iptables-restore < /etc/iptables.rules

Sur notre VM "Poste de travail", on va configurer notre passerelle par défaut pour qu'il utilise notre "routeur":

sudo ip route del default
sudo ip route add default via 192.168.110.1

On va ensuite connecter Suricata à Wazuh. Pour cela, on installe l'agent Wazuh sur notre "routeur".

Puis on modifie la configuration de notre agent Wazuh de la sorte:

sudo vim /var/ossec/etc/ossec.conf
# on ajoute les lignes suivantes
# juste avant </ossec_config>
<localfile>
  <log_format>json</log_format>
  <location>/var/log/suricata/eve.json</location>
</localfile>

et on relance notre agent Wazuh.

Sur notre webui Wazuh, en se plaçant sur le Module Security Events, et en cherchant:

rules.groups:suricata

On devrait voir arriver les logs de Suricata. Il ne nous reste plus qu'à effectuer des requêtes, par exemple vers testmynids.org pour vérifier le fonctionnement de la solution 😃