Wazuh Blocage des attaques avec Active Response

La réponse active permet à Wazuh d'exécuter des commandes sur un agent en réponse à certains déclencheurs. Dans ce cas d'utilisation, nous simulons une attaque SSH Brute Force et configurons une réponse active pour bloquer l'IP de l'attaquant. Ainsi, dans cet article, vous apprendrez comment bloquer les attaques avec une réponse active.

Détecter l'attaque

Tout d'abord, nous devons savoir quand exécuter la réponse. Nous pouvons utiliser l'une des options suivantes :

ID de règle :la réponse sera exécutée sur tout événement avec l'ID défini.
Groupe de règles :la réponse sera exécutée sur n'importe quel événement du groupe défini.
Niveau :la réponse sera exécutée pour tout événement de ce niveau ou supérieur.

Dans ce cas d'utilisation, nous voulons empêcher les SSH brute force attacks donc quand la règle 5712 - SSHD brute force trying to get access to the system est déclenché, il exécutera la réponse active appropriée pour bloquer l'IP de l'attaquant.

Définir la commande

Nous savons quand la réponse active sera exécutée, maintenant nous devons définir ce qu'elle fera. Vous pouvez créer votre propre script pour bloquer une adresse IP ou toute autre action, mais Wazuh est livré avec un ensemble de scripts communs utilisés en réponse active. Ces scripts sont dans /var/ossec/active-response/bin/ . Nous allons utiliser le firewall-drop script qui fonctionne avec les systèmes d'exploitation Linux/Unix courants et qui permet de bloquer une adresse IP malveillante à l'aide du pare-feu local.

Définir la commande dans le ossec.conf de votre responsable Wazuh :

<command>
  <name>firewall-drop</name>
  <executable>firewall-drop</executable>
  <timeout_allowed>yes</timeout_allowed>
</command>

Définir la réponse active pour bloquer les attaques

Définir la réponse active dans le ossec.conf de votre responsable Wazuh :

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

Redémarrez le gestionnaire Wazuh pour appliquer les modifications.

Preuve de concept

Nous allons simuler une attaque SSH, l'attaque sera exécutée de 10.0.0.6 à notre agent fonctionnant sur 10.0.0.5. Tout d'abord, nous vérifions s'il existe une connectivité entre l'attaquant et l'agent :

[ec2-user@ip-10-0-0-6 ~]$ ping 10.0.0.5
PING 10.0.0.5 (10.0.0.5) 56(84) bytes of data.
64 bytes from 10.0.0.5: icmp_seq=1 ttl=64 time=0.602 ms
64 bytes from 10.0.0.5: icmp_seq=2 ttl=64 time=0.774 ms

Maintenant, nous essayons plusieurs fois de nous connecter à l'agent par SSH en utilisant un utilisateur invalide :

$ ssh 10.0.0.5
Permission denied (publickey).
$ ssh 10.0.0.5
Permission denied (publickey).
$ ssh 10.0.0.5
Permission denied (publickey).
$ ssh 10.0.0.5
Permission denied (publickey).
$ ssh 10.0.0.5
Permission denied (publickey).
$ ssh 10.0.0.5
Permission denied (publickey).
$ ssh 10.0.0.5
Permission denied (publickey).
$ ssh 10.0.0.5
Permission denied (publickey).

Après 8 tentatives, nous pouvons voir dans le gestionnaire comment la règle est déclenchée :

Si on essaie de pinger l'agent de l'attaquant, on voit que ce n'est pas possible :

[ec2-user@ip-10-0-0-6 ~]$ ping 10.0.0.5
PING 10.0.0.5 (10.0.0.5) 56(84) bytes of data.
^C
--- 10.0.0.5 ping statistics ---
12 packets transmitted, 0 received, 100% packet loss, time 11000ms

Générer une alerte lorsqu'une réponse active est déclenchée

Chaque agent a un fichier journal sur /var/ossec/logs/active-responses.log où les activités de réponse active sont enregistrées. Par défaut, ce fichier est surveillé.

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

Lorsque la réponse active est déclenchée, nous pouvons voir l'alerte correspondante :

Ceci est possible car la règle 651 est définie dans ossec_rules.xml . Si vous créez votre propre script, vous devez ajouter la règle appropriée.

Liste blanche

Nous pouvons également définir une liste d'adresses IP qui ne doivent jamais être bloquées par la réponse active. Dans la section globale de ossec.conf dans le Manager, utilisez le champ white_list . Il permet l'adresse IP ou netblock

<ossec_config>
  <global>
    <jsonout_output>yes</jsonout_output>
    <email_notification>no</email_notification>
    <logall>yes</logall>
    <white_list>10.0.0.6</white_list>
  </global>

Augmenter le temps de blocage pour les récidivistes

Nous avons mis en place un temps de blocage de 30 minutes pour notre réponse active, mais au cas où vous auriez besoin d'augmenter ce temps de blocage pour les récidivistes vous pouvez ajouter la configuration suivante dans le ossec.conf de chaque agent :

<active-response>
  <repeated_offenders>60,120,180</repeated_offenders>
</active-response>

La première fois que la réponse active est déclenchée, elle bloquera l'IP pendant 30 minutes, la deuxième fois pendant 60 minutes, la troisième fois pendant 120 minutes et enfin la quatrième fois pendant 180 minutes.

Grâce à la réponse active, vous pouvez effectuer des actions répondant à plusieurs scénarios et restreindre les activités malveillantes et bloquer les attaques. Sachez que toute réponse automatisée comporte un risque implicite, alors définissez soigneusement vos réponses.