WIKI sur Linux (ADB)

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

LINUX Discussion

LINUX:Wazuh-Décodeurs et Règles (voir la source)

Version du 2 mars 2022 à 19:22

2 970 octets ajoutés ,  2 mars 2022
aucun résumé des modifications
Aucun résumé des modifications
Aucun résumé des modifications
Ligne 34 : Ligne 34 :


=1er cas=
=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.
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 PHPMyAdmin 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.




Ligne 50 : Ligne 50 :
  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"
  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 remarquons la diversité des requêtes. De plus nous remarquons la diversité des n° de message d'erreur d'HTTP. 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 ("404") correspond à une requête sécurisée car non redirigée mais dont l'URL n'existe pas.




Ligne 83 : Ligne 83 :
         mail: 'False'
         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 de décodage a permis d'identifier le n° de message d'erreur d'HTTP ("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".
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".




Celle règle existante est à chercher dans le répertoire adapté "/var/ossec/ruleset/rules". Une rapide recherche avec une commande "grep", nous informe qu'elle se trouve dans le fichier "0245-web_rules.xml" dont voici un extrait:
----
<nowiki><group name="web,accesslog,">
  <rule id="31100" level="0">
    <category>web-log</category>
    <description>Access log messages grouped.</description>
  </rule>
&nbsp;
  <rule id="31108" level="0">
    <if_sid>31100</if_sid>
    <id>^2|^3</id>
    <compiled_rule>is_simple_http_request</compiled_rule>
    <description>Ignored URLs (simple queries).</description>
  </rule>
&nbsp;
  <rule id="31101" level="5">
    <if_sid>31100</if_sid>
    <id>^4</id>
    <description>Web server 400 error code.</description>
    <group>attack,pci_dss_6.5,pci_dss_11.4,gdpr_IV_35.7.d,nist_800_53_SA.11, nist_800_53_SI.4, tsc_CC6.6,tsc_CC7.1,tsc_CC8.1,tsc_CC6.1,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3,</group>
  </rule>
</group> </nowiki>
----
C'est la première qui a été déclenchée car lors de son pre-décodage, il a repéré que c'était une requête de type WEB ("<nowiki><category>web-log</category></nowiki>"); le niveau est "0" ("level=0").
La seconde règle aurait pu être déclenchée mais elle n'est pas d'un niveau supérieur. Cette seconde règle fait suite à la première ("<nowiki><if_sid>31100</if_sid></nowiki>"); elle n'est évaluée que si la première est validée. La condition "<nowiki><id>^2|^3</id></nowiki>" signifie qu'elle est validée pour tout message d'erreur d'HTTP commençant par "2" ou (barre verticale les séparant) "3" (le chapeau signifiant "commençant par").
Pour faire bonne mesure, nous avons ajouté une troisième règle qui dépend de la première et qui concerne tout message d'erreur commençant par "4", ce qui est le cas de notre quatrième entrée du journal.
Dans le répertoire "/var/ossec/etc/rules" reprenant les règles personnelles, nous créons le fichier "perso-web_rules.xml" dans laquelle on ajoute la règle suivante:
----
<nowiki><group name="web,accesslog,">
  <rule id="100105" level="7">
    <if_sid>31100, 31101,  31102</if_sid>
    <url>^/phpMyAdmin|^/phpmyadmin</url>
    <description>Web attaque 1 (ADB).</description>
  </rule>
</group> </nowiki>
----
Toute règle doit avoir un n° unique sinon le service "wzud-manager.service" ne démarre pas. Nous avons choisit le n° "100105" de niveau "7".
Cette règle ne sera évaluée que si une des trois règles de base est validée ("<nowiki><if_sid>31100, 31101,  31102</if_sid><:nowiki>"). Ensuite le champs "url" doit commencer par "phpmyadmin" ou par "/phpMyAdmin". 0Nous avons ajouté cette variante également rencontrée. (Unix est sensible à la case au contraire de Windows)




Ligne 116 : Ligne 158 :
  **Alert to be generated.
  **Alert to be generated.
----
----
Notre règle a bien été enclenchée.




Ligne 149 : Ligne 192 :
     Trying rule: 31108 - Ignored URLs (simple queries).
     Trying rule: 31108 - Ignored URLs (simple queries).
     Trying rule: 31511 - Blacklisted user agent (wget).
     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: 31115 - URL too long. Higher than allowed on most browsers. Possible attack.
     Trying rule: 31103 - SQL injection attempt.
     Trying rule: 31103 - SQL injection attempt.
Ligne 161 : Ligne 202 :
  **Alert to be generated.
  **Alert to be generated.
----
----
On a ici plus de détails sur le cheminement.


Il nous reste à ajouter ce n° de règle "100195" au fichier de configuration "/var/ossec/etc/ossec.conf" de notre serveur à la section "<active-response>", option "<rules_id>" comme vu précédemment




Récupérée de « https://www.adbweb.gslb.eu/wiki/index.php?title=Spécial:MobileDiff/2215 »