« LINUX:Wazuh-VULNERABILITY-DETECTEUR » : différence entre les versions

De WIKI sur Linux (ADB)
Aller à la navigation Aller à la recherche
Aucun résumé des modifications
Aucun résumé des modifications
Ligne 50 : Ligne 50 :
Ces règles ne s'appliqueront qu'à cette distribution Red Hat Entreprise de version 9. Or nous utilisons la distribution Fedora de versions 36 et 37. Il faut donc étendre l'utilisation de ces règles à nos deux OS.
Ces règles ne s'appliqueront qu'à cette distribution Red Hat Entreprise de version 9. Or nous utilisons la distribution Fedora de versions 36 et 37. Il faut donc étendre l'utilisation de ces règles à nos deux OS.


C'est le but de l'option '''"allow"''' dont la valeur doit reprendre l'OS et la version séparé par un tiret. On peut spécifier plusieurs valeurs séparées par une virgule. Cette valeur doit être exactement celle utilisée par Wazuh Manager. Il faut donc interroger sa base de données soit via son API soit directement sa base de données.  
C'est le but de l'option '''"allow"''' dont la valeur doit reprendre l'OS et la version séparé par un tiret. On peut spécifier plusieurs valeurs séparées par une virgule. Cette valeur doit être exactement celle utilisée par Wazuh Manager. Il faut donc interroger sa base de données soit via son API soit directement sa base de données. Cette recherche doit être faite sur la machine manager.
 


Par défaut Wazuh utilise SQLite. Il faut donc l'installer cet outil pour pouvoir interroger cette base de données:
Par défaut Wazuh utilise SQLite. Il faut donc l'installer cet outil pour pouvoir interroger cette base de données:
  dnf install sqlite
  dnf install sqlite


Nous allons interroger la base de données SQLite avec la commande suivante:
Nous allons interroger la base de données SQLite avec la commande suivante:
Ligne 70 : Ligne 70 :




On peut aussi utiliser l'API de Wazuh.
Voici un script:
----
#!/bin/bash
TOKEN=$(curl -u wazuh:wazuh -k -X GET <nowiki>"https://localhost:55000/security/user/authenticate?raw=true"</nowiki>)
curl -k -X GET "https://localhost:55000/agents?pretty=true&agents_list=000&select=os.name,os.major" -H  "Authorization: Bearer $TOKEN"
curl -k -X GET "https://localhost:55000/agents?pretty=true&agents_list=001&select=os.name,os.major" -H  "Authorization: Bearer $TOKEN"
----
Pour rappel, la seconde ligne sert à s'authentifier à l'API via le paramètre "-u" en donnant le couple nom d'utilisateur suivi du mot de passe séparés par un double point. A l'installation cet utilisateur est "wazuh" et son mot de passe est "wazuh"; il est crucial et évident de changer ce mot de passe pour une question de sécurité basique. Nous verrons dans un autre article comment changer ces mots de passe et comment adapter la configuration en conséquence.
Grâce à cette requête, on récupère un jeton pour cette session dans la variable "TOKEN"; ce jeton est utilisé pour les requêtes qui suivent.
La troisième ligne récupère l'OS ("select=os.name") et la version ("select=os.major") de l'agent local ("agents_list=000"). La quatrième pour l'agent distant n°1 ("agents_list=001").


Voici les résultats:
----
{
  "data": {
      "affected_items": [
        {
            "os": {
              '''"major": "37",'''
              '''"name": "Fedora Linux"'''
            },
            '''"id": "000"'''
        }
      ],
      "total_affected_items": 1,
      "total_failed_items": 0,
      "failed_items": []
  },
  "message": "All selected agents information was returned",
  "error": 0
}
&nbsp;
{
  "data": {
      "affected_items": [
        {
            "os": {
              '''"major": "36",'''
              '''"name": "Fedora Linux"'''
            },
            '''"id": "001"'''
        }
      ],
      "total_affected_items": 1,
      "total_failed_items": 0,
      "failed_items": []
  },
  "message": "All selected agents information was returned",
  "error": 0
}
----




