Les journaux, ou logs dans le
jargon, servent à enregistrer tous les évènements qui surviennent
sur un système. Historiquement, le service syslog a été développé pour la branche Unix des
systèmes BSD. Depuis, ce service
a été très largement adopté. On le retrouve sur tous les systèmes
Unix, GNU/Linux et surtout sur les équipements réseau de nombreux
constructeurs. Le protocole syslog
est décrit dans le document RFC3164 The BSD Syslog Protocol.
Dans le contexte de ce document, les messages syslog émis par les équipements réseau doivent
être collectés par une machine avec un système GNU/Linux. Ce type
de machine constitue un dépôt de référence avec horodatage des
évènements survenus sur le système d'information. Du point de vue
sécurité c'est un maillon essentiel du contrôle d'intégrité. Dans
le cas où des équipements ont été compromis, il subsistera toujours
des messages permettant de remonter à l'instant d'origine de
l'attaque.
Une fois les messages collectés, il faut les traiter. La problématique du traitement des journaux est un sujet d'étude à part entière qui sort du cadre de ce document. La Section 5.4, « Traitement des journaux » donne juste quelques pistes.
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'instruction 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ération 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 :
- 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.
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.
Voici un extrait de rapport relatif à l'utilisation d'une règle de filtrage sur un routeur :
Security Events =-=-=-=-=-=-=-= Jan 24 23:12:06 Router 20656: Jan 25 00:12:05.856 GMT: %SEC-6-IPACCESSLOGP: \ list inbound denied udp aaa.aaa.aaa.aaa(53) -> ddd.ddd.ddd.ddd(33434), 3 packets Jan 24 23:15:06 Router 20660: Jan 25 00:15:05.884 GMT: %SEC-6-IPACCESSLOGP: \ list inbound denied udp bbb.bbb.bbb.bbb(53) -> ddd.ddd.ddd.ddd(33434), 2 packets Jan 24 23:20:06 Router 20666: Jan 25 00:20:05.932 GMT: %SEC-6-IPACCESSLOGP: \ list inbound denied udp bbb.bbb.bbb.bbb(53) -> ddd.ddd.ddd.ddd(33434), 1 packet
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 conntrack --ctstate NEW -j ACCEPT <snip/>
Pour un exemple complet, voir Annexe A, Configuration type du filtrage réseau.