Aller au contenu | Aller au menu | Aller à la recherche

Another Home Page Blog

lundi, février 14 2011

Utilisation des plugins Awstats

Nous avons vu dans un précédent billet comment mettre en oeuvre la génération de statistiques de visites avec Awstats. Nous allons maintenant enrichir et améliorer ces statistiques, avec dans un premier temps l'utilisation de plugins. Le prérequis pour ce billet est bien entendu d'avoir configuré Awstats et de posséder les modules Perl suivants : URI::Escape, Storable et Geo::IP.

Décoder correctement les phrases clés et les mots clés

Awstats permet de voir quels mots clés et quelles phrases clés ont été utilisés dans un moteur de recherche pour arriver sur votre site. Mais avec les jeux de caractères, Awstats peut avoir du mal à décoder les chaînes de caractères. Pour remédier à cela, il suffit d'activer le plugin decodeutfkeys dans notre fichier de configuration :

LoadPlugin="decodeutfkeys"

Accélération des recherches DNS

Dans notre configuration précédente, Awstats est paramétré pour faire une recherche DNS inverse des IP des visiteurs, ce qui peut prendre du temps. Il est donc possible de créer un fichier de cache pour accélérer ces recherches et éviter de faire 36 fois la même requête DNS. Pour cela, on active le plugin hashfiles :

LoadPlugin="hashfiles"

Géolocalisation des visiteurs

Il peut s'avérer très intéressant de savoir d'où viennent vos visiteurs selon le thème ou la langue du site : par exemple, un site rédigé en Français a dans le top 10 de ses visiteurs une adresse IP russe, une brésilienne et une chinoise (pays choisis au hasard). Si on regarde dans les logs, on se rend compte que 90% de leurs requêtes terminent en 404 ;) On va donc activer le plugin GeoIP :

LoadPlugin="geoip GEOIP_STANDARD /var/www/awstats/GeoIP.dat
LoadPlugin="geoip_city_maxmind GEOIP_STANDARD /var/www/awstats/GeoLiteCity.dat"

On remarque que dans le cas de GeoIP, il est nécessaire de disposer d'une base de données associant des plages d'adresses IP à un pays d'appartenance. Le fournisseur le plus connu pour ce type de bases de données est Maxmind, qui propose des solutions gratuites et payantes. Deux bases sont disponibles gratuitement, celle des pays et celle des villes. Ensuite, il reste à placer ces fichiers (décompressés) dans un répertoire accessible à Awstats; personnellement je le met au même endroit que les données de statistiques, donc /var/www/awstats ou /var/lib/awstats selon qu'on est sous NetBSD ou Linux. Les bases de données sont mises à jour chaque mois, pensez donc à régulièrement télécharger les nouvelles versions.

Attention  : ce type de traitement entraîne un ralentissement de la vitesse d'exécution d'Awstats, sur des gros sites cela peut très vite devenir gênant pour la carge CPU et mémoire de votre serveur.

Autres infos sur les IP des visiteurs

Plutôt que de copier-coller les IP de vos visiteurs dans un service de whois, il est possible d'utiliser le client whois d'Awstats via le plugin hostinfo :

LoadPlugin="hostinfo"

Au prochain épisode...

Nous avons maintenant quelques détails de plus sur nos visiteurs grâce aux plugins, il nous reste maintenant à mieux comprendre les visites via les directives "ExtraSection", qui fera l'objet d'un prochain billet... :)

mercredi, février 9 2011

Logrotate dans pkgsrc : ça marche chez toi ?

Il y a quelques mois maintenant, je me suis inscrit au projet pkgsrc-wip chez Sourceforge, dans le but de mettre à jour Logrotate. Le résultat est maintenant utilisable : il y a un makefile et des patches, tout ça compile sans accrocs sous NetBSD 5.0.2 et 5.1 (en amd64 du moins), bref de mon côté c'est au poil :)

