WIKI sur Linux (ADB)

« LINUX:Wazuh: HIDS » : différence entre les versions

← Modification précédente
Aucun résumé des modifications
Aucun résumé des modifications
 
(26 versions intermédiaires par le même utilisateur non affichées)
Ligne 23 : Ligne 23 :




[[FILE:LINUX:Wazuh1.png|800px|center]]
[[FILE:LINUX:Wazuh.1.pdf|800px|center]]




Ligne 31 : Ligne 31 :




[[FILE:LINUX:Wazuh2.png|800px|center]]
[[FILE:LINUX:Wazuh.2.pdf|800px|center]]




Ligne 49 : Ligne 49 :
  [wazuh]
  [wazuh]
  gpgcheck=1
  gpgcheck=1
  gpgkey=https://packages.wazuh.com/key/GPG-KEY-WAZUH
  gpgkey=<nowiki>https://packages.wazuh.com/key/GPG-KEY-WAZUH</nowiki>
  enabled=1
  enabled=1
  name=EL-$releasever - Wazuh
  name=EL-$releasever - Wazuh
  baseurl=https://packages.wazuh.com/4.x/yum/
  baseurl=<nowiki>https://packages.wazuh.com/4.x/yum/</nowiki>
  protect=1
  protect=1
----
----
Ligne 71 : Ligne 71 :


=Configurer le mur de feu ou FireWall=
=Configurer le mur de feu ou FireWall=
Comme des échanges se font via le réseau entre le serveur et les agents, il faut ajouter deux règles au FireWall.  
Comme des échanges se font via le réseau entre le serveur et les agents, il faut ajouter deux règles au FireWall dans le fichier "/etc/sysconfig/iptables".  


* Voici ces règles pour IPTABLES à mettre sur le serveur:
* Voici ces règles pour IPTABLES à mettre sur le serveur:
----
----
  -A INPUT -p tcp -m tcp --dport 1514  -s 192.168.1.0/24 -j ACCEPT
  -A INPUT -p tcp -m tcp --dport 1514  -s 192.168.1.0/24 -m conntrack --ctstate NEW -j ACCEPT
  -A INPUT -p tcp -m tcp --dport 1515  -s 192.168.1.0/24 -j ACCEPT
  -A INPUT -p tcp -m tcp --dport 1515  -s 192.168.1.0/24 -m conntrack --ctstate NEW -j ACCEPT
----
----
Ici on ouvre l'accès à tous le LAN local. On peux être plus restrictif:
Ici on ouvre l'accès à tous le LAN local. On peux être plus restrictif:
Ligne 122 : Ligne 122 :
  </alerts>
  </alerts>
----
----
Dans mon cas, j'ai modifié quelques autres options.
 
Pour une question de clarté, je ne reprend que l'option concernée située dans ses blocs parents.
 
On active la surveillance liée à la distribution "RedHat" comme nous utilisons "Fedora".
----
  <vulnerability-detector>
    <enabled>'''yes'''</enabled>
    <provider name="redhat">
      <enabled>'''yes'''</enabled>
    </provider>
  </vulnerability-detector>
----
On élimine le bloc concernant l'option "cluster".
On élimine le bloc concernant l'option "cluster".
----
----
Ligne 209 : Ligne 200 :
Pour une question de clarté, je ne reprend que l'option concernée située dans ses blocs parents.
Pour une question de clarté, je ne reprend que l'option concernée située dans ses blocs parents.


L'analyse des paquets logiciels est désactivé.
 
----
  <wodle name="syscollector">
    <packages>'''no'''</packages>
  </wodle>
----
On garde la définition de cette commande.
On garde la définition de cette commande.
----
----
Ligne 222 : Ligne 208 :
   </command>
   </command>
----
----
Ainsi que celle que nous utiliserons par la suite dans le cadre de la réaction à une tentative d'intrusion.
La définition de cette commande est nécessaire. Plus bas, nous verrons comment mettre à jour dynamiquement, automatiquement la configuration des agents distants grâce à la configuration '''"Shared"'''. Ce changement distant de la configuration nécessite que le service de l'agent distant redémarre. Ce bloc défini quel quel exécutable utiliser; ces derniers se trouvent dans le répertoire  "/var/ossec/active-response/bin".
 
 
Nous gardons également celle que nous utiliserons par la suite dans le cadre de la réaction à une tentative d'intrusion.
----
----
   <command>
   <command>
