WIKI sur Linux (ADB)

LINUX:Wazuh-Décodeurs et Règles

Révision datée du 2 mars 2022 à 18:27 par Adebast (discussion | contributions)

→ retour à Wazuh: HIDS

But

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 logiciel vient avec un grand ensemble de décodeurs et de règles. Mais il se peut que vous soyez confronté à un problème ou que vous souhaitiez refouler des attaques intempestives malgré qu'elles ne soient pas problématiques. Nous allons donner quelques exemples pratiques qui permettent de mieux comprendre le fonctionnement de cet écosystème.


Emplacement

Les décodeurs et les règles sont réparties en deux ensembles, celles qui viennent avec le logiciel et celles que vous créez.

Voici les répertoires où elles se situent:

  • "/var/ossec/ruleset/decoders" : les décodeurs du logiciel
  • "/var/ossec/ruleset/rules"  : les règles du logiciel
  • "/var/ossec/etc/decoders"  : les décodeurs personnels
  • "/var/ossec/etc/rules"  : les règles personnelles

Il est important de ne jamais modifier les fichiers venant avec le logiciel car vous risquez de perdre vos modifications lors d'une mise à jour. On utilise l'espace personnel.


Utilitaires

Il existe un utilitaire qui permet de tester interactivement les réactions des décodeurs et des règles. Normalement toute modification de décodeur ou de règle ne nécessite pas de redémarrage du service "wazuh-manager.service" mais j'ai remarqué que tout suppression ou renommage d'un de ces fichiers mettait en erreur cet utilitaire. Par contre, les modifications ne le perturbent pas, pour autant qu'il soit relancé.

Cet utilitaire est: 

/var/ossec/bin/wazuh-logtest

L'option "-h" présente l'aide. Le lancement sans option suffit.

L'ancien utilitaire obsolète était plus utile car il donnait le cheminement des règles successives utilisées, ce qui aide grandement l'élaboration d'une règle. Il est encore disponible sous le nom: 

/var/ossec/bin/wazuh-logtest-legacy -v

L'option "-v" apporte ce cheminement. Il faudrait cette même approche pour les décodeurs.


1er cas

J'ai un serveur Web. On remarque rapidement que certains essaient d'accéder à des URLs qui donneraient accès à données fondamentales. Par exemple au produit PHPMyAdmni qui donne accès à des bases de données MySql. Nous allons créer une règle qui permet de les identifier et de les bloquer par le firewall.


Requête type du journal d'HTTP

Dans notre journal "/var/log/access_log", nous sélectionnons quelques exemples qui nous permettrons de tester notre règle.

En voici quatre: 

139.5.145.26 - - [24/Feb/2022:05:16:39 +0100] "GET /phpmyadmin2019/index.php?lang=en HTTP/1.1" 301 267 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.82 Safari/537.36"
 
205.185.125.167 - - [20/Feb/2022:19:19:29 +0100] "GET /phpmyadmin/scripts/setup.php HTTP/1.1" 301 263 "-" "ZmEu"
 
147.139.195.52 - - [09/Jan/2022:20:05:09 +0100] "GET /phpMyAdmin-5.1.0-english/index.php?lang=en HTTP/1.1" 301 277 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.82 Safari/537.36"
 
137.184.120.250 - - [28/Jan/2022:22:01:53 +0100] "GET /phpmyadmin/index.php HTTP/1.1" 404 196 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.121 Safari/537.36"

Nous remarquons la diversité des requêtes. De plus nous remarquons la diversité des n° de message d'erreur d'Apache. Dans trois cas, le code "301" signifie une redirection, ce qui est normal car le serveur redirige d'office les requêtes de type "http://" vers "https://"; tous sites devraient utiliser une connexion sécurisée par certificat. Le code "301" n'est donc pas une erreur à la base car il peut conduire par la suite à un code "200" pour une URL correcte, existante. La dernière correspond donc à une requête sécurisée mais inexistante.


Nous commençons par lancer la commande de test avant tout ajout de règle pour observer la réaction de Wazuh. Quand on a lancé la commande, on colle la ligne du journal que nous voulons tester. Nous allons utiliser la première requête pour nos tests.


On lance la commande avant l'ajout de la règle: 

/var/ossec/bin/wazuh-logtest

Résultat: 

Starting wazuh-logtest v4.2.5
Type one log per line
 
139.5.145.26 - - [24/Feb/2022:05:16:39 +0100] "GET /phpmyadmin2019/index.php?lang=en HTTP/1.1" 301 267 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.82 Safari/537.36"
 
