LogWatch

logwatch est un analyseur de log. Exécuté chaque jour, il envoie par courriel un bilan des logs de la machine. Cela présente un interêt "global", mais ne permet pas vraiment de suivre la vie de son serveur en détail, juste d'avoir une vue d'ensemble.

LogCheck

logcheck est complement indispensable si on veut vraiment suivre ses serveurs.

Le principe de base est le suivant : il analyse tous les nouveaux logs depuis son dernier lancement. Il fait le tri dans les lignes de log, en retirant toutes les lignes "habituelles" (il faut configurer et adapter cela). Il envoie alors le résultat de ce tri par mail.

logcheck est donc assez complexe à mettre en place (au début) car il fonctionne sur le principe de "on notifie tout ce qui n'est pas habituel". Il faut donc réflechir à la notion "d'habituel".

Cependant, au fur et à mesure de l'écriture des règles de filtrage, on apprend a bien connaitre les particularités de son système. Logcheck est donc un outil utile à double titre.

Installation de logcheck

Comme d'habitude : aptitude install logcheck

Attention : logcheck nécessite un MTA (agent de tranport de messagerie) car il doit envoyer des messages. Nous vous conseillons d'installer d'abord votre serveur de messagerie (Postfix de préférence, ou Exim sur une machine non dédiée au mail).

Configuration de base

La configuration de base se situe dans /etc/logcheck/logcheck.conf. On doit notamment y indiquer l'adresse de destination des messages du type SENDMAILTO=root@quelquepart.org. Il faut aussi configurer le niveau d'alerte qu'on veut détecter : le mode "server" proposé par défaut est une bonne base de départ : REPORTLEVEL="server".

Ensuite il faut donner la liste des fichiers à surveiller dans /etc/logcheck/logcheck.logfiles.

Enfin on peut éventuellement adapter la fréquence de lancement de logcheck dans /etc/cron.d/logcheck. Par défaut logcheck est lancé une fois par heure ainsi qu'à chaque redémarrage.

la variable INTRO=0 permet d'éliminer les quelques lignes de blabla au début de chaque mail, qu'on fini sinon par connaître par coeur même sans le vouloir.

Les filtres

Les filtres sont des expressions rationnelles (regular expressions ou regex). Ils sont placés dans des fichiers, classés dans des sous-répertoires de /etc/logcheck. Un répertoire par fonction :

• cracking.d : contient les filtres indiquant les erreurs graves à rapporter. Son petit frère cracking.d.ignore permet de supprimer les faux positifs : on y indique les erreurs qui n'en sont pas.

• violations.d : même chose, mais avec les erreurs "classiques".

• ignore.d.server : les filtres caractérisant toutes les lignes de logs à ignorer. C'est dans ce répertoire que quasiment tout se passe !

S'adapter au fur et à mesure : ajouter des filtres

Une fois que logcheck est installé, il va commencer à envoyer des tas de messages par mail (un par heure, contenant des logs qui ne sont pas forcément des erreurs).

Il faut déterminer quelles sont les lignes de logs qui ne sont pas des problèmes, et ajouter des filtres dans ignore.d concernant ces règles.

Ces filtres étant des expressions rationnelles, il faut un peu maîtriser le sujet : http://fr.wikipedia.org/wiki/Expression_rationnelle

Quelques idées :

• faites en sorte de définir une expression rationnelle la plus restrictive possible : il ne faut pas qu'une expression trop laxiste fasse que logcheck ignore tout un ensemble de lignes de log. Il ne doit ignorer que les lignes que vous avez repérées.

• utiliser les options -t et -o pour voir si vos filtres fonctionnent : # sudo -u logcheck logcheck -to

• inspirez-vous des filtres déjà existants
• demandez à la liste de discussion tech@ quand vous avez un doute : il faut vraiment éviter les faux positifs (ignorer une ligne de log qui représentait une anomalie).

• pour ne pas consommer trop de ressources machines pour l'analyse des expressions, écrire des expressions les moins ambigües possibles, et surtout, éviter au maximum les .*, que grep ne soit pas obligé d'aller jusqu'au bout de la ligne avant d'abandonner. écrire une ligne qui ne commence pas par le caractere ^ est puni de la peine de mort.

• mutualiser au maximum les régles en utilisant des (|), par exemple, s'il y a deux codes d'erreur à ignorer pour un même logiciel : ne pas faire deux lignes, une pour chaque cas, mais plutôt quelquechose du genre Erreur fatale : plus de (glaçons|pastis)

• surveiller l'espace libre de l'endroit (jesaisplusoù ? /tmp ??? à vérifier) où logcheck écrit ses fichiers temporaires : en cas de problème majeur qui rempli les logs, vous aller en plus avoir un problème d'espace libre sur cette partition là.

Quelques exemples de filtres

deux trois régles qui traînent sur smtp.sn.auf.org, pour éviter de spammer root+smtp@refer.sn :

root@mail-dakar:/etc/logcheck/ignore.d.server# cat auf
^\w{3} [ :0-9]{11} [._[:alnum:]-]+ chfn\[[0-9]+\]: changed user `[a-z0-9]+' information
^\w{3} [ :0-9]{11} [._[:alnum:]-]+ useradd\[[0-9]+\]: new user: name=[a-z0-9]+, UID=[0-9]+, GID=100, home=/home/[a-z0-9]+, shell=/bin/false
^\w{3} [ :0-9]{11} [._[:alnum:]-]+ usermod\[[0-9]+\]: change user `[a-z0-9]+' (password|expiration from `-?[0-9]+' to `1[0-9]+')
^\w{3} [ :0-9]{11} [._[:alnum:]-]+ dovecot-auth: \(pam_unix\) (check pass; user unknown|account .* has expired)
^\w{3} [ :0-9]{11} [._[:alnum:]-]+ kernel: APIC error on CPU0:
^\w{3} [ :0-9]{11} [._[:alnum:]-]+ snmpd\[[0-9]+\]: Connection from UDP/IPv6: \[(2001:4278:1002|2002:d59a:4141):ba0:10:196:1:10\]:
^\w{3} [ :0-9]{11} [._[:alnum:]-]+ named\[[0-9]+\]: client (.*: updating zone '.*/IN': update unsuccessful:|::ffff:.*: transfer of '.*/IN': AXFR-style IXFR started)