WordPress et Elasticsearch – Gestion des informations et des événements de sécurité

Introduction

Code sur Github: ELK WordPress SIEM

Ce tutoriel montre comment vous pouvez configurer la gestion des informations et des événements de sécurité (SIEM) de base pour les clusters de serveurs Linux hébergeant de nombreux sites Web WordPress.

Notre solution utilisera Elasticsearch, Kibana, Logstash, Beats Library, Clam Antivirus et Fail2Ban.

Ce diagramme représente l'infrastructure que nous devons mettre à niveau pour SIEM.

Ce diagramme montre notre objectif/solution :

Exigences

Dans la vidéo, nous avons utilisé trois machines virtuelles Ubuntu 22.04 dans un service cloud. Leurs spécifications étaient les suivantes :

• Deux des machines disposaient de 2 Go de mémoire et d'un processeur. Elles servaient de serveurs WordPress.
• L'une des machines disposait de 8 Go de mémoire et de 2 processeurs. Elle servait de serveur Elasticsearch.

La mémoire et le processeur indiqués sont exigences minimales. Certains services peuvent échouer à s'installer si vous disposez de moins de ressources que le minimum.

Mesures

Étape 0 - Installer WordPress

Si vous possédez déjà au moins une instance WordPress, vous pouvez ignorer cette étape. Pour référence, voici ma configuration WordPress. Vous pouvez ignorer cette étape si vous possédez déjà au moins une instance WordPress. Pour référence, je décrirai les étapes de ma démonstration WordPress.(uniquement pour la démonstration, pas entièrement sécurisé pour une utilisation en production).

J'ai créé un script bash appelé install-wordpress.sh. Vous pouvez télécharger le script ici :

• Script pour installer WordPress sur Ubuntu

N'oubliez pas de mettre à jour la variable ip_server avec l'adresse IP de votre serveur. Si vous utilisez des adresses IP locales commençant par 172. ou 192. pour tester sur un réseau local, n'oubliez pas de configurer les enregistrements FQDN appropriés dans votre /etc/hosts fichier pour garantir que les URL correspondent à l'adresse IP de votre serveur WordPress.

Exécuter le ./install-wordpress.sh pour installer et configurer tous les services backend pour WordPress.

Accédez à votre navigateur pour visiter http://web1.evermight.net, http://web2.evermight.net, et http://web3.evermight.net pour terminer votre configuration. Vous pouvez voir le nom d'utilisateur, le mot de passe et les noms de base de données MySQL spécifiés dans le ./install-wordpress.sh fichier. Au moment de la rédaction de cet article, ils sont web1, web1-ABCD-pass, web1 respectivement. Remplacer 1 avec 2 ou 3 pour web2 et web3 respectivement.

Vous pouvez répéter ces étapes pour des serveurs supplémentaires.

Étape 1 - Configurer Elasticsearch et Kibana

Cette étape est probablement celle par laquelle la plupart des gens commenceront, car la plupart des gens avaient déjà Étape 0 mis en place d'une manière ou d'une autre.

Nous devons configurer Elasticsearch pour stocker et gérer les données d'observabilité et SIEM provenant de nos serveurs WordPress. Nous proposons de nombreux autres guides expliquant comment procéder. Voici deux des plus populaires que vous connaissez peut-être et qui pourraient également convenir pour cette vidéo :

1. Configurer ELK avec des certificats auto-signés -Explication vidéo & Résumé écrit
2. Configurer ELK avec des certificats auto-signés avec Docker -Explication vidéo & Résumé écrit

Nous utiliserons une version simplifiée de la deuxième option, plus simple à réaliser pour les tests. Voici les étapes simplifiées :

Étape 1.1 – Configurer le serveur Ubuntu

Allons-y Git, Docker, Docker Compose et boucle sur le serveur en utilisant ces commandes :

apt-get update; apt-get install -y docker docker-compose git curl vim;

Étape 1.2 - Exécuter le projet Docker + Elasticsearch

Nous pouvons démarrer Elasticsearch et Kibana en utilisant notre projet Github ici :

• Elasticsearch + Kibana + Docker Compose

Exécutez ces commandes :

git clone https://github.com/evermight/elk-wordpress-siem.git; cd elk-wordpress-siem/es; cp env.sample .env; docker-compose up --build -d;

