« LINUX:Wazuh-VULNERABILITY-DETECTEUR » : différence entre les versions
Aucun résumé des modifications |
Aucun résumé des modifications |
||
(8 versions intermédiaires par le même utilisateur non affichées) | |||
Ligne 1 : | Ligne 1 : | ||
__FORCETOC__ | |||
---- | ---- | ||
''→ [[LINUX:Wazuh-Actions préventives|retour au menu pour les actions préventives]]'' | ''→ [[LINUX:Wazuh-Actions préventives|retour au menu pour les actions préventives]]'' | ||
Ligne 10 : | Ligne 11 : | ||
La configuration est comprise entre les balises '''<vulnerability- | La configuration est comprise entre les balises '''<vulnerability-detecteur>''' et '''</vulnerability-detecteur>'''. | ||
Voici une configuration: | Voici une configuration: | ||
---- | ---- | ||
<vulnerability- | <vulnerability-detection> | ||
<enabled>yes</enabled> | <enabled>yes</enabled> | ||
< | <index-status>yes</index-status> | ||
<feed-update-interval>60m</feed-update-interval> | |||
</vulnerability-detection> | |||
< | |||
</vulnerability- | |||
---- | ---- | ||
La troisième ligne ("index-status") pointe vers la configuration qui suit. | |||
Cette section s'ajoute en relation avec Wazuh-Indexer et FileBeat: | |||
---- | |||
<indexer> | |||
<enabled>yes</enabled> | |||
<hosts> | |||
<nowiki><host>https://</nowiki>'''127.0.0.1:9200'''<nowiki></host></nowiki> | |||
</hosts> | |||
<ssl> | |||
<certificate_authorities> | |||
<ca>/etc/filebeat/certs/root-ca.pem</ca> | |||
</certificate_authorities> | |||
<certificate>/etc/filebeat/certs/filebeat.pem</certificate> | |||
<key>/etc/filebeat/certs/filebeat-key.pem</key> | |||
</ssl> | |||
</indexer> | |||
---- | |||
On y a modifié la référence d'accès au service Wazuh-Indexer vers l'adresse IP "127.0.0.1" comme on le verra dans l'article sur l'[[LINUX:Wazuh-WUI|Interface Utilisateur Web (WUI)]]. | |||
=OS supportés= | |||
Cette fonctionnalité n'est malheureusement pas supportée pour tout OS. On peut consulter cette liste d'OS supportés à l'URL: https://documentation.wazuh.com/current/user-manual/capabilities/vulnerability-detection/how-it-works.html | |||
Malheureusement pour moi, Fedora n'y est pas repris. | |||
Si vous désirez avoir une liste de OS de vos machines où s'exécute Wazuh, il existe deux moyens à exécuter sur la machine Wazuh-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: | ||
Ligne 60 : | Ligne 56 : | ||
qui donne: | qui donne: | ||
---- | ---- | ||
0|Fedora Linux| | 0|Fedora Linux|40 | ||
1|Fedora Linux| | 1|Fedora Linux|39 | ||
---- | ---- | ||
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. | 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. | ||
On peut aussi utiliser l'API de Wazuh. | On peut aussi utiliser l'[[LINUX:Wazuh-API|API]] de Wazuh. | ||
Voici un script: | Voici un script: | ||
---- | ---- | ||
#!/bin/bash | #!/bin/bash | ||
TOKEN=$(curl -u wazuh:wazuh -k -X GET <nowiki>"https://localhost:55000/security/user/authenticate?raw=true"</nowiki>) | TOKEN=$(curl --silent -u wazuh:wazuh -k -X GET <nowiki>"https://localhost:55000/security/user/authenticate?raw=true"</nowiki>) | ||
curl -k -X GET <nowiki>"https://localhost:55000/agents?pretty=true&agents_list=000&select=os.name,os.major"</nowiki> -H "Authorization: Bearer $TOKEN" | curl --silent -k -X GET <nowiki>"https://localhost:55000/agents?pretty=true&agents_list=000&select=os.name,os.major"</nowiki> -H "Authorization: Bearer $TOKEN" | ||
curl -k -X GET <nowiki>"https://localhost:55000/agents?pretty=true&agents_list=001&select=os.name,os.major"</nowiki> -H "Authorization: Bearer $TOKEN" | curl --silent -k -X GET <nowiki>"https://localhost:55000/agents?pretty=true&agents_list=001&select=os.name,os.major"</nowiki> -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. | 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. | ||
Ligne 91 : | Ligne 83 : | ||
{ | { | ||
"os": { | "os": { | ||
'''"major": " | '''"major": "40",''' | ||
'''"name": "Fedora Linux"''' | '''"name": "Fedora Linux"''' | ||
}, | }, | ||
Ligne 110 : | Ligne 102 : | ||
{ | { | ||
"os": { | "os": { | ||
'''"major": " | '''"major": "39",''' | ||
'''"name": "Fedora Linux"''' | '''"name": "Fedora Linux"''' | ||
}, | }, | ||
Ligne 126 : | Ligne 118 : | ||
=Vérification= | |||
Suivez l'exécution du module "VULNERABILITY-DETECTEUR" dans le fichier journal "/var/ossec/logs/ossec.log" (machine manager seule). Repérez toute erreur et y remédier. | |||
En filtrant ce journal: | |||
grep vulnerability-scanner: /var/ossec/logs/ossec.log | |||
on devrait obtenir ce type de messages. | |||
---- | |||
2024/06/13 19:31:15 wazuh-modulesd:vulnerability-scanner: INFO: Starting vulnerability_scanner module. | |||
2024/06/13 19:31:16 wazuh-modulesd:vulnerability-scanner: INFO: Vulnerability scanner module started | |||
---- | |||
=Résultats= | |||
Ensuite si vous avez activé la réception de mails, vous devrez recevoir un rapport succinct par analyse au format JSON. | |||
Ces rapports sont aussi centralisés sur la machine manager dans les journaux d'alertes. Le fichier courant est "/var/ossec/logs/alerts/alerts.json". Ceci pour autant que les niveaux d'alerte soient supérieurs ou égaux à ceux définis dans le fichier de configuration entre les balises <alerts> et </alerts> comme vu précédemment. | |||
Si vous avez installé le module WUI de Wazuh que nous verrons dans un autre article, vous pouvez y voir le détail. Il faut choisir un agent. Dans le menu en haut à gauche, on clique sur "WAZUH" et en dessous sur "Agents". On clique ensuite sur l'agent désiré dans la liste qui apparaît. Enfin dans l'écran qui s'ouvre, on clique sur "Vulnerabilities" dans le menu du haut pour avoir une vue d'ensemble des résultats. | |||
<!-- | |||
Malheureusement cet interface WEB ne reprend que les agents distants et non l'agent local de la machine manager. | |||
Il est possible d'avoir ces détails pour l'agent local de la machine manager en effectuant une requête à l'[[LINUX:Wazuh-API|API]] de WAZUH sur la machine manager; on obtient une sortie au format JSON. Nous verrons l'utilisation de l'API dans un autre article. | |||
Voici un script qui récupère au format JSON le résultat de l'analyse. Ce script est brut. La sélection demande à être affinée par exemple sur les dates. | |||
---- | ---- | ||
#!/bin/bash | |||
TOKEN=$(curl --silent -u wazuh:wazuh -k -X GET <nowiki>"https://localhost:55000/security/user/authenticate?raw=true"</nowiki>) | |||
curl --silent -k -X GET <nowiki>"https://localhost:55000/vulnerability/000/last_scan"</nowiki> -H "Authorization: Bearer $TOKEN" | python -m json.tool | |||
curl --silent -k -x GET <nowiki>"https://localhost:55000/vulnerability/000/summary/name"</nowiki> -H "Authorization: Bearer $TOKEN" | python -m json.tool | |||
curl --silent -k -X GET <nowiki>"https://localhost:55000/vulnerability/000/summary/severity"</nowiki> -H "Authorization: Bearer $TOKEN" | python -m json.tool | |||
curl --silent -k -X GET <nowiki>"https://localhost:55000/vulnerability/000?select=cve,architecture,version,name,severity,cvss2_score,cvss3_score,detection_time,title,condition,updated,published,external_references&offset=0"</nowiki> -H "Authorization: Bearer $TOKEN" | python -m json.tool | |||
---- | ---- | ||
Le résultat peut être conséquent; on peut le rediriger vers un fichier. | |||
--> | |||
Dernière version du 14 juin 2024 à 11:25
→ 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-detecteur> et </vulnerability-detecteur>.
Voici une configuration:
<vulnerability-detection> <enabled>yes</enabled> <index-status>yes</index-status> <feed-update-interval>60m</feed-update-interval> </vulnerability-detection>
La troisième ligne ("index-status") pointe vers la configuration qui suit. Cette section s'ajoute en relation avec Wazuh-Indexer et FileBeat:
<indexer> <enabled>yes</enabled> <hosts> <host>https://127.0.0.1:9200</host> </hosts> <ssl> <certificate_authorities> <ca>/etc/filebeat/certs/root-ca.pem</ca> </certificate_authorities> <certificate>/etc/filebeat/certs/filebeat.pem</certificate> <key>/etc/filebeat/certs/filebeat-key.pem</key> </ssl> </indexer>
On y a modifié la référence d'accès au service Wazuh-Indexer vers l'adresse IP "127.0.0.1" comme on le verra dans l'article sur l'Interface Utilisateur Web (WUI).
OS supportés
Cette fonctionnalité n'est malheureusement pas supportée pour tout OS. On peut consulter cette liste d'OS supportés à l'URL: https://documentation.wazuh.com/current/user-manual/capabilities/vulnerability-detection/how-it-works.html
Malheureusement pour moi, Fedora n'y est pas repris.
Si vous désirez avoir une liste de OS de vos machines où s'exécute Wazuh, il existe deux moyens à exécuter sur la machine Wazuh-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|40 1|Fedora Linux|39
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.
On peut aussi utiliser l'API de Wazuh.
Voici un script:
#!/bin/bash TOKEN=$(curl --silent -u wazuh:wazuh -k -X GET "https://localhost:55000/security/user/authenticate?raw=true") curl --silent -k -X GET "https://localhost:55000/agents?pretty=true&agents_list=000&select=os.name,os.major" -H "Authorization: Bearer $TOKEN" curl --silent -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": "40", "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": "39", "name": "Fedora Linux" }, "id": "001" } ], "total_affected_items": 1, "total_failed_items": 0, "failed_items": [] }, "message": "All selected agents information was returned", "error": 0 }
Vérification
Suivez l'exécution du module "VULNERABILITY-DETECTEUR" dans le fichier journal "/var/ossec/logs/ossec.log" (machine manager seule). Repérez toute erreur et y remédier.
En filtrant ce journal:
grep vulnerability-scanner: /var/ossec/logs/ossec.log
on devrait obtenir ce type de messages.
2024/06/13 19:31:15 wazuh-modulesd:vulnerability-scanner: INFO: Starting vulnerability_scanner module. 2024/06/13 19:31:16 wazuh-modulesd:vulnerability-scanner: INFO: Vulnerability scanner module started
Résultats
Ensuite si vous avez activé la réception de mails, vous devrez recevoir un rapport succinct par analyse au format JSON. Ces rapports sont aussi centralisés sur la machine manager dans les journaux d'alertes. Le fichier courant est "/var/ossec/logs/alerts/alerts.json". Ceci pour autant que les niveaux d'alerte soient supérieurs ou égaux à ceux définis dans le fichier de configuration entre les balises <alerts> et </alerts> comme vu précédemment.
Si vous avez installé le module WUI de Wazuh que nous verrons dans un autre article, vous pouvez y voir le détail. Il faut choisir un agent. Dans le menu en haut à gauche, on clique sur "WAZUH" et en dessous sur "Agents". On clique ensuite sur l'agent désiré dans la liste qui apparaît. Enfin dans l'écran qui s'ouvre, on clique sur "Vulnerabilities" dans le menu du haut pour avoir une vue d'ensemble des résultats.
→ retour au menu pour les actions préventives