WIKI sur Linux (ADB)

« LINUX:Wazuh-Décodeurs et Règles » : différence entre les versions

← Modification précédente
Aucun résumé des modifications
m Adebast a déplacé la page LINUX:Wazuh: Décodeurs et Règles vers LINUX:Wazuh-Décodeurs et Règles sans laisser de redirection
 
(15 versions intermédiaires par le même utilisateur non affichées)
Ligne 415 : Ligne 415 :


==Règle personnelle==
==Règle personnelle==
Sur cet base, on conçoit une règle où on recherche un poucentage de deux digits commençant par "9". Cette recherche est exprimée par la chaîne "9\d%".
Sur cette base, on conçoit une règle où on recherche un poucentage de deux digits commençant par "9". Cette recherche est exprimée par la chaîne "9\d%".


Dans le répertoire "/var/ossec/etc/rules" reprenant les règles personnelles, nous créons le fichier "perso-os_rules.xml" dans laquelle on ajoute la règle suivante:  
Dans le répertoire "/var/ossec/etc/rules" reprenant les règles personnelles, nous créons le fichier "perso-os_rules.xml" dans laquelle on ajoute la règle suivante:  
Ligne 461 : Ligne 461 :




=4<sup>ème</sup> cas=
Sur une machine, j'ai installé le logiciel Nagios, programme de surveillance du matériel et des services à travers le réseau. Sur cette machine existe un serveur de messagerie comprenant les protocoles POP3, POP3S, IMAP et IMPAPS au travers du logiciel DOVECOT. Ces services ont logiquement été mis sous surveillance à intervals réguliers. Dès ce moment, quatre alarmes de niveau 5 intempestives sont apparues et répétées régulièrement. Nous avons voulu remettre ces alarmes à un niveau 0 pour cet émetteur et ce récepteur bien précis, identifiés par leurs adresses IP. Deux approches sont présentées.
==Requête type du journal de la messagerie==
Voici quatre exemples d'entrées dans le journal "/var/log/mail":
----
Mar  1 20:13:14 serverdb dovecot[1034]: pop3-login: Disconnected: Aborted login by logging out (no auth attempts in 0 secs): user=<>, rip=192.168.1.110, lip=192.168.1.110, secured, session=<rKDy9CzZIsTAqAE8>
&nbsp;
Mar  1 20:12:01 serverdb dovecot[1034]: imap-login: Disconnected: Aborted login by logging out (no auth attempts in 0 secs): user=<>, rip=192.168.1.110, lip=192.168.1.110, secured, session=<PwmX8CzZUqHAqAE8>
&nbsp;
Mar  1 20:05:39 serverdb dovecot[1034]: pop3-login: Disconnected: Aborted login by logging out (no auth attempts in 0 secs): user=<>, rip=192.168.1.110, lip=192.168.1.110, TLS, session=<ZY3O2SzZ3tLAqAE8>
&nbsp;
Feb 21 21:24:28 serverdb dovecot[1034]: imap-login: Disconnected: Aborted login by logging out (no auth attempts in 0 secs): user=<>, rip=192.168.1.110, lip=192.168.1.110, TLS, session=<J3/qBI3Y9NzAqAE8>
----
==Evaluation==
Comme pour les cas précédents, nous allons utiliser la commande qui émet une alarme de niveau 5. Nous avons pris comme exemple la première ligne de l'extrait du journal:
/var/ossec/bin/wazuh-logtest
Résultat:
----
Starting wazuh-logtest v4.2.5
Type one log per line
&nbsp;
Mar  1 20:13:14 serverdb dovecot[1034]: pop3-login: Disconnected: Aborted login by logging out (no auth attempts in 0 secs): user=<>, rip=192.168.1.110, lip=192.168.1.110, secured, session=<rKDy9CzZIsTAqAE8>
&nbsp;
**Phase 1: Completed pre-decoding.
        full event: 'Mar  1 20:13:14 serverdb dovecot[1034]: pop3-login: Disconnected: Aborted login by logging out (no auth attempts in 0 secs): user=<>, rip=192.168.1.110, lip=192.168.1.110, secured, session=<rKDy9CzZIsTAqAE8>'
        timestamp: 'Mar  1 20:13:14'
        hostname: 'serverdb'
        program_name: 'dovecot'