Je n'ai pas forcément testé intensivement le paquet binaire, donc je lance ce léger appel à tests, si jamais ça intéresse quelqu'un. Comme Le CVS de pkgsrc-wip est actuellement indisponible, vous pouvez télécharger le Makefile et les patches dans une archive ici. Compilez, faites tourner les logs, merci d'avance !

lundi, janvier 31 2011

Awstats

Qu'est-ce qu'Awstats ? A quoi sert-il ?

Awstats est un outil web de statistiques pour un serveur web, FTP ou mail. Il permet donc de voir, pour un site internet par exemple, s'il y a beaucoup de visites, quelles sont les pages les plus visitées, quelle quantité de données est transférée, et "qui" vient le plus souvent visiter son site. Awstats est un logiciel libre, sous licence GNU GPL. Il peut être appelé dynamiquement, générer des pages HTML de statistiques, ou, grâce à des contributions externes de créer des fichiers PDF. Autre détail qui a son importance : Awstats se base sur les fichiers de log de votre serveur, il n'est donc pas à ma connaissance compatible avec les hébergements mutualisés.

De quoi ai-je besoin pour le faire fonctionner ?

Awstats a avant tout besoin de Perl ! Ensuite, selon votre besoin ou vos désirs, il faut que votre serveur web puisse exécuter des scripts CGI. Dans le cas d'Apache donc, pas besoin de mod_perl pour afficher vos statistiques Awstats, mais il faudra activer mod_cgi si vous souhaitez afficher dynamiquement les statistiques.

De plus, selon les fonctionnalités que vous souhaiterez activer, il est nécessaire d'avoir quelques modules Perl. Si vous souhaitez suivre ces billets, il peut être de bon ton d'installer les modules Perl suivants : URI::Escape, Storable, Geo::IP (et non Geo::IPfree) et Net::XWhois . Concernant NetBSD, j'ai installé les paquets suivants :

  • p5-Business-ISBN
  • p5-Business-ISBN
  • p5-Geo-IP
  • p5-MIME-Base64
  • p5-Net-XWhois
  • p5-Test-Simple
  • p5-URI

Installation

Awstats est généralement fourni dans les paquets de votre distribution Linux ou BSD favorite. Si ce n'est pas dans les dépôts officiels, il est fort probable que des dépôts alternatifs soient disponibles. Ainsi, pour RHEL et ses clones tels que CentOS, vous pouvez utiliser le dépôt EPEL. Si vous ne connaissez aucun dépôt ou que ceux-ci fournissent une version trop ancienne, vous pouvez utiliser l'archive disponible sur le site d'Awstats. Point non négligeable : comme il s'agit d'un programme Perl, nul besoin de le compiler, ce qui est fort appréciable !

Pour la suite : tous les exemples et codes proviennent d'une machine NetBSD 5, et Awstats est installé grâce au paquet disponible sur pkgsrc.

Première configuration

Nous avons donc installé Awstats. Avant de configurer Awstats

La configuration se situe dans /usr/pkg/etc/awstats/' et on y trouve déjà un fichier : awstats.model.conf''. Copions ce modèle et éditons-le :

root@vhost:/usr/pkg/etc/awstats# cp -p awstats.model.conf awstats.blog.anotherhomepage.org.conf
root@vhost:/usr/pkg/etc/awstats# vi awstats.blog.anotherhomepage.org.conf

Examinons maintenant la configuration, nous allons renseigner :

  • l'emplacement du fichier de logs
  • le nom (dns) du site web, ainsi que ses alias
  • renseigner les pages d'index
  • exclure Awstats des statistiques
  • exclure notre adresse IP des statistiques
  • et bien d'autres trucs encore !

Attention :

  • je n'affiche par la suite que les options que j'ai modifiées par rapport au modèle
  • ma configuration date un peu : mon fichier a été créé à l'époque d'Awstats 6.6, et de nouvelles options ont fait leur apparition
