Gentoo Logo

1.  Introduction

Vous devriez augmenter le niveau de journalisation des événements pour obtenir plus d'avertissements ou de messages d'erreurs pouvant indiquer une attaque en cours ou ayant déjà porté ses fruits. Les attaquants scannent ou sondent généralement avant de commencer une attaque.

Il est également vital que les fichiers des journaux soient lisibles et facilement exploitables. Gentoo Linux vous permet de choisir entre 3 types de systèmes de journalisation au moment de l'installation.

1.  Syslogd

Syslogd est le système de journalisation le plus répandu sous Linux et UNIX en général. Il inclut un système de rotation de base pour les journaux, mais utiliser /usr/sbin/logrotate dans des tâches de cron est souvent recommandé, car il est plus puissant. Logrotate est configuré dans /etc/logrotate.conf. La fréquence de rotation des journaux que vous devriez paramétrer dépend de la charge de votre système.

Ci-dessous, vous trouverez le syslog.conf standard avec quelques fonctionnalités supplémentaires. Nous avons décommenté les lignes cron et tty et ajouté un serveur de journalisation distant. Pour encore plus de sécurité, vous pouvez ajouter les journaux dans deux emplacements.

Exemple de code 1.1 : /etc/syslog.conf

#  /etc/syslog.conf     Fichier de configuration pour syslogd.
#
#                       Pour plus d'informations, voir la page man syslog.conf(5).
#                       Cela provient de Debian, nous l'utilisons actuellement.
#                       Daniel Robbins, 5/15/99

#
# Tout d'abord quelques fichiers de journaux standards. Journal par fonction.
#

auth,authpriv.*                 /var/log/auth.log
*.*;auth,authpriv.none          -/var/log/syslog
cron.*                         /var/log/cron.log
daemon.*                        -/var/log/daemon.log
kern.*                          -/var/log/kern.log
lpr.*                           -/var/log/lpr.log
mail.*                          /var/log/mail.log
user.*                          -/var/log/user.log
uucp.*                          -/var/log/uucp.log
local6.debug                    /var/log/imapd.log

#
# Journaux pour le système de courrier. Séparez-le afin
# qu'il soit facile d'écrire des scripts pour analyser ces fichiers.
#
mail.info                       -/var/log/mail.info
mail.warn                       -/var/log/mail.warn
mail.err                        /var/log/mail.err

# Journaux pour le système de « news » INN.
#
news.crit                       /var/log/news/news.crit
news.err                        /var/log/news/news.err
news.notice                     -/var/log/news/news.notice

#
# Quelques fichiers de journaux « attrape-tout ».
#
*.=debug;\
        auth,authpriv.none;\
        news.none;mail.none     -/var/log/debug
*.=info;*.=notice;*.=warn;\
        auth,authpriv.none;\
        cron,daemon.none;\
        mail,news.none          -/var/log/messages

#
# Les urgences et alertes sont envoyées à toutes les personnes connectées.
#
*.emerg                         *
*.=alert                        *

#
# J'aime avoir des messages affichés sur la console, mais seulement
# sur une console virtuelle que je n'utilise pas.
#
daemon,mail.*;\
       news.=crit;news.=err;news.=notice;\
       *.=debug;*.=info;\
       *.=notice;*.=warn       /dev/tty8

# Installation d'un serveur de journaux distant.
*.*                        @logserver

# Le tube nommé /dev/xconsole est pour l'utilitaire `xconsole'.  Pour l'utiliser,
# vous devez invoquer `xconsole' avec l'option `-file' :
#
#    $ xconsole -file /dev/xconsole [...]
#
# NOTE : ajustez la liste ci-dessous ou vous allez devenir fou si vous avez
#        un site plutôt actif...
#
#daemon.*,mail.*;\
#       news.crit;news.err;news.notice;\
#       *.=debug;*.=info;\
#       *.=notice;*.=warn       |/dev/xconsole

local2.*                --/var/log/ppp.log