**Phase 2: Completed decoding.
        name: 'dovecot'
        parent: 'dovecot'
**Phase 3: Completed filtering (rules).
        id: '9707'
        level: '5'
        description: 'Dovecot Aborted Login.'
        groups: '['dovecot', 'invalid_login']'
        firedtimes: '1'
        gdpr: '['IV_35.7.d', 'IV_32.2']'
        gpg13: '['7.1']'
        hipaa: '['164.312.b']'
        mail: 'True'
        nist_800_53: '['AU.14', 'AC.7']'
        pci_dss: '['10.2.4', '10.2.5']'
        tsc: '['CC6.1', 'CC6.8', 'CC7.2', 'CC7.3']'
**Alert to be generated.
----
C'est la règle n° 9707 qui est concernée.
==Règles du logiciel==
Cette règle se retrouve dans le fichier "/var/ossec/ruleset/rules/0155-dovecot_rules.xml".
Voici un extrait:
----
<group name="dovecot,">
  <rule id="9700" level="0">
    <decoded_as>dovecot</decoded_as>
    <description>Dovecot Messages Grouped.</description>
  </rule>
  <rule id="9707" level="5">
    <if_sid>9700</if_sid>
    <match>: Aborted login</match>
    <description>Dovecot Aborted Login.</description>
    <group>invalid_login,pci_dss_10.2.4,pci_dss_10.2.5,gpg13_7.1,gdpr_IV_35.7.d,gdpr_IV_32.2,hipaa_164.312.b, nist_800_53_AU.14,nist_800_53_AC.7,tsc_CC6.1,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3,</group>
  </rule>
</group>
----
==1<sup>ère</sup> approche==
Pour cette première approche, nous avons utilisé la même méthode que dans les cas précédents; c'est à dire l'ajout d'une règle.
===Règle personnelle===
On va donc créer un fichier qui va contenir nos règles personnelles liées à la messagerie. On le nommera "/var/ossec/etc/rules/perso-mail_rules.xml". Le décodage ne nous fourni que peu d'information. Seul le n° de règle activée (9707) nous est fourni. Il ne nous reste que l'exploitation directe du message brut. Il nous faut désactiver cette alarme pour un émetteur et un récepteur bien précis au travers de leurs adresses IP. Cette partie du message qui correspond à ces critères est "rip=192.168.1.110, lip=192.168.1.110" et l'interrogation émise par Nagios qui ne tente pas d'effectuer une authentification ("Disconnected: Aborted login by logging out"), est utilisé.
Voici cette règle:
/var/ossec/etc/rules/perso-mail_rules.xml
----
<group name="dovecot,">
  <rule id="100153" level="0">
    <if_sid>9707</if_sid>
    <match>rip=192.168.1.110, lip=192.168.1.110</match>
    <match>Disconnected: Aborted login by logging out</match>
    <description>Nagios-dovecot (ADB).</description>
  </rule>
</group>
----
===Validation===
On passe à l'étape évaluation. On lance la commande:
/var/ossec/bin/wazuh-logtest
Résultat:
----
Starting wazuh-logtest v4.2.5
Type one log per line
&nbsp;
Mar  1 20:13:14 serverdb dovecot[1034]: pop3-login: Disconnected: Aborted login by logging out (no auth attempts in 0 secs): user=<>, rip=192.168.1.110, lip=192.168.1.110, secured, session=<rKDy9CzZIsTAqAE8>
&nbsp;
**Phase 1: Completed pre-decoding.
        full event: 'Mar  1 20:13:14 serverdb dovecot[1034]: pop3-login: Disconnected: Aborted login by logging out (no auth attempts in 0 secs): user=<>, rip=192.168.1.110, lip=192.168.1.110, secured, session=<rKDy9CzZIsTAqAE8>'
        timestamp: 'Mar  1 20:13:14'
        hostname: 'serverdb'
        program_name: 'dovecot'
