Les logs sont l’élément essentiel de toute administration de systèmes et de réseaux. Ils permettent d’obtenir des informations concernant l’état des services, les diverses échecs, pannes, informations de comportement, qu’ont décidé de rendre visible les développeurs. Dans le monde Linux, les logs sont nettement plus poussés que dans le monde Windows. Ils sont le point clé de la compréhension de tout service.
Les logs sont stockés conventionnellement dans un dossier bien spécifique: /var/log, où ils sont répartis dans diverses fichiers/répertoires. La gestion des logs est effectuée par un démon que l’on appelle le syslog, par exemple rsyslog (par défaut sous Debian), syslog (version basique sur openSuse et redhat, ou encore syslog-ng.
Certains fichiers de logs sont des clés de voûte de la compréhension du comportement du système. Il s’agit de /var/log/syslog, qui contient les informations sur les services tournant sur la machine, de auth.log qui recence tous les problèmes d’authentification (PAM, SSH, …) ou encore de kern.log qui correspond aux messages provenant du noyau linux. Les services ont également un log propre qui est généralement un fichier ou un ensemble de fichiers contenu dans un répertoire du nom du service.
Les logs ont généralement des niveaux de sévérité (DEBUG, INFO, WARN, CRIT, …) qui correspondent au niveau de séverité du message qu’il fournit.
Conformément à la loi du 23 janvier 2006 du code des postes et communications électroniques (vous pourrez le lire ici), les administrateurs et ingénieurs systèmes ont pour obligation de garder une trace écrite non altérée des connections et des utilisations de leur réseau par les employés de l’entreprise dont ils ont la charge. Ces logs doivent être stockés sur un serveur extérieur, en théorie un serveur sur lequel vous n’aurez jamais la main, mais en partique c’est quasiment impossible, qui sera chargé de centraliser l’ensemble des logs de connexion et de navigation de vos utilisateurs. En cas d’enquête judiciaire, si une attaque de type terroriste ou contre la nation est véhiculée via votre réseau, vous devez avoir ses logs sous peine d’être sanctionnées.
Les logs doivent être conservés durant 1 an glissant au maximum. Ceux-ci sont consultable à volonté durant cette période mais n’auront de valeur juridique pour l’entreprise que durant les 6 mois suivant l’action enregistrée. Les logs ne peuvent être demandés aux divers services informatique de force sans l’accord d’un juge assermenté.
Cette problématique juridique, nous conduit donc sur ce tutoriel. Comment mettre en oeuvre un serveur de logs sécurisé respectant l’ensemble des conditions légales permettant à votre entreprise d’être “sur les rails”. Serveur de logs Installation
Nous allons ici utiliser le paquet syslog-ng pour sa puissance et le paquet logrotate pour la fonction de glissement des logs.
apt-get install syslog-ng logrotate
Nous allons tout d’abord configurer le glissement. Ouvrez le fichier /etc/logrotate.conf
monthly
rotate 12
create
/var/log/* {
monthly
rotate 12
create 640 root adm
compress
}
include /etc/logrotate.d
Ce fichier de configuration définit le logrotate tous les ans, avec création du fichier une fois supprimé au bout d’un an. La section /var/log/* définit des droit particulier sur les fichiers de ce répertoire. La directive enrichie create permet de définit les droits et propriétaires du fichier. La directive compress définit la compression du fichier une fois la taille de celui-ci trop grande.
Vous trouverez également dans le dossier logrotate.d des scripts particuliers à chaque service qu’il faudra reconfigurer pour faire perdurer 1 an.
Configurons maintenant le service syslog-ng. Ouvrez le fichier /etc/syslog-ng/syslog-ng.conf et supprimez l’ensemble du contenu pour refaire une configuration au propre
options { long_hostnames(on); flush_lines(0); use_dns(no); use_fqdn(no);
owner("root"); group("adm"); perm(0640); stats_freq(0);
bad_hostname("^gconfd$");
};
source s_src { unix-dgram("/dev/log"); internal();
file("/proc/kmsg" program_override("kernel"));
};
source s_net { udp(port(65001)); };
destination net_auth{ file("/ARCHIVED-LOGS/$HOST/$YEAR/$MONTH/$DAY/auth.log" create_dirs(yes)); };
destination local_logs{ file("/var/log/syslog" create_dirs(yes)); };
filter f_debug { match("debug"); }
filter f_auth { not filter(f_debug); };
log { source(s_net); filter(f_auth); destination(net_auth);};
log { source(s_src); destination(local_logs);};
Les options en début de fichier permettent de définit l’utilisation des noms DNS des machines, le propriétaire des fichiers de logs et les permissions associées à celui ci.
Les logs avec syslog-ng sont managés par 3 catégories spécifiques:
La source est l’endroit d’où proviennent les logs. Dans le cas de s_src il s’agit des logs de la machine. Nous les enverrons ici vers le syslog classique. Pour s_net, ces logs seront archivés et reçus sur le port 65001 qu’écoutera le serveur de logs. Il est conseillé d’utiliser UDP pour gagner du temps au vu du nombre d’entrées qui vont transiter sur le réseau.
La destination définit le lieu où vont être écrits les logs. Ici nous utilisons des variables syslog-ng afin de répartir les logs dans des répertoires correspondant à des machines, puis par année, mois, jour. L’option create_dirs doit être positionnée à yes afin d’éviter à avoir à créer les dossiers soit même à la main chaque jour.
Le filtre va permettre de pouvoir interragir avec le log pour le classer de façon plus précise. Notre filtre f_auth va vérifier que le log est bien un log d’authentification qui n’est pas un log de debug pour le mettre dans auth.log. La directive match permet de définir le filtre à vrai si la chaîne est trouvée dans le log et est très pratique, par exemple pour apache afin de séparer les diverses erreurs HTTP.
Pour terminer, la directive log va prendre une ou plusieurs sources, filtrée ou non par un ou plusieurs filtres et l’envoyer vers une ou plusieurs destinations.
La puissance du syslog-ng réside dans la hiérarchisation logique de vos logs. Avec ces 3 éléments vous avez de quoi logguer de façon efficace vos serveurs. Vous pouvez bien entendu écouter plus de ports pour pouvoir hiérarchiser vos logs encore plus efficacement en définissant quel service utilisera quel port.
Maintenant étudions le comportement niveau client.
Sur vos switches CISCO, Dell… la manipulation est très simple
logging 10.0.0.250
Le paquet sera envoyé en UDP sur le port 514
Maintenant étudions sur les machines Linux, installez le paquet syslog-ng s’il n’y est pas puis ouvrez le fichier /etc/syslog-ng/syslog-ng.conf
options { long_hostnames(off); flush_lines(0); use_dns(no); use_fqdn(no);
owner("root"); group("adm"); perm(0640); stats_freq(0);
bad_hostname("^gconfd$");
};
source s_src { unix-dgram("/dev/log"); internal();
file("/proc/kmsg" program_override("kernel"));
};
source s_apache2 { file("/var/log/apache2/access.log"); };
destination log_server {udp("serveurdelogs.lan" port(65001)); };
destination log_local_server { file("/var/log/local_syslog };
destination log_local_apache { file("/var/log/apache2/local_access.log};
log { source(s_src); destination(log_server); destination(log_local_server)};
log { source(s_apache2); destination(log_server); destination(log_local_apache)};
Les directives sont similaires à celles du serveur de log, seul changement, la destination est un serveur en UDP sur le port 65001 comme le définit la directive:
udp("serveurdelogs.lan" port(65001));
Nous stockons une copie en local pour la simplicité d’utilisation, de surcroît, mais avec un nom différent. Pourquoi un nom différent ? Si vous ne faîtes pas ceci vous allez engendrer une boucle infinie de lecture écriture qui va saturer l’ensemble de la place disponible sur votre disque dur en moins de 10 minutes.
Et on termine par le redémarrage du service
service syslog-ng restart
Vous savez désormais manipuler le syslog-ng et stocker vos logs de manière centralisée.