L'attaquant essaiera généralement d'effacer ses traces en éditant ou en effaçant les fichiers de journaux. Vous pouvez rendre sa tâche plus complexe en envoyant les journaux sur un ou plusieurs serveurs de journalisation situés sur des machines distantes. Vous trouverez plus d'informations sur syslogd en consultant sa page man (man syslog).

1.  Metalog

Metalog, écrit par Frank Dennis, n'est pour sa part pas capable de journaliser sur des serveurs à distance, mais il a bien d'autres avantages concernant les performances et la flexibilité de journalisation. Il peut journaliser par nom de programme, importance ou fonction (comme syslogd) et permet aussi l'analyse des journaux avec des expressions rationnelles permettant de déclencher l'exécution de commandes. Cela s'avère très pratique dans les situations qui demandent une réaction.

La configuration de base est généralement suffisante. Si vous voulez être averti par courrier quand une erreur de mot de passe est commise, utilisez l'un des scripts suivants.

Pour postfix :

Exemple de code 1.1 : /usr/local/sbin/mail_pwd_failures.sh pour postfix

#! /bin/sh
echo "$3" | mail -s "Attention (programme : $2)" root

Pour netqmail :

Exemple de code 1.1 : /usr/local/sbin/mail_pwd_failures.sh pour netqmail

#!/bin/sh
echo "To: root
Subject:Echec (Attention: $2)
$3
" | /var/qmail/bin/qmail-inject -f root

N'oubliez pas de rendre ces scripts exécutables en faisant /bin/chmod +x /usr/local/sbin/mail_pwd_failures.sh

Ensuite, décommentez les lignes de commande sous « Password failures » dans /etc/metalog/metalog.conf comme ceci :

Exemple de code 1.1 : /etc/metalog/metalog.conf

command  = "/usr/local/sbin/mail_pwd_failures.sh"

1.  Syslog-ng

Syslog-ng propose les mêmes fonctionnalités que syslog et metalog avec quelques petites différences. Il peut notamment filtrer les messages en se basant sur un niveau d'exécution et un contenu (tout comme metalog), gérer des journaux distants comme syslogd, exploiter des journaux venant de syslogd (même de flux venant de Solaris), écrire sur une console TTY, exécuter des programmes et être paramétré comme serveur de journaux. Il représente actuellement le meilleur système, combinant les qualités des deux autres programmes cités ci-dessus en ajoutant des options de configuration avancées.

Voici un fichier de configuration classique légèrement modifié :

Exemple de code 1.1 : /etc/syslog-ng/syslog-ng.conf

options {
        chain_hostnames(no);

        # L'action par défaut de  syslog-ng est d'écrire une ligne STATS
        # dans le fichier toutes les 10 minutes.  Après quelque temps c'est plutôt affreux.
        # Passez le à toutes les 12 heures et vous aurez une mise à jour journalière sur 
        # le nombre de messages que syslog-ng a manqué (0).
        stats_freq(43200);
};

source src {
    unix-stream("/dev/log" max-connections(256));
    internal();
};

source kernsrc { file("/proc/kmsg"); };

# Définir les destinations
destination authlog { file("/var/log/auth.log"); };
destination syslog { file("/var/log/syslog"); };
destination cron { file("/var/log/cron.log"); };
destination daemon { file("/var/log/daemon.log"); };
destination kern { file("/var/log/kern.log"); };
destination lpr { file("/var/log/lpr.log"); };
destination user { file("/var/log/user.log"); };
destination mail { file("/var/log/mail.log"); };

destination mailinfo { file("/var/log/mail.info"); };
destination mailwarn { file("/var/log/mail.warn"); };
destination mailerr { file("/var/log/mail.err"); };

destination newscrit { file("/var/log/news/news.crit"); };
destination newserr { file("/var/log/news/news.err"); };
destination newsnotice { file("/var/log/news/news.notice"); };

destination debug { file("/var/log/debug"); };
destination messages { file("/var/log/messages"); };
destination console { usertty("root"); };

# Par défaut, les messages sont écrits sur tty12...
destination console_all { file("/dev/tty12"); };

