Séance 6 : La gestion des traces (logs)
Objectifs :
Identifier les différents outils de sauvegarde sous GNU/Linux
Configurer le démon syslogd
Appliquer les outils de gestion des journaux sous GNU/Linux
Plan :
I.
Introduction
II. Configuration et fonctionnement
III. Outils de traitement de journaux
I. Introduction :
La journalisation est une part extrêmement importante de la sécurité et c’est un des seuls outils à
notre disposition pour la surveillance du système. Elle est un complément à la protection et c’est un
des piliers de la détection d’intrusion. On ne peut se contenter d’une détection d’intrusion
cantonnée à l’entrée du réseau. Les pirates réussissent parfois à entrer, ou ils peuvent être internes à
l’organisme. Une bonne gestion de la journalisation couplée à un logiciel de réponse automatique va
permettre une détection rapide des problèmes et faciliter l’étude postmortem de l’intrusion.
La journalisation sert toutefois essentiellement à la surveillance du système. C’est le principal outil
dont dispose l’administrateur. Il faut toutefois trouver le bon compromis, car la journalisation utilise
des ressources CPU et disque.
Une journalisation importante est parfois nécessaire lors de l’implantation d’un nouveau service,
mais il faut bien vérifier qu’elle est nécessaire par la suite. On notera également que la
journalisation des événements sert également a des fins de statistiques ou de facturation. Sur les
systèmes UNIX/Linux il existe un démon principal gérant la journalisation d’événement. C’est le
démon Syslogd. Ce démon reçoit des messages événementiels de la part de clients (locaux ou
distants) Syslog (par exemple named, sendmail, etc..) ou du démon Klogd qui est chargé d’écouter
les messages du noyau et de les envoyer au démon Syslogd pour que celuici les journalise suivant
son fichier de configuration. Dans ce dossier nous nous focaliserons principalement sur l’étude du
démon Syslogd (communément appelé Syslog). Klogd ne sera donc pas étudié dans les détails. Au
niveau réseau, on précisera que le démon Syslog est un processus de niveau applicatif (couche 7
modèle OSI) utilisant comme port quand le serveur syslog est configuré pour écouter sur le réseau
le port UDP 514 (protocole Syslog).
II. Configuration et fonctionnement
1. Le programme syslogd :
Le programme Syslogd est en général lancé au démarrage tout comme le programme klogd (qui
travaille en général avec syslogd). Tous deux sont présents dans les répertoires rcX.d/ sous forme de
liens vers les scripts de démarrage des services (S10syslogd).
Nous allons à présent expliquer et détailler le fonctionnement du service syslogd. Le binaire syslogd
présent dans /sbin/ est lancé par le script de démarrage /etc/init.d/sysklogd lorsque celuici est
invoqué avec un argument de type start ou restart. Au démarrage du programme, le fichier de
configuration /etc/syslog.conf qui est le fichier de configuration principal de syslogd est lu.
Le paquet (ou fichiers installés après une compilation) sysklogd contient un certain nombre de
fichiers (binaires, fichiers de configurations, fichier de documentations, etc..) .
On voit dans ces fichiers outre le binaire principal /sbin/syslogd, le fichier binaire /usr/sbin/syslogd
listfiles et /usr/sbin/syslogfacility. Ils constituent les 3 fichiers binaires de l’ensemble syslog.
Le binaire syslogdlistfiles a pour but de sélectionner le fichier de logs le plus adapté a une rotation
(en général le fichier le plus volumineux) dans les fichiers de logs listés dans /etc/syslog.conf. Ce
binaire est lancé par les scripts /etc/cron.daily/sysklogd et /etc/cron.weekly/sysklogd qui s’exécutent
a période constante. Le fichier binaire syslogfacility sert a installer ou désinstaller une nouvelle
priorité a un message dans le fichier de configuration syslog.conf.
Il est à noter que le démon syslogd par défaut n’écoute pas sur le réseau et reçoit donc des messages
événementiels en local à l’aide d’une socket Unix domain. Cette socket est en réalité un fichier
spécial appelé FIFO se comportant comme une liste d’attente dans lequel le démon va lire. Il s’agit
en réalité du fichier /dev/log. Un programme C peut donc envoyer des messages à Syslogd en
écrivant directement dans ce fichier. Il est cependant possible de modifier le comportement par
défaut du processus en lui demandant d’écouter les messages sur le réseau via le protocole syslog en
utilisant le port UDP 514. Pour configurer cela, on aura besoin de rajouter l’option –r lors du
lancement du script de démarrage sysklogd ou alors, on modifie le fichier de configuration
/etc/default/syslogd ou le script /etc/init.d/sysklogd en rajoutant l’option –r à la variable SYSLOGD
#! /bin/sh
/etc/init.d/sysklogd: start the system log daemon.
Publicité
PATH=/bin:/usr/bin:/sbin:/usr/sbin
pidfile=/var/run/syslogd.pid
binpath=/sbin/syslogd
test x $binpath || exit 0
Options for start/restart the daemons
For remote UDP logging use SYSLOGD="r"
#
SYSLOGD="r"
Pour modifier les fichiers de configuration qui appartiennent à root, il faut obligatoirement avoir les
droits de superutilisateur. Les fichiers de configuration ont les droits de lecture uniquement pour
tout le monde sauf root qui a en plus les droits d'écriture. Les fichiers de configuration cron ont tous
les droits en mode root, le droit x en plus pour les utilisateurs du groupe root, et les autres n’ont
toujours que le droit r. Pour ce qui concerne les binaires et les fichiers scripts, root a toujours tous
les droits, les membres du groupe root ont les droits x et r et les autres n’ont que le droit d'exécution.
2. Configuration de /etc/syslog.conf
Le fichier /etc/syslog.conf est le principal fichier de configuration du démon syslogd.
Syntaxe générale :
Chaque ligne de ce fichier indique le type du message (appelé Service ou Facility en anglais), le
niveau de gravité (appelé Priorité) et sa Destination (fichier, terminal,...).
Par exemple, la ligne suivante permet d’envoyer les messages d’information des programmes de
messagerie dans le fichier «mail.info» :
mail.info /var/log/mail.info
Chaque ligne est de la forme : Service.Priorité Destination
➢ Service correspond au type de programme (Démon, Noyau,...) et doit être l’un de ces mots
clés : auth, authpriv, cron, daemon, kern, lpr, mail, mark, news, security (identique à auth),
syslog, user, uucp et local0 à local7.
➢ Priorité représente le niveau de gravité du message et doit être l’un de ces mots clés :
debug, info, notice, warning, warn (identique à warning), err, error (identique à err), crit, alert,
emerg, panic (identique à emerg). ATTENTION : En indiquant un niveau, syslog enverra les
messages de ce niveau et tous les messages des niveaux plus importants. Donc en mettant «debug»,
syslog enverra tous les messages (de debug à panic).
➢ Destination représente la destination du message est peut être un chemin vers un fichier
texte (ex : /var/log/mail.info) ou le nom d’une console pour envoyer les messages à l’écran (ex :
/dev/tty8) ou un autre serveur (ex : @MonAutreServeur).
Remarque : Chaque programme détermine les «Services» et les «Priorités» qu’il utilise et il est
rarement possible de les modifier. Par exemple, les programmes Postfix et Fetchmail utilisent le
Service mail
Le signe « ; » pour séparer plusieurs « Services »
Il est possible de mettre plusieurs services pour une même destination en utilisant le « ; » :
Service1.Priorité1; Service2.Priorité2 Destination
Le signe « , » pour plusieurs « Services » avec une même « Priorité »
Il est possible d’indiquer plusieurs « Services » pour le même niveau de « Priorité » avec le signe
« , ». La ligne suivante envoie dans le fichier « mail_news » les messages en provenance des
« Services » « mail » et « new » dont la « Priorité » est supérieure ou égale à « info ». :
mail,news.info /var/log/mail_news
Le signe « = » pour ne traiter que la « Priorité » indiquée
Il est possible de n’envoyer que les messages d’une seule « Priorité » (sans les « Priorités » de
niveaux supérieures) avec le singe « = ». Exemple :
mail.=err /var/log/mail.err
Le signe « * » pour traiter toutes les « Services »
La commande suivante permet d’envoyer les messages d’erreurs de toutes les « Services » dans le
fichier « error »
*.error /var/log/error
Le signe « * » pour traiter toutes les « Priorités »
Le signe « * » permet d’indiquer que l’on souhaite toutes les « Priorités » (Le résultat est le même
qu’en mettant « debug », mais c’est plus lisible). Exemple :
mail.* /var/log/mail
Le signe « * » pour envoyer des messages sur toutes les consoles ouvertes
La ligne suivante, permet d’envoyer tous les messages d’erreurs sur toutes les consoles ouvertes
grâce au signe « * » placé en destination à la fin de la ligne :
*.alert *
Publicité
Le signe « ! » pour exclure les niveaux supérieurs ou égaux à la « Priorité » indiquée
Le signe « ! » permet d’indiquer que l’on souhaite exclure le niveaux indiqué et tous les niveaux
supérieurs à celui indiqué. La ligne suivante, permet d’envoyer dans le fichier « mail » tous les
messages sauf ceux supérieurs ou égaux à la « Priorité » « warn » :
mail.*;mail.!warn /var/log/mail
La ligne suivante permet d’envoyer dans le fichier « mail » tous les messages supérieurs ou égaux à
la « Priorité » « notice » et inférieure à la « Priorité » « crit » :
mail.notice;mail.!crit /var/log/mail
Le signe « » pour améliorer les performances en écriture
Le signe « » est utilisé devant les chemins de fichiers les moins critiques pour améliorer les
performances en écriture au risque de perdre des données en cas de crash du système (pas de
synchronisation des fichiers). Cette ligne enregistre tous les messages de la « Service » « mail »
dans le fichier « mail » :
mail.* /var/log/mail
Le signe « \ » pour écrire une instruction sur plusieurs lignes
La commande suivante écrite sur deux lignes grâce au signe « \ », permet d’envoyer tous les
messages de mails ou de news dans le fichier « mail_news » :
mail.*;\
news.* /var/log/mail_newsEnvoyer les logs dans une console
La ligne suivante permet d’envoyer tous les logs dans la console « tty8 » (CTRL+ALT+F8) :
*.* /dev/tty8
Les lignes suivantes permettent d’envoyer les logs des mails dans le fichier « mail » et en même
temps sur la console « tty8 »
mail.* /var/log/mail
mail.* /dev/tty8
Le signe @ pour envoyer les logs sur un autre serveur
La ligne suivante permet d’envoyer tous les logs sur un autre serveur nommé «pgdebian» :
*.* @pgdebian
Redémarrer le démon
A chaque modification du fichier «/etc/syslog.conf», il faut redémarrer le démon :
/etc/init.d/sysklogd restart
Lors du démarrage, le démon créera les nouveaux fichiers de logs, si ceuxci n’existent pas.
Mettre syslogd à l’écoute du réseau
Pour pouvoir centraliser les logs en provenance d’autres serveurs ou routeurs, il faut mettre le
démon « syslogd » à l’écoute du réseau.
Pour cela, il faut ajouter le paramètre « r » sur la commande de démarrage du démon.
Sur Debian testing, il faut modifier le fichier « /etc/default/syslogd » et renseigner la variable
« SYSLOGD » comme indiquée cidessous :
SYSLOGD="r"
Il faut aussi configurer les routeurs ou les autres serveurs pour que ceuxci exportent leurs logs vers
le serveur principal.
Exporter des logs d’un autre poste sous Linux
Pour exporter tous les logs d’un poste vers un serveur appelé par exemple « pgdebian », il suffit
d’ajouter la ligne suivante dans le fichier « /etc/syslog.conf » de ce poste :
*.* @pgdebian
La ligne suivante permet de n’envoyer que les messages d’erreurs :
*.notice{{ }}@pgdebian
Exporter les logs d’un poste Windows
Pour qu’un système Windows (NT, 2000,..) exporte ses logs sur un serveur syslog sous Linux, il faut
installer le programme « ntsyslog » (http://ntsyslog.sourceforge.net/).
La commande suivante, permet d’installer le service sur le poste Windows :
ntsyslog install
Le programme «NTSyslogCtrl.exe» permet de configurer le service pour indiquer le serveur et les
logs à envoyer sur celuici.
Quelques commandes pour consulter les logs
La commande suivante permet de voir les 10 dernières lignes du fichier « syslog »
tail /var/log/syslog
La commande suivante, permet de voir les 200 dernières lignes :
tail 200 /var/log/syslog
La ligne suivante permet de voir les 10 dernières lignes avec une actualisation en temps réel :
tail f /var/log/syslog
Publicité
Cette commande retourne les lignes du fichiers « syslog » contenant la chaîne de caractères
« LeMotif » :
cat /var/log/syslog | grep i LeMotif
En combinant les deux commandes précédentes, il est possible par exemple d’avoir en temps réel,
les logs de fetchmail :
tail f /var/log/syslog | grep fetchmail
Pour avoir uniquement les logs du noyau Linux au démarrage du poste :
dmesg
Utilisation de syslogng :
Le service syslog présente au moins deux défauts : la sécurité et la non discrimination des sources.
La non discrimination des sources d'émission de messages de journalisation est beaucoup plus
gênante du point de vue exploitation.
L'utilisation de syslogng permet de traiter cette difficulté simplement. Le démon syslogng se
substitue complètement au démon syslog précédent.
La grande différence se situe au niveau du fichier de configuration du service : /etc/syslog-
ng/syslog-ng.conf. Pour chaque catégorie de journalisation, on doit composer avec une
définition de source, de filtre et de destination. Voici un exemple reprenant le cas du commutateur :
Définition d'une source
source net { # journalisation via eth2 -> commutateur sw1 udp(ip(192.168.2.1)); };
Définition d'un filtre
filter f_sw1 { host(192.168.2.2) and level(info,notice,warn,crit,err); };
Définition d'une destination
destination d_net_devices { file("/var/log/$HOST.log" owner("root") group("adm") perm(0640)); };
Utilisation des trois définitions
log { source(net); filter(f_sw1); destination(d_net_devices); };
L'application de cette configuration entraîne la création d'un fichier
/var/log/192.168.2.2.log qui reçoit tous les messages du commutateur sw1 qui a
l'adresse IP 192.168.2.2. Le fichier de destination est créé avec un nom correspondant à
l'adresse IP de l'équipement parce qu'aucun service DNS n'a été configuré. En exploitation réelle, on
installe généralement un service DNS dédié au périmètre de gestion de l'infrastructure. Dans ce cas,
les fichiers de journalisation portent le nom d'hôte de l'équipement.
L'ajout de tout nouvel équipement avec un autre nom et une autre adresse IP entraînera le création
d'un nouveau fichier de journalisation. On pourra alors traiter les alertes séparément pour chaque
équipement.
III. Outils de traitement de journaux :
La problématique du traitement des journaux bute sur «la motivation très limitée» des responsables
d'exploitation. On entend trop souvent que la lecture des journaux est fastidieuse et inutile. Pourtant,
on ne compte plus les exemples d'intrusions qui auraient pu être évitées facilement si les logs
avaient été consultés régulièrement.
L'offre des outils de traitement de logs est très diverse. Voici deux propositions d'outils choisis avec
un parti pris évident : imposer la lecture des journaux via le courrier électronique.
Logwatch
logwatch émet un rapport toutes les 24h synthétisant les évènements par service. Dans le
contexte de ce document, on active un service correspondant à tous les journaux émis par les
équipements réseau. La grande force de logwatch, c'est la sommation des entrées répétitives
qui optimise la taille du rapport.
Logcheck
logcheck est un outil conçu à partir des paquets Debian GNU/Linux. Il émet un rapport toutes
les heures en fonction de trois niveaux d'utilisation : poste de travail, serveur et
«paranoïaque». Plus on avance vers la «paranoïa», plus le nombre de messages retenus est
important. Pour chaque niveau d'utilisation, la synthèse des évènements comprend trois
niveaux de priorité de traitement : alerte, sécurité et système. Dans le contexte de ce
document, on ajoute les fichiers de journalisation des équipements réseau à la liste des fichiers
traités par logcheck. Après la lecture de quelques rapports, on est capable d'éditer ses propres
règles de sélection en s'inspirant des règles existantes pour les autres services du système. La
grande majorité des opérations de sélection effectuées par logcheck sont prédéfinies par des
utilisateurs très expérimentés : les responsables des paquets. C'est un avantage considérable
pour les débutants. On gagne ainsi un temps très important dans l'apprentissage du travail
d'analyse.