Sommaire
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. Ce mail contient donc non pas un récapitulatif, mais un ensemble de lignes de logs que logcheck trouve étranges (à problème). Il faut donc correctement le configurer pour qu'il n'envoie effectivement que les lignes à problème, et pas les lignes ordinaires (du genre : "progfou vient de se connecter au système", alors qu'on sait que progfou se connecte au système tous les jours).
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 ! C'est dans ce répertoire qu'il faut créer les fichiers contenant les expressions régulières, filtres permettant d'éliminer les lignes de logs qu'on ne souhaite pas recevoir.
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
Si votre fichier de règles est local_rules, la commande egrep -f local_rules /var/log/syslog vous permet de voir ce que votre filtre capture, et donc va éliminer dans le mail que logcheck vous envoie.
inspirez-vous des filtres déjà existants : En général, le debut des filtres existants précisent juste la date et le nom du serveur, le début peut donc ne pas être modifié. On peut cependant être plus explicite en mettant directement le nom du serveur. Exemple : Si mon serveur s'appelle mail-dakar, je peux bien remplacer \w{3} [ :0-9]{11} [._[:alnum:]-]+ par \w{3} [ :0-9]{11} mail-dakar
- 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)Autres exemples :
root@mail-dakar:/etc/logcheck/ignore.d.server# cat local_rules
^\w{3} [ :0-9]{11} mail-dakar named\[[0-9]+\]: client .* query \(cache\) './NS/IN' denied$
^\w{3} [ :0-9]{11} mail-dakar spamd\[[0-9]+\]: spamd: using default config for (exim|nobody): /var/spool/exim4/user_prefs $
^\w{3} [ :0-9]{11} mail-dakar spamd\[[0-9]+\]: Use of uninitialized value in concatenation \(\.\) .*$
^\w{3} [ :0-9]{11} mail-dakar spamd\[[0-9]+\]: .*skipping greylisting call $
Quelques petites explications :
- Première ligne :
. Du caractère ^ à {11} permet de relever la date écrit de cette manière : Feb 16 10:10:04
. mail-dakar named : c'est une chaîne normale
. \[[0-9]+\]: : donne des numéros (de processus)
. Le reste de la ligne permet de capturer des requêtes DNS refusées
- Deuxième ligne : Seule chose à expliquer vient des parenthèses qui permettent à ce niveau de la chaîne de choisir soit exim, soit nobody.
Une utilisation : projet de centralisation et d'analyse des log systèmes
Dans le cadre du projet de centralisation des logs, partie intégrante du projet Supervision des systèmes centraux à Montréal :