[inetdoc.LINUX]

Comme indiqué dans la Section 1.3, « Logiciels utilisés », seuls les paquets de la distribution Debian GNU/Linux sont présentés ici. L'installation de sysklogd se résume donc à l'intruction suivante :

# apt-get install sysklogd

Par défaut, la configuration du service ne prévoit pas de recevoir des messages via le réseau. Il faut donc éditer le fichier /etc/init.d/sysklogd pour que le démon syslogd accepte les messages sur le port 514/udp. Voici une copie des 15 premières lignes du fichier /etc/init.d/sysklogd :

#! /bin/sh
# /etc/init.d/sysklogd: start the system log daemon.

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"

On se retrouve ici dans une situation voisine de celle du service tftpd à une différence importante près. Il n'est pas possible d'utiliser le tcpwrapper du super-démon inetd pour mettre en place un contrôle d'accès. Il ne reste que le filtrage pour limiter les accès réseau au démon syslogd. Voir Section 5.5, « Un soupçon de sécurité ».

Pour finir de configurer le service, il faut paramétrer la destination des messages reçus via le réseau. Cette opérattion se fait en ajoutant une ou plusieurs lignes au fichier /etc/syslog.conf. En reprenant l'exemple du commutateur 2950, voici un exemple :

local6.*                        /var/log/sw1.log

Ici, tous les messages du niveau de gravité 6 (Informational) seront placés dans le fichier /var/log/sw1.log. Le codage des niveaux de gravité dépend de l'équipement qui émet les messages de journalisation.

Une fois encore, c'est la syntaxe de l'IOS Cisco™ qui sert d'exemple de configuration. On ne traite qu'un seul exemple sachant que les commandes de configuration sont identiques entre routeurs et commutateurs. Voici un résumé des commandes permettant d'émettre des messages syslog sur le réseau.

logging on
logging buffered 16384
service sequence-numbers
service timestamp log datetime msec localtime show-timezone
!
logging 192.168.2.1
!
logging facility local6
logging trap Informational
!
logging source-interface Vlan2

Une fois cette configuration implantée, le fichier de journalisation reçoit les messages émis par l'équipement. Voici un extrait consécutif à un chargement de fichier de configuration via le service TFTP :

Jan 25 13:18:45 192.168.2.2 146: 000143: 2w0d: %LINEPROTO-5-UPDOWN: \
   Line protocol on Interface FastEthernet0/24, changed state to up
Jan 25 14:06:31 192.168.2.2 156: 000153: Jan 25 14:06:30.534 CET: %SYS-5-CONFIG_I: \
   Configured from tftp://192.168.2.1/sw1-confg by console

Le service syslog, tel qu'il a été introduit, présente au moins deux défauts : la sécurité et la non discrimination des sources.

Le volet sécurité sort du cadre de ce document. On se contente de donc de contrôler simplement les sources de messages : voir Section 5.5, « Un soupçon de sécurité ». Ensuite, on donne quelques pistes sur le contrôle d'intégrité des messages au point Journalisation système de la Section 8, « Pour aller plus loin ! ».

La non discrimination des sources d'émission de messages de journalisation est beaucoup plus génante du point de vue exploitation. En effet, la configuration présentée ci-dessus (voir Section 5.1, « Installation et configuration du service syslog ») a ouvert le port 514/udp en écoute et tous les messages reçus par ce canal sont rangés dans le fichier /var/log/sw1.log. Ce cas de figure convient très bien pour un équipement unique. Dans le cas où le nombre d'équipement augmente, ce point de stockage unique devient très vite difficile à gérer.

L'utilisation de syslog-ng permet de traiter cette difficulté simplement. Le démon syslog-ng se substitue complètement au démon syslog précédent. L'installation du paquet Debian GNU/Linux n'est pas différente des précédentes et le remplacement de syslog est automatique :

# apt-get install syslog-ng

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 :

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.

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.

Comme tftpd, le service syslogd n'est pas un modèle en matière de sécurité. Il est donc souhaitable de bien encadrer son utilisation. On configure le contrôle d'accès avec une règle de filtrage réseau par équipement.

Voici un extrait du fichier /var/lib/iptables/active utilisé par le script d'initialisation du paquet iptables.

*filter
:INPUT DROP [0:0]
<snip/>
-A INPUT -s 192.168.2.2 -p udp --dport 514 -m state --state NEW -j ACCEPT
<snip/>

Pour un exemple complet, voir Annexe A, Configuration type du filtrage réseau.