**Phase 2: Completed decoding.
        name: 'dovecot'
        parent: 'dovecot'
**Phase 3: Completed filtering (rules).
        id: '100153'
        level: '0'
        description: 'Nagios-dovecot (ADB).'
        groups: '['dovecot']'
        firedtimes: '1'
        mail: 'False'
----
==2<sup>ème</sup> approche==
Dans cette seconde approche, nous allons agir en amont. Les décodeurs ne nous donnent aucune information sur l'émetteur et le récepteur. Nous tacherons de les mettre en évidence.
===Décodeurs du logiciel===
On retrouve les décodeurs utilisés dans le fichier "/var/ossec/ruleset/decoders/0085-dovecot_decoders.xml".
Voici un extrait:
----
<decoder name="dovecot">
  <program_name>^dovecot</program_name>
</decoder>
&nbsp;
<decoder name="dovecot-disconnect-user">
  <parent>dovecot</parent>
  <prematch offset="after_parent">^\w\w\w\w-login: Disconnected\.+user=</prematch>
  <regex offset="after_parent">user=(\S+), method=\S+, rip=(\S+), lip=(\S+),</regex>
  <order>srcuser, srcip, dstip</order>
</decoder>
&nbsp;
<decoder name="dovecot-disconnect">
  <parent>dovecot</parent>
  <prematch offset="after_parent">^\w\w\w\w-login: Disconnected</prematch>
  <regex offset="after_prematch">rip=(\S+), lip=(\S+),|rip=(\S+), lip=(\S+)$</regex>
  <order>srcip, dstip</order>
</decoder>
----
La première entrée précise que les messages du journal sont émis par le programme "dovecot". C'est le prédécodage qui lui fourni cette information ("program_name"); deux autres informations sont aussi identifiées ("timestamp" et "hostname"). Ces champs proviennent du début du message du journal ("Mar  1 20:13:14 serverdb dovecot[1034]:"). Cette partie est acquise et mise de côté. Le reste va être décodé par les décodeurs suivants.
Par héritage, les décodeurs suivants analysent cette seconde partie. Elles concernent la déconnexion ("Disconnected") suite à une demande d'authentification ("-login"). La chaîne "^\w\w\w\w" signifie qu'en début de message ("^"), on prend quatre caratères alphanumériques de base limités à droite par la chaîne "-login:". Ces quatre caractères collent aux mots POP3 et IMAP recherchés.
Sur les trois décodeurs présentés, c'est le second qui s'active.
Pour une explication des codes spéciaux utilisés dans la recherche, voyez l'explication dans la documentation de Wazuh à l'URL <nowiki>https://documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/regex.html</nowiki>
===Présentation de la solution===
Comme les résultats du second décodeur ne nous conviennent pas, il faut en insérer un juste avant.
Mais comme il ne faut jamais modifier un décodeur venant avec le logiciel, il faut le mettre dans le répertoire personnel "/var/ossec/etc/decoders". Mais si ce décodeur est mis seul, il sera traité en dernier lieu et ce sera toujours le décodeur du logiciel qui sera activé. Pour contourner ce problème, on va utiliser une astuce.
* En premier lieu, on recopie le fichier "/var/ossec/ruleset/decoders/0085-dovecot_decoders.xml" dans le répertoire "/var/ossec/etc/decoders". Par soucis de visibilité, on garde son nom. ("/var/ossec/etc/decoders/0085-dovecot_decoders.xml")
* En second lieu, on désactive le décodeur d'origine, par l'ajout d'une option dans le fichier de configuration du serveur de Wazuh. ("/var/ossec/etc/ossec.conf")
* En troisième lieu, on ajoute notre décodeur dans le fichier "/var/ossec/etc/decoders/0085-dovecot_decoders.xml".
* Enfin on redémare le service 'wazuh-manager.service".
===Configuration du service===
On ajoute la ligne mise en gras ci-dessous sous la section "ruleset" dans le fichier de configuration du serveur "/var/ossec/etc/ossec.conf".
----
  <ruleset>
    '''<decoder_exclude>ruleset/decoders/0085-dovecot_decoders.xml</decoder_exclude>'''
  </ruleset>