# Emplacement du fichier de log
LogFile="/var/log/httpd/blog-access.log"
# Nom DNS de notre site internet
SiteDomain="blog.anotherhomepage.org"
# Autres noms DNS possibles, ou adresse IP directement
HostAliases="localhost 127.0.0.1 www.blog.anotherhomepage.org 188.40.96.170"
# Faire une recherche inverse DNS sur les IP des visiteurs, cela permet d'avoir une meilleure visibilité en voyant
# les DNS inversedes FAI, mais attention : sur un gros site, cela peut énormément ralentir Awstats !
# Si vous avez un doute, mettez cette valeur à 0
DNSLookup=1
# Localisation des bases de données des statistiques, ici le chemin NetBSD !
# Sous GNU/Linux, le chemin est généralement /var/lib/awstats
DirData="/var/www/awstats"
# Localisation du GCI appelé par notre page de statistiques (awstats.pl)
DirCgi="/awstats"
# ...
DirIcons="/awstats/icon"
# Awstats peut proposer de mettre à jour en direct les statistiques via un bouton.
# C'est risqué, donc on désactive
EnableLockForUpdate=1
# Je préfère générer la page web en XHTML plutôt qu'en HTML
BuildReportFormat=xhtml
# C'est toujours bien les sauvegardes :)
KeepBackupOfHistoricFiles=1
# Page d'index par défaut
DefaultFile="index.html index.php"
# On peut s'exclure des visites : si on est en IP fixe, mieux vaut exclure son IP
# ainsi que celle du serveur et la boucle locale
SkipHosts="127.0.0.1 188.40.96.170"
# Ici j'exclue des statistiques le panneau d'admin de Dotclear, le répertoire des thèmes et quelques fichiers
# en rapport  avec un plugin
SkipFiles="REGEX[^\/admin] REGEX[^\/awstats] REGEX[^\/themes] /?pf=partager2/img/delicious.png /?pf=partager2/img/digg.png /?pf=partager2/img/yahoomyweb.png /?pf=partager2/img/wikio.gif /?pf=partager2/img/sprite_partager2.png"
# Si vous avez des URL de type http://monsite.com/kikoo.php?variable=valeur
# vous pouvez différencier les requêtes selon ce que vaut "valeur"
# Mieux vaut faire de même pour votre referrer ;)
URLWithQuery=1
URLWithQueryWithoutFollowingParameters="PHPSESSID jsessionid"
URLReferrerWithQuery=1
# Je suis un peu parano sur les bord, je cherche à voir si des vers tentent d'accéder à mon site
LevelForWormsDetection=2
# Awstats affiche le top 10, sauf si on va dans le détail, où il affiche le top 1000 par défaut
# Moi j'en veux encore plus ! (mais la page est plus longue à charger)
MaxRowsInHTMLOutput=2000
# Je force la langue en Français, mais vous n'êtes pas obligé d'en faire autant
Lang="fr"
# J'affiche les stats sur les vilains vers qui polluent le Net
ShowWormsStats=HBL

Génération des statistiques de visites

Pour lancer la génération des statistiques, la commande est la suivante :

root@vhost:~# /usr/pkg/bin/perl /usr/pkg/awstats/bin/awstats.pl --config=blog.anotherhomepage.org --update

Affichage des statistiques de visites Par défaut, la configuration suivante existe pour Apache :

root@vhost:~# cat /usr/pkg/etc/httpd/conf.d/awstats.conf
Alias /awstats/icon/ /usr/pkg/awstats/icon/
Alias /awstats/css/ /usr/pkg/awstats/css/
Alias /awstats/js/ /usr/pkg/awstats/js/

Alias /awstats/ /usr/pkg/awstats/cgi-bin/

<Location /awstats/>
        DirectoryIndex awstats.pl
        Options ExecCGI FollowSymLinks
        AddHandler cgi-script .pl
        AddHandler cgi-script .cgi
        order allow,deny
        allow from all
</Location>

Sous NetBSD, les fichiers .conf présents dans /usr/pkg/etc/httpd/conf.d/ sont automatiquement inclus dans votre configuration, ce qui ajoute un certain confort. A noter que de cette manière, vos statistiques sont accessibles au monde entier ! Vous pouvez utiliser un fichier htaccess ou les directives Allow avec votre IP si vous êtes en IP fixe pour restreindre l'accès aux statistiques.

