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.

[pastacode lang= »bash » manual= »%20%3Ccommand%3E%0A%20%20%20%20%3Cname%3Efirewall-drop%3C%2Fname%3E%0A%20%20%20%20%3Cexecutable%3Efirewall-drop%3C%2Fexecutable%3E%0A%20%20%20%20%3Ctimeout_allowed%3Eyes%3C%2Ftimeout_allowed%3E%0A%20%20%3C%2Fcommand%3E » message= » » highlight= » » provider= »manual »/]

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)

[pastacode lang= »bash » manual= »%3Cactive-response%3E%0A%20%20%3Ccommand%3Efirewall-drop%3C%2Fcommand%3E%0A%20%20%3Clocation%3Elocal%3C%2Flocation%3E%0A%20%20%3Crules_id%3E5712%3C%2Frules_id%3E%0A%20%20%3Ctimeout%3E60%3C%2Ftimeout%3E%0A%3C%2Factive-response%3E » message= » » highlight= » » provider= »manual »/]

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 :

[pastacode lang= »bash » manual= »%2Fvar%2Fossec%2Fbin%2Fwazuh-control%20restart » message= » » highlight= » » provider= »manual »/]

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 :

[pastacode lang= »bash » manual= »ping%2010.200.200.13%20-c1″ message= » » highlight= » » provider= »manual »/]

Résultat :

[pastacode lang= »bash » manual= »PING%2010.200.200.13%20(10.200.200.13)%2056(84)%20bytes%20of%20data.%0A64%20bytes%20from%2010.200.200.13%3A%20icmp_seq%3D1%20ttl%3D63%20time%3D40.0%20ms%0A%0A—%2010.200.200.13%20ping%20statistics%20—%0A1%20packets%20transmitted%2C%201%20received%2C%200%25%20packet%20loss%2C%20time%200ms%0Artt%20min%2Favg%2Fmax%2Fmdev%20%3D%2039.964%2F39.964%2F39.964%2F0.000%20ms » message= » » highlight= » » provider= »manual »/]

Authentification ssh avec un compte inexistant :

[pastacode lang= »bash » manual= »root%40my-new-instance%3A~%23%20ssh%20toor%4010.200.200.13%0Atoor%4010.200.200.13%3A%20Permission%20denied%20(publickey).%0A » message= » » highlight= » » provider= »manual »/]

Au bout de 8 tentatives toor est bloqué 60 secondes

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

active_responses_set_unset