LINUX:Wazuh-Activation des réactions à une tentative d'intrusion
But
Le but d'un HIDS est de détecter des actions malveillante. En fonction du type d'attaque, il est primordial de réagir pour la contrer. Le type d'action présentée consiste à ajouter une règle dans le firewall qui exclu l'accès à cet personne via son adresse IP et ceci pendant un certain temps. Nous utilisons IPTABLES comme firewall.
Le mode d'action est le suivant. Le Manager analyse les informations récupérées de l'Agent. Pour les cas positifs, il émet une action à destination de l'Agent. Cet agent exécute cette action. Il y a donc une configuration à effectuer au niveau du Manager et une au niveau de l'Agent distant.
Configuration du serveur (Manager)
Sur le serveur (Manager) (machine "A"), il faut activer une section dans le fichier "/var/ossec/etc/ossec.conf".
<active-response>
<disabled>no</disabled>
<command>firewall-drop</command>
<location>local</location>
<timeout>86400</timeout>
<rules_id>31103, 31104, 31105, 31106, 31109, 31110, 31151, 31152, 31153, 31154, 31161, 31162, 31163, 31164, 31165, 31166, 31167, 31168, 31169, 31508, 31509, 31510, 31514, 31515, 31516, 31550</rules_id>
</active-response>
Explication des options:
- la commande "firewall-drop" définie précédemment sera activée sur l'agent; elle ajoutera une règle d'exclusion (DROP) dans le firewall IPTABLES.
- Elle s'exécutera sur la machine ayant subit l'attaque ("local"). Il existe d'autres destinations possibles.
- Cette action sera annulée après un certain temps (86400 secondes ou une journée).
- On liste ensuite les règles qui demandent une action ("rules_id").
Ces attaques sont repérées en analysant les journaux sur base de règles. Au final, une règle est activée; chacune possède un niveau d'alerte: le niveau "0" étant le plus bas et signifiant qu'il n'y a pas de problème. Chaque règle est identifiée par un n° unique. On liste donc toutes les règles qui doivent enclencher une action. Les différents n° sont séparés par une virgule et remarque importante, cette option doit être seule et reprise sur une seule ligne!!! J'ai essayé pour une question de lisibilité de la répartir sur plusieurs lignes; toute action devient alors inopérante.
On retrouve la définition de toutes ces règles dans les fichiers se trouvant dans le répertoire "/var/ossec/ruleset/rules" sur le serveur. Elles sont regroupées par applications. Repérez les applications sensibles dans votre cas et dans le fichier concerné, le descriptif ("description") dont le niveau d'alerte ("level") est supérieur ou égal à 7 vous aidera dans notre choix. Amendez aussi la liste en fonction des alertes reçues par mail. La liste données est indicative. Il est également possible d'ajouter nos propres règles dans le répertoire "/var/ossec/etc/rules".
Comme nous voulons utiliser la commande "firewall-drop", nous devons la définir selon le bloc suivant:
<command> <name>firewall-drop</name> <executable>firewall-drop</executable> <timeout_allowed>yes</timeout_allowed> </command>
Ces exécutables se trouvent dans le répertoire "/var/ossec/active-response/bin" aussi bien sur l'agent local (machine "A") que sur les agents distants (machines "B" et suivantes).
Le serveur Wazuh Manager enverra à l'agent concerné, attaqué, l'ordre d'exécution. Cet ordre comprend l'adresse IP de l'attaquant; l'agent en exécutant cette commande, ajoutera une règle de type DROP dans le Firewall; dès cet instant, tout accès de l'attaquant sera refusé. Ces ordres se retrouvent dans le fichier "/var/ossec/logs/active-responses.log" sur l'agent.
L'option "white_list" permet de définir les machines qui ne seront pas exclues. Ceci permet de ne pas se bloquer soi-même. Dans l'exemple, nous avons mis sur liste blanche notre serveur et la machine agent. On suppose alors que l'agent ne sera pas compromis; ce qui est discutable.
<global> <white_list>127.0.0.1</white_list> <white_list>^localhost.localdomain$</white_list> <white_list>192.168.1.110</white_list> <white_list>192.168.1.100</white_list> </global>
Lors de vos tests, vous risquez de vous bloquer vous-même. Ayez une voie alternative pour pouvoir vous débloquer.
Configuration de l'agent distant
Le fichier de configuration "/var/ossec/etc/internal_options.conf" déjà évoqué sur le serveur, existe aussi sur l'agent distant (machines "B" et suivantes). Il y a une option à activer pour permettre l'exécution les parades demandées par le Manager. Ce paramètre est à ajouter dans le fichier local "/var/ossec/etc/local_internal_options.conf". S'il n'existe pas, on le crée.
logcollector.remote_commands=1
Le journal "/var/ossec/logs/active-responses.log"
Les actions arrivent sur l'agent local ou distant en fonction du destinataire. Elles sont reprises dans le fichier "/var/ossec/logs/active-responses.log" au format JSON.
ATTENTION: Ce fichier doit exister. S'il ne l'est pas, créez-le. Il doit appartenir et accessible à l'utilisateur "ossec".
chmod 660 /var/ossec/logs/active-responses.log chown ossec:ossec /var/ossec/logs/active-responses.log
Rotation du journal "/var/ossec/logs/active-responses.log"
Les journaux de Wazuh subissent automatiquement une rotation; c'est à dire que tous les jours, chaque journal est renommé sur base de la date du jour et archivé sauf le journal "/var/ossec/logs/active-responses.log". Il va donc grandir indéfiniment.
On peut profiter dur service "logrotate" normalement installé pour effectuer cette tâche sur ce journal. Il suffit de créer un fichier que l'on nommera "wazuh" dans le répertoire "/etc/logrotate.d".
Voici son contenu sur le serveur (machine "A"):
/var/ossec/logs/active-responses.log {
weekly
missingok
rotate 2
su ossec ossec
create 0660 ossec ossec
postrotate
/usr/bin/systemctl restart wazuh-manager.service > /dev/null 2>&1 || true
endscript
}
Et voici celui sur l'agent (machines "B" et suivantes):
/var/ossec/logs/active-responses.log {
weekly
missingok
rotate 2
su ossec ossec
create 0660 ossec ossec
postrotate
/usr/bin/systemctl restart wazuh-agent.service > /dev/null 2>&1 || true
endscript
}
Dans cette configuration, la rotation se fait une fois par semaine et deux archives sont gardées. Ce processus est effectué par l'utilisateur "ossec". Les droits sur ce nouveau fichier vide est conforme à ce qui est demandé plus haut. Enfin il faut relancer le service wazuh correspondant pour qu'il identifie correctement le nouveau fichier journal créé.