Automatisation, multiplication et gestion de la rotation des logs

Tout ça c'est bien, mais une fois qu'on a 2-3 sites internet qui tournent, on ne va pas se connecter chaque jour sur notre serveur pour lancer une mise à jour par site. Il est possible de remédier à cela grâce à un utilitaire fourni avec Awstats : awstats_updateall.pl permet de mettre à jour tous les sites configurés en une seule commande ! En utilisation dans une crontab, tout est automatisé :) Exemple :

root@vhost:~# crontab -l | grep -i awstats
# Awstats :
10      0-23/4  *       *       *       /usr/pkg/bin/perl /usr/pkg/awstats/bin/awstats_updateall.pl now -awstatsprog=/usr/pkg/awstats/cgi-bin/awstats.pl -configdir=/usr/pkg/etc/awstats/ > /dev/null

Et voici nos statistiques mises à jour toutes les quatre heures, à la dixième minute (00h10, 4h10, 8h10...)

Si vous effectuez une rotation de vos logs avec logrotate, le plus intelligent est encore d'ajouter votre mise à jour de statistiques dans la configuration de logrotate, comme le détaille la FAQ d'Awstats.

Au prochain épisode...

Cette configuration basique et fonctionnelle permet d'avoir des statistiques intéressantes, mais nous pouvons aller plus loin, comme par exemple avec la géolocalisation d'adresses IP et l'utilisation d'autres plugins, et même aller jusqu'à créer nos propres filtres pour avoir des statistiques sur certaines parties du site par exemple.

lundi, janvier 17 2011

Vérifications de permissions - suite

Introduction : les astuces de ce billet sont extraites du document Guide to the Secure Configuration of Red Hat Enterprise Linux 5 édité par la NSA. Vous pouvez télécharger le document au format PDF dans son intégralité sur leur site. Cette introduction me permet d'être en conformité avec leur notice de Copyright.

Après les droits des répertoires et le sticky bit, amusons-nous un peu avec SUID et SGID : un fichier possédant l'attribut SUID ou SGID permet d'être lancé avec les droits de l'utilisateur ou du groupe qui a été placé, généralement root. Ainsi, le programme at, permettant de lancer une tâche à un moment donné, est accessible aux utilisateurs classiques alors que son fonctionnement nécessite des droits plus élevés. Ceci peut s'avérer risqué car si un programme SUID root possède une faille, celle-ci peut être exploitée avec les droits de root, même si l'attaquant n'a pas les droits.

Comme pour le sticky bit, commençons par vérifier notre environnement :

root@orgrimmar:~# whoami
root
root@orgrimmar:~# cat /etc/redhat-release 
CentOS release 5.5 (Final)

Recherchons maintenant tous les fichiers possédant un SUID ou un SGID :

root@orgrimmar:~# find / \( -perm -4000 -o -perm -2000 \) -type f -print
/bin/ping6
/bin/umount
/bin/ping
/bin/mount
/bin/su
/lib64/dbus-1/dbus-daemon-launch-helper
/usr/bin/wall
/usr/bin/chfn
/usr/bin/newgrp
/usr/bin/sudoedit
/usr/bin/chsh
/usr/bin/write
/usr/bin/at
/usr/bin/chage
/usr/bin/crontab
/usr/bin/ssh-agent
/usr/bin/passwd
/usr/bin/sudo
/usr/bin/gpasswd
/usr/bin/locate
/usr/bin/screen
/usr/libexec/openssh/ssh-keysign
/usr/libexec/libvirt_proxy
/usr/libexec/utempter/utempter
/usr/kerberos/bin/ksu
/usr/sbin/userhelper
/usr/sbin/postqueue
/usr/sbin/postdrop
/usr/sbin/usernetctl
/usr/sbin/ccreds_validate
/sbin/netreport
/sbin/mount.nfs4
/sbin/umount.nfs4
/sbin/umount.nfs
/sbin/mount.nfs
/sbin/unix_chkpwd
/sbin/pam_timestamp_check
find: /proc/9859/task/9859/fd/4: Aucun fichier ou répertoire de ce type
find: /proc/9859/task/9859/fd/4: Aucun fichier ou répertoire de ce type
find: /proc/9859/fd/4: Aucun fichier ou répertoire de ce type
find: /proc/9859/fd/4: Aucun fichier ou répertoire de ce type
root@orgrimmar:~# 

