Différences

Ci-dessous, les différences entre deux révisions de la page.

--- cyber:vulnerabilite:analyselogs [2025/07/03 11:33] – [Analyse de logs] admin
+++ cyber:vulnerabilite:analyselogs [2025/07/03 11:57] (Version actuelle) – [Exploiter] admin
@@ Ligne 32: / Ligne 32: @@
 ==== Exploiter ====
-Consultez les solutions de chaque challenge.
 ===== Bénéfices potentiels =====
@@ Ligne 47: / Ligne 47: @@
   * Utiliser des outils de surveillance et d'analyse de logs en temps réel.
+====== Exemples ======
+===== Exemple 1 =====
+Voici un exemple de logs Apache qui pourraient indiquer une tentative d'**injection SQL** :
+<code class="apache">
+.0.0.1 - - [21/Jan/2022:10:00:00 +0000] "GET /index.php?id=1' OR '1'='1 HTTP/1.1" 200 612
+.0.0.1 - - [21/Jan/2022:10:00:01 +0000] "GET /index.php?id=1' OR '1'='2 HTTP/1.1" 500 612
+.0.0.1 - - [21/Jan/2022:10:00:02 +0000] "GET /index.php?id=1'; DROP TABLE users; -- HTTP/1.1" 500 612
+</code>
+Dans cet exemple, trois requêtes HTTP distinctes sont envoyées au serveur Apache.
+  * La première requête contient une chaîne de caractères <code>1' OR '1'='1</code>  dans le paramètre **id**. Cette chaîne est souvent utilisée par les attaquants pour tester la vulnérabilité SQL Injection. Si la requête renvoie un code de retour HTTP 200 (succès), cela peut indiquer que l'injection SQL est possible.
+  * La deuxième requête, avec la chaîne <code>1' OR '1'='2</code>, est une autre tentative d'injection, visant à vérifier la réaction du serveur. Un code de retour **HTTP 500** (erreur interne du serveur) peut suggérer que l'injection SQL n'a pas réussi ou que le serveur a rencontré une erreur.
+  * La troisième requête est une tentative d'exploitation plus malveillante, visant à supprimer une table de la base de données. Encore une fois, un code de retour **HTTP 500** peut indiquer une erreur ou un blocage par des mesures de sécurité.
+===== Exemple 2 =====
+Voici un exemple de logs Nginx qui pourraient indiquer une tentative d'attaque de type **LFI (Local File Inclusion)**:
+<code class="nginx">
+.0.0.1 - - [21/Jan/2022:10:00:00 +0000] "GET /index.php?file=../../../etc/passwd HTTP/1.1" 403 612
+.0.0.1 - - [21/Jan/2022:10:00:01 +0000] "GET /index.php?file=../../../var/log/nginx/access.log HTTP/1.1" 403 612
+</code>
+Dans cet exemple, deux requêtes HTTP sont envoyées au serveur Nginx.
+  * La première requête tente d'accéder au fichier <code>/etc/passwd</code> du système, ce qui est une tentative commune d'inclusion de fichier local. Si la requête renvoie un code de retour **HTTP 403** (accès interdit), cela indique que des mesures de sécurité peuvent être en place pour bloquer l'accès aux fichiers sensibles.
+  * La deuxième requête tente d'accéder au fichier de logs d'accès de Nginx. Un code de retour **HTTP 403** indique également que l'attaque LFI n'a pas réussi en raison des restrictions d'accès.
+====== References ======
+URL :
+  * https://openclassrooms.com/fr/courses/1750566-optimisez-la-securite-informatique-grace-au-monitoring/7144422-selectionnez-les-logs-a-analyser
+  * https://openclassrooms.com/fr/courses/1750566-optimisez-la-securite-informatique-grace-au-monitoring
+  * https://www.ssi.gouv.fr/uploads/2022/01/anssi-guide-recommandations_securite_architecture_systeme_journalisation.pdf
+  * https://www.ssi.gouv.fr/uploads/2022/01/anssi-guide-recommandations_securite_journalisation_systemes_microsoft_windows_environnement_active_directory.pdf
+  * https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-92.pdf
 ====== Retour fiches vulnérabilités ======
   * [[cyber:vulnerabilite:accueil|Cyber fiches vulnérabilités]]