Récemment, sur un site web avec une audience non négligeable (sans être démentielle : 70 000 hits hebdo), j’ai eu à mettre en place un outil de statistiques vite fait bien fait. J’ai choisi webalizer car je connaissais et car ça se met en place en 3 minutes et que ça sort mine de rien déjà pas mal d’infos (volume de hits, pays d’origine, mots-clefs, référant etc). Et c’est mieux que “pas de stats du tout” dans un premier temps.

Il y avait deux trucs tout bêtes dans l’histoire : j’avais un an de logs non “synthétisés” par webalizer. Il a donc fallu les faire passer dans webalizer pour rattraper l’historique. Et deuxièmement, c’est à ce moment là que j’ai vu que le HostnameLookups était à Off dans la conf /etc/apache2/apache2.conf. Donc les logs ne contenaient que les IP, pas les hostname. Donc pas de statistiques par pays dans Webalizer. Dommage pour une boîte internationale qui veut voir un peu où en est sa notoriété sur la planète…

J’ai donc remédié à tout ça. Cet article présente donc l’installation de la conf rapide de Webalizer (et Apache2 en conséquence) et donne une ligne de commande pour récupérer l’année d’historique (apache2 garde par défaut 52 fichiers de logs en rotation hebdo) et enfin, le plus marrant, mouliner sur les logs pour retrouver les hostnames correspondants aux IP… (en espérant que mon hébergeur ne me flingue pas en voyant le nombre de requête DNS que je crache en ce moment même Je lui ai posé la question, ne négligez pas ce point, ce serait bête de se faire des ennemis)

Installation et conf Webalizer

Sous Debian, un simple :

aptitude install webalizer

L’outil de conf pose 2/3 questions assez simples à répondre, comme votre nom de serveur web, le nom du fichier “logrotaté”, typiquement /var/log/apache2/access.log.1 (et pas /var/log/apache2/access.log).
De toute manière, on va repasser sur le fichier de conf tout de suite après l’install. Sachez que “webalizer” fait ses calculs via la cron.daily, au petit matin (par défaut sur Debian) quand vous dormez.
Je mets 2/3 commentaires sur certains paramètres ; voyons ce que donne egrep -v "^$|^#" /etc/webalizer/webalizer.conf :