----
Elle désactive la prise en compte de ce fichier de décodeurs.
===Décodeur personnel===
L'extrait des décodeurs présenté plus haut devient (fichier "/var/ossec/etc/decoders/0085-dovecot_decoders.xml") suite à l'ajout d'un décodeur: 
----
<decoder name="dovecot">
  <program_name>^dovecot</program_name>
</decoder>
&nbsp;
'''<decoder name="dovecot-disconnect-adb">'''
  '''<parent>dovecot</parent>'''
  '''<prematch offset="after_parent">^\w\w\w\w-login: Disconnected: Aborted login by logging out</prematch>'''
  '''<regex offset="after_prematch">user=\p>, rip=(\S+), lip=(\S+),</regex>'''
  '''<order>srcip, dstip</order>'''
'''</decoder>'''
&nbsp;
<decoder name="dovecot-disconnect-user">
  <parent>dovecot</parent>
  <prematch offset="after_parent">^\w\w\w\w-login: Disconnected\.+user=</prematch>
  <regex offset="after_parent">user=(\S+), method=\S+, rip=(\S+), lip=(\S+),</regex>
  <order>srcuser, srcip, dstip</order>
</decoder>
&nbsp;
<decoder name="dovecot-disconnect">
  <parent>dovecot</parent>
  <prematch offset="after_parent">^\w\w\w\w-login: Disconnected</prematch>
  <regex offset="after_prematch">rip=(\S+), lip=(\S+),|rip=(\S+), lip=(\S+)$</regex>
  <order>srcip, dstip</order>
</decoder>
----
L'ajout est mis en gras. La balise "<prematch offset="after_parent">" permet de faire une première sélection et si elle est acceptée, on passe à la seconde identification par la balise "<regex offset="after_prematch">".
Les chaînes "(\S+)" privilégient une suite de caratères ("\S+") qui sera placée dans un champs par le fait de la présence des parenthèses qui les entourent. Il y a deux de ces zones. La correspondance avec le nom des champs est reprise dans l'ordre derrière la balise "<order>".
* la zone derrière la chaîne "rip=" (comme remote IP) correspond au champs "srcip"
* la zone derrière la chaîne "lip=" (comme local IP) correspond au champs "dstip"
Derrière la chaîne "user=", on s'attend à "<>" mais ces deux caratères identifient habituellement une balise; pour éviter cette interprétation, la chaîne "\p" remplace quelques caractères spéciaux tel "<".
===Règle personnelle===
Maintenant le décodeur nous fournira deux champs reprenant les adresses IP des corresponants. Notre règle peut dès lors les utiliser.
Voici cette règle qui remplace celle présentée ci-dessus dans le fichier "/var/ossec/etc/rules/perso-mail_rules.xml". De plus on se base directement sur la première règle qui identifie le programme qui a généré ce message dans le journal:
----
<group name="dovecot,">
  <rule id="100153" level="0">
    <if_sid>9700</if_sid>
    <match>Disconnected: Aborted login by logging out</match>
    <srcip>192.168.1.110</srcip>
    <dstip>192.168.1.110</dstip>
    <description>Nagios-dovecot (ADB).</description>
  </rule>
