De Elastic Stack à Wazuh
J’ai toujours joué avec le duo gagnant Fail2ban et PSAD pour protéger les serveurs internets de mes clients. Deux HIPS (Host Intrusion Protection System) qui travaillent de concert avec iptables et se contentent de bien faire ce qu’on leur demande ! Le seul problème étant de faire remonter les informations… De quoi saturer votre boite mail que vous vous empresserez de vider chaque matin sans même consulter les alertes…
Et c’est là qu’intervient le SIEM (Security Information and Event Management) et donc d’Elastic Stack (anciennement ELK) la plateforme de référence dont la mission est d’ingérer simultanément des données provenant de multiples sources, puis de les transformer et les envoyer vers Elasticsearch, un moteur de recherche (nosql) et d’analyse, pour permettre aux utilisateurs de visualiser des données avec des tableaux et des graphes dans Kibana, son outil de visualisation.
On se sert (entre autres solutions possibles) de beats, qui sont des petits agents que l’on met sur les serveurs dont on veut analyser les logs… Et notamment de filebeat, qui est un agent avec de nombreux modules pour apache, nginx, suricata… Mais pas pour fail2ban ou psad !
Il a donc fallu y remédier en rajoutant à filebeat des inputs et des ingest-pipelines (pour la géolocalisation, notamment). Le but étant de parser les journaux de fail2ban et de psad et de les envoyer à elasticsearch en nous servant de dissect qui, comme son nom l’indique est un processeur de dissection qui segmente les chaînes entrantes à l’aide de modèles définis (et notamment avec l’aide de https://dissect-tester.jorgelbg.me/).
Et puis Elastic Stack a changé de licence, anciennement sous licence Apache 2.0, et dorénavant basée sur le principe de tarification en fonction des ressources ! J’ai donc cherché une alternative… Et je suis tombé sur Wazuh ! Une plateforme libre unifiée SIEM/XDR… Elle-même basée à la fois sur OSSEC un IDS libre, et sur le fork libre d’Elastic Stack !
Pour ce qui est du SIEM, et donc de remonter dans notre cas, les journaux de Fail2ban et PSAD, Wazuh se sert de templates Filebeat, et cela s’est avéré assez simple. Même si Fail2ban n’envoyant pas ses journaux dans syslog, il a fallu commencer par dire à Wazuh de les collecter. Cela peut se faire sur les agents concernés ou sur le manager de façon centralisée. Et ensuite, il nous a fallut écrire un decoder de la ligne de log et une règle correspondante :
La ligne de log en question :
2023-05-03 09:41:27,045 fail2ban.actions [722]: NOTICE [sshd] Ban 192.168.2.77
Le decoder:
<decoder name="fail2ban"> <prematch>[\d+]: NOTICE\s+[\S+] Ban \d+.\d+.\d+.\d+</prematch> <regex>[(\S+)] Ban (\d+.\d+.\d+.\d+)</regex> <order>jail,srcip</order> </decoder>
Et la règle pour générer l’alerte :
<rule id="100002" level="5">
<decoded_as>fail2ban</decoded_as>
<description>IP $(srcip) banned by Fail2ban jail $(jail)</description>
<group>authentification_failed</group>
<mitre>
<id>T1110</id>
</mitre>
Et pour PSAD :
La ligne de log en question :
2023-05-03T10:54:21.555505+02:00 debian psad: scan detected (Nmap -sT or -sS scan): 192.168.2.77 -> 192.168.2.63 tcp: [32-55056] flags: SYN tcp pkts: 30 DL: 4 total scan dsts: 1Le decoder:
<decoder name="psad">
<program_name>psad</program_name>
<prematch>scan detected</prematch>
<regex>(\S+)\s->\s(\S+)\s(\w+):</regex>
<order>srcip,dstip,protocol</order>
</decoder>
Et la règle pour générer l’alerte :
<rule id="100003" level="5">
<decoded_as>psad</decoded_as>
<description>Port scan $(protocol) detected from $(srcip)</description>
<group>recon</group>
<mitre>
<id>T1046</id>
</mitre>
</rule>
Et maintenant venons-en au XDR (Détection et Réponse Étendue). En effet, nous pouvons avec Wazuh, nous passer de fail2ban et le remplacer par une réponse active centralisée, ici, firewall-drop, en nous basant sur les alertes de Wazuh :
<active-response>
<command>firewall-drop</command>
<location>local</location>
<rules_id>5760,5710</rules_id>
<timeout>300</timeout>
</active-response>Il n’y a pas véritablement de détection de scans de ports à la PSAD, sur wazuh, on peut par contre configurer PSAD en IDS simple et laisser Wazuh gérer la réponse :
<active-response>
<command>firewall-drop</command>
<location>local</location>
<rules_id>100003</rules_id>
<timeout>300</timeout>
</active-response>Ces règles sont sommaires, et peuvent bien sûr être améliorées mais le principe est là…
Il y a plein d’autres modules sur Wazuh, (File Integrity, Rootcheck, Audit…) et autant de possibilités. Et je ne regrette pas un instant d’avoir abandonné Elastic Stack. Même si son apprentissage a grandement facilité mon adoption de Wazuh. Eh oui, c’est ça, la force des logiciels libres. Et aujourd’hui, en tant que formateur, je dois bien dire qu’au niveau de l’installation, de la configuration et de la mise en œuvre, Wazuh est beaucoup plus facile d’accès qu’ Elastic Stack. Même si ce n’est que mon avis, bien sûr !