Sur le coup, voir autant de lignes peut paraître effrayant, mais si on y regarde de plus près, on peut comprendre que 99% des fichiers indiqués aient besoin du SUID. Le seul qui m'inquiète, c'est screen. Je vais donc regarder sur une autre machine, bien différente cette fois-ci :

nils@tomb:~$ uname -sr
NetBSD 5.0.2
nils@tomb:~$ ls -hl /usr/pkg/bin/scree*
lrwxr-xr-x  1 root  wheel   12B Jul 11 11:23 /usr/pkg/bin/screen@ -> screen-4.0.3
-r-s--x--x  1 root  wheel  279K Jul 11 11:23 /usr/pkg/bin/screen-4.0.3*

On voit que screen sur ma machine NetBSD a aussi un bit SUID. C'est bon, je peux aller me coucher l'esprit tranquille :) Mais avant, revenons à notre serveur CentOS, et comme pour l'affaire du sticky bit, simulons un programme dont le SUID a été ajouté inutilement :

root@orgrimmar:~# cat > testbin
#!/bin/bash
echo -n "Je suis un programme SUID de test"
exit 0
root@orgrimmar:~# chmod -v +x testbin 
Le mode d'accès de `testbin' a été modifié à 0755 (rwxr-xr-x).
root@orgrimmar:~# ls -hl testbin 
-rwxr-xr-x 1 root root 63 déc 31 00:44 testbin*
root@orgrimmar:~# chmod -v +s testbin 
Le mode d'accès de `testbin' a été modifié à 6755 (rwsr-sr-x).
root@orgrimmar:~# ls -hl testbin 
-rwsr-sr-x 1 root root 63 déc 31 00:44 testbin*

Relançons notre recherche :

root@orgrimmar:~# find /root \( -perm -4000 -o -perm -2000 \) -type f -print
/root/testbin

Supprimons maintenant le SUID et relançons la recherche :

root@orgrimmar:~# chmod -v -s testbin 
Le mode d'accès de `testbin' a été modifié à 0755 (rwxr-xr-x).
root@orgrimmar:~# find /root \( -perm -4000 -o -perm -2000 \) -type f -print
root@orgrimmar:~# 

Et voilà, nous sommes tranquille :)