Ligne 86 : Ligne 139 :
  2022/11/24 12:34:25 wazuh-modulesd:vulnerability-detector: INFO: (5400): Starting 'National Vulnerability Database' database update.
  2022/11/24 12:34:25 wazuh-modulesd:vulnerability-detector: INFO: (5400): Starting 'National Vulnerability Database' database update.
  2022/11/24 12:34:29 wazuh-modulesd:vulnerability-detector: INFO: (5430): The update of the 'National Vulnerability Database' feed finished successfully.
  2022/11/24 12:34:29 wazuh-modulesd:vulnerability-detector: INFO: (5430): The update of the 'National Vulnerability Database' feed finished successfully.
&nbsp;
  2022/11/24 12:34:29 wazuh-modulesd:vulnerability-detector: INFO: (5431): Starting vulnerability scan.
  2022/11/24 12:34:29 wazuh-modulesd:vulnerability-detector: INFO: (5431): Starting vulnerability scan.
&nbsp;
  2022/11/24 12:34:34 wazuh-modulesd:vulnerability-detector: INFO: (5450): Analyzing agent '000' vulnerabilities.
  2022/11/24 12:34:34 wazuh-modulesd:vulnerability-detector: INFO: (5450): Analyzing agent '000' vulnerabilities.
  2022/11/24 12:34:34 wazuh-modulesd:vulnerability-detector: INFO: (5471): Finished vulnerability assessment for agent '000'
  2022/11/24 12:34:34 wazuh-modulesd:vulnerability-detector: INFO: (5471): Finished vulnerability assessment for agent '000'

Version du 24 novembre 2022 à 13:24

→ retour au menu pour les actions préventives

But

Sur la machine manager, les informations récoltées récoltées et reçues par le module SYSCOLLECTOR, sont analysées afin d'y repérer des risques d'attaques.


Configuration

Sur la machine où le service "wazuh-manager" s'exécute, cette configuration est placée dans le fichier "/var/ossec/etc/ossec.conf".


La configuration est comprise entre les balises <vulnerability-detector> et </vulnerability-detector>.

Voici une configuration: 

 <vulnerability-detector>
   <enabled>yes</enabled>
   <interval>12h</interval>
   <run_on_start>no</run_on_start>
 
   <provider name="redhat">
     <enabled>yes</enabled>
     <os allow="Fedora Linux-36,Fedora Linux-37">9</os>
     <update_interval>6h</update_interval>
   </provider>
 
   <provider name="nvd">
     <enabled>yes</enabled>
     <update_from_year>2010</update_from_year>
     <update_interval>6h</update_interval>
   </provider>
 </vulnerability-detector>

Explication des options:

  • enabled: active le module
  • scan_on_start: lance le traitement dès le lancement du service
  • interval: définit l'intervalle entre le lancement de deux traitements; ici 12h


L'analyse doit se baser sur un ensemble de règles de contrôle que Wazuh doit récupérer régulièrement. C'est l'utilité des blocs limités par les balises "<provider name="XXX">" et "</provider>".

Dans la configuration fournie en exemple lors de l'installation, on trouve divers cas de figure pour divers systèmes opératoires (OS).

Nous utilisons la distribution de Linux Fedora (versions 36 et 37) appartenant à l'ensemble des distributions sous l'égide de RedHat. Pour cette raison, nous avons retenu et activé le bloc commençant par "<provider name="redhat">" via l'option "<enabled>".

Sur base de cette distribution, il faut spécifier une version. Nous choisissons la plus élevée actuellement car la distribution Fedora est toujours en avance. C'est à dire "<os>9</os>".

Ces règles ne s'appliqueront qu'à cette distribution Red Hat Entreprise de version 9. Or nous utilisons la distribution Fedora de versions 36 et 37. Il faut donc étendre l'utilisation de ces règles à nos deux OS.

C'est le but de l'option "allow" dont la valeur doit reprendre l'OS et la version séparé par un tiret. On peut spécifier plusieurs valeurs séparées par une virgule. Cette valeur doit être exactement celle utilisée par Wazuh Manager. Il faut donc interroger sa base de données soit via son API soit directement sa base de données. Cette recherche doit être faite sur la machine manager.


Par défaut Wazuh utilise SQLite. Il faut donc l'installer cet outil pour pouvoir interroger cette base de données: 

dnf install sqlite

Nous allons interroger la base de données SQLite avec la commande suivante: 

sqlite3 /var/ossec/queue/db/global.db "SELECT ID, OS_NAME, OS_MAJOR FROM AGENT ;"

qui donne: 

0|Fedora Linux|37
1|Fedora Linux|36