# ...si vous voulez utiliser /dev/console pour des programmes tels que xconsole
# vous pouvez mettre en commentaire la ligne destination au dessus de ces réferences /dev/tty12
# et décommenter la ligne en dessous.
#destination console_all { file("/dev/console"); };

# Créer les filtres
filter f_authpriv { facility(auth, authpriv); };
filter f_syslog { not facility(authpriv, mail); };
filter f_cron { facility(cron); };
filter f_daemon { facility(daemon); };
filter f_kern { facility(kern); };
filter f_lpr { facility(lpr); };
filter f_mail { facility(mail); };
filter f_user { facility(user); };
filter f_debug { not facility(auth, authpriv, news, mail); };
filter f_messages { level(info..warn)
        and not facility(auth, authpriv, mail, news); };
filter f_emergency { level(emerg); };

filter f_info { level(info); };
filter f_notice { level(notice); };
filter f_warn { level(warn); };
filter f_crit { level(crit); };
filter f_err { level(err); };
filter f_failed { message("failed"); };
filter f_denied { message("denied"); };

# Connecter le filter à la destination
log { source(src); filter(f_authpriv); destination(authlog); };
log { source(src); filter(f_syslog); destination(syslog); };
log { source(src); filter(f_cron); destination(cron); };
log { source(src); filter(f_daemon); destination(daemon); };
log { source(kernsrc); filter(f_kern); destination(kern); };
log { source(src); filter(f_lpr); destination(lpr); };
log { source(src); filter(f_mail); destination(mail); };
log { source(src); filter(f_user); destination(user); };
log { source(src); filter(f_mail); filter(f_info); destination(mailinfo); };
log { source(src); filter(f_mail); filter(f_warn); destination(mailwarn); };
log { source(src); filter(f_mail); filter(f_err); destination(mailerr); };

log { source(src); filter(f_debug); destination(debug); };
log { source(src); filter(f_messages); destination(messages); };
log { source(src); filter(f_emergency); destination(console); };

#Journal par défaut
log { source(src); destination(console_all); }

Syslog-ng est très simple à configurer, mais il est aussi très facile d'oublier quelque chose dans le fichier de configuration tellement il est volumineux. L'auteur nous promet d'autres améliorations comme le cryptage, l'authentification, la compression et le contrôle par adresse MAC (Mandatory Access Control). Avec ces options, il deviendra un système de journalisation réseau parfait étant donné que l'attaquant ne pourra plus espionner le journal.

Syslog-ng a un autre avantage : il n'a pas besoin d'être exécuté en tant que root !

1.  Analyse des journaux avec Logcheck

Bien sûr, journaliser les événements n'est que la moitié de la bataille. Une application telle que Logcheck peut faciliter grandement l'analyse régulière des journaux. Logcheck est un script accompagné d'un programme binaire nommé logtail, qui est exécuté à partir du démon cron et qui compare vos journaux à un ensemble de règles pour repérer une éventuelle activité suspecte. Il envoie ensuite le résultat par courrier à l'utilisateur root.

Logcheck et logtail font partie du paquet app-admin/logsentry.

Logcheck utilise quatre fichiers pour filtrer les journaux et départager les entrées importantes de celles qui ne le sont pas. Ces fichiers sont logcheck.hacking, qui contient des messages connus relatifs au « hacking », logcheck.violations, qui contient des motifs relatifs aux violations de sécurité, logcheck.violations.ignore, qui contient des mots-clés sensibles d'être présents dans le fichier des violations, ce qui permet d'ignorer les entrées ordinaires, et logcheck.ignore, qui correspond aux entrées à ignorer.

Attention : ne laissez pas logcheck.violations.ignore vide. Logcheck utilise grep pour l'analyse lexicale des journaux. Or, certaines versions de grep considèrent un fichier vide comme un joker. Toutes les violations seraient alors ignorées.

Dernière mise à jour le 2 avril 2010

Donate to support our development efforts.

Copyright 2001-2014 Gentoo Foundation, Inc. Questions, Comments? Contact us.