**Phase 1: Completed pre-decoding.
       full event: '139.5.145.26 - - [24/Feb/2022:05:16:39 +0100] "GET /phpmyadmin2019/index.php?lang=en HTTP/1.1" 301 267 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.82 Safari/537.36"'
**Phase 2: Completed decoding.
       name: 'web-accesslog'
       id: '301'
       protocol: 'GET'
       srcip: '139.5.145.26'
       url: '/phpmyadmin2019/index.php?lang=en'
**Phase 3: Completed filtering (rules).
       id: '31100'
       level: '0'
       description: 'Access log messages grouped.'
       groups: '['web', 'accesslog']'
       firedtimes: '1'
       mail: 'False'

La phase de décodage a permis d'identifier le n° de message d'erreur d'Apache ("id"), l'adresse IP de la source de la requête ("srcip") et la requête proprement dite ("url").

La phase suivante affiche le résultat de la règle finale qui a été appliquée. Chaque règle a un n° unique; celle utilisée est la "31100" et le niveau d'alarme est "0" donc il n'y a pas d'alarme or nous désirons qu'il soit au moins de "7".



Après l'ajout de la règle, on lance la commande: 

/var/ossec/bin/wazuh-logtest

Résultat: 

Starting wazuh-logtest v4.2.5
Type one log per line
 
139.5.145.26 - - [24/Feb/2022:05:16:39 +0100] "GET /phpmyadmin2019/index.php?lang=en HTTP/1.1" 301 267 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.82 Safari/537.36"
 
**Phase 1: Completed pre-decoding.
       full event: '139.5.145.26 - - [24/Feb/2022:05:16:39 +0100] "GET /phpmyadmin2019/index.php?lang=en HTTP/1.1" 301 267 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.82 Safari/537.36"'
**Phase 2: Completed decoding.
       name: 'web-accesslog'
       id: '301'
       protocol: 'GET'
       srcip: '139.5.145.26'
       url: '/phpmyadmin2019/index.php?lang=en'
**Phase 3: Completed filtering (rules).
       id: '100105'
       level: '7'
       description: 'Web attaque 1 (ADB).'
       groups: '['web', 'accesslog']'
       firedtimes: '1'
       mail: 'True'
**Alert to be generated.


Pour comparaison, on lance l'ancienne commande: 

/var/ossec/bin/wazuh-logtest-legacy -v

Résultat: 

2022/03/02 16:40:01 wazuh-testrule: INFO: Started (pid: 2712892).
Since Wazuh v4.1.0 this binary is deprecated. Use wazuh-logtest instead
wazuh-testrule: Type one log per line.
 
139.5.145.26 - - [24/Feb/2022:05:16:39 +0100] "GET /phpmyadmin2019/index.php?lang=en HTTP/1.1" 301 267 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.82 Safari/537.36"
 
**Phase 1: Completed pre-decoding.
      full event: '139.5.145.26 - - [24/Feb/2022:05:16:39 +0100] "GET /phpmyadmin2019/index.php?lang=en HTTP/1.1" 301 267 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.82 Safari/537.36"'
      timestamp: '(null)'
      hostname: 'serverdb'
      program_name: '(null)'
      log: '139.5.145.26 - - [24/Feb/2022:05:16:39 +0100] "GET /phpmyadmin2019/index.php?lang=en HTTP/1.1" 301 267 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.82 Safari/537.36"'
**Phase 2: Completed decoding.
      decoder: 'web-accesslog'
      srcip: '139.5.145.26'
      protocol: 'GET'
      url: '/phpmyadmin2019/index.php?lang=en'
      id: '301'
**Rule debugging:
   Trying rule: 4 - Generic template for all web rules.
      *Rule 4 matched.
      *Trying child rules.
   Trying rule: 31100 - Access log messages grouped.
      *Rule 31100 matched.
      *Trying child rules.
   Trying rule: 31108 - Ignored URLs (simple queries).
   Trying rule: 31511 - Blacklisted user agent (wget).
   Trying rule: 100161 - Web WP-LOGIN (ADB).
   Trying rule: 100150 - Web fichier (ADB).
   Trying rule: 31115 - URL too long. Higher than allowed on most browsers. Possible attack.
   Trying rule: 31103 - SQL injection attempt.
   Trying rule: 100105 - Web attaque 1 (ADB).
      *Rule 100105 matched.
**Phase 3: Completed filtering (rules).
      Rule id: '100105'
      Level: '7'
      Description: 'Web attaque 1 (ADB).'
**Alert to be generated.





→ retour à Wazuh: HIDS

Récupérée de « https://www.adbweb.gslb.eu/wiki/index.php?title=LINUX:Wazuh-Décodeurs_et_Règles&oldid=2214 »