Les journaux systèmes, plus communément appellés logs, sont un point clés de la gestion d'un système Unix et encore plus particulièrement d'un serveur.

En effet, étant souvent l'un des seuls moyens d'obtenir des informations des programmes s'éxecutants en arrière-plan, que ce soit le noyau ou les differents services (démons), la compréhension du système de logs est un acquis indispensable à toute personne souhaitant se lancer dans l'aventure de l'administration d'un serveur sous un système Unix.

On trouvera en général les logs du système dans le dossier /var/log, chaque fichier dans ce dossier étant écrit par les differents services du systèmes pour y placer des informations.

Il existe pour un programme deux façon de générer des logs :

• soit en écrivant directement dans un fichier,
• soit en utilisant le programme syslog.

Il est assez rare qu'un service ne propose pas le choix entre les deux solutions, qui ont chacunes leurs avantages et leurs inconvénients.

• avantages de l'utilisation du démon syslog :
  • centralisation de la répartition des informations dans les differents fichiers de logs dans un seul fichier de configuration,
  • sécurité: seul l'utilisateur sous lequel tourne le daemon syslog à besoin d'avoir accès en écriture au fichier de log, ainsi en cas de faille ou de compromission du service, ce dernier ne sera pas dans la possibilité d'effacer ses propres logs,
  • l'on peut configurer syslog pour retransmettre directement les logs à une autre machine sur le réseau, utile pour garder des traces en cas de compromission de la machine,
  • grosse simplification de la gestion des droits sur les fichiers de logs ;

• avantages de l'écriture directe dans un fichier :
  • dans le cas d'une application générant une grande quantité de logs, il peut être plus pratique d'utiliser l'application pour rediriger les informations vers plusieurs fichiers distincts (les filtres de syslog n'étant pas forcément adaptés au tri de l'application en question).

Il est très fortement conseillé d'effectuer une copie en temps réel des logs vers une seconde machine. Pour cela l'usage d'un gestionnaire de logs omniscient est recommandé sur la machine. une configuration judicieuse d'un daemon tel que syslog est conseillé à ce sujet (associé à un renforcement des régles du firewall autours du port 514).

Le programme historique de gestion des logs sous les systèmes Unix s'appelle syslog. Il est encore installé par défaut sur nombre de distributions.

Ce démon reçoit les messages qui lui sont envoyés par les applications via la commande logger ou la fonction syslog(). Il permet ensuite de de diriger ces informations vers les differents fichiers selon un principe simple de filtres → destination.

Les 2 principaux filtres de syslog sont le niveau de gravité de l'information (de 0(Emergency) à 7(Debug)) et la « FACILITY », grossièrement le thème de l'information (noyau, syslog lui-même, information d'authentifications, système d'impression, etc …).

Les destinations possibles sont :

• l'écriture dans un fichier,
• le relai à un autre serveur syslog sur le réseau,
• pipe des informations à un programme.

Configuration détaillée: syslog.

Le programme syslog-ng (ng pour new generation) est un programme entièrement compatible avec le programme syslog, mais qui apporte également un certain nombre d'ajouts à celui-ci. Les filtres et FACILITIES de syslog pouvant souvent se réveler insuffisants et rendant peu lisibles des règles ne rentrant pas dans les cases des FACILITIES déjà prévues.

• au niveau des filtres :
  • utilisations d'expression régulières dans les filtres,
  • on peut filtrer directement sur le nom du programme, simplifiant souvent l'écriture de règles simples (1 service = 1 log),
  • utilisation de filtres avec conditions complexes (si A et B ou C mais PAS D alors E) 
• au niveau des destinations :
  • insertion directe dans une base de donnée MySQL via l'utilisation de templates,
  • envoie directe vers la console d'un utilisateur, que cette console soit un tty, un xterm ou une session ssh, syslog-ng se chargeant de trouver où est connecté cet utilisateur,
  • utilisation de variables dans la définition des destinations ($HOST,$DATE,etc …).

Configuration détaillée: syslog-ng.

L'une des premières chose à faire lorsque l'on tente de mettre en place un service, repérer dans la configuration où et comment cette application place ses logs. Les suivre au fur et à mesure de l'avancement de la mise en place, on ne le répètera jamais assez: quand ça marche pas, regardez les logs. Si vous n'avez pas assez d'infos dans les logs, augmentez le niveau de verbosité.

Il existe nombre d'outils permettant de genérer des rapports d'activité d'une ou plusieurs applications à partir des logs de celle-ci. De solutions généralistes avec système de plugins comme logwatch aux simples scripts shell en passant par des programmes spécifiques à une application, vous en trouverez pléthore sur la toile ou dans les dépôts de votre distribution.

Savoir ce qu'il se passe, c'est bien, y réagir c'est encore mieux. Il est indispensable, notement pour tout ce qui a trait aux questions d'authentification¹⁾ de pouvoir réagir à de trop nombreuses tentatives ratés d'authentifications, soit :

• si vous avez des utilisateurs dont les mots de passe ne sont pas nécéssairement choisies dans les règles de l'art ;
• même si les mots de passes sont en béton :
  • toutes ces tentatives, ça surcharge le serveur (et c'est parfois le seul but),
  • une faille peut toujours s'être glissé dans vos applications qui permette de réduire considérablement le nombre de tentatives nécessaire au brute-force.

Le plus connu des outils de ce type est fail2ban, écrit en python, très complet et livré avec de nombreuses règles pour de nombreuses applications. On peut également ajouter relativement facilement ses propres règles.

Il existe également plusieurs applications dédiés à la protection d'un serveur SSH, notement denyhost et ssh-guard.

Là encore, pour faire des statistiques précises de l'usage d'une application, ce sera généralement les logs qui serviront de matériel d'analyse. Vu la nature précise de la tâche, ce sont des outils spécifiques à chaque application qui seront chargés de cette tâche.

Voire la page sur les statistiques.

Bon, tous ces logs, ça s'entasse, ça se remplit et ça va finir par prendre de la place tout ça ! Il va de soi que vous n'allez pas conserver tous ces fichiers ad vitam æternam. Il va donc falloir faire le tri régulièrement, et virer les inutiles, archiver-compresser-backuper les vitaux, etc., etc.

Il est de plus nécessaire de faire tourner régulièrement les fichiers de logs afin que ceux-ci ne deviennent pas trop gros, ce qui peut entrainer un ralentissement des applications ayant à y accéder.

Et bien-entendu selon l'adage que si ce n'est pas automatisé ce ne sera pas fait, il existe pour cela le programme logrotate qui vous permettra de traiter vos logs automatiquement: rotation, archivage, compression, selon les critères précisés pour chaque fichier ou groupe de fichiers de log.

Configuration détaillée: logrotate.

Un autre programme à utiliser est aussi newsyslog.

Ceci dit «opérationnellement» parlant, il est conseillé d'avoir un petit script personnel (ou plusieurs) qui archive les logs du jour dans une arborescence séparée, qui en effectue la copie vers une seconde machine, et qui en effectue la sauvegarde sur un medium amovible (là : la bande magnétique est royale… mais il faut oser détenir un lecteur SCSI…).

Cette sauvegarde sur une autre machine pourra faire aussi l'objet d'une comparaison à la volée avec ce que cette seconde machine aura reçu en temps réel par discussion entre daemons syslogd.

Hormis les aspects techniques, il ne faut pas oublier certaines considérations légales, notamment tout ce qui concerne les obligations de conservations de certaines données de connexion.

Voir la page consacrée aux contraintes juridiques.