HTML5 / CSS 2.x/3 / PHP / MySQL ...

Analyse du contenu du fichier de traçage

Maintenant que votre script de traçage est installé, vous devez certainement commencer à voir ces fichiers dans le dossier logs de votre site web. Voyons maintenant comment analyser leur contenu.

Gérer les fichiers de traçage

Si vous faites bien votre travail de développeur, vous avez certainement protégé l'accès de vos fichiers de traçage avec un fichier .htaccess placé dans le dossier logs et contenant:

<?php
deny from all

Si ce n'est pas fait, faites-le sans tarder. AInsi, vous seul aurez accès au contenu du dossier logs par ftp.

Faites le ménage

Prennez un peu de temps régulièrement pour voir ces fichiers de traçage. Ne les conservez pas inutilement pendant un temps indéterminé. D'une part, ils encombreraient le serveur, d'autre part, leur analyse régulière vous fera remonter des comportements anormaux auxquels il serait souhaitable de trouver très rapidement des solutions.

Copiez localement ces fichiers de traçage et supprimez-les du serveur très régulièrement.

Si vous ne pouvez gérer ces fichiers, mettez en commentaire dans index.php la ligne qui include tracage.inc.php.

Première analyse en vrac d'un fichier de traçage

La première chose importante est de faire un balayage visuel d'un fichier de traçage. Cette opération est réalisée avec un éditeur de texte ordinaire. On charge le contenu d'un fichier de traçage et on le survole rapidement en faisant défiler les lignes à la recherche d'anomalies:

analyse en vrac par balayage visuel

Ici une copie d'écran du balayage visuel du contenu d'un fichier de traçage. Immédiatement nous avons détecté une anomalie, surlignée en bleu clair dans la copie d'écran. Extrait des anomalies:

"76.164.223.210";02/09/2014 02:13:05;/fckeditor/editor/filemanager/connectors/asp/connector.asp;;
"76.164.223.210";02/09/2014 02:13:05;/fckeditor/editor/filemanager/connectors/php/connector.php;;
"76.164.223.210";02/09/2014 02:13:05;/fckeditor/editor/filemanager/browser/default/connectors/asp/connector.asp;;
"76.164.223.210";02/09/2014 02:13:05;/fckeditor/editor/filemanager/browser/default/connectors/php/connector.php;;
"76.164.223.210";02/09/2014 02:13:06;/admin/fckeditor/editor/filemanager/browser/default/connectors/aspx/connector.aspx;;
"76.164.223.210";02/09/2014 02:13:06;/admin/fckeditor/editor/filemanager/browser/default/connectors/asp/connector.asp;;

Afin de ne pas saturer l'affichage, nous avons retiré le contenu de certains champs.

Ce qui est anormal dans ce rapport de traçage:

C'est le signe évident d'une attaque informatique par un script automatique qui recherche toutes les failles de notre serveur.

Ici, l'adresse IP du visiteur est 76.164.223.210 et provient des USAs.

Les robots d'indexation

Dans ce même fichier de traçage, on retrouve la trage de robots d'indexation:

"66.249.64.154";02/09/2014 02:59:56;/sortie/detail/id/495?PHPSESSID=tuhl5pki2qn4ksgpt98eobatk7;;Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)

Ici c'est le robot d'indexation Google qui est passé sur le site web. Mais il y a d'autres robots qui viennent indexer nos pages, des robots beaucoup moins connus:

"217.118.23.112";02/09/2014 12:33:32;/sortie;;ADmantX Platform Semantic Analyzer - ADmantX Inc. - www.admantx.com - support@admantx.com
"54.164.154.216";02/09/2014 12:33:39;/sortie/creation;;Mozilla/5.0 (compatible; proximic; +http://www.proximic.com/info/spider.php) :24.0) Gecko/20100101 Firefox/24.0
"54.164.154.216";02/09/2014 12:33:40;/profil/connexion/;;Mozilla/5.0 (compatible; proximic; +http://www.proximic.com/info/spider.php)
"54.164.154.216";02/09/2014 12:33:40;/sortie/creation;;Mozilla/5.0 (compatible; proximic; +http://www.proximic.com/info/spider.php)
"54.164.154.216";02/09/2014 12:33:40;/profil/connexion/;;Mozilla/5.0 (compatible; proximic; +http://www.proximic.com/info/spider.php)

Ici, deux robots, admantx et proximic....

La "signature" de ces robots d'indexation apparaît dans le dernier champ, celui où nous enregistrons le user-agent, c'est à dire le navigateur utilisé par le visiteur:

ADmantX Platform Semantic Analyzer - ADmantX Inc. - www.admantx.com - support@admantx.com

Il est évident que le navigateur admantx n'existe pas. D'ailleurs, on retrouve le lien de leur site web. Après quelques recherches, nous découvrons que c'est plus un robot d'indexation parasite. Après quelques recherches via Google, c'est classé comme spamBot, un robot qui génère du trafic parasite sur les sites web.

Nous verrons plus loin comment neutraliser de manière radicale ces spamBots.

Voir les robots dans le traçage

Si votre éditeur de texte dispose d'une fonction de recherche, lancez une recherche sur "crawl" puis "bots". Les mots recherchés vont apparaître surlignés:

mise en évidence des bots

Dans la copie d'écran ci-dessus, on a surligné le mot "bot". On voit qu'il y en a vraiment beaucoup. Même un peu trop.

Jusqu'à présent, vous n'aviez pas conscience du trafic généré par les robots d'indexation. Dans la réalité, l'indexation dévore enre 50 et 80% de vos ressources informatiques.

C'est un peu comme si vous conduisez un bus et que sur les 40 places passagers disponibles, 30 étaient occupées par des contrôleurs! Dans la vie réelle, vous trouvereriez ça absurde. Pourtant, c'est ce qui se passe AVEC TOUS LES SERVEURS WEB!

Si on analyse le trafic d'un site web tel qu'il est enregistré dans les fichiers de traçage, on découvrira - avec étonnement et effroi - qu'il y a pléthore de connexions non fructueuses:

Donc, les vrais visiteurs deviennent complètement minoritaires. Et pire, s'ils viennent au moment où un spamBot exécute plusieurs requêtes par seconde, il y a fort à parier que le visteur trouvera votre serveur bien lent, voire carrément indisponible! Bref, il ne reviendra pas.

Les risques du trafic parasite

Le trafic parasite généré par les robots d'indexation, les spamBots et les scripts automatiques d'attaque des hackers représentent un vrai risque:

Si votre hébergeur trouve que votre serveur sollicite trop les ressources, il peut:

Le plus grave: beaucoup de bases de données limitent le nombre de requêtes simultanées. Si un spamBot fait 10 requêtes secondes, il est évident qu'il va planter votre base de données!

Conclusion

Analyser le trafic de son serveur web est d'un intérêt stratégique.

mais il faut aussi mettre en place des méthodes de protection adaptées et efficaces. C'est ce que nous verrons, si vous le souhaitez, en allant ici:
sécurisation de son site web

Tous les articles sur ce thème