LogFile         /var/log/apache2/access.log.1
OutputDir       /var/www/webalizer # A vous de voir. Pensez à un htaccess si besoin...
Incremental     yes
ReportTitle     Statistiques d'utilisation de mon serveur web
HostName        toto.com
TopReferrers    50
TopAgents       30
HideSite        *toto
HideSite        *toto.com
HideReferrer    www.toto.com/ # sinon vous passez votre temps à votre les mouvements interne au site
HideReferrer    toto.com/ # idem
HideReferrer    Direct Request
HideURL         *.gif
HideURL         *.GIF
HideURL         *.jpg
HideURL         *.JPG
HideURL         *.ra
HideURL         *.png
GroupURL        /cgi-bin/*
GroupAgent      MSIE
HideAgent       MSIE*
GroupAgent      Mozilla
HideAgent       Mozilla*
GroupAgent      Lynx
HideAgent       Lynx*
GroupAgent      Konqueror
HideAgent       Konqueror*
GroupAgent      Opera
HideAgent       Opera*
IgnoreSite      localhost # je tunnele l'accès à mon propre site et je suis un gros visiteur de mon propre site
IgnoreReferrer  localhost # idem
MangleAgents    4

Dans la conf Apache2 /etc/apache2/apache2.conf, pensez à activer le paramètre HostnameLookups si vous voulez avoir un semblant de trace des pays rendant visite à votre site web (et rechargez Apache).

Chargement de l’historique

Il faut décompresser les logs Apache puis les importer un à un dans webalizer.Simple.
En considérant que vous avez copié vos fichiers access.log.*.gz dans /tmp, vous faites ceci :

for i in access*gz
do
        gunzip $i
done

Et ensuite, lancement de l’import :

for i in `./seq_reverse.py`
do
        webalizer access.log.$i
done

Je ne sais plus si on peut faire un seq sortant les chiffres de 1 à 52 dans l’ordre inverse, alors j’ai pondu un script python pour le faire.

A la fin, si votre répertoire /var/www/webalizer est blindé de fichiers, c’est bon. Vous pouvez voir vos stats sur l’année écoulée.

Retrouver les hostnames

C’est la partie amusante (et bourrin). Si vous n’aviez pas les hostnames des IP visitant votre serveur web, vos logs Apache ressemblait à ça :

86.x.y.190 - - [15/Mar/2007:06:25:25 +0100] "GET /favicon.ico HTTP/1.1" 200 2238 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2"

Si vous aviez activé le lookup dans Apache, vos logs ressemblent partiellement à ce qu’il y a ci-dessus (pour les serveurs n’ayant pas de nom) et généralement, ils contiennent plutôt ça :

truc.machin.com - - [02/Mar/2008:06:26:27 +0100] "GET / HTTP/1.1" 200 27488 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"

L’idée est de retrouver les noms lorsque vous n’avez que les IP. J’ai écrit un script Python pour ça (excusez-moi, je débute en Python). Script Python pour retrouver les hostnames à partir des IP d’un log Apache2

Et donc à la fin, vous envoyez la purée :

for i in /tmp/access.log.*
do
        ./retrouve_hostname.py $i
done

Attention, c’est bourrin, faites le sur un petit fichier d’abord. Le script vous génère un fichier $i.new, à vous de vider vos statistiques webalizer (rm /var/www/webalizer/*) ensuite et de relancer la moulinette d’import sur ces nouveaux fichiers.

walaaaa, c’est tout pour aujourd’hui.

Informations en préambule

Les impacts pour l’utilisateur sont minimes : délai d’environ 30 minutes (en théorie 5 minutes) lors des x (x = 5 par défaut) premiers échanges entrants avec un serveur donné. L’article anglais sur wikipedia se veut un peu plus méfiant que sa traduction minimaliste en français. A vous de voir. L’autre risque serait de se retrouver face à un vieux serveur de mails tout pourri qui implémente mal le protocole… boarf, je doute que ça arrive dans la pratique. Au pire l’utilisateur verra le problème et il sera temps de whitelister ledit serveur.

Principe

Le principe – je vous renvois à l’article wikipedia pour plus de détails – est d’utiliser une fonction standard du procotole SMTP pour redemander l’envoi d’un mail lorsqu’on le reçoit. On indique au serveur de renvoyer le message dans 5 minutes. Deux options : le serveur en face le fait, ou non. Au bout de x fois – si le serveur s’est bien comporté – on le “whiteliste” pour de bon et il n’y aura plus de délai pour celui-ci.

Quel lien avec les spammeurs ?

Imaginez une armée de PC (windows) zombies envoyant des mails à tout va (à l’insu de l’utilisateur, forcément). Le zombie utilise un programme le plus simple possible qui se contente d’envoyer la purée. De toute manière, un PC zombie comme de ce type n’a en général pas de lien retour possible vers lui même sur le port 25 (pensez à votre PC derrière un routeur genre freebox). Donc il ne recevra jamais votre demande standard de renvoi de mails. Et donc vous n’aurez jamais le mail, qui était un spam à coup sûr. CQFD.
Lisez plus bas dans l’article quelques extraits d’adresses “greylistées”, vous comprendrez que des zombies, il y en a des millions sur la planète… que fait Buffy ???
Reste ensuite les *vrais* spammeurs. Je ne sais pas dire si beaucoup d’entre eux utilisent des serveurs standard de mails. Ceux qui n’ont pas prévu le coup en tout cas, ils passent aussi à la benne. Les autres, je ne sais pas s’ils perdent du temps à renvoyer la purée alors que des gens mal protégés, il y en a tant d’autres…
Alors, en attendant que les zombies prennent en charge correctement le protocole et fasse des contournements réseaux compliqués (impossible ?), le greylisting peut vous aider.

Léger pré-requis sur les backups MX

Dernière petite remarque en préambule : il faut que tous vos serveurs frontaux (donc les backups MX) implémentent le greylisting !!! Donc oubliez les backups gracieusement offerts par votre fournisseur/hébergeur etc. En général ils ne le font pas. Si vous avez un tel backup MX – par pseudo-sécurité – il est en général déclaré de faible priorité et c’est justement celui qui est d’abord visé par les envois de spammeurs car on n’a moins souvent la main dessus. S’il ne greyliste pas, alors il enverra tout à votre MX principal qui acceptera sans broncher. Le greylisting ne servira pas à grand chose dans ce cas.
(Tiens, ça me fait penser à une technique qui consiste à utiliser un serveur inexistant comme MX de plus faible priorité. Faudra que je teste ça un jour. Si quelqu’un a un retour, je suis preneur)

Graphiques après plusieurs semaines d’utilisation

Plutôt qu’un long discours, quelques dessins. Je vous laisse deviner la date de mise en place…

Sur le frontal (MX primaire) :

Et sur le backend (qui identifie les spams une fois le mail accepté) :

En chiffres

Avec quelques chiffres moyens pris avant et après le greylisting (ceux sur le graphe sont pris “pendant” la mise en place, donc une moyenne d’avant/après, pas terrible), ça donne ça :
- Sur le frontal, avant, on recevait environ 9,5 msg/min et on rejetait 1/3 (tentatives d’openrelay, destinataires bidon etc). Maintenant, on en reçoit 3,2 par minute, toujours 1/3 de rejet pour les mêmes motifs.
- Sur le backend du coup, il y a une sacrée chute d’occupation CPU par “spamd” et on identifie 0,6 msg/min contre 6 par minute avant (même taux de faux-positifs ou d’oubli, à savoir presque nul).
- En une semaine, ce ne sont pas moins de 137000 “serveurs” (zombies) qui ont été greylistés, avec des charmants noms comme :

         0x50a1511f.hknxx3.adsl-dhcp.tele.dk[80.161.81.31] 2 Time(s)
         0x50a403bf.abnxx10.adsl-dhcp.tele.dk[80.164.3.191] 2 Time(s)
         103.95.119-80.rev.gaoland.net[80.119.95.103] 4 Time(s)
         12-208-209-2.client.mchsi.com[12.208.209.2] 2 Time(s)
         12-219-39-94.client.mchsi.com[12.219.39.94] 2 Time(s)
         124-171-184-145.dyn.iinet.net.au[124.171.184.145] 2 Time(s)
         129-28-235-201.fibertel.com.ar[201.235.28.129] 2 Time(s)
         131.201.218.87.dynamic.jazztel.es[87.218.201.131] 2 Time(s)
         131.206.50.60.cbj04-home.tm.net.my[60.50.206.131] 2 Time(s)
         1434933186.ip2long.net[85.135.87.194] 2 Time(s)
         149.pool85-49-8.dynamic.orange.es[85.49.8.149] 2 Time(s)
         1503021874.dhcp.dbnet.dk[89.150.75.50] 4 Time(s)
         152-60.go.evo.bg[85.217.152.60] 2 Time(s)
         156-90-99-58-T-tdtv.tinp.net.tw[58.99.90.156] 2 Time(s)
         167-68-246-201.adsl.terra.cl[201.246.68.167] 2 Time(s)
         168-226-244-166.mrse.com.ar[168.226.244.166] 2 Time(s)
...
         adsl-67-114-84-118.dsl.lsan03.pacbell.net[67.114.84.118] 2 Time(s)
         adsl-68-23-4-190.dsl.ipltin.ameritech.net[68.23.4.190] 2 Time(s)
         adsl-69-209-147-42.dsl.sfldmi.ameritech.net[69.209.147.42] 2 Time(s)
         adsl-69-209-154-96.dsl.sfldmi.ameritech.net[69.209.154.96] 2 Time(s)
...
         host234-234-static.116-81-b.business.telecomitalia.it[81.116.234.234] 2 Time(s)
         host241-167-dynamic.19-79-r.retail.telecomitalia.it[79.19.167.241] 2 Time(s)
         host246-209-dynamic.15-87-r.retail.telecomitalia.it[87.15.209.246] 2 Time(s)
         host248-13-dynamic.1-87-r.retail.telecomitalia.it[87.1.13.248] 2 Time(s)
...
         pool-71-241-246-243.washdc.fios.verizon.net[71.241.246.243] 2 Time(s)
         pool-71-244-163-181.chi01.dsl-w.verizon.net[71.244.163.181] 2 Time(s)
         pool-71-246-128-243.aubnin.fios.verizon.net[71.246.128.243] 2 Time(s)
         pool-71-251-115-130.tampfl.fios.verizon.net[71.251.115.130] 2 Time(s)
         pool-71-251-140-235.cmdnnj.east.verizon.net[71.251.140.235] 2 Time(s)
         pool-71-252-137-81.dllstx.fios.verizon.net[71.252.137.81] 2 Time(s)
         pool-71-99-87-26.tampfl.dsl-w.verizon.net[71.99.87.26] 6 Time(s)
...
         ppp83-237-30-117.pppoe.mtu-net.ru[83.237.30.117] 2 Time(s)
         ppp85-140-146-212.pppoe.mtu-net.ru[85.140.146.212] 2 Time(s)
         ppp85-140-21-109.pppoe.mtu-net.ru[85.140.21.109] 2 Time(s)
         ppp85-140-43-193.pppoe.mtu-net.ru[85.140.43.193] 2 Time(s)
         ppp85-141-174-160.pppoe.mtu-net.ru[85.141.174.160] 4 Time(s)
...
         unknown[116.22.163.196] 6 Time(s)
         unknown[116.45.106.170] 2 Time(s)
         unknown[117.12.65.40] 4 Time(s)
...

- 

Conclusion

N’hésitez pas, apt-get install postgrey, modif du fichier main.cf et reload de postfix. Ca prend 3 minutes et ça envoi du gros !