> Tech > Qui visite votre site ?

Qui visite votre site ?

Tech - Par iTPro.fr - Publié le 24 juin 2010
email

par Gary Guthrie
L'utilitaire UPDHTTPLOG permet de saisir le nom de domaine des clients qui accèdent à  un serveur Web AS/400.

Dans le domaine du commerce électronique, les informations sur les visites effectuées sur un site Web sont d'une valeur inestimable. Aussi, la plupart des serveurs Web, et notamment les serveurs HTTP sur AS/400 (Internet Connection Server et Internet Connection Secure Server, respectivement en V4R1 et V4R2), permettent d'obtenir des informations sur les visiteurs d'un site Web en offrant la possibilité de consigner sur le serveur des informations concernant les accès des clients. Lorsque la log des accès au serveur est activée, chaque demande d'accès reçue par le serveur permet de capturer des informations utiles. Par exemple, la périodicité des accès et le nombre d'octets transmis peuvent être utilisés pour optimiser les ressources allouées au service des clients. Une autre option consiste par exemple, à  utiliser la log pour assurer le suivi des documents auxquels les clients accèdent afin, par exemple, d'identifier les produits qui les intéressent le plus.

Les adresses IP n'aident guère à  l'identification d'un client, car elles se ressemblent toutes 

L'identité du client est également une information importante qui peut être consignée. Pour chaque requête adressée au serveur, celui-ci reçoit les adresses IP du client demandeur. Toutefois, les adresses IP n'aident guère à  l'identification d'un client, car elles se ressemblent toutes. De ce fait, il est préférable de consigner le nom qualifié du domaine du demandeur. Le serveur Web AS/400 offre le choix de consigner les noms DNS (Domain Name System) résolus.

Malheureusement, la résolution des noms de domaines implique une pénalisation considérable des performances, le serveur Web devant faire une recherche inverse auprès d'un serveur DNS. Une recherche inverse implique que le serveur Web contacte le serveur DNS, lequel recherche ensuite dans un tableau de noms une adresse IP correspondante avant de retourner le nom de l'hôte associé au serveur Web. Cela prend du temps ! Pire encore, si un client accédant au site ne possède pas de nom DNS associé à  son adresse IP, le serveur Web attendra dans une boucle de temporisation de résolution d'adresse (jusqu'à  30 secondes) pour chaque requête émise par le client. Etant donné que l'accès aux pages Web consiste en des requêtes multiples, cela peut se traduire en délais extrêmement longs et en performances très médiocres pour les clients visitant sur le site. Le nom DNS n'est pas nécessaire pour servir une page Web. Aussi, la question qui se pose est de savoir pourquoi générer des surcoûts de recherche DNS au moment de satisfaire une requête HTTP ? En fait, différer les recherches DNS à  un moment ultérieur est une meilleure approche.

C'est pourquoi, j'ai créé la commande UPDHTTPLOG (Update HTTP Log), un utilitaire qui fait une recherche DNS inverse à  la demande. Cette commande permet d'une part, de désactiver la fonctionnalité de recherche de demande de connexion DNS et d'autre part, d'exécuter une recherche du nom de l'hôte en batch à  la place, au moment de votre choix. UPDHTTPLOG lit le fichier de log système créé par le serveur Web, traduit les adresses IP en noms de domaine et génère un nouveau fichier log contenant les noms traduits. Etudions de plus près les caractéristiques de la commande UPDHTTPLOG.

Le fichier de log des accès de la plupart des serveurs Web utilise un format baptisé format commun. Ce dernier représente en fait un fichier texte au format libre. L’AS/400 offre un choix supplémentaire, le format DDS. Celui-ci convertit chaque enregistrement de log en zones d’une base de données. Les deux formats enregistrent les mêmes informations. Toutefois, pour un programmeur AS/400, le format DDS est beaucoup plus facile à  manipuler et représente évidemment mon choix. L’AS/400 crée le fichier log des accès dans la bibliothèque QUSRSYS. Pour ce faire, il utilise automatiquement le fichier modèle QATMHLOG de la bibliothèque QTCP. On peut spécifier le nom de fichier de son choix dans l’instruction AccessLog de la configuration HTTP. Plusieurs directives serveur sont associées au fichier de log. Pour de plus amples informations sur ces instructions, consultez l’encadré “Instructions de log des accès,” et le manuel Webmaster’s Guide V4R2 (GC41-5434).

J’ai utilisé les définitions de champs issues de QATMHLOG comme point de départ d’un fichier de log défini par l’utilisateur, et j’y ai ajouté un champ pour le nom de domaine traduit. J’ai également spécifié l’adresse IP du client et la date et l’heure de sa requête comme clés afin de pouvoir ignorer tout enregistrement du fichier log provenant du système d’origine déjà  traité avec succès. Les DDS de la figure 1 présentent un exemple de fichier d’historique défini par l’utilisateur. Les champs de la section A correspondent à  ceux trouvés dans le fichier modèle QATMHLOG et constituent par conséquent le fichier de log système. Notez les champs que j’ai ajouté en B pour le fichier de log défini par l’utilisateur.

Le fichier de log système contiendra un membre pour chaque jour où le serveur fonctionne. Si le serveur est opérationnel, un nouveau membre est ajouté à  minuit. Dans le cas contraire, la première fois que vous démarrez le serveur un jour donné, un nouveau membre est ajouté. La date est répercutée dans le nom du membre et a le format Qsaammjj, où s représente l’indicateur de siècle, aa indique l’année, mm représente le mois, et enfin jj le jour.

Téléchargez cette ressource

Checklist de protection contre les ransomwares

Checklist de protection contre les ransomwares

Comment évaluer votre niveau de protection contre les ransomwares à la périphérie du réseau, et améliorer vos défenses notamment pour la détection des ransomwares sur les terminaux, la configuration des appareils, les stratégies de sauvegarde, les opérations de délestage... Découvrez la check list complète des facteurs clés pour améliorer immédiatement la sécurité des terminaux.

Tech - Par iTPro.fr - Publié le 24 juin 2010