</group>
----
===Validation===
On passe à l'étape évaluation. On lance la commande:
/var/ossec/bin/wazuh-logtest
Résultat:
----
Starting wazuh-logtest v4.2.5
Type one log per line
&nbsp;
Mar  1 20:13:14 serverdb dovecot[1034]: pop3-login: Disconnected: Aborted login by logging out (no auth attempts in 0 secs): user=<>, rip=192.168.1.110, lip=192.168.1.110, secured, session=<rKDy9CzZIsTAqAE8>
&nbsp;
**Phase 1: Completed pre-decoding.
        full event: 'Mar  1 20:13:14 serverdb dovecot[1034]: pop3-login: Disconnected: Aborted login by logging out (no auth attempts in 0 secs): user=<>, rip=192.168.1.110, lip=192.168.1.110, secured, session=<rKDy9CzZIsTAqAE8>'
        timestamp: 'Mar  1 20:13:14'
        hostname: 'serverdb'
        program_name: 'dovecot'
**Phase 2: Completed decoding.
        name: 'dovecot'
        parent: 'dovecot'
        dstip: '192.168.1.110'
        srcip: '192.168.1.110'
**Phase 3: Completed filtering (rules).
        id: '100153'
        level: '0'
        description: 'Nagios-dovecot (ADB).'
        groups: '['dovecot']'
        firedtimes: '1'
        mail: 'False'
----
On remarque l'apparition des champs "dstip" et "srcip" lors de la phase de décodage. Notre règle s'active bien à un niveau 0.
=5<sup>ème</sup> cas=
J'ai un site Web de type WordPress. Le moyen commun d'accéder à ce type de site pour le modifier est d'effectuer une authentification. Le script "wp-login.php" permet cet accès. Je désire d'abord être averti si quelqu'un veut y accéder alors que personne n'en a besoin. Ensuite je veux bloquer tout autre appel de ce script pour une URL inexistante.
==Requête type du journal d'HTTP==
Dans notre journal "/var/log/access_log", nous sélectionnons quelques exemples qui nous permettrons de tester nos règles.
En voici quatre:
----
157.55.39.130 - - [27/Feb/2022:16:40:09 +0100] "GET /abeille/wp-login.php HTTP/2.0" 200 8413 "-" "Mozilla/5.0 (compatible;bingbot/2.0; +<nowiki>http://www.bing.com/bingbot.htm</nowiki>)"
&nbsp;
64.225.26.22 - - [02/Sep/2021:09:15:17 +0200] "GET /abeille/wp-login.php HTTP/1.1" 301 253 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.159 Safari/537.36"
&nbsp;
14.29.240.225 - - [04/Mar/2022:23:44:49 +0100] "GET /wp-login.php HTTP/1.1" 404 16 "-" "Apache-HttpClient/4.5.2 (Java/1.8.0_161)"
&nbsp;
143.110.247.244 - - [20/Dec/2021:18:23:27 +0100] "GET /outil/wp-login.php HTTP/1.1" 301 243 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0"
----
Les deux premiers sont acceptés mais demandent un avertissement par mail. Les deux suivants nécessitent un blocage.
==Evaluation==
Nous passerons cette étape qui a déjà été abordée au cas n° 1 et qui ne nous apportera aucune information supplémentaire.
==Règles du logiciel==
De même ici, les règles du logiciel rencontrées sont les mêmes que dans le cas n° 1.
==Règles personnelles==
Nous allons donc concevoir des règles sur base de ces informations et des contraintes.
Dans le répertoire "/var/ossec/etc/rules" reprenant les règles personnelles, nous créons le fichier "perso-web_rules.xml" s'il n'existe pas dans laquelle on ajoute les règles suivantes:
----
<group name="web,accesslog,">
  <rule id="100161" level="0">
    <if_sid>31100, 31101, 31108</if_sid>
    <url>/wp-login.php</url>
    <description>Web WP-LOGIN (ADB).</description>
  </rule>
&nbsp;
  <rule id="100162" level="5">
    <if_sid>100161</if_sid>
    <url>^/abeille/wp-login.php</url>
    <description>Web abeille WP-LOGIN (ADB).</description>
  </rule>
&nbsp;
  <rule id="100119" level="7">
    <if_sid>100161</if_sid>
    <url>!^/abeille/wp-login.php</url>
    <description>Web attaque WP-LOGIN (ADB).</description>
  </rule>