Ligne 231 : Ligne 220 :
----
----
Les autres "command" peuvent être éliminées.
Les autres "command" peuvent être éliminées.
Une section mérite votre attention. Le serveur vérifie les modifications apportées à un certains nombre de fichiers et spécialement le répertoire "/etc" qui contient toutes les configurations. J'ai installé "WebMin" et certains fichiers se modifient continuellement; nous allons donc les ignorer.
----
  <syscheck>
    '''<ignore>/etc/webmin/system-status/info</ignore>'''
    '''<ignore>/etc/webmin/system-status/history</ignore>'''
  </syscheck>
----




Ligne 260 : Ligne 241 :
       <protocol>tcp</protocol>
       <protocol>tcp</protocol>
     </server>
     </server>
     <config-profile>'''fedora, fedora34'''</config-profile>
     <config-profile>'''fedora, fedora40'''</config-profile>
     <notify_time>10</notify_time>
     <notify_time>10</notify_time>
     <time-reconnect>60</time-reconnect>
     <time-reconnect>60</time-reconnect>
Ligne 269 : Ligne 250 :
----
----
Au passage, remarquons que l'installation a reconnu le nom de notre distribution.
Au passage, remarquons que l'installation a reconnu le nom de notre distribution.
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 deux options qu'il est utile d'activer.
Ces paramètres sont à ajouter dans le fichier local "'''/var/ossec/etc/local_internal_options.conf'''". S'il n'existe pas, on le crée.
----
wazuh_command.remote_commands=1
logcollector.remote_commands=1
----




Ligne 298 : Ligne 287 :
==Remarque==
==Remarque==
On ne touche pas au reste. Sur le site Web de Wazuh, la documentation vous aidera pour aller plus loin. De nombreuses sections peuvent être éliminées, activées ou désactivées en fonction de vos préférences.  
On ne touche pas au reste. Sur le site Web de Wazuh, la documentation vous aidera pour aller plus loin. De nombreuses sections peuvent être éliminées, activées ou désactivées en fonction de vos préférences.  
=Activation des réactions à une tentative d'intrusion=
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".
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éé.




Ligne 405 : Ligne 305 :
  systemctl restart wazuh-agent
  systemctl restart wazuh-agent
Dès que l'agent sera lancé, il essaye de se connecter au serveur et si c'est la première fois, il y a échange de clés entre eux via le port TCP 1515 afin que l'agent soit reconnu par la suite.
Dès que l'agent sera lancé, il essaye de se connecter au serveur et si c'est la première fois, il y a échange de clés entre eux via le port TCP 1515 afin que l'agent soit reconnu par la suite.
=[[LINUX:Wazuh-Activation des réactions à une tentative d'intrusion|Activation des réactions à une tentative d'intrusion]]=
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.




Ligne 425 : Ligne 329 :




=[[LINUX:Wazuh: Décodeurs et Règles|Analyse: décodeurs et règles]]=
=[[LINUX:Wazuh-Décodeurs et Règles|Analyse: décodeurs et règles]]=
Le serveur manager de Wazuh récolte les journaux auprès des agents. Ces journaux sont ensuite analysés. Une première phase consiste à décoder le journal pour y repérer des informations utiles. Sur cette base, un ensemble de règles analysent cette information prédigérée pour au final émettre un alarme graduée de 0 à 16, le niveau 0 étant l’absence d'alarme.
Le serveur manager de Wazuh récolte les journaux auprès des agents. Ces journaux sont ensuite analysés. Une première phase consiste à décoder le journal pour y repérer des informations utiles. Sur cette base, un ensemble de règles analysent cette information prédigérée pour au final émettre un alarme graduée de 0 à 16, le niveau 0 étant l’absence d'alarme.




=[[LINUX:Wazuh-Statistiques|Statistiques]]=
Au fur et à mesure, les attaques se diversifient et s'accumulent. A partir des adresses IP, on peut connaitre le pays d'origine et de là établir des statistiques.
=[[LINUX:Wazuh-Actions préventives|Actions préventives]]=
Jusqu'ici nous avons traité de l'aspect des actions immédiates à toute attaque. Wazuh dispose de divers autres modules ayant une action préventives. Ils tentent à repérer des problèmes potentiels de sécurité afin que nous puissions combler ces trous de sécurité.
=[[LINUX:Wazuh-API|API]]=
Wazuh dispose d'un interface de type HTTP qui permet d'interagir avec Wazuh Manager.
=[[LINUX:Wazuh-WUI|Interface Utilisateur Web (WUI)]]=
Wazuh dispose d'un outil additionnel sous forme d'interface utilisateur Web. Il permet de consulter les résultats des diverses analyses effectuées accompagnées de nombreux graphiques, d'avoir accès à la configuration,...
Les alertes sont regroupées par jour et les graphiques qui en découlent sont présentés sous forme chronologiques.




Récupérée de "https://www.adbweb.gslb.eu/wiki/index.php?title=LINUX:Wazuh:_HIDS"