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:

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:

• La même adresse IP 76.164.223.210 a sollicité le serveur plusieurs fois par secondes (voir dates et heures);
• Il a appelé des pages qui n'existent pas, comme /fckeditor/editor/filemanager/browser/default/connectors/asp/connector.asp

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:

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.

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:

• utilisateurs étrangers tombés chez vous par hasard, une minorité;
• les robots d'indexation:
  • les bons robots, ceux qui vous indexent sur les vrais moteurs de recherche: Google, Bing, Yahoo....
  • les mauvais robots, appelés aussi spamBots, qui vous indexent pour le profit de quelques sociétés d'analyse de trafic et dont les résultats ne sont pas accessibles aux visiteurs ordinaires;
• les hackers qui utilisent des scripts d'attaque plus ou moins agressifs;

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:

• de sécurité: les hackers cherchent des failles. S'ils en trouvent, ils vont pourrir votre site, voler des données...
• accroître le trafic: votre hébergeur vous accorde assez souvent un volume mensuel en émission assez élevé. Mais si les robots et autres spamBots dévorent ce quota, vous risquez fort de voir votre hébergement interrompu.
• sur-solliciter les requêtes eb base de données: certaines pages font parfois des traitements assez lourds en base de données. Inutile de servir des spamBots au détriment des performances de votre base de données ppour les vrais utilisateurs.

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

• vous demander de payer pour un hébergement plus musclé;
• limiter votre bande passante en sortie. Les pages deviendront anormalement lentes pour un visiteur normal;
• couper temporairement votre hébergement si les sollications mettent en péril les autres serveurs hébergés chez lui;

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