NOTE- pensez à utiliser des mots de passe différents dans votre .env fichier avant d'exécuter le docker-compose up --build -d.

Vous pouvez désormais accéder à Elasticsearch via Kibana en visitant https://[elastic.ip.address]:5601.

Connectez-vous avec l'utilisateur elastic et le mot de passe spécifié dans votre .env déposer.

Facultatif - Mettre à jour le fichier hôte sur l'ordinateur de travail

Il peut être fastidieux de toujours saisir l'adresse IP du serveur Elasticsearch dans votre navigateur web. Nous mettrons à jour le fichier hôte de l'ordinateur avec le navigateur web afin que le nom d'hôte soit correctement saisi.kibana correspond à l'adresse IP des serveurs Elasticsearch et Kibana. Désormais, nous accéderons au site web de Kibana avec https://kibana:5601.

Étape 1.3 – Préparer les scripts d’installation

Nous avons préparé des scripts bash dans le répertoire ~/elk-wordpress-siem/es/scripts pour faciliter l'intégration de Beats, Logstash, WordPress, ClamAV et Fail2ban.

Ces bash scripts de configuration effectuez des requêtes HTTP vers l'API REST Elasticsearch et l'API REST Kibana pour configurer de nouvelles ressources telles que des comptes utilisateurs, des index, des vues de données, des connecteurs, des visualisations, des tableaux de bord, des règles, etc. Si vous choisissez de ne pas utiliser ces scripts bash, vous pouvez les configurer manuellement via l'interface Web de Kibana.

Nous utiliserons notre scripts de configuration, pour garder les choses simples et automatisées.

Avant de pouvoir les utiliser, nous devons créer un .env fichier pour notre scripts de configuration. Le .env Le fichier contiendra les informations de connexion à notre instance Elasticsearch et Kibana. Exécutez simplement ces commandes :

cd ~/elk-wordpress-siem/es/scripts; cp env.sample .env;

Notez que dans notre .env fichier, nous avons déjà spécifié ELASTIC_HOST et KIBANA_HOST. Vous pouvez modifier ces valeurs pour pointer vers une instance complètement différente d'Elasticsearch/Kibana. Cela concerne tout ce qui se trouve dans ce fichier.~/elk-wordpress-siem/es/scripts le répertoire peut être réutilisé pour d'autres instances ELK.

Pour notre cas d'utilisation actuel, nous avons besoin es01 et kibana pour pointer vers 127.0.0.1 qui est lui-même. Ajoutez les lignes suivantes au /etc/hosts fichier du serveur Elasticsearch :

echo '127.0.0.1 es01 kibana' >> /etc/hosts;

Une fois terminé, vous pouvez ping es01 ou ping kibana depuis la fenêtre du terminal, pour voir que ces noms d'hôtes font référence à la machine actuelle.

Vous pouvez désormais les utiliser scripts de configuration dans les étapes suivantes.

Étape 1.4 - Configuration de l'utilisateur de l'agent

Pour des raisons de sécurité, nous ne souhaitons pas utiliser l'existant elastic Le superutilisateur est le compte permettant de connecter des services tels que la bibliothèque Beats, WordPress, ClamAV, etc. à Elasticsearch. Nous allons créer un compte utilisateur différent, spécifié par le AGENT_USER variable dans le ~/elk-wordpress-siem/es/scripts/.env fichier en exécutant cette commande ou ce script :

cd ~/elk-wordpress-siem/es/scripts; ./setup-step-1.4.sh

Vous pouvez confirmer que cet utilisateur a été créé en cliquant sur Kibana > Gestion de la pile > Utilisateurs.

Étape 2 : Configurer la bibliothèque Beats sur le serveur WordPress FIRST

Choisissez le premier serveur WordPress sur lequel vous souhaitez installer la bibliothèque Beats et connectez-vous en SSH.

Étape 2.1 - Mettre à jour le fichier hôte

Ce serveur doit pouvoir accéder à Elasticsearch et Kibana via le nom d'hôte. Exécutez la commande suivante :

echo "[elastic.ip.address] es01 kibana" >> /etc/hosts

Remplacer le [elastic.ip.address] avec l'adresse IP du serveur de Étape 1.2.

Étape 2.2 - Obtenir le certificat de l'AC

Vous devrez copier le certificat TLS de l'autorité de certification créé par votre Elasticsearch.

