MEDIA-WIKI, MEDIA-WIKI_T, Bureaucrates, Administrateurs d’interface, Administrateurs (MediaWiki Sémantique), Conservateurs (MediaWiki Sémantique), Modificateurs (MediaWiki Sémantique), Masqueurs de modifications, Administrateurs
9 045
modifications
« LINUX:Wazuh-Décodeurs et Règles » : différence entre les versions
LINUX:Wazuh-Décodeurs et Règles (voir la source)
Version du 22 novembre 2022 à 23:59
, 22 novembre 2022Adebast a déplacé la page LINUX:Wazuh: Décodeurs et Règles vers LINUX:Wazuh-Décodeurs et Règles sans laisser de redirection
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) |
||
| (6 versions intermédiaires par le même utilisateur non affichées) | |||
| Ligne 415 : | Ligne 415 : | ||
==Règle personnelle== | ==Règle personnelle== | ||
Sur | 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 722 : | Ligne 722 : | ||
---- | ---- | ||
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. | 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>)" | |||
| |||
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" | |||
| |||
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)" | |||
| |||
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> | |||
| |||
<rule id="100162" level="5"> | |||
<if_sid>100161</if_sid> | |||
<url>^/abeille/wp-login.php</url> | |||
<description>Web abeille WP-LOGIN (ADB).</description> | |||
</rule> | |||
| |||
<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 | |||
| |||
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 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 | |||
| |||
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 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. | |||