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 :
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.
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 :
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.
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'authentification1) de pouvoir réagir à de trop nombreuses tentatives ratés d'authentifications, soit :
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.