INSIA SRT 3 SYSLOG. Le protocol ● En tant que protocole, Syslog se compose d'une partie cliente et d'une partie serveur ● La partie cliente émet les informations.

Présentation au sujet: "INSIA SRT 3 SYSLOG. Le protocol ● En tant que protocole, Syslog se compose d'une partie cliente et d'une partie serveur ● La partie cliente émet les informations."— Transcription de la présentation:

1 INSIA SRT 3 SYSLOG

2 Le protocol ● En tant que protocole, Syslog se compose d'une partie cliente et d'une partie serveur ● La partie cliente émet les informations sur le réseau, sur le port UDP 514 ● Le serveur collecte l'information et se charge de créer les journaux. ● Centraliser les journaux d'événements – repérer plus rapidement et efficacement les défaillances d'ordinateurs présents sur un réseau.

3 Le service ● Le service Syslog est responsable de la prise en charge des fichiers de journalisation du système ● Accepte les logs provenants – du noyau (via klogd) – de n'importe quel processus local – et de processus sur systèmes distants. ● klogd est un démon responsable d'envoyer les messages émis par le noyau linux au démon syslogd – Lancé au démarrage du system avec syslogd

4 Intérêt ● Dépannage d'à peu près n'importe quel problème système ou applicatif ● Fournit des signes clairs et de valeurs sur d'éventuels abus du système ● Finalement, quand tout a planté, fournit des données « médico- légales » cruciales

5 Le format syslog ● Un journal contient en général les infos suivantes : – Date d'émission du log – Hostname de l'équipement ayant généré le log – Information sur le processus ayant généré le log – Niveau de gravité du log – Id du processus – Corps du message Sep 14 14:09:09 machine_de_test dhcp service[warning] 110 corps du message

6 Facilités (facilities) ● Simplement des catégories de logs ● Standard : auth, authpriv, cron, dæmon, kern, lpr, mail, mark, news, syslog, user, UUCP and local0 à local7 ● Correspondent souvent à un service – auth: used for many security events. – authpriv: used for access-control-related messages. – dæmon: used by system processes and other dæmons. – kern: used for kernel messages.

7 Facilités (facilities) (suite) – mark: messages generated by syslogd itself that contain only a timestamp and the string ``--MARK--''. To specify how many minutes should transpire between marks, invoke syslogd with the -m [minutes] flag. – user: the default facility when none is specified by an application or in a selector. – local7: boot messages. – *: wildcard signifying ``any facility''. – none: wildcard signifying ``no facility''.

8 8 niveaux de gravité (priority levels) ● Pour chaque facilité, il y a 8 niveaux de gravité ● 0 Emergency (le plus grave) ● 1 Alert ● 2 Critical ● 3 Error ● 4 Warning ● 5 Notice ● 6 Informational ● 7 Debug (le moins grave) ● Normalisé : interopérabilité possible entre équipements de collecte et de génération d'alerte

9 Configurer syslog /etc/syslog.conf ● Un processus client envoie un message de log au serveur, contenant une facilité et une priorité ● A la réception, ce message est enregistré le plus souvent dans un fichier, selon sa facilité et sa priorité – C'est le processus qui décide de la facilité et du niveau de gravité – C'est syslog qui décide où est enregistré l'évènement ● Par exemple, sendmail envoie un message mail.notice ● Syslog décide d'enregistrer cet événement dans /var/log/mail mail.notice /var/log/mail SelectorAction Facility.priorityWrite message to /var/log/mail

10 Configurer Syslog : selectors ● Selector = Facility.priority ● Facilités – Plusieurs facilities possible dans un selector, ou * ou none – mail, uucp.notice – *.emerg ● Priorités – Une seule facilité possible dans un selector – Hiérarchique : spécifier une priorité ● Spécifie la priorité + toutes les priorités supérieures ● mail.notice = mail.notice, warning, err, crit, aler, emerg

11 Configurer Syslog : selectors (suite) ● = devant la priorité précise seulement la priorité – mail.=notice : seule la priorité notice est enregistrée ● ! : négation de la priorité et supérieurs – mail.!notice : toutes les priorités sauf notice et supérieurs ● Combinaison : – mail.!=notice : toutes les priorités sauf notice

12 Configurer Syslog : selectors (suite) ● Plusieurs selectors possible sur une ligne mail,uucp.notice;uucp.!=alert /var/log/mail ● Facilités mail et uucp avec priorités notice et supérieures enregistrées – Sauf priorité alert de facilité uucp ● Tous examinés les uns après les autres, sans exception – contrairement à des règles dans un firewall ● On met le selector le plus général en premier

13 Configurer Syslog : actions ● En fonction de la facilité.priorité, une action associée – Souvent, écrire l'évènement dans un fichier ● mail.notice/var/log/mail ● Eviter la synchronisation : ● mail.notice-/var/log/mail – Pas d'écriture disque à chaque enregistrement – Utilise pour les fichiers de logs à écritures fréquentes – Mais risque de pertes de données

14 Configurer Syslog : actions ● Envoi possible à une machine ● *.emerg@mothership.mydomain.org – Le démon syslog sur la machine destination doit accepté les logs provenant du réseau (option -r ) ● Sauvegarde déportée indispensable à la sécurité : – Le pirate ne peut effacer ses traces sur un serveur distant – Impératif de mettre en place une sécurité basée sur ACL (TCPWrappers) sinon la machine écoute tout – Il peut être bien d'imprimer les logs sensibles – Stealth Logservers : logs envoyé à une machine sans adresse IP qui sniffe les packets

15 Configurer Syslog : actions ● On peut également envoyer à l'écran ● kern.warn;*.err;authpriv.none |/dev/console ● à un ou plusieurs utilisateurs, à l'écran, à une imprimante (/dev/lp0)

16 Tester les logs avec logger ! http://www.linuxjournal.com/article/5476

17 Résumé