Sur votre serveur WordPress, créez un répertoire pour votre CA avec cette commande :

mkdir -p /etc/certs/es/

Sur votre serveur Elasticsearch, obtenez votre CA avec ces commandes :

docker cp wp-es01-1:/usr/share/elasticsearch/config/certs/ca/ca.crt /tmp/. cat /tmp/ca.crt

Copier le contenu /tmp/ca.crt le contenu de votre serveur Elasticsearch dans un nouveau fichier appelé /etc/certs/es/ca.crt sur votre serveur WordPress.

Étape 2.3 - Installer Beats Library

Installer Metricbeat, Filebeat, Auditbeat, Packetbeat sur votre serveur WordPress avec ces commandes :

wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add -; sudo apt-get install apt-transport-https; echo "deb https://artifacts.elastic.co/packages/8.x/apt stable main" | sudo tee -a /etc/apt/sources.list.d/elastic-8.x.list; sudo apt-get update && sudo apt-get -y install metricbeat filebeat auditbeat packetbeat;

Étape 2.4 – Mettre à jour les fichiers YML de chaque beat

Copiez les fichiers de configuration trouvés sous le ~/es/beats Ajoutez le répertoire Elasticsearch à votre serveur WordPress. Vous pouvez exécuter cette commande depuis votre serveur Elasticsearch :