En première position, nous trouvons l'id de l'agent; l'id "0" correspond à l'agent local. Ensuite vient la distribution et enfin la version. Nous avons deux versions différentes; il nous faut donc deux valeurs à notre variable "allow". Ce qui donne: 

<os allow="Fedora Linux-36,Fedora Linux-37">9</os>


On peut aussi utiliser l'API de Wazuh.

Voici un script: 

#!/bin/bash
TOKEN=$(curl -u wazuh:wazuh -k -X GET "https://localhost:55000/security/user/authenticate?raw=true")
curl -k -X GET "https://localhost:55000/agents?pretty=true&agents_list=000&select=os.name,os.major" -H  "Authorization: Bearer $TOKEN"
curl -k -X GET "https://localhost:55000/agents?pretty=true&agents_list=001&select=os.name,os.major" -H  "Authorization: Bearer $TOKEN"

Pour rappel, la seconde ligne sert à s'authentifier à l'API via le paramètre "-u" en donnant le couple nom d'utilisateur suivi du mot de passe séparés par un double point. A l'installation cet utilisateur est "wazuh" et son mot de passe est "wazuh"; il est crucial et évident de changer ce mot de passe pour une question de sécurité basique. Nous verrons dans un autre article comment changer ces mots de passe et comment adapter la configuration en conséquence. Grâce à cette requête, on récupère un jeton pour cette session dans la variable "TOKEN"; ce jeton est utilisé pour les requêtes qui suivent.

La troisième ligne récupère l'OS ("select=os.name") et la version ("select=os.major") de l'agent local ("agents_list=000"). La quatrième pour l'agent distant n°1 ("agents_list=001").

Voici les résultats: 

{
  "data": {
     "affected_items": [
        {
           "os": {
              "major": "37",
              "name": "Fedora Linux"
           },
           "id": "000"
        }
     ],
     "total_affected_items": 1,
     "total_failed_items": 0,
     "failed_items": []
  },
  "message": "All selected agents information was returned",
  "error": 0
}
  
{
  "data": {
     "affected_items": [
        {
           "os": {
              "major": "36",
              "name": "Fedora Linux"
           },
           "id": "001"
        }
     ],
     "total_affected_items": 1,
     "total_failed_items": 0,
     "failed_items": []
  },
  "message": "All selected agents information was returned",
  "error": 0
}






2022/11/24 12:23:08 wazuh-modulesd:vulnerability-detector: INFO: (5400): Starting 'JSON Red Hat Enterprise Linux' database update.
2022/11/24 12:23:21 wazuh-modulesd:vulnerability-detector: INFO: (5430): The update of the 'JSON Red Hat Enterprise Linux' feed finished successfully.
2022/11/24 12:34:24 wazuh-modulesd:vulnerability-detector: INFO: (5400): Starting 'Red Hat Enterprise Linux 9' database update.
2022/11/24 12:34:25 wazuh-modulesd:vulnerability-detector: INFO: (5430): The update of the 'Red Hat Enterprise Linux 9' feed finished successfully.
2022/11/24 12:34:25 wazuh-modulesd:vulnerability-detector: INFO: (5400): Starting 'National Vulnerability Database' database update.
2022/11/24 12:34:29 wazuh-modulesd:vulnerability-detector: INFO: (5430): The update of the 'National Vulnerability Database' feed finished successfully.
 
2022/11/24 12:34:29 wazuh-modulesd:vulnerability-detector: INFO: (5431): Starting vulnerability scan.
2022/11/24 12:34:34 wazuh-modulesd:vulnerability-detector: INFO: (5450): Analyzing agent '000' vulnerabilities.
2022/11/24 12:34:34 wazuh-modulesd:vulnerability-detector: INFO: (5471): Finished vulnerability assessment for agent '000'
2022/11/24 12:34:36 wazuh-modulesd:vulnerability-detector: INFO: (5450): Analyzing agent '001' vulnerabilities.
2022/11/24 12:34:36 wazuh-modulesd:vulnerability-detector: INFO: (5471): Finished vulnerability assessment for agent '001'
2022/11/24 12:34:36 wazuh-modulesd:vulnerability-detector: INFO: (5472): Vulnerability scan finished.


→ retour au menu pour les actions préventives

Récupérée de « https://www.adbweb.gslb.eu/wiki/index.php?title=LINUX:Wazuh-VULNERABILITY-DETECTEUR&oldid=2800 »