Que faire si j'ai un doute sur un programme ? Plusieurs possibilités : s'il s'agit d'un programme qui est fourni par les paquets de votre distribution, on peut toujours aller vérifier sur d'autres machines, dont l'OS ou la distribution peut différer (comme je l'ai fait avec screen); un même programme nécessitant le SUID sur 2 OS différents peut légèrement rassurer. Si le logiciel est libre (exemple : GNU screen :D), on peut aussi aller chercher dans les fichiers de création du paquet binaire, pour les RPM il suffit de chercher le SRPM du logiciel et de l'installer sur une machine de test. Ensuite, on regarde le contenu du fichier .spec qui sert à la création de ce paquet : en effet, ces fichiers contiennent la liste et les droits des fichiers et répertoires du paquet que l'on veut compiler :) Si un .spec n'indique pas que le programme est SUID, alors il est temps de s'inquiéter !

lundi, janvier 3 2011

Vérifications de permissions

Introduction : les astuces de ce billet sont extraites du document Guide to the Secure Configuration of Red Hat Enterprise Linux 5 édité par la NSA. Vous pouvez télécharger le document au format PDF dans son intégralité sur leur site. Cette introduction me permet d'être en conformité avec leur notice de Copyright.

Je vous propose de vérifier les permissions de certains de vos fichiers sur votre serveur ou poste fonctionnant sur un système Linux. Le but est de limiter les possibilités de tentatives d'intrusion en recherchant les moyens d'entrée possibles. Commençons par vérifier notre environnement :

root@orgrimmar:~# whoami
root
root@orgrimmar:~# cat /etc/redhat-release 
CentOS release 5.5 (Final)

Recherchons maintenant tous les répertoires dont les droits permettent à n'importe quel utilisateur d'écrire dedans, et dont le sticky bit n'est pas positionné :

root@orgrimmar:~# find / -type d \( -perm -0002 -a ! -perm -1000 \) -print

Si jamais votre machine possède de nombreuses partitions, et qu'elles sont du genre bien remplies, il est possible de limiter la recherche de find à une partition à la fois :

root@orgrimmar:~# find / -xdev -type d \( -perm -0002 -a ! -perm -1000 \) -print
root@orgrimmar:~# find /home -xdev -type d \( -perm -0002 -a ! -perm -1000 \) -print
root@orgrimmar:~# find /var -xdev -type d \( -perm -0002 -a ! -perm -1000 \) -print

Idéalement (et c'est le cas sur ma machine, ouf !), cette commande ne devrait occasionner aucun affichage. Maintenant, amusons-nous un peu :

root@orgrimmar:/tmp# mkdir insecure
root@orgrimmar:/tmp# chmod -v 777 insecure
Le mode d'accès de `insecure' a été modifié à 0777 (rwxrwxrwx).
root@orgrimmar:/tmp# find /tmp/ -type d \( -perm -0002 -a ! -perm -1000 \) -print
/tmp/insecure

Positionnons maintenant le sticky bit :

root@orgrimmar:/tmp# ls -hl /tmp/ | grep insecure
drwxrwxrwx 2 root root 4,0K déc 30 23:54 insecure/
root@orgrimmar:/tmp# chmod -v +t /tmp/insecure/
Le mode d'accès de `/tmp/insecure/' a été modifié à 1777 (rwxrwxrwt).
root@orgrimmar:/tmp# ls -hl /tmp/ | grep insecure
drwxrwxrwt 2 root root 4,0K déc 30 23:54 insecure/
root@orgrimmar:/tmp# find /tmp/ -type d \( -perm -0002 -a ! -perm -1000 \) -print
root@orgrimmar:/tmp# 

Qu'est-ce que le sticky bit ? Extrait de la page de manuel de chmod (man chmod) :

t (sticky-bit) conserver le code du programme sur le périphérique de swap après exécution. Il s’agit du comportement original, mais de nos jours il sert uniquement pour les répertoires. Il indique que seuls le propriétaire du répertoire, et le propriétaire d’un fichier qui s’y trouve ont le droit de supprimer ce fichier. C’est typiquement utilisé pour les répertoires comme /tmp ayant une autorisation d’écriture générale.

Vérifions cela :

root@orgrimmar:/tmp# cd /
root@orgrimmar:/# ls -hl | grep tmp
drwxrwxrwt   5 root root 4,0K déc 30 23:59 tmp/

Le sticky bit est positionné. Je suis rassuré. Néanmoins, il ne fait pas tout. Regardons donc quels répertoires sont accessibles à tous les utilisateurs, sans chercher à savoir si le sticky bit est positionné :

root@orgrimmar:/# find / -type d \( -perm -0002 \) -print
/var/tmp
/var/lib/xenstored
/dev/shm
/tmp
/tmp/insecure
/tmp/.ICE-unix

Cela fait déjà un peu plus de monde... pas très rassurant mais à part notre répertoire insecure, pas de quoi s'affoler : /var/tmp et /tmp sont des répertoires destinés aux fichiers temporaires des programmes en fonctionnement, /var/shm désigne la mémoire partagée et le xenstored sert au bon fonctionnement de l'hyperviseur Xen.

Pour finir, nous pouvons nettoyer notre petite expérience :

root@orgrimmar:/# rmdir -v /tmp/insecure/
rmdir: destruction du répertoire /tmp/insecure/
root@orgrimmar:/# ls -hal /tmp/ | grep secu

- page 4 de 31 -