cd ~/elk-wordpress-siem/ scp -r ./beats/* root@[wordpress-server]:/etc/

Remplacer le [wordpress-server] avec l'adresse IP de votre serveur WordPress.

Note - Dans le /etc/metricbeat/modules.d/mysql.yml, assurez-vous que les informations d'identification de la base de données sont correctes.

Étape 2.5 - Mettre à jour l'utilisateur Beat - (FACULTATIF)

Facultatif - Dans Étape 1.3, le ~/elk-wordpress-siem/es/scripts/setup.sh J'ai créé un nouvel utilisateur pour la bibliothèque Beats. Le nom d'utilisateur et le mot de passe sont visibles dans la variable.AGENT_USER et AGENT_PASS dans le fichier ~/elk-wordpress-siem/es/scripts/.env fichier. Le yml fichiers dans Étape 2.4 sont configurés pour utiliser les valeurs spécifiées par AGENT_USER et AGENT_PASS. Vous pouvez modifier les fichiers yml pour utiliser un autre utilisateur avant de passer à l'étape suivante.

Étape 2.6 - Initialiser Elasticsearch pour utiliser Beats -(UNE SEULE FOIS)

Effectuez cette étape UNE SEULE FOIS.

Pour utiliser la bibliothèque Beats, nous devons configurer Elasticsearch avec de nouveaux flux de données, index, vues de données, pipelines, etc... Si ceux-ci ont déjà été configurés par une installation précédente de beats utilisée sur d'autres serveurs,alors vous devez ignorer cette étape et passer à l'étape 2.7.

Depuis votre serveur WordPress, exécutez ces commandes pour configurer Elasticsearch et Kibana afin d'utiliser la bibliothèque Beats pour la première fois :

/usr/share/metricbeat/bin/metricbeat test config -c /etc/metricbeat/metricbeat.yml --path.data /var/lib/metricbeat --path.home /usr/share/metricbeat; /usr/share/metricbeat/bin/metricbeat test output -c /etc/metricbeat/metricbeat.yml --path.data /var/lib/metricbeat --path.home /usr/share/metricbeat; /usr/share/metricbeat/bin/metricbeat setup -c /etc/metricbeat/metricbeat.yml --path.data /var/lib/metricbeat --path.home /usr/share/metricbeat; /usr/share/filebeat/bin/filebeat test config -c /etc/filebeat/filebeat.yml --path.data /var/lib/filebeat --path.home /usr/share/filebeat; /usr/share/filebeat/bin/filebeat test output -c /etc/filebeat/filebeat.yml --path.data /var/lib/filebeat --path.home /usr/share/filebeat; /usr/share/filebeat/bin/filebeat setup -c /etc/filebeat/filebeat.yml --path.data /var/lib/filebeat --path.home /usr/share/filebeat; /usr/share/auditbeat/bin/auditbeat test config -c /etc/auditbeat/auditbeat.yml --path.data /var/lib/auditbeat --path.home /usr/share/auditbeat; /usr/share/auditbeat/bin/auditbeat test output -c /etc/auditbeat/auditbeat.yml --path.data /var/lib/auditbeat --path.home /usr/share/auditbeat; /usr/share/auditbeat/bin/auditbeat setup -c /etc/auditbeat/auditbeat.yml --path.data /var/lib/auditbeat --path.home /usr/share/auditbeat; /usr/share/packetbeat/bin/packetbeat test config -c /etc/packetbeat/packetbeat.yml --path.data /var/lib/packetbeat --path.home /usr/share/packetbeat; /usr/share/packetbeat/bin/packetbeat test output -c /etc/packetbeat/packetbeat.yml --path.data /var/lib/packetbeat --path.home /usr/share/packetbeat; /usr/share/packetbeat/bin/packetbeat setup -c /etc/packetbeat/packetbeat.yml --path.data /var/lib/packetbeat --path.home /usr/share/packetbeat;

Revenez ensuite à votre serveur Elasticsearch et exécutez ces commandes pour configurer les ressources élastiques restantes pour SIEM :

cd ~/elk-wordpress-siem/es/scripts; ./setup-step-2.x.sh

Confirmez que les éléments sont installés en :

• visite Kibana > Gestion de la pile > Règles and
• noter l'existence de nombreuses règles telles que Analyses antivirus Clam, Fichier Hosts modifié [Dupliqué] etc...

Voici une capture d’écran qui montre une configuration réussie :

Étape 2.7 – Activer et démarrer Beat Services

Activez et démarrez chacun des services beat avec ces commandes :

systemctl enable metricbeat.service; systemctl enable filebeat.service; systemctl enable auditbeat.service; systemctl enable packetbeat.service; systemctl start metricbeat.service; systemctl start filebeat.service; systemctl start auditbeat.service; systemctl start packetbeat.service;

Confirmez que les rythmes fonctionnent en visitant certains des Kibana > Analyses > Tableaux de bord. Par exemple, cette capture d'écran de Kibana > Analyse > Tableaux de bord > Présentation de l'hôte Metricbeat ECS implique Metricbeat fonctionne correctement :

Étape 2.8 - Capturer les plugins WordPress obsolètes

Nous souhaitons être informés dès qu'une extension WordPress devient obsolète sur l'un de nos sites web. Nous disposons d'une extension simple qui permet d'envoyer les informations de version d'une extension à Elasticsearch et que vous pouvez installer sur chaque site WordPress. L'extension est définie par le fichier ~/elk-wordpress-siem/wordpress/wp-content/plugins/evermight/evermight.php. Avant de copier ce fichier sur votre site Web WordPress, ouvrez le fichier et regardez ces 3 lignes :

define('ES_USER', 'myagent'); define('ES_PASS', 'changeme'); define('PING_INTERVAL', 60*60*12); // minimum number of seconds to wait before next ES submission

Le ES_USER, ES_PASS a été automatiquement codé en dur avec les valeurs de Étape 1.3. N'hésitez pas à modifier ces deux valeurs ainsi que le PING_INTERVAL à quelque chose que vous trouvez plus approprié.

Lorsque vous êtes prêt, copiez le plugin sur votre serveur WordPress :

scp ~/elk-wordpress-siem/wordpress/wp-content/plugins/* root@[wordpress-server]:~/

Remplacer [wordpress-server] with the IP address of your WordPress server.

Sur votre serveur WordPress, copiez le plugin sur chaque site WordPress et mettez à jour les autorisations des fichiers :

mkdir wp-plugins/; mv evermight wp-plugins/; cp -r wp-plugins/* /var/www/web1/wp-content/plugins; cp -r wp-plugins/* /var/www/web2/wp-content/plugins; cp -r wp-plugins/* /var/www/web3/wp-content/plugins; chown -R www-data:www-data /var/www/web1/wp-content/plugins; chown -R www-data:www-data /var/www/web2/wp-content/plugins; chown -R www-data:www-data /var/www/web3/wp-content/plugins;

Connectez-vous à Administration WordPress > Plugins > Plugins installés et Activer le Moniteur de plugin WordPress Elasticsearch.

Envoyez les informations du plugin à Elasticsearch en visitant chacune de ces URL dans votre navigateur Web :

http://web1.evermight.net/?rest_route=/evermight/v1/plugin-check http://web2.evermight.net/?rest_route=/evermight/v1/plugin-check http://web3.evermight.net/?rest_route=/evermight/v1/plugin-check

Confirmez que vous avez reçu les informations du plugin en visitant Kibana > Outils de développement et en exécutant cette requête :

GET /wp-plugins/_search

Alternativement, vous pouvez voir les détails du plugin dans le Kibana > Découvrir > wp-plugins.

Nous créerons un tableau de bord et une alerte par e-mail pour les plugins WordPress obsolètes dans une étape ultérieure.

Étape 2.9 - Heartbeat - Moniteur de disponibilité et vérificateur de plugins WordPress

Dans cette étape,Pulsation fera un ping sur le plugin WordPress que nous avons créé à l'étape précédente AND surveiller la disponibilité de chaque site Web.

Dans notre ~/elk-wordpress-siem/es/docker-compose.yml, nous avons spécifié un conteneur pour Pulsation. Le conteneur utilisera le fichier de configuration ~/elk-wordpress-siem/beats/heartbeat/heartbeat.yml. Vous pouvez voir que notre fichier de configuration vérifiera automatiquement le ~/elk-wordpress-siem/beats/heartbeat/monitors.d/ répertoire toutes les quelques secondes pour les sites Web que nous devons surveiller.

Pour commencer, nous avons déjà répertorié http://web1.evermight.net/ à http://web3.evermight.net/. Vous pouvez ajouter plus d'URL ~/elk-wordpress-siem/beats/heartbeat/monitors.d/wordpress.yml ou ajouter un nouveau yml fichier avec de nouvelles URL.Pulsation chargera automatiquement les nouvelles configurations toutes les quelques secondes.

Nous avons également créé un ~/elk-wordpress-siem/beats/heartbeat/monitors.d/wordpress-plugin.yml en utilisant des conventions similaires mais il envoie un ping au plugin que nous avons créé à l'étape précédente.

Si vous effectuez des tests localement, vous souhaiterez peut-être exécuter une commande similaire à celle ci-dessous pour permettre à votre conteneur d'atteindre votre serveur WordPress via des noms de domaine :

docker exec -it wp-heartbeat01-1 bash; echo '[wordpress-server-ip] web1.evermight.net web2.evermight.net web3.evermight.net' >> /etc/hosts; exit;

Vous pouvez consulter les moniteurs sur Kibana > Observabilité > Disponibilité > Moniteurs. Nous configurerons des alertes par e-mail dans les étapes ultérieures.

Étape 2.10 - ClamAV Antivirus

Nous allons installer ClamAV Un antivirus est installé sur le serveur WordPress afin qu'il puisse l'analyser régulièrement à la recherche de virus et de logiciels malveillants. Nous enverrons ensuite les journaux d'analyse à Elasticsearch. Dans les étapes suivantes, nous configurerons Elasticsearch pour qu'il nous avertisse de la détection de virus.

Installer clamav avec cette commande :

apt-get update; apt-get install -y clamav;

Nous avons préparé quelques scripts utiles pour l'exécution ClamAV. Sur votre serveur WordPress, créez un nouveau répertoire :

mkdir ~/clamscans

Copiez les fichiers dans ~/elk-wordpress-siem/clamscans/* de votre serveur Elasticsearch vers le ~/clamscans répertoire de votre serveur WordPress.

scp ~/elk-wordpress-siem/* root@[wordpress-server-ip]:~/clamscans/

Sur votre serveur WordPress, créez un .env déposer:

cd ~/clamscans; cp env.sample .env;

Modifier les détails de connexion du .env si nécessaire.

Vous pouvez maintenant exécuter le fichier ~/clamscans/clamscan.sh -d [directory you want to scan] pour analyser n'importe quel répertoire de votre serveur. Les journaux d'analyse seront disponibles dans le ~/clamscans/log/scan.log le fichier et les fichiers en quarantaine seront dans le ~/clamscans/q répertoire.

Vous pouvez envoyer les résultats de ~/clamscans/log/scan.log vers Elasticsearch en exécutant ~/clamscans/send.sh. Les journaux apparaîtront dans l'index Elasticsearch appelé clamscans. Aller à Kibana > Outils de développement pour exécuter la requête GET /clamscans/_search pour consulter les journaux. Vous pouvez également consulter les journaux ClamAV.Kibana > Découvrir > clamscans.

Ajoutez le ~/clamscans/scan.sh et ~/clamscans/send.sh au Cron tâche du serveur WordPress de les exécuter périodiquement.

Étape 2.11 - Installer Fail2Ban

Nous allons installer Fail2Ban pour bannir automatiquement les adresses IP qui adoptent des comportements suspects. Nous souhaitons également bannir une adresse IP pour 5 minutes s'ils échouent 10 fois au cours des derniers 5 minutes via /wp-login URL.

Installer Fail2ban avec:

apt-get update; apt-get install fail2ban;

Configurez un fichier de prison en copiant le modèle :

cp jail.conf jail.local

Vous pouvez voir que le contenu de jail.local fait référence à tous les filtres (c'est-à-dire les règles de correspondance regex pour les fichiers journaux) dans le /etc/fail2ban/filters.d répertoire. Nous allons créer un filtre supplémentaire pour notre règle de connexion WordPress échouée et créer un lien vers celui-ci depuis jail.local.

Créez un fichier appelé /etc/fail2ban/filters.d/wordpress-login.conf et collez ce contenu :

[Définition]

badagents =

failregex = ^<HÔTE> -.*"(GET|POST|HEAD) \/+wp-login.*$
^web[0-9]+.evermight.net:80 <HÔTE> -.*"(GET|POST|HEAD) \/+wp-login.*$

ignoreregex =

Ajoutez ensuite ce code à notre jail.local pour créer une nouvelle prison qui bloque un utilisateur pendant 5 minutes s'il n'a pas réussi à se connecter 10 fois au cours des 5 dernières minutes :

[wordpress-login] enabled = true logpath = %(apache_access_log)s findtime = 300 bantime = 300 maxretry = 10

Commencer Fail2ban

systemctl enable fail2ban; systemctl start fail2ban;

Vous pouvez tester la règle en essayant 10 tentatives de connexion infructueuses pour voir si votre adresse IP est bannie.

Vous pouvez consulter les adresses IP interdites avec la commande fail2ban-client status wordpress-login.

Vous pouvez débloquer des adresses IP avec cette commande fail2ban-client set YOURJAILNAMEHERE unbanip IPADDRESSHER;

Note- Vous pouvez également exécuter le iptables -S commande pour vérifier comment Fail2ban a mis à jour vos IPTables sous-jacentes.

Étape 3 – Configurer des serveurs WordPress supplémentaires

Pour créer plus de serveurs WordPress, répétez Étape 2.1 à Étape 2.13 mais sauter Étape 2.6.

Remplacer web1.* à web3.* et toute mention de [wordpress-server-ip] avec l'adresse IP de votre prochain serveur WordPress.

Étape 4 - Examiner les tableaux de bord des beats utiles

La bibliothèque de beats propose de nombreux tableaux de bord utiles. Voici quelques-uns des plus remarquables :Kibana > Tableaux de bord:

Apache :

• [Filebeat Apache] Journaux d'accès et d'erreurs ECS
• [Metricbeat Apache] Présentation d'ECS

MySQL:

• [Filebeat MySQL] Présentation d'ECS
• [Metricbeat MySQL] Présentation de la base de données

Système opérateur:

• [Système Filebeat] Tableau de bord Syslog ECS - Contient des liens vers d'autres tableaux de bord associés
• [Système Metricbeat] Présentation de l'hôte ECS - Contient des liens vers d'autres tableaux de bord associés
• [Système Auditbeat] Présentation du système ECS - Contient des liens vers d'autres tableaux de bord associés
• [Auditbeat File Integrity] Présentation d'ECS
• [Auditbeat Auditd] Présentation d'ECS
• [Filebeat Iptables] Présentation d'ECS

Étape 5 - Activer les règles et les alertes par e-mail

Aller à Kibana > Gestion de la pile > Règles et activez la règle de votre choix. Essayez ensuite de déclencher certaines de ces règles.

Si vous souhaitez recevoir des alertes par e-mail, mettez à jour le SMTP_* variables dans le ~/elk-wordpress-siem/es/.env fichier et docker restart wp-logstash01-1.

Si tu veux courir Logstash depuis la machine hôte sans docker, copiez les fichiers ~/elk-wordpress-siem/logstash/logstash/* à /etc/logstash/ de votre machine hôte. Créez un .env de la env.sample fichier. Exécutez ensuite Logstash en utilisant la commande indiquée dans /etc/logstash/run.sh.