</group>
----
Une des règles 31100, 31101 ou 31108 a été activée selon le n° d'erreur d'HTTP. Nous en héritons dans la première règle qui a pour but de repérer dans l'URL l'utilisation du script PHP "/wp-login.php". Son niveau est 0 car cette règle ne sert que de filtrage intermédiaire.
Les deux règles suivantes héritent de cette première règle.
La deuxième règle repère l'appel de ce script existant sur mon site dans le champs "url". Une alerte de niveau 5 est émise afin qu'un mail soit envoyé. Cette limite est définie dans le fichier de configuration du serveur comme vu précédement (section <alerts>, option <email_alert_level>). Si on ne veut pas d'alerte, on met ce niveau à 0 ou tout au moins en dessus de 5 dans mon cas.
La troisième règle est la négation de la seconde par la présence d'un point d'exclamation ("!") devant la chaîne recherchée dans le champs "url". Elle émet une alerte de niveau 7.
==Validation==
Après l'ajout des règles, on lance de nouveau la commande pour vérification:
/var/ossec/bin/wazuh-logtest
On commence par un accès au site avec le premier message du journal.
Résultat:
----
Starting wazuh-logtest v4.2.5
Type one log per line
&nbsp;
157.55.39.130 - - [27/Feb/2022:16:40:09 +0100] "GET /abeille/wp-login.php HTTP/2.0" 200 8413 "-" "Mozilla/5.0 (compatible;bingbot/2.0; +<nowiki>http://www.bing.com/bingbot.htm</nowiki>)"
&nbsp;
**Phase 1: Completed pre-decoding.
        full event: '157.55.39.130 - - [27/Feb/2022:16:40:09 +0100] "GET /abeille/wp-login.php HTTP/2.0" 200 8413 "-" "Mozilla/5.0 (compatible;bingbot/2.0; +<nowiki>http://www.bing.com/bingbot.htm</nowiki>)"'
**Phase 2: Completed decoding.
        name: 'web-accesslog'
        id: '200'
        protocol: 'GET'
        srcip: '157.55.39.130'
        url: '/abeille/wp-login.php'
**Phase 3: Completed filtering (rules).
        id: '100162'
        level: '5'
        description: 'Web abeille WP-LOGIN (ADB).'
        groups: '['web', 'accesslog']'
        firedtimes: '1'
        mail: 'True'
**Alert to be generated.
----
La règle "100162" s'est bien activée. Le niveau d'alerte est bien 5 et un mail est généré ("mail: 'True'"). La description attendue est correcte.
On fait de même avec un mauvais accès avec le troisième message du journal.
Résultat:
----
Starting wazuh-logtest v4.2.5
Type one log per line
&nbsp;
14.29.240.225 - - [04/Mar/2022:23:44:49 +0100] "GET /wp-login.php HTTP/1.1" 404 16 "-" "Apache-HttpClient/4.5.2 (Java/1.8.0_161)"
&nbsp;
**Phase 1: Completed pre-decoding.
        full event: '14.29.240.225 - - [04/Mar/2022:23:44:49 +0100] "GET /wp-login.php HTTP/1.1" 404 16 "-" "Apache-HttpClient/4.5.2 (Java/1.8.0_161)"'
**Phase 2: Completed decoding.
        name: 'web-accesslog'
        id: '404'
        protocol: 'GET'
        srcip: '14.29.240.225'
        url: '/wp-login.php'
**Phase 3: Completed filtering (rules).
        id: '100119'
        level: '7'
        description: 'Web attaque WP-LOGIN (ADB).'
        groups: '['web', 'accesslog']'
        firedtimes: '1'
        mail: 'True'
**Alert to be generated.
----
La règle "100119" s'est bien activée. Ici l'alerte est de niveau 7 et le descriptif est celui attendu.
==Activation==
Il nous reste à ajouter ce n° de règle "100119" au fichier de configuration "/var/ossec/etc/ossec.conf" de notre serveur à la section "<active-response>", option "<rules_id>" comme vu précédemment. Noublions pas de relancer le service.




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