La journalisation, ou plus communément appelée les logs, est un composant important du système d'information. Sa nécessité se décompose en trois points :
il permet tout d’abord de vérifier qu’il n’y a aucune erreur de configuration sur vos services,
il permet de vérifier qu’il n’y a pas de comportements anormaux de la part des utilisateurs,
il fournit la matière première pour une autopsie en cas de compromission ou de crash système.
Lorsque les constructeurs automobiles installent de nouveaux composants sur leurs produits, ils usent par la suite de crash-tests afin de s’assurer de l’efficacité de ceux-ci. Pour la sécurité de votre SI, il en va de même. Lorsque vous installez un service serveur, vous avez l’obligation de lui faire subir un test de configuration, afin de laisser échapper le moins possible de faiblesses. Vous trouverez entre autres quelques outils dédiés à cet usage dans l’activité suivante de cette même séquence. Pour ce qui nous concerne, il est obligatoire de s’assurer que le syslog que vous avez configuré est bien en mesure de remonter les alarmes que vous lui avez demandé.
Dans ce but, une petite commande, logger, a été écrite pour envoyer les messages et ainsi vous assister dans votre test. Comme vu dans le cours sur syslog, il existe différentes facilités de log. Vous les retrouvez ici : auth, authpriv, cron, daemon, ftp, kern, lpr, mail, news, security (déprécié par auth), syslog, user, uucp, local0, local1, local2, local3, local4, local5, local6, local7.
Chacune de ces facilités ou rubriques peut recevoir un niveau d’alerte différent : alert, crit, debug, emerg, err, error (déprécié par err), info, notice, panic (déprécié par emerg), warning, warn (déprécié par warning).
Exercice : Écrivez un script qui teste toutes les rubriques décrites ci-dessus avec chacun des niveaux d’alerte qui existent.