Wazuh – Configurer les réponses actives

Wazuh – Configurer les réponses actives

L’objectif de cet article est de montrer comment configurer Wazuh afin qu’il bloque toutes tentatives d’attaques sur l’un de mes serveurs. Une fois le comportement malveillant ou suspect détecté, je peux mettre l’ip de l’attaquant dans un denylist du firewall.

Avant tout, je vais identifier une attaque récurrente détectée sur un des serveurs.

Pour cela, il me suffit d’aller voir dans l’onglet « Sécurity Events » et identifier une attaque qui a un score élevé.

rule_ssh_detect

Ci-dessous une attaque ssh par brute force qui un score de 10 et le numéro de règles 7512.

Ensuite, je vais définir la commande a utiliser pour stopper cette attaque.
 <command>
    <name>firewall-drop</name>
    <executable>firewall-drop</executable>
    <timeout_allowed>yes</timeout_allowed>
  </command>

Ci-dessous une commande présente par défaut dans la configuration de base de Wazuh. Dans /var/ossec/etc/ossec.conf

A savoir que le script « firewall-drop » doit être présent dans le répertoire « /var/ossec/active-response/bin/ » de l’agent. Ce qui est le cas par défaut, cependant si vous utilisez un script personnel alors pensez à le déposer dans ce répertoire et le rendre exécutable.

Enfin, je vais ajouter la réponse à incident qui va prendre en compte la commande vu précédemment, la règle de détection qui déclenchera l’action de défense et enfin le temps de bannissement.

Lecture utile Code de la CYBERSECURITE (Amazon)

<active-response>
  <command>firewall-drop</command>
  <location>local</location>
  <rules_id>5712</rules_id>
  <timeout>60</timeout>
</active-response>

Ci-dessus, le bout de code à mettre dans le fichier de configuration du manager « /var/ossec/etc/ossec.conf »

Explication des balises :

  • command: le script qui sera lancé => firewall-drop.
  • location: La localisation de la réponse, dans notre cas sur l’agent. A savoir qu’elle peut aussi être lancé depuis le manager.
  • rules_id: le script est lancé si la regle 7512 est déclenchée.
  • timeout: le temps de bannissement de l’ip, ici 60s pour tester

Relancer le manager avec la commande suivante :

/var/ossec/bin/wazuh-control restart

 

Maintenant, passons aux tests.

La procédure de test est la suivante : ping => multiple erreurs d’authentifications => ping

Le seconds ping ne devrait pas passer et une alerte sera visible dans Wazuh.

Ping :

ping 10.200.200.13 -c1

Résultat :

PING 10.200.200.13 (10.200.200.13) 56(84) bytes of data.
64 bytes from 10.200.200.13: icmp_seq=1 ttl=63 time=40.0 ms

--- 10.200.200.13 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 39.964/39.964/39.964/0.000 ms

 

Authentification ssh avec un compte inexistant :

root@my-new-instance:~# ssh toor@10.200.200.13
toor@10.200.200.13: Permission denied (publickey).

Au bout de 8 tentatives toor est bloqué 60 secondes

Dans les logs on peut voir ces événements :

active_responses_set_unset

Il convient de configurer le chemin des logs de remédiations dans chaque agent pour voir ces événements dans le dashboard Wazuh.

Le chemin est le suivant :

tail -f /var/ossec/logs/active-responses.log

Voila c’est tout bon, le compte y ait. On a vu ensemble comment configurer la réponse automatique à un incident de sécurité détecté par Wazuh.

 

Cette articles est inspiré par celui-ci : https://documentation.wazuh.com/current/user-manual/capabilities/active-response/ar-use-cases/blocking-attacks.html

 

Livre utile OSSEC (Amazon)

Passionné par les nouvelles technologie, notamment l’électronique et tout ce qui se rapporte de prés ou de loin a ce domaine. Arduino et photographie son mes passe temps favoris.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Post comment